| name | meta-harness |
| description | Automated architecture evolution after metric progress plateaus. Discover the code loop, create missing evals, run parallel proposers, benchmark variants, and keep the best patches. |
Meta-Harness
Use this when a measurable improvement loop has plateaued and the likely fix is architectural, not parameter tuning.
It is automated /pursue: multiple isolated proposers change code, then the repo's real checks select winners.
Start
- Read
.evolve/meta-harness/ if it exists: config, frontier, variants, and latest run notes.
- Discover the current evaluator, benchmark, or product check; create the smallest missing check before proposing code.
- Prove the metric connects to user value and can move.
- Seed a baseline from at least three runs when the check is noisy.
Loop
- Launch independent proposers with pinned briefs and separate workspaces.
- Require structural mechanism changes; reject pure parameter tweaks.
- Run the same smoke, benchmark, and repo checks for every variant.
- Keep only variants that beat baseline and pass the checks.
- Record lineage, hypothesis, result, and rejected ideas under
.evolve/meta-harness/.
- Merge only after the winning mechanism is clear and reproducible.
Rules
- Read raw traces or run artifacts before proposing changes.
- Equalize compute across compared variants.
- Prefer small source patches with clear causal mechanisms.
- Compact merged variants to metadata; keep unmerged frontier source only when it teaches something.
Use references/full-reference.md for the full setup, state files, and integration details.
Then consider
evolve when the architecture is stable and the next step is metric tuning.breakout when even automated architecture evolution plateaus near a ceiling — the target is the cap, not the code. Question and raise it.autopsy when a run result is surprising or suspicious.
