Super Simple Software Factory (SSSF)

Reusable combination of agents plus code: deterministic Python ADW scripts own sequencing, retries, and acceptance; coding agents (Pi in v1) work inside bounded phases; typed JSON envelopes carry context between them; everything streams into SQLite for the polled visualizer. Agent proposes, code disposes.

Startup

Three steps. Then stop.

1. Read cookbooks/sssf_overview.md, the system map.
2. ls adws/adw_*.py and read each file's Phases: docstring line.
3. Print the ADWs as a table, name, the chain, one line on when to reach for it, and wait for the engineer's request.

| ADW | Chain | Use when |
|---|---|---|
| adw_scout | engineer → scout | read-only recon; nothing changes |
| adw_simple_sdlc | plan → build → test → review → document, 3 commits | the work is real and its shape is not obvious |

Nothing else. No trace-db queries, no reading the config or the ADW scripts' bodies, no repo inventory, no last-runs summary, no diagnosing an old failure, no "current state" dashboard. None of it was asked for, and it is not free:

• Volunteered state is guessed state. An orchestrator that improvised a status board queried a runs table and a payload column, neither exists (sessions, payload_json). The spec that would have said so is references/observability.md, one lazy read away. Probing to look prepared is how you end up confidently wrong in your first message.
• It spends the context the real task needs, before you know what the task is.
• It is stale on arrival. State printed before the request describes a system that the very next run changes.

Everything else, the db schema, the roster, the handoff contract, is lazy-loaded through the routing table below, when a request actually calls for it. Reading it early defeats the mechanism.