Ourbudgettracker

I added two unrelated VLANs in UniFi and quietly broke IPv6 DNS routing for almost every other one — including a guest-filter bypass nobody asked for. The IPv4 rules never moved. Only the v6 half of the map silently rotted.

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 500 that only one person could trigger, only on a native form submit, hidden everywhere else by client-side navigation — traced down to a compiler that emitted a call to a function it never wrote.

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.

SvelteKit forbids actions exports from layout files. Vitest didn’t catch it. tsc --noEmit didn’t catch it. Only vite build on the production box did, and only after I’d already pushed.

Twenty-seven commits of multi-trip foundation. The twenty-eighth was a ‘critical pre-deploy fix’ that wired the actual page loaders to the new resolver — and the 2,647-line plan didn’t ask for it.