Skip to content

Studio metadata coverage gaps: surface remaining types + promote un-typed concepts #2657

Description

@os-zhuang

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 winsaction, dataset: previews are already registered in metadata-admin/previews, only the Interfaces-pillar rail load is missing.
  • Fill existing pillarsjob → Automations (next to flow); role → Access (next to permission/profile); seed/mapping → Data; datasource → Data or a "Sources" area.
  • New AI pillaragent (note ADR-0063 §2: platform-only, not runtime-creatable → read-only surface), tool, skill.
  • New System/Integration pillartranslation, 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 webhooks
  • connectors (ConnectorSchema) — external-system connectors
  • portals (PortalSchema) — external-user projections of apps/views/actions
  • sharingRules (SharingRuleSchema) — object sharing rules
  • apis (ApiEndpointSchema) — currently code-only via contributes.routes; formalizing as browsable metadata is what powers a first-class, executable API Console in Studio

Per the cross-repo flow, each of these must merge in framework (schema + registry) before objectui can consume it.

Ask

  1. Decide which of the Part B concepts are worth promoting to registered metadata types (and in what order).
  2. 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).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions