Skip to content

feat(ai): get_metadata_schema — let the AI read a type's contract before authoring#1561

Merged
xuyushun441-sys merged 1 commit into
mainfrom
feat/get-metadata-schema-tool
Jun 3, 2026
Merged

feat(ai): get_metadata_schema — let the AI read a type's contract before authoring#1561
xuyushun441-sys merged 1 commit into
mainfrom
feat/get-metadata-schema-tool

Conversation

@xuyushun441-sys
Copy link
Copy Markdown
Contributor

@xuyushun441-sys xuyushun441-sys commented Jun 3, 2026

Why

Follows the discussion of why the AI generated an invalid kanban view (#1559). Root cause: the authoring agent never sees the real spec Zod schemas. It works against a simplified blueprint or sends a free-form definition, and only learns the true shape from post-hoc validation errors. For complex types (view is 500+ lines, plus dashboard/flow/…) that means guessing — e.g. a kanban view's required kanban: { groupByField, columns } block.

Letting the runtime agent read the spec source folder isn't the answer (source isn't present at runtime — only compiled dist; it's an end-user-facing sandboxed agent without a filesystem tool; raw Zod is the wrong format). The right move is to serve the schema it already validates against.

What

New get_metadata_schema tool: returns the JSON Schema for a metadata type, derived (Zod v4 toJSONSchema) from the SAME getMetadataTypeSchema(type) the write path (saveMetaItem) validates against. The agent can read the exact contract and author a correct payload in one shot instead of trial-and-error.

  • Registered on the type-agnostic apply surface (now 12 metadata tools).
  • The metadata_authoring skill instructs the agent to call it before authoring a non-trivial type (kanban block as worked example).
  • Read-only; tolerates a plural type name.

Covers ALL app-development metadata types

Naively, object and action throw inside Zod v4's toJSONSchema because their schemas wrap/nest a .transform()/refine pipe (e.g. an object's actions: z.array(ActionSchema)). The handler uses a robust converter that peels pipes to their input side (io:'input') and, if whole-schema conversion still fails, recurses property-by-property / element-by-element — so every app-dev type yields a usable contract: object, field, view, page, dashboard, report, app, flow, action, agent, role, … (a genuinely unrepresentable leaf degrades to a placeholder rather than failing the whole call).

Tests

metadata-tools: returns a JSON-Schema-shaped contract for view, plural→singular resolution, graceful unknown-type error, and a sweep asserting all 11 core app-dev types serialize (object/action included). service-ai metadata + blueprint suites green (146).

🤖 Generated with Claude Code

@vercel
Copy link
Copy Markdown

vercel Bot commented Jun 3, 2026

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
spec Ready Ready Preview, Comment Jun 3, 2026 7:27am

Request Review

…contract

The authoring agent never sees the real spec Zod schemas; it guesses the shape
of complex types (view/dashboard/flow) and learns from validation errors. New
get_metadata_schema returns the JSON Schema (Zod v4 toJSONSchema) derived from
the same getMetadataTypeSchema the write path validates against, and the
metadata_authoring skill tells the agent to consult it before authoring a
non-trivial type. Read-only; plural-tolerant; graceful error for non-
serializable types (object — covered by create_object anyway).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
@xuyushun441-sys xuyushun441-sys force-pushed the feat/get-metadata-schema-tool branch from 7504959 to 35ce6f3 Compare June 3, 2026 07:25
@xuyushun441-sys xuyushun441-sys merged commit 4888ea2 into main Jun 3, 2026
12 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation size/m tests tooling

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants