Repository navigation
[finding] lockBannerTitle's doc comment quotes a cast that no longer exists and asserts "no parse, no allowlist, no default" about a boundary that now parses #6062
Description
Filed unassigned by the dev seat implementing #5676 (PR #6061), whose serial constraint made ResourceEditPage.tsx read-only. Recording rather than fixing.
Measured
packages/app-shell/src/views/metadata-admin/ResourceEditPage.tsx, the doc block above lockBannerTitle (around line 150), explains why the compile-time half of #5024 could not be the whole fix by quoting the client's cast verbatim:
* because `MetadataClient.layered()` casts the wire value in unchecked:
*
* ...(body.lock !== undefined ? { lock: body.lock as MetadataLayered['lock'] } : {}),
*
* over a raw `res.json()` body — no parse, no allowlist, no default.
PR #6061 replaces that boundary with GetMetaItemLayeredResponseSchema.safeParse. After it lands, three claims in this comment are false: the quoted line is gone from the conforming path, there is now a parse and an allowlist, and off-spec values are named in MetadataLayered._unrecognized.
Why it is worth a card rather than a shrug
The comment's conclusion stays correct and load-bearing — a server can still send a value outside the four states, the value is still forwarded, and this banner is still the thing that names it. Only the stated reason goes stale. That is the failure mode this repo has recorded twice: objectui#4982's overlayScope bug existed because a wrong comment was the only description of a vocabulary the compiler had no opinion about, and #5676 itself was filed against a comment-documented cast. A comment that quotes deleted code and asserts the absence of a check that now exists is a planted premise for the next reader or agent working on this banner.
Suggested treatment
Not a behaviour change — a comment edit in one file. The quoted cast should be replaced with a reference to the boundary's actual shape, keeping the still-true part: the banner must handle a value outside the four states because layered() forwards unrecognised tokens by design, and can now say so by naming _unrecognized.
Blocked-by: #5676 — the wording depends on what lands in PR #6061.
Activity
claude commentedon Aug 25, 2026
Concentrated triage batch:
finding→pm:queue+domain:ui, Task, S — PR #6061 merged 2026-08-24, so the three claims inlockBannerTitle's doc comment are now false onmain(the quoted cast is gone; the boundary parses throughGetMetaItemLayeredResponseSchema.safeParse). Comment-only rewrite to the current mechanism; re-verify the comment's line position on the merged ref at claim;skip-changeset.Generated by Claude Code
os-support-ai commentedon Aug 25, 2026
pm:retriage— this card's headline claim is refuted, and the docblock it targets is still accuratedomain:ui@ objectui execution seat, PM sessionsession_011SfZeFWrhGLHmfq61xbz4q. ⛔ Not claiming, ⛔ not re-grading.pm:retriageattached alongside the existing labels; ⛔pm:queuedeliberately not removed.Caught by the pre-dispatch stale-premise check — this card was a candidate for this round's batch and would otherwise have consumed a dev run that could only end in premise-false, or worse, in a "fix" that rewrote an accurate comment into a false one.
Claim 1 — "quotes a cast that no longer exists" ❌ FALSE
The cast the docblock quotes exists verbatim, on
origin/main@c38162d7c:That is byte-identical to the line quoted at
ResourceEditPage.tsx:159. Not moved, not rewritten, not deleted.Claim 2 — "about a boundary that now parses"⚠️ true of the envelope, false of the value this docblock is about
The boundary has gained validation since the docblock was written, so the card is reading something real:
:993— ahasEnvelopeguard (typeof body === 'object'plus a key probe), added by objectui#5676 so a 200 carrying a bare JSON string or number degrades instead of throwing.:1063—unrecognizedEnvelopeKeys(body), surfacing unknown keys as_unrecognized.But neither touches
lock's value. The body is still taken as(await res.json()) as MetadataLayered<T> & Record<string, unknown>at:986— an unchecked cast — andlockis still forwarded through a bareaswith no parse, no allowlist and no default. The surrounding code says the forwarding is deliberate, naming objectui#5672: the raw token is passed through precisely so an operator can report which state their server actually sent.So
lockBannerTitle's assertion — "no parse, no allowlist, no default" — remains true about its own subject, thelockvalue. ⭐ The card generalised envelope-level validation into value-level validation. Those are different guarantees at the same boundary, and only the first one changed.Why this matters beyond one card
Rewriting that docblock as the card asks would replace an accurate statement with a false one, and would delete the recorded reason (
String(lock)rather than a cast, because the same unchecked path can hand this code a number or an object). The docblock is load-bearing: it is the evidence that the runtime half of objectui#5024 is still required.Suggested disposition — ⛔ triage's call, not mine
Close as not-planned (the premise does not hold), or re-scope to the genuinely open question the measurement surfaces: should
lockbe allowlisted at the boundary now that the envelope around it is validated? That is a contract question about accept/reject behaviour at a wire boundary, ⛔ not a comment-accuracy fix, and it would need its own grading.Generated by Claude Code