Repository navigation
Product Mode
From "add a test to this repository" to "build this product from a prompt". The roadmap is docs/PRODUCT_MODE.md; the decision is ADR 0007. Work is tracked on the project board and the milestones.
A product orchestrator sits above the proven task graph; the task graph stays the unit that builds one feature.
-
Interview (Opus, two to four questions) and a normalised
PRODUCT.md: vision, users, features as testable acceptance criteria, quality bar, stack, approved dependencies. A human approves it. - Bootstrap: git init, scaffold from the toolchain profile, CI, walking skeleton with a smoke test, lint and tests green before the first commit. Creating a GitHub repository is a separate confirmed step.
- Milestone loop (M8): decompose the next milestone into GitHub issues, run each feature through the task graph with the tier pinned on a milestone branch, verify the integrated result (full suite, smoke and e2e against the running app, lint, types, build, audit), one Opus milestone gate that any failing check overrides, one milestone PR, a human merge, then update the progress file and replan if needed.
- Release gate (M11): the product-ready bar: tests with a coverage floor, lint and types clean, build succeeds, smoke and e2e pass, dependency audit and secret scan clean, README run instructions executed by CI, CHANGELOG, LICENSE and a release artifact present.
Product memory lives in the target repository: PRODUCT.md, .scio/product/progress.json, docs/adr/, NOTES.md. There is no product-level dollar cap by default; per-feature tier caps, stall caps and iteration caps remain as runaway guards, and cost is reported at every approval stop. One writer, so a product builds serially.
| Milestone | Deliverable | Done when | State |
|---|---|---|---|
| M6 Foundations | Toolchain profiles behind one protocol (ADR 0009); --tier pins the route; every declared setting read |
regression pass^5 = 1.00, live t001 unchanged, no Python command outside the profile | merged (PR 41) |
| M7 Greenfield bootstrap |
scio new: interview, PRODUCT.md, scaffold, git init, CI, walking skeleton (ADR 0010) |
an empty directory becomes a repo with green CI and a smoke test, Fake and live | built; live run $0.15; in review |
| M8 Decompose + milestone loop | progress file, GitHub milestones and issues, features in sequence, integration verify, milestone PR, resume | a two-milestone Fake product survives crash and resume; one live milestone | next |
| M9 Dependencies + runtime | Docker default, two-phase network, install_deps / run_app / delete_file, e2e runner |
a product with a third-party dependency and an HTTP server passes black-box e2e | planned |
| M10 Second stack |
node-ts profile, stack detection, stack-agnostic acceptance grading |
the same spec builds in Python and TypeScript | planned |
| M11 Product-ready + evals | quality bar, release gate, tag and artifact; p001 CLI, p002 REST API, p003 web app | p001 to p003 pass live; rows in EVAL_HISTORY | planned |
- Every structured output that drives control flow gets a normaliser; the orchestrator, not the model, picks the next feature.
- A hint is not a pin: each feature run's tier is pinned.
- The passing path needs caps too: milestone loops have iteration and stall exits.
- The Fake provider reproduces only the shapes you thought of: every milestone ends with one kept live run, read before anything is scaled.
- Cost grows with the transcript: feature contexts stay small and cached; product memory reaches them only as a summary.
- Docker is not installed on the dev machine; M9's live checks run in CI or on a machine that has it.
Each milestone adds an end-to-end Fake test that is its executable acceptance (M7: an empty directory to a green repository through two human stops, plus crash-style resume), keeps the regression suite at pass^5 = 1.00, and runs one live trial. M8 adds the named tests for the orchestrator-versus-gate dynamic (a failing check overrides the model verdict), crash-and-resume of a two-milestone product with no duplicated issues or commits, and escalation records across features. The rejection-ledger and middle-out handoff ideas from docs/IDEAS_TRIAGE.md are measured before they are built.