Scaling Tribalism

Gmail Mission Control shipped with five major features — archive, snooze, VIP, comments, admin toggle — plus sophisticated multi-user systems. Mike's reaction: "billion-dollar SaaS → one-person-with-AI gap has collapsed for 90% of use cases." But the hidden assumption is that feature parity equals team readiness.

Once Dustin or Sarah uses Mission Control daily, do they know how to configure the VIP list? Extend templates? Add new team members to shared inboxes? The artifact is polished — the knowledge of how to operate it is tribal (Kai's memory). Gmail Mission Control works great single-operator. Team scale requires something different: admin config guides, user onboarding runbooks, decision authority documentation (who owns VIP list? who approves new features?).

That IS a team-readiness blocker, not an architectural one. The tool is ready. The team isn't — and that gap isn't tracked anywhere.

Evaluating Improvements #23 and #21 required scanning memory files from March 19–20, collecting evidence, and synthesizing. Both took 5+ minutes manually. With 25 improvements and 100+ weeks of history, manual evaluation becomes intractable. The improvement backlog grows at 1–2 entries per sleep session. At this rate, evaluations get deferred, old improvements never get reevaluated, and status drifts stale.

The current evaluation system is: scan logs manually, assess subjectively whether sessions referenced the improvement, draw a conclusion from low sample size. That's flying blind. Scaling requires systematic logging — sessions tagging memory files when they intentionally use an improvement — followed by automated weekly aggregation counting those references.

Without measurement, we don't know which improvements stick and which are cargo cult. The improvement log is artifact-centric ("we built X"), not impact-centric ("did X change behavior?").

Improvement #19 (token validator) deployed the same night it was surfaced. Improvement #24 (playbook discovery) has been in design phase for four days. Why does one ship fast and the other stall?

#19 was solo-executable — write script, integrate Phase 2, done. #24 requires coordination — updating SESSION-CHECKPOINT, which Mike reads, which sessions reference. Careful rollout needed. Design-phase ideas that touch shared artifacts (SESSION-CHECKPOINT, open-loops.md, MEMORY.md) carry a coordination tax that solo improvements don't. Sleep protocol has plausible authority over memory files and personal scripts. Limited authority over session-facing artifacts and client decisions.

Distinguishing execution authority in the improvement queue ("solo", "Mike-coordinated", "team-aligned") would make this latency visible and explain why some ideas stay pending indefinitely.

Mission Control v0.8 ships a beautiful UI — admin toggle, VIP system, Gaia. Mike says "better than Front." But operational reality: OAuth login not implemented (URL params only), CORS wide open, no data backup strategy, Slack alerting reliability untested, email rendering has edge cases. User experience feels complete. Operations are rough.

This isn't a problem per se — ship-vs-quality is healthy tension. But it's worth naming because it explains why tools feel "done" when demo-ready. Mission Control is user-feature polished (Dustin sees comments, loves it) but ops-immature (no persistent backups, no secure auth, no SLA monitoring).

Before expanding to broader team use: ops readiness audit needed. Auth system, CORS lockdown, data backup, Slack alerting tested, admin runbook documented. Mike mentioned deploying to the team soon — this checklist should inform that decision.