Form authoring: refuse an object-required field placed inside a predicate-gated section at save time (ruled option B of objectstack#13252)

[zhuangjianguo]

Filed by the director seat (session session_01DxbNgzPMo4YuRBmGmCQp9m) executing the maintainer ruling on objectstack#13252 (2026-08-30, batch #5, verbatim 「同意」 adopting option B). Cross-repo linkage card: the ruling lives there; this card is its objectui-side deliverable.

The ruled behaviour

Form validation refuses, at save/authoring time, the one hazardous arrangement objectstack#13252 measured: a field the OBJECT declares required placed inside a form section carrying a visibleWhen predicate. Without this, the author ships a form that cannot be completed when the predicate hides the section — the user sees a server error naming a field they cannot see. The server stays the single validation authority (deliberately does NOT read form-view predicates — ruled option C rejected: a validator consuming view metadata is presentation semantics leaking into the data contract); this card is the author-facing early fence, exactly where a generating agent needs the feedback (it can see the section grouping; it cannot see the object's required flag).

Landing surface

The form validation / authoring layer (plugin-form or the save-gate that validates authored form views) — ⛔ NOT packages/objectql (that repo's server validator is ruled untouched), ⛔ not a runtime render-time check.

⚠️ Dev-first-verify premises (both unmeasured — either failing is a STOP-AND-REPORT, a successful delivery)

1. Can this layer see the object's required flag at all? Option B's feasibility rests entirely on this and nobody has verified it. If the validation layer has no data path to the object schema, report the gap with the wiring it would need — do not build a new data path on your own authority.
2. Census with a positive control: how many existing forms (this repo + hotcrm if reachable) actually place an object-required field inside a predicate-gated section. If the count is 0 the fence still lands (it is a fence for generated forms, the population that matters is future AI output), but report the number — it calibrates severity.

Scope notes

• The refusal wording must name both facts (the field is object-required AND its section is predicate-gated) and teach the remedy (move the field, or drop the predicate, or make the field not-required at the object).
• Related, already ruled separately: objectui#6237 (type split for FormSectionConfig, batch Add public roadmap, VitePress documentation site, and GitHub Pages deployment #3) — the tabbed-arm predicate plumbing. This card is about the authoring fence, not the render path; do not fold.

Refs: objectstack#13252 (the ruling record) · objectui#6237 · objectui PR #6791 (where the cross-repo half surfaced)

[os-sam]

🔒 Claimed by the domain:ui execution seat

PM session session_013hfmP9hoMd3dJwTh85J4yB · branch claude/issue-6900-required-field-in-gated-section.

Read before claiming: body, 0 comments (window: card created 2026-08-30T13:33:57Z, unmodified since). Written by the director seat executing the maintainer ruling on objectstack#13252, so the card is the ruling's objectui-side statement — there is no thread to miss.

Fence was clear at claim time: this card's surface is plugin-form / the authoring save-gate, and the sibling dev holding packages/plugin-form/ finished when PR #6903 merged at 14:34:55Z. No collision. The other three live devs hold packages/app-shell/ + apps/console/ (#6776), packages/components/ + packages/fields/ (#6859), and packages/data-objectstack/ (#6825).

Landing path: clause ② applied, and the reason is stated so it can be overturned

⚠️ needs:contract-review applied. The card describes a refusal — "Form validation refuses, at save/authoring time" — which moves what the authoring boundary accepts, i.e. a reject-direction change of the same shape the maintainer classed as clause ② on #6781 ("改变已发布渲染器的接受/拒绝行为(拒绝新增)").

⛔ But I am flagging this as my judgement, not the card's: the card does not say clause ②. Clause ② is a floor and over-applying it costs a review cycle, while under-applying it costs a published-surface change with no contract reader. ⇒ I applied it. If the delivered thing turns out to be a non-blocking diagnostic rather than an actual refusal, the tier should be revisited — I have told the dev to say so explicitly if that is what the evidence supports.

⭐ No priority label added. The card carries none, and grading is triage's, not this seat's. Dispatching without one rather than inventing it.

Why this card's two premises are the deliverable, not preliminaries

The card states both plainly, and I am passing them through as written because they are unusually well-posed:

⚠️ Dev-first-verify premises (both unmeasured — either failing is a STOP-AND-REPORT, a successful delivery)

1. Can the validation layer see the object's required flag at all? Option B's entire feasibility rests on this and nobody has verified it. ⛔ If there is no data path, the deliverable is the gap plus the wiring it would need — ⛔ not a new data path built on the dev's own authority.
2. Census with a positive control: how many existing forms actually place an object-required field inside a predicate-gated section. ⭐ The card pre-empts the obvious misreading: "If the count is 0 the fence still lands (it is a fence for generated forms, the population that matters is future AI output), but report the number — it calibrates severity."

⇒ That second note is why I am not treating a zero as a reason to downgrade. This fence exists for the authoring population that does not exist yet, and the card says so before the measurement is taken — which is the right order.

The layering the ruling protects

Option C was rejected: the server must not read form-view predicates, because "a validator consuming view metadata is presentation semantics leaking into the data contract." ⇒ The server stays the single validation authority; this card is the author-facing early fence, placed exactly where a generating agent needs it — it can see the section grouping but cannot see the object's required flag.

⛔ packages/objectql is ruled untouched. ⛔ Not a render-time check. ⛔ Do not fold in #6237's type split — that is the render path, this is the authoring fence, and the card says not to.

---

Generated by Claude Code

[claude]

os-dev-report

{
 "issue": 6900,
 "status": "needs_decision",
 "branch": "claude/issue-6900-required-field-in-gated-section",
 "pr": null,
 "premise_still_valid": false,
 "summary": "STOP-AND-REPORT under premise 1, with a SPLIT answer rather than a flat no — and the split is the finding. Premise 1 asks whether the form-validation layer can see the object's `required` flag. Measured at three layers: (a) plugin-form CAN (both facts already meet in one call, no new data path); (b) the layer that actually validates an AUTHORED form view before save — metadata-admin's `validateMetadataDraft` — CANNOT (no object-schema parameter, no resolver, and a `view` draft carries only `object: 'NAME'`, a name); (c) the published author-time gates (objectui validate/check, `safeValidateSchema`, sdui-parser) CANNOT, and sdui-parser states that boundary as design. So the card's implicit premise — that some layer both sees `required` AND can refuse before save — does NOT hold today. The only layer that sees `required` has no save/authoring gate, only render, which the card excludes; the only layer that can refuse before save needs a new data path, which the card forbids me to build, AND sits inside packages/app-shell, which is fence #6776. Both exits are explicitly closed to this dispatch, so I wrote no code: zero edits, `git status` clean at 3b9c774c5. Two further measured facts materially change the decision and are in open_questions: the arrangement this card would refuse is pinned in 3 test files as the SUPPORTED behaviour of ruled objectui#6237 semantic 1, and `requiredWhen` is already a server-enforced object-level answer to the same hazard.",
 "premise_1": {
 "answer": "SPLIT — yes at plugin-form, no at every layer that can refuse before save",
 "plugin_form_YES": [
 "packages/plugin-form/src/sectionFields.ts — `SectionFieldsContext.objectSchema`, documented as 'Resolved object schema ({ fields: { [name]: fieldDef } }) or null'",
 "packages/plugin-form/src/TabbedForm.tsx:326-338 — buildSectionFieldsShared(section, { objectSchema, ... }): the `section` argument carries `visibleWhen` and the context carries the object's `required`, in ONE call. This is the exact conjunction premise 1 asks about.",
 "packages/plugin-form/src/schemaDefaults.ts — isRequiredInForm(field, isCreateForm) reads `field.required` straight off the object schema",
 "packages/plugin-form/src/ObjectForm.tsx:471 objectSchema state (fetched from the data source) and :1130 effectiveSections live in one component scope",
 "CONSEQUENCE: no new data path would be needed here — but plugin-form's only hook is RENDER, which the card excludes ('not a runtime render-time check')"
 ],
 "authoring_save_gate_NO": [
 "packages/app-shell/src/views/metadata-admin/clientValidation.ts:922-943 — validateMetadataDraft(type, draft, serverSchema?, options?). `serverSchema` is the METADATA TYPE's JSON Schema from /meta/types (RichMetadataTypeEntry.schema); its only use is suppressing top-level 'missing required field' issues on the draft itself. It is NOT the object's field schema.",
 "The one object-fields reader it imports, `readFields` from ./previews/object-fields-io.js, is used only at line 766 inside validateObjectFieldRules on an OBJECT draft's own `draft.fields` — never to resolve a foreign object by name.",
 "Call site packages/app-shell/src/views/metadata-admin/ResourceEditPage.tsx:585 passes (type, draft, entry?.schema, { mode: draftMode }) — no object schema and no object-schema resolver in scope."
 ],
 "published_author_time_gates_NO": [
 "packages/cli/src/commands/validate.ts and check.ts validate ONE schema file at a time via safeValidateSchema; no cross-file object lookup",
 "packages/types/src/zod/index.zod.ts:426 — safeValidateSchema(schema) = AnyComponentSchema.safeParse(schema): a form-view tree in isolation, so a superRefine there structurally cannot read the object's `required`",
 "packages/sdui-parser/src/validate.ts header states the boundary by design: 'binding sites the SERVER must resolve against object schema (we cannot resolve objects/fields here — that check is framework-side by design)'"
 ],
 "wiring_it_would_need": [
 "1. Thread an object-schema resolver into the save gate: give validateMetadataDraft a 5th input, e.g. an objectFields lookup keyed by object name, and have it consulted only for type === 'view' with viewKind form.",
 "2. Supply it at the call site: MetadataProvider already exposes useMetadataType('object') (packages/app-shell/src/providers/MetadataProvider.tsx:1022) and mergeViewsIntoObjects (ibid:382), so ResourceEditPage can hand the matching object's `fields` in without a new fetch layer — but it IS a new dependency edge from the view gate to object metadata, which is precisely the edge the card told me not to create on my own authority.",
 "3. Put the predicate itself in a neutral, non-fenced home so the gate and any future gate share one implementation — @object-ui/core validation is the natural place (plugin-form already depends on it, and app-shell can too); plugin-form would then re-export rather than own it.",
 "4. BOTH 1 and 2 land inside packages/app-shell — live fence #6776 — so this needs sequencing as well as a ruling."
 ]
 },
 "premise_2_census": {
 "numerator_authored_production_form_views": 0,
 "numerator_whole_repo_including_test_fixtures": "10 gated-section literals across 3 distinct files",
 "hazard_files": [
 "packages/plugin-form/src/__tests__/tabbedFormSectionPredicate-6237.test.tsx (6 literals)",
 "packages/components/src/renderers/form/__tests__/fieldtab-visiblewhen-6237.test.tsx (2)",
 "packages/components/src/renderers/form/__tests__/section-grouping-6236.test.tsx (2)"
 ],
 "positive_controls_same_run": {
 "C1_gated_sections_repo_wide": 35,
 "C2_required_true_declarations": 388,
 "C3_synthetic_hazardous_form_view_through_the_same_code": "1 (expected 1) — this is the control on the JOIN, the cell a zero lives in",
 "C4_named_fixture_sectionVisibleWhen_6111_present_in_C1": "1 (expected at least 1)",
 "C5_population_is_non_empty": "20 non-test files declare a `sections:` array (examples/schema-catalog/src/schemas/plugin-form/object-form-tabbed-sections.json, examples/byo-backend-console/src/App.tsx, content/docs/**, package READMEs). The authored-form-view zero is measured over a non-empty population, not a vacuous zero.",
 "files_scanned": 5655
 },
 "control_that_FAILED_first_and_was_fixed": "The first census run reported C3 = 0. The gated-section detector attempted its match only AFTER a quoted key had been consumed as a string, so it saw bare TS keys (`visibleWhen:`) but never JSON ones (\"visibleWhen\":). C1 was 9 and looked plausible; without C3 the numerator would have been reported as a clean zero. Fixed, re-run: C3 = 1. A second widening followed — v1 keyed on a `sections: [...]` PROPERTY and so missed sections bound to a variable (`const sections = (gate) => [...]`, how the plugin-form fixtures write them); v2 recognises a section by SHAPE (an object literal with top-level `fields` AND `visibleWhen`), which took C1 from 9 to 35 and the numerator from 0 to 10.",
 "hotcrm": "NOT REACHABLE from this seat — GET /repos/objectstack-ai/hotcrm returned HTTP 403. Not measured, not reported as zero.",
 "severity_reading": "Zero in shipped/authored form views, as the ruling's confidence gap 1 suspected. Per the card that does not downgrade the work — the population that matters is future generated output. But see open_question 2: every in-repo instance is a DELIBERATE fixture pinning the opposite-direction ruled behaviour."
 },
 "refusal_wording_drafted_not_landed": "Section SECTION_NAME is gated by `visibleWhen`, and it holds FIELD_NAME, which object OBJECT_NAME declares `required: true`. A hidden section's fields skip client-side validation, so this form submits without FIELD_NAME and the server refuses the save naming a field the user cannot see. Fix it in the authoring metadata, one of three ways: (1) move FIELD_NAME into a section that carries no `visibleWhen`; (2) drop `visibleWhen` from section SECTION_NAME; or (3) on object OBJECT_NAME replace `required: true` with `requiredWhen` carrying the SAME predicate — the server's rule-validator enforces `requiredWhen`, so the object and the form agree without the validator ever reading view metadata.",
 "why_an_author_can_act_on_it": "It names both facts the author cannot see together (this field is object-required; this section is predicate-gated), names the three identifiers involved so a generating agent can patch without searching, states the consequence in the order the author will meet it (submit succeeds, server refuses, error names an invisible field), and gives three remedies of increasing correctness. Remedy 3 is the contract-first one and is the reason the wording is worth landing at all: `requiredWhen` is already server-enforced (packages/types/src/form.ts:1045 — 'the server enforces the same rule in its rule-validator'), so it resolves the hazard at the producer with no view-metadata leakage — exactly the direction option C was rejected for violating.",
 "tests": "NOT APPLICABLE — no code was written, so there is no red-first test, no ablation and no changeset. Reporting that plainly rather than filling the template. What WAS run: (1) worktree at /home/user/objectui-6900 off origin/main 3b9c774c5, `pnpm install` exit 0 in 7.3s; (2) the empty branch was pushed as the write-route probe before any edit and succeeded; (3) the premise-2 census, twice, scripts at /tmp/claude-0/-home-user/94290476-0f38-5613-a653-5249437cbbfb/scratchpad/issue-6900/census.py and census2.py, 5655 files scanned, controls C1-C5 above, C3 caught a real scanner defect on the first run; (4) premise-1 was measured by reading signatures and call sites, cited by file and line above. `git status --porcelain` is empty at 3b9c774c5 — zero edits, so no gate was run and none is claimed.",
 "clause_2_read": "Clause 2 cannot be assessed on delivered code, because nothing was delivered. But the PM asked me to test the reasoning, so: the reasoning is sound CONDITIONAL on the thing landing as an actual refusal, and my measurement says the only landing reachable today without a new data path or a fence crossing is a render-time console diagnostic in plugin-form — the exact shape packages/plugin-form/src/sectionPredicateDiagnostic.ts already uses for objectui#6237. That is a non-blocking diagnostic, NOT a reject-direction move of the authoring boundary, so it would NOT be clause 2. Under the wiring above it WOULD be a refusal and clause 2 would apply. The tier therefore follows the landing decision in open_question 1 and should be set after it, not inherited.",
 "mcp_calls": "0 — the whole run used repo-scoped REST (probe HTTP 200) plus git; no MCP GitHub call was made",
 "open_questions": [
 {
 "question": "Where does the authoring fence land, given that no layer today both sees the object `required` flag and can refuse before save?",
 "options": [
 "A. Wire the object-schema resolver into metadata-admin's validateMetadataDraft (the 4 steps above). Real refusal, real save-gate, clause 2 applies. Cost: a new dependency edge from the view gate to object metadata, and it lands inside fence #6776 so it must be sequenced after that card.",
 "B. Land a pure predicate in @object-ui/core (or plugin-form) and wire NOTHING yet. Cost: declared-but-unenforced, which is the rejected option A shape and ADR-0049 enforce-or-remove territory. Not recommended.",
 "C. Land it as a render-time console diagnostic in plugin-form next to sectionPredicateDiagnostic.ts. Cheapest, needs no new data path and crosses no fence — but it is the render-time check the card explicitly excludes, and it is a diagnostic, not a refusal, so it does not deliver the ruling.",
 "D. Re-scope to the producer: teach the fence as `requiredWhen` guidance (see open_question 3) and close the card as satisfied by an existing contract."
 ],
 "recommendation": "A, sequenced after #6776 — but only after the maintainer sees open_questions 2 and 3, either of which could turn the answer into D. A is the only option that delivers the refusal the ruling actually adopted; C delivers the wrong artifact under the right card number, and B is the shape the maintainer already declined."
 },
 {
 "question": "The arrangement this card refuses at authoring time is pinned in 3 test files as the SUPPORTED behaviour of ruled objectui#6237 semantic 1. Is the fence coherent with that ruling, and what happens to those pins?",
 "options": [
 "A. Coherent as stated: #6237 semantic 1 governs the RENDERER (a hidden section's fields skip client validation, the server is the loud floor), the #6900 fence governs the AUTHOR (do not compose it in the first place). Both hold; the fixtures keep pinning render-time degradation for arrangements that slipped through.",
 "B. In tension: tabbedFormSectionPredicate-6237.test.tsx says in its own words 'salary is REQUIRED on the object — the whole point of semantic 1. A form that blocks on it while its tab is hidden re-opens #2959 through the new door.' If authoring refuses the arrangement outright, the semantic-1 machinery is defending a state the platform now forbids, and the pins encode a shape no author may ship."
 ],
 "recommendation": "A, and I believe it survives — but the maintainer should confirm, because the ruling on #13252 was taken WITHOUT this census in hand (its confidence gap 1 said the number was unmeasured and 'decides whether this card is worth doing'). The number is now measured: 0 in shipped form views, and every in-repo instance is a deliberate fixture for the opposite-direction ruling. That is exactly the input the triage seat said should be gathered before spending maintainer attention."
 },
 {
 "question": "Does `requiredWhen` already solve the hazard this card exists for, at the producer, with no fence at all?",
 "options": [
 "A. Yes. packages/types/src/form.ts:1045 declares requiredWhen as a CEL predicate the SERVER enforces in its rule-validator, aligned with @objectstack/spec Field.requiredWhen. An author who writes the section's predicate as the field's requiredWhen gets object and form agreeing, enforced by the single authority, with the validator never reading view metadata — the shape option C was rejected for violating, achieved without option C.",
 "B. No / not fully — requiredWhen is per-field and record-scoped, the section predicate may be scoped differently (host scope, see wizardPredicateScope), so the two are not always expressible as one predicate."
 ],
 "recommendation": "A is likely right for the common case and should be the headline remedy in whatever ships (my drafted wording already leads to it), but I did NOT measure the scope-equivalence in B — the predicate scopes differ between section-level and field-level rules in this repo and that gap is real. If A holds generally, the fence's whole job shrinks to TEACHING requiredWhen, which is option D of open_question 1 and much cheaper than the wiring."
 }
 ],
 "out_of_scope_findings": []
}

Generated by Claude Code

---

Generated by Claude Code