A config-driven engine that runs one research-and-evolution cycle
against a repository each night. In an isolated cloud session it forms
one falsifiable hypothesis, tests it against the
repo’s real benchmarks, and records the result as a gist, an issue,
and a draft PR. Every run ends in ACCEPT,
REJECT, or INCONCLUSIVE. It never merges — a
human reviews and decides.
Freeze the model. Evolve the harness.
Evaluation is not promotion — the machine never merges; a
human does.
v0.1.0 — live on npm, CI green. Run it now with
npx dream-machine init. Six packages, 85 tests, a
working CLI + TUI, and a self-hosting nightly routine. See
npm and
ADR-0001.
What it is
An engine, extracted from two routines that already run.
Two nightly cycles run today in a cloud scheduler — one against
Ruflo, one against MetaHarness — each driven by its own ~800-line
prompt. They run the identical 26-step pipeline and differ only in a
small, well-defined set of per-repo details. Two instances is exactly
enough to see the seam: the shared spine becomes an engine, and the
differences become a dream.config.
The compiler is the core
A dream.config declares the per-repo delta — rotation
slots, cron, evaluator entrypoints, ADR shape — and compiles to the
full routine prompt. The scheduler copy and the in-repo mirror
become build outputs of one source, so the drift between them stops
being a convention and becomes structurally impossible.
Composed, never reimplemented
The expensive stages delegate to the packages that already own
them: flywheel for the promotion gate, darwin for bounded
evolution, redblue for adversarial critique. They are optional
backends selected by config — a night without any of them is a
degraded night, not a failed one.
Hard authority boundaries
The session never merges, never self-promotes flywheel state, never
weakens a test or a threshold, never edits gold answers, never
force-pushes, never publishes packages. Its only publication
surfaces are a gist, an issue, and an always-draft pull request.
The nightly pipeline
Thirteen stages, one verdict.
Scroll to walk the cycle. Each stage narrows what tomorrow needs to
search — the system optimizes for shrinking the search space, not for
producing pull requests.
Nightly cycle
Stage 01
Read the ledger
The night begins by reading every previous night. The ten-column
LEDGER.md is the only durable cross-night memory,
and it feeds deterministic learning signals: suppress a finding
already made, bias away from a surface that has gone fourteen
nights without a merge, throttle a low-scoring streak.
@dream-machine/ledger
Stage 02
Research the surface
One deep surface and a couple of scan targets come off the
rotation declared in dream.config. The session reads
the repository and the field around it — competitor frameworks,
published results, the repo's own ADRs — before it is allowed to
have an opinion.
Stage 03
Freeze one hypothesis
Exactly one falsifiable claim is written down and frozen before
anything is measured. Freezing is what makes the night honest: a
hypothesis that can be edited after seeing the numbers is not a
hypothesis, it is a summary.
Stage 04
Build a concrete candidate
The frozen claim becomes an actual change — a diff you could
read, not a description of a direction. Vagueness here is what
lets a loop declare success without ever having tested anything.
Stage 05
Measure the baseline
The unmodified harness is measured first, in this session, on
this checkout. A baseline inherited from a previous night is a
baseline measured under conditions nobody re-verified.
Stage 06
Evaluate the candidate
The candidate runs against the same tasks, the same sample size,
the same frozen model. Only the harness is allowed to vary — that
is the whole point of freezing the model, and it is what makes
the difference attributable.
Stage 07
Adversarial critique
A red/blue harness attacks the result: what would have to be true
for this measurement to be wrong? Then the reward-hack scan asks
the harder question — did the candidate improve the work, or just
improve the score?
@metaharness/redblue
Stage 08
Bounded Darwin evolution
If the candidate survives critique, a fenced evolution stage
explores variations around it under a fixed generation and
population budget. Bounded is the operative word: the search is
allowed to be creative, not allowed to be open-ended.
@metaharness/darwin
Stage 09
Retain flywheel evidence
Every measurement is captured as a receipt that can be replayed
later, and the promotion gate decides — on the retained evidence,
not on the narrative — whether the candidate cleared the bar.
The session may read the gate's answer. It may never move the
bar.
@metaharness/flywheel
Stage 10
Stamp the witness
The night's published gist and the session's commit are hashed
together —
sha256(sha256(gist) + SESSION_COMMIT) — into a
single witness. Anyone can re-derive it; a single changed byte in
either input breaks it. Provenance stops being a claim and starts
being checkable.
@dream-machine/witness
Stage 11
Publish the finding
An issue goes up carrying the hypothesis, the measurement, the
critique, and the witness. It goes up whether the answer was yes
or no, because the point of the night is the finding, not the
outcome.
Stage 12
Open a draft pull request
If there is a change worth proposing, it opens as a draft — every
night, without exception. This is the invariant everything else
protects: the machine recommends, and a human decides. Promotion
is a human act.
Stage 13
Write the ledger row
The night closes by appending one row: date, surface, hypothesis,
finding, verdict, evidence, artifacts, witness. The row is
written even when the run halts on budget — a night with no row
is a night that never happened, and tomorrow would have to
rediscover it.
@dream-machine/ledger
The three verdicts
Every night ends in exactly one. Never a fourth, never silence.
The verdict vocabulary is deliberately small and deliberately
unflattering. Two of the three outcomes produce no pull request at
all, and both of them are good nights.
ACCEPT
The frozen hypothesis survived measurement, critique, and the
reward-hack scan, and cleared the promotion gate on retained
evidence. The result is a draft pull request and an issue — a
recommendation for a human, not a merge.
REJECT
The hypothesis was measured cleanly and did not hold. This is a
successful night: a question that was open at
dusk is closed by morning, and tomorrow's search space is smaller
for it. Most nights should land here.
INCONCLUSIVE
The measurement could not be taken — blocked credentials, a budget
halt, a sample too small to separate the arms. Stated with its
reason, this is also a success, because the one thing it refuses to
do is guess. A ledger row is written either way.
What it composes
Optional backends, selected by config.
The Dream Machine builds on the ruvnet stack as config-selected
evaluation backends — never hard dependencies. It follows the source
routines' own rule: use the best available implementation, and do not
introduce a dependency merely to satisfy a prompt.
The CLI surface is small on purpose: scaffold a config, compile it,
and then work with the two durable artifacts a night produces — the
ledger row and the witness.
Terminal
npx dream-machine init # scaffold a dream.config for this repo
npx dream-machine compile # dream.config → the routine prompt
npx dream-machine ledger # parse / append / verify LEDGER.md
npx dream-machine witness # stamp and verify a night's provenance
npx dream-machine schedule # prepare the nightly routine
npx dream-machine tui # browse past nights in the terminal
Walk each of these end to end in the
tutorials, or see what a week of
nights looks like on the
dashboard.