From 523a494650b2bbdb2e2be0dc30cd75fdf2006315 Mon Sep 17 00:00:00 2001 From: Dai Ha Date: Sun, 16 Aug 2026 18:54:53 +0200 Subject: [PATCH] 1.1 close-out: CB-582 and CB-604 land; three tickets left MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Moves bridge_ask reach and catalogue debt into Done, folds CB-604 into config accuracy, and adds CB-606 — the three fields with CB-604's shape, one of which turns authentication off on a typo. Also fixes a sentence the cut decision had made false: the milestone intro still said only CB-308 goes to release 2. Four tickets went. The rule that decided it is now stated — missing is not the same as broken. Commit count since v1.0.0 corrected 196 -> 204. --- 8-Roadmap.md | 53 +++++++++++++++++++++++++++++++++++++++------------- 1 file changed, 40 insertions(+), 13 deletions(-) diff --git a/8-Roadmap.md b/8-Roadmap.md index 2220e9b..f06be17 100644 --- a/8-Roadmap.md +++ b/8-Roadmap.md @@ -227,14 +227,16 @@ 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 **196 +`v1.0.0` was tagged **2026-08-10**, message *"One leader, one host, complete"*. Since then **204 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. +would still be broken with exactly one host, it belongs in 1.1.** Read strictly, that rule sent four +tickets to 2.0, not one — see *Deferred to 2.0* below. The distinction it turns on: a capability that +is **missing** is not the same as one that is **broken**. Cost-first placement is missing, and there +is a workaround; a config key that is accepted and silently does nothing is broken. ```mermaid flowchart LR @@ -247,21 +249,24 @@ flowchart LR flaky["green build
CB-601 · CB-603"] ask["bridge_ask reach
CB-582"] docs["catalogue debt
CB-595"] + val["config validation
CB-604 · CB-606"] op["needs the operator
CB-596"] - half["half-shipped
CB-589 · CB-584 · CB-586 · CB-548"] + wip["snapshot pruning
CB-586"] end subgraph r2["release 2 — one centre, many hosts"] fed["CB-308 federation"] + defer["CB-589 · CB-548 · CB-605"] end r1 --> r2 classDef done fill:#2f855a,stroke:#22543d,color:#ffffff; classDef todo fill:#b7791f,stroke:#7b341e,color:#ffffff; - class sup,dur,sec,bugs,cfg,flaky done - class ask,docs,op,half,fed todo + class sup,dur,sec,bugs,cfg,flaky,ask,docs done + class val,op,wip,fed,defer todo ``` *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.* +CB-604 is merged but shares its box with CB-606, which is not — the box stays amber until both land. +Everything on the left is single-host work; the right is release 2.* ### Done — merged and verified @@ -270,18 +275,40 @@ Everything on the left is single-host work; only CB-308 sits on the right.* | **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. | +| **Nudge scheduling** | CB-590 (#75) · CB-598 (#87) · CB-582 (#61) | 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. CB-582 added the third source: a worker paused in `bridge_ask` now nudges the lead itself, and `bridge_status` and REST both show the open question. **The ~55s window is closed, not removed** — still do not brief a worker to "ask me". | +| **Config accuracy** | CB-597 (#85) · CB-599 (#89) · CB-602 (#96) · CB-604 (#102) | Two documented knobs that are read by nothing; a capacity refusal that surfaced as a bare HTTP 500; no test at all in the code→example direction, so a brand-new key could ship undocumented; and an unknown `kind:` accepted silently and routed to the wrong adapter, which now refuses at config load. | +| **Catalogue debt** | CB-595 (#81) | `wiki/11-Features.md` had fallen about fourteen entries behind, worst on the entries that changed what a config key *means*. `bridged.yaml` is gitignored, so that page is the only place an operator could learn them. Cleared — and it turned up two defects on the way (CB-604, CB-606). | | **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 | +Three, as of 2026-08-16 evening. + +| Theme | Ticket | The point | |---|---|---| -| **`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. | +| **Config validation** | CB-606 (#106) | CB-604 fixed one field, and its brief asked the worker to *report* others with the same shape rather than fix them. It found three. The `auth.mode` one is worse than the original: a typo of `token` silently behaves as `loopback-trust`, and `validateAuthExposure()` only fires on a **non-loopback** bind — so a loopback bind hides it completely, and the daemon runs with **no authentication** while the operator believes it is authenticated. | +| **Snapshot pruning** | CB-586 (#67) | Nothing ever prunes `refs/wip/*`, so CB-578 stage C's snapshots pin objects forever. In flight. | | **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. | + +### Deferred to 2.0 — the cut decision + +Made 2026-08-16, by reading the admission rule strictly. + +| Ticket | Why it moved | +|---|---| +| CB-308 (#6) | Federation. It is what 2.0 *is*. | +| CB-589 (#74) | Cost-first placement. `weighted` spreads by ratio with no idea which profile costs money, so paid spawns happen while the free box sits idle — but that is working behaviour that costs too much, with a decisive workaround (`local.weight: 100`), not something broken on one host. A missing **explanation** of the workaround *was* broken, because `bridged.yaml` is gitignored and a fresh host starts without it. **That half shipped in 1.1**; the policy did not. | +| CB-548 (#16) | Architect slots. A new capability, and genuinely blocked: `MemberRegistry.bind` is never called. | +| CB-605 (#103) | The systemd unit carries launchd's login-shell secret gap. Bites only when the first Linux gateway is stood up. | + +### Before the tag + +1. Land or defer CB-606 and CB-586. CB-596 needs the operator. +2. **Redeploy the daemon.** Every merge in 1.1 is undeployed — the running `bridged` holds the jar it + started with. A merge is not a deployment. Run `scripts/redeploy-bridged.sh` once the fleet has + drained; a restart drops in-flight tickets and rendezvous. +3. Confirm `bridge_whoami` still answers `primary` after the restart. +4. Then tag `v1.1.0` and mark this section closed. **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