I spent Monday morning deleting six thousand lines of code I wrote a few months ago. The BookSearchOrchestrator was a search pipeline for AuthorMagic - my book management platform for authors - that was supposed to unify how the system finds books across multiple data sources. I built it, tested it locally, and never shipped it. It sat in the codebase collecting imports and making the type checker slightly slower. Removing it felt like throwing out a draft that never became a chapter.
What happened when I tried to delete it is worth telling.
Things We Learned Today
TypeScript’s type checker has a blind spot that I keep forgetting about. When I removed the BookSearchOrchestrator’s modules, pnpm run type-check came back clean. Everything compiled. But there was a script in the scripts/ directory - test-rainforest-only.ts - that imported from the deleted code. The type checker didn’t see it because scripts live outside the tsconfig.json include paths. It would have broken at runtime.
The lesson is straightforward: type checkers only validate what they can see. When deleting code from a monorepo, always grep the entire repository, not just the TypeScript project boundary. The deep investigation step - a full-repo search for every import path being removed - is the one that catches the silent breakage. I caught this one. I wonder how many I haven’t.
This connects to something else I built over the weekend: snapshot-based regression testing for AuthorMagic’s book data algorithm. The book data pipeline pulls information from multiple sources - ISBNdb, Amazon, Google Books - and merges it into a canonical record. The merging logic has dozens of heuristics for resolving conflicts. When “title” from source A differs from “title” from source B, which one wins? The rules are subtle and I keep accidentally breaking them when I touch adjacent code.
The solution was to take a snapshot of the algorithm’s output against production data - real books, real conflicts, real merge decisions - and commit that snapshot as a baseline. Now every change to the book data code runs against the baseline and flags any difference. I wired it into the pre-commit hook so it’s impossible to skip. If the algorithm changes, you have to explicitly update the snapshot, which means you have to look at what changed. It’s the same principle as Jest snapshots but applied to a data pipeline instead of a UI component.
One specific bug the regression tests would have caught: leading articles in book title grouping. “The Great Gatsby” and “Great Gatsby” were being treated as different books. The fix strips “The”, “A”, and “An” from the beginning of titles before grouping. Simple, but the kind of thing that only surfaces with real data.
Things We Did Today
CureCancerMagic - the cancer care coordination app - had a big few days. Three features landed that together change how it works.
The first is an AI deep research panel (CURE-75). When a user is looking at a contact, a medication, or a treatment option, they can now ask the AI to go deep. It pulls context from the case, runs research, and presents findings in a conversational panel. The user can ask follow-up questions and eventually save a summary back to the case record. The design principle was that the AI should feel like a research librarian who already knows your situation - not a generic chatbot.
The second is global search (CURE-76). Every entity in the system - cases, contacts, communications, tasks, timeline events - is now searchable from one input. Before this, finding a specific oncologist’s email from six months ago meant navigating to the right case, then to communications, then scrolling. Now you type a name and it surfaces everything.
The third is a compose email dialog with AI-generated drafts (CURE-79). The care coordinator can start an email, and the AI drafts it based on the case context and the conversation history with that contact. The human reviews, edits, and sends. This is the first outbound communication feature - everything before this was inbound (ingesting emails and extracting information from them).
CompanyOS - my open-source company operations system - continued its multi-company evolution. The big new capability is an email agent: a Supabase Edge Function that acts as a Gmail-based AI assistant. You forward an email to a specific address, and the agent processes it - creating tasks, extracting contacts, filing information. It supports multiple Gmail accounts with domain-scoped sender authorization, so it can send replies from the right email address depending on which company context it’s operating in. The base64 encoding for email bodies needed a Unicode-safe implementation, which was one of those bugs that only shows up when someone emails you in a language other than English.
The commit skill (/co-commit) also landed, with partitioned flows for PR-based repos versus direct-push repos. It auto-discovers which CompanyOS clone you’re in and handles staging accordingly. And on the lighter side - a Spotify MCP integration with a /co-music skill, because why not have your operating system know what you’re listening to.
On the platform infrastructure side, two production releases went out. The GCP Secret Manager integration got hardened - the staging and production commands now explicitly set the gcloud account flag and verify worktree state before touching secrets. The landing page system got a Hugo-based deployment path with a two-step production publish flow. And the weekly code quality report now includes import-count verification to catch Knip’s systematic false positives around path prefix collisions and platform package re-exports.
Over in Freshell
- the browser based terminal-shell-browser-editor-cli-claude-wonderinterface that Dan Shapiro is building - a security fix landed for the /local-file endpoint. The allowedFilePaths sandbox wasn’t being enforced, which meant the endpoint could serve any file on the machine. The kind of bug where the security model exists in the config but wasn’t actually being checked in the code path.
Fun Things to Try
CureCancerMagic has a work-in-progress branch for ingesting iMessage and WhatsApp conversations (CURE-77). The idea is that a huge amount of care coordination happens in text messages - “the doctor said to call this number,” “here’s a photo of the prescription label,” “can you pick me up from chemo on Thursday.” Right now all of that is invisible to the system. If the ingest works, the AI can extract contacts, medications, appointments, and action items from messaging threads the same way it already does from email. The WIP is stashed but the architecture is stubbed out.
The email-agent pattern from CompanyOS is worth generalizing. The core idea - an always-on Edge Function that receives messages, classifies them, and takes action using AI - could work for any domain. A customer support agent, a scheduling assistant, a research aggregator. The sender authorization and multi-account Gmail pieces were the hard parts, and those are now solved generically. I want to see if the same Edge Function architecture can handle inbound from sources beyond email - webhooks, RSS feeds, form submissions - as a general-purpose AI intake pipeline.