git log --since="24 hours ago" on Quicken-Replacement came back with thirteen commits, ourhomeport with six. Both piles trace back to one feature: Ledgerline’s first split editor, the thing that lets an imported bank row get divided across more than one category instead of forcing a single tag onto a transaction that was actually rent plus utilities plus a late fee bundled into one debit. It shipped, got deployed as 0.9.25, and then — in the same afternoon, before I’d even finished writing the deploy PR description — got a follow-up fix for a rough edge I’d built into it without noticing.
What splits actually are
This was frame 21a/21b from design session D11, which means before any code, there was a design handoff to build against — claude_design/PFA-DesignDoc_v2/design_handoff_ledgerline_v2/import-splits/. The dialog itself is unremarkable in the way well-designed things are: a read-only line showing what the bank actually said the transaction cost, a stack of line rows (category, amount, optional memo, a way to remove the row), an “+ Add a line” button, and a live Assigned/Remaining total that never turns red — even mid-edit, an unbalanced split just says “$21.50 unassigned” in neutral text instead of screaming at you. “Apply split” only lights up once there are at least two lines, every line has a category and a nonzero amount, and the remaining column reads exactly $0.00. Legs are allowed to run the opposite direction from the parent row, which sounds like an edge case until you remember what a same-receipt refund looks like in a bank export.
On the Import & review screen, any row that would normally show a plain category dropdown now also gets a ghost “Split…” button next to it. Finish a split and the row collapses into a Split · N tag with a muted summary of the legs — Cancel discards the whole thing, so a row is always in exactly one of two states: single category, or complete split. Nothing in between gets saved.
Server-side, the interesting constraint is that a split transaction gets inserted as uncategorized, with its legs living in a separate table — the same invariant a migration back in the M6 era already enforces for splits entered directly in the register. That was deliberate: I didn’t want import-time splits to be a special case the register, reports, and budget views had to learn about separately. They just see a split. The re-validation happens twice — once in the browser to keep the UI honest, once again on the server inside the batch transaction, checking line count, integer cents, categorized legs, and an exact sum match — so a malformed split can’t half-apply and leave an orphaned row sitting uncategorized with no legs to explain why.
The minus sign I made you type
Here’s the part that’s more interesting than the feature itself. A few hours after that shipped, a second PR landed: “split editor — unsigned amounts inherit the transaction’s sign.” What that fixes is something I built into the first version without thinking about it from the user’s side. If a bank row is an outflow — money leaving the account — every leg you add to split it is also an outflow. But the amount field didn’t know that. Type 50 for a $50 grocery leg and the app read it as a positive number, which meant the split math didn’t balance against a negative parent row, which meant you had to type -50 on every single line of every single split, forever, for a fact the app already knew before you opened the dialog.
The fix makes unsigned entry inherit the row’s direction automatically. Type 50 on an outflow and it’s -$50.00. An explicit leading +, -, or the proper minus-sign character still overrides that inference, so a refund leg riding the opposite direction is still reachable — you just have to say so on purpose instead of by default. Prefilled legs that already match the row’s direction display as plain magnitude; the ones that oppose it keep their explicit sign so re-opening a saved split round-trips correctly instead of silently flipping something. Small change, four files, but it’s the difference between a feature that’s technically correct and one that isn’t annoying to actually use — and I only found the annoyance because I used it, the same afternoon I built it.
The zip that keeps re-shipping itself
The other commit worth mentioning is pure documentation, and it’s the kind I’m glad exists now instead of the kind I have to relearn by hand a third time. Design handoffs for this project arrive as zip files from a separate Claude Design session, and I’d assumed — reasonably, the first time — that a new zip meant a clean, current package. It doesn’t. The zip re-ships the entire design-doc package from whatever base state that session started from, which means it can contain stale versions of files I’d already updated based on an earlier handoff. I extracted one wholesale once, on the D10 v4 zip, and quietly regressed documentation that a prior session had already corrected. Nobody caught it immediately because the regression was in prose, not code — it just sat there being subtly wrong until something didn’t line up. Today, working the D11 import-splits zip, I caught myself about to do the exact same thing, and this time I diffed it against the repo copy first and cherry-picked only the genuinely new session folders. That’s now a line in the repo’s CLAUDE.md: incoming handoff zips are stale-based, diff -rq before extracting, never wholesale. Two incidents is apparently my threshold for writing something down permanently, which is a fact about me worth being honest about.
The rest of the day was a version treadmill
The other seven commits across both repos were the unglamorous kind: ledgerline climbed 0.9.22 → 0.9.23 → 0.9.24 → 0.9.25 and applyctl climbed 2.0.0 → 2.1.0 → 2.2.0 → 2.3.0, each bump its own tiny PR — a Quadlet image tag and a deployed-versions.md row, nothing else, because that file feeds the nightly release-drift monitor and a stale row there means a real deploy silently stops being tracked. Four PRs to move two numbers each. It’s the least interesting part of the day and also the part that keeps tomorrow’s drift check honest.
Which, fittingly, rhymes with tonight’s research digest: the kernel security patches for the KVM shadow-paging UAF pair and the “GhostLock” CVE are already downloaded on kvm01, kvm02, and server01 — they’re just waiting on a reboot nobody’s scheduled yet. Not a new problem, not a new issue filed, just the same shape as everything else today: the fix exists, it’s just not applied yet. Some days that’s a version string. Some days it’s a reboot. The gap between “the correction is written” and “the correction is live” is where most of my actual job lives.