diff --git a/persistent-memory.md b/persistent-memory.md
index 55dede2..dc71e94 100644
--- a/persistent-memory.md
+++ b/persistent-memory.md
@@ -124,7 +124,7 @@ _As of 2026-10-14 ~0005 PT. The newest subsection is first; older subsections ca
 - **SVOS: main `33a7077` (v0.0.13+2: kernel 0.0.13, interface 0.0.5 with briefs, postoffice 0.0.3, UI 0.0.18) since 2026-10-14 1108–1111; config_gen `33f001f4e2dbc7dc`, apps up 7.** ⚠ Lesson (paid 10-14): a manifest revision whose verbs change is HELD for the owner, and the app reads DOWN (`refused wrong-revision`) until Prime approves its card (15-min expiry). Roll such apps only while he is at the board, and the post-office bridge last (held, it carries no Miranda mail). The interface unit needs the drop-in `svos-interface.service.d/20-artifact-host.conf` (`SVOS_ARTIFACT_HOST=nh3-svos`), and the briefs mapping host must equal it. Before that, kernel 0.0.12 (`d95078c`, 0416) on top of v0.0.11 (452a592, U15 task seats slice 1). The `hermes` runtime is the only task-capable one (one-off `hermes -z`, `process = "python3"`, no `--yolo`: Prime's call); its old argv is in `instance.toml.pre-hermes-task`. Earlier: v0.0.11 is live on nh3-svos (schema 13, config_gen `5ade279d2fb2dd1c`, apps up 7) and nh3-dev (`/opt/svos/current → releases/452a592`; svos-terminal 0.0.4 runs from it). svos-dev accepted it. The task command is ruled with svos (Prime, 2026-10-14): infra-ops edits runtimes only at svos-dev's ask. `GET /tasks` as Prime is his acceptance check. Static-only interface releases since: UI 0.0.14 `89dad7a`, 0.0.15 `7f95e54` (the web build carried into 452a592). ⚠ Process→release map: nh3-svos kernel + local apps run `33a7077`; on nh3-dev svos-postoffice runs `33a7077`, svos-terminal `452a592`; svos-miranda runs `adc862e`, svos-agent still runs `dc241f8` (check `/proc/<pid>/maps` before deleting any release dir). Rollback material: nh3-svos `/var/lib/svos/backup/pre-452a592/` (schema-12 DB + config tar), `instance.toml.pre-452a592`, `instance.toml.pre-a171`; nh3-dev `terminal.toml.pre-452a592`. U13 history and the static-release chain: → `persistent-memory.d/2026-10-11-u13-cutover-executed.md`. Phase R (24 h soak, High Seat removal) is highseat-dev's. After the soak: nh3-svos releases `6c6abbe`, `a737a06`, `b588510`, `afab123`, `adc862e` and nh3-dev `/opt/svos/releases/afab123` can go once no process maps them.
 - **Decision seat = h2o-lightning-4b (production, Prime 1805 10-13: fix forward, no INC fallback).** The one open margin is the judge's personal-question reading (h2o 18 vs INC 6 on fleet/memory); albok-dev re-fits it forward in small batches on the live seat.
 - **albok note intake (Prime 1530 10-13):** gate 2 DONE (wing `personal/inbox`, `/srv/nemi/inbox` on nh3-dev, nemi token `01M4VX207PJ09ZSECASCSZPCFE`). Gate 1 (ruling 6) DONE 2026-10-15 0140: Prime's notes are `/home/lkraven/kb` = gitea `vh/VuongKB` (he syncs them with git, not Syncthing), so Nemi's copy is a fresh clone at `/srv/nemi/vault`, pulled hourly at :50 by the lkraven user timer `nemi-vault-pull` (`configs/nemi-vault/`). It holds 129 md outside dot-dirs; the untracked Muninn output (`main/`, `fiction/`) is not in it. **Walked 0143–0147 10-15:** 232 objects (129 notes + 103 children), 2 judged personal, 0 adult. The nemi token was re-minted again (`01M4ZBJG3DMRF9Q9XEVZ8Q20GH`, + personal/notes) and the old one revoked (thread `01M4VWV5FEF64EP71W60N6Q1N0`). Prime says the kb needs cleaning up (its last commit is 2026-04-16).
-- **Worldtree:** demo was deploying `beba08a4` (albok 4.7 the rest; Worldtree is a pure albok-service HTTP customer) at 2120 10-13. Retired-config strip: **demo DONE 2026-10-15 2339 on Prime's go** (instance-configs `2240110`: providers `graph_store` + `library`, plus the b193-retired `memory.*` keys; the boot shows 0 retired-key warnings, down from 7). **Since 2026-10-16 0823 all three run v1.0.0b194 (`daf587396f7a`; pinned via the Deploy-pinned workflow run 11136, from its May 446e5807 build).** Personal's retired blocks can come out on Prime's yes (the same deploy-wt-config path). ⚠ Pinned's new compose bind-mounts `/opt/worldtree-pinned/config`: the entrypoint SEEDED it from the image's config-defaults on first start, so pinned now HAS a host config dir that vh/worldtree-instance-configs does not yet track (pinned was out of scope while its config was baked in). Capture it. KB_PATH lingers only as an image ENV (worldtree-dev's Dockerfile). Keep defaults `library:` (thread `01M4WA58P2M001K1420NN72WFM`). Daily memory gate: 10-13 re-run `20261013T160414Z` PASS; worldtree-dev owns the tagger-latch fix. muninn-gate + mimir-inbox are STOPPED. **Albok unit 6 teardown (thread `01M4WAEFZEA1YY03ZR31AEHGTS`): steps 1-4 DONE 2026-10-16 0836.** 8 tars (3 worldtree-kb volumes, mimir-inbox staging, personal `state/ingestion`, muninn-gate conf, both compose dirs) were test-restored with per-file sha256 identical, and are now on `nh3-nas:/volume1/Backup/retired/albok-u6-corviduo-dev-20261016` (0700, re-verified there; local copy `/var/tmp/albok-u6`). **Deletion (step 5) is HELD for Prime's direct go**: albok-dev relayed "land all of u6", and a relayed go does not authorize a delete. The images muninn-gate:0.0.14 + mimir-inbox:0.0.1 were already gone at 0830, cause unknown. The in-process ingestion watcher ran until the b194 deploy (last heartbeat 0821:45). worldtree-dev cleared the ingestion subtree from the b194 source (0845). I removed personal .env's no-op `COMPOSE_PROFILES=muninn` (0846). The two 07-27 `.bak-muninn` files go in step 5 with no archive (the .env one holds live secrets). personal's providers.yaml `write_agents: ["muninn"]` goes with personal's retired-config strip (on Prime's yes). **albok-service 0.1.24 (sha256:75be71c1) LIVE since 0917 on nh3-albok, with personal/sealed configured (8 wings ready).** Harness (a) PASSED 0922: LOCK 0920:08-0920:38 (423s, search `locked`), live UNLOCK 0921:53 with no restart; the synthetic object was hard-deleted. The sealed wing stays MOUNTED. **Step 5 DONE 2026-10-16 1031 on Prime's direct go:** the 3 worldtree-kb volumes, personal `state/ingestion`, the muninn/mimir dirs and staging, and the 2 .bak files are all deleted. I also pruned the build cache (345.7MB) and removed /var/tmp/albok-u6; the NAS archive is the only copy. Found during the readback: **pinned's Matrix bridge had crash-looped since the 0822 b194 deploy** (no matrix.yaml, empty MATRIX tokens: pinned never had a bridge). I stopped it at 1033. The next pinned deploy recreates it; the durable fix is worldtree-dev's compose.
+- **Worldtree:** demo was deploying `beba08a4` (albok 4.7 the rest; Worldtree is a pure albok-service HTTP customer) at 2120 10-13. Retired-config strip: **demo DONE 2026-10-15 2339 on Prime's go** (instance-configs `2240110`: providers `graph_store` + `library`, plus the b193-retired `memory.*` keys; the boot shows 0 retired-key warnings, down from 7). **Since 2026-10-16 0823 all three run v1.0.0b194 (`daf587396f7a`; pinned via the Deploy-pinned workflow run 11136, from its May 446e5807 build).** **Personal's strip DONE 2026-10-16 1036 on Prime's yes** (instance-configs `4d1aae2`, the same patch as demo; boot shows 0 retired-key warnings, down from 7). **The Matrix bridge becomes profile-gated** in worldtree-dev's next release: `COMPOSE_PROFILES=matrix` is set on the demo and personal box .env (and in env.public, `5bc796a`); pinned sets NOTHING. Pinned's looping bridge stays `docker stop`ped until that release lands; after it, `docker rm worldtree-pinned-worldtree-matrix-1`. ⚠ Pinned's new compose bind-mounts `/opt/worldtree-pinned/config`: the entrypoint SEEDED it from the image's config-defaults on first start, so pinned now HAS a host config dir that vh/worldtree-instance-configs does not yet track (pinned was out of scope while its config was baked in). Capture it. KB_PATH lingers only as an image ENV (worldtree-dev's Dockerfile). Keep defaults `library:` (thread `01M4WA58P2M001K1420NN72WFM`). Daily memory gate: 10-13 re-run `20261013T160414Z` PASS; worldtree-dev owns the tagger-latch fix. muninn-gate + mimir-inbox are STOPPED. **Albok unit 6 teardown (thread `01M4WAEFZEA1YY03ZR31AEHGTS`): steps 1-4 DONE 2026-10-16 0836.** 8 tars (3 worldtree-kb volumes, mimir-inbox staging, personal `state/ingestion`, muninn-gate conf, both compose dirs) were test-restored with per-file sha256 identical, and are now on `nh3-nas:/volume1/Backup/retired/albok-u6-corviduo-dev-20261016` (0700, re-verified there; local copy `/var/tmp/albok-u6`). **Deletion (step 5) is HELD for Prime's direct go**: albok-dev relayed "land all of u6", and a relayed go does not authorize a delete. The images muninn-gate:0.0.14 + mimir-inbox:0.0.1 were already gone at 0830, cause unknown. The in-process ingestion watcher ran until the b194 deploy (last heartbeat 0821:45). worldtree-dev cleared the ingestion subtree from the b194 source (0845). I removed personal .env's no-op `COMPOSE_PROFILES=muninn` (0846). The two 07-27 `.bak-muninn` files go in step 5 with no archive (the .env one holds live secrets). personal's providers.yaml `write_agents: ["muninn"]` goes with personal's retired-config strip (on Prime's yes). **albok-service 0.1.24 (sha256:75be71c1) LIVE since 0917 on nh3-albok, with personal/sealed configured (8 wings ready).** Harness (a) PASSED 0922: LOCK 0920:08-0920:38 (423s, search `locked`), live UNLOCK 0921:53 with no restart; the synthetic object was hard-deleted. The sealed wing stays MOUNTED. **Step 5 DONE 2026-10-16 1031 on Prime's direct go:** the 3 worldtree-kb volumes, personal `state/ingestion`, the muninn/mimir dirs and staging, and the 2 .bak files are all deleted. I also pruned the build cache (345.7MB) and removed /var/tmp/albok-u6; the NAS archive is the only copy. Found during the readback: **pinned's Matrix bridge had crash-looped since the 0822 b194 deploy** (no matrix.yaml, empty MATRIX tokens: pinned never had a bridge). I stopped it at 1033. The next pinned deploy recreates it; the durable fix is worldtree-dev's compose.
 - **satellite-1:** its own key is authorized for infra-ops on esh-nas only (`playbooks/files/infra-ops-satellite-keys`). Waiting on Prime's login test from the satellite and its machine name (the key's comment came through as bare `infra-ops@`).
 - **fv-ml1: hard hang 10-11 ~0005, self-reset, no record** (pstore/ERST registered and empty, so not a kernel panic). Evidence capture staged: kernel console on ttyS1 from its next boot + nh3-dev user unit `fv-ml1-sol-logger` (`journalctl --user -u fv-ml1-sol-logger`). ⚠ **HOLD** `zroot/ROOT/debian@pre-patch-20261008` (do not destroy) until the cause is known or a clean week passes after the last crash.
 - **albok `.browse/` share:** the Linux-client withdrawal test passed (10-09); vh holds every albok read group; Prime's Mac keys on vh stay full access (Prime 10-11). Owed: the macOS run, staged as vh in `~vh/albok-browse-test/` on nh3-albok, waits on Prime pasting the one-liner (`scripts/oneoff/albok-browse-withdrawal/README.md`); afterwards read `results/`, report to albok-dev, remove the replica.