The seven phases

Three phases on the room side turn evidence into a spec and tests. Four on the clean side turn the spec into an app. Only the spec and the visible tests cross the wall.

Room side: sees the evidenceClean side: never sees it

Setup

init-run.mjs creates the app tree and the room, copies the phase checklist into .remake/progress/checklist.md, and starts the live progress page. You put evidence in <room>/evidence/ and list known open-source reimplementations of the target under blocked.

1Inventory room

Agent: observer (Opus)
Sees: your screenshots, recordings, the app's public docs
Writes: every menu, tool, shortcut, dialog and file format, each with an id

You get the counts and a list of everything marked UNKNOWN, so you can add the evidence that is missing before anything is specified.

2Spec room

Agent: spec-writer (Opus)
Sees: the inventory and the evidence
Writes: spec.json and spec.md: behaviour only, no expression

The spec says what the program does, not how any other program does it. Each feature is marked must, should or could.

You approve it here. The run waits for an explicit yes in chat or on the run page. Requested changes go back to the spec-writer. Only an approved spec is published into the app tree.

3Tests room

Agent: test-writer (Opus)
Sees: the spec only, never the evidence
Writes: conformance tests: ~70% visible, ~30% sealed

Tests come before any code. The visible set is copied into the app tree; the sealed set stays in the room. The hashes of both sets are recorded so nobody can quietly edit the yardstick later.

4Pilot clean side

Agent: builders
Sees: spec and visible tests
Writes: 10 features, then a cost extrapolation

The pilot runs build and verify on 10 must features and reports tokens, time and pass rates per feature.

You approve the cost here. The extrapolation for the full run comes before the full run.

5Build clean side

Agent: 1 to 5 builders (Sonnet), one worktree each
Sees: spec and visible tests
Writes: the app

Each builder takes one unbuilt feature in its own git worktree of the app tree, so the room is never under its feet. Passing branches are merged. Builders cannot edit tests/, spec/ or remake.json, and the harness, not the builder, decides pass or fail.

6Verify clean side

Agent: verifier and harness
Sees: visible results, sealed counts
Writes: hash check, stub scan, parity report

Runs after each merge batch. A hash mismatch on the tests or spec, or a stub posing as a feature, stops the run. How the score is computed

7Review clean side

Agent: reviewer via Codex CLI (Claude if Codex is absent)
Sees: the diff and the spec
Writes: ranked findings

Runs every batch. Must-fix findings go back to Build as new work.

Report

When the score stops rising or you stop the run, you get the parity table and the wall log count. Runs resume from progress files and git checkpoints after a crash or a usage-limit stop.