code-coordinator 0.5.94__tar.gz → 0.5.96__tar.gz

{code_coordinator-0.5.94 → code_coordinator-0.5.96}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: code-coordinator
-Version: 0.5.94
+Version: 0.5.96
 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.94 → code_coordinator-0.5.96}/code_coordinator.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: code-coordinator
-Version: 0.5.94
+Version: 0.5.96
 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.94 → code_coordinator-0.5.96}/code_coordinator.egg-info/scm_version.json

@@ -1,7 +1,7 @@
 {
-  "tag": "0.5.94",
+  "tag": "0.5.96",
   "distance": 0,
-  "node": "gc872293016c9a4132c83fff7881956b707aacbf7",
+  "node": "g312293364325c98de0888c4de55e3f5f168662dd",
   "dirty": false,
   "branch": "HEAD",
   "node_date": "2026-08-15"

{code_coordinator-0.5.94 → code_coordinator-0.5.96}/coord/acceptance.py

@@ -22,7 +22,7 @@ import json
 import re
 from dataclasses import dataclass, field
 from pathlib import Path
-from typing import Any, Callable
+from typing import Any, Callable, Literal
 
 import yaml
 
@@ -1105,3 +1105,46 @@ def clear_expected_red_via_pr(
         f"cleared expected_red for #{issue_number}: {', '.join(sorted(ids))} "
         f"(PR #{pr['number']})"
     )
+
+
+ExpectedRedClearStatus = Literal["cleared", "no_op", "pending_retry", "failed"]
+
+
+def classify_expected_red_clear_result(msg: str) -> ExpectedRedClearStatus:
+    """#2266 review (blocking finding 2): the single source of truth for
+    interpreting :func:`clear_expected_red_via_pr`'s return string.
+
+    Before this, ``coord.merge_queue._maybe_clear_expected_red`` and
+    ``coord.commands.acceptance._clear_stuck_expected_red`` each carried
+    their own ``msg.startswith("cleared expected_red")`` check — two
+    independent implementations of "did the clear succeed?" that agreed
+    today but could silently desync the moment either
+    :func:`clear_expected_red_via_pr`'s wording changed (the exact "One
+    question, one answer" split-brain the epic #2096 review checklist
+    warns about). Both call sites now classify through this function.
+
+    Returns one of four outcomes, not a bare bool — a binary
+    cleared/not-cleared collapsed two very different "not cleared" cases
+    into one (#2266 review, blocking finding 1):
+
+    * ``"cleared"`` — the PR opened *and* merged; entries are gone.
+    * ``"no_op"`` — there was nothing to clear in the first place (no
+      manifest found for this issue, or the issue has no ``expected_red``
+      entries at all). This is the *common* case for an ordinary
+      oracle-loop merge whose issue was never part of a deliberately-red
+      slice — it must never read as a failure.
+    * ``"pending_retry"`` — the clearing PR opened but did not merge yet
+      (branch protection / required checks pending); the caller already
+      knows this will retry on the next merge, not a hard failure.
+    * ``"failed"`` — a genuine failure: everything ``clear_expected_red_via_pr``'s
+      docstring says degrades to a ``"warning: ..."``-prefixed string
+      (unresolvable branch tip, a commit/PR-open/PR-merge exception, an
+      unsupported ``gh_ops``, a JSON manifest, or unchanged text).
+    """
+    if msg.startswith("cleared expected_red"):
+        return "cleared"
+    if msg.startswith("no expected_red entries"):
+        return "no_op"
+    if "did not merge" in msg and "will retry on the next merge" in msg:
+        return "pending_retry"
+    return "failed"

{code_coordinator-0.5.94 → code_coordinator-0.5.96}/coord/commands/acceptance.py

@@ -50,6 +50,7 @@ from coord.acceptance_drivers import DriverError, run_driver
 from coord.commands._common import _CONFIG_OPTION, _load_config
 from coord.comments import format_needs_attention
 from coord.dispatch import DispatchRefused
+from coord.models import Repo
 
 
 @click.group("acceptance")
@@ -642,12 +643,42 @@ def acceptance_record(
         "merge` right after that issue's fix merges) may have failed, or "
         "the fix landed by some other path. A long-lived expected_red "
         "entry is exactly the invisible debt this command exists to "
-        "surface."
+        "surface. #2266: `--clear` acts on it — for every STUCK entry this "
+        "listing finds, invoke the same `clear_expected_red_via_pr` PR "
+        "path `coord merge` uses, so a registry stuck because the merge-"
+        "time trust-gate guards never fired (acceptance never recorded, or "
+        "the PR merged out of band) has a re-fire path instead of only a "
+        "detector. Never touches an entry whose issue is still open — "
+        "those are read as legitimately red, not stuck."
     ),
 )
 @click.argument("repo")
 @_CONFIG_OPTION
-def acceptance_expected_red(repo: str, config_path: Path) -> None:
+@click.option(
+    "--clear", "do_clear", is_flag=True, default=False,
+    help=(
+        "Open+merge the expected_red-clearing PR for every STUCK entry "
+        "this listing finds (issue closed, entries still live). Skips — "
+        "never clears — any entry whose issue is still open."
+    ),
+)
+@click.option(
+    "--issue", "only_issue", type=int, default=None,
+    help="With --clear, restrict clearing to this issue number.",
+)
+def acceptance_expected_red(
+    repo: str, config_path: Path, do_clear: bool, only_issue: int | None,  # noqa: FBT001
+) -> None:
+    if only_issue is not None and not do_clear:
+        # #2266 review nit: `--issue` only narrows what `--clear` acts on
+        # (per its own help text) — silently accepting it without `--clear`
+        # looks like it did something when it didn't.
+        click.echo(
+            "warning: --issue has no effect without --clear; the listing "
+            "below covers every issue.",
+            err=True,
+        )
+
     cfg = _load_config(config_path)
     repo_entry = cfg.repo(repo)
     if repo_entry is None:
@@ -660,23 +691,117 @@ def acceptance_expected_red(repo: str, config_path: Path) -> None:
         return
 
     total = 0
+    # #2266: STUCK entries found while rendering the listing above — the
+    # exact set `--clear` acts on, so the remedy can never drift from the
+    # detector that names the debt.
+    stuck: list[tuple[str, int, frozenset[str]]] = []
     for ms, by_issue in sorted(by_ms.items()):
         click.echo(f"{ms}:")
         for issue_number, ids in sorted(by_issue.items()):
             total += len(ids)
             closed_note = ""
+            is_stuck = False
             try:
                 issue_data = github_ops.get_issue(repo_entry.github, issue_number)
                 if str((issue_data or {}).get("state", "")).lower() == "closed":
                     closed_note = "  [STUCK: issue is closed but entries remain]"
+                    is_stuck = True
             except Exception:  # noqa: BLE001 — a lookup hiccup shouldn't hide the entry itself
                 pass
             click.echo(
                 f"  #{issue_number}: {', '.join(sorted(ids))}{closed_note}"
             )
+            if is_stuck:
+                stuck.append((ms, issue_number, ids))
     click.echo(f"\n{total} expected_red test-id(s) across "
                f"{sum(len(v) for v in by_ms.values())} issue(s).")
 
+    if not do_clear:
+        return
+
+    _clear_stuck_expected_red(repo, repo_entry, stuck, only_issue)
+
+
+def _clear_stuck_expected_red(
+    repo: str, repo_entry: Repo, stuck: list[tuple[str, int, frozenset[str]]],
+    only_issue: int | None,
+) -> None:
+    """#2266: the remedy half of `coord acceptance expected-red --clear`.
+
+    Acts ONLY on *stuck* — the STUCK (issue closed, entries still live) set
+    the listing above already computed — never on an issue whose entries
+    are legitimately still red (still open). `--issue` narrows to one
+    issue but does not widen scope: naming an open issue's number here
+    finds nothing to clear, same as naming one that isn't in *stuck* at
+    all.
+
+    Exits non-zero when at least one entry hard-fails to clear (#2266
+    review, non-blocking finding: without this, a caller scripting this
+    command in CI/cron could only detect a fully-failed run by reading
+    stdout or separately querying the audit log).
+    """
+    from coord.acceptance import (  # noqa: PLC0415
+        classify_expected_red_clear_result,
+        clear_expected_red_via_pr,
+    )
+    from coord.audit import record_audit  # noqa: PLC0415
+
+    if only_issue is not None:
+        stuck = [s for s in stuck if s[1] == only_issue]
+        if not stuck:
+            click.echo(
+                f"\n--issue {only_issue}: not STUCK (open, or no "
+                "expected_red entries recorded for it) — nothing to clear."
+            )
+            return
+
+    if not stuck:
+        click.echo("\nno STUCK entries to clear.")
+        return
+
+    click.echo(f"\nclearing {len(stuck)} STUCK issue(s)...")
+    # #2266 review (blocking finding 2): classify through the same shared
+    # helper `coord.merge_queue._maybe_clear_expected_red` uses, instead of
+    # each surface independently re-deriving "did this succeed?" from the
+    # message text — a split-brain waiting to happen if the message
+    # wording ever changes (epic #2096's "one question, one answer").
+    any_failed = False
+    for ms, issue_number, ids in stuck:
+        msg = clear_expected_red_via_pr(
+            repo_entry.github, repo, repo_entry.default_branch, issue_number,
+            gh_ops=github_ops,
+        )
+        click.echo(f"  #{issue_number}: {msg}")
+        status = classify_expected_red_clear_result(msg)
+        if status == "no_op":
+            # These entries were just listed as STUCK, so this should be
+            # rare (e.g. a race — another process already cleared them) —
+            # but it's still not a failure worth a durable audit row.
+            continue
+        if status == "failed":
+            any_failed = True
+        event_type = {
+            "cleared": "expected_red_clear",
+            "pending_retry": "expected_red_clear_pending",
+            "failed": "expected_red_clear_failed",
+        }[status]
+        # #2266 scope 2: a failed clear must land somewhere durable — the
+        # audit log — so the next pass over this repo can say "this
+        # registry is still stuck" without anyone re-reading this output.
+        record_audit(
+            tier="business",
+            category="acceptance",
+            event_type=event_type,
+            actor="user",
+            summary=f"coord acceptance expected-red --clear {repo} #{issue_number}: {msg}",
+            repo=repo,
+            issue=issue_number,
+            details={"ms": ms, "test_ids": sorted(ids), "result": msg},
+        )
+
+    if any_failed:
+        sys.exit(1)
+
 
 def _acceptance_record_local(
     repo: str,

{code_coordinator-0.5.94 → code_coordinator-0.5.96}/coord/commands/release.py

@@ -371,6 +371,66 @@ def _interactive_session_busy(config) -> list:
     return busy
 
 
+def _paused_machine_busy(config) -> list:
+    """Operator pause / quiet-hours state as host-pinned `Busy` signals (#2174).
+
+    `release_propagate.assess_quiescence`'s ``extra_busy`` docstring has
+    named "a machine paused by an operator" as a seam producer since
+    #1835, but until now nothing fed it one: `coord pause <machine>` said
+    "leave this box alone" and `coord release propagate` read the machine
+    as quiescent anyway, restarting `coord-agent` (and, on the daemon
+    host, `coord-serve`) on it regardless.
+
+    `coord.machine_pause.follow_on_paused_set()` is explicit `coord pause`
+    UNION any quiet-hours window currently covering the machine — both
+    genuine "an operator or an operator-set policy said stay off this
+    box" facts — MINUS #2101 release cordons. Cordons are deliberately
+    excluded: a cordon is THIS command's own drain mechanism, set to make
+    a behind host quiescent, not a sign that it already is one; feeding a
+    cordon back in here as "busy" would make it defer the very roll it
+    exists to unblock.
+
+    Thin-client aware for free: `follow_on_paused_set` routes through the
+    daemon's `/pause` endpoint when a board service is configured (#1563),
+    so this reads the one copy of pause state that actually governs
+    dispatch — same as every other pause-aware call site in the fleet.
+    """
+    from coord.machine_pause import (  # noqa: PLC0415
+        describe_pause_state,
+        effective_quiet_hours,
+        follow_on_paused_set,
+    )
+    from coord import release_propagate as rp  # noqa: PLC0415
+
+    machines = list(getattr(config, "machines", ()) or ())
+    if not machines:
+        return []
+    paused = follow_on_paused_set(machines)
+    if not paused:
+        return []
+    quiet_hours = effective_quiet_hours(machines)
+    busy = []
+    for machine in machines:
+        if machine.name not in paused:
+            continue
+        state = describe_pause_state(machine, paused, quiet_hours=quiet_hours)
+        if state is None:
+            continue  # defensive: membership in `paused` implies a reason
+        detail = (
+            f"quiet hours {state.detail}" if state.kind == "quiet"
+            else "explicit `coord pause`"
+        )
+        busy.append(
+            rp.Busy(
+                kind="machine paused",
+                subject=machine.name,
+                detail=detail,
+                host=machine.name,
+            )
+        )
+    return busy
+
+
 def _daemon_machine_name(
     config, override: str | None, machine_health: dict | None = None
 ) -> str | None:
@@ -638,6 +698,10 @@ def release_propagate(  # noqa: PLR0912, PLR0915 — a pipeline; the decisions a
     # probe `coord sessions --remote` uses, so a live session defers a roll
     # exactly like a live headless assignment does.
     extra_busy.extend(_interactive_session_busy(config))
+    # #2174: nor can it see `coord pause`/quiet-hours state — feed the same
+    # seam from the daemon-aware pause store, so an operator-paused machine
+    # defers exactly like a live assignment does instead of reading idle.
+    extra_busy.extend(_paused_machine_busy(config))
     quiescence = rp.assess_quiescence(
         queue_entries=board.get("drive_queue") or [],
         assignments=board.get("assignments") or [],
@@ -2163,14 +2227,19 @@ def _drain(
     #2228: ``extra_busy_fetch`` re-probes live interactive sessions on
     every poll (not just once) — a session that ends mid-drain should let
     the daemon host clear within THIS wait, not only on the next `coord
-    release propagate` tick. Deliberately keyed off the explicit *config*
-    param, never an implicit ``_load_config(config_path)`` fallback: this
-    function is called with ``config_path=None`` from unit tests that
-    inject their own clock/board — silently resolving a real
-    ``coordinator.yml`` (and then SSH-probing whatever machines it names)
+    release propagate` tick. #2174: the same default also re-reads
+    `coord pause`/quiet-hours state on every poll, for the same reason —
+    an operator pausing the daemon host mid-drain must stop the drain from
+    ever reporting "clear", and an operator lifting a pause mid-drain
+    should let it clear within THIS wait rather than the next tick.
+    Deliberately keyed off the explicit *config* param, never an implicit
+    ``_load_config(config_path)`` fallback: this function is called with
+    ``config_path=None`` from unit tests that inject their own clock/board
+    — silently resolving a real ``coordinator.yml`` (and then SSH-probing
+    whatever machines it names, or reading this host's own pause store)
     the moment ``config`` is omitted would make this loop non-hermetic by
-    default. No *config* simply means "no interactive-session signal this
-    call" — the caller opts in by passing one, as the real
+    default. No *config* simply means "no interactive-session or pause
+    signal this call" — the caller opts in by passing one, as the real
     ``coord release nightly-window`` call site does.
     """
     import time as _time  # noqa: PLC0415
@@ -2184,7 +2253,12 @@ def _drain(
     fetch_fn = board_fetch or _fetch_board
     if extra_busy_fetch is None:
         if config is not None:
-            extra_busy_fetch = lambda: _interactive_session_busy(config)  # noqa: E731
+            # #2174: paused/quiet-hours state, same as the top-level
+            # `propagate` call site — a paused daemon host must keep the
+            # drain from ever reading "clear" just because tmux is quiet.
+            extra_busy_fetch = lambda: (  # noqa: E731
+                _interactive_session_busy(config) + _paused_machine_busy(config)
+            )
         else:
             extra_busy_fetch = lambda: []  # noqa: E731
 

{code_coordinator-0.5.94 → code_coordinator-0.5.96}/coord/merge_queue.py

@@ -4387,26 +4387,36 @@ def _test_author_effective_issue_number(entry: QueuedMerge, board) -> int | None
     return None
 
 
-def _issue_has_expected_red_entries(entry: QueuedMerge, gh_ops: GhOps) -> bool:
-    """#2199 review (blocking finding 2): whether *entry*'s issue has at
-    least one ``expected_red`` entry recorded against it in some
-    ``ms-*/manifest.yml`` on ``entry.target_branch`` — the scope check
-    that keeps :func:`_maybe_clear_expected_red`'s loud "no passing
-    trust-gate verdict" diagnostic from firing on every ordinary
-    ``CLOSES_ISSUE_TYPES`` merge fleet-wide (no driver configured, no
-    oracle-opted-in milestone, an ``oracle:exempt`` issue — none of which
-    ever populate ``expected_red`` for their issue, #2191). Those merges
-    have nothing here for ``coord acceptance record`` to ever have cleared
-    and never will; before this check, the diagnostic branch below could
-    not tell them apart from an issue that genuinely IS in scope and
-    genuinely IS stuck red, so it printed the same actionable-looking
-    (and, for a driverless repo, un-followable) advice on every single one.
+def _expected_red_ids_for_entry(entry: QueuedMerge, gh_ops: GhOps) -> frozenset[str]:
+    """#2199 review (blocking finding 2) / #2266 review (non-blocking
+    finding): the ``expected_red`` test ids, if any, recorded against
+    *entry*'s issue in some ``ms-*/manifest.yml`` on ``entry.target_branch``.
+
+    Two call sites need this:
+
+    * :func:`_issue_has_expected_red_entries` — the scope check that keeps
+      :func:`_maybe_clear_expected_red`'s loud "no passing trust-gate
+      verdict" diagnostic from firing on every ordinary
+      ``CLOSES_ISSUE_TYPES`` merge fleet-wide (no driver configured, no
+      oracle-opted-in milestone, an ``oracle:exempt`` issue — none of which
+      ever populate ``expected_red`` for their issue, #2191). Those merges
+      have nothing here for ``coord acceptance record`` to ever have
+      cleared and never will; before this check, the diagnostic branch
+      below could not tell them apart from an issue that genuinely IS in
+      scope and genuinely IS stuck red, so it printed the same
+      actionable-looking (and, for a driverless repo, un-followable)
+      advice on every single one.
+    * :func:`_maybe_clear_expected_red`'s clear branch, to put the actual
+      test ids (not just a pr/branch pair) into the durable audit row —
+      matching ``coord acceptance expected-red --clear``'s
+      ``details["test_ids"]`` so a merge-queue-triggered clear is just as
+      correlatable back to specific stuck tests as a CLI-triggered one.
 
     Reuses the exact API-only lookup ``coord.acceptance.
     clear_expected_red_via_pr`` already performs on the success path —
     best-effort/read-only like the rest of this sweep: any lookup failure
     (unreachable API, older ``gh_ops`` stub missing the list/get methods)
-    reads as "not in scope", matching :func:`coord.acceptance.
+    reads as "nothing recorded", matching :func:`coord.acceptance.
     find_ms_manifest_for_issue_via_api`'s own fail-soft posture.
     """
     from coord.acceptance import find_ms_manifest_for_issue_via_api  # noqa: PLC0415
@@ -4416,11 +4426,59 @@ def _issue_has_expected_red_entries(entry: QueuedMerge, gh_ops: GhOps) -> bool:
             entry.repo_github, entry.target_branch, entry.issue_number, gh_ops=gh_ops,
         )
     except Exception:  # noqa: BLE001 — best-effort, same posture as callers
-        return False
+        return frozenset()
     if found is None:
-        return False
+        return frozenset()
     _path, _text, _blob_sha, data = found
-    return bool(data.expected_red.get(entry.issue_number))
+    return frozenset(data.expected_red.get(entry.issue_number, frozenset()))
+
+
+def _issue_has_expected_red_entries(entry: QueuedMerge, gh_ops: GhOps) -> bool:
+    """Whether *entry*'s issue has at least one ``expected_red`` entry
+    recorded against it. See :func:`_expected_red_ids_for_entry` for why
+    this scope check exists."""
+    return bool(_expected_red_ids_for_entry(entry, gh_ops))
+
+
+def _record_expected_red_audit(
+    entry: QueuedMerge,
+    event_type: str,
+    message: str,
+    *,
+    test_ids: frozenset[str] | None = None,
+) -> None:
+    """#2266: durable half of an `expected_red` clear/skip/failure — a
+    `MergeEvent` alone only reaches the operator as a `coord merge` output
+    line that scrolls past (issue #2266's framing: "nothing durable,
+    nothing re-checked"). ``record_audit`` gives the same outcomes
+    (cleared, skipped for one of two distinct reasons, pending retry, or
+    attempted-and-failed) a queryable row (`coord audit` / `query_audit_log`)
+    so a repo with a stuck registry is discoverable without re-reading
+    merge output. Best-effort like every other audit call site in this
+    module — ``record_audit`` itself never raises.
+
+    *test_ids*, when given, lands in ``details["test_ids"]`` — matching the
+    CLI path's (`coord.commands.acceptance._clear_stuck_expected_red`)
+    audit payload, per #2266 review non-blocking finding: without it,
+    merge-queue-triggered audit rows were harder to correlate back to the
+    specific stuck test ids than CLI-triggered ones.
+    """
+    details: dict[str, object] = {
+        "pr_number": entry.pr_number, "target_branch": entry.target_branch,
+    }
+    if test_ids:
+        details["test_ids"] = sorted(test_ids)
+    record_audit(
+        tier="business",
+        category="acceptance",
+        event_type=event_type,
+        actor="system",
+        summary=f"{entry.repo_name}#{entry.issue_number}: {message}",
+        repo=entry.repo_name,
+        issue=entry.issue_number,
+        assignment_id=entry.assignment_id,
+        details=details,
+    )
 
 
 def _maybe_clear_expected_red(entry: QueuedMerge, board, gh_ops: GhOps) -> MergeEvent | None:
@@ -4462,21 +4520,29 @@ def _maybe_clear_expected_red(entry: QueuedMerge, board, gh_ops: GhOps) -> Merge
         )
     acceptance_state = getattr(work, "acceptance_state", None)
     if acceptance_state != "passed":
-        if not _issue_has_expected_red_entries(entry, gh_ops):
+        ids = _expected_red_ids_for_entry(entry, gh_ops)
+        if not ids:
             # Not in scope for the oracle loop at all — the pre-#2199
             # silent no-op is still correct here, not a regression (see
             # the docstring above and #2199 review finding 2).
             return None
-        return MergeEvent(
-            entry, "expected_red_clear_skipped_no_acceptance",
+        msg = (
             f"no passing trust-gate verdict recorded on {work.assignment_id} "
             f"(acceptance_state={acceptance_state!r}) — the external `coord "
             "acceptance record` re-run either never happened or did not "
             "pass; skipping expected_red clear. Run `coord acceptance "
             f"record --repo {entry.repo_name} --issue {entry.issue_number} "
             "--sha <merged sha>` by hand, or re-drive the issue, to clear "
-            "any listed entries.",
+            "any listed entries."
+        )
+        # #2266: distinct from the SHA-mismatch guard below — "acceptance
+        # never recorded" and "recorded SHA is stale" are different
+        # problems with different fixes, so they get distinct event types
+        # rather than reaching the operator as the same silence.
+        _record_expected_red_audit(
+            entry, "expected_red_clear_skipped_no_acceptance", msg, test_ids=ids,
         )
+        return MergeEvent(entry, "expected_red_clear_skipped_no_acceptance", msg)
     acceptance_sha = getattr(work, "acceptance_sha", None)
     if acceptance_sha is None or acceptance_sha != entry.branch_head_sha:
         # The recorded trust-gate verdict isn't for the exact commit that
@@ -4486,20 +4552,56 @@ def _maybe_clear_expected_red(entry: QueuedMerge, board, gh_ops: GhOps) -> Merge
         # fresh SHA and this issue's fix merges again... though ordinarily
         # a merge only happens once per issue, so a mismatch here more
         # likely means acceptance was simply never recorded for this SHA.
-        return MergeEvent(
-            entry, "expected_red_clear_skipped",
+        msg = (
             "acceptance_sha does not match the merged commit — skipping "
             "expected_red clear (re-run `coord acceptance record` against "
-            "the merged SHA if entries should have cleared)",
+            "the merged SHA if entries should have cleared)"
         )
+        _record_expected_red_audit(
+            entry, "expected_red_clear_skipped_sha_mismatch", msg,
+            test_ids=_expected_red_ids_for_entry(entry, gh_ops),
+        )
+        return MergeEvent(entry, "expected_red_clear_skipped", msg)
 
-    from coord.acceptance import clear_expected_red_via_pr  # noqa: PLC0415
+    from coord.acceptance import (  # noqa: PLC0415
+        classify_expected_red_clear_result,
+        clear_expected_red_via_pr,
+    )
 
+    # Captured *before* the clear attempt: a successful clear edits the
+    # manifest, so looking this up afterwards would just find the ids the
+    # clear itself just removed (#2266 review non-blocking finding).
+    ids = _expected_red_ids_for_entry(entry, gh_ops)
     msg = clear_expected_red_via_pr(
         entry.repo_github, entry.repo_name, entry.target_branch, entry.issue_number,
         gh_ops=gh_ops,
     )
-    return MergeEvent(entry, "expected_red_clear", msg)
+    # #2266 review (blocking finding 1): a binary "did the message start
+    # with 'cleared expected_red'" conflated a genuine failure with "there
+    # was nothing to clear in the first place" — the *common* case for an
+    # ordinary oracle-loop merge whose issue was never part of a
+    # deliberately-red slice. `classify_expected_red_clear_result` (shared
+    # with the CLI `--clear` path, review blocking finding 2) tells those
+    # apart; the "no_op" case is reported back via `MergeEvent` for `coord
+    # merge` output but never gets a durable audit row — recording one for
+    # every ordinary passing merge would drown the genuinely actionable
+    # `expected_red_clear_failed` rows this audit trail exists to surface.
+    status = classify_expected_red_clear_result(msg)
+    if status == "no_op":
+        return MergeEvent(entry, "expected_red_clear_noop", msg)
+    event_type = {
+        "cleared": "expected_red_clear",
+        "pending_retry": "expected_red_clear_pending",
+        "failed": "expected_red_clear_failed",
+    }[status]
+    # #2266 review (non-blocking finding): `clear_expected_red_via_pr`
+    # never raises — every genuine failure degrades to a "warning: ..."
+    # string. Make that durable too, not just a merge-output line: a
+    # repeated `expected_red_clear_failed` for the same issue is exactly
+    # the signal `coord acceptance expected-red --clear` (the re-fire
+    # path) exists for.
+    _record_expected_red_audit(entry, event_type, msg, test_ids=ids)
+    return MergeEvent(entry, event_type, msg)
 
 
 def process(

{code_coordinator-0.5.94 → code_coordinator-0.5.96}/coord/release_propagate.py

@@ -785,7 +785,29 @@ def assess_quiescence(
     #2228: the interactive-session half is wired from
     ``coord.commands.release._interactive_session_busy``, fed by the same
     fleet-wide tmux sweep ``coord sessions --remote`` renders — until then
-    this half of the seam existed but nothing ever fed it.
+    this half of the seam existed but nothing ever fed it. #2174: the
+    operator-pause half is wired from
+    ``coord.commands.release._paused_machine_busy`` — a machine under an
+    explicit ``coord pause`` or an active quiet-hours window (but NOT a
+    #2101 release cordon: that is this module's own drain mechanism, not a
+    sign a host is already quiescent, and feeding it back in here would
+    make a cordon defer the very roll it exists to unblock) becomes a
+    host-pinned :class:`Busy`. Tmux liveness genuinely has no fleet-wide
+    read (it is a LOCAL fact, #1870, and propagation may run from any
+    host) — pause state does, because it is daemon-aware
+    (``coord.machine_pause``) the same way the board is, so both callers
+    can read it cheaply with no new probe.
+
+    Because a :class:`Busy` carries a host, #2067's per-host quiescence
+    does the obvious thing for a paused NON-daemon host: it defers only
+    that host, and the rest of the fleet still rolls. A paused DAEMON host
+    is different on purpose — the daemon-leads invariant (see the module
+    docstring's LANE ORDER) already defers the WHOLE run whenever the
+    daemon host is itself busy and behind, and a pause is just one more
+    way for the daemon host to be busy. So ``coord pause <daemon-host>``
+    halting all propagation, not just that host's own lane, is read as the
+    correct interpretation of "leave this box alone" applied to the one
+    host every other host's roll depends on — not an emergent accident.
 
     #2110: a ``running`` queue row is not, on its own, proof of anything —
     the reconciler that would have moved it to ``done`` lives inside