feat(admin): show configured fields in content lists

[logelog]

What does this PR do?

Adds collection-level custom field columns to the admin content list.

Collections can opt into up to four scalar fields through admin.listColumns. The collection schema, seed import/export path, API payloads, and runtime manifest preserve that configuration. The manifest validates configured fields, removes duplicates, ignores unknown or unsupported field types, and exposes the field metadata needed by the admin.

The content list renders those fields between Title and Status without extra per-row requests. Select and multi-select values use their configured labels, booleans and dates receive compact formatting, and long values stay bounded so they cannot distort the table.

Searchable custom fields are handled separately in #2191. Trusted plugin-computed columns are handled in #2195. Server-backed indexed sorting and filtering are handled in #2212 and #2213.

#2195 and #2212 are stacked on this branch so all five contributions can be reviewed at the same time without duplicating the collection-column infrastructure. This PR should merge before those two; GitHub will then narrow their diffs automatically.

Addresses #2179
Related design discussion: #1717

Type of change

• Bug fix
• Feature (requires maintainer-approved Discussion)
• Refactor (no behavior change)
• Translation
• Documentation
• Performance improvement
• Tests
• Chore (dependencies, CI, tooling)

Checklist

• I have read CONTRIBUTING.md
• pnpm typecheck passes
• pnpm lint passes
• pnpm test passes (or targeted tests for my change)
• pnpm format has been run
• I have added/updated tests for my changes (if applicable)
• User-visible strings in the admin UI are wrapped for translation (if applicable)
• I have added a changeset (if this PR changes a published package)
• New features link to an approved Discussion: Per-collection admin list columns (admin.listColumns) — show custom fields in the content list #1717 (opened, awaiting maintainer review)

AI-generated code disclosure

• This PR includes AI generated code: Claude Opus 5, GPT-5.6 (via private dev orchestra)

Screenshots / test output

Validated on EmDash 0.32.0 (base 776d65f7) with Node 24.16.0 and pnpm 11.9.0 on macOS. The workspace has all six stacked contributions applied, so these are the integrated totals rather than a per-PR subset:

• core: 403 files, 5211 tests passed, 3 skipped
• admin: 117 files, 1421 tests passed
• Cloudflare: 21 files, 300 tests passed
• Workerd: 12 files, 84 tests passed
• real local D1: 2 files, 7 tests passed
• typechecks and builds for admin, core, cloudflare, workerd, and the demo lab

CI runs each PR on its own branch.

[changeset-bot]

🦋 Changeset detected

Latest commit: 0f5c7c0

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 17 packages

Name	Type
emdash	Minor
@emdash-cms/admin	Minor
@emdash-cms/cloudflare	Minor
@emdash-cms/sandbox-workerd	Patch
@emdash-cms/plugin-mcp-smoke	Major
@emdash-cms/fixture-perf-site	Patch
@emdash-cms/perf-demo-site	Patch
@emdash-cms/cache-demo-site	Patch
@emdash-cms/do-demo-site	Patch
@emdash-cms/do-solo-demo-site	Patch
@emdash-cms/auth	Minor
@emdash-cms/blocks	Minor
@emdash-cms/gutenberg-to-portable-text	Minor
@emdash-cms/x402	Minor
create-emdash	Minor
@emdash-cms/auth-atproto	Patch
@emdash-cms/plugin-embeds	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[github-actions]

Scope check

This PR touches 23 files. PRs with a broad scope are harder to review. Please confirm the scope hasn't drifted beyond the intended change.

If this scope is intentional, no action needed. A maintainer will review it. If not, please consider splitting this into smaller PRs.

See CONTRIBUTING.md for contribution guidelines.

[pkg-pr-new]

Open in StackBlitz

@emdash-cms/admin

npm i https://pkg.pr.new/@emdash-cms/admin@2194

@emdash-cms/auth

npm i https://pkg.pr.new/@emdash-cms/auth@2194

@emdash-cms/auth-atproto

npm i https://pkg.pr.new/@emdash-cms/auth-atproto@2194

@emdash-cms/blocks

npm i https://pkg.pr.new/@emdash-cms/blocks@2194

@emdash-cms/cloudflare

npm i https://pkg.pr.new/@emdash-cms/cloudflare@2194

@emdash-cms/contentful-to-portable-text

npm i https://pkg.pr.new/@emdash-cms/contentful-to-portable-text@2194

emdash

npm i https://pkg.pr.new/emdash@2194

create-emdash

npm i https://pkg.pr.new/create-emdash@2194

@emdash-cms/gutenberg-to-portable-text

npm i https://pkg.pr.new/@emdash-cms/gutenberg-to-portable-text@2194

@emdash-cms/plugin-cli

npm i https://pkg.pr.new/@emdash-cms/plugin-cli@2194

@emdash-cms/plugin-types

npm i https://pkg.pr.new/@emdash-cms/plugin-types@2194

@emdash-cms/registry-client

npm i https://pkg.pr.new/@emdash-cms/registry-client@2194

@emdash-cms/registry-lexicons

npm i https://pkg.pr.new/@emdash-cms/registry-lexicons@2194

@emdash-cms/registry-verification

npm i https://pkg.pr.new/@emdash-cms/registry-verification@2194

@emdash-cms/sandbox-workerd

npm i https://pkg.pr.new/@emdash-cms/sandbox-workerd@2194

@emdash-cms/x402

npm i https://pkg.pr.new/@emdash-cms/x402@2194

@emdash-cms/plugin-ai-moderation

npm i https://pkg.pr.new/@emdash-cms/plugin-ai-moderation@2194

@emdash-cms/plugin-atproto

npm i https://pkg.pr.new/@emdash-cms/plugin-atproto@2194

@emdash-cms/plugin-audit-log

npm i https://pkg.pr.new/@emdash-cms/plugin-audit-log@2194

@emdash-cms/plugin-color

npm i https://pkg.pr.new/@emdash-cms/plugin-color@2194

@emdash-cms/plugin-embeds

npm i https://pkg.pr.new/@emdash-cms/plugin-embeds@2194

@emdash-cms/plugin-field-kit

npm i https://pkg.pr.new/@emdash-cms/plugin-field-kit@2194

@emdash-cms/plugin-forms

npm i https://pkg.pr.new/@emdash-cms/plugin-forms@2194

@emdash-cms/plugin-webhook-notifier

npm i https://pkg.pr.new/@emdash-cms/plugin-webhook-notifier@2194

commit: 0f5c7c0

[emdashbot]

This PR correctly implements collection-level custom field columns for admin content lists as an additive, scoped feature. The approach fits EmDash's architecture: admin.listColumns is persisted in _emdash_collections.admin_config as JSON, travels through seeds and schema APIs, is validated/deduplicated/capped in the manifest build, and is rendered client-side from data already present in the content list payload (no extra per-row queries).

I reviewed the diff statically and traced the changes across the migration, schema registry, seed apply/validate/export, runtime manifest build, admin manifest types, and the ContentList component. I checked for Lingui coverage, RTL-safe Tailwind, SQL safety, API envelope consistency, query-count impact, comment discipline, and test coverage.

Headline conclusion: the code is clean. The migration is guarded by columnExists. The registry round-trips admin_config correctly and preserves existing list columns on unrelated updates. The manifest filter caps list columns at four supported, existing field types and warns appropriately. The admin UI renders headers and cells with logical Tailwind classes and uses the existing manifest/field metadata for select/multi-select labels and compact formatting. Tests cover the manifest cap behavior, registry persistence, migration registration, and component rendering.

I did not run the test suite, linter, or build; the author reports passing checks in the PR description.

[github-actions]

Overlapping PRs

This PR modifies files that are also changed by other open PRs:

• feat(admin): allow trusted plugins to add content list columns #2195 (3 shared files)
• feat(core): configurable titleField and dateField per collection #1973 (12 shared files)
• feat: reference field type (storage-less edges + admin UI) #1928 (8 shared files)
• feat(admin): add date-only content field #1365 (6 shared files)

This may cause merge conflicts or duplicated work. A maintainer will coordinate.

[emdashbot]

Re-review of feat/content-list-custom-field-columns. This is the same diff that was approved in the previous pass; I re-read the full diff and the changed files plus AGENTS.md and found no new code issues.

What I checked again

• The migration (055_collection_admin_config) is idempotent via columnExists and only adds a nullable text column — safe and forward-only.
• Registry create/update/seed round-trips admin_config correctly and preserves existing list columns on unrelated updates.
• API schema and admin client types expose admin.listColumns with slug validation.
• Runtime manifest build validates configured columns against existing fields, removes duplicates, ignores unsupported types, and caps at four in memory (no extra DB queries).
• ContentList renders the new columns from item.data already present in the list payload, so there are no per-row requests.
• Lingui wraps user-facing strings (Not set, Yes, No); custom headers use RTL-safe text-start; no raw SQL interpolation.
• Tests cover manifest capping, registry persistence, seed export/validate, and component rendering.

Headline conclusion
The implementation is still clean. No line-level findings.

Still-open governance item (not a code defect)
The PR checklist notes that the feature’s design discussion (#1717) is opened, awaiting maintainer review. AGENTS.md asks for a maintainer-approved Discussion before a feature merges, so that approval should land before this is merged. With that resolved, the code is ready to go.