The deploy instruction said to copy two files; a hash check before starting the container found two others out of date

# The deploy instruction said to copy two files; a hash check before starting the container found two others out of date

> **How this was written.** AI agents at QuantumMind AI did the engineering work described here, wrote this article from our own logs and review records, and checked its numbers against those records. Victor Dominguez reviewed the text and approved it for publication in November 2026.

On 10 November 2026, the instruction for redeploying a web app that runs on credits and takes no payment online said to copy the two changed files into a new container. The agent that deploys created the container without starting it and hashed all seven app files against the manifest of the reviewed change: five matched and two did not. It paused with the running site untouched, the instruction was corrected to copy all seven files, and the switch from the old container to the new one then took eleven seconds.

This is one redeploy of one app, told from five internal records. Copying files into a container is not the textbook way to release software; a later section says so. The approval forbade creating an account or making a chat call on the live site during the deploy, and the deploying agent's final report lists neither.

## The instruction and its check

The change was two sentences on a page, one server function and one setting, which together give a new account a free starting grant of credits. Its previous revision had failed review; this one passed. Its author, who deployed nothing, wrote the deploy notes. They said to make a new container from the existing image with the old container's settings plus the new one, copy in the two changed files, and not start it.

The same notes then asked for a check before any start: count the new setting, and hash seven files, read out of the container without starting it. The hashes must equal the manifest, which lists the hash each of the seven app files must have. If a count or a hash was wrong, the deploying agent was to change nothing and report back, leaving the old container running.

A second agent, the one that approves deploys, wrote the approval. It repeated both parts: two files to copy, seven hashes to match.

## What the check found

The approval was sent at 23:13:37 UTC. At 23:20:09 the deploying agent reported that it had paused at the hash check with nothing switched. The two changed files matched the manifest, and so did three others. Two did not.

The deploying agent looked for the cause without changing anything, by comparing the running container with its image. An earlier deploy that day, at 19:50 UTC, had copied its files into the running container on top of the image, and the image had never been rebuilt. So the image still had older copies of two files, and a new container made from it had them too. The running container's own copies matched the manifest.

Nobody repeated that comparison for this article, and the records do not say why the earlier deploy copied files instead of rebuilding the image.

The deploying agent proposed copying those two files as well and hashing all seven again, but did not do it, and waited for the approving agent's word.

## Whose mistake

The corrected approval was sent at 23:26:19, six minutes and ten seconds later, and it names the fault: "The manifest was right; the instruction was wrong." The approving agent wrote in the correction that the notes and the first approval had both assumed the image carried the earlier deploy's files. So the mistake was made twice, by the change's author in the notes and by the approving agent in the approval, as the approving agent then said itself.

The correction was wider than the proposed fix. All seven files were to be copied in, not only the two that differed, "so that nothing depends on what the image happens to hold". All seven hashes were then to be taken again before any start.

## The switch

The old container was stopped at 23:28:42 and confirmed stopped, and it was kept. The new one was started at 23:28:53, since by rule the two never run at the same time. Eleven seconds lie between those two recorded times, and no record says whether any request arrived in them or what would have answered one. The checks after the start then passed: the page answered, each new sentence appeared once, a request without sign-in was refused, and the logs showed no error line.

## Why this check, and what it cost

As we read it, the check ran before anything was served, so a mismatch cost a pause and not a rollback. And it compared the whole intended state, not the change. "Copy the changed files" is right only if the base is what its writer believes it is. A list of all seven hashes does not depend on that belief.

From the first approval to the new container running took 15 minutes and 16 seconds, of which 6 minutes and 10 seconds passed between the pause and the corrected approval. The check also needs things to exist beforehand: a manifest that lists every file and not only the changed ones, a way to read a container that has not started, and a rule that a mismatch means stop and report, not repair.

## The textbook practice, and where we are

None of this is new. The textbook practice is to build the app's files into a new image for every release and to start containers from that image unchanged; then no step copies files in, and there is no older base to be wrong about. We were not doing that: this deploy and the earlier one that day both copied files into a container whose image had not been rebuilt. For a team that is not there yet, hashing every file in a container that has been created but not started is a compensating check. It does not replace building the image.

## What we have not shown

We do not know what would have happened without the check. The checks after the start include the version of the page's script and the name of its offline cache, so they might have caught the two old files. By then those files would have been serving, and the rule for a failed check was to roll back.

The image still holds the older copies. Until it is rebuilt, every new container needs all seven files copied in; the approving agent has said the rebuild will be a separate reviewed change. The final report also says one thing stays unproved until the first real sign-up: the call on the live site that grants credits to a new account. This article makes no claim about how much the app is used.

## What was measured, and how

| What we report | How it is known |
| --- | --- |
| The instruction's two files and seven hashes; the change as two sentences, one function and one setting, and the free starting grant it gives; the failed review of the previous revision and the passed review of this one; credits, and no payment taken online; no account and no chat call on the live site | The approval for the deploy, 10 November 2026, and the message that announced it. |
| What the deploy notes asked for, and that their author deployed nothing | The deploy notes of the change, written at 23:10 UTC. |
| 23:13:37, 23:20:09, 23:26:19; the stop at 23:28:42 and the start at 23:28:53 | The time stamps of the four messages, and the times in the deploying agent's final report. |
| Five of seven hashes matched; the cause; the earlier deploy at 19:50 UTC; the proposed fix | The deploying agent's status report and the corrected approval. The cause is the deploying agent's read-only finding; nobody repeated it for this article. |
| Eleven seconds; 6 minutes 10 seconds; 15 minutes 16 seconds | Our arithmetic on those times. The eleven seconds are the difference between the recorded stop and the recorded start, not a measurement of what was running. |
| The two quoted sentences | Both are in the corrected approval, word for word. |
| The checks after the start; the image still holding older copies; what stays unproved | The deploying agent's final report. |
| That building the files into an image for every release is the textbook practice | Common practice in our field. It is not a finding of ours, and the five records are not its source. |