What a carrier writes down.
Before it stops, a carrier saves a baton. It says what is true now and what to do next, with how to tell it is done. It names the traps, and the evidence for what it says. Its references point out to the real work, the sources, and the places secrets live.
Every accepted save gets the next number: r1, r2, r3. A saved revision is never edited.
- True now
- The migration ran on staging. Prod is not touched.
- Next action
- Deploy
4e11adcto prod behind the flag.Done when/versionshows4e11adc. - Traps
- Don't re-run the migration on staging. It will duplicate invoice rows.
- Evidence
- The staging run log at 02:31 shows every migration step passed.
- References
- Required work: pull request 482
- secret:
vault:billing/prod-db, where the database password lives. Never the password itself.
One carrier at a time.
Each carrier's stretch is a leg. A piece of work has one live leg at a time. It moves to a new carrier in one of two ways: offered and caught, or dropped and caught.
- Held
Carry.
A carrier holds the work on a lease, 30 minutes by default. Each save pushes the lease on. While it holds, nobody else can save.
- Waiting
Offer.
When it is done for now, it offers the baton to one named handle, or to anyone in the workspace. The offer waits until it is caught, taken back or its deadline passes.
- Held
Catch.
The next carrier catches the baton and starts its own leg from it. If two try at once, one wins, and the other is told who did.
- Dropped
Drop.
If a carrier stops without offering, or its lease runs out, the work shows as dropped: who held it, since when, and its last save. Anyone in the workspace can catch it.
After a drop, check before you repeat.
A carrier can stop in the middle of a step, after its last save. So when the next one catches a drop, the tool says whose contact was lost, how and when. It names the last accepted save. Then it asks the new carrier to check every step before doing it again.
It may have done more than one step after that save, so every step of the next action, and any step the baton names as in flight, may already be done, not only the first. Before you do each of those steps, check its outcome through the references, even a step that looks safe to repeat: skip it if it was done, and do only the rest if it was partly done. If you cannot tell for a step, stop and block the work.
On the record, even offline.
Every hand-over is on the record.
The record keeps each save, offer, catch, drop, note and refusal in order. Nothing in it changes afterwards. Read it with
handsoff history <work>, or sign in and open the work in your browser.No network? Your writes wait.
If the tool cannot reach the service, it keeps each write on your machine as pending. It sends them the next time the service answers, for up to 24 hours. A write only ever lands on the leg and revision it was made against.
handsoff pendinglists what is waiting.Any agent, or a person.
Claude Code and Codex get an adapter. It tells each new session about Handsoff and reports when the session starts and stops. Any other runtime, or a person, runs the same commands.