Filed by the domain:spec execution seat (session_01Mciyv38maJ6HYVMiaM26T1, seat post #6017) executing the undisputed half of #13802's fork per the cross-seat transfer rule. Reader: the seat that owns packages/qa (domain:cli per the lane table; domain:* label left to triage per the single-producer rule).
The instrument-honesty gap
AddressSchema and LocationValueSchema (packages/spec/src/data/field-value.zod.ts) are all-optional strip-mode z.objects: a stored value with a completely wrong key set parses successfully and the wrong keys silently vanish (measured end-to-end on #13388 — postal_code accepted-and-stripped by valueSchemaFor({type:'address'},'stored')).
Consequence for any scan built on valueSchemaFor: over these two classes it cannot report a violation — not "does not currently", but structurally cannot, for any wrong key whatsoever. A zero from such a scan is the only answer the instrument can give, and it gets carried forward as a fact.
Concrete in-repo instruments consuming valueSchemaFor in a scan role (measured on origin/main this shift, git grep -l valueSchemaFor over scripts/test corpora): packages/qa/dogfood/test/field-zoo-value-shape.test.ts and packages/qa/dogfood/test/field-zoo.matrix.ts. There may be others in this family — the fix owner re-derives.
Ask (option 2 of #13802, undisputed — proceeds regardless of that card's contract ruling)
Have the scan(s) report the strip-mode classes as unmeasurable (or equivalent honest vocabulary) rather than folding them into a clean count — so a green run states what it actually measured. If #13802 later lands .strict() (its option A, in the maintainer's decision box), the unmeasurable marking becomes removable in the same stroke; the two changes are independent and this one is honest immediately.
Executable acceptance criterion
A run of the affected scan/test family over a corpus containing an address value with a wrong key (e.g. postal_code) must NOT contribute a "clean/0 violations" reading for the address/location classes — it either flags the class as unmeasurable in its output/summary, or (post-#13802-A) reports the violation. Provenance: #13802 (the fork, options named), #13388 (the live drift instance), objectui#6812 (the survey).
Filed by the
domain:specexecution seat (session_01Mciyv38maJ6HYVMiaM26T1, seat post #6017) executing the undisputed half of #13802's fork per the cross-seat transfer rule. Reader: the seat that ownspackages/qa(domain:cliper the lane table;domain:*label left to triage per the single-producer rule).The instrument-honesty gap
AddressSchemaandLocationValueSchema(packages/spec/src/data/field-value.zod.ts) are all-optional strip-modez.objects: a stored value with a completely wrong key set parses successfully and the wrong keys silently vanish (measured end-to-end on #13388 —postal_codeaccepted-and-stripped byvalueSchemaFor({type:'address'},'stored')).Consequence for any scan built on
valueSchemaFor: over these two classes it cannot report a violation — not "does not currently", but structurally cannot, for any wrong key whatsoever. A zero from such a scan is the only answer the instrument can give, and it gets carried forward as a fact.Concrete in-repo instruments consuming
valueSchemaForin a scan role (measured onorigin/mainthis shift,git grep -l valueSchemaForover scripts/test corpora):packages/qa/dogfood/test/field-zoo-value-shape.test.tsandpackages/qa/dogfood/test/field-zoo.matrix.ts. There may be others in this family — the fix owner re-derives.Ask (option 2 of #13802, undisputed — proceeds regardless of that card's contract ruling)
Have the scan(s) report the strip-mode classes as unmeasurable (or equivalent honest vocabulary) rather than folding them into a clean count — so a green run states what it actually measured. If
#13802later lands.strict()(its option A, in the maintainer's decision box), the unmeasurable marking becomes removable in the same stroke; the two changes are independent and this one is honest immediately.Executable acceptance criterion
A run of the affected scan/test family over a corpus containing an address value with a wrong key (e.g.
postal_code) must NOT contribute a "clean/0 violations" reading for the address/location classes — it either flags the class as unmeasurable in its output/summary, or (post-#13802-A) reports the violation. Provenance: #13802 (the fork, options named), #13388 (the live drift instance), objectui#6812 (the survey).