code-coordinator 0.5.58__tar.gz → 0.5.59__tar.gz

{code_coordinator-0.5.58/code_coordinator.egg-info → code_coordinator-0.5.59}/PKG-INFO

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

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

@@ -1,7 +1,7 @@
 {
-  "tag": "0.5.58",
+  "tag": "0.5.59",
   "distance": 0,
-  "node": "g36b37b343666fd25278ef49e2b4521e94ec1a50a",
+  "node": "g3cb11f81fa08e124d66859415a0b01368d4da64a",
   "dirty": false,
   "branch": "HEAD",
   "node_date": "2026-08-13"

{code_coordinator-0.5.58 → code_coordinator-0.5.59}/coord/acceptance.py

@@ -574,6 +574,16 @@ def expected_red_failure_summary(verdict: dict[str, Any]) -> str:
     can't mistake this for "a test failed" — it is the opposite signal, and
     the fix is editorial (clear the manifest entry, or realize the
     assertion never exercised the bug), not code.
+
+    #2199: the guidance below used to send the operator to `coord
+    acceptance record`, on the claim that a green trust-gate run clears the
+    entry automatically. PR #2173 deliberately moved clearing OUT of
+    `record` and into the post-merge hook (`coord.merge_queue.
+    _maybe_clear_expected_red` / `coord.acceptance.
+    clear_expected_red_via_pr`, right after the fix's own PR actually
+    merges — see that function's docstring for the ordering bug this
+    fixed). Re-running `record` today clears nothing; an operator who
+    followed the old wording would watch it not work with no clue why.
     """
     ids = verdict.get("unexpected_green") or []
     if not ids:
@@ -583,10 +593,15 @@ def expected_red_failure_summary(verdict: dict[str, Any]) -> str:
         f"HARD FAILURE: {len(ids)} test(s) listed in `expected_red` now PASS:\n"
         f"{listed}\n"
         "An expected-red test that passes means either the fix already "
-        "landed silently (clear it — `coord acceptance record` does this "
-        "automatically on a green trust-gate run) or the assertion never "
-        "exercised the bug in the first place (#1965). This is NOT an "
-        "ordinary test failure — it is the opposite signal."
+        "landed silently — it clears automatically once ITS OWN PR actually "
+        "merges (the post-merge hook, not `coord acceptance record`; see "
+        "docs/ORACLE_LOOP.md). Still listed after that merge? Check `coord "
+        "merge`'s own output for an `expected_red_clear_skipped*` event "
+        "naming why (no work assignment found, no passing trust-gate "
+        "verdict recorded, or a stale acceptance SHA), or run `coord "
+        "acceptance expected-red <repo>` to see current state — or the "
+        "assertion never exercised the bug in the first place (#1965). "
+        "This is NOT an ordinary test failure — it is the opposite signal."
     )
 
 

{code_coordinator-0.5.58 → code_coordinator-0.5.59}/coord/drive.py

@@ -288,6 +288,35 @@ class DriveCounters:
     # capture deserves its own full budget of cheap waits before the next
     # forced retry.
     gate_wait_rounds: int = 0
+    # #2199: bounded retry for the trust gate's OWN dispatch — distinct from
+    # `fix_rounds` (which bounds "the work needs another round" once a
+    # verdict, passed or failed, actually landed on the board). This counts
+    # attempts where `coord acceptance record` itself never got that far —
+    # a missing local checkout, a driver crash, GitHub unreachable — so a
+    # persistently broken environment reaches a named `_die()` instead of
+    # `coord drive` re-running a full git-worktree + suite invocation every
+    # poll forever. Bounded by `opts.max_work_retries`, the same "how many
+    # times do we retry a flaky infra thing" budget `work_retries` uses.
+    #
+    # #2199 review (blocking finding 1): scoped to ONE sha via
+    # `acceptance_gate_attempts_sha` below — NOT a lifetime total. A fresh
+    # SHA (a fix round pushing a new commit) legitimately needs its own
+    # dispatch, and that dispatch is the entire point of the "same shape as
+    # `_decide_test`'s fix loop" design a few lines up in
+    # `_decide_acceptance_gate`; sharing one un-reset counter across every
+    # SHA a drive ever sees meant the SECOND round after the FIRST fix round
+    # already exhausted the default `max_work_retries=1` budget and died
+    # with a false "environment broken" diagnosis — even though the trust
+    # gate was working exactly as designed (quadraui#542's actual shape:
+    # one fix round, then this).
+    acceptance_gate_attempts: int = 0
+    # #2199 review: the SHA `acceptance_gate_attempts` above is counting
+    # dispatch attempts FOR. `_decide_acceptance_gate` resets the counter to
+    # 0 whenever it sees a SHA that doesn't match this — a fresh commit (a
+    # fix round, a rebase) always gets its own full attempt budget, and only
+    # repeated failures to produce ANY verdict for the SAME commit reach
+    # `_die()`.
+    acceptance_gate_attempts_sha: str = ""
     # #2079: a SECOND, independent budget of exactly the same shape, spent
     # only on landing the oracle-mode JIT acceptance slice
     # (`_decide_acceptance_landing`). Separate rather than shared because the
@@ -375,6 +404,14 @@ class AcceptanceGateChecker(Protocol):
 
     def resolve_for_path(self, repo_name: str, milestone_number: int) -> str | None: ...
 
+    def is_issue_exempt(
+        self,
+        repo_name: str,
+        milestone_number: int,
+        issue_number: int,
+        issue_labels: tuple[str, ...],
+    ) -> bool: ...
+
 
 @dataclass
 class GitHubAcceptanceGateChecker:
@@ -412,6 +449,34 @@ class GitHubAcceptanceGateChecker:
             return None
         return resolve_for_path(self.config, repo_cfg, milestone_number)
 
+    def is_issue_exempt(
+        self,
+        repo_name: str,
+        milestone_number: int,
+        issue_number: int,
+        issue_labels: tuple[str, ...],
+    ) -> bool:
+        """#2199: does *issue_number* opt out of the sealed suite — the
+        SAME ``manifest.exempt`` list / ``oracle:exempt`` label the #1138
+        hard gate (:func:`coord.milestone_dispatch.issue_oracle_ready`)
+        already reads. Reused rather than re-derived so the JIT-authoring
+        gate and the #2199 trust gate can never disagree about which
+        issues the oracle loop covers — see that function's own docstring
+        for why ``exempt`` says "doesn't consume the sealed suite" and
+        nothing about Gate A sign-off (already established True by the
+        time :func:`resolve_oracle_decision` calls this).
+        """
+        from coord.milestone_dispatch import issue_oracle_ready  # noqa: PLC0415
+
+        repo_cfg = self.config.repo(repo_name)
+        if repo_cfg is None:
+            return False
+        readiness = issue_oracle_ready(
+            repo_cfg, self.config, milestone_number, issue_number,
+            issue_labels=issue_labels,
+        )
+        return readiness.exempt
+
 
 @dataclass(frozen=True)
 class OracleDecision:
@@ -424,11 +489,23 @@ class OracleDecision:
     to guess which mode a run is in. ``tracking_issue`` is set iff ``active``
     — the argument :func:`_decide_acceptance_author` needs to build ``coord
     acceptance author <repo> <tracking_issue> --issue <N>``.
+
+    #2199: ``issue_exempt`` — resolved alongside ``active`` (same one-shot
+    GitHub fetch budget: ``AcceptanceGateChecker.is_issue_exempt`` reuses the
+    #1138 hard gate's own manifest read) — is *this issue*'s
+    ``manifest.exempt``/``oracle:exempt`` opt-out from the sealed suite.
+    :func:`_decide_acceptance_gate` (the trust gate) skips entirely when
+    this is ``True``: an exempt issue has no authored slice for `coord
+    acceptance record` to re-run, so treating its absence as a red verdict
+    would be exactly the "acquire a new blocking gate it never opted into"
+    regression #2199's acceptance criteria rule out. Always ``False`` when
+    ``active`` is ``False`` — meaningless outside the oracle loop.
     """
 
     active: bool
     reason: str
     tracking_issue: int | None = None
+    issue_exempt: bool = False
 
 
 def resolve_oracle_decision(
@@ -488,6 +565,13 @@ def resolve_oracle_decision(
             f"acceptance mock {state.repo} {state.milestone_tracking_issue}` "
             "first for the oracle loop, docs/ORACLE_LOOP.md)",
         )
+    # #2199: resolved here, alongside everything else `resolve_oracle_decision`
+    # already settles once per run — see `OracleDecision.issue_exempt`'s
+    # docstring for why the trust gate needs this and why it must reuse
+    # (not re-derive) the #1138 hard gate's own exemption check.
+    issue_exempt = gate_checker.is_issue_exempt(
+        state.repo, state.milestone_number, state.issue, state.issue_labels,
+    )
     return OracleDecision(
         True,
         f"ORACLE DRIVE — ms-{state.milestone_number}'s Gate-A contract is "
@@ -496,6 +580,7 @@ def resolve_oracle_decision(
         f"{state.milestone_tracking_issue} --issue {state.issue}`) before "
         "dispatching work",
         tracking_issue=state.milestone_tracking_issue,
+        issue_exempt=issue_exempt,
     )
 
 
@@ -851,12 +936,14 @@ def _acceptance_message(message: str, state: IssueState) -> str:
 
 
 class MergeVerifier(Protocol):
-    """The two git/GitHub questions the state machine cannot answer itself."""
+    """The git/GitHub questions the state machine cannot answer itself."""
 
     def branch_has_commits(self, state: IssueState) -> bool: ...
 
     def verify_merged(self, state: IssueState) -> bool: ...
 
+    def branch_head_sha(self, state: IssueState) -> str | None: ...
+
 
 @dataclass
 class GitMergeVerifier:
@@ -965,6 +1052,23 @@ class GitMergeVerifier:
         finally:
             self._git(base, "update-ref", "-d", vref)
 
+    def branch_head_sha(self, state: IssueState) -> str | None:
+        """The exact commit `coord acceptance record --sha` (#2199) must be
+        pointed at — the trust gate re-runs the sealed suite against a
+        precise SHA, never a branch name that could move under a slow
+        drive loop. GitHub API, not a local checkout: same reasoning as
+        :meth:`verify_merged`'s primary path — authoritative for every
+        machine this driver might run on, no ``~/src/<repo>`` clone
+        required. Returns ``None`` (never raises) when the branch is gone
+        or GitHub is unreachable; callers treat that as "try again next
+        poll", never as a verdict.
+        """
+        if not state.work_branch or not state.repo_github:
+            return None
+        from coord import github_ops  # noqa: PLC0415
+
+        return github_ops.get_branch_sha(state.repo_github, state.work_branch)
+
 
 # ── preflight (pure) ─────────────────────────────────────────────────────────
 
@@ -1326,6 +1430,22 @@ def decide(
             _escalate_dead_end(state, dead_end), warnings=warnings
         )
 
+    # #2199: the oracle loop's TRUST GATE — docs/ORACLE_LOOP.md Phase-1 step
+    # 6, right here between the dead-end predicate and the Test gate,
+    # because this is the first point `coord drive` has observed the work
+    # assignment's branch head AFTER push. Before this, nothing ever called
+    # `coord acceptance record`: an issue driven end-to-end by `coord drive`
+    # completed with `acceptance_state = None` forever, so the sealed suite
+    # was never re-run externally and `_maybe_clear_expected_red` could
+    # never clear (quadraui#542).
+    acceptance_gate = _decide_acceptance_gate(
+        state, opts, counters, machine, oracle, verifier, gate_checker
+    )
+    if acceptance_gate is not None:
+        return replace(
+            acceptance_gate, warnings=warnings + acceptance_gate.warnings
+        )
+
     test = _decide_test(state, opts, counters, machine)
     if test is not None:
         return replace(test, warnings=warnings + test.warnings)
@@ -1467,6 +1587,161 @@ def _decide_advisory(
     )
 
 
+def _decide_acceptance_gate(
+    state: IssueState,
+    opts: DriveOptions,
+    counters: DriveCounters,
+    machine: str,
+    oracle: OracleDecision | None,
+    verifier: MergeVerifier,
+    gate_checker: AcceptanceGateChecker | None,
+) -> Action | None:
+    """The #2199 oracle-loop TRUST GATE — ``coord acceptance record --repo
+    R --issue N --sha <pushed sha>``, run by the COORDINATOR (this process,
+    never inside the worker's own session) against the exact commit the
+    work assignment pushed. docs/ORACLE_LOOP.md's Phase-1 step 6, and the
+    reason it exists: a headless worker's in-session "green" claim
+    (``coord acceptance run``, Phase-1 step 5) can lie; it cannot fake the
+    coordinator re-running the sealed suite itself. ``None`` means "not
+    applicable, or already resolved for this SHA — fall through to Test".
+
+    Before #2199 NOTHING ever called this — an issue driven end-to-end by
+    ``coord drive`` completed with ``acceptance_state = None`` forever, so
+    ``coord.merge_queue._maybe_clear_expected_red`` could never clear an
+    ``expected_red`` entry either (quadraui#542, quadraui#492).
+
+    Only fires when ``oracle.active`` (a driver-configured repo, an issue
+    in a milestone whose Gate-A contract is merged — the same condition
+    that gated JIT-slice authoring) AND this issue is not
+    ``oracle.issue_exempt`` (``manifest.exempt`` / the ``oracle:exempt``
+    label — an issue that never consumed the sealed suite has nothing for
+    ``record`` to re-run, so gating on its absence would be a NEW blocking
+    gate an exempt issue never opted into, exactly what #2199's acceptance
+    criteria rule out). Every other issue — no driver, no milestone,
+    ``--no-acceptance`` — passes straight through unchanged.
+
+    *gate_checker* (#2199 review, blocking finding 3): resolves
+    ``--for-path`` for a ROUTED repo (``acceptance.drivers.<repo>.routes``)
+    exactly like :func:`_decide_acceptance_author` already does — without
+    it, ``coord commands/acceptance.py``'s ``_resolve_driver`` hard-refuses
+    every dispatch on a routed repo with "no route matched", so the trust
+    gate silently never functioned there at all.
+    """
+    if oracle is None or not oracle.active or oracle.issue_exempt:
+        return None
+    assert gate_checker is not None, (
+        "oracle.active implies resolve_oracle_decision ran with a real "
+        "gate_checker; decide() always threads one through"
+    )
+
+    sha = verifier.branch_head_sha(state)
+    if sha is None:
+        # GitHub unreachable or the branch vanished between polls — don't
+        # let a transient lookup block a whole drive run; retry next poll.
+        return _wait(label="ACCEPTANCE: waiting to resolve the pushed SHA")
+
+    if state.work_acceptance_sha == sha:
+        if state.work_acceptance_state == "passed":
+            return None  # trust gate already green for this exact commit
+        if state.work_acceptance_state == "failed":
+            # Same shape as a failed Test verdict (#2199 acceptance: "a
+            # failed trust gate must block, not warn ... at the same place
+            # a failed Test verdict does") — a bounded fix-round retry,
+            # sharing the ONE fix budget `_decide_test` also spends from
+            # (#1692: a failed test and a failed trust gate are two shapes
+            # of the same "the work needs another round" loop).
+            if counters.fix_rounds >= opts.max_fix_rounds:
+                return _die(
+                    f"acceptance trust gate still failing after "
+                    f"{counters.fix_rounds} fix round(s) at {sha} — "
+                    "stopping.\n"
+                    f"   Reason: {state.work_acceptance_reason or 'none recorded'}\n"
+                    f"   Inspect: coord log {state.work_aid} --machine "
+                    f"{state.work_machine or machine}"
+                )
+            counters.fix_rounds += 1
+            return Action(
+                kind=RUN,
+                label=(
+                    "ACCEPTANCE: trust gate failed → fix round "
+                    f"{counters.fix_rounds}/{opts.max_fix_rounds} "
+                    f"(coord fix {state.work_aid})"
+                ),
+                command=("fix", state.work_aid),
+                error_message=(
+                    f"coord fix {state.work_aid} failed to dispatch after a "
+                    "failed acceptance trust gate."
+                ),
+            )
+
+    # No verdict recorded yet for this exact SHA — never run, or run
+    # against a now-stale one (a fix round, a rebase). Dispatch it.
+    #
+    # #2199 review (blocking finding 1): `acceptance_gate_attempts` is
+    # scoped to THIS sha, not a lifetime total — a fresh SHA (this branch
+    # runs again after a fix round pushed a new commit) gets its own full
+    # attempt budget. Without this reset, the legitimate re-dispatch for
+    # SHA2 inherited SHA1's already-spent count and died immediately with a
+    # false "environment broken" diagnosis on exactly the second round the
+    # docstring above says this mirrors `_decide_test` for.
+    if counters.acceptance_gate_attempts_sha != sha:
+        counters.acceptance_gate_attempts = 0
+        counters.acceptance_gate_attempts_sha = sha
+
+    # `on_error="warn"` is deliberate: `coord acceptance record` exits
+    # non-zero BOTH when it successfully records a red verdict (the board
+    # write already happened before it exits — the next poll's
+    # `work_acceptance_state == "failed"` branch above is what actually
+    # bounces to Fix) and when it errors out before ever reaching a verdict
+    # (no local checkout, a driver crash, a git fetch failure). Raising
+    # `DriveError` here on either would turn a routine red trust-gate round
+    # into a terminal drive failure — exactly the "must block [via Fix],
+    # not warn" the acceptance criteria ask for, achieved one poll later by
+    # observation rather than by inspecting this exit code directly.
+    if counters.acceptance_gate_attempts >= opts.max_work_retries:
+        return _die(
+            f"acceptance trust gate never produced a verdict for {sha} "
+            f"after {counters.acceptance_gate_attempts} attempt(s) — "
+            "`coord acceptance record` keeps failing before recording "
+            "anything (checkout/driver/environment problem, not a red "
+            "suite).\n"
+            f"   Inspect: coord acceptance record --repo {state.repo} "
+            f"--issue {state.issue} --sha {sha}"
+        )
+    counters.acceptance_gate_attempts += 1
+
+    # #2199 review (blocking finding 3): resolve `--for-path` exactly like
+    # `_decide_acceptance_author` does — a routed repo's `_resolve_driver`
+    # (coord/commands/acceptance.py) hard-refuses with "no route matched"
+    # when it's omitted, which made the trust gate structurally unable to
+    # ever record a verdict for such a repo.
+    from coord.acceptance import ForPathResolutionError  # noqa: PLC0415
+
+    try:
+        for_path = gate_checker.resolve_for_path(state.repo, state.milestone_number)
+    except ForPathResolutionError as exc:
+        return _die(
+            f"could not resolve --for-path for {state.repo}'s acceptance "
+            f"trust gate on #{state.issue}: {exc}"
+        )
+    command = [
+        "acceptance", "record", "--repo", state.repo, "--issue",
+        str(state.issue), "--sha", sha,
+    ]
+    if for_path:
+        command += ["--for-path", for_path]
+
+    return Action(
+        kind=RUN,
+        label=(
+            "ACCEPTANCE: trust gate → coord acceptance record --sha "
+            f"{sha[:12]}" + (f" --for-path {for_path}" if for_path else "")
+        ),
+        command=tuple(command),
+        on_error="warn",
+    )
+
+
 def _decide_test(
     state: IssueState,
     opts: DriveOptions,

{code_coordinator-0.5.58 → code_coordinator-0.5.59}/coord/drive_state.py

@@ -84,6 +84,20 @@ class IssueState:
     work_review_iter: int = 0
     work_exit_code: int | None = None
     work_failure_reason: str = ""
+    # #2199: the trust-gate verdict `coord acceptance record --issue N --sha
+    # <sha>` writes onto THIS issue's own `work` row (see `coord.state.
+    # record_acceptance_verdict` — the same field `coord.merge_queue.
+    # _maybe_clear_expected_red` already reads via `getattr(work,
+    # "acceptance_state", None)`). "" | "passed" | "failed" — "" means no
+    # verdict has ever been recorded for this work row, which is exactly
+    # the ambiguity #2199 exists to resolve: nothing used to write this at
+    # all, so it was indistinguishable from "the gate ran and lied clean".
+    # `work_acceptance_sha` is the commit the last verdict was recorded
+    # against — a fresh push (fix round, rebase) invalidates it the same
+    # way `review_head_sha` invalidates a stale review approval.
+    work_acceptance_state: str = ""
+    work_acceptance_reason: str = ""
+    work_acceptance_sha: str = ""
 
     review_aid: str = ""
     review_status: str = ""
@@ -141,6 +155,12 @@ class IssueState:
     # member of any tracked work order — the "normal drive" case.
     milestone_number: int | None = None
     milestone_tracking_issue: int | None = None
+    # #2199: this issue's own GitHub labels — resolved from the same
+    # `/board` `issues` row `milestone_number` is (no extra I/O). Threaded
+    # through so `resolve_oracle_decision` can resolve per-issue
+    # `oracle:exempt`/`manifest.exempt` opt-out for the trust gate
+    # (`AcceptanceGateChecker.is_issue_exempt`) without a second board scan.
+    issue_labels: tuple[str, ...] = ()
 
     # The JIT slice's own `type="test-author"` assignment (#1171: keyed on
     # `for_issue_number == issue`, NOT `issue_number` — that field is the
@@ -224,6 +244,12 @@ class IssueState:
                 self.work_aid,
                 self.work_status,
                 self.work_test_state,
+                # #2199: the trust gate's own verdict is a real transition
+                # the same way work_test_state is — see the docstring above
+                # for why omitting an analogous field mutes the `state:`
+                # log line and fools the stall detector.
+                self.work_acceptance_state,
+                self.work_acceptance_sha,
                 self.work_review_state,
                 self.work_review_iter,
                 self.review_status,
@@ -402,6 +428,9 @@ def project(payload: dict, repo: str, issue: int, config: Any) -> IssueState:
         work_review_iter=int(g(work, "review_iteration", 0) or 0),
         work_exit_code=None if exit_code is None else int(exit_code),
         work_failure_reason=g(work, "failure_reason"),
+        work_acceptance_state=g(work, "acceptance_state"),
+        work_acceptance_reason=g(work, "acceptance_reason"),
+        work_acceptance_sha=g(work, "acceptance_sha"),
         review_aid=g(review, "assignment_id"),
         review_status=g(review, "status"),
         review_verdict=g(review, "review_verdict"),
@@ -421,6 +450,7 @@ def project(payload: dict, repo: str, issue: int, config: Any) -> IssueState:
         picked_machine_no_capable=_machine_pick.no_capable_machine,
         milestone_number=milestone_number,
         milestone_tracking_issue=milestone_tracking_issue,
+        issue_labels=tuple(issue_labels),
         # #2024: the per-issue Test-stage policy, off the labels already read
         # above (no extra I/O). `test_mode_from_labels` is the same function
         # `coord.state._get_issue_test_mode_local` uses, so the driver and the

{code_coordinator-0.5.58 → code_coordinator-0.5.59}/coord/merge_queue.py

@@ -3835,6 +3835,42 @@ def _work_assignment_for_entry(entry: QueuedMerge, board) -> Assignment | 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.
+
+    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.
+    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
+
+    try:
+        found = find_ms_manifest_for_issue_via_api(
+            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
+    if found is None:
+        return False
+    _path, _text, _blob_sha, data = found
+    return bool(data.expected_red.get(entry.issue_number))
+
+
 def _maybe_clear_expected_red(entry: QueuedMerge, board, gh_ops: GhOps) -> MergeEvent | None:
     """#2164: right after *entry*'s PR has actually merged into
     ``entry.target_branch``, clear any of its issue's ``expected_red``
@@ -3843,17 +3879,52 @@ def _maybe_clear_expected_red(entry: QueuedMerge, board, gh_ops: GhOps) -> Merge
     wrong (clearing at record-time, before the merge that's the whole
     point had actually happened; see ``coord.acceptance.
     clear_expected_red_via_pr``'s docstring). Returns ``None`` when there
-    is nothing to do (not a `work` entry, no recorded acceptance, or no
-    acceptance verdict at all — the overwhelmingly common case), else a
-    ``MergeEvent`` describing what happened. Never raises — every failure
+    is nothing to do (not a `work` entry, or this issue was never in scope
+    for the oracle trust gate at all) — every other skip path names itself
+    with its own ``MergeEvent`` (see below), so ``coord merge`` output
+    never implies a clear that didn't happen. Never raises — every failure
     mode inside ``clear_expected_red_via_pr`` degrades to a message, and
     this wrapper's own lookups are read-only/best-effort.
+
+    #2199 review: before the trust gate had a call site at all
+    (``coord acceptance record`` was never invoked by anything —
+    ``getattr(work, "acceptance_state", None) != "passed"`` was the
+    UNIVERSAL case), this branch returned bare ``None`` — silently. An
+    ``expected_red`` entry could then never clear, indistinguishable from
+    #1965's genuine vacuous-assertion alarm (quadraui#542). Now it names
+    which condition failed instead — but ONLY for an issue actually in
+    scope for the oracle loop (:func:`_issue_has_expected_red_entries`,
+    #2199 review finding 2): the first cut of this fix regressed to
+    printing that same loud, actionable-looking text on every ordinary
+    merge fleet-wide, contradicting the acceptance criterion that exempt
+    issues and driverless repos stay unaffected.
     """
     if entry.assignment_type not in CLOSES_ISSUE_TYPES:
         return None
     work = _work_assignment_for_entry(entry, board)
-    if work is None or getattr(work, "acceptance_state", None) != "passed":
-        return None
+    if work is None:
+        return MergeEvent(
+            entry, "expected_red_clear_skipped_no_work",
+            "no `work` assignment found for this merge entry — cannot read "
+            "an acceptance verdict; skipping expected_red clear",
+        )
+    acceptance_state = getattr(work, "acceptance_state", None)
+    if acceptance_state != "passed":
+        if not _issue_has_expected_red_entries(entry, gh_ops):
+            # 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",
+            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.",
+        )
     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