Hundreds to low thousands of active work items per user.
Strong foundation. Explicit limits.
The data shape scales cleanly across users, but the current client still assumes a bounded solo workspace. Here is the honest line.
Atomic, attributed, idempotent transitions share one graph.
Code is built; Functions billing and Slack installation remain.
Needs workspace tenancy, archival, and production observability.
Firestore fits the first product wedge
Documents stay small, ownership is clear, and event history does not inflate the current-state record.
Goal updates never rewrite arrays of executable work.
Focus, Queue, Zones, and Done read one canonical state.
Audit and summaries grow independently from hot work state.
Earn complexity in four phases
Each phase removes a measured constraint before introducing the next operating model.
- 01NowProve the solo loop
Flutter + MCP + Slack around one user's execution graph.
- Deploy API
- Install Slack app
- Validate beta retention
- 02NextBound the hot data
Keep active views fast while execution history grows.
- Archive Done history
- Measure query cost
- Add retention controls
- 03TeamIntroduce workspace tenancy
Move ownership from one user to a permissioned shared workspace.
- Membership roles
- Invitations
- Workspace-scoped collections
- 04FleetOperate agent workloads
Make long-running and scheduled execution observable and durable.
- Due-job queue
- Cost telemetry
- Fleet-level run recovery
What fails first if usage jumps
Next: measure + tune per-view queriesNext: retention + archival policyFix: membership + RBACFix: due-job queue