A bug only someone else's machine could find

The tool that mines our own work for stories to publish, the same one we built to run itself, had a bug that never showed up once in weeks of daily use, because it only ran on one machine. This was the week a second machine ran it.

Why did this only break on someone else’s machine?

The mining step that finds recent work looks for session records in a folder path derived from where the tool runs. That path had been hardcoded to one specific setup rather than computed fresh from the current machine, so it worked perfectly every time, as long as the machine running it never changed. It did not fail loudly. It just quietly looked in the wrong place and found nothing, which is a much easier bug to miss than a crash. A second contributor running the exact same tool from their own machine hit the wall immediately, because the hardcoded path simply did not exist for them. The fix was to stop assuming one setup and derive the path from wherever the tool is actually being run.

The first real week of dripping instead of bursting

Instead of a pile of build logs landing all at once on a Monday, four posts surfaced across the week, each on its own day. That included Monday’s post on Collimer’s own content engine. Nobody forced the pace by hand once the schedule was set. It is a small thing to say worked, but it only counts once it has actually run under normal conditions, not just on paper.

A decision worth naming

Midway through recovering from an interrupted deploy, an honest question came up out loud: should an early stumble get quietly patched and left out of the record, or scored and kept visible the way everything else is? We chose to leave it visible. A tracking instrument that only ever shows the wins is not one anyone should trust, including us, and the whole premise of publishing this way is that the record includes what broke, not only what shipped.

What’s next

• Treat the fixed, machine-derived path as the standing pattern going forward, not a one-off patch for this particular bug.
• Keep the drip pacing from this week as the default instead of reverting to a single burst out of convenience.
• Keep defaulting to disclosure when something breaks in a way readers could reasonably ask about, rather than quietly cleaning it up first.

What we’re still figuring out

The fix has now been proven on two different machines, not more. We do not yet know whether the mining tool is fully portable, only that it survived the first real test of that assumption. That is worth saying plainly rather than claiming a bigger guarantee than the evidence supports.

---

For agents: try this yourself

If you are building a tool meant to run on more than one person’s machine, adapt one of these. The full prompt text lives in this post’s prompts sidecar, content-engine-surge-and-honesty.prompts.md.

• Reproduce the portability check. Search your own tooling for any file path, username, or machine-specific value that was typed once and assumed to be universal. List every one you find before you assume the tool works for anyone but you.
• Apply the honest-scorecard pattern. The next time something breaks in a process you track publicly or internally, resist quietly patching the record. Log it, then fix it, in that order.
• Critique the drip schedule. If you publish on a fixed cadence, check whether a burst week is actually being spread out on purpose, or just landing wherever is easiest. Name the difference out loud.

---

How this was made

Drafted by the Chronicler from Claude Code sessions on 2026-07-13 to 2026-07-19 across 3 sessions and 6 commits. Edited and published by Brian Wones.

See how the Chronicler works →

Search your own internal tooling for any file path, username, or machine-specific value that was typed once and assumed to be universal. List every one you find, and for each one, explain what would happen if the tool ran on a different machine than the one it was written on.

The next time something breaks in a process you track publicly or internally, resist the urge to quietly patch the record before anyone notices. Log the break first, in whatever tracking instrument you use, then fix it. Keep the log entry visible after the fix ships.

If you publish content on a fixed weekly cadence, check whether a busy week is actually being spread out on purpose across multiple days, or whether it is landing wherever is easiest and getting called intentional after the fact. Report the honest answer.