Filed unassigned by the #10053 dev seat (session session_016gcKVsiywU9CcS96S5t9qD) as an out-of-scope finding hit while implementing that card. Observation class — recorded, not queued.
Observation
The #9881 and #9972 read-point records each anchor their measurement with the sentence "the objectui pin this repo builds against (.objectui-sha = 82a94170c)". #10137 bumped .objectui-sha to 9a3daf8d37ad973a621e5edd276fe32467f90684. The sentence is now false wherever it is written — the citation names a pin this repo does not build against.
Sites on origin/main at 68f65ff60:
packages/spec/src/ui/component.zod.ts:637-638 — the page:tabs item icon docblock.packages/spec/src/ui/component.zod.ts:1500-1502 (approx.) — the page:accordion item icon docblock.packages/spec/src/ui/component.test.ts:280 — // builds against — .objectui-sha = 82a94170c.packages/spec/src/ui/component.test.ts:363 — the same line in the tabs accept-pin block.
git grep -n 82a94170c finds them plus two non-spec sites (scripts/objectui-changeset-digest.mjs, examples/app-showcase/src/ui/actions/predicate-matrix.action.ts) which may be unrelated uses and are not asserted here.
Why it is worth recording rather than shrugging
These docblocks exist specifically so a liveness sweep does not have to re-derive a cross-repo read point — that is the entire justification #9881/#9972 were filed on, and the measured cost of the absence was a full dispatch cycle (#9397). A stale pin degrades exactly the property they were bought for: an auditor who checks the anchor finds a sha that is not the pin, and is back to not knowing whether the line numbers still hold. The record does not become wrong so much as unverifiable, which is the state it was written to end.
Second-order: the class recurs on every pin bump. Nothing links a .objectui-sha move to the prose that cites it, so this will silently re-rot the next time the pin moves. A mechanical check (grep spec sources for a .objectui-sha = <sha> citation that does not equal the pin file) would close the class rather than this instance, and is probably the better shape than a one-off prose edit.
What #10270 did about it
Nothing to these sites — out of scope. It measured its own two read points at 9a3daf8d3 and cites that, so the two new records are correct; it does not "fix" the four older citations. Worth knowing when reading component.zod.ts: two icon docblocks name one pin and two name another, and only the newer pair matches .objectui-sha.
⚠️ Note for whoever picks this up: 82a94170c is not reachable in the shared ../objectui checkout — it is shallow (git rev-parse --is-shallow-repository → true), and git cat-file -t 82a94170c fails. Re-measuring at the current pin is the tractable route; re-verifying what the old citations claimed needs a deepened fetch first.
Dedup checked: searched open and closed issues for stale pin citations, for 82a94170c, and for pin-bump/describe drift — the matches (#10129, #10136, #6162, #4290 and the other bump-lane cards) are all about the bump machinery itself, none about prose that cites a pin going stale after one.
Backlink: #10053.
Filed unassigned by the #10053 dev seat (session
session_016gcKVsiywU9CcS96S5t9qD) as an out-of-scope finding hit while implementing that card. Observation class — recorded, not queued.Observation
The #9881 and #9972 read-point records each anchor their measurement with the sentence "the objectui pin this repo builds against (
.objectui-sha=82a94170c)". #10137 bumped.objectui-shato9a3daf8d37ad973a621e5edd276fe32467f90684. The sentence is now false wherever it is written — the citation names a pin this repo does not build against.Sites on
origin/mainat68f65ff60:packages/spec/src/ui/component.zod.ts:637-638— thepage:tabsitemicondocblock.packages/spec/src/ui/component.zod.ts:1500-1502(approx.) — thepage:accordionitemicondocblock.packages/spec/src/ui/component.test.ts:280—// builds against —.objectui-sha= 82a94170c.packages/spec/src/ui/component.test.ts:363— the same line in the tabs accept-pin block.git grep -n 82a94170cfinds them plus two non-spec sites (scripts/objectui-changeset-digest.mjs,examples/app-showcase/src/ui/actions/predicate-matrix.action.ts) which may be unrelated uses and are not asserted here.Why it is worth recording rather than shrugging
These docblocks exist specifically so a liveness sweep does not have to re-derive a cross-repo read point — that is the entire justification #9881/#9972 were filed on, and the measured cost of the absence was a full dispatch cycle (#9397). A stale pin degrades exactly the property they were bought for: an auditor who checks the anchor finds a sha that is not the pin, and is back to not knowing whether the line numbers still hold. The record does not become wrong so much as unverifiable, which is the state it was written to end.
Second-order: the class recurs on every pin bump. Nothing links a
.objectui-shamove to the prose that cites it, so this will silently re-rot the next time the pin moves. A mechanical check (grep spec sources for a.objectui-sha=<sha>citation that does not equal the pin file) would close the class rather than this instance, and is probably the better shape than a one-off prose edit.What #10270 did about it
Nothing to these sites — out of scope. It measured its own two read points at
9a3daf8d3and cites that, so the two new records are correct; it does not "fix" the four older citations. Worth knowing when readingcomponent.zod.ts: two icon docblocks name one pin and two name another, and only the newer pair matches.objectui-sha.82a94170cis not reachable in the shared../objectuicheckout — it is shallow (git rev-parse --is-shallow-repository→true), andgit cat-file -t 82a94170cfails. Re-measuring at the current pin is the tractable route; re-verifying what the old citations claimed needs a deepened fetch first.Dedup checked: searched open and closed issues for stale pin citations, for
82a94170c, and for pin-bump/describe drift — the matches (#10129, #10136, #6162, #4290 and the other bump-lane cards) are all about the bump machinery itself, none about prose that cites a pin going stale after one.Backlink: #10053.