Monolith Ceiling

Gmail Mission Control worker is 2,400+ lines in a single file. No tests, no modular structure, 15+ endpoints interwoven. Adding any feature requires editing the whole file and redeploying. If one endpoint breaks, the entire tool goes down. The Chrome Extension MVP adds new endpoints, which means editing that 2,400-line file again.

This is a familiar pattern from system growth: AI builds fast, monolithic first, then complexity accumulates. The worker has reached the point where it's a team tool — Chrome extension deployed, Bonsai CF account, multiple team members accessing it — but uses a personal-scale codebase. The cost of that choice shows up immediately at team transition: deploying to production risks regressions in unrelated endpoints; onboarding new features requires deep understanding of the whole system; testing a new endpoint requires running everything.

The root cause: team-scale complexity wasn't anticipated when designing the worker. If it had been, the design would have split into modular request handlers, unit tests, and staged deployments from the start.

Mission Control was built on Mike's personal Cloudflare account. When it shipped and the team needed to use it, it had to be migrated cross-account. Same issue with Front credentials (found in backup instead of standard location) and Google OAuth (required fresh GCP project creation instead of using the existing Bonsai project).

This pattern repeats. Infrastructure decisions made at day-1 — which cloud account, which OAuth app, which credential storage, which monitoring setup — cascade through the entire tool lifecycle. Bad early choices compound hours during team scaling. Right now, each tool rediscovers these decisions independently. The next tool will do the same.

The fix: a "Bonsai Cloud Foundation" playbook in the execution templates, documenting the standardized infrastructure setup before any team tool is built. Standardize account, auth app, secret storage, and monitoring once — so future tools don't repeat the debt.

Front comments were imported via subject-line matching instead of Message-ID matching, because the Front API doesn't expose Message-ID headers. This introduces false matches: 12% of subjects under 15 characters have high collision risk. Old comments from 2023 can attach to March 2026 emails with the same subject. The fix was parked as "If Needed" — only build if team complains.

This is a classic sign of working backwards from constraints. The ideal architecture (Message-ID-based linking) wasn't available, so the implementation settled for a weaker signal (subject line). The workaround works 88% of the time. But it breaks silently in edge cases, and "wait for someone to complain" isn't a quality gate — it's a support tax deferred.

The difference between these two isn't the workaround — it's whether the limitation is documented. A "Known Limitations" section in tool runbooks makes edge cases visible before they become support overhead.