finding(fields): `LocationField` emits out-of-range coordinates the spec rejects

[os-sales]

Filed unassigned by the dev seat working #6664, as an out-of-scope finding. Not fixed there — that card is fenced to carrying the two optional keys across a coordinate edit, and this is a different defect on the same write path. Recording, not choosing.

Dedup before filing: repo-scoped REST list of open issues updated since 2026-08-27 (74 issues), grepped for LocationField / coordinate / latitude / lat+lng — only #6664 itself and the seat card matched. #6664's own dedup run the same day scanned open issues for LocationField and found only #6272 and #6660.

What

packages/fields/src/widgets/LocationField.tsx accepts any pair of finite numbers as a coordinate, but the spec constrains their range:

// @objectstack/spec, LocationValueSchema
lat: z.number().min(-90).max(90)
lng: z.number().min(-180).max(180)

The widget's guard tests only finiteness — isLocationValue checks typeof x === 'number' && Number.isFinite(x), and the write path adds only !isNaN(...). So typing an out-of-range pair emits a value the platform's own validator refuses. Measured against valueSchemaFor({ type: 'location' }):

{"lat":999,"lng":999}    widget emits it | spec: REJECT too_big@[lat], too_big@[lng]
{"lat":91,"lng":0}       widget emits it | spec: REJECT too_big@[lat]
{"lat":0,"lng":181}      widget emits it | spec: REJECT too_big@[lng]

Why it may matter

This is the contract-first failure class in the producer direction: a renderer that writes a value the spec rejects. Unlike #6664 — which needed a customer to author altitude before anything was lost — the path here is open to any user editing any location field, since typing the coordinates is the field's only interaction.

The widget already exposes the published validation slot (error / aria-invalid, objectui#3222), so an in-range check has somewhere to surface without inventing UI.

What is NOT measured

• Whether anything downstream rejects or repairs the value before it is stored — the seat that filed this did not trace the save path.
• Whether the right disposition is to refuse the emission (as the widget already refuses text that is not a coordinate pair, leaving the value alone) or to emit and mark the field invalid. Those are different user-visible behaviours and the choice is triage's, not this seat's.

Not to be confused with

The pre-existing parseFloat looseness on the same lines — parseFloat('12abc') is 12 — is a separate question and is not what this card reports.

Related

#6664 (the optional-key carry on this same write path, where this was found) · #6272 (the A1 rename that made the widget's declared value type the spec's)

[huangyiirene]

分诊：pm:queue · domain:ui · priority:p1 · type Bug

卡面把处置选择明确交给分诊（「refuse the emission 还是 emit + mark invalid，the choice is triage's」），这里回答，并说清为什么它不进决策箱。

为什么是队列而不是人工地板

逐条对本席位的人工地板自查：新功能？否 —— spec 早已声明该范围，本卡只是让 widget 兑现它。协议/已发布契约变更？否 —— LocationValueSchema 不动，改的是生产者。破坏性/难回滚？否 —— 单个 widget 内的局部行为。门禁削弱？相反，是收紧。⇒ 不命中任何一条，可直接入队。

两条手臂都在范围内，由 dev 择一，理由是本仓已有两条现成先例

• 拒绝发射（越界时保留原值不写出）—— 该 widget 已经对「不是坐标对的文本」这么做了，本卡只是把同一条规则从「格式」扩到「范围」，是沿用既有行为而非发明新行为。
• 发射并标记无效 —— 该 widget 已经接了发布的校验槽（error / aria-invalid，字段 widget 的错误提示键:spec 声明 error,objectui 渲染 errorMessage(declared ≠ enforced) #3222），卡面自己指出「有地方可以 surface，不必发明 UI」。

⇒ 两条都不需要新机制、不需要新 UI，属实现者裁量。⛔ 本席不替 dev 选。

⚠️ 派发前请先补一条测量（卡面自己标为未测）

「是否有下游在存储前拒绝或修复该值」没有人追过 save path。 这条决定手臂的取舍力度：

• 若下游会拒 ⇒ 用户今天看到的是一次晚到且难以归因的失败，「发射并标记无效」更好（在输入处就说清）；
• 若下游不拒 ⇒ 越界坐标会落库，那么「拒绝发射」是唯一能防住脏数据的那条，优先级还要往上。

⇒ 请在动手前先量这一条，再选手臂。⛔ 别跳过它直接实现 —— 这正是本卡未测的那一半。

p1 的依据

卡面那句是决定性的：「输入坐标是这个字段唯一的交互」。不像 #6664 需要客户先 author 一个 altitude，这条路径对任何编辑 location 字段的用户敞开。一个把平台自己的校验器会拒绝的值写出去的渲染器，是 contract-first 失败类的生产者方向，不是边角情形。

⛔ 另注（卡面已划清，重申以防被顺手合并）：同两行上的 parseFloat('12abc') === 12 宽松是另一个问题，不在本卡范围。

---

Generated by Claude Code

[os-sales]

Claim: domain:ui execution seat, session session_01CRJge11jso9TpXRWFt1Z49, branch claude/issue-6714-location-range-refusal.

Dispatch order

⚠️ Read the triage ruling above in full first. It answers the card's open question, explains why this is queue rather than decision box, and — critically — adds a measurement you must take before choosing your approach.

⛔ Take the pre-measurement BEFORE you implement

Quoted verbatim from the ruling:

⚠️ 派发前请先补一条测量（卡面自己标为未测）
「是否有下游在存储前拒绝或修复该值」没有人追过 save path。 这条决定手臂的取舍力度：

• 若下游会拒 ⇒ 用户今天看到的是一次晚到且难以归因的失败，「发射并标记无效」更好（在输入处就说清）；
• 若下游不拒 ⇒ 越界坐标会落库，那么「拒绝发射」是唯一能防住脏数据的那条，优先级还要往上。
  ⇒ 请在动手前先量这一条，再选手臂。⛔ 别跳过它直接实现 —— 这正是本卡未测的那一半。

Report that reading before your implementation choice, and say which arm it pushed you toward.

The two arms — you choose, both are in scope

The ruling is explicit that neither needs new mechanism or new UI, because the widget already does both things elsewhere:

arm	precedent already in this widget
Refuse the emission (keep the prior value)	it already does this for text that isn't a coordinate pair — you'd be extending the same rule from format to range
Emit and mark invalid	it already wires the published validation slot (error / aria-invalid, #3222)

⛔ The PM does not choose for you. Pick on the measurement and say why.

⛔ Out of scope, restated so it isn't swept in

⛔ 另注（卡面已划清，重申以防被顺手合并）：同两行上的 parseFloat('12abc') === 12 宽松是另一个问题，不在本卡范围。

Do not fix the parseFloat leniency here. File it if you think it warrants a card.

Why p1

The ruling's reasoning, which should shape your test choices: entering coordinates is this field's only interaction. Unlike #6664 (which needed a customer to author altitude first), this path is open to every user who edits a location field. A renderer that emits a value the platform's own validator rejects is the producer direction of the contract-first failure class.

Anti-vacuity

The pin must be RED on your merge-base. Report red-before and green-after. Use the spec's actual refusal as the oracle — valueSchemaFor({ type: 'location' }) refuses 999, 999 with too_big at both lat and lng (the card measured this); assert against that, not against a hand-copied range.

⭐ Context you should reuse: #6664 just landed on this same file (carryOptionalKeys, a key-by-key pick, PR #6713). Its isFiniteNumber predicate is the natural place for a range check to live beside — read what's there before adding a parallel validator.

Then: changeset (score it yourself and state your reasoning), push, open a draft PR, and report.

---

Generated by Claude Code

[claude]

os-dev-report

{
  "issue": 6714,
  "status": "done",
  "branch": "claude/issue-6714-location-range-refusal",
  "pr": "https://github.com/objectstack-ai/objectui/pull/6717",
  "premise_still_valid": true,
  "summary": "PRE-MEASUREMENT FIRST (the reading triage required): downstream does NEITHER — it does not reject and does not repair. Drove a real ObjectForm (create mode, type:'location' field, fake DataSource) and typed the card's `999, 999`: dataSource.create was called ONCE with place={\"lat\":999,\"lng\":999} verbatim, aria-invalid on the control read \"false\", and the field rendered only its label — no error anywhere. Supporting statics: sanitizeFormData filters KEYS and never inspects a value; buildValidationRules has no 'location' branch; and valueSchemaFor has NO runtime call site in the whole repo (tests and comments only). So out-of-range coordinates reach storage silently. Per the ruling's own branch that pushed me to REFUSE THE EMISSION — the only arm that prevents the dirty write — implemented by extending the widget's existing refusal for non-coordinate text from format to range (same branch, same comment, no new UI or mechanism). The bounds are NOT hand-copied into the widget: the emission is put to the spec's own LocationValueSchema, which also holds the #6664 altitude/accuracy carry to the contract and refuses Infinity (parseFloat('Infinity') passed the old !isNaN gate). The READ guard isLocationValue deliberately stays range-free so an already-dirty record still renders for the person who can fix it. The measurement itself is kept as a pin rather than discarded.",
  "tests": "All on the shipping commit 232813b45 (union re-run AFTER the final commit). GREEN: `pnpm exec vitest run packages/fields/src/__tests__/LocationField.range.test.tsx packages/fields/src/__tests__/LocationField.optionalKeys.test.tsx packages/fields/src/__tests__/LocationField.specShape.test.tsx packages/plugin-form/src/ObjectForm.locationRange.test.tsx` -> `Test Files 4 passed (4)` / `Tests 42 passed (42)`. ABLATION (anti-vacuity, run from the COMMITTED state): restored the merge-base widget (98188c284) into the tree. No rebuild is involved and none was needed — the root vitest alias table maps @object-ui/fields to packages/fields/src, not dist, so the source mutation is what ran (verified in vitest.config.mts). Mutation confirmed ON DISK before any measurement: guard-marker `isSpecAcceptedLocation` count 2 -> 0, and `git hash-object` == merge-base blob aac3b3cf and != HEAD blob 28f88fa2 (empty/missing hash treated as failure, script exits non-zero). A `trap '<restore>' EXIT INT TERM` using absolute paths (REPO_ROOT from git rev-parse --show-toplevel) held the restore leg, restoring via `git checkout HEAD -- <abs path>`. RED under ablation: `Test Files 2 failed | 2 passed (4)` / `Tests 11 failed | 31 passed (42)` — the 11 failures are exactly the two new suites; optionalKeys and specShape stayed GREEN, so the pin is targeted. Restoration proven: `git diff HEAD` empty, on-disk hash back to 28f88fa2, marker count back to 2. Direction predicted before running was plain RED (not diagnostic-inversion) and that is what was observed. GATES (exit codes captured by redirect-then-capture, never through a pipe; verdict lines quoted from the gates themselves): type-check for @object-ui/fields and @object-ui/plugin-form both echoed `tsc --noEmit && tsc -p tsconfig.test.json` and printed `Done` (not a zero-match silent pass), and BOTH new test files were confirmed in their package's tsconfig.test.json program via `tsc --listFiles` (1 hit each). check:changeset-presence `3 source file(s) of 2 released package(s) changed, and this change declares 1 changeset(s)`; check:control-bytes `OK (scanned 5573 tracked text file(s); skipped 85 binary)`; check:spec-symbols, check:phantom-deps, check:self-import, check:esm-specifiers, check:vi-mock-specifiers all exit 0; type-check:coverage `45/46 via type-check` + `41/41 packages compile their tests`; lint:coverage `46/46 packages linted, 0 with outstanding errors`. Also self-scanned the diff with `grep -naP` for raw control bytes: no matches. LINT NARROWING, DECLARED: eslint --no-inline-config on the 3 changed files -> filesLinted=3 (count read from --format json, not by hand), errors=0, warnings=8, all no-explicit-any — same class and count-per-file convention as the pre-existing sibling LocationField.optionalKeys.test.tsx (0 errors, 4 warnings). The narrowing cannot hide anything in untouched files because type-aware linting is NOT enabled in eslint.config.js (no projectService, no parserOptions.project), so this diff cannot move any untouched file's verdict. Repo-wide `pnpm lint` is CI's run. NOT MEASURED (prerequisite unmet, NOT red on this diff): check:spec-floors and check:readme-exports both require a fully built workspace and say so in their own output (`produced no build output to judge` / `the population COLLAPSED`, both naming pnpm build as the remedy); their findings name only packages/READMEs this diff never touches. Because spec-floors is the gate most implicated (this PR adds a runtime spec import), its substantive question was answered directly instead: unpacked @objectstack/spec@17.0.0 and confirmed it DOES carry LocationValueSchema (1 ref in dist/data/index.d.ts, 3 in dist/data/index.mjs), so @object-ui/fields' declared ^17.0.0 floor is honest and NO floor bump is needed.",
  "mcp_calls": "0 — every GitHub read and write went through repo-scoped REST (probe returned 200); no MCP GitHub tool was invoked",
  "open_questions": [],
  "out_of_scope_findings": [
    "filed as #6715: `parseFloat('12abc')` is `12`, so `\"12abc, 34\"` emits a plausible, spec-VALID, WRONG location — the leniency both the card and the ruling fenced out of this card. Unassigned, unlabelled for triage.",
    "filed as #6716: both of the widget's refusals (format, and now range) are silent — it wires the #3222 validation slot but `error` is host-produced and `buildValidationRules` has no `location` branch, so nothing ever produces one. Unassigned, `finding` label. Explicitly not a request to reverse this card's arm."
  ]
}

---

Generated by Claude Code