fix(devx): the objectui pin guard tests walk completeness, not object presence

[os-steve]

Fixes#9408

The card is right about the mechanism and I reproduced it byte-for-byte before changing anything. Two of its four suggested repairs are implemented, one is subsumed, and one is not implemented because I measured it and it does not work — details below.

Reproduced first, on two specimens

This container is still a live specimen — the PM triage note expected it not to be. /home/user/objectui is shallow right now, boundary 75444e38a, inside the pin range:

$ git -C /home/user/objectui rev-parse --is-shallow-repository -> true
$ cat .git/shallow -> 75444e38a07e...
$ git rev-list --count --no-merges 665661ab0932..82a94170c405 -> 137 (truth: 191)

Running the unmodified digest against it credited 12 entries to 75444e38a and exited 0 — PR #9398's competing derivation, regenerated. Grafting a second copy at 183d09b78 (the card's own recipe) reproduced the landed record exactly: 36 entries credited to the sink, 110 non-merge commits, and the entry list byte-identical to the pre-correction artifact at 83fe945d6 (119 lines, diff clean). The index arithmetic holds independently: 183d09b78 at index 110, 75444e38a at index 137.

Not implemented: the arithmetic check, because it cannot fire

The card's fourth suggestion — no commit may be credited with more added changesets than git show --name-only attributes to it — is described as catching all three bad runs. Measured against both runs I can reproduce, it catches neither:

specimen	credited to sink	git show --name-only attributes	fires?
boundary 183d09b78 (landed record)	36	72	no
boundary 75444e38a (this container)	12	47	no

It cannot fire on any history. git show --name-only on the sink runs the same empty-tree diff that produced the fault, and the digest's credited set is that attributed set minus the seen dedup — a subset by construction. The comparison is a tautology: no false positives because no positives at all. Pinned as such in the self-test (C12) so it is not reintroduced later as a "cheap backstop".

What replaces it: one true check

findRangeTruncation tests a parentless commit inside the range. That is the harm itself — the sink is the parentless commit — so it catches a --depth clone, a hand-written .git/shallow, a graft, a git replace, and unrelated histories without naming any of them. It is also strictly more precise than asking whether the clone is shallow: a shallow clone whose boundary sits at or before from walks the range completely, and refusing it would be a false positive. In an untruncated history the range cannot contain a parentless commit at all, so a hit is always real.

It lives in classifyRange, the single shared implementation, so objectui-range.mjs cannot derive from a truncated walk either (it already wraps that call in a loud die()).

Deepen first — measured, not assumed

git fetch --unshallow on objectui costs 6 seconds and ~4 MB, and takes the walk from 110 commits to the true 191. A degraded console changeset becomes permanent published CHANGELOG text, so repairing the input beats labelling a truncated derivation of it. The fetch is additive (adds objects, drops .git/shallow; moves no branch, touches no working tree), announced before and after, and opt-out-able with OBJECTUI_NO_DEEPEN=1.

One measured trap it handles: git fetch --unshallow in a checkout with no remote configured exits 0 and changes nothing. The range is therefore re-checked afterwards rather than the fetch status trusted — otherwise this card's failure would simply reappear one layer further in. Pinned in C17/C18.

The other two PM assumptions, tested

• The degraded path is genuinely honest. Confirmed, unchanged: it emits ⚠️ **Degraded list**, "NOT a complete account of the range", and the tip subject only. I extended the reason only — a truncated range must also be distinguishable from an absent endpoint, because the remedies differ and only one is a fetch away.
• to-endpoint validation is missing. Partly falsified. The digest CLI already validated both endpoints (exit 2, verified). The gap was in bump-objectui.sh's own RANGE_OK, which now goes through --check-walkable and covers both.

Tests

18 new checks (C1–C18) in objectui-changeset-digest.mjs --self-test. The truncation is synthesized by writing .git/shallow, so the complete and truncated fixtures are the same commits differing in exactly one file — each assertion is about the graft, not about two repos that differ somehow.

Both directions are pinned, per the explicit ask that a refusal-only test would pass on a guard that refuses everything: C1/C2 keep the complete walk, and C7 is the sharper control — a tree that is shallow with its boundary outside the range must still derive identically (stillWhole.body === whole.body). C7 is exactly the false positive an --is-shallow-repository guard would produce.

Reverse verification, at commit 68615c550: ablating both refusal call sites turns 8 checks red (C8, C9, C10, C13, C14, C15, C16, C17) and the ablated build emits the defect in miniature — 5 releasing of 5 changesets added across 3 non-merge commits with entries 1, 2 and 3 all credited to one sink. C3/C4/C5/C12 stay green by design: they measure the defect mechanism, not the guard. Restored with git checkout HEAD --, byte-identical, green.

Gates run against 68615c550 (working tree clean, equal to head):

pnpm check:objectui-changeset OK (120 checks; digest + objectui-range self-tests)
pnpm check:nul-bytes OK (6122 files)
pnpm check:objectui-pin-fresh --self-test OK

Gate family derived from the changed paths with node scripts/pm/dispatch-gates.mjs, which names check:objectui-changeset alone; check:nul-bytes and the pin-fresh consumer were added because the diff touches them.

Scope

scripts/bump-objectui.sh and scripts/objectui-changeset-digest.mjs only, as dispatched. No changeset: scripts/ is repo tooling and this PR publishes nothing, so it carries skip-changeset.

.github/workflows/cut-rc.yml has the same object-presence test at line 285 and prints "range is walkable, the changeset digest will be complete" on the strength of it. It is currently harmless — that job clones objectui full, deliberately — so I did not widen this PR into a third file; filed separately instead.

Generated by Claude Code

---

Generated by Claude Code