Summary
A captain session should start on the project's integration branch (main / staging / develop), not on whatever branch the working tree happened to be left on. Today a captain booted on a stale feature branch and that single fact propagated into every piece of work it did.
Why this matters more than it looks
The captain's current checkout is not just cosmetic — squadrant crew spawn bases each crew worktree on the captain's current branch. So a captain sitting on a feature branch silently hands every crew the wrong base.
In one session (prism-app, 2026-08-18) the captain booted on feat/bug-report, a branch that was 75 commits behind origin/staging and had been untouched for six days. Consequences:
- Every crew spawn printed
base: feat/bug-report. Five crews, five wrong bases.
- Each brief needed an explicit "your worktree may say base
feat/bug-report — IGNORE that and check out X explicitly" line. That is a workaround being copy-pasted into every task, which is the classic sign the default is wrong.
- Any crew that didn't get that line would have branched from a six-day-old base and produced a diff full of phantom changes — reverting 75 commits of other people's merged work.
- The captain's own read-only checks (
git log, git diff, file reads) silently describe stale code unless it remembers to qualify every path with origin/staging.
The failure mode is quiet. Nothing errors. The work just gets done against the wrong tree.
Proposed behaviour
On captain startup, if the checkout is not on the project's base branch:
- Default: check out the base branch (resolved the way
handoff facts already resolves baseBranch — it correctly reported main via the GitHub API in this session) and fast-forward it.
- Do not do this silently if the tree is dirty — uncommitted work must never be stranded or discarded. Warn and stay put instead.
- Respect an explicit user intent — if the operator asked to work on a specific branch, or a config flag pins one, honour that.
- Print what happened either way, so the captain can see the base it will hand to crews.
A softer first version: don't switch, but warn loudly at startup when the checkout isn't the base branch, including how far behind it is. That alone would have caught this.
Related
squadrant crew spawn inheriting the captain's checkout is arguably the deeper issue — a crew's base should probably be derived from the task, not from wherever the captain is standing. Worth considering whether spawn should default to the project base branch and take an explicit flag to inherit.
Repro
- Leave a project checkout on a stale feature branch.
- Start the captain.
squadrant crew spawn <project> "..." — observe base: <stale feature branch>.
Summary
A captain session should start on the project's integration branch (
main/staging/develop), not on whatever branch the working tree happened to be left on. Today a captain booted on a stale feature branch and that single fact propagated into every piece of work it did.Why this matters more than it looks
The captain's current checkout is not just cosmetic —
squadrant crew spawnbases each crew worktree on the captain's current branch. So a captain sitting on a feature branch silently hands every crew the wrong base.In one session (prism-app, 2026-08-18) the captain booted on
feat/bug-report, a branch that was 75 commits behindorigin/stagingand had been untouched for six days. Consequences:base: feat/bug-report. Five crews, five wrong bases.feat/bug-report— IGNORE that and check out X explicitly" line. That is a workaround being copy-pasted into every task, which is the classic sign the default is wrong.git log,git diff, file reads) silently describe stale code unless it remembers to qualify every path withorigin/staging.The failure mode is quiet. Nothing errors. The work just gets done against the wrong tree.
Proposed behaviour
On captain startup, if the checkout is not on the project's base branch:
handoff factsalready resolvesbaseBranch— it correctly reportedmainvia the GitHub API in this session) and fast-forward it.A softer first version: don't switch, but warn loudly at startup when the checkout isn't the base branch, including how far behind it is. That alone would have caught this.
Related
squadrant crew spawninheriting the captain's checkout is arguably the deeper issue — a crew's base should probably be derived from the task, not from wherever the captain is standing. Worth considering whetherspawnshould default to the project base branch and take an explicit flag to inherit.Repro
squadrant crew spawn <project> "..."— observebase: <stale feature branch>.