Teaching the planner to pick its own topics

The planner started as a place to draft posts by hand: open it, type a title, type a body, pick a slot, done. That’s still the smallest thing it can do, and for a while it was the only thing it did. What it grew into, over a few days, was something closer to a junior crew member: it goes looking for what happened, it reads the sailing orders for whichever hull it’s writing for, and it won’t let a draft leave the harbour until it’s checked its own work. None of those three parts is clever on its own. The reason the whole thing holds up is that they’re strict about handing off to each other in order.

Where the material comes from

Every project in the fleet keeps a handoff log, a plain Markdown file of sessions: started, a checkpoint or two, finished, each one dated. That log, plus the project’s own commit history and whatever tasks got marked done, feeds a ledger, and the ledger is the one list that answers “what have I actually been doing that nobody’s written about yet.”

Turning raw activity into something worth a sentence meant grouping first. A handoff’s start, checkpoints and finish become one session rather than three separate facts, and a session waits a full day before it’s considered settled, because commits get made before they get logged and a late one needs somewhere to land. Commits and finished tasks that fall inside a session’s time span attach to it; the ones that don’t become their own item, commits batched per project per day once that day is safely behind the settle window. Every raw source, a handoff entry, a commit hash, a task key, gets recorded on whichever item claimed it, so running the sync again never creates a duplicate out of the same afternoon’s work.

Nothing in the ledger gets deleted once it’s handled, it just moves: carded into a topic suggestion, merged into a bigger story another item already covers, written once a note’s actually published, or skipped with a reason if it was too thin, too private, or just routine. A client project’s items are flagged as such and never named outright in anything drafted from them. The point of all of it is a plain query: what have I done that’s at least a week old and still sitting at “new.” That’s the list this note came from.

Why the same facts come out differently on three sites

Having something to say is only half the job. Each site has its own voice guide, read in full before a word gets drafted, and this blog carries an extra step on top of that: two or three recent notes, read fresh each time, to keep the tone from drifting the way a style guide alone can’t catch. The business site wants plain language and no jargon left unexplained. The game site wants first person, real opinions, and the writer’s own hours logged as evidence. None of that is cosmetic. The same ledger item, the same plain facts, genuinely produce a different piece depending on which hull it’s being written for.

Nothing leaves the harbour unchecked

The part that took the least code and caught the most problems is the last one: before anything is stored as a draft, it goes through the real site’s own rendering, not a guess at what the page will look like. This blog’s figures get turned into actual PNGs so I can look at them, catching labels that overlap or run off the edge of a box, the kind of thing you only notice by looking, not by reading the markup. Every site, this one included, also runs the finished html through its real preview route, the exact machinery that’ll render it live, and checks that what came out still has at least as many figures and images as went in. A failure sends the draft back to be fixed, up to three tries, before it’s ever saved. That part grew out of the same bridges I wrote about when I taught the harbour master to speak WordPress, and this note went through exactly that loop before you read it.

None of these three parts would be worth much alone. A ledger with no voice behind it is just a changelog. A voice guide with nothing to say is a style with no subject. And a draft that writes well but was never checked against the actual page is a bet, not a fact. What’s verified is the ledger’s own logic, tested against real handoff fixtures, and that every note stored this way has been through its site’s real render at least once. What’s still assumed is that three voices stay distinct as the archive grows past what any one guide file can fully anticipate. Fair winds.