Proposals

The Proposals tab’s main job is the test-writer’s handiwork: the real proposed test, reconstructed from the run’s own tape, that the herd authored to target a surviving mutant. Each proposal shows the surviving fault it targets, the goal the code is supposed to satisfy, and an honest result — proven-kills (the jail confirmed the test actually kills that mutant) or candidate-not-proven (it compiles but hasn’t been run to a kill yet). Approve or reject with a typed reason; the reason is recorded alongside the decision.

In a replay, this human gate is demo-only: a recording is read-only, so clicking approve or reject re-renders the card but doesn’t persist anywhere. The real wiring — POST the decision to the brain and sign it into the ledger — is a stated follow-on, not shipped yet. Only a live run against a live brain writes the decision anywhere durable.

The same tab (and the same approve/reject human gate) also surfaces the learning loop’s proposed lessons and skills once enough runs corroborate a pattern — approving promotes the guidance into vetted memory and syncs the matching skill fleet-wide (see the learning loop); rejecting sends it back until the evidence doubles. Proposed tests and proposed lessons share the tab and the gate, but the test proposal — closing an actual, execution-proven gap in the file you just audited — is the one worth looking at first.