Roadmap: 1.1 is mostly done — split the section into done and open

Six of the ten themes are merged and verified today: supervision,
durability, credential scope, nudge scheduling, config accuracy and the
green build. The section still described all of them as outstanding.

Four remain: bridge_ask reach (decided, in flight), the last five
Features areas, CB-596 which needs the operator, and the four
half-shipped tickets that are the deferral candidates.

Commit count since v1.0.0 corrected from 175 to 196.
Dai Ha
2026-08-16 18:24:34 +02:00
parent b1d13d77e3
commit e1106b3e8e
+34 -17
@@ -227,7 +227,7 @@ guards regression-protected · `CB-521` the AMQP contract test runnable both loc
## 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
`v1.0.0` was tagged **2026-08-10**, message *"One leader, one host, complete"*. Since then **196
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?
@@ -239,11 +239,16 @@ 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"]
sup["supervision<br/>CB-594 · CB-600"]
dur["durability claim<br/>CB-527 · CB-528"]
sec["credential scope<br/>CB-593 · CB-596"]
sec["credential scope<br/>CB-593"]
bugs["nudge scheduling<br/>CB-590 · CB-598"]
cfg["config accuracy<br/>CB-597 · CB-599 · CB-602"]
flaky["green build<br/>CB-601 · CB-603"]
ask["bridge_ask reach<br/>CB-582"]
docs["catalogue debt<br/>CB-595"]
op["needs the operator<br/>CB-596"]
half["half-shipped<br/>CB-589 · CB-584 · CB-586 · CB-548"]
end
subgraph r2["release 2 — one centre, many hosts"]
fed["CB-308 federation"]
@@ -251,25 +256,37 @@ flowchart LR
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
class sup,dur,sec,bugs,cfg,flaky done
class ask,docs,op,half,fed todo
```
*Figure: the 1.1 milestone by theme. Everything on the left is single-host work; only CB-308 sits on
the right.*
*Figure: the 1.1 milestone by theme, as of 2026-08-16 evening. Green is merged; amber is open.
Everything on the left is single-host work; only CB-308 sits on the right.*
### Done — merged and verified
| Theme | Tickets | What it was |
|---|---|---|
| **Supervision** | CB-594 (#80) · CB-600 (#91) | The launchd unit shipped in `deploy/` and had never been installed, and launchd does not source a login shell — so a supervised daemon got no `WORKER_GITEA_TOKEN` and no `AI_GATEWAY_TOKEN`. The operator had to pick supervision *or* a working fleet. CB-600 then closed the gaps that only bite once the agent is loaded: a log path the script and the plist could silently disagree about, and a failed `load` leaving the agent stopped **and** persistently disabled. |
| **Durability** | CB-527 (#10) · CB-528 (#11) | No `basicQos`, so the backlog lived in JVM heap rather than on the broker; no publisher confirms, so a publish to a missing queue was a silent black hole. The wiki promised more durability than the code delivered. Both closed, with contract tests running against a real broker in CI. |
| **Credential scope** | CB-593 (#79) | The decision about which inherited credentials a member may keep is now recorded, so a deliberate choice no longer looks like an oversight. The canonical block also stopped claiming a member mounts only the bridge. |
| **Nudge scheduling** | CB-590 (#75) · CB-598 (#87) | Two schedules could inject into one lead pane at once. Then the reminder budget turned out to be a counter carried forward with no memory of *which item* it counted, so work arriving during the backoff window inherited an already-capped count and was never nudged once. |
| **Config accuracy** | CB-597 (#85) · CB-599 (#89) · CB-602 (#96) | Two documented knobs that are read by nothing; a capacity refusal that surfaced as a bare HTTP 500; and no test at all in the code→example direction, so a brand-new key could ship undocumented. |
| **Green build** | CB-601 (#95) · CB-603 (#100) | Two flaky tests, same root: a test that observes an asynchronous loop must be safe against that loop's thread, and neither the compiler nor a green build will say it is not. |
### Open
| 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. |
| **`bridge_ask` reach** | CB-582 (#61) | A ~55s ask 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. The decision is made: make a pending question visible to `bridge_poll`, and push it at the lead's pane through the nudge loop CB-588 already built. |
| **Catalogue debt** | CB-595 (#81) | Mostly cleared. Five areas remain, each needing its config surface and gotcha confirmed against the code: `/metrics` and `/healthz`, bearer auth, the authz table and audit log, the systemd unit, and multi-profile routing. |
| **Needs the operator** | CB-596 (#82) | CB-592 blocks one credential name; the pane's login shell re-sources about thirty, and a second forge token is among the untouched ones. The probe that would enumerate them is refused by the command classifier, so this one cannot be closed from inside a session. |
| **Half-shipped** | CB-589 (#74) · CB-584 (#65) · CB-586 (#67) · CB-548 (#16) | Each works today with a stopgap. These are the 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*.
**On "Stage 5 ✅ production shape".** That row was never 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. CB-594 and CB-600
closed the gap between *built* and *safe to install*; the agent is still **not installed**, because
installing it is the operator's decision. Read the Stage 5 table as *built*, not as *running*.
## Delivery reliability & multi-host (CB-306 – CB-308)