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

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.

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

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:

⛔ 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.
⭐ 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

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

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

Survey — the two readings per ADR-0104 value-shape class

Base 30266cf (objectui main). ⛔ No branch was added to buildValidationRules for any type, per the fence this card sets and triage made binding. No PR; the probe used below was a read-only measurement and is deleted.

The instrument — #6744's, reused rather than reinvented

Every verdict below comes from valueSchemaFor(def, 'stored') in @objectstack/spec/data — the same schema the engine's record validator checks a stored value against under ADR-0104 D1. ⛔ No bound, key set or id shape is restated on this side.

⭐ One version fact worth stating, because it makes both repos' datasets comparable: objectui resolves @objectstack/spec@17.2.0, and objectstack's workspace packages/spec is also 17.2.0. One build of the contract adjudicated everything here.

The classes valueSchemaFor declares a shape for, and the widget each resolves to (fieldWidgetMap + field-type-alias.ts):

class	spec shape (stored)	widget
`address`	`AddressValueSchema`	`AddressField`
`composite` / `record`	`z.record(z.string(), z.unknown())`	`ObjectField`
`repeater`	`z.array(z.record(...))`	`GridField`
`vector`	`z.array(z.number())`	`VectorField`
`lookup` / `master_detail` / `tree`	`ReferenceIdValueSchema`	`LookupField`
`user`	`ReferenceIdValueSchema`	`UserField`
`file` / `video` / `audio`	`FileReferenceIdValueSchema`	`FileField`
`image`	`FileReferenceIdValueSchema`	`ImageField`
`avatar`	`FileReferenceIdValueSchema`	`AvatarField`

Reading (a) — does a widget hold a spec-refusing stored value and present it for re-save?

Measured, not read off the source. A real ObjectForm in mode: 'edit' was seeded with a stored value the spec refuses, then submitted without touching the control — the same shape #6744 used. Recorded per class: what the widget showed, whether dataSource.update ran, whether the written value is byte-identical to the stored one, and whether anything set aria-invalid.

Result: yes for all 14 classes. Every one wrote the refused value back unchanged, with nothing marked invalid.

class	seeded refused value	what the widget showed	update	written value	invalid
`address`	`'1 Main St, Seattle WA'` (flat string)	5 sub-inputs, all empty	called	identical	no
`composite`	`'{"width":10,"height":20}'` (JSON text)	the raw JSON text	called	identical	no
`record`	`[{ name: 'A' }]` (array)	the raw JSON text	called	identical	no
`repeater`	`{ '0': { a: 1 } }` (index-keyed object)	one row, `#1` + `Add line`	called	identical	no
`vector`	`['0.12','0.34']` (numeric strings)	`[0.1200, 0.3400...](2D)` — formats the strings as if numbers	called	identical	no
`lookup`	`'{"id":"acc_1","name":"Northwind"}'` (embedded record text)	`Northwind` — it hydrates the embedded record and shows its name	called	identical	no
`master_detail`	`'{"id":"p_1"}'`	`p_1`	called	identical	no
`user`	`{ id: 'u_1', name: 'Ada' }` (expanded object)	`AD` avatar + `Ada`	called	identical	no
`tree`	`'[{"id":"c_1"}]'`	`Select…` (nothing)	called	identical	no
`file`	`'https://cdn.example.com/report.pdf'`	`report.pdf`, parsed out of the URL	called	identical	no
`image`	`{ url: '…/a.png', name: 'a.png' }` (legacy inline blob)	its add-more affordance	called	identical	no
`avatar`	`'https://cdn.example.com/av.png'`	initials + `Change Avatar`	called	identical	no
`video`	`'https://cdn.example.com/a.mp4'`	`a.mp4`	called	identical	no
`audio`	`'https://cdn.example.com/a.mp3'`	`a.mp3`	called	identical	no
`location` (CONTROL)	`{ lat: 999, lng: 999 }`	`999, 999` in the input	0 calls	—	`aria-invalid="true"`

⭐ The control is the load-bearing row. location is the one class with a branch (#6744), and in the same harness, same run, it blocks the write and marks the control invalid. So the fourteen "wrote it back" readings are a property of those classes, not an artifact of a harness that cannot see a refusal.

Second control direction. For seven classes a spec-accepted value was seeded as well (address {street,city}, composite {width:10}, record {primary:{…}}, repeater [{a:1}], vector [0.12,0.34], file 'file_abc123', image 'img_abc123'): written back unchanged, nothing invalid — identical outcome to the refused values. ⇒ the surface makes no distinction whatsoever between a value the platform accepts and one it refuses. That is the "no branch" fact, measured rather than inferred.

⚠️ Two rows deserve reading twice, because they are worse than the plain "unchanged re-save" the card anticipated:

lookup and user hydrate the refusing value into a friendly label (Northwind, Ada). To the person on the form the field looks correctly filled; the stored value is an embedded record the write path refuses under ADR-0104 D1.
file / video / audio derive a filename from the legacy URL (report.pdf, a.mp4), so a retired external-URL value presents as a real attachment.
address is the opposite failure: it presents nothing (five empty boxes) and still re-saves the original string. ⇒ the card's hypothesis "address may not [have the property]" is falsified: it does re-emit unchanged; it just never shows the user what it is about to re-save.

Reading (b) — how many spec-refusing values of each class exist in measurable datasets?

Answer: zero refused, in every class — but the population differs by three orders of magnitude between classes, so the zeros are not worth the same and are reported per class.

Population and how it was bounded

Values were adjudicated only where the field's definition could be identified — never by bare key name (a global key match is unusable here: field names like record, user, avatar, gallery collide with ordinary property names, and the first pass produced 20,229 "values" of which 10,727 "refused", every sampled one a CSS style object, a Mongo filter operator or a view-type string). Three precise joins:

J1 — objectstack seeds. Every defineSeed(Object, { records }) call, joined through the file's imports to that object module's own fields map: 24 of 24 calls joined, 0 unjoined. Generated rows (...Array.from(…) inside an arrow body) are walked too.
J2 — same-document schema+data. A fields map/array plus a sibling value container (data / defaultValues / records / rows / …) inside one file. Run over 10,516 files across both repos.
J3 — the qa/dogfood field-zoo matrix, whose entries carry their own type.

Dataset files parsed: 875 (400 under objectstack examples/ + packages/qa/, 475 under objectui examples/), inside the 10,516-file J2 sweep. Datasets covered: the app-showcase seed, app-crm, app-todo, embed-objectql, packages/qa (dogfood incl. the field-zoo matrix), and the objectui schema-catalog — i.e. #6744's three, plus every other example app.

Controls — 32 of them, in the same execution, through the same call path

For each class, one value that must be accepted and one that must be refused were adjudicated by the same schemaFor() used for the readings: 32/32 behaved as required (e.g. file accepts 'file_1' and refuses 'https://cdn.example.com/a.pdf'; lookup accepts 'acc_1' and refuses '{"id":"acc_1"}'; the location pair from #6744 reproduces). ⇒ each zero below is a reading, not a query that silently matched nothing.

Per class

class	values adjudicated	refused	where the population comes from	how much the zero is worth
`lookup`	76	0	showcase seed 45, app-crm 31	substantive — comparable to #6744's 28
`master_detail`	36	0	showcase seed 36	substantive
`vector`	4	0	showcase 1, ui-catalog 2, dogfood 1	thin
`address`	2	0	showcase 1, dogfood 1	thin and structurally weak — see below
`composite`	2	0	showcase 1, dogfood 1	thin, schema is near-open
`record`	2	0	showcase 1, dogfood 1	thin, schema is near-open
`repeater`	2	0	showcase 1, dogfood 1	thin
`file`	1	0	dogfood matrix (`file_zoo_doc`)	N=1
`image`	1	0	dogfood matrix (`file_zoo_image`)	N=1
`avatar`	1	0	dogfood matrix (`file_zoo_avatar`)	N=1
`video`	1	0	dogfood matrix (`file_zoo_video`)	N=1
`audio`	1	0	dogfood matrix (`file_zoo_audio`)	N=1
`user`	0	—	nothing anywhere	⛔ not a zero reading — no value exists to measure
`tree`	0	—	the one dogfood entry is a runtime-resolved placeholder	⛔ not a zero reading

Total: 129 stored values adjudicated, 0 refused, plus 3 non-static values (the dogfood matrix's REFERENCE_PLACEHOLDER for f_lookup / f_master_detail / f_tree, substituted with a real row id at runtime) reported as not adjudicable statically rather than counted either way.

⛔ user and tree must not be read as "clean". The showcase deliberately leaves f_user / f_users / f_owner unseeded (its own comment: sys_user rows come from sign-up, not seeds), and the five file-class fields are unseeded too — showcase_task.cover carries a docblock explaining that the ADR-0104 D3 wave-2 stored form is an opaque sys_file id, which is why nothing is seeded there. The classes most likely to hold a legacy shape are precisely the ones with almost no measurable values.

Independent cross-check (#6744's method B, adapted)

A deliberately over-inclusive pass — pair any literal under a key that any field container in the dataset roots declares with that class — was run to see whether the precise joins had missed a record value. 147 hits across the dataset files, 30 refused, every one hand-classified and none of them a stored record value:

25 are i18n label maps: fields: { account: { label: 'Account' } } in system/translations — refused only because a {label} object is not a record id;
5 are flow templates: account: '{account_id}' in flows/*.ts — refused only because ReferenceIdValueSchema rejects a leading {, and the template is interpolated before it is ever stored.

Extended to both whole repos, every file-class and reference-class refusal falling in a dataset path is likewise a permission matrix (crm_lead: {allowRead:true}), an expand spec (contact: {object, fields}) or a dashboard filter flag (customer: false). The one value the precise joins genuinely missed was account: 'Northwind' inside a generated 24-row block — accepted, and now folded into the 76 above.

⚠️ Boundary, as #6744's ruling requires it stated

Customer deployments are not measurable from this container. Every zero above means "zero within measurable scope", never "does not exist". Nothing here is evidence about deployed data.

⭐ One structural result that changes what a zero can mean

AddressValueSchema declares every member optional and is a zod z.object, which strips unrecognized keys instead of refusing them. So the only address values the stored contract can refuse are non-objects. Measured in the same run: the showcase seed's { street, city, state, postal_code, country } is accepted, with postal_code silently dropped from the parse output.

⇒ for address — and, more weakly, for composite / record, which are z.record(z.string(), z.unknown()) and admit any object — a zero-violation count is close to unfalsifiable, and is not evidence that stored values of that class are well-formed. Whatever disposition those three classes get should rest on the schema question, not on their count. (The postal_code drift itself is filed separately as objectstack#13388.)

Verification of the three PM assumptions

Branch list re-derived on my own base, not taken from the card. On 30266cf, buildValidationRules sits at packages/fields/src/index.tsx:2645 and its branches are, in full: required · minLength/maxLength (each with a legacy snake_case fallback) · min · max · pattern · email · url · a field-authored validate · location. ⇒ unchanged: none of the four packages/fields landings this round (fix(fields): validate a stored location value on an edit form #6811, fix(fields): announce bad input across the type="number" widget class #6801, test(fields): drive the type="number" widgets with values a browser can deliver #6850, fix(fields): compose the host onBlur in CurrencyField and TagsField #6858) added or moved a branch, so the survey's subject is the one the card describes.
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 instrument read and reused. Its reading was 28 stored location values adjudicated by valueSchemaFor(…, 'stored') with controls in the same call, plus a 12,465-file literal sweep whose 44 out-of-range hits were all test fixtures, docblocks, docs prose or changesets. Same predicate, same controls-in-the-same-call discipline, and the same two-method structure used above.
The producer claim is VERIFIED, with one refinement and one boundary.
- Verified: buildValidationRules(field) at ObjectForm.tsx:705 and sectionFields.ts:131 feeds react-hook-form's Controller, and the widget's error prop is fieldState.error?.message at form.tsx:2683.
- Refinement: it is the producer of every rule except presence — form.tsx deletes the compiled required and composes its own live required validator (via core's isMissingForRequired) so the verdict tracks the record as it changes.
- ⚠️ Boundary: it is the producer on the form surface only. InlineFieldInput (detail-page inline editing) never calls it and never receives an error prop, so that surface runs no host-side rule at all — including location. Filed as finding(plugin-detail): the inline-edit surface runs no host-side validation at all — InlineFieldInput never calls buildValidationRules and never gets an error prop #6868; this card's readings should be read as bounded to the form surface.

Disposition — no escalation is due

The registered conditional escalation (a non-zero count for any class ⇒ stop, file a needs-user-decision card per affected class, do not choose a posture) did not trigger: every count is zero. ⛔ No posture was chosen, and no branch was added.

What each class needs before it can be dispatched or closed on its own evidence:

lookup / master_detail — reading (a) yes; reading (b) 0 of 76 and 0 of 36, the only counts comparable to the precondition 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 on. These two are the ones a "does this class need a branch" decision could actually be taken on today.
file / image / avatar / video / audio — reading (a) yes, and worse than plain: the widgets present a legacy URL as a named attachment. Reading (b) is N=1 per class, all id-shaped by construction in the dogfood matrix. ⛔ That is not yet a count. These classes need a wider population first — and note the stored contract for them narrowed recently (ADR-0104 D3 wave 2), which is exactly the situation where deployed data is most likely to be older than the contract.
user / tree — no measurable value exists. Any disposition would rest on nothing.
address / composite / record — reading (a) yes; the count cannot falsify much (see above).
repeater / vector — reading (a) yes; a thin zero (N=2, N=4).

How to reproduce

Adjudication + controls: a Node script over both repos' dataset files using valueSchemaFor(def,'stored') from the resolved @objectstack/spec@17.2.0, with the three joins described above. It executes nothing from the datasets; values are read as static literals from the TypeScript/JSON AST.
Round-trip probe: a vitest file rendering a real ObjectForm per class (packages/plugin-form), run under the container's shared verify lock — VERDICT command-exit 0, 16 tests, 13.3 s. It was never committed and has been removed; packages/fields was not touched.

Generated by Claude Code

os-dev-report

{
  "issue": 6812,
  "status": "done",
  "branch": "claude/issue-6812-stored-value-shape-survey",
  "pr": null,
  "premise_still_valid": true,
  "summary": "SURVEY DELIVERED AS A CARD COMMENT; pr:null is the expected shape and no branch was added to buildValidationRules for any type. READING (a), measured through a real ObjectForm in edit mode seeded with a spec-refusing stored value and submitted untouched: YES for all 14 classes -- every one wrote the refused value back BYTE-IDENTICAL with nothing marked invalid. The `location` control in the same harness blocked the write and set aria-invalid, so the fourteen readings are a property of those classes and not an artifact. A second control direction (a spec-ACCEPTED value on 7 classes) came back identical, i.e. the surface makes no distinction at all. Three rows are worse than the card anticipated: lookup and user HYDRATE the refusing value into a friendly label (Northwind, Ada) so the field looks correctly filled; file/video/audio derive a filename from a retired external URL so it presents as a real attachment; address is the inverse -- it presents five EMPTY boxes and still re-saves the string, which FALSIFIES the card's guess that address may not have the property. READING (b): 129 stored values adjudicated by valueSchemaFor(def,'stored') from @objectstack/spec 17.2.0 (objectui's resolved version AND objectstack's workspace version are both 17.2.0, so one build of the contract judged both repos), 0 REFUSED in every class, 32/32 accept/refuse controls behaved as required in the same execution. Populations differ by three orders of magnitude and are reported per class: lookup 76 and master_detail 36 are substantive; vector 4, address/composite/record/repeater 2 each are thin; file/image/avatar/video/audio are N=1 each (all dogfood-matrix ids, id-shaped by construction); user and tree have NO measurable value at all and are reported as 'not a zero reading' rather than as clean. CONDITIONAL ESCALATION NOT TRIGGERED: every count is zero, so no needs-user-decision card is due under the registered condition, and no posture was chosen. ONE STRUCTURAL RESULT worth the PM's eye: AddressValueSchema is an all-optional zod z.object, which STRIPS unknown keys instead of refusing them, so the only address values the stored contract CAN refuse are non-objects -- a zero for address is close to unfalsifiable and is not evidence that stored addresses are well-formed (same weaker point for composite/record, which are z.record(z.string(), z.unknown())). Their disposition should rest on the schema question, not on a count. ZONE-2 ASSUMPTIONS: (1) branch list re-derived on my own base 30266cf -- required, minLength/maxLength (+legacy snake_case), min, max, pattern, email, url, authored validate, location, at index.tsx:2645 -- UNCHANGED, none of the four packages/fields landings touched it; (2) #6744's instrument read and reused rather than reinvented; (3) the producer claim VERIFIED (buildValidationRules at ObjectForm.tsx:705 / sectionFields.ts:131 feeds RHF's Controller, and the widget's error prop is fieldState.error?.message at form.tsx:2683) with ONE REFINEMENT -- form.tsx deletes the compiled `required` and composes its own live presence validator, so buildValidationRules produces every rule EXCEPT presence -- and ONE BOUNDARY: it is the producer on the FORM surface only; the inline-edit surface never calls it and never receives an error prop, filed as #6868.",
  "tests": "No code changed, so there is no gate union to report; what follows is the measurement evidence. (1) ROUND-TRIP PROBE, the reading-(a) instrument: a vitest file rendering a real ObjectForm per class, run through the shared lock -- `OS_VERIFY_LOCK_SLOT=dev-6812 bash /home/user/objectstack/scripts/pm/os-verify-lock.sh -c '... pnpm exec vitest run packages/plugin-form/src/__survey6812.probe.test.tsx --maxWorkers=2'` -- quoting the wrapper's own verdict line: 'VERDICT command-exit 0 - held the lock 14s - waited 15s', vitest 'Test Files 1 passed (1) / Tests 16 passed (16), Duration 13.32s'. The first attempt of this run was deliberately re-run because the command was a PIPELINE and the wrapper printed 'VERDICT batch-last-exit 0 - NOT A VERDICT ON THE WHOLE COMMAND'; the quoted verdict above is from the re-run with the parts joined by '&&'. Results were written to a file from inside the test, not to stdout, because this repo's vitest setup suppresses console output -- reading them off a silent stdout would have been a zero that measured nothing. The probe asserts nothing about correctness (every case asserts true); its OUTPUT is the reading. It resolves @object-ui/* through the root vitest alias to source (vitest.config.mts:285/297), so no build was needed and none of the unbuilt-ablation hazards apply. (2) HARNESS CONTROL, in the same run: `location` (the one class with a branch) gave update-call-count 0 and aria-invalid=true, proving the harness can see a refusal; a spec-ACCEPTED value on 7 classes gave wrote/unchanged/not-invalid, proving the 'wrote unchanged' readings are not specific to bad values. (3) ADJUDICATION SWEEP, the reading-(b) instrument: a Node script over both repos using the resolved @objectstack/spec/data, three precise joins (24 of 24 defineSeed calls joined to their object fields maps, 0 unjoined; same-document schema+data over 10,516 files; the self-typed dogfood field-zoo matrix), 875 dataset files inside that sweep. Output: 129 adjudicated, 0 refused, 3 non-static placeholders reported as not-adjudicable rather than counted; controls 32/32. (4) INDEPENDENT CROSS-CHECK: a deliberately over-inclusive key-paired pass over the dataset roots produced 147 hits and 30 refusals, EVERY ONE hand-classified and none a stored record value (25 i18n label maps, 5 flow templates refused only for a leading '{'); extended to both whole repos, every file-class and reference-class refusal in a dataset path is a permission matrix, an expand spec or a dashboard filter flag. The one value the precise joins had missed (account:'Northwind' inside a generated 24-row block) was found by this pass, is accepted, and was folded into the 76. (5) BOUNDARY, as #6744's ruling requires: customer deployments are not measurable from this container; every zero means 'zero within measurable scope', never 'does not exist'. (6) CLEANUP PROVEN: the probe file was deleted, `git status --short` prints nothing and `git diff HEAD --stat` is empty at HEAD 30266cf (= the recorded BASE), node_modules removed and the worktree removed WITHOUT --force.",
  "mcp_calls": "4 -- issue_read get + get_comments on #6812 and on #6744. Everything else went through repo-scoped REST via the proxy (issue listings for dedup, comment creation, issue creation, comment read-back), which was probed first and returned 200/201 from this seat.",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as objectstack#13388 (unassigned, no label): the app-showcase seed writes `showcase_field_zoo.f_address.postal_code`, a key AddressValueSchema does not declare -- the spec ACCEPTS the value and silently strips the key (all-optional z.object), and @object-ui/fields reads only `postalCode` (with a legacy `zipCode` limb), so the ZIP box renders empty in the app whose job is to show what each field type looks like. Deduped against 356 open objectstack issues with a control that must hit ('showcase seed' -> 6 hits); zero hits for postal_code / postalCode / f_address / AddressValueSchema.",
    "filed as objectui#6868 (unassigned, label `finding`): the inline-edit surface runs NO host-side validation -- InlineFieldInput (rendered by DetailSection and HeaderHighlight) never calls buildValidationRules and never receives an `error` prop, so the published #3222 slot has no producer there, including for `location`, the one stored-value rule the platform has. Found while verifying this card's own premise 3, and it bounds this card's readings to the FORM surface. Deduped against 249 open objectui issues with two controls that must hit (buildValidationRules -> #6812/#6366; '3222' -> #6812/#6803/#6778/#6776); zero hits for InlineFieldInput or inline-edit validation. Nearest neighbour #6803 checked and rejected as a duplicate: it is the consumer half (a widget not READING the slot) on the form surface."
  ]
}

Generated by Claude Code

Navigation Menu

Repository navigation

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

The fact

What is NOT claimed here

Suggested first step

Related

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

Survey — the two readings per ADR-0104 value-shape class

The instrument — #6744's, reused rather than reinvented

Reading (a) — does a widget hold a spec-refusing stored value and present it for re-save?

Reading (b) — how many spec-refusing values of each class exist in measurable datasets?

Population and how it was bounded

Controls — 32 of them, in the same execution, through the same call path

Per class

Independent cross-check (#6744's method B, adapted)

⚠️ Boundary, as #6744's ruling requires it stated

⭐ One structural result that changes what a zero can mean

Verification of the three PM assumptions

Disposition — no escalation is due

How to reproduce

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

The fact

What is NOT claimed here

Suggested first step

Related

Activity

os-project-manager commented on Aug 29, 2026

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

claude commented on Aug 30, 2026

claude commented on Aug 30, 2026

claude commented on Aug 30, 2026

Survey — the two readings per ADR-0104 value-shape class

The instrument — #6744's, reused rather than reinvented

Reading (a) — does a widget hold a spec-refusing stored value and present it for re-save?

Reading (b) — how many spec-refusing values of each class exist in measurable datasets?

Population and how it was bounded

Controls — 32 of them, in the same execution, through the same call path

Per class

Independent cross-check (#6744's method B, adapted)

⚠️ Boundary, as #6744's ruling requires it stated

⭐ One structural result that changes what a zero can mean

Verification of the three PM assumptions

Disposition — no escalation is due

How to reproduce

claude commented on Aug 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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