finding(fields): `LocationField` drops the spec's optional `altitude` / `accuracy` when a user edits the coordinate pair

[os-sales]

Filed unassigned by the dev seat working #6272 (branch claude/issue-6272-locationfield-spec-flip), as an out-of-scope finding. Not fixed there — #6272 implements the maintainer's 2026-08-28 A1 ruling, which is a bare rename at both ends of the widget and nothing else. Recording, not choosing.

Dedup run before filing: an open-issue scan for altitude / accuracy / LocationField found only #6660 (the docs half of #6272, which merely quotes the value shape) and #6272 itself. No card covers this.

What

@objectstack/spec@17.2.0 declares the canonical stored shape as

LocationValue = { lat: number; lng: number; altitude?: number; accuracy?: number }

LocationField (packages/fields/src/widgets/LocationField.tsx) edits the pair as one comma-separated text box, and its onChange builds a fresh object from the parsed text:

onChange({ lat, lng });

So a stored { lat, lng, altitude, accuracy } — every key of which the spec's valueSchemaFor({ type: 'location' }) accepts — loses altitude and accuracy the moment a user retypes the coordinates. Nothing warns; the two keys simply are not in the emitted object.

Why it is filed now rather than fixed in #6272

The drop is pre-existing, not introduced by #6272: before that card the widget emitted { latitude, longitude } and discarded everything else just the same. What #6272 changes is only that the widget's declared value type is now the spec's, so the type says the widget handles four keys while the write path handles two. That is a mismatch worth a decision, but it is a different decision from the one the A1 ruling made, and widening #6272's atomic fence to take it would have been scope creep on a card that was explicitly fenced to the rename.

What is NOT yet measured

Deliberately left for triage, because the answer changes whether this is worth fixing at all:

• Is there a producer? Nothing in objectui writes altitude or accuracy for a type: 'location' value that this seat found. If no producer exists in the platform either, the population is empty today and this is an implementation-first key rather than a live defect.
• Is there a consumer? LocationCellRenderer and ObjectMap read lat/lng only, so neither surface would show the loss.

If both answers are "no", the honest disposition may well be to close this rather than to write code for it — that judgement is triage's, not this seat's.

If it is taken

The fix is small and does not reintroduce any dialect: carry only the two spec-declared optional keys forward from an already-valid value, e.g. keep altitude / accuracy from the incoming value when it is a valid LocationValue. ⛔ It must not be written as a wholesale spread of the incoming value — that would carry a deprecated latitude / longitude key straight back into the emitted object and undo #6272.

[huangyiirene]

定级：Bug · priority:p2 · domain:ui · pm:queue

中央分诊席位，session session_01Aujz2zykf5LXt3T98gRsGe。落点 packages/fields/src/widgets/LocationField.tsx ⇒ 发布库 ⇒ domain:ui。

---

⭐ 卡留给分诊的两个测量，我做了 —— 答案不是它设想的二分

卡写：「If both answers are "no", the honest disposition may well be to close this rather than to write code for it — that judgement is triage's.」

丢弃点确认   packages/fields/src/widgets/LocationField.tsx:85   onChange({ lat, lng });

生产者 · objectui     → 无
  唯一两处 altitude 命中：metadata-viewer.tsx:232 是无关比喻（"altitude projection"）；
                        LocationField.tsx:12 是它自己的文档注释在引用形状
生产者 · objectstack  → 无
  全部 altitude 命中都是 "at different altitudes" 这类比喻

⇒ 平台内确实没有生产者。⛔ 但这不足以关卡，因为还有第三条读数：

⭐ objectstack packages/spec/authorable-surface.base.json:3438  "data/LocationCoordinates:altitude"
                                                        :3442  "data/LocationValue:altitude"

⇒ ⭐ 该键被登记在「可编写面」注册表里 —— 也就是说 客户可以自己写它。

⇒ 正确的处置：不是关卡，也不是"实现优先的键"

卡的二分是「平台是否生产它」。⚠️ 但真正决定人群的是「客户是否编写它」，而后者：

• 本席位测不了（客户元数据不在这两个仓里）；
• ⭐ 且平台已经通过 authorable-surface 注册表向客户承诺了它可编写。

⇒ ⭐ 一旦有客户写了 altitude，他重新输入一次坐标就会静默丢掉它。 这不是"实现优先的键"，是一个已承诺可编写、却在编辑路径上被静默丢弃的键。

⇒ 定 p2 而非 p1，因为人群未知；⛔ 定 pm:queue 而非关卡，因为承诺已经作出。

---

⚠️ 取卡者围栏 —— 卡给的修法约束必须逐字执行

The fix is small and does not reintroduce any dialect: carry only the two spec-declared optional keys forward from an already-valid value.
⛔ It must not be written as a wholesale spread of the incoming value — that would carry a deprecated latitude / longitude key straight back into the emitted object and undo #6272.

⭐ 这条禁令是本卡最重要的一句，⛔ 一个字都不要改：整体 spread 会把已废弃的 latitude/longitude 原样带回发出的对象，直接撤销 #6272 刚做完的重命名。

• ⭐ 只从"已经是合法 LocationValue"的入参里，逐个取 altitude / accuracy 两个键。⛔ 不是 spread，⛔ 不是 Object.assign。
• ⚠️ 验收要带一个负对照：构造一个带 latitude/longitude 的旧方言输入，断言发出的对象不含这两个键。⛔ 没有这条，禁令就没有守卫。
• ⛔ 不得顺手让 LocationCellRenderer / ObjectMap 显示这两个键 —— 卡已测出它们只读 lat/lng；那是功能新增，另立卡。

⭐ 为公道起见记一笔

这个丢弃是先于 #6272 就存在的（此前 widget 发的是 { latitude, longitude }，同样丢弃其余）。#6272 改变的只是声明的值类型现在是 spec 的 ⇒ 类型说 widget 处理四个键、写路径只处理两个。⭐ 那个 dev 没有把它塞进 #6272 的原子围栏，是正确的判断 —— A1 裁决明确只是两端重命名。

相关

#6272（A1 裁决的重命名，本卡的发现出处）· #6660（#6272 的文档半边，仅引用值形状）

---

Generated by Claude Code

[os-sales]

Claim: domain:ui execution seat, session session_01CRJge11jso9TpXRWFt1Z49, branch claude/issue-6664-location-field-preserve-altitude-accuracy.

Dispatch order

⚠️ Read the triage ruling comment above in full before touching code. It is not a grading note — it overturns the card's own suggested disposition and it sets a hard fence.

The card proposed closing itself. Its words: "If both answers are 'no', the honest disposition may well be to close this rather than to write code for it." Triage took both measurements the card asked for, and both came back "no producer" — in objectui and in objectstack alike. It still did not close. A third reading decided it:

objectstack packages/spec/authorable-surface.base.json:3438  "data/LocationCoordinates:altitude"
                                                      :3442  "data/LocationValue:altitude"

⇒ the key is registered on the authorable surface. The platform has already promised customers they may write it. So the population that matters is not "does the platform produce it" but "does a customer author it" — unmeasurable from these two repos, and already promised. Hence pm:queue, and hence p2 rather than p1 (population unknown, promise made).

Do not re-derive that as a reason to narrow or close the card. It is settled.

The defect

packages/fields/src/widgets/LocationField.tsx:85 — onChange({ lat, lng }). Editing the coordinate pair silently drops the spec's optional altitude / accuracy.

⛔ The fence — execute the ruling's constraint literally

Quoted verbatim from the card, as the ruling requires:

The fix is small and does not reintroduce any dialect: carry only the two spec-declared optional keys forward from an already-valid value.
⛔ It must not be written as a wholesale spread of the incoming value — that would carry a deprecated latitude / longitude key straight back into the emitted object and undo #6272.

And the triage seat's amplification, verbatim:

⭐ 这条禁令是本卡最重要的一句，⛔ 一个字都不要改：整体 spread 会把已废弃的 latitude/longitude 原样带回发出的对象，直接撤销 #6272 刚做完的重命名。

Concretely:

• ⛔ Not a spread. ⛔ Not Object.assign. Pick the two keys by name, individually, from a value that is already a valid LocationValue.
• ⚠️ The acceptance test needs a negative control, and without it the prohibition has no guard: construct an old-dialect input carrying latitude/longitude, and assert the emitted object does not contain those keys. The ruling is explicit — ⛔ 没有这条，禁令就没有守卫.
• ⛔ Do not make LocationCellRenderer or ObjectMap display the two keys. Triage measured that they read only lat/lng. Adding display is a feature, and it belongs on its own card. If you think it is needed, say so in the report; do not write it.

Anti-vacuity

The positive test (edit coordinates, altitude/accuracy survive) must be RED on your merge-base before your fix. Report red-before and green-after. The negative control above should be green both before and after — say so explicitly, and say why that is the correct reading rather than a vacuous one: it guards against a future regression toward the spread, not against today's code.

Context worth carrying into the PR

The drop predates #6272 — the widget previously emitted { latitude, longitude } and discarded the rest just the same. What #6272 changed is that the declared value type is now the spec's, so the type says the widget handles four keys while the write path handles two. Triage explicitly recorded that the #6272 dev was right not to fold this into that PR's atomic fence, since the A1 ruling covered only the two-sided rename. Keep that framing: this is a pre-existing drop made visible by a correct earlier change, not a regression that change introduced.

Reporting

Report the red-before/green-after on the positive pin, the negative-control reading with your reasoning, confirmation that no spread was used, and your changeset score with reasoning.

Refs: #6272 (the A1 rename, where this was found) · #6660 (its docs half).

---

Generated by Claude Code