From 3bc7c6986f424f46475e866e305d8942984e8e32 Mon Sep 17 00:00:00 2001 From: Vuong Hoang Date: Sat, 5 Sep 2026 07:20:11 -0700 Subject: [PATCH] memory: svos cutover verified; record the cutover-destroys-the-old-key foot-gun MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cutover landed clean — a 201 define rather than 409/PATCH, which is what proves the new identity is actually in use. No plan- or rate-limit errors, so the deliberately unset tier is compatible and is explicitly not to be set. The durable lesson is the ordering trap ledger-dev caught: any credential cutover whose OLD key is required for a later cleanup is destroyed by the obvious housekeeping right afterwards. Re-vaulting the post-cutover env.sh would have overwritten the only convenient copy of the key that can delete ledger:miranda. Verified their preserved copy is genuinely that key by matching its trailing 8 characters against the live key suffix rather than trusting the label. Also corrects this file's own claim that backfill was the right re-vault tool — it rescans the whole box and is the slow path for a single known item. --- persistent-memory.md | 26 ++++++++++++++++++++++++-- 1 file changed, 24 insertions(+), 2 deletions(-) diff --git a/persistent-memory.md b/persistent-memory.md index e76e957..a0afecb 100644 --- a/persistent-memory.md +++ b/persistent-memory.md @@ -201,12 +201,34 @@ below is a live commitment or a known-open risk._ delivery is confirmed. **The cutover itself — pasting the value into env.sh, flipping `worldtree.user_id` from `ledger` to `svos`, registering `svos:miranda`, restarting the service — is WITH THE OPERATOR**, not with me; - they will not do it off a peer message. They will `secret backfill` afterwards - rather than asking for a manual re-put. **OPERATOR RULING 2026-09-05: + they will not do it off a peer message. **CUTOVER DONE + VERIFIED 2026-09-05**: + `POST /agents/define` returned **201, not 409** — the load-bearing signal that + they are genuinely on the new identity rather than silently still on the old + one — then clean session create, turn, bifrost handshake and tool-call. **No + plan- or rate-limit errors, so the unset tier is compatible and is NOT to be + set** (they asked explicitly; it stays a watch item to fix on report, never by + guess). Incidentally confirmed the bifrost allowlist really is per-deployment + (host:port), not per-consumer — Worldtree reached back to their untouched + endpoint under the new consumer_id. `env.sh` re-vaulted, sha 8a225c002072. + ⚠ **`secret backfill` was the WRONG tool for one known item** — it rescans every + `~/development/*/{env.sh,.env}` and had not reached svos after three minutes; + targeted `put` is the fast path, backfill is for catching drift across the box. + **OPERATOR RULING 2026-09-05: worldtree-dev owns code only, no ops — key material is infra-ops's.** The global `~/.claude/CLAUDE.md` line routing "Heimdall scopes (Worldtree auth) → worldtree-dev" was corrected in place the same day on operator instruction. +- ⚠ **FOOT-GUN, generalises past this rename: a credential cutover whose OLD key + is required for a later cleanup is destroyed by the natural housekeeping motion + right after cutover.** Re-vaulting the post-cutover `env.sh` would have + overwritten the last convenient copy of the old `ledger` key value — the only + credential that can ever delete `ledger:miranda`. ledger-dev caught it and + preserved the value first at + `nh3-dev/development/svos/worldtree-api-key-ledger-legacy` (sha d44c2c1a651b); + their step 8 ends by deleting that item. **I verified it is genuinely the live + key** rather than trusting the label: its last 8 chars are `e68a5170`, matching + the `ledger` key's suffix (key_id b38932f5). + - **Original constraints on that mint** (recorded because the deletion ordering is a permanent trap, not a one-time step): string `svos` verbatim (WT tier 3 admits only `^[a-z][a-z0-9-]{2,63}$`, INV-181-15);