diff --git a/docs/design/2026-06-05-three-tier-projects-collections.md b/docs/design/2026-06-05-three-tier-projects-collections.md
index e4d0fce..b71d70a 100644
--- a/docs/design/2026-06-05-three-tier-projects-collections.md
+++ b/docs/design/2026-06-05-three-tier-projects-collections.md
@@ -10,8 +10,18 @@
 > semantics, the `type`/`initial_state`/`unreviewed` machinery) carry over
 > unchanged, re-homed onto the collection. Rationale and the decisions behind
 > this live in [`multi-project.md`](./multi-project.md) and session 0072.
-> Target release: folded into the not-yet-shipped §22 work (Plan B + M3-frontend),
-> a pre-1.0 minor carrying breaking changes with upgrade steps (§20.2).
+>
+> ⚠️ **CORRECTION (session 0072, after code re-check).** Parts of §0/§A.3/§E
+> were drafted on a stale-memory premise that "Plan B (migration 028) and
+> M3-frontend have not shipped." **That is false.** As of v0.39.0 the entire
+> **two-tier** model is shipped to `main`: migration 028 already rebuilt the
+> slug PK to `(project_id, slug)`; v0.35.0 shipped `/p/<project>/` routing and
+> the live `/p/<project>/e/<slug>` URLs; v0.37.0/0.38.0 shipped per-project
+> read + propose. Inserting the third tier is therefore an **evolution of a
+> shipped system**, not a revision of unshipped designs. The migration strategy
+> (Part E) is **pending re-decision** with correct facts; the structural model
+> (Parts A–D) is unaffected. Target release: a further pre-1.0 minor with
+> breaking changes + upgrade steps (§20.2).
 
 ---
 
@@ -29,9 +39,11 @@ the original §22 said about a corpus (type, slug namespace, catalog, philosophy
 landing state, review flag, membership) moves down one level to the collection;
 the deployment level is unchanged.
 
-The timing is favorable: the breaking slug-PK rebuild (Plan B / migration 028)
-and the public `/p/<id>/` routing (M3-frontend) **have not shipped**, so this is
-a revision of in-flight *designs*, not a rework of shipped surfaces (§7).
+⚠️ The two-tier model is **already shipped** (v0.39.0): migration 028 rebuilt
+the slug PK to `(project_id, slug)`, and `/p/<project>/e/<slug>` URLs are live
+(v0.35.0). So inserting the third tier evolves a shipped system — see the
+corrected Part E for the real migration cost (a new migration 029 + a breaking
+URL change with 308s), pending re-decision.
 
 ---
 
@@ -166,10 +178,12 @@ collections** in that project the visitor can see. Conveniences:
 - `/` redirects to the sole visible project when there is exactly one (the N=1
   case, §A.6).
 
-Backcompat is light: no `/p/<id>/` URL ever shipped (M3-frontend is unmerged).
-The only live legacy URLs are the pre-multi-project `/rfc/<slug>` /
-`/proposals/<n>`, which **308-redirect** to the migration's default project →
-default collection (§A.6).
+⚠️ **Backcompat is heavier than first drafted.** `/p/<project>/e/<slug>` URLs
+**are live** (v0.35.0), so adding the `/c/<collection>/` segment is a breaking
+URL change: the shipped `/p/<project>/e/<slug>` must **308-redirect** to
+`/p/<project>/c/<default-collection>/e/<slug>`, alongside the pre-multi-project
+`/rfc/<slug>` → `/p/<default-project>/c/<default-collection>/…` redirect. Both
+are handled in the migration (§A.6 / Part E).
 
 ---
 
@@ -465,11 +479,21 @@ Applied in place when §22 is rewritten; listed here as the change surface.
 
 # Part E — Revised slicing plan (the roadmap re-slot)
 
-Strategy (session 0072 decision): **fold the third tier into the not-yet-shipped
-work** rather than ship two-tier and migrate again. M1, M2, and M3-backend
-Plan A are additive and already merged (v0.39.0); they keep running. The tier
-goes in at the **first breaking migration (Plan B / 028)** and the **first
-public routing (M3-frontend)**, before either ships.
+> ⚠️ **PENDING RE-DECISION (session 0072).** The strategy below assumed Plan B
+> and M3-frontend were unshipped. They are shipped (v0.35.0–0.39.0). The "fold
+> into not-yet-shipped work" framing is void; the actual work is a **new
+> migration 029** that evolves the shipped two-tier schema to three tiers, plus
+> a **breaking `/p/<project>/e/<slug>` → `/p/<project>/c/<collection>/e/<slug>`
+> URL change with 308s**. The two live mapping options (relabel today's
+> project → collection + insert a group tier above, vs. add a collection
+> sub-grain beneath today's project) are being put back to the operator. The
+> text below is retained only as the structural target, not the sequencing.
+
+Strategy (ORIGINAL, premise now false): fold the third tier into the
+not-yet-shipped work rather than ship two-tier and migrate again. M1, M2, and
+M3-backend Plan A are additive and already merged (v0.39.0); they keep running.
+The tier goes in at the **first breaking migration (Plan B / 028)** and the
+**first public routing (M3-frontend)**, before either ships.
 
 - **Landed, unchanged (v0.39.0):** M1 (additive `project_id` spine, mig 026),
   M2 (authz resolver), M3-backend Plan A (registry mirror, APIs, propose /