SKILL.md still hand-derived the worktree list PR #357 automated (#360)

[fdaviddpt]

Closes #360

What

PR #357 merged scripts/lane_setup.py and wired it into commands/tick.md, but skills/manager/SKILL.md -- the document a tick loads first -- still instructed the maintainer to hand-derive the base commit and the live-worktree list before every brief. So the loop documented two procedures for one step.

Both spots in SKILL.md that instructed naming/deriving the worktree list by hand (the Run a fleet, not a queue section and item 6 of the per-brief checklist) now point at scripts/lane_setup.py <issue> instead, in the same "run this, not these are the answers" shape the rest of the file uses.

agents/developer.md is deliberately left unchanged: it already re-derives its own base via origin/<default_branch> rather than trusting a pasted sha, and it receives the live-worktree list from the brief rather than deriving it itself, so it never carried the hand-derivation instruction this issue is about. Argued in the report, not guessed.

Guard

tests/test_content_invariants.py gains _lane_setup_unmet/_requires_naming_the_script, in the same two-copy-invariant shape as the existing #266 (_out_of_tree_write_unmet) and #250 pairs: a document that instructs naming the live worktrees without also naming scripts/lane_setup.py is a finding. The trigger phrase ("live worktree") is chosen to survive the fix's own rewording, with a must-fire control asserting the phrase itself does not silently disappear -- the trap the issue calls out explicitly: a check asserting only "SKILL.md mentions the script somewhere" would pass against a document that mentions it in passing while still instructing hand-derivation three paragraphs later.

Red confirmed against the reconstructed pre-fix wording and against the real pre-fix SKILL.md before the edit; green after.

Evidence, measured

With the hand-copy procedure in force: main moved four times across two ticks, and fix/313 / fix/341 were each briefed onto README.md forty minutes apart because the worktree ownership list was retyped rather than derived -- the correctness half of #317 arriving as a real defect.

Testing

• pytest tests/test_content_invariants.py -k "lane_setup or worktree_naming or pre_360" -q --no-cov: 1 failed / 3 passed before the fix, 4 passed after.
• Full suite python3 -m pytest tests/ -q --no-cov: 2580 passed, 2 skipped (run because the new guard lives in a shared fixture file every other content-invariant test also imports from).
• Changelog fragment: changelog.d/360.fixed.md, verified with python3 scripts/assemble_changelog.py --check --dir changelog.d --changelog CHANGELOG.md (run alone, no --check-links).

Self-review

Spawned an Explore reviewer and an oss:auditor against the committed diff. Both returned NO FINDINGS / FINDINGS: 0. Full exchange in the report's review field and in the note.

Verified by the maintainer

Independent red re-run, against the tag candidate rather than a moving main. A detached
worktree at e4d48de — the commit 0.8.0 was going to be cut from — with this branch's
tests/test_content_invariants.py copied in and nothing else changed:

1 failed, 151 passed
assert not {'skills/manager/SKILL.md': ['the-script-is-not-named']}

One assertion fires and 151 hold, and the failure names the contradiction rather than a missing
string. That is the shape I asked for: a check satisfied by "SKILL.md mentions the script
somewhere" would have passed against exactly the state #360 describes — the script named in
passing while hand-derivation is still instructed three paragraphs later.

The declined half is the better half. agents/developer.md was left unchanged, with a reason
rather than a shrug: it already re-derives its own base against origin/<default_branch> instead of
trusting a pasted sha, and it receives the worktree list from the brief rather than deriving it, so
it never carried the instruction this issue is about. I told the lane either answer was acceptable
with an argument; this is the argument.

Why this merged when it was being deliberately held. It sat green and unmerged through two ticks
so that merging it could not move main out from under 0.8.0's cleared gate 1 (e4d48de, 13/13)
or the release audit's v0.7.0..e4d48de range. That audit has now returned findings, one of them
blocking, so the tag does not get cut from e4d48de and the range has to be re-audited over the
fixes regardless. The reason for holding expired with the verdict; recording it here so the sequence
reads as a decision rather than as an inconsistency.