Branch adjudication, 2026-08-31

Adjudicated by the BRANCHLAND convergence lane against main at 6cb1269b (the sweep ran while main was moving under live lanes; it started at ec806db7 and every conclusion below is of the form "main already contains this", which main moving forward can only strengthen).

git branch --no-merged main counted 50 branches when this began. Forty-seven of them are retired here. Three are live and were not touched.

What the sweep found

Not one of the fifty branches held work that main lacks. This is not the usual "the merge is hard, give up" conclusion — it is the measured one. Main absorbed every branch's content between Aug 25 and Aug 31, mostly under different commit names, which is exactly why git branch --no-merged kept reporting them as outstanding. The refs were stale pointers, not pending work.

Method, and why it is trustworthy

Three independent checks had to agree before a branch was retired.

1. Patch equivalence — git cherry main <branch>. A - means an equivalent patch already exists in main's history after the fork point. 41 branches were - on every single commit.
2. File-level sweep — for all 50 branches, the set of files present on the branch but absent from main. Nothing branch-unique survived this. The three paths that appeared on ~45 branches at once (crates/dclutch-liability-basis-v2-kernel/src/product_claims.rs, .../tests/product_claims.rs, programs/dclutch-trading-sbf/src/series/lifecycle.rs) are main's own deliberate deletions — 8bdc191b finished the DCLTLNK2 deletion, b20256ee took the lifecycle artifact's name off the funding module. Old branches simply still carry files main removed. Likewise packages/dclutch-cli/src/submit.ts, deleted on main by 7c2de1e5.
3. Landing-commit resolution — for every retired commit, the commit on main that carries the same work, resolved by subject match and, where the subject was rewritten, by file-content verification. Those hashes are in the tables.

For the branches whose commits were not patch-equivalent, a fourth check ran: byte-size comparison of every file the branch touched against main's version of the same file. In every case main's file was identical or larger — main holds a superset, never a subset. Details in the second table.

Resurrecting anything retired here

Every tip SHA is recorded below. git branch <name> <sha> brings any branch back intact; the objects stay reachable through the reflog. This document is the tombstone, so the recovery instruction lives with the evidence.

Retired: re-landed on main under a different commit name

Every commit on these branches is patch-equivalent to a commit already in main (git cherry reported - throughout). The hash in the last column is main's copy of the branch's tip commit.

Note the pair lane/fractional-twin-20260828 and lane/fractional-twin-current-20260828: two branch names, one commit's worth of work, both resolving to the same 6d1a9bc8. A branch was cut twice for the same lane and only one copy was ever needed.

Retired: work re-landed in adapted form, verified by content

These branches carried commits whose patch-ids do not match anything in main — git cherry said +. Each was checked at the file level instead. Main holds the work; it was reshaped on the way in, so the patch-id moved.

Held: live lanes, deliberately untouched

Also checked and requiring no action: lane/closeseal-20260831 (60a21da6), lane/basis-d-20260831 (c8a9e0f4) and lane/genseven2-20260831 (9ccee8c4) are all already merged to main and so never appeared in the unmerged list. lane/allkeys no longer exists as a ref — it landed through the merge e7805d62 and was cleaned up before tonight.

Landed: lane/basis-d-20260831

One branch in this sweep was neither retired nor held: BASIS-D finished while the adjudication was running and was handed over as landable. It had committed on-branch only because main's Cargo.lock held another lane's uncommitted lines at the time; by the time this lane reached it the lock was quiet.

Landed as ffdc63f1, carrying aac98afd "basis: the kernel de Boor ports into the codec, weights first and rounding not yet" — 6 files, +953: spline_eval_v3.rs (483), spline_differential_v3.rs (450), and the runtime_v3.rs / lib.rs / Cargo.toml / Cargo.lock wiring.

Verified before the merge commit, twice, because main moved 12 commits during the first build and the verification was redone at the new tip rather than trusted across the gap:

• spline_differential_v3 (9 tests) and basis_corpus_v3 (6 tests) — all green.
• All three generated-byte guards cmp-clean post-merge: check-generated-basis-corpus-v3, check-generated-runtime-v3, check-generated-v3.
• cargo build --workspace — exit 0.

After

git branch --no-merged main: 50 before, 3 after. The three are live lanes — lane/fee-core-20260830, lane/fee-tx2-20260831, lane/genseven2-20260831 — which is what that command is supposed to be for. It can be trusted again as a question about pending work rather than a list of ghosts. (lane/fraccheck2-trading-half-20260831 landed on its own during the sweep, and lane/basis-d-20260831 landed through it.)

Not drifting again

git branch --no-merged cannot see re-landing, so it will rot into noise again on its own. tools/branch-census/census.sh is the check that does not: it classifies each unmerged branch by patch equivalence and branch-unique files, discounts files the trunk deliberately deleted, and picks its base deliberately — refusing the stale-main trap that would have argued for six wrong landings in the public wrapper. It runs in 0.3s here and is a report, not a gate.

Fifty names, and forty-seven ghosts;
the work had all come home by other roads
and left its markers standing at the posts.
We read each stone before we let it go.

---

The divergent line: ~/dev/dragons-clutch

Adjudicated read-only. dragons-clutch is public; nothing was pushed, and no ref was deleted there. Dispositions are recorded for a human to execute.

Six integrate/* branches, none of which was ever pushed (git ls-remote --heads origin shows none of them). All six are ancestors of origin/main — git merge-base --is-ancestor <branch> origin/main answers yes for every one, and git cherry origin/main <branch> prints nothing at all, because there is no symmetric difference to report.

A method trap worth writing down. Running git cherry main <branch> in dragons-clutch reports 1578–1631 + commits per branch and would argue loudly for six LANDs. It is an artifact: local main there is 1710 commits stale (tip 445988f2b, 2026-08-25 23:30, against origin/main at ba533ddb3, 2026-08-31 00:29). Five of the six branches fail the ancestor test against local main only because local main predates them. In dragons-clutch, measure against origin/main, or fetch and fast-forward first. This trap does not apply to dclutch, which has no remotes at all — its local main is the trunk.

One genuinely unlanded thing. dragons-clutch's local main carries a commit origin/main does not have: 445988f2b "site: explain the living dClutch successor" (2026-08-25 23:30). It is the only unlanded work in the whole dragons-clutch sweep, and it will be lost silently by any future git checkout main && git reset --hard origin/main. It wants a deliberate decision, not a default. Flagged, not touched.

Scale note for whoever does hygiene next. dragons-clutch holds 201 local branches, 190 of them agent/*. The six integrate branches are 3% of the problem. The same ancestor-of-origin/main test that cleared all six would classify the agent/* population cheaply.

---

The two preserved clones: gone

The brief asked for these to be inspected and explicitly not deleted:

• /private/tmp/dclutch-sites-source.bbC1jj (reported 8 commits on a codex remote)
• /private/tmp/dclutch-sites-src.Uxc5vI (reported 1 commit)

Both are already gone, and nothing this lane did removed them. The machine rebooted at Mon Aug 31 01:42 and macOS cleared /private/tmp. Every one of the 39 surviving entries in that directory has an mtime of 01:43 or later; nothing that predated the boot is left. The two clones were last touched Aug 28 13:30 and Aug 28 07:51, so they went with everything else. They were not preserved — they were unreferenced temp directories that outlived their session by luck and then ran out of it.

What they held, reconstructed from surviving transcript traces:

• Uxc5vI (17 entries) was a checkout of the web app tree, not the monorepo — transcripts name scripts/generate-route-census.mjs, lib/directTicket.ts and lib/directTicket.test.ts inside it, i.e. the apps/dclutch-web source root.
• bbC1jj (5 entries) was created the same minute as the tarball dclutch-sites-ba487c8.hyhdTh (1,448,732 bytes) — it was that snapshot's staging source.

What is recoverable and what is not. The sibling tarballs are named by commit SHA. da31941a still resolves in dragons-clutch ("wrapper: pulse accepted live-activity substrate", 2026-08-28), so the baseline the clones were cut from survives. But ba487c8 and 7a07e50 exist in no repository we have — git cat-file finds no such object in either tree and neither appears in any reflog. Those were commits made inside the temp clones. They are unrecoverable, and any uncommitted working-tree work there is unknowable.

The "codex remote" has no surviving substantiation. dclutch has no remotes configured at all; dragons-clutch has exactly one, origin. No codex remote exists in either repo, and a grep across all of ~/.claude/projects for the clone names alongside codex/remote/origin/clone returns nothing. It was most likely a local-path or sandbox remote that died with its sandbox.

The lesson is cheap to state and was paid for anyway: /private/tmp is not storage. Work that matters goes on a branch in a real repo, the same hour it is made. A clone under /private/tmp is one reboot away from never having existed.