Dev Log: 2026-08-08 - stubs that answer politely, and a CSS property that doesn't exist

Heavy day, mostly on one private deployment platform, plus a small but instructive fix in a PDF book engine and a pass over a product marketing site. The through-line, and I didn't see it until I read the day back: almost everything was a thing that answered without being able to answer. A stub that says yes. A column with no producer. A CSS rule the renderer doesn't implement. 1. The platform: making the fakes declare themselves Fourteen commits, and they're variations on one theme. An approval gate that approved everything. A rollback engine with a contract and a fake whose step classes didn't exist - so a previous piece of work read the whole seam as scaffolding and routed around it. A complete access-review model with zero callers, meaning the compliance control it was written for couldn't be evidenced at all. A public-IP column with a migration, a UI row, and no driver anywhere that ever set it. The fix that generalises: make "which parts of this are real?" an enumerable question. One enum case per resolvable capability - driver, agent, reverse proxy, load balancer, runtime - so a deliberate fake and an accidental fake stop looking identical in the code. Two rules I'll be reusing: - Write compliance evidence outside the transaction it describes. Inside, it rolls back together with the thing it was recording - you lose the record exactly when you need it. - Null is unknown, not zero. An unreachable provider is not a cluster that shrank to nothing. Keep the last known value and say so. Also landed: a bootstrap pipeline that handles both Debian and RHEL families from one path. The trick there was giving up on package lists - dnsutils is bind-utils , gnupg is gnupg2 , iproute2 is iproute . A template naming packages is a template that works on exactly one family. So the baseline is stated as capabilities ("DNS tools", "time sync", "firewall") and an OS profile turns each one into the right names for the machine in front of it. Steps stop branching on the OS entirely, which is what makes the difference between the two families assertable in a test instead of only on a real box. Written up properly in a separate post. 2. The book engine: I explained a bug with a property that doesn't exist My favourite kind of commit - the one that deletes yesterday's fix. I had a pagination problem in a print stylesheet: headings getting stranded at the bottom of a page with their content pushed to the next. The fix I'd reasoned out relied on break-after: avoid being transitive - heading welded to intro, intro welded to whatever follows. It isn't transitive. It doesn't exist. The rendering engine honours break-inside only and ignores break-before /break-after: avoid along with the legacy page-break-* aliases entirely. So every weld I'd added was inert, and the chain-cutter I'd introduced to stop the welds running away cut nothing. The bug was real; the mechanism I'd explained it with was fiction. Two things came out of it: - The dead rules stay in the sheet - they're correct CSS and cost nothing if the print path ever moves to an engine that implements them - but they're now documented as dead, in a comment at the head of their section. Specifically so the next pagination bug isn't diagnosed in their terms again. - The actual fix uses the mechanism that does work: wrap the pair that must move together in one box with break-inside: avoid , and tag oversized code panels so they're allowed to break rather than being forced onto a fresh page and stranding the heading above them. The general lesson, and it's not really about CSS: before you explain a bug in terms of a mechanism, check that the mechanism is implemented. A plausible explanation that produces a plausible fix and no observable change is far more expensive than no explanation, because it stops you looking. 3. Marketing site: every claim has to be checkable in the codebase Smallest diff, most discipline. A pass over a product site to align what it says with what actually ships - a provider list corrected to what's implemented, deployment modes folded down to the ones that exist, spec tables replacing prose. Not a code lesson. Still a real one: the marketing page is documentation with a shorter feedback loop and a worse failure mode. If a claim on it can't be traced to something in the repo, it's a bug - just one that gets reported by a customer instead of CI. What's next The capability enum only covers the resolver's own methods right now. The obvious next step is rendering it as a per-provider readiness table in the UI, so "this provider is 60% real" is something an operator sees before they deploy onto it, not after. Top comments (0)