code-coordinator 0.5.263__tar.gz → 0.5.264__tar.gz

{code_coordinator-0.5.263 → code_coordinator-0.5.264}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: code-coordinator
-Version: 0.5.263
+Version: 0.5.264
 Summary: Coordinate Claude Code workers across multiple machines and repos.
 Author-email: John Donaghy <johnfdonaghy@gmail.com>
 License-Expression: LicenseRef-FSL-1.1-MIT

{code_coordinator-0.5.263 → code_coordinator-0.5.264}/code_coordinator.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: code-coordinator
-Version: 0.5.263
+Version: 0.5.264
 Summary: Coordinate Claude Code workers across multiple machines and repos.
 Author-email: John Donaghy <johnfdonaghy@gmail.com>
 License-Expression: LicenseRef-FSL-1.1-MIT

{code_coordinator-0.5.263 → code_coordinator-0.5.264}/code_coordinator.egg-info/SOURCES.txt

@@ -265,6 +265,7 @@ coord/skills/fleet-restart-safety/SKILL.md
 coord/skills/merge-stuck-triage/SKILL.md
 coord/skills/pipeline-limbo-triage/SKILL.md
 coord/skills/portal-followup/SKILL.md
+coord/skills/release-now/SKILL.md
 coord/skills/review-verdict-recovery/SKILL.md
 coord/skills/tui-quadraui-workflow/SKILL.md
 coord/skills/update-issue/SKILL.md

{code_coordinator-0.5.263 → code_coordinator-0.5.264}/code_coordinator.egg-info/scm_file_list.json

@@ -241,6 +241,7 @@
     "coord/skills/merge-stuck-triage/SKILL.md",
     "coord/skills/pipeline-limbo-triage/SKILL.md",
     "coord/skills/portal-followup/SKILL.md",
+    "coord/skills/release-now/SKILL.md",
     "coord/skills/review-verdict-recovery/SKILL.md",
     "coord/skills/tui-quadraui-workflow/SKILL.md",
     "coord/skills/update-issue/SKILL.md",

{code_coordinator-0.5.263 → code_coordinator-0.5.264}/code_coordinator.egg-info/scm_version.json

@@ -1,7 +1,7 @@
 {
-  "tag": "0.5.263",
+  "tag": "0.5.264",
   "distance": 0,
-  "node": "g48c97e278762fe857dec843b91373c0a1ce790b2",
+  "node": "g037604ea4782108f989df77750337682d26f2a36",
   "dirty": false,
   "branch": "HEAD",
   "node_date": "2026-08-28"

{code_coordinator-0.5.263 → code_coordinator-0.5.264}/coord/commands/release.py

@@ -3146,7 +3146,29 @@ def release_nightly_window(
     existing = read_roll_pending()
 
     if dry_run:
-        if existing is not None:
+        # #2866: a marker naming a STALE target (not equal to the freshly
+        # resolved `record.target_version` — PyPI's "latest" moved, or the
+        # daemon reached/passed it some other way since the marker was set)
+        # must never be echoed back as "would attempt ... --target <stale>".
+        # This is the exact 2026-08-28 incident: a `propagate`-set marker
+        # for v0.5.254 survived on disk after the daemon had already
+        # reached v0.5.258 by other means, and `nightly-window --dry-run`
+        # read it back and printed a proposal to roll BACKWARDS to
+        # v0.5.254 — cleared by hand with `coord drive-queue cancel-roll`
+        # at the time. In reality a NON-dry-run run never fires a stale
+        # target either (section 3 below replaces it with
+        # `record.target_version` instead, whenever it differs) — this
+        # branch only makes the --dry-run description match that real
+        # behaviour instead of quoting the stale value as if it would run.
+        if existing is not None and existing.target_version != record.target_version:
+            click.echo(
+                f"a roll is pending for a stale target ({existing.describe()}) — "
+                f"would replace it with v{record.target_version} ({daemon_name} "
+                f"currently reports v{record.daemon_version or '?'}) rather than "
+                "ever firing the stale value (#2866); its original set_at/"
+                "deferrals would be preserved (#2607)"
+            )
+        elif existing is not None:
             click.echo(
                 f"a roll is already pending ({existing.describe()}) — would "
                 f"attempt `coord release propagate --daemon-host {daemon_name} "

{code_coordinator-0.5.263 → code_coordinator-0.5.264}/coord/deploy/coord-release-propagate.service

@@ -64,17 +64,38 @@
 #
 # MIN-RELEASES-BEHIND GATE (#2583) — OFF BY DEFAULT, NOT SET HERE
 # -----------------------------------------------------------------
-# `coord release propagate` (and `coord release nightly-window`, below)
-# support holding a run below a configurable delta —
-# `propagation.min_releases_behind` in coordinator.yml, or `--min-behind` on
-# either command — instead of attempting a roll on ANY delta at all (today's
-# default, `min_releases_behind=1`, unchanged unless configured). This
-# `ExecStart=` deliberately does NOT pass `--min-behind`: the threshold is
-# meant to be set (or left alone) via coordinator.yml so both this timer and
-# `coord-release-window.service` read the SAME value, and — per
-# `docs/AGENT_OPERATIONS.md`'s "Auto-roll threshold gate" section — must NOT
-# be raised above 1 on a fleet that has not first taken one manual roll onto
-# a fixed propagation lane. Below the threshold, this unit's own run reports
+# `coord release propagate` (and `coord release nightly-window`, its sibling
+# in `coord-release-window.service`) support holding a run below a
+# configurable delta — `propagation.min_releases_behind` in coordinator.yml,
+# or `--min-behind` on either command — instead of attempting a roll on ANY
+# delta at all (the default, `min_releases_behind=1`, unchanged unless
+# configured). This `ExecStart=` deliberately does NOT pass `--min-behind`:
+# THIS timer reads `propagation.min_releases_behind` straight from
+# coordinator.yml, un-overridden, and that is intentional — see #2866's
+# split:
+#
+#   | Trigger                          | Threshold | Role                  |
+#   |-----------------------------------|-----------|----------------------|
+#   | coord-release-propagate.timer     | 5 (config)| opportunistic — must  |
+#   | (this unit, every 20 min)         |           | not cordon/drain the  |
+#   |                                    |           | fleet every ~45 min,  |
+#   |                                    |           | auto-release.yml's    |
+#   |                                    |           | measured cadence      |
+#   |                                    |           | (12 releases on       |
+#   |                                    |           | 2026-08-27)           |
+#   | coord-release-window.timer        | 1 (fixed  | the guarantee — one   |
+#   | (daily)                           | via       | painless roll a day,  |
+#   |                                    | --min-behind)| whatever accumulated|
+#
+# `coordinator.yml` is a SHARED value read by both commands — raising it
+# here to spare this 20-minute cadence from over-eager rolls would ALSO
+# raise `coord-release-window.service`'s threshold if that unit read the
+# same unqualified default, which is exactly why THAT unit pins
+# `--min-behind 1` explicitly on its own `ExecStart=` rather than relying on
+# this shared config value. Per `docs/AGENT_OPERATIONS.md`'s "Auto-roll
+# threshold gate" section, `propagation.min_releases_behind` must NOT be
+# raised above 1 on a fleet that has not first taken one manual roll onto a
+# fixed propagation lane. Below the threshold, this unit's own run reports
 # `holding: N behind, threshold M` and exits 0, exactly like an ordinary
 # deferral — no cordon, no host touched.
 

{code_coordinator-0.5.263 → code_coordinator-0.5.264}/coord/deploy/coord-release-window.service

@@ -126,20 +126,53 @@
 #
 # MIN-RELEASES-BEHIND GATE (#2583) — OFF BY DEFAULT, NOT SET HERE
 # -----------------------------------------------------------------
-# This unit is the PREFERRED vehicle for the #2583 threshold: it is the one
-# place `coord release nightly-window` itself decides whether the daemon
-# host needs a roll at all, so a `propagation.min_releases_behind` set in
-# coordinator.yml (or a `--min-behind` appended to `ExecStart=` below) holds
-# it there — no roll-pending marker set, no `coord release propagate`
-# subprocess spawned — until the daemon is genuinely that many releases
-# behind PyPI's latest. Left unset here on purpose: `min_releases_behind=1`
-# (any delta at all, today's behaviour) is the safe default until an
-# operator deliberately raises it — see `docs/AGENT_OPERATIONS.md`'s
-# "Auto-roll threshold gate" section for why the CURRENT fleet must take one
-# manual roll first, onto a fixed propagation lane, before this is ever
-# turned up. A held run reports `holding: N behind, threshold M` in its own
-# journal (`coord release window-history`) and exits 0, same as a normal
-# `roll-pending`/`up-to-date` outcome.
+# #2866: `--min-behind 1` is set EXPLICITLY on `ExecStart=` below — this is
+# the packaged default now, not "left unset" as an earlier revision of this
+# comment said. The two release timers want DIFFERENT thresholds, and
+# `propagation.min_releases_behind` in coordinator.yml is shared by both
+# `coord release propagate` (step 3a) and `coord release nightly-window`
+# (step 2b) — raising it to spare the 20-minute propagate cadence from
+# cordoning/draining the fleet on every delta would ALSO raise it here,
+# which defeats the entire point of this unit (a guaranteed daily roll,
+# whatever accumulated):
+#
+#   | Trigger                          | Threshold | Role                  |
+#   |-----------------------------------|-----------|----------------------|
+#   | coord-release-propagate.timer     | 5 (config)| opportunistic — must  |
+#   | (every 20 min)                    |           | not cordon/drain the  |
+#   |                                    |           | fleet every ~45 min,  |
+#   |                                    |           | auto-release.yml's    |
+#   |                                    |           | measured cadence      |
+#   |                                    |           | (12 releases on       |
+#   |                                    |           | 2026-08-27)           |
+#   | coord-release-window.timer        | 1 (here)  | the guarantee — one   |
+#   | (daily)                           |           | painless roll a day,  |
+#   |                                    |           | whatever accumulated  |
+#
+# Measured on dellserver at 1 release behind: without `--min-behind` this
+# unit inherited the shared config's `min_releases_behind=5` and reported
+# `holding: 1 behind, threshold 5` — the daily guarantee was silently
+# count-based instead of time-based. `--min-behind` on `ExecStart=` always
+# wins over `propagation.min_releases_behind` (see `coord release
+# nightly-window --help`), so this unit's threshold stays 1 regardless of
+# what the shared config sets for the propagate timer. See
+# `docs/AGENT_OPERATIONS.md`'s "Auto-roll threshold gate" section for why a
+# threshold above 1 requires one manual roll first onto a fixed propagation
+# lane — that requirement is about `propagation.min_releases_behind`
+# (the propagate timer's knob), not this unit's hardcoded 1. A held run
+# reports `holding: N behind, threshold M` in its own journal (`coord
+# release window-history`) and exits 0, same as a normal `roll-pending`/
+# `up-to-date` outcome.
+#
+# The dellserver drop-in this superseded
+# (`~/.config/systemd/user/coord-release-window.service.d/override.conf`,
+# added as the interim fix before this landed) can now be deleted — this
+# `ExecStart=` reproduces it exactly, so removing the drop-in changes
+# nothing. `coord agent update` rewrites this unit file on every roll but
+# never touches a drop-in, which is why that override survived every roll
+# since it was added but would NOT have survived a from-scratch rebuild of
+# this host — the whole reason this is now the packaged default instead of
+# operator-local state.
 
 [Unit]
 Description=Release window: set/fire the #2587 roll-pending marker on the daemon host
@@ -153,7 +186,11 @@ Type=oneshot
 # it shells out to when firing an already-pending marker. A fleet that is
 # still busy is reported and left for the drive-queue tick to keep
 # watching, never overridden.
-ExecStart=%h/.local/bin/coord release nightly-window --config %h/.coord/coordinator.yml
+# #2866: --min-behind 1 is the daily guarantee's own threshold, deliberately
+# independent of `propagation.min_releases_behind` (which the 20-minute
+# coord-release-propagate.service alone should govern) — see the
+# MIN-RELEASES-BEHIND GATE comment above for the full split.
+ExecStart=%h/.local/bin/coord release nightly-window --config %h/.coord/coordinator.yml --min-behind 1
 # Bounded by the SAME ceiling coord-release-propagate.service uses: the
 # "marker already pending -> attempt a fire" branch shells out to `coord
 # release propagate` with its own 1800s subprocess timeout

code_coordinator-0.5.264/coord/deploy/coord-release-window.timer

@@ -0,0 +1,55 @@
+# coord release nightly-window — fires coord-release-window.service
+# (Type=oneshot) once a night. See that unit's header for the full
+# rationale (#2112, rewritten #2587).
+#
+# 10:00 America/Chicago — #2866: this is what the fleet actually runs
+# (dellserver carried it as an untracked
+# `coord-release-window.timer.d/override.conf` drop-in from 2026-08-26
+# until this became the packaged default), replacing the earlier packaged
+# 03:00 UTC. Named with an explicit zone rather than a bare local wall-clock
+# time specifically so a DST transition cannot drift the fire time by an
+# hour twice a year — `systemd.time(7)`'s `OnCalendar=` resolves a
+# zone-qualified spec against that zone's own clock, DST included. Still
+# inside a low-drive-activity part of the day; the exact hour matters far
+# less than picking ONE the operator can reason about, since #2587 already
+# means a late/early firing costs nothing (see below). #2587: this firing
+# itself is now fast (resolve the target, set-or-fire the roll-pending
+# marker, return) — there is no multi-hour drain to leave room for any
+# more. The ACTUAL roll may still land well after this fires if the fleet
+# stays busy; that is fine and by design, since it fires the instant `coord
+# drive-queue tick` sees the fleet's own next inter-drive gap rather than
+# waiting for THIS timer's next fire, and never stops any timer to get
+# there.
+#
+# The dellserver drop-in this superseded can now be deleted — this
+# `OnCalendar=` reproduces it exactly (same zone-qualified spec), so
+# removing the drop-in changes nothing. A from-scratch rebuild of that host
+# would otherwise have silently reverted to 03:00 UTC with no warning,
+# which is the whole reason this moved from operator-local override to
+# packaged default.
+#
+# RandomizedDelaySec is small and exists only to avoid firing at the exact
+# same wall-clock instant `coord-drive-queue.timer`'s own OnCalendar-free
+# interval schedule might land on, not because two hosts might race this
+# unit — it belongs on the daemon host ONLY (same rule as
+# coord-release-propagate.timer; see that unit's header for why a second
+# copy elsewhere is the #1440 two-overseers failure in a new costume).
+#
+# Persistent=true (#2112 trap 4 / acceptance-adjacent): a host that was
+# asleep or rebooted through 03:00 still catches up on the next boot, rather
+# than silently skipping a whole night. `coord release nightly-window`
+# itself is idempotent — see its module docstring's `needs_roll`: a fleet
+# already current at whatever time this actually fires touches nothing at
+# all.
+
+[Unit]
+Description=Nightly release window on the daemon host (#2112, #2587)
+
+[Timer]
+OnCalendar=*-*-* 10:00:00 America/Chicago
+RandomizedDelaySec=5min
+AccuracySec=1min
+Persistent=true
+
+[Install]
+WantedBy=timers.target

{code_coordinator-0.5.263 → code_coordinator-0.5.264}/coord/skills/coord-dispatch-verbs/SKILL.md

@@ -1,3 +1,9 @@
+---
+name: coord-dispatch-verbs
+description: "Use before running a `coord` CLI command to enqueue, dispatch, stage, or otherwise move a GitHub issue through the coordinator — disambiguates ~70 top-level commands with similarly-named pairs that silently do the wrong thing instead of erroring."
+trigger: About to run a `coord` command to move an issue forward, especially when unsure of the exact subcommand, or a command exited 0 but the expected effect didn't happen.
+---
+
 # coord-dispatch-verbs skill
 
 **Trigger:** About to run a `coord` command to enqueue, dispatch, stage, or

{code_coordinator-0.5.263 → code_coordinator-0.5.264}/coord/skills/drive-queue-preflight/SKILL.md

@@ -1,3 +1,9 @@
+---
+name: drive-queue-preflight
+description: "Use before queuing more than ~2 issues on one repo with `coord drive-queue add`, setting up an overnight/unattended run, or seeing a QUEUE: STALLED/BLOCKED status-bar alert — gives the real cost model and the read-the-alert table."
+trigger: "About to `coord drive-queue add` deep on one repo, or looking at a QUEUE: STALLED/BLOCKED alert."
+---
+
 # drive-queue-preflight skill
 
 **Trigger:** About to `coord drive-queue add` more than ~2 issues on one repo,

{code_coordinator-0.5.263 → code_coordinator-0.5.264}/coord/skills/fleet-restart-safety/SKILL.md

@@ -1,3 +1,9 @@
+---
+name: fleet-restart-safety
+description: "Use before restarting coord-agent/coord-serve or editing coordinator.yml on a live fleet — the two restarts kill different things (headless workers vs. interactive finalize) and neither warns you the way you'd expect."
+trigger: About to restart coord-agent (incl. `coord agent update`) or coord-serve, or edit coordinator.yml/coordinator.remote.yml on a live fleet.
+---
+
 # fleet-restart-safety skill
 
 **Trigger:** About to restart `coord-agent` (including `coord agent update`)

{code_coordinator-0.5.263 → code_coordinator-0.5.264}/coord/skills/merge-stuck-triage/SKILL.md

@@ -1,3 +1,9 @@
+---
+name: merge-stuck-triage
+description: "Use when a story won't merge — the TUI Go does nothing, `coord merge` skips it, or the queue box stays grey/pending — walks the merge gates in the order they actually block instead of guessing."
+trigger: A story won't merge, or an operator asks why something isn't merging.
+---
+
 # merge-stuck-triage skill
 
 **Trigger:** A story won't merge — the TUI "Go" does nothing, `coord merge` skips

{code_coordinator-0.5.263 → code_coordinator-0.5.264}/coord/skills/pipeline-limbo-triage/SKILL.md

@@ -1,3 +1,9 @@
+---
+name: pipeline-limbo-triage
+description: "Use when an issue sits in the Pipeline with no dispatch or visible activity — explains that Board vs Pipeline membership is label-driven, not assignment-driven, and gives the one-command fix."
+trigger: An issue shows up in the Pipeline but nobody dispatched it, or a Pipeline card looks stuck.
+---
+
 # pipeline-limbo-triage skill
 
 **Trigger:** An issue shows up in the Pipeline but nobody dispatched it, a

{code_coordinator-0.5.263 → code_coordinator-0.5.264}/coord/skills/portal-followup/SKILL.md

@@ -1,3 +1,9 @@
+---
+name: portal-followup
+description: "Use when investigating a customer-portal signoff/event that hasn't shown up, or troubleshooting `coord portal` state — gets a straight answer out of outbox/events/sync instead of confusing local-machine state with the bridge's own."
+trigger: Investigating a stuck customer-portal signoff/event, or any `coord portal` state troubleshooting.
+---
+
 # portal-followup skill
 
 **Trigger:** Investigating a customer-portal signoff/event that "hasn't shown up"

code_coordinator-0.5.264/coord/skills/release-now/SKILL.md

@@ -0,0 +1,177 @@
+---
+name: release-now
+description: "Use for an on-demand urgent deploy — finding which release actually contains a fix, distrusting `coord --version` on an agent host, forcing --min-behind past the holding threshold, checking headless workers the right way, and verifying the payload (not just the version banner) actually landed."
+trigger: Need a specific fix live on the fleet right now, outside the normal daily/20-minute release cadence.
+---
+
+# release-now skill
+
+**Trigger:** An operator needs a specific fix live on the fleet **right now**
+— a merged PR that must not wait for the next `coord-release-propagate.timer`
+fire or the nightly window — or is trying to confirm whether a fix is
+actually deployed anywhere.
+
+**Purpose:** Encode six things that had to be discovered by hand during the
+2026-08-27 incident (#2850 was in v0.5.257 while the fleet ran v0.5.254),
+so the next urgent deploy is a checklist instead of a rediscovery. Sourced
+from that incident and #2866; read `docs/AGENT_OPERATIONS.md`'s
+"Auto-roll threshold gate" section for the full `--min-behind` mechanism
+this skill leans on.
+
+---
+
+## 1. Which release actually contains the fix
+
+A closed issue and a merged PR say **nothing** about which published release
+ships the fix — the merge could still be unreleased, or the fleet could be
+several releases behind the one that has it. Answer it directly:
+
+```bash
+git tag --contains <merge-sha>       # every tag that already includes this commit
+```
+
+The lowest of those tags is the first release carrying the fix. #2850's
+merge landed in v0.5.257; the fleet was on v0.5.254 — three releases short,
+not "already deployed" the way "issue closed" suggests.
+
+## 2. `coord --version` is useless on these hosts
+
+It reports `0+unknown` on a machine running the pinned agent venv (`coord`
+resolves to a non-editable install with no importable package version at
+that path). Don't trust it as the ground truth for what's running. Read the
+wheel's own dist-info instead:
+
+```bash
+ls ~/.coord-venv/lib/python*/site-packages/ | grep -i '^coord-'
+cat ~/.coord-venv/lib/python*/site-packages/coord-*.dist-info/METADATA | grep '^Version:'
+```
+
+`coord release verify` / `coord release history` are the other honest
+sources — they read the same lane data this skill's step 5 cross-checks
+against, not a CLI banner.
+
+## 3. `--min-behind 1` is mandatory for an urgent roll
+
+`coord release propagate` and `coord release nightly-window` both hold
+below `propagation.min_releases_behind` (5 on a typical fleet,
+`coordinator.yml`'s `propagation:` block) — **without an explicit override
+this is a reported no-op**: `holding: N behind, threshold 5`, exit 0,
+nothing touched. An urgent deploy needs the delta to roll on ANY count:
+
+```bash
+coord release propagate --min-behind 1 --target vX.Y.Z --verify --rollback-on-red
+```
+
+Never omit `--min-behind 1` here just because the daily window "usually"
+handles it — the whole point of this skill is that the daily window's own
+cadence is too slow for "right now" (see #2866 for why the daily window
+itself now packages `--min-behind 1` by default, which does not help an
+urgent roll fired outside its schedule).
+
+## 4. `coord sessions --remote` does not see headless workers
+
+Carried over from the `fleet-restart-safety` skill: an urgent
+`coord release propagate` restarts every agent, which kills in-flight
+headless `claude -p` workers exactly like any other agent restart. Check
+**active assignments**, not interactive sessions, before firing:
+
+```bash
+curl -s http://<agent-host>:7433/status | python3 -c \
+  "import json,sys; print([(a['id'],a['status']) for a in json.load(sys.stdin).get('active',[])])"
+# or, fleet-wide:
+coord status
+```
+
+`coord sessions --remote` coming back empty is not evidence anything is
+safe to restart.
+
+## 5. Verify the payload, not the roll
+
+`✓ vX.Y.Z verified` (from `coord release propagate`/`coord release verify`)
+means **that version string is installed on that lane** — it does not mean
+your specific fix's code is present, imported, or reachable. Grep the venv
+directly for a symbol the fix introduced:
+
+```bash
+grep -r "SYMBOL_THE_FIX_ADDS" ~/.coord-venv/lib/python*/site-packages/coord/
+```
+
+When the fix spans a producer and a consumer, check **both halves** — a
+verified version string proves neither side landed correctly on its own.
+Example from #2850: `MERGE_LANDED_MARKER` needed to be present in both
+`drive.py` and `models.py`, **and** the `is_merge_landed_reason` import
+needed to be present in `drive_queue.py` — three greps, not one, before
+calling the roll confirmed.
+
+## 6. A stale `roll_pending.json` is a footgun, not cosmetic
+
+`coord drive-queue status` (or the TUI) shows the live #2587 roll-pending
+marker; the raw file is `~/.coord/roll_pending.json` on the daemon host.
+A marker naming an **older** version than what is currently deployed is
+actively dangerous, not harmless clutter — it can get fired (or, under
+`coord release nightly-window --dry-run`, at least *proposed*) as a
+backwards roll the next time the fleet goes quiescent. #2866 hardens
+`coord release nightly-window` against proposing a target the daemon has
+already passed, but a marker can still exist for other reasons (a `propagate`
+run that deferred, then got superseded by a manual roll). Check it before
+AND after an urgent deploy:
+
+```bash
+coord drive-queue status               # shows the marker if one is pending
+coord drive-queue cancel-roll          # clears it if it's stale/wrong
+```
+
+If `nightly-window --dry-run` ever proposes rolling to a version *older*
+than what `coord release verify` reports as currently installed, that is
+the #2866 footgun — clear the marker by hand rather than letting the next
+quiescent window fire it.
+
+## Checklist for an urgent deploy
+
+1. `git tag --contains <sha>` — confirm which release actually has the fix.
+2. Read the venv's dist-info (not `coord --version`) on the target host(s)
+   to confirm the CURRENT state, before touching anything.
+3. `coord status` / agent `/status` — confirm no headless worker is
+   mid-assignment on a host you're about to restart.
+4. `coord drive-queue status` — check for a stale roll-pending marker
+   before you start.
+5. `coord release propagate --min-behind 1 --target vX.Y.Z --verify
+   --rollback-on-red` (add `--daemon-host`/`--only` as needed).
+6. Grep the venv for a symbol the fix introduced — both producer and
+   consumer sides if the fix spans more than one file.
+7. `coord drive-queue status` again — confirm nothing was left pending
+   pointing at a stale target.
+
+## Incident history
+
+- **2026-08-27 (#2850):** the fix was merged and closed, but the fleet was
+  three releases behind it (v0.5.254 vs. the v0.5.257 that shipped it).
+  Discovering this required `git tag --contains`, not the issue/PR state.
+  The subsequent roll needed `--min-behind 1` because the default
+  `min_releases_behind=5` reported a silent no-op. Verifying the roll
+  required grepping the venv for `MERGE_LANDED_MARKER` /
+  `is_merge_landed_reason` — the version banner alone said nothing about
+  whether that specific fix was live.
+- **2026-08-28 (#2866):** a `roll_pending.json` marker left over from a
+  prior day's deferred `propagate` run named a version (0.5.254) the daemon
+  had already passed (it was on 0.5.258 by then). `nightly-window --dry-run`
+  read it back and proposed rolling the fleet **backwards**. Cleared by
+  hand with `coord drive-queue cancel-roll`; `coord release nightly-window`
+  itself was subsequently hardened to refuse this specific shape.
+
+## Rules
+
+- Never trust `coord --version` on an agent host — read the venv's
+  dist-info or `coord release verify`/`history` instead.
+- Always pass `--min-behind 1` explicitly for an on-demand roll — the
+  configured `propagation.min_releases_behind` threshold exists for the
+  opportunistic 20-minute timer, not for "I need this live now."
+- Always verify a payload symbol the fix introduces, not just the version
+  string `coord release propagate`/`verify` reports — check every side of a
+  producer/consumer fix.
+- Check `coord drive-queue status` for a stale roll-pending marker both
+  before and after an urgent deploy; a marker naming an older version than
+  what's installed is a backwards-roll hazard, not cosmetic state.
+- Check active assignments (`coord status` / agent `/status`), never
+  `coord sessions --remote`, before restarting anything that could kill a
+  headless worker.

{code_coordinator-0.5.263 → code_coordinator-0.5.264}/coord/skills/review-verdict-recovery/SKILL.md

@@ -1,3 +1,9 @@
+---
+name: review-verdict-recovery
+description: "Use when `coord gates` shows review : ERROR (not BLOCKED), or a headless review completed with no parseable verdict — recovers the verdict already sitting in the transcript instead of burning a full re-review cycle."
+trigger: "`coord gates <repo> <issue>` shows review : ERROR, or a review reached END_REVIEW with review_verdict=None on the board."
+---
+
 # review-verdict-recovery skill
 
 **Trigger:** `coord gates <repo> <issue>` shows `review : ERROR` (not

{code_coordinator-0.5.263 → code_coordinator-0.5.264}/coord/skills/tui-quadraui-workflow/SKILL.md

@@ -1,3 +1,9 @@
+---
+name: tui-quadraui-workflow
+description: "Use when working on tui/ (coord-tui) and the task needs the pinned quadraui git rev in tui/Cargo.toml bumped, or needs building against an unmerged quadraui branch/PR without touching the pin."
+trigger: Working on tui/ and the task needs the quadraui pin bumped, or building against an unmerged quadraui branch/PR.
+---
+
 # tui-quadraui-workflow skill
 
 **Trigger:** Working on `tui/` (coord-tui) and the task needs the `quadraui`

{code_coordinator-0.5.263 → code_coordinator-0.5.264}/coord/skills/update-issue/SKILL.md

@@ -1,3 +1,9 @@
+---
+name: update-issue
+description: "Synthesizes what was agreed in a 'Chat about issue' conversation and writes it back to the GitHub issue body, so the next worker or human picks up a refined, accurate scope instead of the original text."
+trigger: /update-issue
+---
+
 # /update-issue skill
 
 **Trigger:** Operator types `/update-issue` during a "Chat about issue" session.

{code_coordinator-0.5.263 → code_coordinator-0.5.264}/deploy/coord-release-propagate.service

@@ -64,17 +64,38 @@
 #
 # MIN-RELEASES-BEHIND GATE (#2583) — OFF BY DEFAULT, NOT SET HERE
 # -----------------------------------------------------------------
-# `coord release propagate` (and `coord release nightly-window`, below)
-# support holding a run below a configurable delta —
-# `propagation.min_releases_behind` in coordinator.yml, or `--min-behind` on
-# either command — instead of attempting a roll on ANY delta at all (today's
-# default, `min_releases_behind=1`, unchanged unless configured). This
-# `ExecStart=` deliberately does NOT pass `--min-behind`: the threshold is
-# meant to be set (or left alone) via coordinator.yml so both this timer and
-# `coord-release-window.service` read the SAME value, and — per
-# `docs/AGENT_OPERATIONS.md`'s "Auto-roll threshold gate" section — must NOT
-# be raised above 1 on a fleet that has not first taken one manual roll onto
-# a fixed propagation lane. Below the threshold, this unit's own run reports
+# `coord release propagate` (and `coord release nightly-window`, its sibling
+# in `coord-release-window.service`) support holding a run below a
+# configurable delta — `propagation.min_releases_behind` in coordinator.yml,
+# or `--min-behind` on either command — instead of attempting a roll on ANY
+# delta at all (the default, `min_releases_behind=1`, unchanged unless
+# configured). This `ExecStart=` deliberately does NOT pass `--min-behind`:
+# THIS timer reads `propagation.min_releases_behind` straight from
+# coordinator.yml, un-overridden, and that is intentional — see #2866's
+# split:
+#
+#   | Trigger                          | Threshold | Role                  |
+#   |-----------------------------------|-----------|----------------------|
+#   | coord-release-propagate.timer     | 5 (config)| opportunistic — must  |
+#   | (this unit, every 20 min)         |           | not cordon/drain the  |
+#   |                                    |           | fleet every ~45 min,  |
+#   |                                    |           | auto-release.yml's    |
+#   |                                    |           | measured cadence      |
+#   |                                    |           | (12 releases on       |
+#   |                                    |           | 2026-08-27)           |
+#   | coord-release-window.timer        | 1 (fixed  | the guarantee — one   |
+#   | (daily)                           | via       | painless roll a day,  |
+#   |                                    | --min-behind)| whatever accumulated|
+#
+# `coordinator.yml` is a SHARED value read by both commands — raising it
+# here to spare this 20-minute cadence from over-eager rolls would ALSO
+# raise `coord-release-window.service`'s threshold if that unit read the
+# same unqualified default, which is exactly why THAT unit pins
+# `--min-behind 1` explicitly on its own `ExecStart=` rather than relying on
+# this shared config value. Per `docs/AGENT_OPERATIONS.md`'s "Auto-roll
+# threshold gate" section, `propagation.min_releases_behind` must NOT be
+# raised above 1 on a fleet that has not first taken one manual roll onto a
+# fixed propagation lane. Below the threshold, this unit's own run reports
 # `holding: N behind, threshold M` and exits 0, exactly like an ordinary
 # deferral — no cordon, no host touched.