Changes touching this path
- Skills hygiene: adopt the invocation split, give the binary preamble one home, fix describe -m guidance (#561)
d6a368bf · dbf3dbe6… - Sweep the rust-1.96 clippy debt; document the land-holds-the-binary hazard (#667, #681)
26cfbaa9 · dbf3dbe6…diff - a view step refuses over work no change records, and a primary finalize says so on stderr (#436)
a3248ede · dbf3dbe6…diff - loot <verb> --help prints that verb's usage block plus its accepted flags, not all ~80 verbs (#585)
b87eae53 · dbf3dbe6…diff - a view step refuses over work no change records, and a primary finalize says so on stderr (#436) (conflict resolution: .claude\skills\loot-runbooks\BINARIES.md)
1651fccc · dbf3dbe6…diff - the lane runbooks stop assuming a shell that remembers anything (#883)
Found running ticket-to-lane for #867 end to end. Its step 4 exported
LOOT_SESSION in bash and its step 5 said to cd into the lane, all subsequent
work happening there — and neither survives a call here. Variables do not
carry, and this repo resets the working directory back to the primary after
every call, so step 5 certified a state the harness discarded a moment later
and every one of the ~20 later commands needed its own Set-Location.
The reset is a good default, so the runbooks lean into it rather than fight it:
a lane is a path you carry, not a directory you move into. Step 5 becomes Pin
the lane path.
The rule is shared — land-change runs entirely from a lane — so it lands once
in BINARIES.md beside Where you run them, as the fresh shell, with both skills
pointing at it. It names the two things that ride every call and not just the
first: the Set-Location prefix, and $env:LOOT_SESSION, which was written as a
spawn-time formality even though lane gc is session-scoped too and needs the
same label set again in that call.
Three smaller ones from the same run: step 1 gains a
`git log origin/main --grep=(#<n>)` check, because open is not unbuilt here and
a ticket whose work landed under another id stays open until someone notices;
the BINARIES pointer said before step 1 when the first loot call is step 3; and
the primary-only rule was stated three times, so the guardrail bullet folds
into step 4, where its mechanism explains why step 3 checks at all.
The frontmatter description promised the skill cds you into the lane, which the
step 5 change makes untrue — it now says it hands back the path.
3bf849b5 · dbf3dbe6…diff - the agent runbooks stop naming one machine: the primary is derived, not spelled, and every hazard says which platform it is about (#1006)
130b15a6 · dbf3dbe6…diff - status names landed content instead of letting it read as your edits, and the bootstrap actually puts loot on PATH (#1010, #1009)
d6cddffa · dbf3dbe6…diff - a store knows which machine materialized it: an arrived copy refuses to record until loot rehome, so a bootstrap cannot silently capture every sealed path as deleted (#986)
4c15a2ca · dbf3dbe6…diff - afk-loop no longer tells the implementing subagent to run the implement skill, which a subagent cannot invoke and whose last step commits to a git branch a lane lacks: its implement-in-a-subagent step now hands the subagent a new sibling brief, IMPLEMENT-BRIEF.md, derived from the procedure recent runs inlined, with the ticket, lane and primary filled in. the brief states the split (the subagent implements, tests and describes, and never signs, lands, writes through git or writes to GitHub), has the subagent read the ticket comments and each blocker state reason itself (the hand-off half of #1853), carries the build job cap, the cargo fmt ban, the empty-filter count rule, mutation proofs and the prose checks, and points at BINARIES.md and AGENTS.md for what they own. the review sweep no longer credits implement with a per-ticket review, and HUNT-SECURITY names the subagent instead. a planted home-directory path in the brief turned runbook_portability red (2 passed, 1 failed), BINARIES.md now cites the portability test at its crates/loot-first path, where #1082 moved it, and the workspace suite is green (#1815)
03446134 · dbf3dbe6…diff
Renames are not followed. loot's tree maps a path to an address, so a rename is a delete and an add. This list is the history of the name, not of the bytes.