[finding] A THIRD hand-written FormViewSchema mirror survives in packages/react's spec bridge, and it has drifted on three keys #5596 just measured #5652

Activity

1. os-sales

   added

   finding

   domain:uiobjectui ui stream: fix lands on the published library or apps — objectui execution seatobjectui ui stream: fix lands on the published library or apps — objectui execution seat

   on Aug 22, 2026
2. huangyiirene

   added

   pm:queue

   and removed

   finding

   on Aug 22, 2026
3. huangyiirene commented on Aug 22, 2026

   

   huangyiirene

   on Aug 22, 2026 – with Claude

   Collaborator

   More actions

   Concentration-round first-touch (triage seat): promoted finding → pm:queue, Task S. Ruled between the card's two architectures: repair the three stale keys, keep the documented-subset design — the bridge's declaration is load-bearing documentation (its deliberate non-declarations are a retirement ledger #3901/#3974 depend on), so #5596's blanket derivation is NOT imported here; but the three measured drifts are staleness, not narrowing, and they get the contract's measured answers (columns string arm, dependsOn bare-string arm, visibleWhen object arm) with the bridge's mapping actually consuming each widened arm — declarable-but-dropped would repeat the #5542/#5594 lesson one file over. Dev may propose a lightweight drift guard for this bridge's declared subset (the mirror-catching shape check-spec-symbol-derivation.mjs embodies) as a rider if it stays small; not required.

   ---

   Generated by Claude Code
4. claude

   assigned

   os-zhuang

   on Aug 23, 2026
5. claude commented on Aug 23, 2026

   

   claudeBot

   on Aug 23, 2026 – with Claude

   Contributor

   More actions

   Claiming this card.

   • session id: 01EuPCi56cnGyykygi3z9w4m (os-dev dispatched by the domain:ui PM seat)
   • branch: claude/issue-5652-react-formview-mirror

   Working the triage ruling above: repair the three measured drifts in packages/react/src/spec-bridge/bridges/form-view.ts, keep the documented-subset design and its retirement ledger. Re-measuring each arm against the installed @objectstack/spec before trusting the card's table.

   ---

   Generated by Claude Code
6. claude commented on Aug 23, 2026

   

   claudeBot

   on Aug 23, 2026 – with Claude

   Contributor

   More actions

   {
     "issue": 5652,
     "status": "done",
     "branch": "claude/issue-5652-react-formview-mirror",
     "pr": "https://github.com/objectstack-ai/objectui/pull/5895",
     "premise_still_valid": true,
     "summary": "The third mirror is real and had drifted, so the premise holds — but the card's table was wrong on two of three rows, and I followed the contract. Re-measured with safeParse against the installed @objectstack/spec: (1) FormSection.columns DOES admit the string arm — card correct, widened, and the bridge now folds '3' to 3 because the node's section declares a number and FormSectionContainer indexes its grid-class map by it (that container's own header puts the fold at this seam); (2) FormViewSpec.columns admits NO string arm — FormViewSchema rejects columns:'3' at the form level while FormSectionSchema accepts it at the section level, so the existing `number` was already right and is now bound to the contract with the asymmetry pinned side by side; (3) FormField.dependsOn admits a BARE name and REJECTS the array — the bridge's `string[]` was the exact inverse, admitting only the arm the contract refuses; (4) visibleWhen's object arm requires `dialect` — `{dialect?, source}` is the evaluator's FieldRulePredicate, a different layer's type the contract refuses. DISPATCH/TRIAGE CONFLICT, named rather than silently sided with: the dispatch prompt ordered #5596's blanket derivation; the triage ruling on the card ordered the opposite (keep the documented subset, its non-declarations are a retirement ledger). I shipped the intersection — the hand-listed subset and its ledger are untouched, and only each drift-prone key's TYPE is bound to the spec symbol that owns it. That is also the idiom of the sibling bridge in the same directory (list-view.ts already imports ListView/ListColumn/RowHeight from @objectstack/spec/ui). One bounded in-place fix of the same class, named in the PR: a section's `fields` may be a bare object-field name (the shorthand list-view's mapColumn already honours) and the form bridge ran it through the object mapper, producing `{name: undefined}`.",
     "tests": "Dependency closure first: `pnpm --workspace-concurrency=2 --filter '@object-ui/react^...' build` -> BUILD_EXIT=0 (required, not optional: tsconfig.test.json sets \"paths\": {} so @object-ui/* resolve through built .d.ts). `pnpm vitest run --maxWorkers=2 packages/react/src/spec-bridge` -> 'Test Files 7 passed (7) / Tests 125 passed (125)', VITEST_EXIT=0. `pnpm --filter @object-ui/react type-check` -> script name echoed ('tsc --noEmit && tsc -p tsconfig.test.json'), TYPECHECK_EXIT=0. Exit codes captured before any pipe (redirect-then-capture), never from a tail. GATE UNION re-run AFTER the final commit, at HEAD=ecb98f1e, each quoting its own verdict line: check-changeset-presence EXIT=0 '3 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s)'; check-changeset-no-major EXIT=0 'No changeset declares a `major` bump.'; check-control-bytes EXIT=0 'OK (scanned 4902 tracked text file(s); skipped 85 binary)' plus a manual grep -naP '[control-byte class]' over the four changed files (no match); check-spec-symbol-derivation EXIT=0 '1300 files scanned against 4959 spec export names' + 'spec alignment claims: 2 declared deliberate copies' — green, but see open_question 2: this gate never had jurisdiction over the file; check-phantom-dependencies EXIT=0 'Every in-scope import is declared by the package that publishes it.' LINT: declared narrowing to the owning package (`pnpm --filter @object-ui/react lint`, exit 0) with the three pieces of evidence — population read from eslint's own resolution via --format json (120 files), counts from that JSON (0 errors, 354 warnings; the three changed files hold 0 errors and 20 warnings, ALL @typescript-eslint/no-explicit-any, the file's existing dialect), and invariance: eslint.config.js declares no parserOptions.project/projectService, so type-aware linting is off and this diff cannot move an untouched file's verdict. REVERSE VERIFICATION, 5 legs, each direction predicted before it ran, and every leg matched: A FormSectionSpec.columns->number: predicted type-check RED / vitest GREEN, observed TYPECHECK_EXIT=2 with 4 errors (TS2322 on the '3' fixtures, TS2344 on both pins) and vitest 125 passed. B columns fold removed from the mapping: predicted vitest RED / type-check GREEN, observed VITEST_EXIT=1 ('folds a string SECTION column count onto the number the node carries') with TYPECHECK_EXIT=0. C dependsOn->string[]: predicted type-check RED, observed TYPECHECK_EXIT=2, 5 errors. D visibleWhen->string (field AND section): predicted type-check RED, observed TYPECHECK_EXIT=2, 7 errors. E shorthand un-consumed: predicted BOTH red, observed VITEST_EXIT=1 and TYPECHECK_EXIT=2 (TS2345, mapField refuses string). NON-DISCRIMINATING LEGS, named: vitest stays green through A/C/D because those narrowings are type-only and erased at runtime — only tsc -p tsconfig.test.json sees them; type-check stays green through B because the node builder is Record<string, any>, so only the value assertion catches a dropped fold; the safeParse contract controls discriminate on no leg by construction (they pin the contract, not the bridge). MUTATION CONFIRMED ON DISK, never from an editor exit code: each leg grepped BOTH the removed text (expect 0 occurrences) and the injected text (expect the exact count) — printed as 'ON_DISK removed_text_still_present=0 injected_text_present=N' — and a leg that failed that check would have declared itself unrun. REBUILD: none applies per leg and that is a property of the resolution path, not a skipped step — vitest reaches the mutated file through a relative import and reaches @object-ui/core through a source alias, and tsc compiles the package's own sources directly; only the DEPENDENCY closure is consumed as dist, and it was built once up front (BUILD_EXIT=0) and never mutated. Restoration is a trap (trap '...' EXIT INT TERM) so a foreground-cap SIGTERM mid-mutation cannot poison later measurements; every leg ended RESTORE_DIFF_STAT=[] and the run ended FINAL_DIFF_STAT=[] with a clean worktree. All heavy legs ran through scripts/pm/os-verify-lock.sh (VERDICT lines: command-exit 0 · held 32s/24s/74s).",
     "open_questions": [
       {
         "question": "The dispatch prompt and the card's triage ruling gave opposite instructions on the SHAPE of the conversion (blanket #5596-style derivation vs. keep the documented subset). I shipped the intersection; naming it so the PM can overrule rather than discovering it in review.",
         "options": [
           "A — what shipped: keep the hand-listed subset and its retirement ledger verbatim, bind only each drift-prone key's TYPE to the spec symbol that owns it (also the sibling list-view.ts idiom, same directory).",
           "B — the dispatch's literal reading: Omit<FormView, ...> & { ...narrowings }, matching app-shell's form-spec.ts exactly. Erases the #3901/#3974 retirement ledger's meaning, since every unlisted key returns by derivation.",
           "C — the triage's literal reading: fix the three key types by hand, no spec import at all. Leaves the mirror hand-written, so it drifts again and the derivation pin cannot exist."
         ],
         "recommendation": "A. It is the only option that satisfies both rulings' stated REASONS: the ledger survives (triage's requirement) and no declared type is a restatement (the dispatch's requirement, and the reason the drift happened). B would silently re-declare defaultSort/aria — the exact keys #3901/#3974 retired — and C keeps the defect class alive."
       },
       {
         "question": "Deriving surfaced spec keys the bridge neither maps nor explains, contrary to its own #2545 docstring. Per the dispatch I did NOT quietly add them to an ignore list or map them: FormView.buttons and FormView.defaults; FormSection.pane and FormSection.visibleOn; and 14 FormFieldInput keys (publicPicker, maxLength, minLength, min, max, precision, scale, multiple, immutable, span, language, keyField, disclosure, fields). What each would mean is measurable and mostly bad: `pane` is read at ObjectForm.tsx:302 and is the whole subject of SplitForm, so a spec-authored split form loses explicit placement and falls back to the positional rule; 13 of the 14 field keys are copied onto the runtime field by normalizeSectionField, so authored maxLength/precision/composite `fields` never arrive. Filed as #5898 rather than fixed.",
         "options": [
           "A — triage #5898 as a card: pin the conformance fixture against the contract's own keyof (so a new spec key fails the suite until mapped or explained), then close the gap key by key.",
           "B — fix only the demonstrably-consumed subset now (pane + the 13 field keys) and leave buttons/defaults/publicPicker to enforce-or-remove.",
           "C — leave it: the bridge is a documented subset and the promise wording is what should change."
         ],
         "recommendation": "A, but as its own card — the guard has to exist before the gap is closed, or the next key drops silently the same way. C is the one option I would argue against: the promise is enforced by a test, so weakening the wording weakens a live check."
       },
       {
         "question": "The contract admits an ast-only visibility predicate ({dialect:'cel', ast:{...}} parses; {dialect:'cel'} alone is rejected, so `ast` is a real alternative to `source`), but @object-ui/core's toExpression reads only {dialect, source} and drops `ast`. The bridge now forwards the object arm whole rather than dropping it, so such a predicate reaches the node intact and then fails open at the evaluator with a warning.",
         "options": [
           "A — leave as shipped: the bridge transports, the evaluator's gap stays visible (it warns), and nothing is silently dropped.",
           "B — have the bridge reject/strip an ast-only predicate so the failure is at the seam that can name it.",
           "C — teach evalFieldPredicate to evaluate an authored ast (a formula-engine question, not a bridge one)."
         ],
         "recommendation": "A for this card. B would make the bridge drop spec configuration — the one thing its docstring forbids — and C is a real capability decision for the evaluator's owner. Worth a finding if triage wants it tracked; I did not file one because it is a design gap rather than a measured user-reachable failure."
       },
       {
         "question": "FormField.dependsOn is declared DependsOnInput (@object-ui/types), which is WIDER than the contract (the contract admits a bare name only; DependsOnInput also admits the array and {field, param} arms the runtime reader has always accepted). The pin asserts coverage (contract arm ⊆ declaration), not equality.",
         "options": [
           "A — what shipped: declare the destination slot's own type; the value is forwarded unread into a node slot declared exactly DependsOnInput and read by resolveDependsOnFields, whose parameter is exactly DependsOnInput.",
           "B — declare the contract's `string` exactly. Equality pin becomes possible, but array-authored layouts that work today start type-erroring at the bridge."
         ],
         "recommendation": "A. B is a capability removal disguised as strictness: the bridge also consumes never-parsed documents (the documented reason `groups` and field `visibleOn` are still read), and the runtime has honoured arrays since framework#4074. The coverage pin still fails if the spec widens dependsOn, which is the drift this card is about."
       }
     ],
     "out_of_scope_findings": [
       "filed as #5898: finding(react) — the form-view bridge's #2545 \"never silently drop spec configuration\" promise is false; 18 spec keys are neither mapped nor explained, and pane + 13 field keys are demonstrably read by the layer downstream",
       "filed as #5899: finding(tooling) — check-spec-symbol-derivation.mjs skips every non-exported declaration (hasExportModifier guard at lines 827 and 923), so the three mirrors this card cited it to catch were invisible to both rules; two of them were declared under the spec's own export names and the gate stayed green"
     ]
   }

   ---

   Generated by Claude Code
7. claude commented on Aug 23, 2026

   

   claudeBot

   on Aug 23, 2026 – with Claude

   Contributor

   More actions

   PM rulings — all four open questions

   1. The shape conflict (dispatch vs. the card's triage ruling) — A, the intersection, as shipped

   My dispatch was the half that was wrong. It ordered #5596's blanket derivation without knowing that this file's non-declarations are a retirement ledger #3901/#3974 depends on. B would have silently re-declared defaultSort and aria — the exact keys those cards retired — which is not a stricter bridge, it is a resurrection. C keeps the mirror hand-written and the defect class alive.

   The intersection satisfies both rulings' reasons rather than splitting the difference between their words: the ledger survives verbatim, and no drift-prone type is a restatement. That it is also the idiom of list-view.ts in the same directory settles it — this is the house style, not an invention.

   Detecting the conflict and naming it instead of quietly siding with the prompt is exactly right. A dispatch is an instruction, not evidence.

   2. #5898 (18 spec keys neither mapped nor explained) — A, and it is its own card

   The guard has to exist before the gap is closed, or the next spec key drops the same silent way. Pin the conformance fixture against the contract's own keyof so a new key fails the suite until it is mapped or explained, then close key by key.

   C is wrong and worth saying so explicitly: the #2545 promise is enforced by a live test, so weakening the wording weakens a check. When prose and behaviour disagree, the answer is never to edit the prose down to what the code happens to do.

   ⛔ This seat is not queueing #5898 — it awaits triage first-touch like every other unlabelled finding. But triage should know it is not hygiene: pane is read at ObjectForm.tsx:302 and is the whole subject of SplitForm, and 13 of the 14 field keys are copied onto the runtime field by normalizeSectionField. So authored maxLength / precision / composite fields are being dropped today, on documents the bridge was built to carry.

   3. The ast-only visibility predicate — A, leave as shipped

   B would have the bridge drop spec configuration, which is the one thing its own docstring forbids; fixing a mirror by teaching it to discard is the wrong direction. C is a real capability decision belonging to the evaluator's owner, not to a bridge card.

   What makes A acceptable is narrow and worth stating: the predicate reaches the node intact and the evaluator fails open with a warning. A silent drop and a warned fail-open are not the same class of outcome. Not filing a finding for a design gap with no measured user-reachable failure was the right call.

   4. dependsOn declared as DependsOnInput, coverage pin rather than equality — A

   B is a capability removal disguised as strictness. The runtime has honoured the array arm since framework#4074, the bridge also consumes never-parsed documents (the documented reason groups and field visibleOn are still read), and the value is forwarded unread into a slot declared exactly DependsOnInput and consumed by resolveDependsOnFields, whose parameter is exactly that type. Declaring the destination slot's own type is the honest declaration.

   The coverage pin (contract arm ⊆ declaration) still fails if the spec widens dependsOn, which is the drift this card exists to stop. That is the property that had to survive, and it did.

   The card was wrong on two of three rows, and following the contract instead of the card is the headline

   • FormViewSpec.columns admits no string arm — FormViewSchema rejects columns: '3' at the FORM level while FormSectionSchema accepts it at the SECTION level. The existing number was already right. Had the card been trusted, this PR would have widened a declaration the contract refuses.
   • FormField.dependsOn admits a bare name and rejects the array — the bridge's string[] was the exact inverse: it admitted only the arm the contract refuses.

   Both are the failure mode a dispatch brief cannot protect against, and the reason the brief said to re-measure every arm rather than trust the table.

   The five ablations are the right shape too — each direction predicted before it ran, and the type-only legs (A/C/D) correctly reported vitest green, since those narrowings erase at runtime and only tsc -p tsconfig.test.json can see them. A convergence like this one would be invisible to a suite-only reverse verification.

   #5899 is the most consequential thing in this report

   check-spec-symbol-derivation.mjs skips every non-exported declaration (the hasExportModifier guard), so the gate this card cited to catch hand-written mirrors was blind to all three of them — and two were declared under the spec's own export names while it stayed green. That is a gate reporting coverage it does not have, which is worse than no gate: this lane has been treating its green as evidence. Correctly filed unqueued; flagging it here so triage sees the size of it.

   PR #5895 lands at its gate window.

   ---

   Generated by Claude Code

   ---

   Generated by Claude Code
8. os-zhuang

   closed this as completedin #5895on Aug 23, 2026