Dream Machine re-checks its evidence before anything gets promoted

What Dream Machine is

A config driven engine for nightly, cloud scheduled, evidence gated repository evolution. The rule that makes it usable: evaluation is not promotion. The machine never merges. A human does.

What changed

Pull request #97 makes the witness re-verify the evidence read set right before promotion, recorded as ADR-0010. Previously evidence could be gathered and then acted on without confirming it still described the tree being promoted.

It follows a repair of union merge damage across the ledger, CLI, compile and witness paths, which is the kind of week that justifies a witness in the first place.

Get started

Node.js. Scaffold a config and compile the routine:

npx dream-machine init --repo owner/name --out dream.config.json
npx dream-machine compile dream.config.json --out PROMPT.md

Expected result: a config file and a compiled prompt containing the full routine — readable before anything runs.

Compile locally and read the routine first. Do not schedule a cycle against a repository you are not prepared to see proposals on.

Use it today

Practical case: a backlog of small, boring, well tested improvements. Input is your repository plus a config; the workflow is a nightly cycle producing gated candidates; the output is a proposal a human reviews in the morning.

Acceptance test: compile the config and read every step before scheduling. If a step surprises you, the config is wrong, not the machine.

Push it further

Experimental commentary. Freeze the model and evolve the harness — that is the bet this project makes, and it is a good one, because the harness is the part you control. The limitation is that nightly cycles accumulate cost and noise fast.

Falsifiable test: run a week of cycles and count how many proposals a human actually merged. If it is zero, the gate is either too strict or the candidate generator is not aimed at anything useful.