Verify the Running System, Not Your Memory of It

I sat down to fix a problem that did not exist anymore.

The plan said there was an open loop on the Content Forge MCP server. A few tools left to wire. An auth issue to chase. A connection that would not hold.

None of that was true. The product was already built and merged. What stood between me and a working connection was one stale deploy and three migrations nobody had run yet.

I almost spent the morning re-debugging code that was already correct.

The notes disagreed with each other

Here is the part that should worry you.

I had two memory notes about this project. One said the fix had merged. The other implied it had not. A third said nine of fourteen tools were still left to build.

All three were written by me, or for me, in good faith. All three were stale to some degree. They did not just lag reality. They contradicted each other.

That is the trap. When your records disagree, your instinct is to pick the one you trust most and move on. But there is no version of “trust the right note” that gets you to the truth. The notes are all guesses about a system that has moved on without them.

The live system does not guess

So I stopped reading and asked the running thing directly.

I hit the endpoint. It returned a 307 redirect to the login page. That single response settled the whole argument: the code was right, but the deployed build was old. “Merged” had never meant “deployed.” The fix existed in the repo and had never reached the server.

Then I counted the tools the live server actually registered. Twenty. Not the eighteen I had estimated. Not the “nine remaining” the note claimed. The product had quietly finished itself while my notes were still describing a job half done.

A status note starts rotting the moment you write it. The system keeps changing. The note does not.

Merged is not deployed

This is the line worth tattooing somewhere.

“Merged” is a fact about a git branch. “Deployed” is a fact about a server. They feel like the same event because in a tidy pipeline they happen seconds apart. But they are two different machines telling you two different things, and the gap between them is where you lose hours.

A pull request can be green, approved, and merged, and the thing your users touch can still be last week’s build. The only way to know is to ask the server what it is running right now.

This is close cousin to a lesson I have written before about cached build output lying to you on your local machine. Same family, different room. There, the artifact lied. Here, my own written record lied. The fix is the same in both cases: go to the source that cannot lie, which is the process actually running in production.

Memory is for humans. Interrogation is for state.

Working with AI agents makes this sharper, not softer.

An agent reads your notes. It reads dc-memory. It reads the last session summary. Then it acts with total confidence on a snapshot that may be days old. It will tell you the project is 60 percent done because that is what the note said, and it will be wrong with a straight face.

Notes are useful. They hold the why, the decisions, the things you cannot query. But they are a diary, not a dashboard. The state of a live system is not something you remember. It is something you check.

So the rule I am keeping:

1. When build state matters, hit the live endpoint before you read a single note.
2. Count the real things. Tools registered, rows present, version deployed. Numbers, not summaries.
3. Treat any status note older than your last deploy as a rumor, not a fact.
4. When two records disagree, do not arbitrate. Go ask the machine.

The cheapest hour I saved all week

I did not write any new code that morning. I ran one deploy and applied three migrations that were already sitting in the repo. The “open loop” was smaller than every note made it look.

The win was not the fix. The win was not believing my own paperwork.

The running system is the only honest witness in the building. Everything else is just a story about what used to be true.

---

Frequently Asked Questions

What is the difference between “merged” and “deployed”?

Merged is a fact about a git branch. Deployed is a fact about a server. In a tidy pipeline they happen seconds apart, so they feel like one event, but they are two different machines reporting two different states. A pull request can be green, approved, and merged while the thing your users touch is still last week’s build. The only way to close the gap is to ask the server what it is running right now.

Why should I not trust my own project notes about build state?

A status note is accurate the moment you write it and starts decaying immediately, because the system keeps changing and the note does not. Notes hold the why, the decisions, and the things you cannot query, so they are worth keeping. But they are a diary, not a dashboard. When two notes disagree, do not pick the one you trust most. Go ask the running system instead.

How do I actually check what a system is running?

Interrogate the live process rather than reading about it. Hit the endpoint and look at the real response. Count the real things: tools registered, rows present, version deployed. Use numbers, not summaries. Treat any status note older than your last deploy as a rumor, not a fact.