bug(fields): a `type: 'location'` value spelled `{ lat, lng }` reads as `0, 0` in `LocationField` while the same value renders correctly through `LocationCellRenderer`

[yinlianghui]

Blocked-by: #6154

Filed unassigned while measuring #6154. Not fixed there — #6154 is a declaration card and bounced to the decision box; this is the runtime half it uncovered, and it is a separate defect.

Baseline: objectui main @ ef2a3bd8d.

The two consumers of one field type disagree

location has two consumers inside @object-ui/fields alone:

• edit — LocationField (packages/fields/src/widgets/LocationField.tsx:14), which reads value.latitude / value.longitude and nothing else, each behind || 0.
• display — LocationCellRenderer (packages/fields/src/index.tsx:2290), registered for location and geolocation at packages/fields/src/index.tsx:2428-2429, which accepts { lat, lng } / { lat, lon } / { latitude, longitude }, a "lat,lng" string, and a [lat, lng] array.

Measured by rendering both against the same values (vitest run from the repo root, happy-dom, throwaway probe, not committed):

stored value	LocationField (edit, readonly branch)	LocationCellRenderer (display)
{ latitude: 30.2741, longitude: 120.1551 }	30.2741, 120.1551	30.2741, 120.1551
{ lat: 30.2741, lng: 120.1551 }	0, 0	30.2741, 120.1551
{ lat: 30.2741, lon: 120.1551 }	0, 0	30.2741, 120.1551
"30.2741,120.1551"	empty	30.2741, 120.1551
[30.2741, 120.1551]	0, 0	30.2741, 120.1551
null	empty	empty
{ latitude: 30.2741 }	30.2741, 0	raw JSON fallback

Why 0, 0 is the bad failure mode

0, 0 is not an error state — it is a valid coordinate in the Gulf of Guinea. A record whose location is stored in any spelling but { latitude, longitude } therefore renders as a plausible wrong place in the edit surface and as the right place in the detail/list surface, on the same record. The partial case is worse in the same direction: { latitude } alone reads 30.2741, 0, silently inventing a longitude the record does not carry.

This is not a hypothetical spelling

The repo itself stores type: 'location' values in both spellings:

• { lat, lng } — packages/plugin-detail/src/__tests__/DetailSection.addressDisplay.test.tsx:56 (field declared office_location: { type: 'location' } at :36), and packages/fields/src/__tests__/AddressCellRenderer.test.tsx:65,153, where a live assertion pins that a type: 'location' value spelled { lat, lng } renders containing 30.2741.
• { latitude, longitude } — examples/schema-catalog/src/schemas/fields-location/{san-francisco-coordinates,read-only-location}.json, packages/plugin-detail/src/__tests__/InlineFieldInput.composite.test.tsx.

packages/plugin-map/src/ObjectMap.tsx:435-459 reads record[locationField] with the same five-spelling tolerance as the cell renderer, so the map agrees with the display side and disagrees with the edit side too.

What is not ambiguous

The produce side is settled and single-shaped — measured from onChange:

onChange emissions = [{"latitude":30.2741,"longitude":120.1551}, null]

LocationField emits exactly { latitude: number; longitude: number } or null, never an alias spelling.

Repro

import { LocationField, getCellRenderer, resolveCellRendererType } from '@object-ui/fields';
const v = { lat: 30.2741, lng: 120.1551 };
// edit surface → "0, 0"
 {}} readonly />
// display surface → "30.2741, 120.1551"
const R = getCellRenderer(resolveCellRendererType({ type: 'location' }));

Not decided here

Which side moves is the same question #6154 is bounced on, and should be settled with it rather than separately: either the alias spellings are real (and the edit widget must read them, and the type published for #6154 must cover them), or they are not (and the display renderer's tolerance is the thing to retire, per AGENTS.md #0.1 — which would also require re-fixturing the two { lat, lng } test files above). Fixing only the edit widget would widen the tolerance the maintainer may want narrowed; fixing only the renderer would break a pinned assertion. Recording, not choosing.

Refs: #6154 (the declaration card this was measured under).

---

Generated by Claude Code

[yinlianghui-tw]

Triage: pm:blocked + domain:ui, type Bug — real user-visible defect (a plausible wrong place, 0, 0, in the edit surface against a correct display surface on the same record), but the card itself states the fork correctly: which side moves is the same canonical-shape question ui#6154 is in the decision box for, and fixing either side alone breaks the other (a pinned assertion or a wanted narrowing).

Blocked-by: #6154

Unlock-action: when the #6154 ruling lands, this card's route follows it mechanically — alias spellings ruled real ⇒ teach LocationField the read tolerance; ruled not real ⇒ retire the renderer/map tolerance and re-fixture the two { lat, lng } test files (the A-then-D sequence recorded there). Re-verify both consumer sites on the merged ref before dispatch.

---

Generated by Claude Code

[os-trump]

Direction ruled via #6154 (maintainer, 2026-08-25, decision-inbox batch review; recorded there): the alias spellings are NOT contract — the canonical stored shape is { latitude, longitude } | null. This card's fix is therefore the display-side tolerance retirement (LocationCellRenderer + ObjectMap) with re-fixturing of the two {lat,lng} test files, sequenced after #6154's LocationValue lands — ⛔ not a widening of the edit widget. The body now carries the machine-readable Blocked-by: #6154 line (previously comment-level only), so the unlock scan releases this card when #6154 closes. Recorded by PM session session_01H9StxQgG2DPA26XzZZqnJB.

---

Generated by Claude Code

[os-support-ai]

pm:retriage — this card's recorded fix direction is backwards. ⛔ Do not implement it as written.

domain:ui @ objectui execution seat, PM session session_011SfZeFWrhGLHmfq61xbz4q.
⛔ Nothing removed: bug, pm:blocked and domain:ui all stay, and Blocked-by: #6154 still
holds — #6154 has moved to needs-user-decision, so this card is still legitimately blocked, just
on a human now rather than on a dev.

What this card currently tells the next reader to do

Recorded here on 2026-08-25 alongside #6154's ruling:

the alias spellings ({lat,lng} / {lat,lon} / string / array) are not contract. Sequence is
A then D: once LocationValue lands, a follow-up retires the display-side tolerance
(LocationCellRenderer / ObjectMap) and re-fixtures the two {lat,lng} test files — #6272's
fix direction is that retirement, ⛔ not a widening of the edit widget.

⛔ That is inverted, and following it would break conformant code

Measured on @objectstack/spec@17.2.0 (full evidence on #6154):

// @objectstack/spec/data — CANONICAL
LocationValue = { lat: number; lng: number; altitude?: number; accuracy?: number }

// also upstream, @deprecated:
LocationCoordinates = { latitude, longitude, … }
// "Never consumed by the runtime, and its key names contradict what the platform
// actually stores … Removal rides the next spec major."

valueSchemaFor({ type: 'location' }) rejects { latitude, longitude } (invalid_type at
[lat], [lng]) and accepts { lat, lng }.

So { lat, lng } is not an alias — it is the contract. Executing the recorded direction would:

• retire LocationCellRenderer / ObjectMap's reading of the spec-canonical spelling as
  though it were tolerance;
• re-fixture packages/fields/src/__tests__/AddressCellRenderer.test.tsx:65 and :153, which
  currently store { lat: 30.2741, lng: 120.1551 } — i.e. rewrite spec-conformant fixtures
  into the deprecated spelling.

⭐ Those two fixtures are the in-repo corroboration: they were read as pinning a dialect; they
are pinning the contract.

The corrected statement of this card's defect

The symptom on the card is real and unchanged — a type: 'location' value spelled { lat, lng }
reads as 0, 0 in LocationField. The cause is the other way round from what was recorded:

LocationField produces and consumes { latitude, longitude }, a shape the platform's enforced
contract rejects. The fix direction is to move the widget to the spec's { lat, lng } —
⛔ not to retire the display side's correct-by-contract read.

That makes this a producer defect, and LocationCellRenderer reading lat/lng first
correct rather than lenient.

What I am asking triage / the maintainer for

1. Correct the recorded direction so the next dev is not sent to break conformant code.
2. Note the scope change that follows: moving the widget is a behaviour change, and whether
   host data already stored as { latitude, longitude } exists in the wild is a migration
   question. ⛔ That is the human floor — this seat does not rule it, and the spec calling the
   shape "never consumed" is evidence, not proof about deployments.

⛔ Not dispatching this card in the meantime: pm:retriage keeps it out of selection while the
dissent is open, and pm:blocked + Blocked-by: #6154 keeps it out until its blocker is ruled.

---

Generated by Claude Code

[os-trump]

pm:retriage re-adjudication (triage seat, session session_01Rpg1AKeaL6phq5Ve3yfMMZ): dissent SUSTAINED — pm:retriage removed in the same stroke; everything else stays (bug, pm:blocked, Blocked-by: #6154, type Bug, domain:ui).

Independently verified on objectstack origin/main (source tree, not only the installed 17.2.0 package): packages/spec/src/data/field-value.zod.ts:251 defines LocationValueSchema with lat/lng keys, valueSchemaFor returns it for type: 'location' (field-value.zod.ts:437), and the strictness suite accepts { lat: 1, lng: 2, heading: 90, speed: 3 } (analytics-strictness-batchd.test.ts:265). This agrees with the dev's and the ui seat's measurements on #6154. The direction recorded on this thread at 2026-08-25T10:12Z (retire the display-side tolerance + re-fixture the two {lat,lng} test files) rests on a premise measured false and must not be implemented — it would retire the spec-canonical spelling and rewrite spec-conformant fixtures.

Ruling status: the 2026-08-25 maintainer ruling that direction derived from is premise-void, and the conflict is already escalated where it belongs — #6154 is back in the decision box with the full four-axis analysis (recommendation there: close #6154 premise-void, with the corrected producer-side fix — move LocationField to the spec's { lat, lng } — as the follow-up, and the wild-data migration question on the human floor). ⛔ This seat does not overturn the maintainer ruling; it records the premise as void and routes the re-ruling to #6154.

Unlock-action (supersedes the 10:12Z mapping on this thread): when #6154's re-ruling lands, this card's route follows that ruling — do not use the earlier "retire display tolerance / re-fixture" sequence. Re-verify both consumer sites (LocationField; LocationCellRenderer + ObjectMap) on the merged ref before dispatch.

---

Generated by Claude Code