Recovery means finishing the interrupted task

Work demonstrated September 24–25, 2026 (UTC)

A service can briefly appear healthy while repeatedly crashing. That happened during Cold Fortress’s reboot verification: a single observation initially suggested a successful restart, although the handler was failing between observations. Investigating that discrepancy changed both the implementation and the standard for declaring recovery. The later test followed an interrupted reading through to an answer, rather than stopping when the services returned.

The first defect was a startup dependency. The handler expected a temporary directory that had been created during installation. After a device reboot, that directory no longer existed, and the handler could not create its lock file. Startup was changed to recreate the directory. The original apparent pass was rejected and its failure evidence retained.

The verification change addressed a separate problem. One observation of an active service could catch a short interval between crashes. The revised check required services to remain active for 30 seconds, with unchanged process invocation identities and restart counts. This still allowed finite startup retries, including waiting for clock synchronization, but required a stable interval afterward. The corrected idle reboot trial passed, followed by a real reading after reboot.

An idle restart leaves an important question unanswered: what happens to work already underway? On September 25, a controlled trial rebooted the handler device during an active reading request. The test driver caused the interruption. The handler’s changed boot identity confirmed the reboot, and the services subsequently met the sustained-health check. Because monitoring had been interrupted, the original disposable agent was permanently retired.

The evidence then followed the lifecycle beyond that retirement. Cleanup was confirmed before a fresh replacement was created. The replacement read the assigned IANA page through the source tool, returned at its scheduled rendezvous, and supplied the result that reached the protected agent. The protected turn completed, and the test lineage was retired afterward. This established recovery of the interrupted assignment through a new agent, not merely recovery of the handler process.

The answer review also showed why successful delivery and faithful wording deserve separate attention. The protected agent received the exact admitted result and answered the registration and production-use questions correctly. Its final wording nevertheless broadened the source’s production-use warning to all live applications or services. That qualification remains in the record: the recovery succeeded, while the final paraphrase was less precise than the source.

These observations support a specific advance in the single-agent prototype. A handler-device reboot during active work was followed by retirement, confirmed cleanup, fresh execution, scheduled admission, and a completed protected response. The trial did not reboot the worker or protected device during active work, and it did not restore an entire machine from a clean image. Those are different recovery claims.

The methodological result is as useful as the repaired startup behavior. Recovery evidence needs to follow the interrupted obligation: which request survived, which agent became ineligible, when cleanup finished, and whether a valid result eventually reached its destination. A stable process is one checkpoint in that chain. Here, tracing the whole chain exposed a false success signal and provided a stronger basis for the subsequent recovery finding.