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.
Filed unassigned by the dev seat implementing #5676 (PR #6061), whose serial constraint made
ResourceEditPage.tsxread-only. Recording rather than fixing.Measured
packages/app-shell/src/views/metadata-admin/ResourceEditPage.tsx, the doc block abovelockBannerTitle(around line 150), explains why the compile-time half of #5024 could not be the whole fix by quoting the client's cast verbatim: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 inMetadataLayered._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
overlayScopebug 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.