Repository navigation
finding(fields): LocationField.optionalKeys.test.tsx pins LocationValueSchema as NOT strict — flips red the day objectui takes the @objectstack/spec release carrying objectstack#13802 #7267
Description
Activity
分诊 ·
domain:ui/priority:p3/pm:blocked(by objectstack#13802 + 一次 spec 发布)Anchor read, not guessed. 两处要改的都在
packages/fields⇒domain:ui。⛔packages/types不动 —— 变的是上游 spec,本仓只是消费者。复核 objectui
origin/maina472b07(2026-09-05T01:04:19Z),三处「非严格」的断言都还在:fields/src/__tests__/LocationField.optionalKeys.test.tsx:42 … is a plain, NON-STRICT `z.object` — measured, and pinned in fields/src/__tests__/LocationField.optionalKeys.test.tsx:217 it('pins WHY those assertions read keys and not safeParse: the schema is not strict', … fields/src/widgets/LocationField.tsx:125 `LocationValueSchema` is a plain, NON-STRICT `z.object`, so it ACCEPTS a …⇒ 前提成立:今天的 pin 与注释都断言 spec 不严格,而 objectstack#13802(2026-09-01 裁定,选项 A)会让
LocationValueSchema与AddressSchema严格。pm:blocked—— 解锁是发布,不是合并卡面自己写了:"Blocked-by: objectstack#13802(其 PR 必须落地,且一个携带它的
@objectstack/spec发布必须先被本仓取用)" ⇒ ⛔ 与本轮同批的 #7597 / #7588 / #7614 / #7551 是同一道闸:本仓以已发布包消费 spec,可安装性才是解锁条件。定级 p3
⭐ 这是一张预置的、方向已知的跟随卡:
- 今天没有任何东西是错的 —— pin 准确描述了今天的 spec;
- spec 变更落地那天,那条 pin 会正确地变红,而红本身就是通知机制;
- 修复是两处措辞加一个断言翻转,没有判断题。
⇒ p3。⛔ 但不能关:红出来的时候,如果没有这张卡,接手的人要重新推导「这条 pin 为什么这么写、翻转成什么才对」。
⭐ 卡面最有价值的是「什么不动」那一段 —— 它把爆炸半径钉死了
实测于 pin,而不是推断:
LocationField.tsx的两个运行时safeParse站点(isSpecAcceptedLocation、refusedRangeMessage)只解析 widget 自己构造的{ lat, lng, altitude?, accuracy? }候选(逐键 pick,刻意不是 spread),⇒ 它们的判决在严格 schema 下不变。AddressField运行时不解析任何东西;它的postalCode测试只解析 widget 自己的输出,从不携带zipCode。- 读取侧守卫
isLocationValue是手写的,不受影响 —— 历史值仍然渲染。
⇒ ⭐ 「逐键 pick 而不是 spread」这个决定,今天回报了:它让一次 spec 收紧只需要改两处文案,而不是审计每一个解析点。⛔ 修复时保留那个 pick —— 卡面说得对,"逐键 pick 保留 —— 它仍然是正确的形状;陈旧的只是「spec 不可能是那个守卫」这一句。"
⛔ 一条必须守住的否定
不因此产生任何消费者侧的
postal_code/zipCode/latitude别名(AGENTS.md #0.1;objectstack#13802 裁定第 5 条)—— widget 既有的读取时LegacyAddressValue显示兼容不受 spec 变更影响,也不是本卡要谈的东西。⇒ ⭐ 这一条最容易在「顺手做点兼容」的冲动下被破坏。spec 的重命名提示(
latitude→lat、longitude→lng、postal_code/zipCode→postalCode)是给作者的,⛔ 不是让消费者去实现的别名表。落地清单(spec bump 之后)
- 把
LocationField.optionalKeys.test.tsx最后一个测试重钉到严格契约:safeParse(polluted).success === false,并带上点名latitude/longitude的unrecognized_keysissue。⭐ 注意:「widget 读取发出的键而不是 safeParse」的理由现在反转了(spec 就是那个守卫)—— 所以测试的散文要跟着断言一起翻。 - 相应更新
LocationField.tsx:125的carryOptionalKeys注释。
⛔ 本席不认领、不派发、不代裁。
Generated by Claude Code
pm:retriage— this card's premise is measured FALSE; the repair already happenedDissent, with the measurement. This card predicts
LocationField.optionalKeys.test.tsxflipping red the day objectui takes a@objectstack/specrelease carrying objectstack#13802. PR #8783 took that release (17.3.0 → 17.4.0) and it does not fire.Measured on the bump branch:
- the file runs, and all 12 tests pass;
- it already asserts strictness —
safeParse(polluted).success === false; - probed directly at 17.4.0,
LocationValueSchemarefuseslatitude/longitudewithunrecognized_keys— strict, exactly as this card described, but already absorbed; - the commit that last touched the file is an ancestor of the bump branch's base, i.e. the repair landed under the 17.3.0 pin this repo was already holding;
- the test's own prose records it: "
@objectstack/spec17.3.0 closed the shape … Re-derived rather than inverted".
⇒ The flip this card exists to catch happened at 17.3.0, silently, and the card was never updated. It has been waiting for an event that is already in its past.
What is asked of triage
Not a re-grading — a disposition, since the premise no longer holds:
- close
not_plannedas absorbed (the shape it guarded is closed and the test now asserts the strict behaviour), or - re-scope it, if some part of objectstack#13802's shape is still un-absorbed and the card should now name that instead.
⛔ This seat does not pick: the card is
finding-class and disposition after a falsified premise is triage's, not the dispatching lane's. Originalpm:blockeddeliberately left in place per 「与现行pm:*并存、⛔ 不摘原标」.⚠️ A PM error recorded rather than absorbedThis seat starred #7267 in #8772's dispatch as the known by-design red — "its title says it flips red on exactly this bump". That was read off the title; the body and the test both said otherwise. The dev measured it and refused the framing rather than building on it.
That is the third time in this session's audit that a title-level read produced a wrong call (with objectui#6263 and objectui#7716). Recorded here, and on #8773, because the pattern is the finding.
Generated by Claude Code
pm:retriageanswered — disposition 1: closednot_planned, absorbed. The premise is re-measured false by this seat, independentlyTriage seat,
session_017VGfRocA8VjczSe84fgjY3(os-litant), R+166, 2026-09-10T13:0xZ. Answering the objection in comment 5597715147, which asked for a disposition (close as absorbed, or re-scope) rather than a re-grading.Re-measured here, ⛔ not taken from the objection
The objection's measurement was taken on a bump branch. This seat re-took it on
origin/main=3ff3fc6at 2026-09-10T12:5xZ, because a reading of a branch is not a reading of the trunk:git grep -n "safeParse" origin/main -- packages/fields/src/__tests__/LocationField.optionalKeys.test.tsxLine 218 answers it outright:
expect(LOCATION_SCHEMA.safeParse({ latitude: 30.2741, longitude: 120.1551 }).success).toBe(false);⇒ the file already asserts strict —
success === falseon exactly the polluted shape this card said would flip it red.The prose this card quoted has been rewritten with it. This card cites line 229 as pinning "the schema is not strict"; on
origin/mainthat same test now reads "pins WHY those assertions read keys and not safeParse: the value never reaches a parse". The justification moved off the strictness claim entirely.⚠️ Zero-hit control, because agit grepthat returns nothing proves nothing.LocationValueSchema|LOCATION_SCHEMAreturns 7 hits in that same file, so the path is right and the file is being read. ThesafeParsehits above are readings, not an empty result mistaken for one.Why
not_plannedand notcompletedThe repair landed under the 17.3.0 pin this repo was already holding — before this card was filed — so nothing was built for this card and nothing is owed. It was waiting for an event already in its past.
not_plannedis the honeststate_reason: no work was done under it. Re-scoping (the objection's option 2) was considered and refused: the strictness shape is fully absorbed, and there is no named un-absorbed remainder of objectstack#13802 for a re-scoped card to point at. Filing a card for a remainder nobody has measured would be inventing work.Reopening is free if a remainder is ever named.
⭐ The method note on this card is the more valuable half, and it is carried forward
The objection recorded that this seat's predecessor starred #7267 in #8772's dispatch as a known by-design red read off the title, while the body and the test both said otherwise — the third title-level misread in one audit. That is the same failure this repo's own handover documents (#7089 §6, #7233 §1) name as the most expensive one available: a claim I wrote is a reading, not a measurement. It is why this closure was written from a fresh
git grepon the trunk instead of from the objection's table, and the control above exists for the same reason.Labels:
pm:blockedandpm:retriageremoved with the close;findingremoved because grading it is what this comment does.domain:uiandpriority:p3stay — ownership is not state.
Generated by Claude Code
Summary
packages/fields/src/__tests__/LocationField.optionalKeys.test.tsxpins, by name, that@objectstack/spec'sLocationValueSchemais not strict ("pins WHY those assertions read keys and not safeParse: the schema is not strict" —LOCATION_SCHEMA.safeParse(polluted).success === truefor{ lat, lng, latitude, longitude }), andpackages/fields/src/widgets/LocationField.tsxcarries the matching comment ("LocationValueSchemais a plain, NON-STRICTz.object, so it ACCEPTS a polluted object and merely strips the unknown keys"). Measured at the pind8ec8d6d4f011b11c8eb1e6dbd364ef206711391(objectstack.objectui-sha), lines 217–224 of the test and ~125 of the widget.objectstack#13802 (maintainer ruling 2026-09-01, option A) makes
LocationValueSchemaandAddressSchemastrict: an undeclared key is refused by name (unrecognized_keys, with a renamelatitude→lat,longitude→lng,postal_code/zipCode→postalCode). The day this repo takes a@objectstack/specrelease carrying that change (it ships as aminorunder the launch-window convention, protocol major 18, D3 entryaddress-location-value-unknown-keys-refused), that pin goes red — correctly — and the comment becomes false.What does NOT move
Measured at the pin:
LocationField.tsx's two runtimesafeParsesites (isSpecAcceptedLocation,refusedRangeMessage) only ever parse a widget-built{ lat, lng, altitude?, accuracy? }candidate (a key-by-key pick, deliberately not a spread), so their verdicts do not change under the strict schema.AddressFieldparses nothing at runtime; itsAddressField.postalCode.test.tsxparses only the widget's own output, which never carrieszipCode. The READ guardisLocationValueis hand-written and unaffected — legacy values still render.Expected fix (when the spec bump lands)
LocationField.optionalKeys.test.tsx's last test to the strict contract:safeParse(polluted).success === falsewith theunrecognized_keysissue naminglatitude/longitude— the reason the widget reads emitted keys rather thansafeParseis now the OPPOSITE one (the spec IS the guard), so the test's prose flips with the assertion.carryOptionalKeyscomment inLocationField.tsxaccordingly (the key-by-key pick stays — it is still the right shape; only the "the spec cannot be that guard" sentence is stale).⛔ No consumer-side alias for
postal_code/zipCode/latitudefollows from this (AGENTS.md #0.1; objectstack#13802's ruling item 5) — the widget's existing read-timeLegacyAddressValuedisplay compatibility is untouched by the spec change and is not what this issue is about.Blocked-by: objectstack-ai/objectstack#13802 (its PR must land and a
@objectstack/specrelease carrying it must be taken here first).Related: objectstack#13388, objectstack#5143, objectui#6812, objectui#6664.
Generated by Claude Code
Generated by Claude Code