issue-lane

name	issue-lane
description	"1 issue = 1 lane" lifecycle discipline for herdr pane fleets. Use when assigning an issue to a lane, when an issue closes, when auditing lanes, or to check your own lane hygiene as a worker. Tab and pane labels must both carry the issue ID; lanes die with their issue; the model stays on the fleet default gear unless a ledger entry authorizes a boost.

issue-lane — 1 issue = 1 lane lifecycle discipline

English | 日本語

Invariants (4)

1. 1 issue = 1 lane = 1 writer. The issue ID appears on both label layers: tab label first word = <ISSUE-ID>; pane (agent) label = <space>/<ISSUE-ID>[-role]. Disagreement between the layers is reuse drift. Resident PO panes (tab label po) are exempt.
2. A lane lives exactly as long as its issue. Created at assignment, torn down at Done/Canceled. Never reuse a lane for the next issue — fresh lane, fresh model gear, fresh history, fresh worktree. Rotating to a fresh session mid-issue is not reuse but recommended hygiene: state lives in receipts / PRs / the tracker, so sessions are disposable, and long token-heavy sessions degrade (declaration stalls, hollow output). "1 issue = 1 lane" means one at a time; serial replacement on the same issue is fine — and a free refresh comes before a paid model boost.
3. Model = fleet standard gear by default. Lanes may be Codex or Claude Code agents — default implementers: Codex gpt-5.6-terra (medium; boost gear sol, effort low), Claude Code sonnet (boost tier e.g. opus). A higher gear is legitimate only while the fleet's model ledger holds an open entry for this lane.
4. No lane registry file. Truth = live + the issue tracker, cross-checked. A registry would be a second, drifting authority.