diff --git a/docs/superpowers/specs/2026-04-05-auth-overhaul-design.md b/docs/superpowers/specs/2026-04-05-auth-overhaul-design.md
index 71d5f31..dbaf86c 100644
--- a/docs/superpowers/specs/2026-04-05-auth-overhaul-design.md
+++ b/docs/superpowers/specs/2026-04-05-auth-overhaul-design.md
@@ -347,7 +347,7 @@ These files are removed entirely:
 
 Remove the `PasswordEncoder` bean from `SecurityConfig.java`.
 
-Database migrations V001 (users table), V002 (roles/permissions tables), V003 (default role seed) should be replaced with a single migration that drops these tables if they contain no production data, or left as-is and simply unused if data migration is a concern.
+Database migrations V001 (users table), V002 (roles/permissions tables), V003 (default role seed) are deleted entirely — greenfield, no production data. Replace with clean migrations containing only the tables actually needed.
 
 #### DELETE: Ed25519 key configuration
 
@@ -609,7 +609,7 @@ var key = apiKeyService.generate();
 // Return plaintext to caller (shown once, never stored in plaintext)
 ```
 
-The `bootstrap_token` column on `EnvironmentEntity` becomes the plaintext API key that's injected into the server and agent containers. In a future migration, rename this column to `api_key_ref` or similar. For now, keep the column and populate it with the generated key.
+The `bootstrap_token` column on `EnvironmentEntity` is removed. API keys are managed exclusively through the `api_keys` table. The plaintext is returned once at creation time and injected into server/agent containers.
 
 #### REWRITE: Frontend auth
 
@@ -715,25 +715,20 @@ The bootstrap script already creates the API resource and roles. Verify that the
 
 ---
 
-## Migration Strategy
+## Greenfield Approach
+
+This is a new development — no production data exists. All database schemas, migrations, and code are written fresh without backward-compatibility constraints.
 
 ### Database
 
-1. **New migration V011**: Create `api_keys` table.
-2. **New migration V012**: (Optional) Drop `users`, `roles`, `permissions`, `user_roles`, `role_permissions` tables. Or leave them unused — no runtime cost, avoids risk.
-3. The `bootstrap_token` column on `environments` stays for now. Its value becomes the API key plaintext (stored temporarily for injection into containers).
+- **Remove** migrations V001 (users), V002 (roles/permissions), V003 (default roles) entirely. These tables are not needed — users and roles live in Logto.
+- **Replace** with a single clean migration that creates only the tables needed: `tenants`, `environments`, `api_keys`, `licenses`, `apps`, `deployments`, `audit_log`.
+- The `bootstrap_token` column on `environments` is renamed to `api_key_plaintext` or removed in favor of the `api_keys` table exclusively.
 
-### Backward Compatibility
+### Implementation Order
 
-- **Agent**: No breaking change. `CAMELEER_AUTH_TOKEN` continues to work.
-- **Server**: No breaking change when `CAMELEER_OIDC_ISSUER_URI` is unset.
-- **SaaS frontend**: Breaking change — org role names change. Deployed atomically with backend.
-- **Self-hosted**: No impact. They don't set `CAMELEER_OIDC_ISSUER_URI`, server behaves as before.
-
-### Rollout Order
-
-1. **Phase 1**: Update cameleer3-server (add OIDC resource server support). Deploy. Backward compatible.
-2. **Phase 2**: Update cameleer-saas backend (delete custom JWT stack, add API key management, rewrite security config). Deploy with frontend changes atomically.
+1. **Phase 1**: Update cameleer3-server (add OIDC resource server support). Deploy.
+2. **Phase 2**: Rewrite cameleer-saas backend (clean security config, API key management, Logto-only auth). Deploy with frontend changes atomically.
 3. **Phase 3**: Update bootstrap script (set OIDC env vars on server, stop reading Logto DB directly).
 
 ---