Summary
Coverage audit of the new object-centric Studio (StudioDesignSurface, objectui packages/app-shell) against the authoritative metadata-type registry in @objectstack/spec (DEFAULT_METADATA_TYPE_REGISTRY). Of the 27 authorable metadata types, the new Studio surfaces ~11; the rest have no home yet. This issue tracks the gaps.
Two of the gaps (per-object API reference + Hooks inventory) are already being handled on the objectui side (feat/studio-object-api-hook-tabs) and are out of scope here.
Coverage matrix
| Domain |
Type |
New Studio |
| Data |
object |
✅ full (fields / form / validations / settings) |
| Data |
field validation |
🟡 nested in object (validation: only script editable) |
| Data |
hook |
🟠 in-progress (objectui, separate PR) |
| Data |
seed mapping |
❌ |
| UI |
view page dashboard app report |
✅ Interfaces pillar |
| UI |
action dataset |
❌ previews already registered, just not railed |
| Automation |
flow |
✅ Automations pillar |
| Automation |
job |
❌ |
| Security |
permission profile |
✅ Access pillar |
| Security |
role |
❌ |
| System |
datasource translation email_template book doc |
❌ |
| System |
external_catalog |
➖ runtime-derived by Sync wizard — intentionally skip |
| AI |
agent tool skill |
❌ no AI pillar exists |
Work split
A. objectui Studio UI (spec already complete — no framework change needed)
These are registered types with Zod schemas; the work is purely surfacing them in Studio (rail wiring + reuse of the generic SchemaForm, or a bespoke canvas where the structure warrants it).
- Quick wins —
action, dataset: previews are already registered in metadata-admin/previews, only the Interfaces-pillar rail load is missing.
- Fill existing pillars —
job → Automations (next to flow); role → Access (next to permission/profile); seed/mapping → Data; datasource → Data or a "Sources" area.
- New AI pillar —
agent (note ADR-0063 §2: platform-only, not runtime-creatable → read-only surface), tool, skill.
- New System/Integration pillar —
translation, email_template, book/doc; this is also the natural home for a global, executable API Console + auth (Authorize) control.
(Tracked here for a single platform-wide view; execution lands in objectui.)
B. framework @objectstack/spec (blocking dependency — must land here first)
These concepts exist in ObjectStackDefinitionSchema (stack.zod.ts) as config but are not registered metadata types, so Studio cannot surface them generically until they pass the ADR-0088 admission test and get a Zod schema + registry entry:
Per the cross-repo flow, each of these must merge in framework (schema + registry) before objectui can consume it.
Ask
- Decide which of the Part B concepts are worth promoting to registered metadata types (and in what order).
- Confirm the Part A placement plan (pillars) so objectui can schedule the UI work.
Generated from a two-repo coverage audit (framework spec × objectui new Studio).
Summary
Coverage audit of the new object-centric Studio (
StudioDesignSurface, objectuipackages/app-shell) against the authoritative metadata-type registry in@objectstack/spec(DEFAULT_METADATA_TYPE_REGISTRY). Of the 27 authorable metadata types, the new Studio surfaces ~11; the rest have no home yet. This issue tracks the gaps.Two of the gaps (per-object API reference + Hooks inventory) are already being handled on the objectui side (
feat/studio-object-api-hook-tabs) and are out of scope here.Coverage matrix
objectfieldvalidationscripteditable)hookseedmappingviewpagedashboardappreportactiondatasetflowjobpermissionprofileroledatasourcetranslationemail_templatebookdocexternal_catalogagenttoolskillWork split
A. objectui Studio UI (spec already complete — no framework change needed)
These are registered types with Zod schemas; the work is purely surfacing them in Studio (rail wiring + reuse of the generic
SchemaForm, or a bespoke canvas where the structure warrants it).action,dataset: previews are already registered inmetadata-admin/previews, only the Interfaces-pillar rail load is missing.job→ Automations (next toflow);role→ Access (next to permission/profile);seed/mapping→ Data;datasource→ Data or a "Sources" area.agent(note ADR-0063 §2: platform-only, not runtime-creatable → read-only surface),tool,skill.translation,email_template,book/doc; this is also the natural home for a global, executable API Console + auth (Authorize) control.(Tracked here for a single platform-wide view; execution lands in objectui.)
B. framework
@objectstack/spec(blocking dependency — must land here first)These concepts exist in
ObjectStackDefinitionSchema(stack.zod.ts) as config but are not registered metadata types, so Studio cannot surface them generically until they pass the ADR-0088 admission test and get a Zod schema + registry entry:webhooks(WebhookSchema) — outbound webhooksconnectors(ConnectorSchema) — external-system connectorsportals(PortalSchema) — external-user projections of apps/views/actionssharingRules(SharingRuleSchema) — object sharing rulesapis(ApiEndpointSchema) — currently code-only viacontributes.routes; formalizing as browsable metadata is what powers a first-class, executable API Console in StudioPer the cross-repo flow, each of these must merge in framework (schema + registry) before objectui can consume it.
Ask
Generated from a two-repo coverage audit (framework spec × objectui new Studio).