Filed unassigned by the domain:ui execution seat (PM session session_01CRJge11jso9TpXRWFt1Z49), mirroring a measurement made by the #6716 implementer during its feasibility probe. Recording, not choosing. domain:*, type and grading are triage's to produce.
Dedup before filing: repo-scoped semantic search for the stored-value/no-location-branch shape returned zero. ⛔ A zero is not a reading on its own, so it was reverse-checked with a term known to exist — a LocationField query returns the whole family (#6715, #6716, #6714, #6664, #3343), none of which is this. The zero stands.
The fact
buildValidationRules (packages/fields/src/index.tsx:2551 on faac0d935) has no branch for location. It is the producer of the host-side error prop that every field widget's published objectui#3222 slot reads. So a location value that is already stored and violates the spec's coordinate range is never validated on an edit form: the control renders it, nothing marks it invalid, and submitting re-writes it unchanged.
This is a different defect from #6716. #6716 is about a refusal at INPUT time (the user types something the widget won't emit). This is about a value that is already in the record.
What was measured
During #6716's feasibility probe on faac0d935, a location branch was temporarily installed in buildValidationRules and driven through a real ObjectForm. On an edit form seeded with a stored { lat: 999, lng: 999 }:
- the validator received that object;
aria-invalid flipped to "true";- the message rendered through the form renderer;
- the write was blocked —
dataSource.update called 0 times.
(That run existed as a positive control proving the probe was sound, which is why it also stands as evidence here. The mutation landing and restore were both proven on disk — injected-marker count and blob hashes before/after, git diff HEAD empty afterwards. Nothing was committed.)
⇒ The branch is straightforwardly implementable and demonstrably effective on stored values.
⭐ Why this needs a decision rather than a patch — it moves a premise under a closed card
#6714 weighed "refuse the emission" against "emit and mark invalid" and chose refusal, on this premise: nothing downstream rejects or repairs the value, so an emission is a write.
The measurement above shows that with a location branch present, something downstream does reject — the submit is blocked. So #6714's premise is no longer true once this branch exists.
⛔ That is not an argument that #6714 should be reversed, and this card does not propose reversing it. The format arm settles that independently: there is no location value to emit for text like not a coordinate, so "emit and mark invalid" would mean writing a raw string into a typed location value — a worse contract violation than the one being fixed. The point is narrower and worth recording before someone re-derives it from scratch: the two changes interact, and landing this one silently changes the ground a closed ruling stood on.
⚠️ What is NOT measured — and why it is probably the deciding question
Nobody has counted whether out-of-range location values already exist in stored data. That number decides the shape:
- none ⇒ this is a cheap guard with no migration surface;
- some ⇒ adding the branch blocks edits on existing records until the coordinate is corrected. A user who opens a record they have always been able to save, and now cannot, is a migration-shaped consequence, not a validation improvement. That would need a decision about whether stored-data validation warns or blocks, and possibly a repair path.
Also not measured: whether other field types have the same stored-value gap in buildValidationRules. ⛔ This card is deliberately scoped to location — it is not a request for a validation-coverage census.
Related
Filed unassigned by the
domain:uiexecution seat (PM sessionsession_01CRJge11jso9TpXRWFt1Z49), mirroring a measurement made by the #6716 implementer during its feasibility probe. Recording, not choosing.domain:*,typeand grading are triage's to produce.Dedup before filing: repo-scoped semantic search for the stored-value/no-
location-branch shape returned zero. ⛔ A zero is not a reading on its own, so it was reverse-checked with a term known to exist — aLocationFieldquery returns the whole family (#6715, #6716, #6714, #6664, #3343), none of which is this. The zero stands.The fact
buildValidationRules(packages/fields/src/index.tsx:2551onfaac0d935) has no branch forlocation. It is the producer of the host-sideerrorprop that every field widget's published objectui#3222 slot reads. So a location value that is already stored and violates the spec's coordinate range is never validated on an edit form: the control renders it, nothing marks it invalid, and submitting re-writes it unchanged.This is a different defect from #6716. #6716 is about a refusal at INPUT time (the user types something the widget won't emit). This is about a value that is already in the record.
What was measured
During #6716's feasibility probe on
faac0d935, alocationbranch was temporarily installed inbuildValidationRulesand driven through a realObjectForm. On an edit form seeded with a stored{ lat: 999, lng: 999 }:aria-invalidflipped to"true";dataSource.updatecalled 0 times.(That run existed as a positive control proving the probe was sound, which is why it also stands as evidence here. The mutation landing and restore were both proven on disk — injected-marker count and blob hashes before/after,
git diff HEADempty afterwards. Nothing was committed.)⇒ The branch is straightforwardly implementable and demonstrably effective on stored values.
⭐ Why this needs a decision rather than a patch — it moves a premise under a closed card
#6714 weighed "refuse the emission" against "emit and mark invalid" and chose refusal, on this premise: nothing downstream rejects or repairs the value, so an emission is a write.
The measurement above shows that with a
locationbranch present, something downstream does reject — the submit is blocked. So #6714's premise is no longer true once this branch exists.⛔ That is not an argument that #6714 should be reversed, and this card does not propose reversing it. The format arm settles that independently: there is no location value to emit for text like
not a coordinate, so "emit and mark invalid" would mean writing a raw string into a typed location value — a worse contract violation than the one being fixed. The point is narrower and worth recording before someone re-derives it from scratch: the two changes interact, and landing this one silently changes the ground a closed ruling stood on.Nobody has counted whether out-of-range location values already exist in stored data. That number decides the shape:
Also not measured: whether other field types have the same stored-value gap in
buildValidationRules. ⛔ This card is deliberately scoped tolocation— it is not a request for a validation-coverage census.Related
LocationFieldrefuses input silently — the validation slot it wires has no producer #6716 — the input-time refusal card, where this was measured (its routing comment carries the full reading). Its fix is widget-local and deliberately does not touchbuildValidationRules, so the two do not collide.LocationFieldemits out-of-range coordinates the spec rejects #6714 — the closed card whose premise this moves.LocationFieldaccepts a partly-numeric coordinate, emitting a plausible wrong location #6715 — a thirdLocationFieldfinding (partly-numeric coordinates), still awaiting grading.