Motivation
Findings from the 2026-06 editor gap investigation:
- Block preview renders registry runes as unresolved shells.
collection / relationships / aggregate / xref / expand resolve in core postProcess against coreData.registry (packages/runes/src/config.ts), which the client-side block renderer never runs. RUNTIME_ONLY_TYPES in packages/editor/app/src/lib/preview/block-renderer.ts only placeholders nav*. Data-bound sandboxes (SPEC-093) are similarly dead in block mode. - The registry snapshot is stale.
loadContent() runs at startup and on save (packages/editor/src/server.ts); edits to page A don't reflect in page B's collections until a save round-trips. WORK-056 was filed for exactly this and is still untouched. - The field-match query grammar is typed blind.
collection, relationships, aggregate, sandbox data, and entityRoutes all share the SPEC-070 grammar (type:work filter="status:done" sort="-date"), with no autocomplete despite /api/aggregated carrying everything needed. - SPEC-092 entity frontmatter is invisible. Pages can declare
type / id to register as typed entities and arbitrary frontmatter is indexed as queryable data, but the frontmatter editor's known-field set is the pre-SPEC-092 eight (title, description, tags, draft, order, date, author, slug). - Generated pages don't exist in the editor.
entityRoutes / contributePages produce one page per matching entity; none appear in the file tree, so authors can't see the pages their config generates.
Design
1. Live registry (foundation)
Builds on WORK-056: maintain the registry incrementally — re-index the edited page on every change (debounced, not just on save) and push registry deltas to clients over the existing SSE channel (/api/events). The cached aggregated payload becomes a live view rather than a startup snapshot.
2. Query builder
One shared component for the SPEC-070 field-match grammar, used by every query surface (collection, relationships, aggregate + chart options, sandbox data, and later entityRoutes in SPEC-097):
- Type — dropdown of registered entity types (from the live registry), including rule-derived and frontmatter-declared types.
- Filter — chips over actual field names/values present on entities of the selected type; free-text escape hatch for the full grammar.
- Sort / group / limit / fields — dropdowns and steppers fed from the same field inventory;
group-order (SPEC-095) once groups are chosen. - Live result count — "matches 14 entities" evaluated against the live registry, updating as the query is edited.
The builder round-trips to attribute strings — it edits the markdown source, never a parallel representation.
3. Entity section in the frontmatter editor
type — dropdown of known entity types, plus free text for new types (open-world per ADR-016). Shows the entityRules-derived type as a read-only hint when a rule matches, and marks frontmatter type as an override.id — optional text field; validates uniqueness of (type, id) within scope against the live registry and warns on collision (mirroring the pipeline's last-write-wins warning at authoring time).- Custom fields — promote arbitrary key/value frontmatter to a proper editor (string / number / boolean / date / array inference), since SPEC-092 L1 made every custom field queryable data. Reserved keys (
layout, tint, region, …) stay in their dedicated UIs.
4. Registry inspector panel
A browsable view of the live registry: entities grouped by type, each showing its fields and edges. Actions: jump to the source page, insert an xref / expand / pre-filtered collection at the cursor. This doubles as the author's mental model of "what can I query".
5. Virtual pages in the content tree
Pages generated by entityRoutes appear in the file tree as read-only nodes with a "generated" badge, previewable like any page, linking back to the entity route that produced them and the source entity.
Acceptance Criteria
- The editor maintains a live registry: edits re-index the changed page (debounced) and clients receive updates without a save round-trip.
- A shared query-builder component edits the field-match grammar for
collection, relationships, aggregate, and sandbox data, with type/field/value autocomplete from the live registry and a live match count. - The frontmatter editor gains an Entity section:
type dropdown with rule-derived hint, id with (type, id) collision validation, and a typed custom-fields editor. - A registry inspector panel lists entities by type with fields and edges, and can insert
xref / expand / collection references. entityRoutes-generated pages appear as read-only virtual nodes in the content tree and are previewable.- All query/entity UI degrades gracefully when the registry is empty or still indexing (no blocking spinners over the editing surface).
Non-goals
- Editing relationships/edges from the inspector (read-only view first; edge authoring is a later iteration).
- Server-side rendering of registry blocks in block mode — that ships earlier and independently as WORK-393.
- Config-side query surfaces (
entityRoutes builder) — SPEC-097.
References
- SPEC-092 — frontmatter-declared registry entities (L1–L3).
- SPEC-093 — data-bound sandboxes (query surface).
- SPEC-095 — group-order (builder should expose it).
- WORK-056 — editor background registry (foundation).
- WORK-393 — registry-aware block preview (prerequisite fix).
- SPEC-070 — field-match grammar shared by all query surfaces.
packages/editor/src/server.ts, packages/editor/app/src/lib/preview/block-renderer.ts, packages/editor/app/src/lib/components/FrontmatterEditor.svelte, packages/content/src/registry.ts.