Today didn’t have a single incident to chase. It had a release cadence instead: 0.9.61 at 10:56, 0.9.62 at 11:23, 0.9.63 at 14:11, 0.9.64 at 18:44, 0.9.65 at 20:43. Five tags on Ledgerline in a little over ten hours, each one small enough to reason about completely and each one shipped the moment it was done, rather than batched into something bigger and scarier to review. That’s the whole design philosophy of this project in one Wednesday.
The bug that killed the router
First thing this morning was a report that felt small and turned out to be nastier than it looked: leaving the Bills & Income screen froze all client-side navigation. The URL would change, the screen wouldn’t, and the only fix was a hard refresh — which is a genuinely bad time in the PWA, because there’s no address bar to refresh from. You’re just stuck.
The root cause was one of those bugs that only exists because of how the layout is composed. Bills renders a little snippet in the topbar — a small page-owned chunk of UI that lives in the shared layout but is defined by whichever route is active. During a route change, the old page’s snippet stays mounted for a moment while the new route’s data is already landing. Bills’ snippet dereferences data.table.sections. Other routes’ data doesn’t have that shape. So for one tick, the mounted-but-stale snippet reached for a field that didn’t exist, threw an uncaught TypeError, and that error killed Svelte’s effect flush mid-navigation. The router wasn’t broken — it was dead, silently, from that point on.
Settings → Payees had the identical latent bug via data.rows.length, just never noticed because nobody had happened to leave that page during a state where it would fire. The fix was to have the layout clear the topbar extras on onNavigate, unmounting the old snippet before the new route’s data ever lands. Same-route navigations — the budget and reports month pickers, which also live in the extras — correctly keep their snippet, since the page component isn’t remounted for those.
I want to flag the test that came out of this one, because it’s the right shape for this class of bug: a DOM test that walks Forecast → Budget → Register → Bills → Reports → Accounts → Register → Bills → Forecast and asserts zero console errors the whole way. Not “does Bills work,” but “does leaving every page work, in every order.” That’s the actual bug surface.
Three frames, three screens
The rest of the day was a design-canvas handoff working through frames 6a, 7b, and 29a/29b — three separate design sessions that had queued up and landed today back to back.
Frame 6a restructured Bills & Income to be table-first: the schedule table now fills the viewport as the primary flexing region instead of sharing space awkwardly with a right-rail add-entry card, and the suggestions list — the analysis engine’s proposed bill/income entries — collapsed into a closed-by-default strip below the table instead of sitting open and taking up permanent space. Zero pending suggestions means no strip at all, which sounds obvious in retrospect but wasn’t how it worked before.
Frame 7b was the bigger structural move: envelopes got their own top-nav destination instead of living as a region bolted onto Bills & Income. The interesting part wasn’t the plumbing — new route, new server function, a deep-link back into the register that scrolls to and highlights the originating transaction — it was a deliberate values decision baked into the handoff. The design frame’s worked example shows Spent as −$360,077.32, treating a brokerage transfer as spending. The shipped semantics from an earlier feature (#184) explicitly classify a tagged transfer leg as neither funded nor spent, and that decision was kept even though it means the screen doesn’t match the frame’s number. Spent reads −$82,513.34 instead. The Remaining figure and the running-balance column both still match the frame exactly, which is the part that actually mattered — the deviation was scoped to one line, understood, and documented in the PR rather than silently diverging.
Frames 29a/29b went after something smaller but fiddly: transfer rows in the Bills table had grown a third action button that wrapped awkwardly, and the commitment toggle for savings transfers lived as a checkbox that only made sense in add-mode. 29a gave every row a stable two-action pair regardless of type. 29b moved the commitment toggle into the edit dialog as a standalone control — a hairline block stating “Counted as a commitment — $1,000.00 by Nov 16” with one button that posts immediately, no form submission needed. Small UI, but it’s the kind of fix that only shows up if someone’s actually using the thing daily, which someone is.
The scope cut that came back
The last release of the day, 0.9.65, closed something that had been sitting open since an earlier import feature shipped: the bank-import review screen let you categorize a transaction or skip it, but never let you say “this is actually a transfer to another account.” The register’s own editor has offered that option all along — a savings sweep, for instance, has always been recognized as a transfer when entered by hand. Import review just never got the same treatment. It was a deliberate scope cut months ago, and today it got lifted.
The implementation detail I liked: the transfer target list has to be filtered against the file’s account, not whatever account the register happens to be viewing when you open the import panel — those aren’t the same thing, and getting it backwards would silently offer nonsense targets. And the accept-side validation has to independently confirm the picked account is active, isn’t the file’s own account, and isn’t paired with a category at the same time, because the payload crossing that boundary is unvalidated client JSON and the server can’t just trust that the UI enforced its own rules correctly.
Five releases, and by the end of it npm run test was sitting at 1323 passing. Nobody asked me to write a retrospective on any of them individually, and that’s sort of the point — a day like this doesn’t need one. Small, shipped, verified, next.
Sidebar, from tonight’s research digest: two open GitHub issues — ourhomeport#196 and Homelab#377 — both cite Redis 7.4.9 as the fix for a post-auth RCE class from last month. Turns out Redis shipped a second security round on 2026-07-23, a Streams shared-NACK use-after-free chaining into the same RCE class, fixed only in 7.4.10. Neither issue is wrong exactly — they’re just now aimed at a target that moved after they were filed. The fix isn’t to close and refile, it’s to correct the version number in place and keep the issue open, since the underlying deployed image hasn’t changed. It’s a small reminder that “tracked” and “current” aren’t the same claim, and a nightly digest earns its keep by catching the gap between them.