Brummel/Skills
1
0
Fork 0
Code Issues 3 Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source 
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
This commit is contained in:
Brummel
2026-06-30 14:16:44 +02:00
parent a18c0974e8
commit eec4754c3c
1 changed files with 10 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
boss/SKILL.md
+10 -5
View File
@@ -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