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

{code_coordinator-0.5.58 → code_coordinator-0.5.60}/CLAUDE.md

@@ -100,6 +100,16 @@ coord approve --dry-run 1,2
 coord assign --dry-run precision claude-coordinator 42
 ```
 
+**Workers: scope your test run to your diff, never `pytest` bare (#2169).**
+The full suite exceeds Claude Code's 600s Bash ceiling on this repo and
+duplicates the Test stage + CI, which both run it against your pushed SHA
+regardless. Run just the file(s) that mirror what you changed — `pytest
+tests/test_<module>.py` for a `coord/<module>.py` change, `cargo test` from
+`tui/` scoped with a test-name filter for a `tui/**` change. To see what
+the Test stage itself would run for your diff (and confirm you're not
+missing a suite), `scripts/coord-test-runner.sh <worktree> --print-routing`
+computes the routing without actually building or testing anything.
+
 ## Key Design Decisions
 
 - **No API key needed.** Everything uses `claude -p` which runs on Max/Pro subscription via OAuth.

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

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: code-coordinator
-Version: 0.5.58
+Version: 0.5.60
 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.60}/code_coordinator.egg-info/SOURCES.txt

@@ -720,6 +720,7 @@ tests/test_watch.py
 tests/test_worker_events.py
 tests/test_worker_image_pin_sync.py
 tests/test_worker_safety.py
+tests/test_worker_test_scoping.py
 tests/test_worktree.py
 tests/test_worktree_rmtree_chokepoint.py
 tests/acceptance/ms-33/audit_1039.rs

{code_coordinator-0.5.58 → code_coordinator-0.5.60}/code_coordinator.egg-info/scm_file_list.json

@@ -750,6 +750,7 @@
     "tests/test_worker_events.py",
     "tests/test_worker_image_pin_sync.py",
     "tests/test_worker_safety.py",
+    "tests/test_worker_test_scoping.py",
     "tests/test_worktree.py",
     "tests/test_worktree_rmtree_chokepoint.py",
     "tui/Cargo.lock",

{code_coordinator-0.5.58 → code_coordinator-0.5.60}/code_coordinator.egg-info/scm_version.json

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

{code_coordinator-0.5.58 → code_coordinator-0.5.60}/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.60}/coord/agent.py

@@ -2845,9 +2845,17 @@ This session is ONE-SHOT and non-interactive (#1394):
 completion notifications will NEVER reach you — nothing wakes you up.
 - NEVER start a long-running command in the background and then end your \
 turn waiting for it (no `run_in_background`, no `&`, no "I'll wait for the \
-test run to finish"). Run it in the FOREGROUND and block until it returns, \
-or raise the timeout, or skip it and say so. If you end your turn waiting, \
-the session is over and your work is thrown away.
+test run to finish") — there is no next turn for a notification to land \
+in, so ending your turn that way throws the work away. Prefer running it \
+in the FOREGROUND and blocking until it returns. If it genuinely cannot \
+finish inside one Bash call, you may background it and poll it yourself, \
+in bounded steps, from THIS SAME still-running session — `Monitor`, or \
+repeated `TaskOutput` calls with a bounded `timeout`, never a foreground \
+loop that blocks past the ceiling (`until ! pgrep ...; do sleep ...; done` \
+hits the identical 600s wall) and never a final message that leaves it \
+running unattended and relies on being woken back up. Otherwise, raise the \
+timeout or skip it and say so. If you end your turn waiting, the session \
+is over and your work is thrown away.
 - ALWAYS `git add`, `git commit`, and `git push origin HEAD` BEFORE your \
 final message — even if the build is broken, the tests are failing, or you \
 ran out of time. Uncommitted changes are destroyed when the session ends. \
@@ -2883,8 +2891,25 @@ intentional `#[allow]` with reason, a deferred refactor flagged \
 elsewhere), explicitly call it out in your final message with the \
 reason. Don't silently ship warnings.
 - Re-run the build after fixes to confirm clean output.
-- Run the project's test command (`cargo test`, `pytest`, etc.) and \
-confirm it passes before declaring done.
+- Run only the tests that cover your diff — never the project's whole \
+test suite. A full suite routinely exceeds this tool's 600-second Bash \
+ceiling, and a worker that tries to shepherd it past that wall (splitting \
+it into chunks, backgrounding it and blocking on a poll loop, ...) burns \
+most of a session on that instead of the fix, for no net-new signal: the \
+Test stage and CI both re-run the FULL suite against your pushed SHA right \
+after you, on a clean checkout, which is strictly better evidence than a \
+worker's own partial run (#2169). Find the test file(s)/module(s) whose \
+name or path mirrors what you changed (e.g. `tests/test_<module>.py` for \
+`coord/<module>.py`, the crate-local `#[cfg(test)]` block for a Rust file) \
+and run just those — confirm they pass before declaring done.
+- Exception: if this assignment IS an oracle-loop acceptance round (you \
+were told to run `coord acceptance run --issue N`), keep running that \
+sealed slice as many times as it takes to go green. It is the loop's \
+convergence signal, not duplicated effort, and the scoping rule above does \
+not apply to it.
+- If even the scoped run genuinely cannot finish in time, follow the \
+background-and-poll pattern in the ONE-SHOT section above — do not invent \
+a chunk-and-loop workaround.
 
 #252: before exiting, emit a SMOKE_TESTS block telling the human what to \
 manually verify.  You changed the code; you know what's worth poking.
@@ -3668,7 +3693,13 @@ def default_worker_command(spec: AssignmentSpec, *, binary: str = DEFAULT_WORKER
     else:
         system_prompt = spec.system_prompt if spec.system_prompt else WORKER_SYSTEM_PROMPT
         system_prompt += build_deny_prompt(spec.deny_commands)
-        allowed_tools = "Read,Edit,Write,Bash"
+        # #2169: `Monitor` is the sanctioned way to poll a backgrounded
+        # long-running command in bounded steps (see the ONE-SHOT section of
+        # WORKER_SYSTEM_PROMPT) instead of a foreground loop that blocks
+        # past the 600s Bash ceiling. `TaskOutput`/`TaskStop` were already
+        # reachable without being in this list; `Monitor` was the one
+        # observed denied.
+        allowed_tools = "Read,Edit,Write,Bash,Monitor"
 
     # NOTE: briefing is NOT passed as a positional arg — it is written to
     # stdin as the first stream-json user message by ``_spawn``.

{code_coordinator-0.5.58 → code_coordinator-0.5.60}/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.60}/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