diff --git a/agent-identity-bootstrap.md b/agent-identity-bootstrap.md
index a85624f..4f72ac6 100644
--- a/agent-identity-bootstrap.md
+++ b/agent-identity-bootstrap.md
@@ -54,10 +54,11 @@
 
 ### Key principles
 1. **Cloudron is the identity root.** One invite = identity everywhere (SSO auto-provisions).
-2. **Agents own their credentials.** Each agent generates its own API keys after SSO login, stores them in Bitwarden. No shared `~/.creds/*.env` files.
-3. **Agents are fully independent.** Each agent is a separate Cloudron user with its own SSO sessions, API keys, and Bitwarden collection. They do not share sessions or credentials.
-4. **`coo` Linux account is the orchestration layer** — where humans (Charles/AJ) launch and interact with agent sessions. Not where agents "live" — agents live as Cloudron identities.
-5. **No key material on disk.** All SSH private keys, passwords, API keys live in Bitwarden. SSH via BW SSH agent. (Aligns with SecOps note: only iPad enclave key + Bitwarden key.)
+2. **Bitwarden is the ONLY credential store.** The only secret that lives on disk is the BW access info itself (client_id, client_secret, master password). Everything else — Discourse API keys, Redmine keys, Gitea tokens, SSH private keys, TOTP secrets, app credentials — lives in Bitwarden exclusively. No `~/.creds/*.env` files. No key material on disk.
+3. **Agents own their credentials.** Each agent generates its own API keys after SSO login, stores them in Bitwarden. Agents are fully independent — each is a separate Cloudron user with its own SSO sessions, API keys, and Bitwarden collection.
+4. **The `coo` Linux account is the orchestration layer** — where humans (Charles/AJ) launch and interact with agent sessions. Not where agents "live" — agents live as Cloudron identities.
+5. **SSH via BW SSH agent.** No private keys on disk. Aligns with SecOps target: only iPad enclave key + Bitwarden key.
+6. **reachableceo's personal Crush session stays as-is** — Charles's personal assistant for reviewing tickets, personal projects, and transitioning work to the new agents on his behalf. The TSGCOO account + new agents are an additional layer, not a replacement.
 
 ---
 
@@ -102,13 +103,13 @@ Bitwarden org: "TSYS Group AI Agents"
     └── ...
 ```
 
-### Migration path (3 stages)
+### Migration path (2 stages)
 
-**Stage 1 — Parallel operation (Q3 start).** New agent identities use BW-sourced credentials. The existing `~/.creds/` files remain for `reachableceo`'s direct use. Both work side by side. No breakage.
+**Stage 1 — Agent provisioning.** New agent identities are created in Cloudron, generate their own API keys via SSO, and store everything in Bitwarden. They source credentials exclusively via `bw-run.sh`. The `~/.creds/` files are NOT used by agents — only by `reachableceo`'s personal session.
 
-**Stage 2 — Agent adoption.** Agent-facing tooling (CLI wrappers, Crush configs) source from BW. The `~/.creds/` files are only used by Charles directly. Agents never touch `~/.creds/`.
+**Stage 2 — Full migration (Redmine #440, Aug 19).** `reachableceo`'s `~/.creds/` files are migrated into Bitwarden too. After this, the ONLY secret on disk is the BW access info (client_id/client_secret/master password). All CLI invocations use `bw-run.sh`. The `~/.creds/` directory is deleted.
 
-**Stage 3 — Full migration.** `~/.creds/` files are deleted. Charles uses Bitwarden directly too. All credential access is through BW. (Aligns with Vault migration in P5 — Vault can later wrap BW or replace it for machine secrets.)
+**Principle: the only thing outside Bitwarden is Bitwarden's own access information.** Everything else — API keys, passwords, SSH keys, TOTP secrets — lives in BW exclusively.
 
 ### The credential sourcing layer
 
@@ -368,15 +369,19 @@ for agent in manifest:
 
 ## 8. What I Need From You to Start
 
-1. **Create the `coo` Linux account** on this workstation.
-2. **Create the Bitwarden account** for AI agents; give me `client_id` + `client_secret`.
-3. **Generate Cloudron invite links** for the 3 Q3 agents (vp-techops, vp-secops, vp-techcompliance). Put in a manifest file:
-   ```
-   vp-techops | VP TechOps | https://tsys-cloudron.knel.net/invitation/<token> | Q3
-   vp-secops | VP SecOps | https://tsys-cloudron.knel.net/invitation/<token> | Q3
-   vp-techcompliance | VP TechCompliance | https://tsys-cloudron.knel.net/invitation/<token> | Q3
-   ```
-4. **Resolve the Discourse admin blocker** — create the VP SecOps category via web UI (or give me an admin API key).
-5. *(Optional)* Generate invites for Q4 agents too (coo, svp-knel, svp-tctc) — Phase 1 only, no system access until Q4.
+### Done from this session (reachableceo — Charles's personal assistant)
+- [x] Playwright automation repo built and pushed (`TSYSGroupCorporate/agent-identity-provisioning`)
+- [x] `bw-run.sh` credential sourcing layer built and pushed (`TSYSGroupAIOS/scripts/bw-run.sh`)
+- [x] Redmine tickets filed (#440 BW migration, #441 taxonomy audit, #442 provisioning)
+- [ ] **Ticket transitions** — once agents are provisioned, I (reachableceo session) will transition tickets to the new agent identities on Charles's behalf
 
-Once I have items 1-3, I build the Playwright automation and execute Phases 1-2.
+### To be done from the TSGCOO session (the new operational layer)
+1. **TSGCOO Linux account** is created. Set up the Crush session there.
+2. **BW access info** — place ONLY the BW client_id/client_secret/master password in the TSGCOO account (e.g., `~/.config/bw/env`). This is the ONLY secret on disk. Everything else comes from BW at runtime.
+3. **Discourse admin access** — set `DISCOURSE_API_USERNAME=system` in the TSGCOO session's environment (sourced from BW, not a static file). The `system` user has admin privileges for category creation.
+4. **Cloudron invites** — generate invite links for vp-techops, vp-secops, vp-techcompliance. Put them in `agents.yaml`.
+5. **Run the provisioning** — `docker compose up --build` from the `agent-identity-provisioning` repo.
+6. **VP SecOps category** — the vp-techops agent (or the TSGCOO session) creates the Discourse VP SecOps category using the `system` admin credentials.
+
+### reachableceo session role (unchanged)
+The reachableceo Crush session continues as Charles's personal assistant — reviewing tickets, working personal projects, and handling the transition of work to the new agents. It is not replaced by the TSGCOO layer; it operates alongside it.