finding(react): a spec-bridge form field skips the normalizer's object-schema merge — it arrives with the raw spec (text), never the resolved widget id (field:text)

Found while implementing #5898 (the form-view bridge's dropped spec keys). Filed unassigned as
an observation, for PM triage — #5898's fence was the DROPPED keys, and this is about a key that
arrives, so it is deliberately not folded into it.

The two routes to a runtime `FormField` disagree on `type`

normalizeSectionField (packages/plugin-form/src/sectionFields.ts) is the documented chokepoint
between the spec's authored form-field vocabulary and the runtime one. It branches on the identity
key:

// (3) already a runtime FormField (inline customFields): it carries its own `name`.
// NOTE: in the spec shape `field` is a *string* (the field name); in a runtime
// FormField `field` is the *metadata object*. So a string `field` is the
// disambiguator for the spec shape below.
if (typeof fd.field !== 'string') {
  return attachVisibility(fd as FormField, fd.visibleOn);
}

The spec-bridge's mapField (packages/react/src/spec-bridge/bridges/form-view.ts) maps the spec's
field onto the runtime name and emits no field key at all. So a bridged section field takes
branch (3) — "already a runtime FormField" — and is returned unchanged.

Branch (2), which an authored spec field takes when it reaches the normalizer directly, does five
things branch (3) does not:

resolves the widget id — base.type = mapFieldTypeToFormType(rawType, { multiple })
merges the object-schema base (fromObjectSchema): label i18n, validation (buildValidationRules),
disabled, the field metadata stash widgets read precision / reference_to off
re-runs the create-mode required test against the object field's defaultValue (A required field whose defaultValue is a runtime token (NOW() / current_user) cannot be submitted from a create form #4069)
stamps both lookup spellings (reference / reference_to)
folds the object-level visibleWhen / readonlyWhen / requiredWhen rules onto the runtime field

The measurable half

mapFieldTypeToFormType('text') returns 'field:text' (packages/fields/src/field-type-alias.ts:110).
The bridge forwards the spec type verbatim, so a bridged field reaches the renderer carrying
type: 'text' while the same authored field normalised directly carries type: 'field:text'. The
same asymmetry holds for every entry in that map (number → field:number, datetime →
field:datetime, …), and for the (type, multiple) pair rule objectui#3986 added — a bridged
select + multiple: true cannot land on the multi-value picker, because nothing re-decides the
widget on that route.

Pinned incidentally by the conformance suite in #5898's PR: its carries spec 'type' to its destination row asserts field.type === 'text' on the bridged node, i.e. the raw spec spelling.
That row is correct about the BRIDGE; this card is about whether the value is correct for the
RENDERER one layer on.

Why it is a finding and not a queued card

Two things need a decision above the mechanical part, and neither is mine to make:

Which layer owns the translation. Either the bridge emits fully runtime-shaped fields (and
must therefore do the mapFieldTypeToFormType fold and the object-schema merge itself — but it
has no object schema in hand, only BridgeContext), or it emits spec-shaped fields and lets the
normalizer's branch (2) do the work (which would mean keeping the spec field key rather than
renaming it to name, and that is the 表单字段簇:spec↔runtime 是双层词汇——枢纽补缺、覆盖闸门、边界响亮化(objectstack#4115) #3090 mixed-vocabulary hazard the normalizer warns about
by name). Both are coherent; they are different architectures.
Whether the bridged route is reached in production at all. SpecBridge is exported for
hosts; I did not find an in-repo caller that feeds its object-form node into ObjectForm with a
live object schema, so the blast radius is unmeasured. If the answer is "no host does this", the
honest outcome may be ADR-0049 enforce-or-remove on the route rather than a fix.

Boundary

Searched the open issues before filing (REST list endpoint, all 244 open, filtered locally):
mapFieldTypeToFormType / field-type / field: / normalizeSectionField / spec-bridge /
bridge / runtime FormField / form-view, plus a broad form|type|widget title sweep. Nothing
open covers it. finding: metadata-admin/previews/object-fields-bridge.ts has zero importers, and its serializeDesignerField would destroy every key the designer does not model #6309 is the nearest neighbour by shape (a different bridge whose serializer
would destroy keys) and is unrelated in mechanism. [finding] object-master-detail-form declares formType as a bare string while the renderer switches on the object-form variant enum — an out-of-vocabulary value silently routes around the whole simple-form path #5939 and finding(types): three more type names are declared twice with disagreeing shapes — FormField, MarkdownSchema, KanbanSchema — and one doc asserts FormField is declared once #6172 touch the form-field/formType
vocabulary but from the types side, not this translation.
Not covered by finding(react): the form-view bridge's #2545 "never silently drop spec configuration" promise is false — 18 spec keys are neither mapped nor explained #5898's repair, and deliberately so: every key finding(react): the form-view bridge's #2545 "never silently drop spec configuration" promise is false — 18 spec keys are neither mapped nor explained #5898 restored is copied
same-name, so it lands wherever branch (3) leaves it — the same place colSpan, widget and
required already landed. This card is about the ROUTE, not about any one key.

Generated by Claude Code

Dispatch — domain:ui execution seat @ objectui, round 32.

Claim: session session_011SfZeFWrhGLHmfq61xbz4q, branch claude/issue-6366-spec-bridge-form-field-route. Assigned by the PM.

1. This is a STAGED, MEASURE-FIRST card. A report with no code is a success here.

The card's own body argues it should not be queued, and it was right to — but triage answered it, so read the ruling, not the body's stop sign. Quoted:

Stage 1 is the card's own question 2: establish whether any host actually feeds SpecBridge's object-form node into ObjectForm with a live object schema — grep in-repo consumers and the published examples. If the route is unreached, stop and report: the honest outcome is an enforce-or-remove proposal on a published export, which comes back through the decision box rather than riding this card. Only if the route is live does stage 2 open — and there the architecture fork (bridge emits runtime-shaped fields vs spec-shaped fields through branch 2) is a design decision the dev reports with a recommendation, not implements unilaterally; the #3090 mixed-vocabulary hazard the normalizer warns about is the constraint either answer must clear.

Three things follow, all binding:

⛔ Do not implement stage 2 unless stage 1 says the route is live.
⛔ Even then, do not pick the architecture. Report the fork with a recommendation. Both branches are coherent; choosing between them is not this dispatch's authority.
An enforce-or-remove proposal is a legitimate deliverable. It does not ride this card — it goes back through the decision box.

2. My stage-1 first reading — verify it, your reading wins

I ran the cheap half so you start from a measurement rather than a blank page. This is my reading, not a finding; treat it as a hypothesis to confirm or overturn.

Every in-repo reference to SpecBridge is a test file, the module itself (spec-bridge/SpecBridge.ts), its barrel (spec-bridge/index.ts), a tsconfig.test.json, or a CHANGELOG. I found no production consumer. Full list: three plugin-grid test files, six react/spec-bridge/__tests__ files, bridges/list-view.ts, packages/types' base-schema-label-vocabulary test, plus the module, barrel, tsconfig and changelog.

Separately, object-form does appear in apps/console, apps/site and examples/ — but those look like object-form nodes handed to the renderer directly, which is not the bridged route. Confirming or refuting that distinction is the actual work of stage 1: the question is not "does object-form appear" but "does anything route it through SpecBridge and into ObjectForm with a live object schema".

⚠️ The published-export caveat is the part that makes this non-obvious. SpecBridge is exported for external hosts. "No in-repo caller" does not equal "no host does this", and the card says so itself. So a truthful stage-1 answer distinguishes unreached in this repo from unreachable, and an enforce-or-remove proposal on a published export has to be argued on the published surface, not on in-repo greps alone. ⛔ Do not report "unreached" flatly if what you measured is "no in-repo caller".

3. If stage 1 says the route IS live

Then the measurable half is already stated and should be pinned before anything is designed: mapFieldTypeToFormType('text') returns 'field:text', while a bridged field arrives carrying type: 'text'. The same asymmetry holds for every entry in that map, and for the (type, multiple) pair rule from objectui#3986 — a bridged select with multiple: true cannot reach the multi-value picker, because nothing re-decides the widget on that route.

Note the trap the card names: #5898's conformance suite has a carries spec 'type' to its destination row asserting field.type === 'text' on the bridged node. That row is correct about the bridge and is not a bug to fix; this card is about whether that value is right for the renderer one layer on. Do not "fix" that assertion.

4. Scope

packages/react/src/spec-bridge/bridges/form-view.ts and packages/plugin-form/src/sectionFields.ts are the two named files; both confirmed present on main. ⛔ Nothing in #5898's restored keys — every one of those is copied same-name and this card is about the ROUTE, not any single key.

Shadow check run before this order: no in-flight card in this lane touches packages/react or packages/plugin-form.

5. Reporting

Whatever stage 1 returns, say what you measured and what you did not. "No in-repo caller, published export so external reachability unmeasured" is a complete and useful answer. Several devs on this lane today have returned measurements that overturned a card's framing, and those were worth more than the code in the same PR.

Generated by Claude Code

os-dev-report

{
  "issue": 6366,
  "status": "needs_decision",
  "branch": "claude/issue-6366-spec-bridge-form-field-route (never created — stage 1 stopped before any worktree, edit or push)",
  "pr": null,
  "premise_still_valid": true,
  "summary": "Stage 1 only; no code, no branch, no push, per the triage ruling. The card's MECHANICAL premise is verified true on origin/main (51f9c5bed): `mapField` still emits `name` with no `field` key and forwards the spec `type` verbatim, never calling `mapFieldTypeToFormType`, so a bridged field takes branch (3) and keeps `text` where `field:text` is what the renderer's own normalizer produces. The card's REACHABILITY question resolves against the route: zero non-test consumers of `SpecBridge` / `bridgeFormView` / `transformFormView` / dynamic `.transform('form', …)` in objectui across all file types and on origin/main, none in the sibling objectstack repo (which does not depend on @object-ui/react at all), and a GitHub-wide public code search for the two exported entry names returns 3 hits, all inside objectstack-ai/objectui itself. I found something stronger than 'no in-repo caller', and it changes the framing: the bridged node is STRUCTURALLY INCOMPLETE for this route. `ObjectForm` resolves a live object schema only from `schema.objectName` (ObjectForm.tsx:501 and the 'cannot proceed' branch at :519-525; TabbedForm.tsx:232 for the sectioned variants), `objectName` is documented Required on ObjectFormSchema and is NOT in the spec-aligned key set, and the spec FormView's own object identity (`data.object`, present in #5898's own conformance fixture) is read by nothing in plugin-form — `bridgeFormView` neither reads nor emits `objectName`. So a bridged node handed to the renderer verbatim renders, in the registry wrapper's own words, 'a field-less card in silence' (plugin-form/src/index.tsx, citing objectui#5378 item 2, which adds: 'A form with no objectName is a different defect and is left to report itself'). The only working host recipe, `{...node, objectName: 'contact'} as any`, exists in-repo exclusively in the LIST bridge's integration tests and is documented nowhere. That asymmetry is the sharpest measurement here and explains why this survived: the list bridge has three tests that render bridged nodes through the real renderer, the form bridge has ZERO — every one of its tests stops at the node object, and plugin-form imports SpecBridge nowhere. What I did NOT measure, and cannot from here: private/closed-source hosts and npm-only consumers of @object-ui/react@17.x; GitHub code search indexes public repos only. 'Unreached everywhere I can see' is not 'unreachable'. I filed no out-of-scope issues on purpose — the two candidates (the unread `node.data` copy, and the objectName gap itself) are evidence INSIDE this card's own decision, not independent defects, and filing them separately would fragment one decision; say the word if you want them as cards. I did not touch #5898's `carries spec 'type' to its destination` row.",
  "tests": "No suite run and none owed: no code was produced, and the shared read-only checkout has no node_modules (stage 1 stopped before any worktree/install). Every claim is a static measurement, each re-verified against origin/main 51f9c5bed after I caught that the shared checkout HEAD (ba306e3eb) was stale by 148 lines on the very file in scope — #5898 landed in between, so my first read of form-view.ts was of a superseded tree. Commands and evidence: (1) `grep -rIl SpecBridge .` over ALL file types minus node_modules/dist/.git = 50 files; every hit outside tests, the module, its barrel, tsconfig, CHANGELOGs and docs was a .turbo/cache manifest. (2) `git grep -l 'SpecBridge|bridgeFormView|transformFormView' origin/main -- '*.ts' '*.tsx' '*.mts'` minus tests/spec-bridge = EMPTY. (3) `grep -rn '\\.transform('` — only SpecBridge's own two methods and its tests, so the dynamic route adds no consumer. (4) `git show origin/main:.../form-view.ts` — mapField emits `name`/`label`, forwards `type` if present, and grep for `objectName|mapFieldTypeToFormType|mapped.field` in that file returns nothing. (5) `git show origin/main:packages/fields/src/field-type-alias.ts` — `text: 'field:text'` confirmed in the typeMap. (6) sectionFields.ts: `git diff --stat ba306e3eb origin/main` empty, so the normalizer I read is current. (7) objectstack repo: only a CHANGELOG and an audit doc mention SpecBridge; no package.json depends on @object-ui/react. (8) GitHub code search, all public repos: `transformFormView OR bridgeFormView` = 3 items, all objectstack-ai/objectui. One post-#5898 refinement to the card's measurable half: the bridge now ALSO forwards `multiple`, so both halves of the objectui#3986 (type, multiple) pair now reach the node and still nothing re-decides the widget.",
  "open_questions": [
    {
      "question": "ADR-0049 enforce-or-remove on the bridged form route — a published export of @object-ui/react@17.6.0 (the barrel re-exports the whole spec-bridge at src/index.ts:14, so `SpecBridge`, `bridgeFormView` and `bridgeListView` are all public API). This is the decision the triage ruling said comes back through the decision box rather than riding this card, and it is the maintainer's because it reverses a published promise.",
      "options": [
        "A — REMOVE. Drop `bridgeFormView` + `SpecBridge#transformFormView` as a BREAKING major, exactly as @object-ui/react@17.0.0 already did for `bridgePage`/`bridgeDashboard` on the criteria 'had no runtime consumer' + 'could not receive a spec-valid dashboard even in principle'. Cost: that same changelog entry states 'The list and form bridges are unaffected and remain the live authoring path' — removal reverses a stated commitment, on a surface whose external use is unmeasurable. Benefit: deletes an unreached translation layer and with it this card, the conformance suite that pins a route nothing travels, and #5898's ongoing maintenance surface.",
        "B — ENFORCE. Keep it and make the route real: fix the type translation AND close the objectName gap AND add the missing render-integration pin in plugin-form mirroring the three the list bridge has. Cost: the object-identity half needs a spec-level answer (spec FormView has no object key — that is an objectstack decision, not objectui's), and it builds machinery on a route with zero measured consumers.",
        "C — KEEP AS-IS, DOCUMENT THE BOUNDARY. Declare the bridge a spec-shaped translator, document that the host supplies `objectName` and that the normalizer's branch (2) owns the vocabulary — which requires the bridge to STOP renaming `field` to `name` so branch (2) is actually taken. This is the fork's second horn; it must clear #3090's mixed-vocabulary hazard and it breaks #5898's pin asserting `sections[0].fields[0].name === 'name'`."
      ],
      "recommendation": "A, with C as the fallback if the maintainer wants the export kept — and explicitly NOT 'quietly fix the type mapping in place', which is the one option all four axes reject. Real business need: zero measured demand at every end I can reach (no in-repo caller, no public caller, no documented recipe), and the route cannot work at all without an undocumented host-side fixup — 'looks useful' is exactly what this axis refuses. Long-term soundness: two producers of runtime FormFields that disagree is the defect; contract-first wants one seam, and PR #4603 already ruled on this same bridge's same incapacity (it has no locale, as it now has no object schema) by moving resolution to READ time rather than into the bridge — precedent points at the normalizer owning the translation, i.e. away from B. AI-authored metadata: this is the sharpest axis and it is why 'do nothing' is not neutral — `type: 'text'` does not throw, it lands silently on an unresolved widget id, and the registry wrapper already documents the sibling silent failure ('a field-less card in silence'); removal deletes a silent-failure path, C makes the seam explicit, and only the status quo preserves quiet wrongness. Startup scope: no pull, so implementation-first applies and a published-but-unconsumed capability gets no exemption for sunk cost.",
      "note": "If A or C is chosen, decide it for SpecBridge as a WHOLE, not just the form half: the list bridge measures the same way (no production consumer, also emits no objectName, also needs the `as any` staple its own tests use). Deciding only the form half guarantees this card returns wearing a list-bridge hat."
    },
    {
      "question": "If the route is kept (B or C), one measured fact narrows the fork and is worth having on the record before anyone designs: does the widget-id repair actually need a live object schema?",
      "options": [
        "It does not. In branch (2) `rawType = fd.type ?? ctx.objectSchema?.fields?.[name]?.type`, then `base.type = mapFieldTypeToFormType(rawType, { multiple: base.multiple })` — with a NULL objectSchema the spec's own `type` still drives the mapping and every spec override (widget/label/placeholder/helpText/colSpan/options/required) is still layered on.",
        "Only the MERGE half (validation, precision, reference_to, i18n label, defaultValue-aware required, object-level visibleWhen/readonlyWhen/requiredWhen) needs the object schema."
      ],
      "recommendation": "Both are true and they separate cleanly, which is the useful part: routing bridged fields through branch (2) fixes the widget-id asymmetry the card measures EVEN on a host that never supplies an object schema, while the object-schema merge stays correctly inert until one is supplied. So the architecture fork does not have to be settled together with the objectName question — but neither should be settled by me, and neither is settled here."
    }
  ],
  "out_of_scope_findings": []
}

Generated by Claude Code

Stage 1 complete — no code, no branch, no push, exactly as the triage ruling required. Moving to the decision box.

PM verification of the dev's stage-1 report, re-measured independently on origin/main.

The mechanical premise holds

bridgeFormView still forwards the spec type verbatim and never calls mapFieldTypeToFormType — 0 occurrences in a live 480-line file. So a bridged field keeps text where the normalizer's branch (2) would produce field:text. One post-#5898 refinement from the dev: the bridge now also forwards multiple, so both halves of the objectui#3986 (type, multiple) pair reach the node and still nothing re-decides the widget.

But stage 1 found something stronger, and it reframes the card

The question was "is the route reached?" The answer is that the route cannot work at all, and that is a different finding.

bridgeFormView emits 0 objectName and 0 customFields — verified against the same live file, alongside the positive control that it does emit sections[].fields[] (:366) and type: 'object-form' (:442).
ObjectForm resolves a live object schema only from schema.objectName, via dataSource.getObjectSchema(schema.objectName).
The one escape hatch is hasInlineFields, and it gates on customFields specifically — schema.customFields && schema.customFields.length > 0. Bridged sections[].fields[] do not satisfy it.
So a bridged node takes the branch the code itself labels "No objectName or dataSource and no inline fields — cannot proceed", and the registry wrapper describes the result in its own words: "renders a field-less card in silence (objectui#5378 item 2)" — a comment that ends "A form with no objectName is a different defect and is left to report itself."

So the type-vocabulary defect this card was filed about is downstream of a route that cannot deliver fields in the first place. Fixing the widget id would make a field-less card carry correct widget ids.

Reachability, and the honest limit on it

Zero non-test consumers of SpecBridge / bridgeFormView / transformFormView / dynamic .transform('form', …) anywhere in objectui, on origin/main, across all file types. None in objectstack, which does not depend on @object-ui/react at all. A GitHub-wide public code search for the two exported entry names returns 3 hits, all inside this repository.

⚠️ "Unreached everywhere I can see" is not "unreachable", and the dev said so rather than rounding up: private and npm-only consumers of @object-ui/react@17.x are not measurable from here, and GitHub code search indexes public repos only. That distinction is what makes this a decision rather than a cleanup.

⭐ The sharpest supporting measurement: the list bridge has three tests that render bridged nodes through the real renderer; the form bridge has zero — every one of its tests stops at the node object, and plugin-form imports SpecBridge nowhere. The only working host recipe, {...node, objectName: 'contact'} as any, exists in-repo only inside the list bridge's integration tests and is documented nowhere. That asymmetry is why this survived unnoticed.

⭐ Process note worth recording: the dev caught that the shared checkout's HEAD was stale by 148 lines on the very file in scope — #5898 landed in between — and re-verified every claim against origin/main. A first read of that file would have described a superseded tree.

Why this goes to the maintainer rather than back to the queue

Both live options touch the human floor: option A is a breaking removal of a published capability (SpecBridge, bridgeFormView and bridgeListView are all public API — the barrel re-exports the whole spec-bridge), and the whole question is an ADR-0049 enforce-or-remove call. Neither is a seat's to make. This is precisely the outcome the triage ruling anticipated.

⭐ And the dev's closing constraint is right: decide it for SpecBridge as a whole, not just the form half. The list bridge measures the same way — no production consumer, also emits no objectName, also needs the as any staple its own tests use. Deciding only the form half guarantees this card returns wearing a list-bridge hat.

四维分析

① 实际业务需求

需求信号为零，且是在每一个够得到的端点上测的：仓内无非测试调用方；姊妹仓 objectstack 根本不依赖 @object-ui/react；GitHub 全公开仓代码搜索只有 3 个命中，全在本仓内。更关键的是这条路今天就走不通 —— bridged 节点既无 objectName 也无 customFields，落进代码自己标注的 "cannot proceed" 分支，渲染出注册表包装器所说的「a field-less card in silence」。唯一能让它工作的配方 {...node, objectName: 'contact'} as any 只存在于 list bridge 的集成测试里，任何文档都没写过。

⚠️ 但不可测 ≠ 不存在：私有仓与只从 npm 消费 @object-ui/react@17.x 的宿主，从这个座位测不到。这正是它必须由人裁而非由席位清理掉的原因。

② 平台长远合理性

两个 runtime FormField 生产者互相不一致，这本身就是缺陷；contract-first 要的是一条缝，不是两条。已有先例指向「normalizer 拥有翻译」而非「bridge 拥有翻译」：PR #4603 处理这同一个 bridge 的同类无能（它没有 locale，正如它现在没有 object schema）时，把解析移到读取时，而不是塞进 bridge。

⚠️ 反向成本要照实说：@object-ui/react@17.0.0 移除 bridgePage/bridgeDashboard 时，同一条 changelog 明写「The list and form bridges are unaffected and remain the live authoring path」。选 A 就是反转一条已公开声明的承诺，而且是在一个外部使用量无法测量的面上。这是 A 的真实代价，不是脚注。

③ 避免 AI 写代码犯错

这一维最尖锐，也是「维持现状」不中立的原因：type: 'text' 不抛错，它安静地落在一个未解析的 widget id 上；而同一个包的注册表包装器已经把姊妹静默失败写进注释（"a field-less card in silence"）。AI 产出的 metadata 走这条路，得到的是无声的错，不是可诊断的红。

A（移除）删掉一条静默失败路径；
C（记录边界）把缝显式化；
只有维持现状保留了「安静地错」。

⛔ 而「就地悄悄把 type 映射修了」是四个轴一致否决的那个选项 —— 它让一张 field-less 的卡片带上正确的 widget id。

④ 创业阶段不扩散需求

零拉力，所以 implementation-first 适用：一个已发布但无人消费的能力，不因沉没成本获得豁免。B（enforce）要建的机器还依赖一个规格层的答案 —— spec 的 FormView 没有 object 身份键（data.object 在 #5898 自己的 conformance fixture 里存在，但 plugin-form 里没有任何东西读它），那是 objectstack 的决定，不是 objectui 的。为一条零测得消费者的路，跨仓开一个规格问题，是典型的需求扩散。

待裁选项

A — 移除（dev 推荐）。按 @object-ui/react@17.0.0 移除 bridgePage/bridgeDashboard 的同一判据（「had no runtime consumer」+「could not receive a spec-valid dashboard even in principle」），以 breaking major 移除 bridgeFormView + SpecBridge#transformFormView。代价：反转上述 changelog 的明文承诺。

B — 兑现。修类型翻译且补 objectName 缺口且补上 plugin-form 缺失的渲染集成 pin（对齐 list bridge 已有的三个）。代价：object 身份那一半需要跨仓的规格答案。

C — 保留并写明边界（dev 的备选）。声明 bridge 是 spec 形状的翻译器，宿主负责提供 objectName，词表归 normalizer 的 branch (2) —— 这要求 bridge 停止把 field 改名为 name，否则 branch (2) 根本不会被走到。必须过 #3090 混合词表关，且会打破 #5898 那条断言 sections[0].fields[0].name === 'name' 的 pin。

⭐ 一条与选项无关的实测事实，先记在案：widget-id 的修复不需要活的 object schema。branch (2) 里 rawType = fd.type ?? ctx.objectSchema?.fields?.[name]?.type，object schema 为 null 时 spec 自己的 type 仍然驱动映射，spec 的各项覆盖也照样叠加；只有 merge 那一半（validation、precision、reference_to、i18n label、defaultValue 感知的 required、对象级 visibleWhen/readonlyWhen/requiredWhen）才需要它。所以架构分叉不必和 objectName 问题一起裁 —— 但两者都不由本席裁，此处也都未裁。

⛔ 无论选哪个，请对整个 SpecBridge 裁，不要只裁 form 那一半。

Generated by Claude Code

Maintainer ruling recorded — Option A: remove, and for SpecBridge as a WHOLE

Provenance: maintainer, 2026-08-27, PM chat decision-inbox batch 4 (adjudication session session_01DKWDdUJ2XNRESVVWUvcpnh), verbatim: 「其他接受」 — accepting the stage-1 recommendation A (2026-08-26T12:25Z facet block), with the dev's whole-bridge constraint adopted: the ruling covers SpecBridge, bridgeFormView AND bridgeListView — ⛔ not just the form half (deciding one half guarantees the card returns wearing a list-bridge hat; the list bridge measures the same way).

Basis, from the stage-1 measurement: zero consumers at every reachable endpoint (in-repo, sibling repo, GitHub-wide public search); the bridged route is structurally unable to work (no objectName, no customFields — the "cannot proceed" branch renders "a field-less card in silence"); the only working recipe exists solely inside the list bridge's own tests and is documented nowhere. The priced cost is accepted: this reverses the @object-ui/react@17.0.0 changelog line ("The list and form bridges are unaffected and remain the live authoring path"), on the same criteria that changelog itself used to remove bridgePage/bridgeDashboard.

Dispatch constraints:

Removal follows the retirement discipline: the changelog entry names the ruling and the measurement; the conformance suites pinning the removed route go with it; finding(react): the form-view bridge's #2545 "never silently drop spec configuration" promise is false — 18 spec keys are neither mapped nor explained #5898's restored-key work on the form bridge is superseded, not "fixed".
This is breaking-major class on a published package. ⚠️ The repo's changeset gate refuses major — if the gate blocks the honest declaration, ⛔ do not mislabel it minor: stop and report for release coordination (a major rides a coordinated version bump, which is the maintainer's release act).
Confidence-gap tripwire: external npm-private hosts are unmeasurable — if any evidence of an external consumer surfaces during implementation, stop and report; the fallback ruling is C (keep + document the boundary), recorded here so the flip needs no new analysis.

State: needs-user-decision → pm:queue.

Generated by Claude Code

New evidence for the open decision above — recording it because it bears directly on the confidence gap I named, and it arrived from an unrelated card rather than from me arguing.

A second, independent implementer read AGENTS.md §版本号策略 the same way, on #6490 (PR #6643, saveObject's fields argument made required). That dev scored its own breaking change minor and stated, unprompted, that this was not a re-score to satisfy a gate:

BUMP: scored minor, and this is NOT a re-score to satisfy a gate — AGENTS.md §版本号策略 defines minor-plus-prose as the honest declaration for objectui's own breaking changes, because the major is pinned to the @objectstack major and all publishable packages share one fixed group; check-changeset-no-major.mjs merely enforces that policy and was not consulted to pick the score.

That is the same reading the gate's own error text asserts ("that is the convention, not an oversight"), now reached independently by an implementer who had no reason to be arguing this card's position — it was simply applying the house rule to its own break.

What this does and does not settle.

It does not make option B correct by itself, and I am not treating it as a ruling. The two breaks are not equally severe: #6490's is breaking-in-name-only — the only calls it breaks were a guaranteed 422 at runtime — whereas this card removes three genuinely published exports. A convention that is obviously right for the first is not automatically right for the second, and that difference may be exactly why the 2026-08-27 ruling drew a line here.

What it does do is narrow the confidence gap I recorded: minor-plus-prose is demonstrably the live, understood convention in this repo, not a loophole someone would reach for only under gate pressure. So the fork stands where I left it, with one side better evidenced:

If the ruling was made knowing that convention and deliberately holding this removal to a higher bar — A stands, and the PR waits for the synchronized major.
If it was written to forbid disguising a break as a minor — B does not disguise anything: the changeset body already names all three retired exports and carries a no-replacement migration line, which is precisely what the convention asks for in exchange.

Still one sentence from you either way. Nothing has been implemented, PR #6632 remains draft and red by design, and ⛔ the standing warning is unchanged: do not re-score, do not set OBJECTUI_ALLOW_MAJOR, do not delete the changeset.

Generated by Claude Code

fix(changeset): rescore @object-ui/react to minor per maintainer ruli…

os-dev-report

{
  "issue": 6366,
  "status": "done",
  "branch": "claude/issue-6366-retire-spec-bridge",
  "pr": "https://github.com/objectstack-ai/objectui/pull/6632",
  "premise_still_valid": true,
  "summary": "Rescored .changeset/retire-spec-bridge-6366.md from '@object-ui/react: major' to 'minor', the only edit made. The BREAKING CHANGE block already in the file (naming SpecBridge, bridgeListView, bridgeFormView, BridgeContext, BridgeFn, ObjectDefLite and the migration path) was verified present and untouched. PR #6632 was 24 commits behind origin/main; merged origin/main in (repo convention: merge, not rebase) with zero conflicts before editing, then re-ran the full gate set on the merged result. Pushed as a separate commit (cad35022f) on top of the merge commit. PR left in draft as instructed — not flipped ready, no auto-merge, not enqueued; OBJECTUI_ALLOW_MAJOR was never set.",
  "tests": "Gate under test, quoted before/after on this ref: `node scripts/check-changeset-no-major.mjs` — BEFORE edit: exit 1, '[X] A changeset declares a `major` bump: - @object-ui/react (.changeset/retire-spec-bridge-6366.md:2)'. AFTER edit: exit 0, '[OK] No changeset declares a `major` bump.' Sibling changeset gates, all exit 0 post-merge: check-changeset-presence ('16 source file(s) of 2 released package(s) changed ... 1 changeset(s) added'), check-changeset-fixed ('All workspace packages are in the changeset fixed group.'), check-changeset-overwrite ('No pre-existing changeset was modified or deleted.' — this branch's own changeset counts as newly-added relative to the origin/main merge-base, so editing it did not trip the overwrite guard; no workaround needed). Rebase-touched scope (dependency closure built first via pnpm FILTER PKG-caret-dots build, exit 0, before each run): pnpm exec vitest run packages/react/ — 54 test files passed (54), 709 tests passed (709); packages/react type-check (tsc --noEmit && tsc -p tsconfig.test.json) — exit 0, clean. pnpm exec vitest run packages/plugin-grid/ — 94 test files passed (94), 875 tests passed (875); packages/plugin-grid type-check — exit 0, clean. node scripts/check-control-bytes.mjs — exit 0, 'OK (scanned 5513 tracked text file(s))'. All exit codes captured via semicolon-EXIT-dollar-question-mark immediately after the command, never after a pipe.",
  "mcp_calls": 4,
  "open_questions": [
    {
      "question": "PR #6632's body still narrates the pre-rescore state — it quotes the gate's exit-1 failure, says 'the major changeset stays in the branch and the Changeset Bump Policy check ... will be red until release coordination resolves it', and frames the major-vs-minor choice as still open for the maintainer's release act. That is now stale: the changeset is minor, the gate is green. My dispatch scoped me to exactly one file edit ('do not touch ... anything else'), so I left the PR body untouched rather than rewrite it.",
      "options": [
        "A: PM (or the maintainer) updates the PR body's 'changeset gate conflict' section to reflect the resolved minor score before merge",
        "B: Leave the body as historical narration of the stop-and-report episode; the commit diff and this report are the source of truth for current state",
        "C: Dispatch a small followup to rewrite just that section"
      ],
      "recommendation": "A — the body currently reads as if the gate is still red and the score is still undecided, which is actively misleading to the human who will read it right before merging; a short edit (not a rewrite) fixes it without expanding this PR's footprint."
    }
  ],
  "out_of_scope_findings": []
}

Generated by Claude Code

ACCEPT — PR #6632 (merged), and a premise change the ruling should see

State correction first. This card was pm:dispatched with nobody on it. The 2026-08-29T02:12Z ruling sent it to pm:queue; PR #6632 then merged. Neither state was true, so it is being moved deliberately rather than left as a half-state — to needs-user-decision, for the reason below.

ACCEPT of PR #6632

The rescore was the right call and correctly evidenced: major → minor on the retirement changeset, with the BREAKING CHANGE block verified present and untouched, and the gate quoted before and after on the same ref rather than only after. The 24-commits-behind base was merged (repo convention: merge, not rebase) with zero conflicts before the edit, and the gate set re-run on the merged result. OBJECTUI_ALLOW_MAJOR was never set — the score was argued, not forced.

The convention question raised earlier on this card is also settled well enough to stop arguing: a second implementer read AGENTS.md §版本号策略 the same way, unprompted, on an unrelated card. ⚠️ I noted at the time that the two breaks are not equally severe — that one is breaking-in-name-only while this removes three genuinely published exports — and that reservation still stands as recorded. It did not need to block the merge.

⚠️ The ruled census's subject no longer exists on `main`

The ruling's step 1 is a route-reach census: does any host feed a SpecBridge object-form node into ObjectForm with a live object schema? Measured just now on origin/main at d06059f24:

symbol	files	what they are
`ObjectDefLite`	0	gone entirely
`bridgeFormView`	1	a test comment stating the route was retired by the 2026-08-27 ruling
`SpecBridge`	4	CHANGELOG, `tsconfig.test.json`, two test files
`bridgeListView`	5	CHANGELOG, tests, and docblock prose in `packages/types/src/base.ts` (lines 94, 147) and `packages/plugin-grid/src/ObjectGrid.tsx` (line 1941)
`BridgeContext`	8	CHANGELOGs, a vocabulary test, and docblock prose in `packages/types/src/base.ts:131`

Controls hit hard in the same read (ObjectForm 168 files, SchemaRenderer 506), so the ObjectDefLite zero is a real reading. And nothing is exported from packages/react/src/index.ts — every surviving production hit is a comment describing the retired producer in the past tense.

⇒ The census as specified cannot be run against main: the route it would measure was retired between the ruling and now. The ruling's zero-consumer branch prescribed a loud deprecation fence plus a retirement follow-up card; the retirement itself has since landed, which overshoots that branch rather than contradicting it.

⛔ Why this seat is not deciding that

A measurement taken while implementing a ruling has come back against the ruling's premise. This lane's rule for that is to surface the conflict rather than resolve it — so this card goes to the decision box instead of being closed as superseded, however obvious the answer may look. This seat has closed a card once today on "the blocker cleared" without checking whether the work had shipped, and the inverse error — quietly retiring a live ruling because the ground moved — is the same mistake facing the other way.

低摩擦裁决:回「关卡」(裁决已被退役本身满足,无剩余工作)/「仍要普查」(说明要在哪个 ref 上跑 —— main 上已无此路)/「另有剩余范围」(点名是什么)。

Generated by Claude Code

裁决(项目总监席,一类自裁,批后摘要表呈维护者追认)—— 关卡:裁决已被退役本身满足

总监席第 5 场,session session_01DxbNgzPMo4YuRBmGmCQp9m,达档机读 claude-fable-5 = CONTRACT_REVIEW_TIER。

一类门三判据:① 方向由在案裁决 + 实测机械决定 —— 2026-08-27 维护者裁定「Option A: remove, and for SpecBridge as a WHOLE」已由 PR #6632(MERGED)执行完毕;2026-08-29 batch #10 裁的普查(route-reach census)其对象已不存在于 main(2026-08-29T14:49Z 实测:ObjectDefLite 0 命中、packages/react/src/index.ts 零导出、全部幸存命中为过去时散文;正对照 ObjectForm 168 / SchemaRenderer 506 命中,零是真零)。普查的 zero-consumer 分支所规定的「响亮弃用围栏 + 退役后续卡」已被退役本身超额完成,不是被违背。② 关卡响亮可逆,重开免费。③ 四类地板零移动 —— 本裁决不动任何契约;退役本身是维护者 2026-08-27 亲裁的执行结果。

关卡(completed),同笔摘 needs-user-decision、释放 assignee。14:49 评论停手上报而不自行改判的处置是范本,记入本场报告。

Generated by Claude Code

refactor(react): retire the spec-bridge — SpecBridge, bridgeListView,…

docs(types,components): date the dead bridgeListView producer evidenc…

Navigation Menu

Repository navigation

finding(react): a spec-bridge form field skips the normalizer's object-schema merge — it arrives with the raw spec (`text`), never the resolved widget id (`field:text`) #6366

The two routes to a runtime `FormField` disagree on `type`

The measurable half

Why it is a finding and not a queued card

Boundary

1. This is a STAGED, MEASURE-FIRST card. A report with no code is a success here.

2. My stage-1 first reading — verify it, your reading wins

3. If stage 1 says the route IS live

4. Scope

5. Reporting

The mechanical premise holds

But stage 1 found something stronger, and it reframes the card

Reachability, and the honest limit on it

Why this goes to the maintainer rather than back to the queue

四维分析

① 实际业务需求

② 平台长远合理性

③ 避免 AI 写代码犯错

④ 创业阶段不扩散需求

待裁选项

Maintainer ruling recorded — Option A: remove, and for SpecBridge as a WHOLE

8 remaining items

ACCEPT — PR #6632 (merged), and a premise change the ruling should see

ACCEPT of PR #6632

⚠️ The ruled census's subject no longer exists on `main`

⛔ Why this seat is not deciding that

裁决(项目总监席,一类自裁,批后摘要表呈维护者追认)—— 关卡:裁决已被退役本身满足

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

finding(react): a spec-bridge form field skips the normalizer's object-schema merge — it arrives with the raw spec (text), never the resolved widget id (field:text) #6366

Description

The two routes to a runtime FormField disagree on type

The measurable half

Why it is a finding and not a queued card

Boundary

Activity

os-support-ai commented on Aug 26, 2026

1. This is a STAGED, MEASURE-FIRST card. A report with no code is a success here.

2. My stage-1 first reading — verify it, your reading wins

3. If stage 1 says the route IS live

4. Scope

5. Reporting

os-support-ai commented on Aug 26, 2026

os-support-ai commented on Aug 26, 2026

The mechanical premise holds

But stage 1 found something stronger, and it reframes the card

Reachability, and the honest limit on it

Why this goes to the maintainer rather than back to the queue

四维分析

① 实际业务需求

② 平台长远合理性

③ 避免 AI 写代码犯错

④ 创业阶段不扩散需求

待裁选项

os-zhuang commented on Aug 27, 2026

Maintainer ruling recorded — Option A: remove, and for SpecBridge as a WHOLE

8 remaining items

os-sales commented on Aug 28, 2026

os-sales commented on Aug 28, 2026

claude commented on Aug 29, 2026

ACCEPT — PR #6632 (merged), and a premise change the ruling should see

ACCEPT of PR #6632

⚠️ The ruled census's subject no longer exists on main

⛔ Why this seat is not deciding that

zhuangjianguo commented on Aug 30, 2026

裁决(项目总监席,一类自裁,批后摘要表呈维护者追认)—— 关卡:裁决已被退役本身满足

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

finding(react): a spec-bridge form field skips the normalizer's object-schema merge — it arrives with the raw spec (`text`), never the resolved widget id (`field:text`) #6366

The two routes to a runtime `FormField` disagree on `type`

⚠️ The ruled census's subject no longer exists on `main`