feat(guard): a truncated cargo-mutants run cannot score (#389)

[avrabe]

Closes #389. REQ-GUARD-GATE-EVIDENCE-002 obligation (d) — the last of six.

Unblocked by the runner-side fix applied on #389 earlier today (smithy PR #7).
The issue was explicit that the detector and the infrastructure fix had to land
together, and that arming (2) without (1) "turns a required context into an
infrastructure coin-flip". (1) now holds, so this is (2).

The defect

A cargo-mutants run killed part-way is internally consistent, which is
exactly why -001's cross-check obligation could not see it. Run 30563879100:

missed 210 + caught 603 + unviable 793 + timeout 2  ==  1608  ==  total_mutants

Every count agrees with outcomes.json. Meanwhile the log shows cargo-mutants
had found 1737 mutants and lost its worker trees 3h02m in. total_mutants
is written incrementally, so the report is a truthful account of the 92% that
ran — and truthful about the wrong population.

The failure is flattering, which is what makes it dangerous. A truncated run
under-reports survivors, so 210 sits comfortably under the 292 threshold and the
gate goes green. Any threshold ratcheted down onto such a number is a ceiling set
below the floor.

The discriminator

end_time — null while running, populated on a clean finish. It is the one
field that does not degrade gracefully under truncation.

Absence of outcomes.json is fatal here, which is stricter than
_cross_check (which tolerates absence and says so). That asymmetry is
deliberate: losing the cross-check costs a detector, but losing end_time means
completion cannot be established at all — and "cannot prove it finished" must not
read as "finished".

Why the root cause is worth reading

Not a disk-pressure hook, which is what the issue originally suspected — that
was a red herring, since ACTIONS_RUNNER_HOOK_JOB_COMPLETED only runs between
jobs. The actual reaper was smithy's tmpfiles policy:

e /var/lib/runners/runnerN/_tmp/cargo-mutants-*.tmp - - - 2h -

resting on its own stated assumption — "a job that's still running keeps mtime
fresh". That is false for cargo-mutants specifically. It copies the source
tree into each worker's temp dir once, at start, and never touches those files
again, so their mtime is frozen while the job is very much alive. A 3h02m run
aged past 2h and the next hourly sweep deleted its sources. The four workers
dying "within one second of each other" was one sweep, not four faults.

Age is now 8h, above GitHub's 6h job ceiling. Residual coupling, documented
in the docstring: that only holds while this repo's mutants job stays under
~7h; it is currently timeout-minutes: 240.

Evidence

• 24 self-test cases (was 19). The discriminating pair is the point: the
  same report, same counts, same cross-check, same under-threshold verdict,
  differing only in end_time, must produce different outcomes. Run
  30563879100's exact numbers appear as a case in both truncated and completed
  form.
• Mutation-tested, 5 mutants, all caught — but two survived the first pass,
  and that is the part worth keeping. Tolerating a missing outcomes.json and
  accepting a missing end_time key each still exit 1 through a fallback (a
  missing file raises on json.load; a missing key reads as None). The verdict
  was over-determined, so the cases could not tell which check fired. Fixed by
  pinning the diagnosis as well as the exit code — the same principle the
  gate rests on, turned on its own tests. Both are now caught by "exit 1
  correct, but the diagnosis is wrong".

One thing deliberately NOT done

REQ-GUARD-GATE-EVIDENCE-002 stays proposed. I moved it to implemented while
preparing this change and check_human_scoped.py failed the tree — the
artifact carries the human-scoped tag, and REQ-GUARD-HUMAN-SCOPED-001 exists to
stop an agent promoting exactly this kind of thing. Whether six implementations
mean the requirement is met is the judgement that tag reserves for a human.
Promoting it means dropping the tag in the same diff, so the decision is one
explicit line rather than a status that drifted upward on its own.

NOT claimed: that the surviving-mutant threshold is right. This only ensures
the number being compared came from a complete run.

🤖 Generated with Claude Code

[github-actions]

Rivet verification gate

✅ 20/20 passed

	count
Passed	20
Failed	0
Skipped (no steps)	0

Filter: (and (= type "feature") (or (has-tag "v093") (has-tag "v0100")))

Failed artifacts

(none)

_{Updated automatically by tools/post_verification_comment.py. Source of truth: artifacts/verification.yaml.}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!