Set the objective and acceptance criteria, then explicitly Run. Configured agents carry out the engineering; follow results and intervene when needed.
| You want to… | Start here | Then use |
|---|---|---|
| Understand autonomous work and completion | Overview | First-project tutorial |
| Configure or operate an instance | Configuration tasks | Field lookup, operating guide, runbook decision map |
| Change the implementation | Development guide | Architecture, validation |
| Use a logo or badge | Brand assets | Downloads and embedding examples |
| Answer a precise question, including as an agent | Question-to-owner map | Specifications, reference index |
Planners delegate and sequence child work; Executors implement, investigate and test. Configured review can send findings back for correction. The root Planner assesses the owner's objective and remaining authorized work before completion, without requiring you to approve each transition. See the work and review loop.
The aim is useful coherent delivery against the objective, not activity volume; investigation and justified no-change can be meaningful outcomes too. The output is work in your target workspace, supported by records and evidence. DONE is configured acceptance, not independent software correctness or automatic deployment. Work can remain blocked, failed or unresolved. Making routine supervision mostly unnecessary is the aim, not a measured reliability promise.
Saivage runs against a target workspace in deployment-provided isolation. Agents with command tools can modify files, execute programs and use Git. Provider calls can incur charges. Neither a disposable copy nor loopback binding is an agent sandbox; see the first-use prerequisites.
Records, selected conversations, execution observations and provider evidence make work inspectable. They are not a complete ledger of all changes, proof of model perception, or a guarantee of correct delivery. Persistence is loss-tolerant. Use the evidence guide to interpret what was actually retained.
The guides teach tasks. System requirements own functional behavior; UI needs and UI contracts own operator requirements and exact presentation. Use the specification map to choose a topic. System architecture owns implementation structure; its owner map helps locate a component. The runbook owns operating procedures. Repository development policy remains in AGENTS.md. Editing these pages does not load them into runtime agents or authorize an operation.