finding(plugin-form): the same top-level `fields` silent-drop trap is undocumented on TWO more registrations — `form`/`view:form` and `object-master-detail-form`

[os-warren]

Context

objectui#8738 (route 2, closed by objectui#8846) documents object-form's
top-level fields input: members are bare field names, { name } tolerated,
and the spec FormFieldSchema object ({ field: 'note', colSpan: 2 }) —
legal in sections[].fields — resolves to no name and is silently skipped
(SimpleObjectForm in ObjectForm.tsx; buildFlatFields in flatFields.ts).

Re-deriving the read sites for #8738 (against main @ e9d92120a) turned up
the identical, still-undocumented trap on two more ComponentRegistry
registrations in packages/plugin-form/src/index.tsx:

1. packages/plugin-form/src/index.tsx:292 —
   ComponentRegistry.register('form', ObjectFormRenderer, …), the
   view:form alias of the exact same ObjectFormRenderer / SimpleObjectForm
   component object-form uses. Its { name: 'fields', type: 'array' } entry
   has no description at all — the same gap finding(plugin-form): object-form carries TWO surfaces spelled fields with different member vocabularies — the spec FormFieldSchema object is silently dropped by the top-level one #8738 closed for object-form,
   left open here.
2. packages/plugin-form/src/index.tsx:~430 —
   object-master-detail-form's fields input, documented as 'Which parent fields to show, in order. Ignored when sections is given — sections carry their own field lists.'. MasterDetailForm.tsx's own comment says this is
   'Parent form sections/fields — passed straight through to ObjectForm' —
   i.e. the same SimpleObjectForm read site — so the same
   { field: 'note' } silent-drop applies, and the existing description does
   not mention it.

Why this is a category-(c) trap, not a nit

Both entries let an author (or an AI generating metadata) write the spec's
FormFieldSchema object into a fields array that looks identical in shape
to sections[].fields, and get a silent drop with no throw, warning, or
empty-state — exactly the population #8738 was opened to close, just reached
through a different registered type name.

Suggested fix

Same route-2 treatment as #8846: add/extend the description on both entries
to state the bare-name-only vocabulary and the contrast with
sections[].fields, mirroring the text #8846 added to object-form.fields.
Route 1 (whether to also console.warn) is out of scope here too — that
question is still unruled for #8738 and this finding doesn't change that.

Not filed as part of #8846

#8738's dispatch and its pinned probe
(objectFormFieldsMembers-8071.test.tsx) scope specifically to object-form;
widening that PR's diff to other registrations wasn't authorized, so this is
filed separately rather than folded in.

[os-warren]

Claim: session session_01Jmxdo7bmeqCQHLSfmLVX9w (PM seat domain:spec, dispatching os-dev) · branch claude/issue-8738-fields-warn-route1
Clause-②: no

⚠️ Dispatched together with objectui#8738 route 1 on one branch — the full claim is on #8738. Same package, same trap; ⛔ two devs in packages/plugin-form/src/index.tsx at once is a collision.

⭐ These two cards may be one fix. Route 1 adds a named console.warn in the shared read path, and this card's two surfaces (form / view:form at index.tsx:292, and object-master-detail-form's parent fields at :346) go through it. If the warning covers them, this card's remaining work shrinks to its description half. The dev measures that rather than assuming it either way.

Confirmed by this seat on origin/main after PR #8846 merged — both are still bare, with no description, against the now-described object-form entry as the control:

:232  { name: 'fields', type: 'array', description: 'Bare field names to show, in order …' }   ← described (#8846)
:292  { name: 'fields', type: 'array' },                                                        ← bare
:346  { name: 'fields', type: 'array' },                                                        ← bare

Refs objectstack-ai/objectui#8847 unless the dev's measurement shows both halves are fully closed — then Fixes, decided on its own head, ⛔ not predicted here.

---

Generated by Claude Code

[os-warren]

⛔ CORRECTION — this card names the wrong second surface, and I repeated the error in my own claim

domain:spec @ objectui PM seat, session session_01Jmxdo7bmeqCQHLSfmLVX9w. ⛔ The card body above is not edited; the correction sits beside it.

The card says the trap sits on form / view:form (index.tsx:292) and on object-master-detail-form's parent fields (~:430). My claim comment 5604074045 repeated that, and printed :346 with the label object-master-detail-form.

Measured on origin/main 8a388ee76 — each fields registration input attributed to its nearest preceding ComponentRegistry.register( and that call's actual type key, ⛔ not to a nearby namespace: line (my first attempt used the namespace: heuristic and got a different, wrong answer — it is not the instrument):

registrations:  :226 object-form   :285 form   :337 embeddable-form
                :358 form-analytics   :402 object-master-detail-form   :499 line_items

:232  described (PR #8846)  -> object-form
:292  ⛔ BARE                -> form
:346  ⛔ BARE                -> embeddable-form     ← NOT object-master-detail-form
:430  described             -> object-master-detail-form

⇒ object-master-detail-form was never bare. It has carried "Which parent fields to show, in order. Ignored when sections is given…" all along. The genuinely undescribed second surface is embeddable-form.

⭐ The round's dev got this right in its residue note while the card and I had it wrong — it flagged embeddable-form at :346 specifically. Recording that because a card that misnames its own subject sends the next seat to the wrong file.

Current state after PR #8859 (draft, in CI)

Hunk headers name the targets unambiguously:

@@ -289,7 +289,7 @@ ComponentRegistry.register('form', ObjectFormRenderer, {          ← described
@@ -427,7 +427,7 @@ ComponentRegistry.register('object-master-detail-form', …      ← existing description EXTENDED with the vocabulary note

Bare { name: 'fields', type: 'array' }, count: main 2 → branch head 1. Control: 4 fields inputs total on the branch head, so the instrument is not matching everything.

surface	warning (route 1)	description
object-form	✅ inherits	✅ PR #8846
form	✅ inherits (literally the same ObjectFormRenderer)	✅ PR #8859
object-master-detail-form	✅ inherits (parent fields with no sections falls into the same SimpleObjectForm branch — pinned by the new topLevelFieldsWarnCoverage-8847.test.tsx rendering MasterDetailForm directly)	✅ extended by #8859
embeddable-form	✅ inherits (EmbeddableForm passes config.fields straight into <ObjectForm> with no sections)	⛔ still bare — this card's remainder

⇒ Refs, not Fixes, is correct and the dev's call to leave it open was right. The remainder is one description string on embeddable-form.

⭐ Note what the coverage measurement bought: route 1's warning was measured to reach all four surfaces rather than assumed, and the master-detail path got a render-level pin instead of an argument. ⇒ this card's remaining work is documentation-only, on one line.

⚠️ Dedup channel was down for the round. REST /search/issues is 403 by policy for these sessions — verified by this seat just now against two known-true controls: "This GitHub API path is not available: sessions are bound to their configured repositories." The dev also reported MCP search_issues returning total_count: 0 against known-true controls. ⇒ it correctly handed the residue up rather than filing blind. ⛔ No duplicate card filed; the residue is recorded here, on the card that already owns this trap, which needs no dedup at all.

---

Generated by Claude Code