capability-registry: "VERIFIED NULL: evolve is not among them" is stale — ruflo v3.34.0 ships evolve, bench and flywheel

[ObiWanKenobi]

What

scripts/capability-registry.mjs asserts, twice, that evolve is absent from ruflo's metaharness CLI. On main @ 75f9310 today:

:40   similarity|drift-from-history|mint|redblue|learn|gepa. No `evolve`.
:624  // VERIFIED NULL: `ruflo metaharness --help` enumerates its subcommands and `evolve` is not among them.

That measurement has drifted. Measured just now against ruflo v3.34.0:

$ ruflo metaharness --help
      --subcommand   One of: score | genome | mcp-scan | threat-model | oia-audit |
                     audit-list | audit-trend | similarity | drift-from-history |
                     mint | redblue | learn | gepa | evolve | bench | flywheel

evolve is there — and so are bench and flywheel, neither of which the header enumerates either.

Why it matters

The claim is load-bearing, not just a comment. It justifies turnOn: null on the harness-evolution row (:625), so the console can never offer an action that now exists. On this machine that row reads on with "an evolved policy is active machine-wide … applied 7 days ago" and no way to act on it.

The header's stated rule — "this registry only ships commands a person can paste into a terminal" — is now satisfied by ruflo metaharness --subcommand evolve. It's pasteable, it's real, and it dry-runs safely: without --confirm it prints a plan and exits 0.

Verified the dry-run path is genuinely free before suggesting it:

$ node .../ruflo-metaharness/0.1.1/scripts/evolve.mjs --repo <repo>
{ "dryRun": true, "message": "Pass --confirm to run the evolution." }   # exit 0

Also worth noting for whoever picks this up: the plugin's default is "sandbox": "real" and "mutator": "deterministic" — so a --confirm run costs real test executions but no API key (no OPENROUTER/API_KEY reference anywhere in evolve.mjs or _darwin.mjs).

The class of bug, not just the instance

A VERIFIED NULL is a measurement with a timestamp that isn't written down. It was true when taken and silently became false when ruflo shipped a new subcommand — and nothing re-checks it, because the failure mode is a capability quietly never being offered.

This is the same shape as the anticipate.sh path assertion in #114: a comment asserting a fact about the environment, correct when written, with no test binding it to reality.

Suggested fix, in preference order:

1. Derive it. Parse ruflo metaharness --help at detect time rather than hardcoding the list — the same discipline installer-sibling-imports-packaged.test.mjs already applies ("the list is DERIVED from install.mjs by reading its actual import sites — never hand-maintained").
2. Or bind it to a test that fails when the real --help gains a subcommand the header doesn't list.
3. At minimum, date-stamp VERIFIED NULL claims and name the version they were verified against, so staleness is visible on read.

Happy to send a PR for (1) if you'd like it.

Environment: ruflo v3.34.0 · ruvnet-brain plugin 4.0.7 · macOS

[stuinfla]

🤖 Automated acknowledgment — received and opened. The maintainer has been paged and this is being worked. The next update here will be a fix, findings, or the maintainer in person.

[stuinfla]

You're right, and thank you for pasting the live --help output — that's what made it a five-minute fix instead of an argument.

Re-measured against ruflo v3.34.0 before touching anything:

--subcommand  One of: score | genome | mcp-scan | threat-model | oia-audit |
              audit-list | audit-trend | similarity | drift-from-history |
              mint | redblue | learn | gepa | evolve | bench | flywheel

evolve is there, and so are bench and flywheel. Fixed in 12c29c1.

Your framing — "the claim is load-bearing, not just a comment" — is the important part. It justified turnOn: null, so the Console could never offer an action that had since started existing. A null justified by a measurement has to be re-measured, or it quietly becomes a lie. That's the same defect class as every other drifted assertion here, sitting inside the registry whose entire job is to describe what is actually available.

harness-evolution now carries a real turnOn — and it names its precondition rather than handing you a command that fails: plugin/skills/brain-score/SKILL.md:97 requires OPENROUTER_API_KEY for the WRITE layer and says never to claim the evolve loop just works without it. So the human text says so, and points at --subcommand score as the free read-only layer.

One more thing your report surfaced: that file's header claimed "Four of the eleven capabilities have turnOn: null" while the real number was seven — stale by three, inside the very paragraph explaining why nulls must be re-checked from evidence rather than memory. Counted now, not remembered.