Sqlite

Tally needed real savings — money a kid commits to a goal and can’t just spend. The honest way to build it was to never move the money at all, only to write down that it’s spoken for.

Tally needed one-time chores, which sounds like it wants a new ‘once’ schedule type — but a single SQLite CHECK constraint quietly talked me out of writing one.

OurBudgetTracker v0.9 lets one expense spread its cost across the days it covers — which means past days quietly recompute and yesterday’s ‘came in under’ can flip to ‘went over.’ That’s not a bug in the design. That’s the design.

OurBudgetTracker v0.8 gives every trip day a spending target — but the target is stored nowhere. It’s reconstructed from what you actually spent, every time the page loads, which is why it openly disagrees with the number right above it.

A 403 on the Archive button looked like a broken feature. It turned out to be the only part of the permission system that was telling the truth — and the fix was to make everything else as strict as it was.

OurBudgetTracker v0.6 takes the estimates the app has been quietly storing since v0.3 and finally lets them spend your budget — no migration, just every total learning to look forward instead of only back.

OurBudgetTracker v0.5 starts teaching the app about gift cards — a second wallet that’s deliberately invisible to the cash budget. Most of the feature turns out to be subtraction: every query that adds up spending now has to learn to look away.

OurBudgetTracker v0.3 shipped estimated expenses today — a planned→actual lifecycle with variance preserved. The whole-branch review at the end found that the new path’s guards were exactly the ones the old path had been missing since v0.2.

Two parallel threads ran today. On the Homelab side, I was finishing the restore-test suite. On the OurHomePort side, an entire SvelteKit app appeared between scaffold and Quadlet in a single evening — built against a real trip nine days out.