Purpose
The Back Office turns a specifically approved outcome into a bounded, verified change. It keeps work close to the project that owns it, preserves unrelated work, and records evidence for review.
Steve is the hinge: Front prepares; Back implements; nothing is approved until he says so.
Use one clear outcome per conversation. A short investigation may remain with its parent task; unrelated goals deserve separate sessions and separate review.
Working loop
- Enter — Open the project that owns the outcome and inspect its instructions.
- State — Describe the result, constraints, permissions, and acceptance checks.
- Inspect — Read the relevant code, documentation, history, and working state.
- Change — Make the smallest coherent edit that fully addresses the outcome.
- Verify — Run checks proportionate to the risk and inspect visible behavior.
- Review — Examine the diff, preserve unrelated work, and record a clear handoff.
What crosses the boundary
Packet in
The ask, constraints, Stewardship vetoes, and acceptance conditions arrive as one specifically authorized packet. The packet supplies context; the implementation state must still be checked.
Verified result out
Back Office returns evidence of the result or a bounded handoff with remaining gaps. Steve authorizes each crossing. A packet is not standing access or standing implementation authority.
Durable context
- README explains project identity, purpose, layout, operation, and recovery.
- AGENTS.md records durable instructions for work in its directory.
- Decisions record consequential choices and reasoning when a project benefits.
- Tasks track unfinished multi-session work only when a simpler issue or conversation is insufficient.
Safety and review
Before changing, confirm that the request authorizes the mutation, protect credentials and private records, and check for unrelated or concurrent work.
Before declaring success, run the appropriate syntax, build, test, health, and behavior checks; review the diff and repository state; and separate verified facts from inference and uncertainty.
Multiple sessions
Several read-only conversations may inspect the same project. Concurrent writers require isolated branches or worktrees. Delegated work should be bounded; the main conversation remains responsible for integration and verification.