diff --git a/8-Roadmap.md b/8-Roadmap.md
index a87d2f3..3794e3f 100644
--- a/8-Roadmap.md
+++ b/8-Roadmap.md
@@ -225,6 +225,52 @@ guards regression-protected · `CB-521` the AMQP contract test runnable both loc
 > `invalid_request: missing field <x>`. After any restart onto a jar carrying an adapter change,
 > verify with a real `bridge_spawn`, not with `/healthz`.
 
+## Release 1.1 — the single-host close-out (open)
+
+`v1.0.0` was tagged **2026-08-10**, message *"One leader, one host, complete"*. Since then **175
+commits** have landed on `main` with **no tag**. So the stage tables above are true and still leave
+the obvious question unanswered: what is actually left before the single-host story can be called
+finished?
+
+Gitea milestone: **`1.1 — single-host close-out`**. The admission rule is one sentence — **if it
+would still be broken with exactly one host, it belongs in 1.1.** By that rule, of everything open
+today, only **CB-308** (issue #6) is release 2.
+
+```mermaid
+flowchart LR
+    subgraph r1["release 1.1 — one bridged per host"]
+        sup["supervision<br/>CB-594"]
+        bugs["single-host bugs<br/>CB-590 · CB-582"]
+        dur["durability claim<br/>CB-527 · CB-528"]
+        sec["credential scope<br/>CB-593 · CB-596"]
+        docs["catalogue debt<br/>CB-595"]
+    end
+    subgraph r2["release 2 — one centre, many hosts"]
+        fed["CB-308 federation"]
+    end
+    r1 --> r2
+    classDef done fill:#2f855a,stroke:#22543d,color:#ffffff;
+    classDef todo fill:#b7791f,stroke:#7b341e,color:#ffffff;
+    class sup,bugs,dur,sec,docs todo
+    class fed todo
+```
+
+*Figure: the 1.1 milestone by theme. Everything on the left is single-host work; only CB-308 sits on
+the right.*
+
+| Theme | Tickets | The point |
+|---|---|---|
+| **Supervision** | CB-594 (#80) | The launchd unit ships in `deploy/` and has **never been installed**, and launchd does not source a login shell — so a supervised daemon gets no `WORKER_GITEA_TOKEN` and no `AI_GATEWAY_TOKEN`. Today the operator picks supervision *or* a working fleet. |
+| **Single-host bugs** | CB-590 (#75) · CB-582 (#61) | Two nudge schedules can inject into one lead pane at once. `bridge_ask` has a ~55s window against a lead that polls every few minutes, so a shipped tool does not work in the mode the charter tells leads to prefer. |
+| **Durability** | CB-527 (#10) · CB-528 (#11) | Both are marked *"a v1.0.x as-built gap, independent of federation"* in their own text. No `basicQos`, so the backlog lives in JVM heap rather than on the broker; no publisher confirms, so a publish to a missing queue is a silent black hole. **The wiki currently promises an operator more durability than the code delivers** — fix it or change the sentence. |
+| **Credential scope** | CB-593 (#79) · CB-596 (#82) | CB-592 blocks one credential name; the member's pane login shell re-sources about thirty. A second forge token is among the untouched ones. |
+| **Catalogue debt** | CB-595 (#81) | ~14 shipped operator-facing tickets have no Features entry. Three of them changed what a **config key means** (`weight:`, `maxLoad:`, the lead pin), and `bridged.yaml` is gitignored — so [Features](11-Features) is the only place an operator could learn it. |
+| **Half-shipped** | CB-589 (#74) · CB-584 (#65) · CB-586 (#67) · CB-548 (#16) | Each works today with a stopgap. Candidates to defer to 1.2 if the cut needs to be small. |
+
+**On "Stage 5 ✅ production shape".** That row is not wrong — CB-504 did build a launchd agent and a
+systemd unit. But a unit in `deploy/` that no host has loaded is not supervision, and CB-594 is the
+gap between the two. Read the Stage 5 table as *built*, not as *deployed*.
+
 ## Delivery reliability & multi-host (CB-306 – CB-308)
 
 A cross-cutting track that came out of a **"communication break" review** of the reverse