Trusted native-plugin slots for content-list columns and editor sidebar panels

[logelog]

Problem

Native plugins can add their own admin pages, widgets, and fields, but they cannot augment the two core editorial surfaces where editors already work:

1. the content-list table, and
2. the saved-entry settings sidebar.

That leaves review status, SEO/readiness scores, workflow state, and similar cross-cutting tools with poor choices: duplicate the content list in a plugin page, ask editors to leave the editor, or use brittle DOM queries and mutation observers.

This is adjacent to, but intentionally different from:

• Per-collection admin list columns (admin.listColumns) — show custom fields in the content list #1717, which proposes schema-declared custom field columns for a collection;
• Editor extension point: plugin toolbar buttons, slash-menu items, and inline objects (lightweight complement to #1172) #1996, which proposes TipTap toolbar/inline editor extensions.

The proposal here is a trusted native-plugin host API for read-only list cells and saved-entry sidebar panels. It does not replace either proposal.

Proposed API

A native plugin's existing admin entry may export two optional typed contribution arrays:

export const contentListColumns: ContentListColumnExtension[] = [
  {
    id: "my-plugin:review-status",
    label: "Review",
    collections: ["posts"],
    cell: ReviewStatusCell,
  },
];

export const contentEditorPanels: ContentEditorPanelExtension[] = [
  {
    id: "my-plugin:review-status",
    title: "Review status",
    collections: ["posts"],
    minRole: 40,
    panel: ReviewStatusPanel,
  },
];

Shared contribution metadata:

• stable id
• deterministic order
• collection filter
• minimum role

Host behavior:

• The host owns <th>, <td>, panel section markup, placement, and accessibility.
• Contributions receive read-only, already-loaded saved-entry context.
• Columns apply to the main content list, not Trash.
• Panels render for saved entries only and stay inside the existing narrow/off-canvas settings sidebar.
• Disabled plugins, insufficient roles, collection mismatches, or no contributions preserve the classic markup exactly.
• Duplicate ids are deterministic and logged.
• Each header/cell/panel is isolated by an error boundary so one plugin cannot break the list or editor.

Trust and performance boundary

These slots are available only to format: "native" plugins that already ship an adminEntry into the admin SPA. Sandboxed plugins remain Block Kit-only and cannot reach the registry.

List cells receive the row that is already loaded. The host performs no request per row; documentation explicitly requires shared/batched query keys for any extra data to avoid N+1 traffic.

Prototype

A documented implementation is available for design/API review:

• Branch: https://github.com/logelog/emdash/tree/feat/admin-content-extension-slots
• Includes typed registry/loading, disabled-plugin lifecycle, role/collection filtering, deterministic ordering, error boundaries, docs, tests, and changeset.
• Validation: admin typecheck passed; 27 targeted browser/unit tests passed; git diff --check passed.
• The branch contains no site-specific code, branding, or private plugin implementation.

I will not open a feature PR until maintainers approve the direction. If the API is too broad, the branch can be split into list columns first and editor panels second.

Open questions

1. Should the first PR include both surfaces, or start with content-list columns only?
2. Should plugins receive only the saved row/entry, or also a host-provided batched loader primitive?
3. Is minRole useful at contribution level, or should visibility be entirely controlled inside the component?
4. Should core expose a constrained Block Kit version for sandboxed plugins later, as a separate proposal?