Define the /boss session anchor as the captured start HEAD, not the live main ref #16

New Issue

2026-06-30T14:14:55+02:00

Brummel commented

2026-06-30 14:14:55 +02:00

The rollback-sandbox section defines the /boss session anchor as the
live main HEAD, but an autonomous run is not always on main — under a
git worktree the run sits on its own branch.

boss/SKILL.md:333-335 reads: the orchestrator "notes the current main
HEAD — the last user-ratified state — as the session anchor", and
boss/SKILL.md:535 speaks of "a spec already committed on main". The
section is written in an on-main mental model.

The correct anchor is the HEAD revision captured at run start (a fixed
sha), not the live main ref — which is what the loop already captures
(implement/workflows/implement-loop.js:245, git rev-parse HEAD). In
the primary clone on main the two coincide; in a worktree the run is on
its own branch and a git reset --hard to the anchor only moves that
branch (it cannot reach main).

Claim (unverified, low risk): if the primary clone is ever parked
off-main at spawn, resolving the anchor as the live main ref instead
of the captured start HEAD could reset the session branch to a
non-ancestor commit. Capturing the start-HEAD sha avoids it.

Acceptance:

boss/SKILL.md defines the session anchor as the captured
start-HEAD revision (a fixed sha), branch-agnostic, and notes the
worktree case where it is not main.

The rollback-sandbox section defines the `/boss` session anchor as the live `main` HEAD, but an autonomous run is not always on `main` — under a git worktree the run sits on its own branch. `boss/SKILL.md:333-335` reads: the orchestrator "notes the current `main` HEAD — the last user-ratified state — as the session anchor", and `boss/SKILL.md:535` speaks of "a spec already committed on `main`". The section is written in an on-`main` mental model. The correct anchor is the HEAD revision captured at run start (a fixed sha), not the live `main` ref — which is what the loop already captures (`implement/workflows/implement-loop.js:245`, `git rev-parse HEAD`). In the primary clone on `main` the two coincide; in a worktree the run is on its own branch and a `git reset --hard` to the anchor only moves that branch (it cannot reach `main`). Claim (unverified, low risk): if the primary clone is ever parked off-`main` at spawn, resolving the anchor as the live `main` ref instead of the captured start HEAD could reset the session branch to a non-ancestor commit. Capturing the start-HEAD sha avoids it. Acceptance: - [ ] `boss/SKILL.md` defines the session anchor as the captured start-HEAD revision (a fixed sha), branch-agnostic, and notes the worktree case where it is not `main`.

Brummel referenced this issue from a commit

2026-06-30 14:17:51 +02:00

docs(boss): anchor the rollback sandbox on the captured start HEAD

Brummel closed this issue

2026-06-30 14:17:51 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: Brummel/Skills#16