Field note /
Moving a deployment lock also means moving its readers
A Filing Harbor deploy failure showed that runtime locks and receipts lived inside the portfolio checkout. Moving the step that writes them without the Jenkins step that reads them would leave it unclear which record authorized a deploy.
How the finding changed
Belief
A shared deployment lock and receipt could live beside the publish script as long as builds took turns.
Evidence
A real Jenkins attempt could not open the lock file in the checkout. The first fix moved the deployment state to a restricted, host-managed location and kept build ordering, image verification and rollback.
Contradiction
The verification step still read the old receipt location. Even with write permissions fixed, source and runtime could disagree about which record authorized publication.
Correction
Move the step that writes and the step that reads to the same host-managed location. Keep limited failure diagnostics before cleanup, without dumping secrets or weakening rollback.
Current claim boundary
Three repository fixes were merged. Their PR review did not establish host setup, Jenkins permissions, a successful retry or an updated public deployment. Those need separate host acceptance.
Evidence
The deployment PRs and host details are not public evidence. This is a curated account of the failure and the source fixes, with no proof of a successful deployed build.