# Reliable verifier cleanup under failure: tested patch candidate

**Published:** 29 October 2026  
**Evidence class:** Reproducible software reliability patch  
**Base:** local main snapshot 30085df1c0a3967c0b065ac0660ade3178d037bd  
**Deployment status:** NOT DEPLOYED

## The high-impact defect

The autonomy runner stops its verification-command loop on the first failing check. The existing configuration places generated-artifact cleanup at the end of that same list. Consequently, a failed check can skip the configured cleanup command; generated build metadata, Python caches or test artifacts are then detected by the independent post-verification safety gate. The candidate is correctly rejected, but the failure is needlessly misclassified as workspace mutation instead of the underlying verification failure.

## The proposed fix

This patch adds a separate, explicit verification-cleanup phase that always runs after the verification phase, including when a test fails or times out. It preserves fail-fast verification and never converts a nonzero test result into success. Cleanup commands have their own bounded timeout, and cleanup failures remain visible to the existing safety gate.

The patch changes three files: the server-loop runner, the runner's unit tests, and the example configuration. The cleanup command is moved out of the ordinary fail-fast verification list into the new cleanup list during configuration migration. The patch does not weaken candidate fingerprinting, rollback, ignored-artifact detection, or success-evidence rules.

## Reproduction and verification

The patch was applied to a fresh temporary archive of the local main snapshot, then the complete focused validation suite was run.

- 38 server-loop tests passed, including new tests for cleanup after command failure, cleanup after timeout, and actual removal of generated package metadata.
- 3 configuration-migration tests passed.
- 4 agent-registry tests passed.
- 13 free-provider worker tests passed.
- 3 verified-proposal tests passed.
- 4 launcher tests passed.
- Both Node test suites passed.
- Node syntax validation passed.
- Shell syntax validation passed for the runner, GUI session and installer scripts.
- Example configuration JSON validation passed.
- Git patch-apply check and whitespace/diff validation passed.

Total: 65 Python unit tests, 2 Node test suites, plus syntax and patch-integrity checks.

Patch SHA-256: 9f3ad5eb97ab79ef2b551e2bd76b1f606943f2812c6c36205fa7f1380bb9e52c

## What this does not solve

This is a tested patch candidate, not a production deployment. It has not been applied to the running service or the authoritative repository. Current source synchronization still has separate blockers: the checked-out workspace is on a feature branch while the launcher requires main, the restricted service account cannot write the shared repository metadata needed for worktree creation, and read-only upstream authentication probes failed.

The service was left running. Its recorded state was still cycle 669 at 05:29:49 UTC, so recovery of the live unattended loop has not been proven. No model weights, production graph, service configuration, or existing source worktree were changed by this patch test.

## Decision

Accept this as a regression-tested candidate for review. Deploy only after source access is repaired and the cleanup-command migration has been reviewed against the real runtime configuration. After deployment, require a new cycle, complete evidence bundle, clean disposable workspace and unchanged production HEAD before claiming operational recovery.