The File I Edited Wasn't the File That Shipped

Two copies of one number

PocketBill exists to answer one boring question: does what I remember about my money match what actually happened? It will not take my word for whether that subscription is still running. It goes and looks. Last week I spent an evening on exactly that problem, one directory tree away from my users.

The deploy was fine. That was the trouble.

The build wrote somewhere I wasn't looking

The site has two stages. A build script turns drafts into finished HTML and writes them into a folder called blog. The host, meanwhile, only ever uploads a different folder called public. Between them sits a copy command — run it by hand after a rebuild, and the new pages land where the deploy can see them. Nothing in the deploy checks whether you did.

So the sequence I ran was: edit the draft, rebuild, deploy. Real output, real exit code, a line that said the deploy had completed. The live page was still yesterday's.

Nothing errored, which was the problem

There was no error to read, because the build did its job and the deploy did its job. The mistake lived in the gap between two tools that were both correct — and that gap was me, holding a line of shell I had to remember.

It is not a broken pipeline. It is an unenforced one. Two copies of the same page sit on my disk, and whether the right one goes out depends on a person recalling a step from a runbook. The fix is unglamorous and I have not written it yet: make the deploy compare the two copies and refuse to ship when they disagree. Machines are very good at noticing that two things should match. They only have to be asked.

The manual that outlived its method

There is a slower trap in the same folder. An older version of the runbook still describes the authentication flow I should use: a long-lived token, generated by a command, pasted into an environment variable. That token expired. On this network the command that issues one no longer even finishes, because the step it depends on needs a connection that does not work from here.

The file is dated, but only at the version level — the method inside reads as current. Following it costs an hour before you conclude the tool is broken. Documentation never fails loudly. It just stays plausible after it stops being true.

So now I date the methods, not the file, and delete the ones I have replaced. The old flow is not history worth keeping. It is a future afternoon.

What a single copy buys

PocketBill's answer to this whole class of problem is to never have two copies. Your subscriptions, bills and spending live on the device and nowhere else. No build step, no upload, no copy step to remember — and therefore no gap for a mistake to sit in. The number you see is the number that exists.

That trade costs me things. But it does mean I have never shipped a page that looked untouched, and never had to explain to myself why the thing I just edited was not the thing on the screen.