diff --git a/docs/bulletproof-containers.md b/docs/bulletproof-containers.md
index e8241c9c..737aca90 100644
--- a/docs/bulletproof-containers.md
+++ b/docs/bulletproof-containers.md
@@ -1,15 +1,19 @@
-# Bulletproof Containers for Beta
+# Bulletproof Containers
 
-**Status**: plan agreed 2026-04-22, implementation started.
-**Target**: zero-manual-intervention container lifecycle for the beta launch. A user installs, uninstalls, reboots, updates, or loses power — every combination must leave the node in a known-good state without SSH.
-**Project memory**: `~/.claude/projects/-home-archipelago-Projects-archy/memory/project_reconcile_architecture.md`
-**Failure log**: `~/.claude/projects/-home-archipelago-Projects-archy/memory/feedback_container_lifecycle_failure_modes.md`
+**Status**: historical design record — the plan below (agreed 2026-04-22) has
+been implemented. For the current description of how the lifecycle works, read
+[Container lifecycle](container-lifecycle.md); this document is kept for the
+incident history and the reasoning that produced the design.
+
+**Target**: zero-manual-intervention container lifecycle. A user installs,
+uninstalls, reboots, updates, or loses power — every combination must leave the
+node in a known-good state without SSH.
 
 ---
 
 ## Why we're doing this
 
-The v1.7.38 and v1.7.39 rollouts on 2026-04-22 exposed a cluster of container-lifecycle failures that required manual SSH recovery on every affected node (.116, .198, .228, .253). If a user had been on those nodes, they'd have been stuck with "can't reach" or 500 errors and no path forward. We can't ship beta with this class of failure on the table.
+The v1.7.38 and v1.7.39 rollouts on 2026-04-22 exposed a cluster of container-lifecycle failures that required manual SSH recovery on every affected node. If a user had been on those nodes, they'd have been stuck with "can't reach" or 500 errors and no path forward. We can't ship beta with this class of failure on the table.
 
 The pattern under every failure: **the canonical source of truth had the right answer, but derived state drifted away from it and nothing noticed or fixed it.**
 
@@ -297,18 +301,3 @@ Ordered by likelihood × severity:
 ### Tor
 - [rend-spec-v3](https://github.com/torproject/torspec/blob/main/rend-spec-v3.txt) — descriptor lifetime + republish cadence
 - [stem](https://stem.torproject.org/) — Python Tor controller for `HS_DESC UPLOADED` waits
-
----
-
-## To resume
-
-1. Read project memory: `~/.claude/projects/-home-archipelago-Projects-archy/memory/project_reconcile_architecture.md`
-2. Read failure-mode memory: `~/.claude/projects/-home-archipelago-Projects-archy/memory/feedback_container_lifecycle_failure_modes.md`
-3. Check task list for current release (should start with v1.7.41)
-4. Current state on fleet as of 2026-04-22:
-   - All 4 registry mirrors synced to v1.7.40-alpha
-   - .116, .198, .228, .253 healed manually via `systemd-run chmod 755 /opt/archipelago/web-ui`
-   - .228 still has stale `bitcoin.conf` rpcauth (regenerated during triage; will drift again until v1.7.43)
-   - .228 UI companions (archy-bitcoin-ui, archy-lnd-ui) keep vanishing (Quadlet migration in v1.7.45+ fixes)
-   - .160 Gitea required `podman system renumber` recovery (v1.7.44 automates this)
-5. Implementation is in progress on `main` branch — next edit is `core/archipelago/src/update.rs` for v1.7.41.