docs(migration): add Claude review-lane verification notes

- separate 'present in recovered env' from 'Hermes-supported' (Codex nuance)
- flag Telegram token reuse as a getUpdates collision risk vs Mevy
- first .env = provider keys only, Telegram deferred; Vaultwarden durable home

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

docs/MIGRATION-MANIFEST.md

@@ -78,3 +78,34 @@ migration card — when Hermes gains the capability, the key becomes actionable.
 | Boot now | ~5 | being deployed on OSA |
 | Useful soon | ~10 | pending Hermes config mapping |
 | Old Clawdie-specific | ~89 | roadmap — no action yet |
+
+## Verification notes (Claude — domedog review lane)
+
+Reviewed against the recovered env and standing fleet rules. Two corrections to
+apply before building `/home/clawdie/.hermes/.env`:
+
+1. **Separate "present" from "supported."** Bucket membership currently mixes two
+   axes: *Hermes can support this key* vs. *this key actually exists in the
+   recovered 104-key env*. Codex confirms several Bucket-2 keys (`ANTHROPIC_API_KEY`,
+   `DEEPSEEK_API_KEY`, `GOOGLE_API_KEY`, `GEMINI_API_KEY`, `TELEGRAM_ADMIN_IDS`,
+   `TELEGRAM_OPS_CHAT_ID`) were **absent** from the recovered env — so they are
+   roadmap items (Bucket-3 behavior), not migration inputs. **You can't copy a key
+   that isn't there.** Treat the recovered env as the migration input set; treat the
+   bucket table as the capability roadmap. Only Bucket-1 keys confirmed present
+   migrate now.
+2. **Telegram token reuse is a collision hazard, not a copy.** Bucket 1 marks
+   `TELEGRAM_BOT_TOKEN → (same) → ready`, but Mevy already runs a Telegram bot on
+   `osa`, and the handoff rule is *do not reuse any existing token* (one token per
+   service). Two consumers polling `getUpdates` on one token steal each other's
+   updates. **Before any reuse:** confirm the old Clawdie bot is dead, or mint a
+   fresh bot for hermes-osa. Do not assume "same" is safe.
+
+**First `.env` build (Telegram-off validation):** provider keys only
+(`OPENROUTER_API_KEY`, `OPENAI_API_KEY`, `ZAI_API_KEY`) — defer all Telegram keys
+until after a clean CLI proof. Durable home for these values is **Vaultwarden**
+(`vault.smilepowered.org`); the backup file stays sealed as the migration source.
+The built `.env` is local to `osa` and must never flow through any repo.
+
+_Review lane: Claude (domedog) verifies migration/handoff steps against standing
+rules and confirms Codex's osa results when reported — closing the loop through
+verification. See [`HOST-MATRIX.md`](HOST-MATRIX.md) §1._