code-coordinator 0.5.543__tar.gz → 0.5.545__tar.gz

{code_coordinator-0.5.543 → code_coordinator-0.5.545}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: code-coordinator
-Version: 0.5.543
+Version: 0.5.545
 Summary: Coordinate Claude Code workers across multiple machines and repos.
 Author-email: John Donaghy <johnfdonaghy@gmail.com>
 License-Expression: LicenseRef-FSL-1.1-MIT
@@ -30,12 +30,17 @@ Provides-Extra: postgres
 Requires-Dist: psycopg[binary]>=3.1; extra == "postgres"
 Provides-Extra: reports-xlsx
 Requires-Dist: openpyxl>=3.1; extra == "reports-xlsx"
+Provides-Extra: tui-pty
+Requires-Dist: pyte>=0.8; extra == "tui-pty"
+Requires-Dist: pywinpty>=2.0; sys_platform == "win32" and extra == "tui-pty"
 Provides-Extra: all
 Requires-Dist: code-coordinator[server]; extra == "all"
 Requires-Dist: code-coordinator[reports-xlsx]; extra == "all"
+Requires-Dist: code-coordinator[tui-pty]; extra == "all"
 Provides-Extra: dev
 Requires-Dist: code-coordinator[server]; extra == "dev"
 Requires-Dist: code-coordinator[reports-xlsx]; extra == "dev"
+Requires-Dist: code-coordinator[tui-pty]; extra == "dev"
 Requires-Dist: pytest>=8.0; extra == "dev"
 Requires-Dist: pytest-asyncio>=0.23; extra == "dev"
 Requires-Dist: pytest-xdist>=3.5; extra == "dev"

{code_coordinator-0.5.543 → code_coordinator-0.5.545}/code_coordinator.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: code-coordinator
-Version: 0.5.543
+Version: 0.5.545
 Summary: Coordinate Claude Code workers across multiple machines and repos.
 Author-email: John Donaghy <johnfdonaghy@gmail.com>
 License-Expression: LicenseRef-FSL-1.1-MIT
@@ -30,12 +30,17 @@ Provides-Extra: postgres
 Requires-Dist: psycopg[binary]>=3.1; extra == "postgres"
 Provides-Extra: reports-xlsx
 Requires-Dist: openpyxl>=3.1; extra == "reports-xlsx"
+Provides-Extra: tui-pty
+Requires-Dist: pyte>=0.8; extra == "tui-pty"
+Requires-Dist: pywinpty>=2.0; sys_platform == "win32" and extra == "tui-pty"
 Provides-Extra: all
 Requires-Dist: code-coordinator[server]; extra == "all"
 Requires-Dist: code-coordinator[reports-xlsx]; extra == "all"
+Requires-Dist: code-coordinator[tui-pty]; extra == "all"
 Provides-Extra: dev
 Requires-Dist: code-coordinator[server]; extra == "dev"
 Requires-Dist: code-coordinator[reports-xlsx]; extra == "dev"
+Requires-Dist: code-coordinator[tui-pty]; extra == "dev"
 Requires-Dist: pytest>=8.0; extra == "dev"
 Requires-Dist: pytest-asyncio>=0.23; extra == "dev"
 Requires-Dist: pytest-xdist>=3.5; extra == "dev"

{code_coordinator-0.5.543 → code_coordinator-0.5.545}/code_coordinator.egg-info/SOURCES.txt

@@ -163,6 +163,7 @@ coord/test_author.py
 coord/test_chat.py
 coord/test_orchestrator.py
 coord/test_report.py
+coord/tui_pty_driver.py
 coord/tui_release.py
 coord/uat_checks.py
 coord/usage.py
@@ -858,6 +859,7 @@ tests/test_throwaway_vm.py
 tests/test_tmux_host.py
 tests/test_tmux_session.py
 tests/test_transcript_floor.py
+tests/test_tui_pty_driver.py
 tests/test_uat_checks.py
 tests/test_usage.py
 tests/test_usage_limits.py

{code_coordinator-0.5.543 → code_coordinator-0.5.545}/code_coordinator.egg-info/requires.txt

@@ -9,10 +9,12 @@ tzdata
 [all]
 code-coordinator[server]
 code-coordinator[reports-xlsx]
+code-coordinator[tui-pty]
 
 [dev]
 code-coordinator[server]
 code-coordinator[reports-xlsx]
+code-coordinator[tui-pty]
 pytest>=8.0
 pytest-asyncio>=0.23
 pytest-xdist>=3.5
@@ -31,3 +33,9 @@ starlette>=0.37
 uvicorn>=0.30
 websockets>=12.0
 psutil>=5.9
+
+[tui-pty]
+pyte>=0.8
+
+[tui-pty:sys_platform == "win32"]
+pywinpty>=2.0

{code_coordinator-0.5.543 → code_coordinator-0.5.545}/code_coordinator.egg-info/scm_file_list.json

@@ -290,6 +290,7 @@
     "coord/test_chat.py",
     "coord/test_orchestrator.py",
     "coord/test_report.py",
+    "coord/tui_pty_driver.py",
     "coord/tui_release.py",
     "coord/uat_checks.py",
     "coord/usage.py",
@@ -885,6 +886,7 @@
     "tests/test_tmux_host.py",
     "tests/test_tmux_session.py",
     "tests/test_transcript_floor.py",
+    "tests/test_tui_pty_driver.py",
     "tests/test_uat_checks.py",
     "tests/test_usage.py",
     "tests/test_usage_limits.py",

{code_coordinator-0.5.543 → code_coordinator-0.5.545}/code_coordinator.egg-info/scm_version.json

@@ -1,7 +1,7 @@
 {
-  "tag": "0.5.543",
+  "tag": "0.5.545",
   "distance": 0,
-  "node": "g46bffa6e864139be6fd12e036d29b7d76c2a4c02",
+  "node": "g43201054b1bb8cd75c1a632db8f016f315da8957",
   "dirty": false,
   "branch": "HEAD",
   "node_date": "2026-09-30"

{code_coordinator-0.5.543 → code_coordinator-0.5.545}/coord/acceptance_drivers.py

@@ -8,11 +8,11 @@ is the one seam that varies per medium — TUI (quadraui ``TuiDriver``), CLI
 normalized list of ``{"id": str, "status": "pass"|"fail"|"skip", "message":
 str}`` dicts (``cli-pytest`` additionally carries ``"expected"``/``"got"``
 on a failing test — see :func:`parse_pytest_junit_xml`). ``tui-tuidriver``,
-``cli-pytest`` (#1125), ``web-playwright`` (#1539), and ``terraform``
-(#3232) are implemented; other ``kind`` values are declared in
-``coordinator.yml`` (see :class:`coord.config.AcceptanceConfig`) but
-rejected here with a clear "not yet implemented" error until their issues
-land (native).
+``cli-pytest`` (#1125), ``web-playwright`` (#1539), ``terraform``
+(#3232), and ``tui-pty`` (#3483) are implemented; other ``kind`` values are
+declared in ``coordinator.yml`` (see :class:`coord.config.AcceptanceConfig`)
+but rejected here with a clear "not yet implemented" error until their
+issues land (native).
 
 ``cli-pytest`` parses pytest's built-in ``--junit-xml`` report (a core
 pytest flag, not a plugin — no extra dependency required in the driven
@@ -45,6 +45,22 @@ enough to run ``validate`` at all) comes out regardless of what the driven
 repo's own terraform version prints to plain stdout. This is a compile
 check, not an acceptance oracle — see :data:`VALIDATE_ONLY_KINDS`.
 
+``tui-pty`` (#3483, Tier 2 of the TUI acceptance ladder — ``tui-tuidriver``
+above is Tier 1, in-process) launches the driven repo's real compiled
+binary under a real pty/ConPTY and drives it with real terminal byte
+sequences, rather than going through quadraui's in-process ``TuiDriver``.
+Three real Windows TUI bugs (vimcode#1634-#1636) all passed their
+in-process tests on 2026-09-29 — the bytes an in-process harness feeds and
+reads are never generated by, or read back through, a real terminal, so a
+whole class of bug is invisible to it by construction. All of the actual
+byte-level driving, the VT emulation, and the platform-neutral YAML smoke
+spec live in :mod:`coord.tui_pty_driver` — see that module's docstring for
+the spec format and the ``ESC[6n`` startup-handshake lesson folded in from
+vimcode's own ConPTY tests. This adapter (:func:`_run_tui_pty`) is a thin
+seam: it resolves the smoke spec from the driver's ``entrypoint:`` (the
+``tui-pty`` analogue of ``tui-tuidriver``'s own entrypoint-as-sealed-file
+convention) and hands off to :func:`coord.tui_pty_driver.run_smoke_spec`.
+
 ``terraform`` additionally runs a deterministic policy gate (#3234, epic
 #3230 child 3) whenever the driven repo has opted in by carrying the
 convention files: ``tflint`` (rule-based HCL/provider checks — pinned
@@ -75,7 +91,7 @@ from pathlib import Path
 # Driver kinds this module knows how to run. Keep in sync with the adapters
 # implemented below — a kind can be *declared* in coordinator.yml ahead of its
 # adapter landing, but running it must fail loudly rather than silently no-op.
-SUPPORTED_KINDS = ("tui-tuidriver", "cli-pytest", "web-playwright", "terraform")
+SUPPORTED_KINDS = ("tui-tuidriver", "cli-pytest", "web-playwright", "terraform", "tui-pty")
 
 # #2748 (IL-2): driver kinds whose `run` produces a real pass/fail verdict
 # but NOT yet a deterministic one, because an input they depend on hasn't
@@ -229,7 +245,7 @@ def render_run_command(run_command: str, *, ms: str | None = None) -> str:
 
 def run_driver(
     kind: str, run_command: str, cwd: str, *, timeout: int = 900, ms: str | None = None,
-    setup_command: str = "",
+    setup_command: str = "", entrypoint: str = "",
 ) -> DriverResult:
     """Execute *run_command* in *cwd* and parse its output for *kind*.
 
@@ -250,6 +266,13 @@ def run_driver(
     before *run_command* ever executes — with a message that names it as a
     provisioning failure so it isn't mistaken for a test failure or folded
     into a driver's own "wrote no report" crash message.
+
+    *entrypoint* (``AcceptanceDriverConfig.entrypoint``) is only consulted
+    by ``tui-pty`` (#3483) — it names the repo-root-relative smoke-spec YAML
+    file (see :mod:`coord.tui_pty_driver`), the same way ``entrypoint``
+    already names ``tui-tuidriver``'s sealed Rust acceptance file for
+    :func:`coord.acceptance.acceptance_root_for_driver`. Every other kind
+    ignores it.
     """
     if kind not in SUPPORTED_KINDS:
         raise DriverError(
@@ -269,6 +292,8 @@ def run_driver(
         return _run_web_playwright(run_command, cwd, timeout=timeout)
     if kind == "terraform":
         return _run_terraform(run_command, cwd, timeout=timeout)
+    if kind == "tui-pty":
+        return _run_tui_pty(run_command, cwd, entrypoint, timeout=timeout)
     return _run_generic(run_command, cwd, timeout=timeout)
 
 
@@ -572,6 +597,68 @@ def _run_terraform_policy_gate(cwd: str, *, timeout: int) -> tuple[list[dict], s
     return tests, raw_output
 
 
+def _run_tui_pty(run_command: str, cwd: str, entrypoint: str, *, timeout: int) -> DriverResult:
+    """The ``tui-pty`` shape (#3483): *run_command* is the shell command
+    that launches the driven repo's real compiled binary (e.g.
+    ``./target/release/vcd``) — the platform-neutral smoke spec YAML that
+    drives it lives at *entrypoint* (repo-root-relative), the ``tui-pty``
+    analogue of ``tui-tuidriver``'s own ``entrypoint:``-as-sealed-file
+    convention (see the module docstring and CLAUDE.md's sealed-paths
+    section).
+
+    All the actual pty/ConPTY spawning, real terminal-byte input, and VT
+    screen assertions live in :mod:`coord.tui_pty_driver` — this function is
+    the thin seam that resolves *entrypoint* to a spec file and calls
+    :func:`coord.tui_pty_driver.run_smoke_spec`, then folds its normalized
+    ``tests`` list into a :class:`DriverResult` the same way every other
+    kind in this module does.
+
+    Raises :class:`DriverError` — never a bare exception — for a missing
+    ``entrypoint:``, a spec file that doesn't exist, or a malformed spec
+    (an invalid-YAML/unknown-step-type :class:`coord.tui_pty_driver.TuiPtySpecError`).
+    A child process that dies mid-run, a step that times out, or a failed
+    assertion do NOT raise here — :func:`coord.tui_pty_driver.run_smoke_spec`
+    folds those into individual failing entries in ``tests`` instead, so a
+    real regression (e.g. vimcode#1634's idle-flicker check) reads as a
+    normal failing test, not a crashed driver run.
+    """
+    from coord.tui_pty_driver import (  # noqa: PLC0415 — see module docstring on the deferred import
+        TuiPtyRuntimeError,
+        TuiPtySpecError,
+        run_smoke_spec,
+    )
+
+    if not entrypoint:
+        raise DriverError(
+            "tui-pty driver requires an `entrypoint:` naming the smoke-spec "
+            "YAML file (repo-root-relative) — none configured"
+        )
+    spec_path = Path(cwd) / entrypoint
+    if not spec_path.is_file():
+        raise DriverError(f"tui-pty smoke spec not found: {spec_path}")
+
+    try:
+        spec_text = spec_path.read_text()
+    except OSError as e:
+        raise DriverError(f"tui-pty smoke spec could not be read: {spec_path}: {e}") from e
+
+    try:
+        tests = run_smoke_spec(
+            spec_text, launch_command=run_command, cwd=cwd, timeout=timeout,
+        )
+    except TuiPtySpecError as e:
+        raise DriverError(f"tui-pty smoke spec is invalid: {e}") from e
+    except TuiPtyRuntimeError as e:
+        raise DriverError(f"tui-pty driver could not run: {e}") from e
+
+    exit_code = 0 if tests and all(t.get("status") != "fail" for t in tests) else 1
+    raw_output = "\n".join(
+        f"{t.get('status')}: {t.get('id')} {t.get('message', '')}".rstrip()
+        for t in tests
+    )
+    return DriverResult(exit_code=exit_code, tests=tests, raw_output=raw_output)
+
+
 def parse_test_output(output: str) -> list[dict]:
     """Parse a driver's stdout into normalized ``{"id", "status", "message"}``.
 

{code_coordinator-0.5.543 → code_coordinator-0.5.545}/coord/commands/acceptance.py

@@ -352,7 +352,7 @@ def acceptance_run(
     try:
         result = run_driver(
             driver_cfg.kind, driver_cfg.run, cwd=str(cwd), ms=ms,
-            setup_command=driver_cfg.setup,
+            setup_command=driver_cfg.setup, entrypoint=driver_cfg.entrypoint,
         )
     except DriverError as e:
         click.echo(f"error: {e}", err=True)
@@ -1019,7 +1019,7 @@ def _acceptance_record_local(
         try:
             result = run_driver(
                 driver_cfg.kind, driver_cfg.run, cwd=str(wt_path), ms=ms,
-                setup_command=driver_cfg.setup,
+                setup_command=driver_cfg.setup, entrypoint=driver_cfg.entrypoint,
             )
         except DriverError as e:
             click.echo(f"error: {e}", err=True)

{code_coordinator-0.5.543 → code_coordinator-0.5.545}/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)
@@ -1789,7 +1842,10 @@ def milestone_gate_c_cmd(
     # suite dir for Gate C's "full accumulated suite" semantics.
     ms = ms_dirname(ctx.milestone_number)
     try:
-        result = run_driver(driver_cfg.kind, driver_cfg.run, cwd=str(repo_dir), ms=ms)
+        result = run_driver(
+            driver_cfg.kind, driver_cfg.run, cwd=str(repo_dir), ms=ms,
+            entrypoint=driver_cfg.entrypoint,
+        )
     except DriverError as e:
         click.echo(f"error: {e}", err=True)
         sys.exit(1)
@@ -2095,7 +2151,10 @@ def milestone_ship_cmd(
     click.echo(f"Gate C: running the full accumulated acceptance suite in {repo_dir}...")
     ms = ms_dirname(ctx.milestone_number)
     try:
-        result = run_driver(driver_cfg.kind, driver_cfg.run, cwd=str(repo_dir), ms=ms)
+        result = run_driver(
+            driver_cfg.kind, driver_cfg.run, cwd=str(repo_dir), ms=ms,
+            entrypoint=driver_cfg.entrypoint,
+        )
     except DriverError as e:
         click.echo(f"error: {e}", err=True)
         sys.exit(1)

{code_coordinator-0.5.543 → code_coordinator-0.5.545}/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