Late in the day I plugged a Raspberry Pi 5 into the Apple Studio Display using a micro-HDMI to USB-C cable and got nothing. No splash screen, no error, just a monitor that didn’t react. After some debugging I found the reason: the Studio Display only accepts Thunderbolt 3 video input. It cannot receive HDMI. The USB-C Digital AV Multiport Adapter - the one Apple sells for connecting Macs to HDMI TVs - is a one-way converter. It sends Mac video OUT to HDMI devices. There is no path from a Raspberry Pi’s micro-HDMI output to a Studio Display input. The solution, I thought, was going headless - SSH from the Mac on the same network. But the Pi I bought had all the ports locked down in the configuration, so SSH wasn’t an option either. Amazon is bringing me a 7 Inch IPS LCD Touch Screen Raspberry Pi Monitor Display tomorrow morning.
The rest of the day was software.
Things We Learned Today
The demo mode work for AuthorMagic - a book management platform for authors - produced the most useful single insight of the day. The original design called for dedicated “demo accounts” with special mechanisms: discount code redemption to grant subscription tiers, admin override tables, promote and clear buttons, lifecycle tracking through launch cohorts. Around 200 lines of infrastructure for simulating what an alpha user experiences.
Then I looked at actual alpha users in production. They’re just regular users. Same auth flow, same database rows, same policies. The only thing special about them is they’re in a launch cohort and have a tag.
So the demo “New User” flow became: create a real user, give them a name, add them to a cohort, then impersonate them. That came to about 50 lines. Every feature works because the app doesn’t know the admin created the account - to the app it IS a real user session.
The lesson for me: before building a mechanism to simulate X, check whether you can just do X directly.
Getting there did require one detour. Demo accounts had their book and sales data flagged as synthetic, and every service in the codebase filters that data out - correct behavior for real users who also have sample data mixed in. This is catastrophic for a demo account whose only data is that synthetic seed data. The fix was to mark the demo data as real. I found the same filtering bug in 17 files. The deeper pattern: when a boolean flag exists to separate real from synthetic, a demo mode has to audit every filter in the query chain.
Configuration drift in monorepos follows a predictable pattern. When CureCancerMagic - a cancer care coordination app - was added to the platform, the “big” items got updated correctly. But 10+ ancillary configurations were missed: CI test matrix entries, security scanning lists, secrets validation scripts, backup scripts. The omissions only surfaced later when something broke.
The structural reason: the central app registry is enforced by TypeScript’s type system, so adding a new app creates compile errors everywhere a config is missing. The type system catches the important stuff. The 20+ ancillary configs are scattered across shell scripts and YAML files that the compiler can’t reach. Those require a checklist. The runbook created today organizes the full process into 6 sequential phases with checkboxes precisely because of this.
Context window economics annoyed me again so I did a cleanup. About 46,000 tokens were being consumed before any user interaction in a Claude Code session on this codebase - roughly 23% of the available window. The most actionable finding: the pattern of pointing to large docs that only load when needed is already in place, but wasn’t applied consistently. Moving 8 rarely-used rules to on-demand references saves ~6,500 tokens with zero behavioral change.
React 19’s useTransition has a subtle issue with server actions: errors don’t always propagate to the surrounding try/catch - they can go to the nearest Error Boundary instead, leaving the loading spinner stuck forever. The symptom is a button that spins indefinitely with no error message. The fix is to manage loading state manually with useState, which gives complete control over the lifecycle. useTransition is designed for non-urgent UI transitions. It’s the wrong tool for server action error handling.
Things We Did Today
CureCancerMagic went from schema and initial landing pages to a working auth flow, dashboard navigation, and unit test coverage. The data architecture is fundamentally different from other platform apps - it’s case-scoped rather than user-scoped, which is what you need for multiple care team members collaborating on a single patient’s record. Getting it running locally produced a few bugs worth noting: Next.js 16 is stricter about when you can write cookies (not during rendering, only during mutations), and the redirect behavior on unauthenticated access needs a landing page that doesn’t itself redirect authenticated users away, or you get an infinite loop.
The AuthorMagic book website publishing pipeline reached end-to-end. The full chain now works: author edits their landing page config in AuthorMagic, an adapter translates it to the platform’s standard site format, Hugo generates the pages, and it deploys to a per-author Vercel project. The integration test caught a bug the unit tests missed - the adapter produced a valid type but the validation layer had a naming convention the tests didn’t cover. This is why unit tests and integration tests aren’t substitutes for each other.
The review triage system got an overhaul. The old logic used file count as the primary signal: small changesets got no review. This is a bad discriminator - one file can have a security hole, and three harmless renames aren’t risky at all. The new logic uses content type: any source code change gets at least a lightweight review, regardless of how many files. Review agents now run in parallel, which makes multi-agent review essentially free in wall-clock time.
Other things that shipped: email infrastructure consolidated across five apps, Sentry filtering cleaned up, a cron job timeout fixed, the pre-commit hook fixed for a symlinked directory edge case, and a deep code review pass on the Freshell open-source project.
Fun Things to Try
Linear’s GraphQL API has an email intake address feature that the MCP server doesn’t expose. You can hit the API directly to generate a @linear.app address that routes emails into a team’s inbox as issues. This is worth knowing as a general pattern - when an MCP server doesn’t expose something, dropping to a direct API call often works.
The review ecosystem audit surfaced one architecture improvement worth trying: a synthesis pass after agents run in parallel. Right now findings get concatenated. When two agents independently flag related issues on adjacent lines, they show up as separate items. A synthesis agent that reads all the outputs and merges related findings would reduce noise considerably. I’d implement it as a general-purpose subagent rather than a custom agent - deduplication is orchestration, not domain-specific review logic.