No way to gate run success on goal-search coverage: a 3-of-77 audit reaches the same succeeded status as a complete one

Summary

There is no way to make a run's terminal status depend on how much of the audit actually ran. Now that goal lanes may legitimately end empty, a run that searched a small fraction of its planned goals reaches the same succeeded status as one that searched all of them. An unattended consumer — CI, a dashboard, the eval harness — reads that status, not the report prose.

Filed as the counterpart to the goal-coverage reporting gap: reporting fixes the human reader, this fixes the machine reader.

Why a hard built-in threshold is the wrong answer

The obvious fix is refusing succeeded below some coverage percentage. That should not be the default, for two reasons:

• Any baked-in threshold is arbitrary. Some goals legitimately cannot complete — a goal targeting a capability the target does not have is correctly abandoned, and the applicability decisions in the plan already record that. A fixed floor either blocks legitimate runs or is set so low it certifies nothing.
• succeeded has a defensible existing meaning: the workflow ran to completion. Redefining it to mean "and covered enough" conflates orchestration health with audit thoroughness, which are separately useful signals.

The actual defect is that coverage is invisible to anything that consumes the run programmatically, and that there is no supported way for an operator to say "do not treat this as a passing audit".

Proposal

Three parts, in priority order:

1. Expose coverage as a first-class machine-readable verdict on the run, beside the terminal status — not only as a field inside report.json. A consumer should be able to read completed/planned and the stopped-early count without parsing the report.
2. Add an opt-in gate — e.g. --min-goal-coverage <ratio> on the run and status paths, plus a config equivalent — that fails validation when coverage falls below the operator's chosen bar. Opt-in keeps the policy with the operator, where it belongs, and gives CI and the eval harness a real gate.
3. Never let unknown read as complete. A missing census must produce an explicit unknown verdict, and the opt-in gate must treat unknown as failing rather than passing.

Deliberately not proposed: a new terminal status such as succeeded-partial. Terminal statuses are consumed in several places (isTerminalRunStatus, the deadline check in workflow-control.ts, the eval runner) and adding one risks changing control-flow behaviour well outside reporting.

Acceptance criteria

• Goal coverage is readable programmatically from run state without parsing the report.
• An operator can configure a minimum coverage below which the run does not validate as a passing audit.
• With no threshold configured, behaviour is unchanged apart from the coverage verdict being present.
• An absent or unreadable census yields an explicit unknown verdict and fails a configured gate.

Trace run state and status handling, starting with isTerminalRunStatus, the deadline check in workflow-control.ts, the eval runner, and the report.json coverage data. Then inspect the run and status paths plus configuration handling. Done means coverage is machine-readable, an optional minimum gate works, and missing census data is explicitly unknown and fails the gate.