You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Not a workflow file in the repo. A /schedule cloud routine
(trig_01HpEqAcEP7wzrxy3TzakrQ2, "Ruflo Nightly Dream Cycle", cron
0 6 * * * UTC) — a fully isolated cloud session with its own fresh git
checkout of ruvnet/ruflo, no access to any local machine, spun up once a
night and given one long, structured prompt.
Grepping the repo for a generator will come up empty. That's expected: the
routine lives in Anthropic's cloud scheduler, not in the repository it
studies. It reads and writes back through git/gh, the same as any other
contributor would.
The problem it was built to fix
The first version (v1, May–August 2026, 80 nightly runs) was research-only:
fetch papers, grade every claim A/B/C for evidence quality, file an issue +
gist + optional ADR + an always-draft PR. Genuinely good research, zero
follow-through:
4 shipped (5%)
1 rejected
75 untouched (94%), some >2.5 months stale
The root cause wasn't laziness — it was architecture. Every run was a fresh
checkout with zero memory of the 79 nights before it, beyond a
gh issue list --label dream-cycle grep. It also never touched the repo's
own Flywheel/MetaHarness evaluation infrastructure — 1,700+ lines of
tested, sequential-evidence-testing, champion/challenger promotion
machinery (ADR-176, ADR-322, ADR-381) that had never been exercised in
production. Two disconnected systems: one that proposed ideas, one that
could rigorously test them, with no bridge between them.
v2 → v3
v2 (first fix, same day) added:
docs/dream-cycle/LEDGER.md — a git-committed table read at the start of
every run, tracking the actual fate (merged/closed/stale/open) of recent
nights' issues and PRs. The one piece of durable memory a stateless
cloud checkout otherwise lacks.
Parallel research via the Task tool instead of a serial WebFetch
chain.
A bridge step: for harness/prompting/routing-shaped findings, draft a
real candidate and run it through metaharness bench/evolve for a
genuine evaluation receipt, attached as evidence — never self-promoted.
v3 (this version) takes the same core architecture and makes every
piece of it a first-class, mandatory pipeline stage instead of an optional
bridge:
1 — Ledger check. Read docs/dream-cycle/LEDGER.md, inspect the last
14 rows, re-check the fate of the last 7 via gh issue view/gh pr view.
Zero merges in 14 nights biases tonight toward something small and
reviewable over another broad research essay.
2 — Control plane discovery. Before doing anything, probe what's
actually available in this checkout — metaharness --help,
ruvector harness doctor/status, the local CLI. Never assume a capability
exists because the prompt mentions it.
3 — Parallel research. Five roles fanned out concurrently: deep
researcher, two scan researchers, a competitor analyst, an architecture
reviewer. Every external claim graded A (reproducible)/B (vendor,
cross-checked)/C (single source, informs but never justifies alone). Five
candidate findings scored on fit/testability/measurability/production
value/novelty/reviewability — the top score isn't auto-selected; an
override has to be explained.
4 — Formal hypothesis. Frozen before evaluation begins, in a fixed
falsifiable format:
Given <workload>, when <candidate change> is applied,
then <primary metric> should improve relative to <baseline>,
subject to <quality/safety/regression invariants>.
Cannot be edited after the fact. A failure is a recorded result, not a
discarded attempt.
5 — Testability gate. Does the finding map to something concretely
testable tonight — prompt structure, routing, model/tier selection,
topology, memory policy, a harness genome parameter? If not: file the
research issue with an explicit reason, skip evaluation, don't fabricate a
benchmark to force one.
6 — Concrete candidate. An actual diff, not prose. Target under 300
changed lines, one conceptual change.
7–9 — Benchmark corpus, baseline, candidate evaluation. Locate or
create a small committed benchmark corpus (a small honest one beats a
large synthetic one). Evaluate the parent first, on the real evaluator,
before the candidate ever runs. Then evaluate the candidate against the
identical corpus and policy. The candidate is never permitted to modify
gold answers. If the evaluator itself can't run, that's a recorded
blocker — never an invented fallback metric.
10–11 — Adversarial critique, reward-hack check. An independent critic
(not the candidate's own author) is handed the result and asked, point
blank: did it weaken the benchmark, cherry-pick tasks, exploit the
evaluator, hide cost, quietly touch a threshold, lean on an undocumented
cache? Any unresolved signal is a hard block on ACCEPT, regardless of
how good the headline number is.
12 — Bounded Darwin evolution. Only after basic evaluation clears does
Darwin get a small fenced budget — 3 generations, 4 candidates each, 1
promoted lineage — to explore around the winning candidate's parameters
(routing weights, topology, prompt/memory parameters). Darwin may never
rewrite the test judging it, disable a safety check, or touch acceptance
thresholds. A frozen fitness function is recorded before evolution starts:
Failed mutations are retained, not discarded — so the next Dream Cycle
doesn't burn a night rediscovering a dead end it already found.
13 — Flywheel evidence record. Every piece of knowledge produced
tonight is classified honestly on the way into durable memory —
OBSERVATION | MEASUREMENT | INFERENCE | HYPOTHESIS | DECISION | REJECTION. An inference is never filed as a measurement. If the evidence
can't be independently replayed from what's stored (flywheel verify),
it's demoted back to a research finding — it doesn't get to count as
promotion-quality just because it looked good once.
14 — Promotion gate. The single rule everything above exists to
protect: evaluation is not promotion. This session never merges, never
self-promotes a Flywheel candidate, never weakens a test to get a
favorable result. ACCEPT means "strong enough evidence to recommend
human review" — nothing more.
15 — Security review. For security-sensitive findings: prompt
injection, tool/MCP authority, credential exposure, cross-agent poisoning,
supply-chain exposure. MCP access defaults to least-privilege/read-only
where applicable.
Verification is five steps anyone can run: fetch the raw gist, hash it,
concatenate the session commit, hash again, compare to WITNESS.
17–25 — Publish, file, branch, validate, commit, push, draft PR, update
ledger. Everything downstream of the gate is publication, not action.
Even a statistically significant, fully-evaluated result stays a draft
PR — "evaluated" earns a human's attention faster, it doesn't earn
merge rights. The final ledger row is what STEP 1 reads tomorrow night.
26 — Self-review. A closing checklist against every invariant above —
was the hypothesis frozen before evaluation, was the critic independent,
was Darwin bounded, did we avoid self-promotion, did we avoid merging.
Any "no" gets corrected or explicitly reported, not silently dropped.
The invariant that survives every stage
Every run ends in exactly one of three states — never a fourth, never
silence:
Verdict
Means
ACCEPT
Sufficient evidence exists to recommend human review
REJECT
The hypothesis or candidate failed a mandatory criterion
INCONCLUSIVE
The experiment couldn't reliably distinguish candidate from baseline
A rejected hypothesis with a clean measurement is a successful Dream
Cycle. A research document with no actionable finding is not. The system
is explicitly not optimizing for PR count — it's optimizing to make
tomorrow's search space smaller and the accumulated evidence stronger,
whichever way tonight's answer came out.
Do not introduce dependencies merely to satisfy this prompt.
STEP 0.6: BUDGET
v3 does substantially more work per night than v2 — parallel research
subagents, baseline and candidate evaluation, up to three Darwin
generations of four candidates each. None of that has an enforced spend or
time ceiling yet. Set one now, before research begins.
research phase : target well under half of tonight's total budget
evaluation phase : baseline + candidate + Darwin, bounded by Darwin's
own generation/candidate caps in STEP 12 — do not
add extra generations or candidates beyond that cap
to chase a better result
hard ceiling : if elapsed effort is clearly running long relative
to a normal night, stop adding new work — finish
documenting whatever state exists rather than
starting another research or evaluation round
The one invariant that survives any budget pressure: STEP 25 (ledger
update) always happens. A Dream Cycle that runs out of budget mid-pipeline
must still leave a ledger row recording what stage it reached and why it
stopped there — silently vanishing without a ledger entry is worse than an
incomplete night, because it breaks STEP 1's ability to reason about
tonight tomorrow.
If a stop is forced by budget rather than by the STOP CONDITIONS section
below, record it explicitly as HALT: budget in the ledger row and the
final report, distinct from the other halt reasons — this is a different
failure mode and future nights should be able to tell them apart.
Analyze the ledger for recurring failure patterns.
Rules:
If substantially the same finding appears in 3 or more prior runs:
reject duplicate direction
→ use the next slot's DEEP surface
If both the selected surface and substitution are exhausted:
HALT
If zero of the last 14 candidate PRs merged:
Bias tonight toward an experimentally small, easily reviewable candidate.
Prefer:
one file
one trait
one parameter
one measurable improvement
over broad architecture changes.
If three consecutive gist self scores are below 5:
Reduce tonight to a single deep surface.
If multiple accepted candidates never merged:
Treat reviewability, patch size, and regression risk as part of tonight's optimization objective.
STEP 1.2: PRIOR GIST SCORE
Score the previous Dream Cycle gist out of 10.
Rubric:
2 points: benchmark evidence grade A or B
2 points: at least 4 competitor rows
2 points: specific executable recommendations
2 points: valid witness
1 point: less than 1500 words
1 point: genuinely novel finding
Record the score in tonight's issue and ledger.
STEP 2: LOAD FLYWHEEL MEMORY
Before researching externally, inspect accumulated internal learning.
Check:
.claude-flow/flywheel/
.harness/
docs/dream-cycle/
existing benchmark corpus
prior evaluation receipts
existing genome states
prior Darwin lineage
prior rejected candidates
accepted hypotheses
rejected hypotheses
inconclusive hypotheses
known benchmark failures
known routing failures
known topology failures
previously tested genomes
previously rejected Darwin mutations
known regression thresholds
known security failures
Do not rediscover a failed direction unless new evidence or implementation changes justify reopening it.
STEP 2.1: EXTERNAL COLLECTIVE MEMORY (read-only)
Before external research begins, also check whether other RuvNet-ecosystem
agents have already surfaced prior art for tonight's surface, via the
shared collective knowledge base at pi.ruv.io:
This call is READ-ONLY. Do not POST, vote, or write anything to pi.ruv.io
from this session — sharing tonight's finding back into that public
collective knowledge base is a separate, deliberately deferred decision,
not part of this pipeline yet. If the endpoint is unreachable or the
response is empty, note that and continue — this is a supplementary
signal, not a dependency; nothing downstream should block on it.
STEP 3: PARALLEL RESEARCH
Use MetaHarness or the available Task system to fan out the research.
Run the research tasks concurrently.
Roles:
1. Deep Researcher
2. Scan Researcher A
3. Scan Researcher B
4. Competitor Analyst
5. Ruflo Architecture Reviewer
The deep researcher must examine:
recent papers
official documentation
competitor changes
relevant benchmarks
Ruflo current implementation
Preferred primary research sources:
arXiv
conference proceedings
official project repositories
official vendor docs
official benchmark reports
standards organizations
Research recent work from relevant venues when applicable:
For security use relevant OWASP agentic and LLM guidance as one rubric.
STEP 3.1: CLAIM GRADING
Every material external claim receives an evidence grade.
A:
reproducible paper
official benchmark
directly reproduced result
authoritative standard
B:
official vendor claim cross checked with another credible source
C:
single source claim
plausible but unverified
C grade claims may inform research.
They may not independently justify implementation or promotion.
STEP 3.2: CANDIDATE GENERATION
The deep researcher must propose 5 candidate findings.
Each candidate contains:
hypothesis
why now
gap in Ruflo
testable tonight?
expected value
estimated patch size
expected evaluation cost
risk
Score each from 1 through 5 for:
Ruflo fit
novelty
testability
measurability
production value
reviewability
Before implementation, freeze a falsifiable hypothesis.
Format:
Given <workload>,
when <candidate change> is applied,
then <primary metric> should improve relative to <baseline>,
subject to:
<quality invariant>
<safety invariant>
<regression threshold>.
Do not modify the hypothesis after evaluation begins.
If it fails, record failure.
STEP 4: WRITE INITIAL GIST
Write:
/tmp/dream-gist-${DATE}.md
Structure:
# <Surface> SOTA Report — ${DATE}
TL;DR
## What's New in 2026| Finding | Source | Confidence |## Ruflo Current Capability## Competitor Comparison## Hypothesis## Benchmarks## Evaluation## Darwin Results## SOTA Proof & Witness## Recommended Next Steps
Requirements:
under 1500 words
2026 in title
2026 in first paragraph
minimum 4 competitor rows
3 specific recommended actions
no fake benchmarks
no unsupported performance claims
STEP 5: TESTABILITY GATE
Determine whether the selected finding is harness shaped.
Harness shaped means it maps to a concrete testable change involving one or more of:
If the ledger records another canonical path, inspect that path.
If no corpus exists, create a minimal representative benchmark set.
The benchmark corpus should include multiple task types relevant to tonight's hypothesis.
A small honest corpus is preferable to a large synthetic one.
Record:
corpus path
task count
task categories
gold data source
random seed where relevant
created_by_date (tonight's DATE if newly created; otherwise the
date already on record for this corpus path)
created_by_hypothesis (tonight's hypothesis if newly created; otherwise
the one already on record)
The candidate may not modify evaluation gold answers.
A corpus created tonight is graded by the same session that will use it to
evaluate tonight's own candidate — the adversarial critic in STEP 10 checks
the candidate against the corpus, but nothing yet checks whether the corpus
itself was subtly shaped to be easy to pass. STEP 10 now includes a
periodic corpus fairness check for exactly this reason — see below.
STEP 8: BASELINE EVALUATION
Evaluate the current parent before the candidate.
Capture:
task count
success rate
quality
latency
token usage
model cost if available
error rate
informative pairs
Use the repository's real evaluator.
Possible commands include:
node bin/cli.js metaharness evolve --bench <path>
or the currently supported Flywheel interface.
Do not infer benchmark results from logs.
Preserve the actual evaluation receipt.
STEP 9: CANDIDATE EVALUATION
Evaluate the concrete candidate using the same corpus and evaluation policy.
Capture the real receipt:
parent
candidate
effect size
significance
informative pairs
quality result
latency result
cost result
regressions
verdict
If evaluation fails because of infrastructure:
EVALUATED=blocked
VERDICT=INCONCLUSIVE
Record the exact blocker.
Do not invent a fallback metric.
STEP 10: ADVERSARIAL EVALUATOR
Before Darwin runs, assign an independent critic.
The critic must ask:
Did the candidate weaken the benchmark?
Did it alter gold answers?
Did it cherry pick tasks?
Did it exploit the evaluator?
Did it increase cost materially?
Did latency regress?
Did quality regress?
Did it merely move work elsewhere?
Did it rely on an undocumented cache?
Did it modify test thresholds?
Did it leak expected answers?
Is the baseline fair?
Is the effect statistically meaningful?
Would the change survive a different workload?
Periodic corpus fairness check. Tonight's candidate is not the only thing
under suspicion — the corpus grading it might be too, especially when it was
authored by a prior night's session rather than freshly built tonight. Check
created_by_date/created_by_hypothesis from STEP 7. If the corpus already
existed before tonight (reused, not newly created), the critic also asks:
Does this corpus's pass rate look suspiciously high across the candidates
that have been run against it so far, relative to what an honestly hard
benchmark should produce?
Was this corpus ever edited by the same hypothesis it was built to test?
Would a completely unrelated, deliberately weak candidate fail enough of
these tasks to prove the corpus still has teeth?
Answering these does not require re-running history — a quick sanity pass
(spot-check a handful of tasks, or run one known-weak candidate through the
corpus if one is cheaply available) is enough. If the corpus looks like it
has gone stale or soft, say so in the report and treat that as a signal for
STEP 4 candidate generation on a future night — "harden or replace corpus
<path>" is itself a valid finding — but do not block tonight's verdict on
fixing it retroactively.
The candidate generator may not act as the sole evaluator.
Never optimize only one metric unless the hypothesis explicitly concerns only that metric and all other metrics are hard constraints.
STEP 12.2: DARWIN LINEAGE
For each mutation record:
parent
mutation
fitness
effect size
quality
latency
cost
regressions
reward hack result
accepted or rejected
Failed mutations are valuable evidence.
Persist them.
Do not repeatedly rediscover them in later Dream Cycles.
STEP 13: FLYWHEEL EVIDENCE RECORD
The Flywheel is the durable experimental memory.
Record:
hypothesis
baseline
candidate
benchmark corpus
evaluation receipt
critic decision
Darwin lineage
reward hack result
security result
final verdict
commit identity
witness identity
Session commit
Report SHA256
Witness stamp
Evaluation receipt identity
Flywheel evidence identity when available
Darwin lineage identity when available
Verifier procedure:
1. Fetch the raw gist.
2. Compute SHA256.
3. Concatenate hash + SESSION_COMMIT.
4. Compute SHA256 again.
5. Result must equal WITNESS.
DATE
DEEP
one line finding
issue number or LOCAL
PR number or NONE
yes/no/blocked
ACCEPT/REJECT/INCONCLUSIVE
effect size when available
witness prefix
prior fate summary
The ledger must be committed.
This is the long term memory connecting Dream Cycles.
STEP 26: SELF REVIEW
Before completing, verify:
Did research use current sources?
Was the candidate concrete?
Was the hypothesis frozen before evaluation?
Was the baseline fair?
Was the benchmark real?
Was evaluation performed by the real evaluator?
Was the receipt preserved?
Did an independent critic review it?
Did we check reward hacking?
Was Darwin bounded?
Did Darwin preserve failed lineage?
Did Flywheel retain the evidence?
Was the witness calculated from the final gist?
Did we avoid self promotion?
Did we avoid merging?
Did we update the durable ledger?
Any No answer must be corrected or explicitly reported.
STOP CONDITIONS
Halt publication but retain local evidence when:
unresolvable merge conflict
all external research sources fail
selected research surface exhausted
AND
substitute surface exhausted
repository cannot execute the relevant evaluator
benchmark corpus is corrupted and cannot be repaired safely
candidate modifies evaluation infrastructure in a way that prevents fair comparison
reward hack detection finds unresolved gaming
witness generation fails
GitHub authentication failure is not a fatal stop condition.
Done. Issue #<N or LOCAL>, Gist <URL or LOCAL>, PR #<N or NONE> (evaluated=<yes/no/blocked>, verdict=<ACCEPT/REJECT/INCONCLUSIVE>), ADR-<NNN> or none. Witness: <WITNESS>.
FINAL OPERATING PRINCIPLE
The Dream Cycle is not a nightly content generator.
It is an evidence producing evolutionary control loop for Ruflo.
The invariant is:
ledger
→ research
→ hypothesis
→ candidate
→ baseline
→ evaluation
→ adversarial critique
→ bounded Darwin evolution
→ Flywheel retention
→ witness
→ human gated promotion
Every night should make tomorrow's search space smaller and Ruflo's accumulated evidence stronger.
If a candidate wins, retain why it won.
If it loses, retain why it lost.
If the result is inconclusive, retain exactly what must be measured next.
Never optimize for producing a PR.
Optimize for reducing uncertainty about what Ruflo should become.
