← board

T: append the session trailer from a hook, not from memory

Decided in decided/decide-the-ticket-lock-is-too-heavy-for-a-per-minute-commit-loop (owner, 2026-08-30). That ticket rejected file locks and lock-dropping; this is the one piece it accepted, and it is tooling, so it is T's.

The measurement

Over origin/master 2026-08-29 18:00 -> 2026-08-30 09:00, excluding watcher commits (tstate* — a daemon with no session, correctly untrailed):

agent commits   1262
with trailer     422  (33%)
missing          840

The ticket that prompted this cited 219/607; the true rate is worse. The cost is not hypothetical: frankA hit a near-miss in ir_codegen.inc and could not identify the two sessions it would most have collided with, with the whole log in front of it.

Why a hook works where instruction does not

CLAUDE_CODE_SESSION_ID is set in every agent's environment (verified 2026-08-30). A prepare-commit-msg hook reads it and appends the trailer unconditionally, so the population that currently skips it — hurried commits, scripted commits, mid-refactor banks — is exactly the population it covers.

The repo already ships a tracked hook (.claude/hooks/no-full-suite.sh, wired in .claude/settings.json), so the pattern and the install path exist.

Requirements

Gate

Track T's own tooling gate as defined in devdocs/dev/track-t.md (T holds the PXX_TRACK=T escape for it), plus the functional check that actually settles this one: make a commit with CLAUDE_CODE_SESSION_ID set and one with it unset, and confirm the trailer appears in the first and not the second. Also confirm a rebase of a trailered commit does not duplicate it.

Verify after landing

Re-run the attribution count over a later window. The number to move is 33% -> ~100% of agent commits; watcher commits should stay at 0%.

Deprioritised 2026-09-02 — the Track T tooling backlog was cut as a pile

This ticket is not being called wrong. It was moved as part of a pile, not judged individually, and nothing here disputes its finding.

Owner decision. 73 of the 74 open track: T tickets were filed between 2026-08-31 and 2026-09-02, 58 on one day. The pile was too large to work through and returned almost nothing, and a ticket nobody will fix does not sit neutrally — it stays in the ranker forever at zero value, which is the argument CLAUDE.md already makes for a terminal folder over a low prio.

Four were kept in the ranker on a purely structural test — an active umbrella or a hard blocked-by: edge from live work: umbrella-one-full-tier-run-with-no-red-tier, feature-t-freebsd-image-and-runner, and the two regression-test-core-* reds that block the umbrella.

Kept, not deleted, for two reasons: so the finding is not rediscovered and refiled from scratch by the next agent who trips over it, and so it can be pulled back if what it touches becomes load-bearing.

To revive it: move it to the owning lane's backlog, set status: backlog, and say in the ticket WHAT CHANGED to make it matter now. Restoring it because it reads well is how the pile comes back.