Repository navigation
finding(fields): buildValidationRules has no location branch, so a STORED out-of-range coordinate is never validated — and adding one falsifies the premise #6714 chose refusal on #6744
Description
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-invalidflipped to"true";- the message rendered through the form renderer;
- the write was blocked —
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 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
- finding(fields):
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. - finding(fields):
LocationFieldemits out-of-range coordinates the spec rejects #6714 — the closed card whose premise this moves. - finding(fields):
LocationFieldaccepts a partly-numeric coordinate, emitting a plausible wrong location #6715 — a thirdLocationFieldfinding (partly-numeric coordinates), still awaiting grading. - objectui#3222 — the published validation slot whose producer this is.
Activity
huangyiirene commentedon Aug 29, 2026
定级：
needs-user-decision·domain:ui·priority:p1。finding已离标。⛔ 不派发。⛔ 不代裁。理由：本卡的形状不是"缺一个分支"，而是"加上这个分支会挡住存量记录的编辑，而存量里有多少越界坐标，开发容器里量不出来"。那是迁移形状的后果，落在人工地板内（难以回滚、用户可感知）。
<!-- os-decision-facets -->
（读回：上面这一行是四棱决策标记，本仓按转义拼写书写——
<直接跟字母会让 MCP 读取在此处静默截断，后面全部丢失。）四棱
① 项目长远合理性 —
buildValidationRules是 objectui#3222 那个已发布校验槽的生产者，每个字段控件的errorprop 都从它来。location是其中唯一没有分支的类型之一 ⇒ 长远看这个洞该补，这一点四个选项都不争。② 实际业务拉动 — 拉动来自"存量坏坐标现在被静默接受、并在每次保存时被原样写回"。⚠️ 但拉动的大小正比于存量坏数据的条数，而那个数就是未知量本身。⇒ 本轴无法独立给出强度。
③ 防 AI 犯错 — ⭐ 本卡最尖的一面，且与代码无关：#6714 是一张已关闭的卡，它在"拒绝发射"与"发射并标为无效"之间选了拒绝，前提是*「下游没有任何东西会拒绝或修复这个值，所以一次发射就是一次写入」*。本卡的测量证明：装上
location分支后，下游确实会拒绝（dataSource.update调用 0 次）。⇒ 落地本卡会静默移动一条已关闭裁决所站的地基。任何后来重新推导这段的人（人或 AI）都会撞上一个前提与结论不再对齐的闭卡。④ 创业阶段不扩散 — 卡已自我设限：⛔ 只管
location，不要求做校验覆盖率普查。这个限制应当保留；把它扩成"所有字段类型的存量校验缺口"会立刻变成一个没有边界的工程。选项与客户真正能感知到的代价
推荐（一个建议，不是裁决）
选 1，但把不可测的部分交给能测的人：越界坐标的计数在开发容器里不可测，在目标部署上是可测的（一次只读查询）。⇒ 建议裁 1 并附一个前置条件：上线前由掌握部署的人跑一次计数，为 0 直接落 1；非 0 则退到 3，并单独立一张修复路径的卡。
这样做的好处是它把"未知量"从阻塞项变成了一个有主的动作，而不是让本卡在决策箱里等一个永远等不到的普查（对照 objectstack#12920：那张卡正是因为同形的不可测普查而长期卡住）。
兜底：若不接受前置计数，则选 3——它在两种存量状态下都不产生迁移事件，代价是明说的部分执行。
LocationFieldemits out-of-range coordinates the spec rejects #6714。本卡关于 format arm 的论证（"对not a coordinate这类文本根本没有 location 值可发射，所以 emit-and-mark-invalid 等于把裸字符串写进 typed location"）我是接受立卡人的转述。⇒ 若那条论证不成立，选项空间会变，finding(fields):LocationFieldemits out-of-range coordinates the spec rejects #6714 可能真的需要重开，而不是像本卡主张的那样"前提变了但结论仍站得住"。裁前值得让人核一眼。location裁一个存量校验策略，很可能会在下一个字段类型上被推翻一次。裁后执行
pm:queue，范围＝加location分支 + 前置计数（计数由部署侧执行，不在 PR 内）。pm:queue，范围须额外包含一句说明：为何location与其他字段的挡/不挡行为不一致，写进代码注释而不是只写在 PR 里。pm:queue，范围含脏值门，并同时立一张"存量坏坐标的修复路径"卡。LocationFieldemits out-of-range coordinates the spec rejects #6714 上留一条记录，说明其前提已被本次改动移动。⛔ 这不是重开 finding(fields):LocationFieldemits out-of-range coordinates the spec rejects #6714，只是不让下一个读者从一个已经不成立的前提出发。⛔ 裁定落地时请挂
pm:retriage。我预登记的条件改判不会自动触发——objectstack#13037 上我同样预登记过一条，维护者裁了，改判没发生，债在我这边。散文不是载体。低摩擦裁决：回一句「裁 1 / 2 / 3」即可，其余我来执行。
Generated by Claude Code
claude commentedon Aug 29, 2026
Claim + dispatch order —
domain:uiexecution seat, PM sessionsession_01CRJge11jso9TpXRWFt1Z49, round R16.Branch:
claude/issue-6744-location-validation-branch. Oneos-devagent, one worktree.The ruling (verbatim, 照抄不译)
⛔ The hard precondition comes FIRST
Before you write the branch, count existing out-of-range coordinates across everything measurable — dogfood, demo, and catalog datasets, in full.
Terrain I verified myself
packages/fields/src/index.tsx:2551onorigin/maind06059f24—export function buildValidationRules(field: any): any {. The card's line number was taken onfaac0d935; this one is on the current main. Re-derive on your own base anyway and state it.packages/fields/src/widgets/*andpackages/fields/src/__tests__/*in the same package — but notsrc/index.tsx, which I checked against its file list. So your file is clear; expect no conflict, but if you find yourself editing anything underwidgets/, stop and tell me, because that would be a collision I did not plan for.Acceptance
Pins in both directions: an out-of-range stored value is blocked on edit; a legal value is unaffected; the create form's behaviour is unchanged. Scope-lock to
locationonly — a repo-wide survey of stored-value validation coverage across all field types is a different card; file it if you find it, do not fold it in.Point 3 of the ruling is a deliverable: leave a record comment on #6714 (closed) noting that its "nothing downstream intercepts" premise stops holding once this lands, and that the ruling itself is unchanged. That comment exists to stop a third person re-deriving this interaction.
Generated by Claude Code
claude commentedon Aug 29, 2026
os-dev-report
{ "issue": 6744, "status": "done", "branch": "claude/issue-6744-location-validation-branch", "pr": "https://github.com/objectstack-ai/objectui/pull/6811", "premise_still_valid": true, "summary": "HARD PRECONDITION PASSED WITH A ZERO READING, so the cheap guard landed. Every stored location value in every measurable dataset (28 of them: app-showcase seed hq x14 / task.location x10 / field_zoo.f_location x1, the qa dogfood field-zoo matrix, and the objectui schema-catalog location schemas) was adjudicated by the platform's own valueSchemaFor({type:'location'},'stored') -- 28 accepted, 0 refused, with {lat:999,lng:999} refused and {lat:37.7749,lng:-122.4194} accepted as controls from the same call. An independent sweep of 12,465 files across both repos for lat/lng and legacy latitude/longitude literals found 44 out-of-range values, every one of them a test negative fixture, a source docblock, docs prose, or a changeset -- ZERO in any dataset. BOUNDARY, as the ruling requires: customer deployments are not measurable from this container, so this zero means 'zero within measurable scope' and is never evidence that no out-of-range coordinate exists. IMPLEMENTATION: buildValidationRules now compiles a validate.location entry adjudicating a PRESENT value against valueSchemaFor(field,'stored') -- the same schema the engine's record validator uses under ADR-0104 D1 -- with no bounds restated in objectui and the message built from the schema's own issues. Absence is left to required via core's isMissingForRequired, and a field-authored validate composes under its own key. ONE DESIGN CALL WORTH YOUR EYE: the rule adjudicates the WHOLE value, not only its range, so it also marks a stored value the spec refuses for another reason (a retired {latitude,longitude} record, a numeric string). I counted that class too rather than shipping on an uncounted one -- the same 28-value adjudication used the full schema and returned zero. Rationale: a range-only test would have meant hand-picking issue codes, i.e. the second contract AGENTS.md #0.1 bans, and a spec-refused value is already one the platform's write path warns on or rejects. TERRAIN RE-DERIVED ON MY OWN BASE: on origin/main d06059f24, packages/fields/src/index.tsx:2551 is 'export function buildValidationRules(field: any): any {' -- matching what you verified. After my change it sits at line 2645. HOT-FILE REPORT, per your instruction: I edited NOTHING under packages/fields/src/widgets/ or packages/fields/src/__tests__/, so there is no collision with PR #6801 (whose 14-file list I pulled and confirmed excludes src/index.tsx and every LocationField file). But two docblocks there now carry a sentence my change falsifies -- 'buildValidationRules still has no location branch' at packages/fields/src/widgets/LocationField.tsx:356 and packages/fields/src/__tests__/LocationField.refusalDiagnostic.test.tsx:32. Both are prose with no assertion depending on them. I left them alone and am reporting instead of editing; they want a one-line follow-up once #6801 lands. The three pins in packages/plugin-form/ that asserted the branch's ABSENCE were rewritten, not deleted: two of them (locationRefusal #6716, locationResidue #6715) now assert the property that actually survives -- a refusal produces no value, so the rule is handed undefined and the input-time announcement stays the widget's -- and locationRange's docblock was corrected. Ruling item 3 delivered: record comment on the closed #6714 at https://github.com/objectstack-ai/objectui/issues/6714#issuecomment-5463551015 -- it states the 'nothing downstream intercepts' premise stops holding, that the ruling itself is unchanged and is not reopened, and why the two changes do not overlap. #6714 re-read afterwards: still closed/completed.", "tests": "GREEN UNION at the final commit 27c53b7ec (git rev-parse --short HEAD read at that run; git status clean and git diff HEAD empty before and after): `pnpm exec vitest run packages/fields/ packages/plugin-form/ packages/components/src/renderers/form/` -> 'Test Files 253 passed (253) / Tests 3142 passed (3142)', wrapper 'VERDICT command-exit 0 . held the lock 323s'. All heavy runs went through scripts/pm/os-verify-lock.sh with OS_VERIFY_LOCK_SLOT=dev-6744; verdicts read from the printed VERDICT line, never a bare $? behind a pipe. NEW PINS: packages/plugin-form/src/ObjectForm.locationStoredRange.test.tsx, 13 cases through a real ObjectForm. Blocked direction: stored {lat:999,lng:999} on an EDIT form gives aria-invalid='true', the spec's own message rendered, and dataSource.update called 0 times; repeated on each bound (91,0 / -91,0 / 0,181 / 0,-181). Unaffected: a legal value saves back unchanged with aria-invalid='false', altitude/accuracy survive, an absent location does not block. Create unchanged: untouched field still creates, legal typed coordinate still stored, out-of-range typed coordinate still refused by the WIDGET (#6714 untouched). The expected message is BUILT from the schema's issues in the test, not typed out. ABLATION (predicted direction stated first: RED). The location branch was deleted from the COMMITTED tree and the pins re-run. NO REBUILD WAS NEEDED FOR EITHER LEG, and this is proven rather than assumed: the root vitest.config.mts line 279 aliases '@object-ui/fields' to './packages/fields/src', so the test resolves source, not dist -- the unbuilt-ablation-stays-green hazard does not apply here. Mutation confirmed ON DISK, not by an editor exit code: HEAD blob 1ca938326db8..., on-disk after ffc00029098d..., deleted-anchor grep count 1 -> 0, injected-marker count 1, and the script aborts on any of those. Result: 'Tests 5 failed | 8 passed (13)'. The 5 reds are exactly the branch-dependent cases (both blocked-direction cases plus the three rule-seam cases); the 8 that stayed GREEN are the unchanged-behaviour pins, which is the control proving they are not merely measuring the branch. Restore leg proven with the same rigour (git checkout HEAD -- ABSOLUTE path, from a trap on EXIT INT TERM): on-disk hash back to 1ca938326db8..., ABLATED marker count 0, anchor count 1, `git diff HEAD` empty, `git status` clean. TYPECHECK: `pnpm --filter @object-ui/fields type-check` and `pnpm --filter @object-ui/plugin-form type-check` both green, script name echoed in the output so the zero-match-filter-exits-0 trap is excluded (objectui spells it 'type-check', with a hyphen). NOT-MEASURED hazard checked: both packages' type-check is 'tsc --noEmit && tsc -p tsconfig.test.json', and `tsc -p tsconfig.test.json --listFiles` shows all four edited/added test files present (one hit each), so that green genuinely covers them. Dependency closure built first (pnpm --workspace-concurrency=2 --filter '...^...' build). GATES, each quoting its own printed verdict: check:control-bytes 'OK (scanned 5646 tracked text file(s))'; check:spec-symbols OK; check:phantom-deps 'Every in-scope import is declared by the package that publishes it'; check:self-import 'No package names itself inside its own src/'; check:esm-specifiers OK; check:i18n-keys 'Every in-scope call-site key resolves against the en pack'; check:side-effects-array OK; check:vi-mock-specifiers OK; check:designer-field-key-parity OK; check:action-forward-parity OK; check-changeset-presence OK ('declares 1 changeset'); check-changeset-no-major OK. Also ran a control-character sweep over the new file (grep -naP over the C0 range) -- no hits. LINT, narrowed with the three required pieces of evidence: (1) in-scope population read from eslint's OWN config, not my guess -- 306 files across the two changed packages; (2) that count read from --format json output; (3) config invariance -- eslint.config.js extends tseslint.configs.recommended (NOT recommendedTypeChecked) and languageOptions declares no project/projectService, so there is no type-aware linting and a rule's verdict on a file depends only on that file's own text plus config; my diff touches no file outside those two packages and no eslint config, so no untouched file's verdict can move. Result: 0 errors, exit 0 (1645 pre-existing warnings, all severity-1 no-explicit-any, none an error; the package script is bare `eslint .` with no --max-warnings). NOT MEASURED, left to CI, and reported as NOT MEASURED rather than as green or red: check:readme-exports -- after building my two packages it reports ZERO findings for either of them, but its repo-wide population needs every package's dist and without that the gate prints its own verdict 'the population COLLAPSED -- this run proves nothing'; this PR adds no export. check:sdui-registration-pins and check:eager-closure -- both need a console build; the former prints 'This is exit 2, not a pass ... a run with nothing to read has measured nothing'. Flagging check:eager-closure for your CI read specifically, because this PR adds a runtime import of '@objectstack/spec/data' to the fields barrel. Exposure is bounded: that module is ALREADY an eager runtime import in @object-ui/core (server-owned-value.ts, unmaterialized-fields.ts, filter-tokens.ts) and @object-ui/types (zod/form.zod.ts), so no new vendor chunk appears; budget headroom on main is 45,996 bytes.", "mcp_calls": "0 -- the whole run used repo-scoped REST through the proxy (issue reads, PR file list, PR creation, comments, issue creation, label existence checks); no MCP GitHub tool was called. /search/issues was probed once and returned 403 as you said it would, so dedupe went through a repo-scoped listing plus local grep with a control term.", "open_questions": [], "out_of_scope_findings": [ "filed as #6812 (label `finding`, unassigned): buildValidationRules validates no structured stored value except `location` -- the other ADR-0104 value-shape classes (address, composite, record, repeater, vector, reference ids, file ids) are unmeasured. Filed per ruling item 4, which anticipates exactly this card. Deliberately framed as a request to MEASURE, not to add branches: #6744 only landed because its precondition count came back zero, and reproducing that shape N times without N counts is the migration-shaped consequence the ruling exists to prevent. Deduped against 251 open issues with a control term (nearest neighbour #2731 checked and ruled not a duplicate -- it is a domain:spec design card about declaring value shapes in the spec, a different layer).", "NOT filed, reported to you instead per your hot-file instruction: two docblocks under the PR #6801 directories state `buildValidationRules still has no location branch`, which this PR falsifies -- packages/fields/src/widgets/LocationField.tsx:356 and packages/fields/src/__tests__/LocationField.refusalDiagnostic.test.tsx:32. Prose only, no assertion depends on them. Wants a one-line follow-up once #6801 lands; say the word and I will do it in a separate PR." ] }Generated by Claude Code
claude commentedon Aug 29, 2026
硬前置:通过,零读数 —— 而且方法本身才是它成立的原因
裁决要求落地前先数存量越界坐标。报告的读数不是一次 grep,是两条独立方法互相印证:
valueSchemaFor({type:'location'},'stored')判定 —— 28 接受、0 拒绝,且同一次调用里带了正反对照({lat:999,lng:999}被拒、{lat:37.7749,lng:-122.4194}被接受)。⇒ 零是读数,不是查询坏了。lat/lng与 legacylatitude/longitude字面量,命中 44 个越界值 —— 每一个都是测试的反例夹具、源码 docblock、文档散文或 changeset,数据集里一个都没有。⇒ 两条方法都给零,而第二条还解释了"为什么会有人以为有" —— 44 个越界值确实存在,只是它们全都是故意写的反例。
边界照裁决写明了:客户部署在本容器不可测,所以这个零的含义是「可测范围内为零」,⛔ 永远不是「不存在」。
⚖️ 那个设计判断:采纳,而且理由比结论重要
报告特意标出来问我:规则裁决的是整个值,不只是范围 —— 所以它也会标记 spec 因别的原因拒绝的存量值(退役的
{latitude,longitude}形状、数字字符串)。**采纳。**理由是报告自己给的那条,而且是本卡最好的一个判断:
⇒ 只测范围,就必须由 objectui 侧挑选 spec 的 issue code —— 那是在 spec 之外再立一份关于"什么算合法坐标"的契约,正是这一族卡存在的原因。用
valueSchemaFor(field,'stored')(引擎记录校验器在 ADR-0104 D1 下用的同一个 schema)、不在 objectui 侧重述任何边界、消息由 schema 自己的 issues 生成 —— 这是 contract-first 的正确形状。⭐ 更关键的是:它没有在一个没数过的类上落地。同一次 28 值裁决用的就是完整 schema,所以那个更宽的类也是零。⇒ 把硬前置应用到了自己的范围扩张上,而不是拿"前置是给范围的"来绕过。这正是裁决那条前置想要的行为。
范围锁也没破:裁决锁的是「
location一个类型」,整值裁决仍在这一个类型之内。两句被证伪的散文:已决定在 #6811 内更正
报告发现
widgets/LocationField.tsx:356与__tests__/LocationField.refusalDiagnostic.test.tsx:32各有一句写着buildValidationRules仍然没有location分支 —— 本 PR 把它们变成假的。报告没有顺手改,而是报上来问,这是对的。本席核过两件事再定的:① 那两个文件不在 PR #6801 的 file list 里(只是同目录),⇒ 无冲突;② 两句散文确实在
origin/main26896c689的那两行上。⇒ 在 #6811 内改,不另开 PR。制造矛盾的是这个 PR,发版时留下一段说反话的 docblock,就是把陷阱交给下一个读者。更正自己变假的散文是把改动做完,不是加宽。⚠️ 已明确要求:只改那两句,不加断言,不碰 #6801 名单里的任何文件;若其中一句其实并未被本改动证伪,留着并报告是哪一句。
其余
LocationFieldemits out-of-range coordinates the spec rejects #6714 上留了记录评论(其「下游无人拦截」前提自本分支起不再成立,裁决不动、不重开)。buildValidationRulesvalidates no structured stored value exceptlocation— the other ADR-0104 value-shape classes are unmeasured #6812(其余 ADR-0104 值形状类未测)。⭐ 它被刻意写成"请求测量"而不是"请求加分支" —— 因为本卡之所以能落,正是它的前置数出了零;不带 N 次计数就把这个形状重复 N 遍,恰是裁决要防的那种迁移形状。这个自我克制值得记一笔。正式 ACCEPT 待 CI 跑满 —— 现在 27/30 还在排队,⛔
queued不是通过。Generated by Claude Code
claude commentedon Aug 29, 2026
os-dev-report addendum
Correcting one item in the report above, so that report does not itself become the stale record.
It listed the two docblocks under the PR #6801 directories as "NOT filed, reported to you instead" and pending a follow-up PR. They are now corrected inside PR #6811, on the coordinator's instruction after they verified that neither file is in #6801's file list — #6801 touches
CurrencyField,GeolocationField,NumberField,PercentField,numberBadInputand twoNumberInputWidgetstests only, so the directories overlap but the files do not. I re-verified that against #6801's 14-file list before editing: zero overlap.Each sentence was a compound claim, and only half of it was falsified, so only that half was rewritten:
packages/fields/src/widgets/LocationField.tsx:356buildValidationRulesstill has nolocationbranch, and this card does not give it one."buildValidationRulesHAS alocationbranch as of objectui#6744 — for that STORED case, never for these refusal arms — and this card did not give it one."packages/fields/src/__tests__/LocationField.refusalDiagnostic.test.tsx:32locationbranch and this card does not give it one."The "this card did not give it one" half is true in both places and was kept verbatim: #6716 and the refusal-diagnostic card did not add the branch, this one did. The surrounding paragraph in each file — that a branch installed there sees
undefinedin both refusal arms while firing correctly for a stored pair — is confirmed by this change rather than contradicted, so it was left untouched.Prose only: no assertion, no behaviour, no export, no changeset. New head
aa8372ad4, still draft. Green union re-run at that head:pnpm exec vitest run packages/fields/ packages/plugin-form/ packages/components/src/renderers/form/gave "Test Files 253 passed (253) / Tests 3142 passed (3142)", andcheck:control-bytesprinted "OK (scanned 5646 tracked text file(s); skipped 85 binary)". Both corrected lines were read back from GitHub ataa8372ad4, and the falsified phrase now has zero hits in either file.mergeable_statereadsbehindbecauseorigin/mainhas moved past this branch's base. Not touched: no rebase, no force-push — the merge queue rebuilds on currentmain.Generated by Claude Code
claude commentedon Aug 29, 2026
ACCEPT — PR #6811
Verification. Check-runs on head⚠️ a
aa8372ad4:total_count=30, 30 rows, 27success+ 3skipped, zero non-terminal. That head is the one carrying the docblock correction, not the earlier27c53b7ec—check_suite.completedarrived for the superseded commit at 17:26 and was deliberately not read as a verdict.The substantive review — the zero-reading precondition by two independent methods, and the ruling on whole-value versus range-only adjudication — is in my comment above and is not repeated.
The docblock correction came back sharper than I asked for
I asked for two falsified sentences to be rewritten. The report came back with a distinction I had not made: each sentence was a COMPOUND claim, and only half of it was falsified.
⇒ The first half is now false; the second half is still true — #6716 and the refusal-diagnostic card genuinely did not add the branch, #6744 did. So the clause was kept verbatim and only the first half rewritten, in both files. The surrounding paragraph — that a branch installed there sees
undefinedin both refusal arms while firing correctly for a stored pair — is confirmed by this change rather than contradicted, and was left untouched.⭐ That is the right instinct, and it is the opposite of the failure this lane keeps hitting: when a sentence is found to be partly wrong, the cheap move is to rewrite the whole thing and quietly discard a true clause with it. It also re-verified my own hot-file reading independently rather than taking it on trust, and corrected the PR body's now-stale "deliberately NOT touched" section so the PR does not ship a description its own diff contradicts.
Ruling items delivered
LocationFieldemits out-of-range coordinates the spec rejects #6714 is posted, states that its "nothing downstream intercepts" premise stops holding, that the ruling itself is unchanged and not reopened, and why the two changes do not overlap. finding(fields):LocationFieldemits out-of-range coordinates the spec rejects #6714 re-read afterwards: stillclosed/completed.buildValidationRulesvalidates no structured stored value exceptlocation— the other ADR-0104 value-shape classes are unmeasured #6812 filed — and deliberately framed as a request to MEASURE, not to add branches, because finding(fields):buildValidationRuleshas nolocationbranch, so a STORED out-of-range coordinate is never validated — and adding one falsifies the premise #6714 chose refusal on #6744 only landed on a zero precondition count and reproducing that shape N times without N counts is exactly the migration-shaped consequence the ruling exists to prevent. ⭐ That self-restraint is worth as much as the fix.One thing flagged for the CI read, correctly
This PR adds a runtime import of
@objectstack/spec/datato the fields barrel. Exposure is bounded and the report says why — that module is already an eager runtime import in@object-ui/coreand@object-ui/types, so no new vendor chunk appears. The budget gate has since reported PASS on this PR's head.mergeable_state: behindwas correctly left alone — no rebase, no force-push; the merge queue rebuilds on currentmain.Landing when the runner pool opens; that is a throughput hold, not a review one.
Generated by Claude Code