“Project authorization” in 0dai is not one thing. It is the combination of account auth, repository binding, activation state, and periodic project heartbeats. If those concepts are mixed together, both users and operators get confusing signals.
The Four Layers
- Account auth proves which user is in control.
- Activation proves the user can actually use the product path.
- Project bind connects one repository to that account.
- Heartbeat refreshes project health, drift, and runtime metadata.
Why Teams Confuse Them
The browser can be authenticated while the CLI is not. A repository can be initialized without being bound. A project can be bound without a fresh heartbeat. All three states feel like “I already signed in,” but operationally they are different.
How to Debug a Broken Project Surface
- Check
0dai auth statusfirst. - Confirm the dashboard shows the expected
project_id. - Run
0dai syncif drift or generated configs look stale. - Send a fresh heartbeat after init/sync so server-side project status updates.
What Operators Should Store
Store secrets and billing at the account level. Store repo identity and health at the project level. Do not try to move local machine auth through project sync. That keeps project state shareable and account state isolated.
Why This Matters for Launch
A product that reports the wrong project health or hides the next step looks broken even when the core engine works. Clear project authorization surfaces are not a docs problem. They are a conversion and trust problem.