code-coordinator 0.5.542__tar.gz → 0.5.544__tar.gz

{code_coordinator-0.5.542 → code_coordinator-0.5.544}/PKG-INFO

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

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

@@ -1,7 +1,7 @@
 {
-  "tag": "0.5.542",
+  "tag": "0.5.544",
   "distance": 0,
-  "node": "gdf0736aada6feb22b04725dbc54d5aec689a1da6",
+  "node": "g9d671b639715e489d153691e9b55302116326817",
   "dirty": false,
   "branch": "HEAD",
   "node_date": "2026-09-30"

{code_coordinator-0.5.542 → code_coordinator-0.5.544}/coord/commands/milestone.py

@@ -25,8 +25,10 @@ from coord.milestone_dispatch import (
     MilestoneDispatchError,
     dispatch_entry,
     fetch_milestone_context,
+    gate_a_probe,
     gate_a_status,
     is_milestone_complete,
+    milestone_oracle_loop,
     pick_machine,
     plan_dispatch,
     plan_queue,
@@ -1106,11 +1108,16 @@ def milestone_dispatch_cmd(
     # #2542: under oracle-loop control (Gate A already checked above), chain
     # the whole milestone's drive-queue entries so the tick can never launch
     # two of them at once — see plan_queue's own docstring for why.
+    # #2785: resolved per milestone via `milestone_oracle_loop`, not the
+    # repo-level `has_driver` alone. `block_reason` above already confirms
+    # this milestone's Gate-A contract exists (we'd have exited otherwise).
     queue_plan = plan_queue(
         ctx.work_order,
         ctx.terminal_issues,
         repo_entry.name,
-        oracle_loop=cfg.acceptance.has_driver(repo_entry.name),
+        oracle_loop=milestone_oracle_loop(
+            repo_entry, cfg, gate_a_satisfied=block_reason is None
+        ),
     )
 
     if not queue_plan:
@@ -1318,10 +1325,26 @@ def milestone_drive_cmd(
     # #2542: pass the same `oracle_loop` the gate tick itself will use, so
     # this preview never shows more than the one entry the actual `work`
     # gate would dispatch for an oracle-loop milestone.
+    # #2785: resolved per milestone via `milestone_oracle_loop`, not the
+    # repo-level `has_driver` alone.
+    #
+    # #2785 review (non-blocking): reads the DURABLE `record.cleared` (has
+    # GATE_A already been stamped as cleared for this milestone?) rather
+    # than `probes.gate_a_blocked` — that field is a fresh live Gate-A
+    # re-probe (`probe_milestone`'s own docstring), and folding a single
+    # transient read failure there straight into `gate_a_satisfied=False`
+    # would cosmetically over-show this preview's ready frontier for one
+    # invocation. `_milestone_gate_tick`'s WORK-state dispatch (the thing
+    # this preview mirrors) already made this same durable-vs-live switch
+    # for the identical reason — matching it here keeps the preview and the
+    # actual tick reading the same signal instead of two that can flap
+    # independently.
     if ctx.work_order.nodes:
         plan = plan_dispatch(
             ctx.work_order, board, cfg, repo_entry, ctx.terminal_issues,
-            oracle_loop=cfg.acceptance.has_driver(repo_entry.name),
+            oracle_loop=milestone_oracle_loop(
+                repo_entry, cfg, gate_a_satisfied=mg.GATE_A in record.cleared
+            ),
         )
         to_dispatch, skipped, waiting, deferred = (
             plan.to_dispatch, plan.skipped, plan.waiting, plan.deferred,
@@ -1501,9 +1524,39 @@ def milestone_write_order_cmd(
     # (coord-portal#122). Cheap/early check for the explicit-group case only
     # — see validate_no_shared_oracle_group's docstring for what it can't
     # catch.
+    #
+    # #2785: resolved PER MILESTONE via `milestone_oracle_loop` — NOT
+    # `cfg.acceptance.has_driver(repo_entry.name)` alone, which is true for
+    # every milestone in a repo that has ever declared ANY acceptance
+    # driver and so wrongly refused #1949's (ms-60's) work order, which
+    # shares no manifest with anything since ms-60 has no
+    # `tests/acceptance/ms-60/` at all. No other Gate-A probe has run yet in
+    # this command, so resolve one fresh via `gate_a_probe` — the same
+    # existence check `coord milestone dispatch` performs.
+    #
+    # #2785 review: unlike `milestone_dispatch_cmd`/`milestone_drive_cmd`,
+    # this command must NOT abort on a *confirmed*-absent contract — ms-60
+    # has no contract at all and that is exactly the correctly-permissive
+    # case (`gate_a_satisfied=False` -> `oracle_loop=False` -> shared groups
+    # allowed), the whole point of this issue. Only a *transient* read
+    # failure (`GateAResult.transient`, #2973's tri-state) must abort:
+    # folding it into `gate_a_satisfied=False` would silently disable the
+    # shared-group refusal for a milestone that may well be oracle-loop-
+    # controlled, purely because of ordinary GitHub flakiness — the #2785
+    # review's blocking finding. `gate_a_status`'s plain `str | None` can't
+    # tell the two apart, so this uses `gate_a_probe` directly.
+    probe = gate_a_probe(repo_entry, cfg, milestone_number)
+    if probe.transient:
+        click.echo(f"error: {probe.block_reason}", err=True)
+        sys.exit(1)
+
     try:
         validate_no_shared_oracle_group(
-            work_order, oracle_loop=cfg.acceptance.has_driver(repo_entry.name)
+            work_order,
+            oracle_loop=milestone_oracle_loop(
+                repo_entry, cfg,
+                gate_a_satisfied=probe.block_reason is None,
+            ),
         )
     except WorkOrderError as e:
         click.echo(f"error: {e}", err=True)

{code_coordinator-0.5.542 → code_coordinator-0.5.544}/coord/drive.py

@@ -2405,6 +2405,7 @@ def decide(
     machine: str = "",
     oracle: OracleDecision | None = None,
     gate_checker: AcceptanceGateChecker | None = None,
+    reread_state: Callable[[], IssueState | None] | None = None,
 ) -> Action:
     """One step of the state machine: given the board, what next?
 
@@ -2420,6 +2421,20 @@ def decide(
     to ``coord assign``. *gate_checker* is only consulted when *oracle* is
     active (to resolve a routed repo's ``--for-path``, #1453 review finding
     1) — unused, like *oracle*, on every pre-#1453 call site.
+
+    *reread_state* (#2304) is the dead-end predicate's confirmation read.
+    ``detect_dead_end`` judges a single snapshot, and shape 1
+    (``review_terminal_no_verdict``) rests on the ABSENCE of a field — a
+    snapshot taken a moment before the verdict was written and evaluated a
+    moment after presents exactly the forbidden combination, and no amount of
+    staring at that one snapshot can tell "not written yet" apart from "never
+    coming". ``None`` (the default, every pre-#2304 caller) preserves the old
+    behaviour byte-for-byte: escalate on the first read. When supplied, a
+    dead-end verdict gets ONE fresh re-read before it is trusted; if the
+    re-read no longer reproduces the shape, *state* itself is swapped for the
+    fresh copy and the rest of this function runs on it — so a verdict that
+    landed in the interim is not just un-escalated, the drive actually
+    continues onto the fix/merge arm it unblocks, in this same call.
     """
     machine = machine or opts.machine or state.picked_machine
 
@@ -2902,6 +2917,22 @@ def decide(
     # #2024: `--skip-test` is a live Test-stage move (`_decide_test` records
     # `skipped`), so the human-attended-Test shape must not escalate past it.
     dead_end = detect_dead_end(state, can_waive_test_gate=opts.skip_test)
+    if dead_end is not None and reread_state is not None:
+        # #2304: a dead end whose predicate rests on an ABSENT field (shape
+        # 1's `not state.review_verdict`, above all) cannot be trusted off a
+        # single snapshot — presence is observable, absence-so-far is not.
+        # One confirmation re-read closes the whole class: if the fresh row
+        # still reproduces the shape, escalate on IT (so the recorded gates
+        # match what was actually seen last); if it does not, the verdict
+        # landed in the gap between the stale read and this check, and
+        # `state` is swapped for the fresh copy so every gate below sees it
+        # too — the drive falls through to the fix/merge arm the verdict
+        # unblocks in this same call, rather than merely suppressing a false
+        # escalation and waiting out another full poll for the same result.
+        fresh = reread_state()
+        if fresh is not None:
+            state = fresh
+            dead_end = detect_dead_end(state, can_waive_test_gate=opts.skip_test)
     if dead_end is not None:
         return replace(
             _escalate_dead_end(state, dead_end), warnings=warnings
@@ -5910,6 +5941,11 @@ class Driver:
             action = decide(
                 state, self.opts, counters, self.verifier,
                 machine=machine, oracle=oracle, gate_checker=self.oracle_gate,
+                # #2304: the dead-end predicate's confirmation re-read — the
+                # same board fetch this loop already does every poll, just
+                # available to `decide()` for an extra, immediate look before
+                # a `review_terminal_no_verdict`-shaped snapshot is trusted.
+                reread_state=self.read_state,
             )
             for warning in action.warnings:
                 self.warn(warning)

{code_coordinator-0.5.542 → code_coordinator-0.5.544}/coord/milestone_dispatch.py

@@ -37,7 +37,7 @@ Three call sites share this module:
 from __future__ import annotations
 
 from dataclasses import dataclass, field
-from typing import TYPE_CHECKING, Callable, Iterable
+from typing import TYPE_CHECKING, Callable, Iterable, NamedTuple
 
 import httpx
 
@@ -61,7 +61,10 @@ __all__ = [
     "MilestoneContext",
     "fetch_milestone_context",
     "GateAFileExists",
+    "GateAResult",
+    "gate_a_probe",
     "gate_a_status",
+    "milestone_oracle_loop",
     "ManifestFetch",
     "GateAApprovalFetch",
     "gate_a_signoff",
@@ -220,22 +223,51 @@ def _default_gate_a_file_exists(repo_github: str, path: str, branch: str) -> boo
         return False
 
 
-def gate_a_status(
+class GateAResult(NamedTuple):
+    """The full tri-state result of a Gate-A existence check (#2785 review).
+
+    ``gate_a_status`` (below) collapses this into a plain ``str | None`` for
+    the callers that just want to abort on ANY truthy result — dispatch/drive
+    correctly treat "confirmed absent" and "read failed" identically, since
+    neither justifies dispatching. But a caller resolving
+    :func:`milestone_oracle_loop`'s ``gate_a_satisfied`` needs to tell the two
+    apart: a *confirmed* absence legitimately means "not oracle-loop, nothing
+    to race on yet" (``gate_a_satisfied=False`` is correct), while a
+    *transient* read failure means the answer is unknown and must not be
+    silently folded into the same "not oracle-loop" branch — that would
+    disable #2542's shared-group refusal for a milestone that may well be
+    under oracle-loop control, purely because of ordinary GitHub flakiness.
+
+    ``block_reason`` is ``None`` when Gate A is satisfied (dispatch may
+    proceed); otherwise a human-readable message, exactly as
+    :func:`gate_a_status` returns. ``transient`` is ``True`` only when
+    ``block_reason`` is set because of a failed *read* (network, auth, a
+    rate limit) rather than a confirmed 404 on every candidate path.
+    """
+
+    block_reason: str | None
+    transient: bool = False
+
+
+def gate_a_probe(
     repo_cfg: Repo,
     config: "Config",
     milestone_number: int,
     *,
     file_exists: GateAFileExists | None = None,
-) -> str | None:
+) -> GateAResult:
     """Gate A (docs/ORACLE_LOOP.md, #930): a milestone's issues may not
     dispatch until its black-box contract exists.
 
-    Returns ``None`` when dispatch may proceed — either the repo has no
-    ``acceptance.drivers`` entry configured (Gate A is an oracle-loop
-    concept; repos outside that model dispatch exactly as before #930), or
-    the contract file already exists on the repo's default branch. Returns a
-    human-readable block reason otherwise, naming the missing path and the
-    command that produces it.
+    Returns a :class:`GateAResult` whose ``block_reason`` is ``None`` when
+    dispatch may proceed — either the repo has no ``acceptance.drivers``
+    entry configured (Gate A is an oracle-loop concept; repos outside that
+    model dispatch exactly as before #930), or the contract file already
+    exists on the repo's default branch. Otherwise ``block_reason`` is a
+    human-readable message naming the missing path and the command that
+    produces it, and ``transient`` says whether that's a confirmed absence
+    or an inconclusive (failed) read — see :class:`GateAResult`'s own
+    docstring for why the distinction matters.
 
     #2896: a bare *milestone_number* doesn't say which acceptance search
     root its contract lives under (the shared repo-root tree, or an
@@ -259,7 +291,7 @@ def gate_a_status(
     remedy attached.
     """
     if not config.acceptance.has_driver(repo_cfg.name):
-        return None
+        return GateAResult(None)
 
     from coord import github_ops  # noqa: PLC0415
     from coord.acceptance import gate_a_contract_candidates  # noqa: PLC0415
@@ -270,19 +302,20 @@ def gate_a_status(
     for path in candidates:
         try:
             if check(repo_cfg.github, path, repo_cfg.default_branch):
-                return None
+                return GateAResult(None)
         except github_ops.GhTransientError as e:
             transient = transient or e
             continue
     if transient is not None:
-        return (
+        return GateAResult(
             f"Gate A undetermined: could not read {repo_cfg.name}'s Gate-A "
             f"contract on {repo_cfg.default_branch!r} ({transient}). This is "
             "a failed read, not a confirmed absence — the contract may well "
-            "exist. Retry once the rate limit clears."
+            "exist. Retry once the rate limit clears.",
+            transient=True,
         )
     named = " or ".join(repr(p) for p in candidates)
-    return (
+    return GateAResult(
         f"Gate A not satisfied: {named} does not exist yet on "
         f"{repo_cfg.default_branch!r}. Run `coord acceptance mock {repo_cfg.name} "
         "<tracking_issue>` (docs/ORACLE_LOOP.md) to render the mock + write "
@@ -290,6 +323,81 @@ def gate_a_status(
     )
 
 
+def gate_a_status(
+    repo_cfg: Repo,
+    config: "Config",
+    milestone_number: int,
+    *,
+    file_exists: GateAFileExists | None = None,
+) -> str | None:
+    """Thin ``str | None`` view over :func:`gate_a_probe`, for the callers
+    (``milestone_dispatch_cmd``, ``milestone_drive_cmd``,
+    ``_milestone_drain_tick``) that only need to know whether to abort —
+    they already treat a confirmed absence and a transient read failure
+    identically (abort either way, since neither justifies dispatching), so
+    dropping ``GateAResult.transient`` here is safe for them. A caller that
+    needs to tell the two apart (:func:`milestone_oracle_loop`'s
+    ``gate_a_satisfied``) should call :func:`gate_a_probe` directly instead.
+    """
+    return gate_a_probe(
+        repo_cfg, config, milestone_number, file_exists=file_exists
+    ).block_reason
+
+
+def milestone_oracle_loop(
+    repo_cfg: Repo,
+    config: "Config",
+    *,
+    gate_a_satisfied: bool,
+) -> bool:
+    """Whether a milestone is actually under oracle-loop control (#2785).
+
+    #2542 introduced a family of checks/behaviors keyed on "is this
+    milestone oracle-loop-controlled" (:func:`coord.milestone_order.
+    validate_no_shared_oracle_group`'s shared-group refusal,
+    :func:`plan_dispatch`'s one-entry-per-tick cap, :func:`plan_queue`'s
+    whole-milestone ``after=`` chaining) — but every one of those call sites
+    resolved the question from ``config.acceptance.has_driver(repo_cfg.
+    name)`` alone. That is a REPO-level fact (does this repo declare ANY
+    acceptance driver at all, for ANY milestone), not a per-milestone one.
+    A repo can have a driver configured and still run milestones that never
+    touch the oracle loop at all — this repo's own ms-60 (Store Service,
+    plain refactors, no ``tests/acceptance/ms-60/``) alongside ms-37/ms-65
+    (real oracle-loop milestones). Under the old resolution EVERY milestone
+    in a repo that has EVER declared a driver was treated as oracle-loop-
+    controlled — #1949 (ms-60's tracking epic) had its `## Work order`
+    become permanently un-editable, refusing shared groups that pose no
+    actual hazard, because there is no ``tests/acceptance/ms-60/manifest.
+    yml`` for anything to race on.
+
+    True only when the repo has a driver configured AND *this milestone's*
+    Gate-A contract already exists (``gate_a_satisfied`` — the caller's
+    already-resolved :func:`gate_a_status` existence probe: ``... is
+    None``, the same signal :func:`coord.acceptance.gate_a_contract_candidates`
+    checks for). A milestone with no contract yet has nothing to race on
+    either: nobody has authored a JIT acceptance slice into a manifest that
+    doesn't exist, so treating it as oracle-loop-active before Gate A is
+    even satisfied would repeat the same category of over-broad mistake
+    this replaces, just one gate later.
+
+    Deliberately takes the already-resolved ``gate_a_satisfied`` rather than
+    a bare ``milestone_number`` and re-probing GitHub itself: every caller
+    in this module and ``coord.serve_app`` already computes a Gate-A
+    existence probe on the same tick (``gate_a_status`` / ``probe_milestone
+    ().gate_a_blocked``) before ever reaching an ``oracle_loop=`` call site
+    — re-deriving it here would mean a second live fetch per tick for no
+    new information. A caller with no probe in hand yet (``coord milestone
+    write-order``, which has no other reason to touch Gate A) computes one
+    fresh via ``gate_a_status(repo_cfg, config, milestone_number) is None``.
+
+    Single source of truth for this question (epic #2096, "one question,
+    one answer") — every #2542 caller should resolve ``oracle_loop``
+    through this rather than re-deriving ``has_driver`` locally, so the two
+    can never drift apart again.
+    """
+    return config.acceptance.has_driver(repo_cfg.name) and gate_a_satisfied
+
+
 # (repo_github, path, branch) -> file content, or None if it doesn't exist.
 # Injected so tests never hit `gh` — mirrors GateAFileExists above.
 #
@@ -704,6 +812,17 @@ def issue_oracle_ready(
     the entry (re-checked every tick) instead of landing it in terminal
     ``blocked``, which nothing re-evaluates (#2040) — this is an explicitly
     operator-fixable condition with a one-command remedy.
+
+    #2785 audit note: the ``has_driver`` check below is correctly
+    repo-level — it's a cheap early exit only, immediately followed by the
+    real per-milestone ``gate_a_status`` existence check a few lines down
+    (via ``effective_file_exists``). A repo with no driver at all can have
+    no oracle-loop milestone, so short-circuiting there costs nothing; a
+    repo WITH a driver still falls through to the per-milestone contract
+    check before this ever returns non-default readiness. Unlike #2542's
+    ``validate_no_shared_oracle_group``/``plan_dispatch``/``plan_queue``
+    family (see :func:`milestone_oracle_loop`), this function never treated
+    ``has_driver`` alone as sufficient.
     """
     if milestone_number is None or not config.acceptance.has_driver(repo_cfg.name):
         return OracleReadiness()
@@ -943,9 +1062,12 @@ def plan_dispatch(
     distinct idle machines instead of piling onto one).
 
     ``oracle_loop`` (#2542) — the caller's already-resolved
-    ``config.acceptance.has_driver(repo_cfg.name)`` — caps ``to_dispatch`` at
-    **one** entry per call. Without this, two ready-frontier entries with no
-    claim/dependency edge between them (the normal, desired fan-out above)
+    :func:`milestone_oracle_loop` for *this milestone* (#2785; NOT the
+    repo-level ``config.acceptance.has_driver(repo_cfg.name)`` alone — see
+    that function's docstring for why the distinction matters) — caps
+    ``to_dispatch`` at **one** entry per call. Without this, two
+    ready-frontier entries with no claim/dependency edge between them (the
+    normal, desired fan-out above)
     would both dispatch in the very same tick under an oracle-loop
     milestone, and each independently authors its own JIT acceptance slice
     into the SAME ``tests/acceptance/ms-N/manifest.yml``
@@ -1039,9 +1161,12 @@ def plan_queue(
     the defensive tail below only fires on inputs constructed outside it.
 
     ``oracle_loop`` (#2542) — the caller's already-resolved
-    ``config.acceptance.has_driver(repo_name)`` — additionally chains every
-    entry's ``after`` to the issue immediately before it in this function's
-    own topological order, so the drive-queue admits the WHOLE milestone
+    :func:`milestone_oracle_loop` for *this milestone* (#2785; NOT the
+    repo-level ``config.acceptance.has_driver(repo_name)`` alone — see that
+    function's docstring for why the distinction matters) — additionally
+    chains every entry's ``after`` to the issue immediately before it in
+    this function's own topological order, so the drive-queue admits the
+    WHOLE milestone
     strictly one entry at a time. Without this, two entries with no declared
     edge between them (different ``group``s, or neither declaring one) are
     both ``waiting`` the moment their own pre-reqs land, and the

{code_coordinator-0.5.542 → code_coordinator-0.5.544}/coord/milestone_order.py

@@ -614,11 +614,19 @@ def validate_no_shared_oracle_group(
     ms-N's manifest at once.
 
     ``oracle_loop`` is the caller's already-resolved
-    ``config.acceptance.has_driver(repo_name)`` — this stays a pure
-    function, no config/GitHub reach-out of its own. A no-op when
-    ``oracle_loop`` is False (repos outside the oracle loop keep declaring
-    parallel groups exactly as before this check existed) or when no group
-    holds more than one node.
+    :func:`coord.milestone_dispatch.milestone_oracle_loop` for *this
+    milestone* (#2785) — NOT the repo-level ``config.acceptance.
+    has_driver(repo_name)`` alone, which is true for every milestone in a
+    repo that has ever declared ANY acceptance driver and so over-fires for
+    a milestone that has no ``tests/acceptance/ms-N/`` of its own to race
+    on (#2785's ms-60/#1949: ordinary refactors sharing a repo with real
+    oracle-loop milestones, whose `## Work order` became permanently
+    un-editable under the old, repo-level resolution). This function stays
+    pure either way — no config/GitHub reach-out of its own; resolving
+    ``oracle_loop`` correctly is the caller's job. A no-op when
+    ``oracle_loop`` is False (a milestone outside the oracle loop keeps
+    declaring parallel groups exactly as before this check existed) or when
+    no group holds more than one node.
 
     This is deliberately only the cheap, early check for the EXPLICIT-group
     case — ``coord milestone write-order`` validates it before a word order

{code_coordinator-0.5.542 → code_coordinator-0.5.544}/coord/serve_app.py

@@ -1951,10 +1951,12 @@ def _milestone_drain_tick(config: Config) -> list:
     that filter for free). A per-milestone fetch/dispatch error must not
     silence the other registered milestones — caught and logged per entry.
 
-    Same ``oracle_loop`` capping as ``_milestone_gate_tick`` (#2542): a repo
-    under oracle-loop control gets at most one dispatch per registered
-    milestone per tick, so this legacy path can't fan two same-milestone
-    entries out to distinct machines in one call and race them on the
+    Same ``oracle_loop`` capping as ``_milestone_gate_tick`` (#2542,
+    resolved per milestone via ``milestone_oracle_loop`` since #2785): a
+    milestone under oracle-loop control gets at most one dispatch per
+    registered milestone per tick, so this legacy path can't fan two
+    same-milestone entries out to distinct machines in one call and race
+    them on the
     shared ``tests/acceptance/ms-N/manifest.yml`` either — even though only
     pre-#2335 registrations feed it today (see above), it is the same class
     of hole as the gate tick's and worth closing the same way.
@@ -2043,9 +2045,17 @@ def _milestone_drain_tick(config: Config) -> list:
         from coord.dispatch_liveness import github_issue_liveness_fetcher  # noqa: PLC0415
         from coord.network import claude_credential_reachable  # noqa: PLC0415
 
+        # #2785: resolved per milestone via `milestone_oracle_loop`, not
+        # the repo-level `has_driver` alone — see that function's
+        # docstring. `block_reason` above already is this specific
+        # milestone's Gate-A existence probe (confirmed `None`, or this tick
+        # would already have `continue`d above), so reuse it rather than
+        # re-fetching.
         plan = md.plan_dispatch(
             ctx.work_order, board, config, repo_cfg, ctx.terminal_issues,
-            oracle_loop=config.acceptance.has_driver(repo_name),
+            oracle_loop=md.milestone_oracle_loop(
+                repo_cfg, config, gate_a_satisfied=block_reason is None
+            ),
             credential_fetcher=claude_credential_reachable,
         )
         # #3376 review round 1: this drain tick is a real production
@@ -2129,13 +2139,30 @@ def _milestone_gate_tick(config: Config, *, now: float | None = None) -> list:
     hold-and-report: it logs why it cannot advance and leaves the record
     where it is. Nothing here silently falls through.
 
-    ``plan_dispatch`` is called with ``oracle_loop=config.acceptance.
-    has_driver(repo_cfg.name)`` (#2542) — for a repo under oracle-loop
-    control this caps the tick's dispatch at one ready-frontier entry, so
-    this walk (docs/ORACLE_LOOP.md's "oracle drive", #1453 — the documented
-    primary driver for an oracle-loop milestone) can never launch two
-    same-milestone entries into their JIT slice-authoring phase in the same
-    tick, racing on the shared ``tests/acceptance/ms-N/manifest.yml``.
+    ``plan_dispatch`` is called with ``oracle_loop=md.milestone_oracle_loop
+    (repo_cfg, config, gate_a_satisfied=mg.GATE_A in record.cleared)`` (#2542,
+    resolved per milestone rather than repo-wide since #2785) — for a
+    milestone under oracle-loop control this caps the tick's dispatch at one
+    ready-frontier entry, so this walk (docs/ORACLE_LOOP.md's "oracle
+    drive", #1453 — the documented primary driver for an oracle-loop
+    milestone) can never launch two same-milestone entries into their JIT
+    slice-authoring phase in the same tick, racing on the shared
+    ``tests/acceptance/ms-N/manifest.yml``.
+
+    #2785 review: this reads ``GATE_A in record.cleared`` — the *durable*
+    record of whether this milestone's Gate-A contract has already been
+    confirmed to exist — rather than re-deriving it from a fresh
+    ``probes.gate_a_blocked`` live probe. The ``work`` gate is only
+    reachable after ``evaluate_gate`` already advanced this record past
+    ``GATE_A`` (which stamps ``GATE_A`` into ``cleared``, see
+    ``apply_step``), so the two answers agree on the happy path — but
+    ``probe_milestone`` unconditionally re-fetches Gate A on *every* tick
+    regardless of the milestone's current gate, so a single tick's transient
+    GitHub read failure would otherwise flip ``gate_a_satisfied`` to
+    ``False`` for that tick alone, un-capping the one-entry-per-tick limit
+    and reopening #2542's manifest race exactly when GitHub is least
+    reliable. The durable record can't flap tick to tick the way a live
+    re-probe can.
 
     Deliberately **not** gated on ``config.milestone.auto_dispatch`` — that
     flag gates the legacy standalone drain (:func:`_milestone_drain_tick`),
@@ -2244,9 +2271,29 @@ def _milestone_gate_tick(config: Config, *, now: float | None = None) -> list:
                 from coord.dispatch_liveness import github_issue_liveness_fetcher  # noqa: PLC0415
                 from coord.network import claude_credential_reachable  # noqa: PLC0415
 
+                # #2785: resolved per milestone via `milestone_oracle_loop`,
+                # not the repo-level `has_driver` alone — see that
+                # function's docstring.
+                #
+                # #2785 review: reads the DURABLE `record.cleared` (has
+                # GATE_A already been stamped as cleared for this milestone?)
+                # rather than `probes.gate_a_blocked` — that field is a
+                # fresh live Gate-A re-probe recomputed on EVERY tick
+                # (`probe_milestone`'s own docstring), and a single tick's
+                # transient GitHub read failure there would silently drop
+                # `oracle_loop` to False for that tick's dispatch, un-capping
+                # the one-entry-per-tick limit right when GitHub flakiness
+                # makes caution matter most. The `work` gate is only
+                # reachable after `evaluate_gate` already advanced this
+                # record past GATE_A (which appends it to `cleared` —
+                # `apply_step`), so this durable signal is exactly as
+                # accurate on the happy path and immune to that flap.
                 plan = md.plan_dispatch(
                     ctx.work_order, board, config, repo_cfg, ctx.terminal_issues,
-                    oracle_loop=config.acceptance.has_driver(repo_cfg.name),
+                    oracle_loop=md.milestone_oracle_loop(
+                        repo_cfg, config,
+                        gate_a_satisfied=mg.GATE_A in record.cleared,
+                    ),
                     credential_fetcher=claude_credential_reachable,
                 )
                 # #3376 review round 1: same issue-liveness wiring as the