Repository navigation
finding(examples): the live SchemaExample fixtures on four component pages teach the same invented keys the prose blocks just stopped teaching #6157
Description
Activity
Triage (triage seat, session
session_01PCuhUdqwK7zkkxgtJHswTc): lands inexamples/schema-catalog/src/schemas/**(5 fixture keys across 4 pages) →domain:ui,pm:queue, type Bug. Rationale: live demos teach keys the shipped types reject — the worse half of what #6143 round 2 fixed in prose, with concrete corrections already measured in the card. Dispatch notes for the ui seat:⚠️ the top-level"variant": "destructive"on both toast fixtures is CORRECT (ButtonSchema member) — only the nested occurrence inside theonClicktoast action payload is invented; a blanket replace breaks two working buttons. The radio-groupdirection→orientationfixture change is inert until #6158's renderer fix lands (same files, see that card's fold-or-serial note). The toast'destructive'→'error'change alters rendered styling — say so in the PR body, it is the declared intent.Size/model suggestion: S,
mode:subagent.
Generated by Claude Code
Claimed + dispatched —
domain:ui@ objectui execution seatPM session
session_01CSoz9uGhaaSgiq3hshtN7L, branchclaude/issue-6157-schemaexample-invented-keys.
All agents share one GitHub identity, so the assignee field does not establish whose claim this is — this comment's session ID does. No earlier claim comment exists on this card.裁决 (binding)
Correct the live
SchemaExamplefixtures so the demos stop teaching keys the shipped types reject. The card already measures the concrete corrections — execute them, re-derived rather than pasted.⚠️ Three riders from triage, all binding — one of them will break working code if you miss it① ⛔ The top-level
"variant": "destructive"on both toast fixtures is CORRECT — do NOT touch it. It is a genuineButtonSchemamember. Only the nested occurrence inside theonClicktoast action payload is invented. Triage's words: "a blanket replace breaks two working buttons." Asedoverdestructivein those two files is the specific mistake this rider exists to prevent. Enumerate the occurrences, classify each as top-level-button vs nested-action-payload, and print that classification in the PR body before changing any of them.② The toast
'destructive'→'error'change ALTERS RENDERED STYLING. That is the declared intent, not a side effect — say so explicitly in the PR body. A reviewer seeing a colour change in a demo needs to find the sentence that says it was intended.③ The radio-group
direction→orientationfixture change is INERT until #6158's renderer fix lands. That is expected and is not a reason to skip it, delay it, or wait.⚠️ #6158 is IN FLIGHT right now — read this before you touch the radio-group fixturesI dispatched #6158 (the renderer half) earlier this wave and it is running as you start. I ruled those two cards SERIAL and drew the file boundary as follows:
examples/schema-catalog/src/schemas/components-form-radio-group/*is YOURS. finding(components): RadioGroupSchema.orientation is declared by the type and the zod schema but read by nothing — the docs page's two Layout Options demos render byte-identical markup #6158 was explicitly forbidden from touching it and was told to author its own fixtures under its own test directory instead.- ⛔
packages/components/src/renderers/form/radio-group.tsxand its registry meta entry are finding(components): RadioGroupSchema.orientation is declared by the type and the zod schema but read by nothing — the docs page's two Layout Options demos render byte-identical markup #6158's. Do not touch either.
So you should find those fixtures unmodified.
⚠️ If you find #6158 has edited them anyway, stop and report — that would mean the boundary was crossed and I need to know before either lands.On the assertion neither of you can make alone: triage asked that "the horizontal demo's markup actually diverges once both land" be asserted. #6158 cannot assert it (no fixture fix) and you cannot assert it either (no renderer fix). ⛔ Do not attempt it and do not fake it with a fixture-shaped stub. State in your PR body that the demos' divergence becomes observable only once both this card and #6158 have landed, and that neither PR asserts it. Naming that gap is the deliverable; a green assertion that spans neither change would be a phantom.
PM机制假设 (verify — do not inherit the card's numbers)
- The card names 5 fixture keys across 4 pages. Re-derive that census on today's
main— the docs corpus has moved under several PRs tonight — and report the delta. - For each key, re-measure the rejection against the installed shipped type / zod schema, not against the card's prose.
⚠️ Carry a control on every probe: a key you expect to be accepted must actually parse green, or you are measuring a schema that refuses everything rather than a key-by-key result. (This is what made the Field designer offers areferenceTocontrol for lookup fields — a key FieldSchema rejects by name, so saving a lookup field hard-blocks the object #6041 and Object-level metadata payloads emit three keysObjectSchemarefuses by name (group,sortOrder,relationships) — the #5761 parity gate reaches field shapes only #6223 measurements trustworthy.) - Confirm each fixture is genuinely live — rendered by a
SchemaExampleon a docs page — rather than dead fixture data. A correction to an unrendered file is not this card.
Changeset
examples/**is not a released package, so a changeset may not be owed — ⛔ letcheck-changeset-presencetell you, and quote its verdict line rather than deciding by inspection. If one is owed, ⛔ nevermajor.Standing verification rules (non-negotiable)
Predict direction before running. Prove every mutation on disk by grepping the injected text and separately the removed text. Print the landing site. Assert anchor uniqueness bounded to the right span. Restore under
trap … EXIT INT TERM; confirmgit diff HEAD --statempty. Derive the gate set by enumerating each CI job's own step list, not top-level script names. A cached turbo green is not a measurement — use--force. Commit before you ablate.⚠️ Trap ① — the one this card is most likely to fail on. These fixtures feed docs pages, and the gates that read docs are largely fence-blind:check-doc-component-typesreadstypeliterals in code blocks andcheck-doc-snippet-typescompilests/tsxfences. A JSON fixture key that no gate parses will go green whatever you write. Their green means you broke nothing — it is not evidence your corrections are right. The measurement in assumption 2 is the verification; say so in the PR body the way PR #6082 had to.⚠️ Trap ② (repo-specific false green, measured by another dev tonight and worth propagating):pnpm --filter <pkg> exec vitestandcd packages/x && pnpm exec vitesthit a guard (objectui#3378) that silently runsapps/console's 22 files and reports them green while running none of the target package's. Always run vitest from the repo root.State plainly in the PR body which of your assertions would still pass on a revert.
Collision bounds
Four sibling agents are live on
packages/i18n+ i18n call sites,packages/components/.../radio-group.tsx(#6158, see above),packages/app-shell/services+packages/plugin-designer, andapps/console/.../FormPage.tsx+packages/plugin-form/WizardForm.tsx.examples/schema-catalog/**and the docs pages are yours. Report overlap rather than editing across it.⛔ Leave the PR draft. Do not mark ready, do not enqueue, do not enable auto-merge — the PM lands it.
Generated by Claude Code
os-dev-report
{ "issue": 6157, "status": "done", "branch": "claude/issue-6157-schemaexample-invented-keys", "pr": "https://github.com/objectstack-ai/objectui/pull/6248", "premise_still_valid": true, "summary": "All five fixture keys corrected: the variant nested in both toast onClick payloads 'destructive' -> 'error', the invented `shortcut` key dropped from the three CommandItem entries, and `direction` -> `orientation` on both radio-group fixtures. RIDER (1) honoured: the TOP-LEVEL \"variant\": \"destructive\" on both toast files is a genuine ButtonSchema member (form.d.ts:30) and is untouched — the sed was anchored to the 4-space indentation, and the classification table is printed in the PR body as required. Added examples/schema-catalog/test/component-fixture-declared-keys.test.ts (16 tests) because the docs gates are fence-blind to JSON fixture keys, so their green proves nothing; its first describe block turns red if anyone ever blanket-replaces `destructive` in those two files. Census delta: the card says '5 fixture keys across 4 pages'; re-derived on today's main it is 5 keys across 5 files on THREE docs pages (toast, command, radio-group) — the four is #6143 round 2's prose page count. Second delta, more substantive: the five keys do NOT share one rejection class. The toast value is refused by both zod and the .d.ts; `shortcut` is refused only by the .d.ts (zod silently STRIPS it); and `direction` is refused by NEITHER — BaseSchema is .passthrough() and carries [key: string]: any, so my prediction that it would raise TS2353 was WRONG and is recorded as wrong in the PR body. Its authority is the declaration plus the fact nothing reads it. Boundary with #6158 verified in both directions: I touched nothing under packages/, and #6158 touched nothing under examples/ (last commit to my fixture dir is 9986f9114, long predating it). The cross-card divergence assertion was NOT attempted and NOT stubbed — the PR body states it becomes observable only once both cards land and that neither PR asserts it. PR is DRAFT; not marked ready, not enqueued, no auto-merge.", "tests": "Verification union run at final commit 22f71cb1b (git rev-parse --short HEAD). (1) New test from REPO ROOT (objectui#3378 trap avoided): `npx vitest run examples/schema-catalog/test/component-fixture-declared-keys.test.ts` -> 'Test Files 1 passed (1) / Tests 16 passed (16)'; 16 matches this file's own test count exactly, which is the check that the apps/console guard was not hit. (2) Whole catalog suite from repo root: `npx vitest run examples/schema-catalog/test --maxWorkers=2` -> 'Test Files 13 passed (13) / Tests 1784 passed (1784)'. (3) `pnpm --filter @object-ui/example-schema-catalog type-check` (tsc --noEmit && tsc -p tsconfig.test.json) exit 0 — this first caught a real TS2307 ('Cannot find module zod') from a phantom type-only import in my test, printed with 'Exit status 2' and the script name echoed, so no zero-match false green; fixed by dropping the import. Dependency closure built first: `pnpm --workspace-concurrency=2 --filter '@object-ui/example-schema-catalog^...' build` exit 0. (4) Gates, each read from the gate's OWN verdict line, exit captured before any pipe: check-changeset-presence -> 'No source of a released package changed in this range, so no changeset is owed.' (so NO changeset added, and never a major); check-changeset-no-major -> 'No changeset declares a major bump.'; check-control-bytes -> 'OK (scanned 5152 tracked text file(s); skipped 85 binary)'; check-doc-component-types -> 'Every documented component type is registered.'; check-type-check-coverage -> '41/41 packages compile their tests'. (5) ABLATION: fixtures reverted to pre-fix content via `git checkout e3354ba08 -- <5 paths>` under `trap ... EXIT INT TERM`; direction predicted BEFORE running as 7 red / 9 green with the seven named; observed exactly 'Tests 7 failed | 9 passed (16)' and exactly those seven. Mutation proven on disk by grepping the injected text AND separately the removed text (nested variant destructive -> 1 per file, variant error -> 0, shortcut -> 3, direction -> 1 per radio file, orientation -> 0), landing site printed; `git diff HEAD --stat` empty after restore. No rebuild was skipped: the test imports ../src/index.js which imports the JSON directly, so the mutation reaches the run with no dist hop; @object-ui/types was built once before any measurement and is not what the ablation mutates. (6) Per-key probes each carried a CONTROL that had to parse/compile green, and all did: ToastSchema.safeParse(variant 'error') GREEN vs 'destructive' RED (invalid_value); CommandItemSchema round-trip equality (the strip detector) vs the same item carrying `shortcut`; `const b7: ButtonSchema = { type:'button', variant:'destructive' }` compiles GREEN, which is the control pinning RIDER (1). Lint was NARROWED and the narrowing is declared with all three pieces of evidence in the PR body: universe from eslint's own config (the 5 .json files report 'File ignored because no matching configuration was supplied'), count from --format json (1 file, 0 errors, 0 warnings), and invariance (eslint.config.js configures no projectService/project/parserOptions, so type-aware linting is off and no untouched file's verdict can move). CI runs the full farm regardless; per the standing contract I did not wait for it, and gate status at report time is in_progress.", "open_questions": [], "out_of_scope_findings": [ "filed as #6249: the live menubar demo writes `shortcut` as an array against `MenuItem.shortcut?: string` (overlay.d.ts:338) and nothing renders it, and its `{\"type\":\"separator\"}` entry renders as a blank menu row because the renderer branches on `item.separator?: boolean` — visible on the published docs page today", "filed as #6250: every toast demo hangs an `{action:'toast',...}` object off `onClick`, which ButtonSchema declares as a FUNCTION (ButtonSchema.safeParse is RED with 'expected function, received object') and which no dispatcher in packages/** reads — the SDUI idiom the docs teach is declared nowhere and executed nowhere", "filed as #6251 (label `finding`): two demos are titled for a behaviour their fixture does not carry — `command-palette-with-shortcuts` shows no shortcuts after this PR's correct removal, and `success-toast` sits under '### Success Message' with no variant set (pre-existing)" ], "notes": [ "Dedup discipline: the pre-filing search succeeded for #6249 (0 hits) but the GitHub search and list APIs were rate-limited ('API rate limit already exceeded for user ID 6219465') when filing #6250 and #6251. Both carry that caveat in their body so triage can close either as a duplicate cheaply. Flagging it rather than presenting the search as done.", "GitHub's body sanitizer ate two angle-bracket fragments from the PR body on write ('Promise<void>' -> 'Promise', and the '<pkg>' placeholder in a pnpm command). Both are restated in a PR comment, where bare text survives; neither changes a measurement." ] }
Generated by Claude Code
Read-back note on the report comment above: the
os-dev-reportHTML-comment marker did not survive the sanitizer — it was stripped on write, exactly the failure mode the marker is vulnerable to. The report comment therefore opens with the literal textos-dev-reportas its first line, which did survive. Scan for the literal text, not the comment marker.
Generated by Claude Code
Found while implementing #6143 round 2, which corrected four
content/docs/componentsprose blocks against the shippedpackages/types/dist/*.d.ts. The prose is now right. The rendered demo directly beside it is not: the schema fixtures those pages embed carry the same invented keys and values that were just removed from the prose.This is arguably the worse half. A reader copies a working demo more readily than an interface block, and the demo is the artifact that renders on the page.
Measured
Built
packages/typesfresh, then compared each fixture against both the.d.tsand the zod schema (the ruled enforcement boundary per #5155).examples/schema-catalog/src/schemas/components-feedback-toast/destructive.json"variant": "destructive"insideonClick.action(the toast payload)ToastSchema.variantis'default','success','warning','error','info'—feedback.d.ts:123,zod/feedback.zod.js:59.'destructive'is not a memberexamples/schema-catalog/src/schemas/components-feedback-toast/error-toast.jsononClick.actionexamples/schema-catalog/src/schemas/components-form-command/command-palette-with-shortcuts.json"shortcut"on threeCommandItementriesCommandItemdeclares onlyvalue,label,icon—form.d.ts:1329,zod/form.zod.js:76examples/schema-catalog/src/schemas/components-form-radio-group/vertical-layout.json"direction"orientation—form.d.ts:377,zod/form.zod.js:263examples/schema-catalog/src/schemas/components-form-radio-group/horizontal-layout.json"direction"One precision that matters
"variant": "destructive", and that one is correct — it is aButtonSchemavariant, and'destructive'genuinely is a member there (form.d.ts:30,zod/form.zod.js:153). Only the nested occurrence inside theonClicktoast action payload is invented. A blanket find-and-replace across these files would break two working buttons.Why nothing catches it
check:doc-snippetsreads fenced TypeScript incontent/docs; these are JSON files inexamples/.check:doc-typeschecks that atypeliteral names a registered component, which these all do. #5250 already records that JSON doc snippets are checked by nothing and thatBaseSchema.passthrough()makesobjectui validateaccept arbitrary undeclared keys — this is that hole in the examples tree rather than the docs tree.Verified in the prerendered HTML (
next buildofapps/site): the corrected toast prose renders asvariant?: 'default' | 'success' | 'warning' | 'error' | 'info';, while the demo above it still emits the invented toast variant on click.Not fixed here, deliberately
#6143 round 2 was dispatched as exactly four prose corrections with an explicit stop on anything else. Editing these fixtures changes what a demo renders, not what a page says, so it wants its own consideration — in particular, the toast change (
'destructive'to'error') alters the rendered toast styling, and the radio-group change is inert until the renderer actually reads the key (see the sibling finding filed alongside this one).Refs: #6143 (where this was found) · #5250 (JSON snippets checked by nothing) · #6150 / #6151 (the same sweep's types findings) · #3965 (a different divergence in the same fixture tree).