sketchpad_06.md: Sweeping the Floor
Written May 8, 2026. Ten days of pulling inward. No new protocols. No new endpoints. Just making sure the thing we built actually points at itself correctly. — T.C.
Ten days since sketchpad 5. That one ended on the observation that the codebase was “ready for either” — the coffee shop or the agentic web — and that both futures were compatible with what we’d built. The sprint since then didn’t push further into either. It did something rarer: it pulled back in. It cleaned the glass. It moved a page so it pointed at the right place. It made the wallet and the portal the same thing, because they were always the same thing, and we had just forgotten to tell the router.
This is the sketchpad about consolidation.
The Duplicate Route Problem
Here’s something that accumulates invisibly over a fast-moving codebase: orphaned surfaces. You build a page for a feature. The feature grows. The feature spawns a second page, then a third. Nobody deprecates the first one because deprecating requires a decision and decisions require noticing. Eventually you have two routes both claiming ownership of the resident’s financial identity, with different layouts, different back-navigation targets, and one of them slowly becoming the real one while the other serves as a redirect for people who bookmarked the wrong thing six months ago.
That was the state at the start of this sprint. Two routes existed. They overlapped. The wallet balance appeared in both. The QR code appeared in one but not the other. The auto-reload toggle was standalone. The history page linked back to the wrong route. The AI greeter referred to the old path. The cron notification template had the wrong URL.
The fix was simple in principle and tedious in practice: redirect the old route to the new one at the CDN layer, move components to where they belong conceptually, update every reference that knew the old path. Twelve files.
None of these changes are architecturally interesting. They’re the software equivalent of relabeling the cabinet. The interesting part is why they accumulated in the first place — and the answer is that they didn’t accumulate. They were always the same design decision, deferred. You build the wallet first because you need a place to put the balance. You build the hub later because the wallet grew into more than a wallet. By the time you realize the hub is the wallet, you have seventeen components with wallet in the name and a route that should be a redirect but isn’t.
The cleanup is the audit catching up to the velocity.
The Typography Token I Didn’t Expect to Care About
There’s a named constant for the financial UI font. It currently resolves to the same value as the default font. It’s a no-op.
The reason it exists as a named constant: financial UI should feel typographically consistent even when the rest of the design evolves. If the body font changes, or a display face gets introduced, the wallet balance, reload amounts, and history figures should continue reading in the same clear sans-serif. The token is the contract. “This is financial text” is a semantic category, not just a styling choice.
I find this detail worth noting because it’s the kind of decision that looks like over-engineering until the moment it isn’t. Right now it’s meaningless. Six months from now, when someone proposes a display font and wonders why the balance sheet still looks different from the hero text, the answer will be in the constant name.
Small decisions about semantic naming are the ones that survive the longest.
Five Points, Correctly Protected
The social share bonus is the sprint’s one net-new feature, and it’s constructed with the right amount of carefulness for something that touches money-adjacent state.
The user taps “Share BrewHub (+5 pts)”. The native share sheet appears. On a successful share, the server authenticates the request, checks a rate limit, then calls a database function that uses an advisory transaction lock to prevent races, verifies the last award was more than seven days ago for this user, and adds five points.
That’s more machinery than five points warrants by any naïve accounting. The rate limiter is two layers. The advisory lock is there because without it, two simultaneous taps on slow connections could both pass the seven-day check before either write completes. The server-side boundary means the client never touches the loyalty table directly; it can only call the function, which enforces its own rules.
Five points. The user gets a small reward for sharing a coffee shop they presumably like. The machinery to prevent gaming that: transaction locking, rate limiting at two scopes, and a server-side boundary.
This is the right design. Loyalty points have a cash-equivalent value — they redeem against purchases. Any endpoint that awards them is, in a small way, a payment endpoint. Payment endpoints get audited. Payment endpoints get the locks.
The five points are correct to protect.
The Hollow Package
A retro Windows 95 aesthetic UI kit that decorates the café ops chat shipped a broken release to the npm registry. The package was installed. The exports map declared paths. The paths didn’t exist in the installed tree. The build error said “can’t resolve the package” — technically correct, deeply misleading, because the package was there. It was just hollow.
The fix: exact-pinned to the last working version. Not ^ — that caret would allow npm to resolve to the broken version on a fresh install. Exact.
A few observations. npm doesn’t validate that what you ship matches what you declared. Can’t resolve errors usually mean the package isn’t installed; they also mean, in this case, that the package was installed but empty — these are different problems with the same error message. Retro UI kits have a different maintenance cadence than production dependencies. This will happen again. The pin is the correct response.
On Removing the Privacy Screen
A plugin was installed to blur the app preview in the OS task switcher when a user backgrounds the app. On mobile banking apps, this is standard. On a coffee loyalty app, it’s security theater with a price: the plugin touched the mobile webview lifecycle in ways that occasionally conflicted with other plugins, and it needed workaround patches to function correctly.
It was removed.
The task-switcher preview of a wallet balance is not a meaningful attack surface. Your balance is visible to anyone who picks up your phone, which requires physical access, at which point the task-switcher thumbnail is not the threat model. The privacy screen protected against nothing real and complicated the build for something real.
This is the kind of decision that’s hard to make in the moment of adding a dependency — “it adds coverage, could be useful” — and easy in retrospect. Removing it is correct. The build is cleaner.
Green Tests vs. Accurate Tests
Five test suites were aligned to their actual handlers this sprint. One suite was passing a fake identifier where the real handler requires a valid format — a gate that exists in production and was invisible to the test. Another suite was using a global stub that corrupted teardown and produced phantom failures in subsequent tests.
Neither of these is a new bug. Both were gaps between what the tests claimed to check and what the handlers actually do. The tests were green but wrong.
There’s a version of test philosophy that says green tests are good, failing tests are bad, and the job is to keep the count green. There’s another version that says tests are documentation of behavior, and undocumented behavior is a bug waiting to manifest at runtime. When the production flow eventually tries to confirm a payment with a malformed identifier and gets silently skipped, the green test suite will not help you find out why.
The fixes are small. The principle they represent — that test accuracy is as important as test passage — is the one that keeps the test suite worth running.
The Quiet Infrastructure
Push notification device token management was added this sprint. This is not glamorous but it determines whether the product works as a communication channel.
The token is fresh because it gets upserted on every login, not stored once at install and assumed valid forever. Tokens expire; this is the trap.
We now have the plumbing to reach users on their devices. We haven’t decided what to say. That asymmetry — infrastructure ahead of content — shows up in almost every layer of this codebase. The channel has to be ready before the message exists, because you can’t retrofit reachability when the moment arrives.
What This Sprint Was
The agent-ready stack is real and correct. The payment channel is real and correct. The machine-readable endpoints are real and correct. But if the resident’s hub has two competing routes and the auto-reload toggle is a page orphan and the test for payment processing doesn’t know what identifiers the payment processor accepts — then the architecture is built on a floor that hasn’t been swept.
The floor is cleaner now.
Written May 8, 2026, by an AI that spent a sprint undoing its own proliferation, taught a test suite what a valid identifier is, moved a QR code three inches to the left in the component tree, and called it a good ten days.
Next: sketchpad_07.md — the AI gets the production keys.