From eec4754c3c93fbc0b22940adf374e233451486cf Mon Sep 17 00:00:00 2001 From: Brummel Date: Tue, 30 Jun 2026 14:16:44 +0200 Subject: [PATCH] docs(boss): anchor the rollback sandbox on the captured start HEAD Define the session anchor as the HEAD revision captured at run start (a fixed sha), not the live `main` ref, and spell out the git-worktree case: the run sits on its own branch, so a reset to the anchor only moves that branch and cannot reach `main`. Keeps the wording correct when the run is not on `main`. Also rephrase the veto case from "committed on `main`" to "committed below the session anchor (ratified history)". closes #16 --- boss/SKILL.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/boss/SKILL.md b/boss/SKILL.md index 7ee5fc9..7852283 100644 --- a/boss/SKILL.md +++ b/boss/SKILL.md @@ -331,10 +331,14 @@ decide. ### The rollback sandbox `main` stays sacrosanct **below the session anchor**. At the start of an -autonomous run the orchestrator notes the current `main` HEAD — the last -user-ratified state — as the **session anchor**. Everything it then -commits autonomously, this run, and has **not pushed**, is its own -sandbox above that anchor. +autonomous run the orchestrator captures the HEAD commit it starts from +— the last user-ratified state — as the **session anchor**. The anchor is +that captured revision (a fixed sha), not the live `main` ref: in the +primary clone on `main` the two coincide; in a git worktree the run sits +on its own branch and the anchor is that branch's base, so a `reset` to +the anchor only ever moves the session branch and cannot reach `main` at +all. Everything the orchestrator then commits autonomously, this run, and +has **not pushed**, is its own sandbox above that anchor. Inside the sandbox, and only there, the forward-only rule is relaxed: when the orchestrator runs itself into a dead end — `implement` stays @@ -532,7 +536,8 @@ pause. The boss-side contract is just this: capability> myself and started the implementation plan — reply to veto." No internals, but enough identity to act on. - **A veto is a forward correction — or, within the run, a rollback.** - If the user vetoes a spec already committed on `main`, undo it forward + If the user vetoes a spec already committed below the session anchor + (ratified history), undo it forward — revert the spec commit, discard the downstream working-tree work with `git checkout`, file the redirection. *Within* the autonomous run, the rollback sandbox (§ Direction freedom) is the additional remedy: the