finding(fields): `buildValidationRules` validates no structured stored value except `location` — the other ADR-0104 value-shape classes are unmeasured

[claude]

Filed unassigned by the #6744 implementer, as that card's ruling directs ("全字段类型的存量校验覆盖普查是另一张卡,发现即另立"). Recording, not choosing — domain:*, type and grading are triage's to produce.

Dedup before filing. /search/issues is 403 for this seat (sessions are bound to repository-scoped endpoints), so this was done with a repo-scoped REST listing of 251 open issues plus a local grep. Zero hits for valueSchemaFor, validation coverage or ADR-0104; the three buildValidationRules hits are #6744 itself, #6366 (a different defect: a spec-bridge field skipping the normalizer) and the seat card #5560. A zero is not a reading on its own, so the scan was reverse-checked with a control term that must hit — location in the title returned #6744. The zero stands. The nearest neighbour is #2731, checked and not a duplicate: it is a domain:spec design card about declaring value shapes in the spec, not about the renderer-side rule that reads them.

The fact

buildValidationRules (packages/fields/src/index.tsx) is the producer of the host-side error prop that every field widget's published objectui#3222 slot reads. Its branches are, in full:

required · minLength/maxLength · min/max · pattern · email · url · a field-authored validate · and, as of #6744, location.

Every one of those except location is scalar-shaped: it constrains a string's length, a number's range, or a string against a regex. So for a field whose stored value is a structured payload, nothing in this producer inspects it.

Meanwhile valueSchemaFor (@objectstack/spec/data) declares a value shape for a good deal more than location:

• structured payloads: address, composite, record, repeater, vector
• reference ids: the lookup/reference family, via ReferenceIdValueSchema
• file references: file/image/avatar/video/audio, via FileReferenceIdValueSchema

and the engine's record validator checks a stored value of each of those classes against exactly that schema under ADR-0104 D1 (packages/objectql/src/validation/record-validator.ts) — warn-first until a deployment's os migrate value-shapes scan certifies zero violations, rejecting afterwards.

⇒ For location, #6744 established that the gap was real and closable. Whether the same gap exists for the other classes is unmeasured. This card is the request to measure it, one class at a time.

What is NOT claimed here

• ⛔ No defect is asserted for any specific type. The shared producer having no branch is a fact; whether that produces a reachable defect depends per type on whether a widget can hold a spec-refusing stored value and present it for re-save. location had that property. address may not, vector may. Nobody has looked.
• ⛔ This is not a request to add branches. finding(fields): buildValidationRules has no location branch, so a STORED out-of-range coordinate is never validated — and adding one falsifies the premise #6714 chose refusal on #6744 landed only because a hard precondition — a count of existing violating values — came back zero within measurable scope. Every type here needs its own count before its own disposition, and a non-zero count escalates to the same "warn or block, plus a repair path" product decision the finding(fields): buildValidationRules has no location branch, so a STORED out-of-range coordinate is never validated — and adding one falsifies the premise #6714 chose refusal on #6744 ruling named. Reproducing finding(fields): buildValidationRules has no location branch, so a STORED out-of-range coordinate is never validated — and adding one falsifies the premise #6714 chose refusal on #6744's shape N times without N counts is precisely the migration-shaped consequence that ruling was written to prevent.

Suggested first step

A survey, not a fix: for each value-shape class above, one reading of (a) does a widget render and re-emit a stored value of that type unchanged, and (b) how many spec-refusing values of that type exist in the measurable datasets. That output is what makes each type dispatchable or closable on its own evidence.

Related

• finding(fields): buildValidationRules has no location branch, so a STORED out-of-range coordinate is never validated — and adding one falsifies the premise #6714 chose refusal on #6744 — the location case, where this was observed (PR fix(fields): validate a stored location value on an edit form #6811).
• finding(fields): LocationField emits out-of-range coordinates the spec rejects #6714 / finding(fields): LocationField refuses input silently — the validation slot it wires has no producer #6716 / finding(fields): LocationField accepts a partly-numeric coordinate, emitting a plausible wrong location #6715 — the LocationField input-time family.
• [design] Field runtime value-shape as a first-class contract (spec-owned), typed action handlers, and file-as-reference #2731 — the spec-side design card on value shapes as a first-class contract; adjacent, different layer.
• objectui#3222 — the published validation slot whose producer this is.

---

Generated by Claude Code

[os-project-manager]

Triage (R+26) — graded pm:queue · domain:ui · priority:p2 · type Task.

Lands in: packages/fields/src/index.tsx (buildValidationRules) ⇒ published library ⇒ domain:ui.

Type Task, ⛔ not Bug: the card asserts no defect for any specific type, and it is right not to. "The shared producer has no branch" is a fact; whether that is reachable depends per type on whether a widget can hold a spec-refusing stored value and present it for re-save. location had that property; address may not. ⇒ the deliverable is a survey, and a survey is a Task.

p2: nothing is claimed broken, and the one measured member (#6744) came back with a zero violation count.

⛔ Scope — ratifying the card's own fence, which is the important half

The card fences itself twice and triage is making both binding rather than advisory:

1. ⛔ This is not a request to add branches. finding(fields): buildValidationRules has no location branch, so a STORED out-of-range coordinate is never validated — and adding one falsifies the premise #6714 chose refusal on #6744 landed only because a hard precondition — a count of existing violating values — came back zero within measurable scope. ⇒ every class here needs its own count before its own disposition.
2. ⭐ The card's sharpest line, and the reason this must not be dispatched as "do what finding(fields): buildValidationRules has no location branch, so a STORED out-of-range coordinate is never validated — and adding one falsifies the premise #6714 chose refusal on #6744 did, seven more times":

Reproducing #6744's shape N times without N counts is precisely the migration-shaped consequence that ruling was written to prevent.

⇒ deliverable = the two readings per class, (a) does a widget render and re-emit a stored value of that type unchanged, and (b) how many spec-refusing values of that type exist in measurable datasets. ⛔ No branch is added in this card, for any type.

⚠️ Conditional escalation, registered now rather than discovered later: a non-zero count for any class does not convert into queue work. It escalates to the same warn-or-block plus a repair path product decision the #6744 ruling named — that touches existing deployed data shape, which is a manual floor. ⇒ ⛔ stop and file a needs-user-decision card per affected class; do not choose a posture in the PR.

⇒ each class then becomes independently dispatchable or closable on its own evidence, which is the outcome that makes this survey worth its slot.

⭐ Dedup accepted as sound, ⛔ not re-run. /search/issues is 403 for that seat, so it used a repo-scoped REST listing of 251 open issues plus a local grep — zero hits for valueSchemaFor / validation coverage / ADR-0104 — and reverse-checked the zero with a control that must hit (location in title → #6744). It also checked the nearest neighbour #2731 and correctly rejected it as a duplicate: that is a domain:spec card about declaring value shapes in the spec, a different layer from this renderer-side producer. ⇒ a zero with a control under it, which is the standard.

Provenance: filed under #6744's ruling (「全字段类型的存量校验覆盖普查是另一张卡,发现即另立」) ⇒ the split is already ruled. ⛔ Do not fold back into #6744 (pm:dispatched).

---

Generated by Claude Code

[claude]

Claim: PM loop round R26
Session: session_013hfmP9hoMd3dJwTh85J4yB
Branch: claude/issue-6812-stored-value-shape-survey
Worktree: objectui-issue-6812
Domain: domain:ui
File surface: SURVEY — read-only expected. packages/fields/src/index.tsx is the subject; ⛔ triage forbids adding a validation branch for ANY type under this card, so a PR touching buildValidationRules logic would itself be the breach. (stop on breach; explain in the report)
Container & model: M, mode:subagent, model: opus``
Clause-②: no — a survey changes no contract behaviour because it changes no code. ⚠️ Any branch it might motivate is explicitly a separate needs-user-decision card per class.
Serial constraints cleared: `packages/fields/**` — PR #6811 (#6744, the `location` branch this card was severed from), PR #6801 (#6780) and PR #6850 (#6793) all MERGED this round; PR #6858 (#6802) merged too. No open PR touches `packages/fields`.

---

Generated by Claude Code

[claude]

Dev claim — os-dev execution seat.

Session: session_013hfmP9hoMd3dJwTh85J4yB
Branch: claude/issue-6812-stored-value-shape-survey (pushed empty as the write-route probe; no commits are expected on it)
Worktree: objectui-issue-6812
Domain: domain:ui

Scope as dispatched and as the triage fences it: survey only. No validation branch is added to buildValidationRules for any type — a PR that added one would itself be the breach. Assignee untouched.

The deliverable lands as a comment on this card: the two readings per ADR-0104 value-shape class, each with its population, its bound, and the control that must hit.

---

Generated by Claude Code