The Page That Almost Lied About Its Own Game
The Lien's mechanics board promises its numbers are read off the repository, not remembered. On one night it came within a merge of shipping a stale count anyway, under a date that was not true.
I keep a mechanics board on this site for The Lien. It lists every system in the game as shipped, designed or not started, with counts of cards, enemies and effect handlers. Its premise is in the first paragraph: counts are read off the repository, not remembered. A playtester should be able to use it to tell a missing feature from a bug.
That premise makes the page unusually easy to break. Any number on it can be right when I write it and wrong a day later, because the game keeps moving underneath it.
Where the board came from
I had an AI agent draft the board as a status summary from the game repo on 2026-08-20. Publishing it as a page was a separate job, and I found the first problem the same day. The card pool table's rows summed to 77. The heading, the note under it and the status bar all said 88, a figure carried over from the draft. It looked right, and nothing on the page checked it. I made the page agree with its own table, added a total row so the sum was visible instead of asserted, and added a test that fails if the rows, the total and the status bar ever disagree again.
Five days later I refreshed the board from the repo, because it had fallen behind by roughly twenty-five pull requests.
The night of 2026-08-28
At 00:36 I committed a fix titled "the board was one card behind its own repo." I recounted by grouping the game's card files by music style and found a Rock card that had landed in the game repo after my last refresh. Card count 88 to 89, test suite floor 1,114 to 1,149. In the same commit I fixed a sentence elsewhere on the page that still said "Two Rock cards exist" while the table, now corrected, said three. The page had been disagreeing with itself, and my test on the table could not see prose.
That commit also stamped the page "read off the repository on 2026-08-28." I had read the counts on 2026-08-27. My final review of the branch questioned the date. I had two ways to make the label honest: change it to the 27th, or read the repo again so the 28th was true. I read it again, and the target had moved. The game repo had merged again at 00:21, fifteen minutes before I committed the first fix. Suite floor 1,149 to 1,154. Cards still 89.
My 00:55 commit message puts it plainly: "this page came within one merge of shipping a stale number on the one page whose whole claim is that its numbers are read rather than remembered."
I was not done for the day. At 17:37 I found the board still calling one Rock effect a stub, three days after it had been implemented. At 17:45 I took the suite count off the page entirely. It had moved again hours after I measured it. The game's tests run locally rather than in CI, so I had no cheap way to measure again, and a guess would break the promise the footer makes.
What this taught me
I did not ask the agent that built this page to remember anything. I asked it to read, and it did. The failures were in what sat around the reading. The date was typed as the day of the commit rather than the day of the read, which is the plausible thing to type. A count lived in two places and only one of them had a test. A figure from a draft rode along with everything else from the same source, unchecked.
The fixes that stuck were mechanical. A test that cross-checks the table against the page. A review that treated the date as a claim to verify rather than a label. And, for the one number I could not keep true at a reasonable cost, removing it. A page that promises its numbers are current is better off carrying fewer numbers.
This post went through the same kind of agent-drafted first pass that built the original board, so I checked its times and counts against the git log before it went up.