code-coordinator 0.5.230__tar.gz → 0.5.231__tar.gz

{code_coordinator-0.5.230 → code_coordinator-0.5.231}/PKG-INFO

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

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

@@ -1,7 +1,7 @@
 {
-  "tag": "0.5.230",
+  "tag": "0.5.231",
   "distance": 0,
-  "node": "g2e59935577bb8bd17362609676a470181e55ba5b",
+  "node": "g9bcc6d2ee8084e339463aeb3572a47a58b9b1657",
   "dirty": false,
   "branch": "HEAD",
   "node_date": "2026-08-22"

{code_coordinator-0.5.230 → code_coordinator-0.5.231}/coord/commands/milestone.py

@@ -48,6 +48,7 @@ from coord.milestone_order import (
     replace_sub_issues_section,
     replace_work_order_section,
     validate_milestone_membership,
+    validate_no_shared_oracle_group,
 )
 
 
@@ -1088,7 +1089,15 @@ def milestone_dispatch_cmd(
     # issue as its pre-reqs land; that also makes `register_milestone_drain`
     # redundant here (the queue IS the durable drain, and registering would
     # have the daemon's direct-dispatch drain racing it).
-    queue_plan = plan_queue(ctx.work_order, ctx.terminal_issues, repo_entry.name)
+    # #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.
+    queue_plan = plan_queue(
+        ctx.work_order,
+        ctx.terminal_issues,
+        repo_entry.name,
+        oracle_loop=cfg.acceptance.has_driver(repo_entry.name),
+    )
 
     if not queue_plan:
         click.echo("Nothing to queue — every work-order node is already closed.")
@@ -1277,18 +1286,25 @@ def milestone_drive_cmd(
 
     # The frontier half of the dry-run report. Computed for both modes so the
     # non-dry-run confirmation shows what the first `work` tick will do.
+    # #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.
     if ctx.work_order.nodes:
         plan = plan_dispatch(
-            ctx.work_order, board, cfg, repo_entry, ctx.terminal_issues
+            ctx.work_order, board, cfg, repo_entry, ctx.terminal_issues,
+            oracle_loop=cfg.acceptance.has_driver(repo_entry.name),
+        )
+        to_dispatch, skipped, waiting, deferred = (
+            plan.to_dispatch, plan.skipped, plan.waiting, plan.deferred,
         )
-        to_dispatch, skipped, waiting = plan.to_dispatch, plan.skipped, plan.waiting
     else:
-        to_dispatch, skipped, waiting = [], [], []
+        to_dispatch, skipped, waiting, deferred = [], [], [], []
 
     if dry_run:
         for line in mg.format_plan(
             record, steps,
             to_dispatch=to_dispatch, skipped=skipped, waiting=waiting,
+            deferred=deferred,
         ):
             click.echo(line)
         return
@@ -1311,7 +1327,7 @@ def milestone_drive_cmd(
     state.save_milestone_gate(record.to_dict())
     for line in mg.format_plan(
         record, steps, to_dispatch=to_dispatch, skipped=skipped, waiting=waiting,
-        footer=False,
+        deferred=deferred, footer=False,
     ):
         click.echo(line)
     click.echo()
@@ -1448,6 +1464,22 @@ def milestone_write_order_cmd(
         click.echo(f"error: {e}", err=True)
         sys.exit(1)
 
+    # #2542: refuse a proposed work order that puts two issues in the same
+    # `{group: ...}` cohort when this milestone is under oracle-loop control
+    # — every group member's JIT acceptance slice would additively append to
+    # the SAME tests/acceptance/ms-N/manifest.yml, a manifest race that
+    # exists regardless of whether the issues' actual feature work overlaps
+    # (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.
+    try:
+        validate_no_shared_oracle_group(
+            work_order, oracle_loop=cfg.acceptance.has_driver(repo_entry.name)
+        )
+    except WorkOrderError as e:
+        click.echo(f"error: {e}", err=True)
+        sys.exit(1)
+
     # #1057: a valid `## Work order` block alone doesn't make this issue
     # findable as the milestone's tracking epic — `coord plans`/the TUI
     # Plans panel key off the `epic` label (TRACKING_ISSUE_LABEL). Ensure it

{code_coordinator-0.5.230 → code_coordinator-0.5.231}/coord/milestone_dispatch.py

@@ -25,6 +25,11 @@ Three call sites share this module:
   same fetch → plan → dispatch sequence for milestones registered via a
   non-dry-run ``coord milestone dispatch`` call, so newly-unblocked frontier
   entries dispatch automatically as dependencies complete.
+- The daemon's gate tick (``coord.serve_app._milestone_gate_tick``, #1929),
+  whose ``work`` gate state IS the drain for a gate-driven milestone (``coord
+  milestone drive``, docs/ORACLE_LOOP.md) — same ``plan_dispatch`` +
+  ``dispatch_entry`` primitives, so gate policy and dispatch policy can't
+  drift apart.
 - Tests exercise the pure ``plan_dispatch``/``pick_machine`` functions
   directly with a seeded :class:`~coord.models.Board`, no GitHub or HTTP.
 """
@@ -66,6 +71,7 @@ __all__ = [
     "pick_machine",
     "MachinePick",
     "NoMachineAvailable",
+    "DeferredByOracleLoop",
     "MilestonePlan",
     "plan_dispatch",
     "QueuePlanEntry",
@@ -642,15 +648,37 @@ class NoMachineAvailable:
     reason: str = "no idle machine available for this repo"
 
 
+@dataclass(frozen=True)
+class DeferredByOracleLoop:
+    """A ready-frontier entry withheld *this tick* because the milestone is
+    under oracle-loop control and another entry already claimed the tick's
+    one dispatch slot (#2542).
+
+    Distinct from both :class:`~coord.milestone_order.BlockedNode` (the
+    frontier itself considers this entry ready) and
+    :class:`NoMachineAvailable` (there may well be an idle machine for it) —
+    it is held back purely so two same-milestone entries never enter their
+    JIT-slice-authoring phase concurrently and race on the shared
+    ``tests/acceptance/ms-N/manifest.yml``. It will be reconsidered on the
+    next tick, by which point the dispatched entry is claimed (an active
+    board assignment) and drops out of the ready frontier on its own.
+    """
+
+    entry: FrontierEntry
+    reason: str = "oracle-loop milestone: only one entry dispatches per tick"
+
+
 @dataclass(frozen=True)
 class MilestonePlan:
     """The result of :func:`plan_dispatch`: what to dispatch now, what's
-    idle-machine-starved, and what Phase 0's frontier says is still blocked.
+    idle-machine-starved, what's withheld for oracle-loop serialization, and
+    what Phase 0's frontier says is still blocked.
     """
 
     to_dispatch: tuple[MachinePick, ...] = ()
     skipped: tuple[NoMachineAvailable, ...] = ()
     waiting: tuple[BlockedNode, ...] = ()
+    deferred: tuple[DeferredByOracleLoop, ...] = ()
 
 
 def plan_dispatch(
@@ -659,6 +687,8 @@ def plan_dispatch(
     config: "Config",
     repo_cfg: Repo,
     terminal_issues: frozenset[int] | set[int],
+    *,
+    oracle_loop: bool = False,
 ) -> MilestonePlan:
     """Compute the ready frontier and pick a machine for each ready entry.
 
@@ -667,6 +697,33 @@ def plan_dispatch(
     the first idle+capable machine not already claimed by an earlier entry
     in *this* call (so a cohort of N ready issues fans out across up to N
     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)
+    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``
+    (``coord.test_author``'s "later slices MERGE into this file"
+    convention) — a race regardless of what the declared work order says is
+    safe to parallelize. This is the same hazard :func:`plan_queue`'s
+    ``oracle_loop`` chaining closes for the drive-queue path; this is the
+    equivalent for the daemon's direct-dispatch paths
+    (``coord.serve_app._milestone_gate_tick``'s ``work`` state and the
+    legacy ``_milestone_drain_tick``), which call this function directly
+    rather than going through the drive-queue. Entries that would otherwise
+    have dispatched this tick are returned in :attr:`MilestonePlan.deferred`
+    instead of silently dropped; they re-enter ``ready`` on a later tick
+    once the dispatched entry is claimed (an active board assignment) and
+    falls out of the frontier on its own — see
+    :func:`~coord.milestone_order.ready_frontier`.
+
+    Deliberately coarse, mirroring ``plan_queue``: it withholds the ENTIRE
+    entry (not just its slice-authoring phase), a real throughput cost for
+    an oracle-loop milestone dispatched via the daemon in bulk. #2543
+    (per-issue manifest fragments) is what would let real concurrency come
+    back safely; this is defense-in-depth until it lands.
     """
     frontier = ready_frontier(
         work_order,
@@ -677,8 +734,12 @@ def plan_dispatch(
     )
     picks: list[MachinePick] = []
     skipped: list[NoMachineAvailable] = []
+    deferred: list[DeferredByOracleLoop] = []
     used: set[str] = set()
     for entry in frontier.ready:
+        if oracle_loop and picks:
+            deferred.append(DeferredByOracleLoop(entry))
+            continue
         machine = pick_machine(repo_cfg.name, board, config, exclude=frozenset(used))
         if machine is None:
             skipped.append(NoMachineAvailable(entry))
@@ -686,7 +747,10 @@ def plan_dispatch(
         used.add(machine.name)
         picks.append(MachinePick(entry, machine))
     return MilestonePlan(
-        to_dispatch=tuple(picks), skipped=tuple(skipped), waiting=frontier.blocked
+        to_dispatch=tuple(picks),
+        skipped=tuple(skipped),
+        waiting=frontier.blocked,
+        deferred=tuple(deferred),
     )
 
 
@@ -708,6 +772,8 @@ def plan_queue(
     work_order: WorkOrder,
     terminal_issues: frozenset[int] | set[int],
     repo_name: str,
+    *,
+    oracle_loop: bool = False,
 ) -> tuple[QueuePlanEntry, ...]:
     """Translate the work order's DAG into drive-queue enqueues (#2335).
 
@@ -724,6 +790,31 @@ def plan_queue(
     :func:`~coord.milestone_order.parse_work_order` already refused cycles,
     self-edges, and edges to undeclared nodes, so the sort always terminates;
     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
+    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
+    drive-queue's per-repo concurrency cap (``coord.drive_queue.plan_tick``)
+    launches both at once — each independently authoring its own JIT
+    acceptance slice into the SAME ``tests/acceptance/ms-N/manifest.yml``
+    (``coord.test_author``'s "later slices MERGE into this file"
+    convention), regardless of what the declared work order says is safe to
+    parallelize. This is exactly coord-portal#122's SECOND collision (#130
+    vs. #132, filed as #2542's correction) — ``validate_no_shared_oracle_
+    group`` only catches the explicit-group case, and this milestone's
+    entries shared no group at all.
+
+    Deliberately coarse: it serializes the entry's WHOLE dispatch (Work
+    through Merge), not just its slice-authoring phase, because the
+    drive-queue has no notion of "authoring" vs. "working" phases to hang a
+    narrower edge on. That is a real throughput cost for an oracle-loop
+    milestone dispatched in bulk — #2543 (giving each issue its own manifest
+    fragment instead of one shared appended file) is what would let real
+    concurrency come back safely; this is defense-in-depth until it lands.
     """
     from coord.drive_queue import entry_key  # noqa: PLC0415
 
@@ -746,16 +837,27 @@ def plan_queue(
         if not progressed:  # cycle — unreachable via parse_work_order; see above
             ordered.extend(remaining.values())
             break
-    return tuple(
-        QueuePlanEntry(
-            issue_number=n.issue_number,
-            after=tuple(
-                entry_key(repo_name, d) for d in n.after if d not in terminal
-            ),
-            group=n.group,
+
+    entries: list[QueuePlanEntry] = []
+    previous_issue_number: int | None = None
+    for n in ordered:
+        after_numbers = list(n.after)
+        if oracle_loop and (
+            previous_issue_number is not None
+            and previous_issue_number not in after_numbers
+        ):
+            after_numbers.append(previous_issue_number)
+        entries.append(
+            QueuePlanEntry(
+                issue_number=n.issue_number,
+                after=tuple(
+                    entry_key(repo_name, d) for d in after_numbers if d not in terminal
+                ),
+                group=n.group,
+            )
         )
-        for n in ordered
-    )
+        previous_issue_number = n.issue_number
+    return tuple(entries)
 
 
 @dataclass(frozen=True)

{code_coordinator-0.5.230 → code_coordinator-0.5.231}/coord/milestone_gate.py

@@ -637,17 +637,26 @@ def format_plan(
     to_dispatch: list = (),
     skipped: list = (),
     waiting: list = (),
+    deferred: list = (),
     footer: bool = True,
 ) -> list[str]:
     """Render a ``--dry-run`` report: the gate walk plus the work frontier.
 
-    ``to_dispatch``/``skipped``/``waiting`` come straight off a
+    ``to_dispatch``/``skipped``/``waiting``/``deferred`` come straight off a
     :class:`~coord.milestone_dispatch.MilestonePlan` (the same frontier
     ``coord milestone dispatch --dry-run`` prints), so the operator sees both
     halves of #1440's fourth acceptance bullet — every gate, *and* what would
     dispatch — in one output.  Returns lines rather than echoing so both the
     CLI and a test can consume it.
 
+    ``deferred`` (#2542) is populated only when the caller resolved
+    ``oracle_loop=True`` — entries the frontier considers ready but that the
+    `work` gate is deliberately holding back this tick so no two
+    same-milestone entries start authoring a JIT acceptance slice
+    concurrently. Rendered separately from ``skipped`` (no idle machine) so
+    the report never implies "we couldn't find a machine" for something
+    that's actually being serialized on purpose.
+
     ``footer`` controls whether the trailing blank line + "(dry run — ...)"
     line is included.  A non-dry-run confirmation (``coord milestone drive``
     without ``--dry-run``) wants the same report *without* that footer, since
@@ -702,6 +711,10 @@ def format_plan(
         lines.append("  Waiting on declared-order dependencies:")
         for b in waiting:
             lines.append(f"    #{b.issue_number}: {b.reason}")
+    if deferred:
+        lines.append("  Deferred (oracle-loop: one entry per tick):")
+        for d in deferred:
+            lines.append(f"    #{d.entry.issue_number}: {d.reason}")
 
     if footer:
         lines.append("")

{code_coordinator-0.5.230 → code_coordinator-0.5.231}/coord/milestone_order.py

@@ -111,6 +111,7 @@ __all__ = [
     "remove_sub_issues_section",
     "milestone_work_order_membership",
     "validate_milestone_membership",
+    "validate_no_shared_oracle_group",
     "FrontierEntry",
     "BlockedNode",
     "Frontier",
@@ -571,6 +572,66 @@ def validate_milestone_membership(
             )
 
 
+def validate_no_shared_oracle_group(
+    work_order: WorkOrder,
+    *,
+    oracle_loop: bool,
+) -> None:
+    """Refuse two `## Work order` nodes sharing a `{group: ...}` cohort when
+    the milestone is under oracle-loop control (#2542).
+
+    A ``group`` annotation declares its members safe to dispatch — and
+    therefore author their JIT acceptance slices (``coord acceptance
+    author``, docs/ORACLE_LOOP.md) — CONCURRENTLY. Every slice for one
+    milestone additively appends to the SAME file,
+    ``tests/acceptance/ms-N/manifest.yml`` (``coord.test_author``'s "later
+    slices MERGE into this file" convention), so two issues in the same
+    group race on that write regardless of whether their actual feature
+    work overlaps at all — the coupling is mechanical, not semantic, and
+    so invisible to ``coord.overlap_predict`` (#2247), which only reasons
+    about declared/real *diffs*. coord-portal#122 hit exactly this: #128
+    and #132 shared ``{group: A}`` because they looked feature-independent
+    (a schema change vs. a status override) and both authored slices into
+    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.
+
+    This is deliberately only the cheap, early check for the EXPLICIT-group
+    case — ``coord milestone write-order`` validates it before a word order
+    is ever written. It cannot catch two issues that share no declared
+    group but still end up concurrently eligible via the drive-queue's
+    per-repo concurrency cap (coord-portal#122's SECOND collision, #130 vs.
+    #132, filed as this issue's correction) — that hazard is closed
+    separately, by serializing the whole milestone's drive-queue ``after=``
+    chain (:func:`coord.milestone_dispatch.plan_queue`'s ``oracle_loop=``
+    parameter). Neither check alone is sufficient; see #2542.
+    """
+    if not oracle_loop:
+        return
+    by_group: dict[str, list[int]] = {}
+    for n in work_order.nodes:
+        if n.group:
+            by_group.setdefault(n.group, []).append(n.issue_number)
+    for group, numbers in by_group.items():
+        if len(numbers) > 1:
+            joined = ", ".join(f"#{i}" for i in numbers)
+            raise WorkOrderError(
+                f"work order: {joined} share group {group!r}, but this "
+                "milestone is under oracle-loop control (Gate A contract / "
+                "JIT test-author slices apply) — every issue's slice "
+                "additively appends to the SAME "
+                "tests/acceptance/ms-N/manifest.yml, so authoring them "
+                "concurrently races on that file regardless of whether the "
+                "issues' actual feature work overlaps (#2542). Sequence "
+                "them with `after:` instead of sharing a `group`."
+            )
+
+
 # ── Ready frontier ───────────────────────────────────────────────────────────
 
 

{code_coordinator-0.5.230 → code_coordinator-0.5.231}/coord/serve_app.py

@@ -1317,6 +1317,14 @@ 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
+    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.
+
     Extracted as a module-level function so tests can call it directly
     without wiring up the async ``_tick_loop`` infrastructure (mirrors
     ``_auto_drain_tick``'s doc comment above).
@@ -1390,7 +1398,15 @@ def _milestone_drain_tick(config: Config) -> list:
             )
             continue
 
-        plan = md.plan_dispatch(ctx.work_order, board, config, repo_cfg, ctx.terminal_issues)
+        # #2542: an oracle-loop repo (Gate A contract exists, JIT test-author
+        # slices apply) may only dispatch one ready-frontier entry per tick —
+        # see plan_dispatch's oracle_loop docstring for why (two concurrently
+        # dispatched entries under one milestone race on the same shared
+        # tests/acceptance/ms-N/manifest.yml).
+        plan = md.plan_dispatch(
+            ctx.work_order, board, config, repo_cfg, ctx.terminal_issues,
+            oracle_loop=config.acceptance.has_driver(repo_name),
+        )
         for pick in plan.to_dispatch:
             outcome = md.dispatch_entry(
                 pick, repo_cfg, config, board, tracking_issue=tracking_issue
@@ -1466,6 +1482,14 @@ 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``.
+
     Deliberately **not** gated on ``config.milestone.auto_dispatch`` — that
     flag gates the legacy standalone drain (:func:`_milestone_drain_tick`),
     whereas gate driving is opted into per milestone by an explicit ``coord
@@ -1557,8 +1581,20 @@ def _milestone_gate_tick(config: Config, *, now: float | None = None) -> list:
             # and _milestone_drain_tick use, so gate policy and dispatch
             # policy can't drift apart.
             try:
+                # #2542: cap this tick's dispatch to one entry for an
+                # oracle-loop milestone — see plan_dispatch's oracle_loop
+                # docstring. Without it, `plan_dispatch`'s normal N-ready ->
+                # N-idle-machine fan-out (by design, for non-oracle-loop
+                # milestones) lets two same-milestone entries both start
+                # their JIT slice-authoring phase in this single for-loop,
+                # racing on the same tests/acceptance/ms-N/manifest.yml —
+                # this is the "third, independent place" gap the write-order
+                # validator and plan_queue's chaining alone don't cover: the
+                # gate walk (docs/ORACLE_LOOP.md's "oracle drive", #1453) is
+                # the documented primary driver for an oracle-loop milestone.
                 plan = md.plan_dispatch(
-                    ctx.work_order, board, config, repo_cfg, ctx.terminal_issues
+                    ctx.work_order, board, config, repo_cfg, ctx.terminal_issues,
+                    oracle_loop=config.acceptance.has_driver(repo_cfg.name),
                 )
                 for pick in plan.to_dispatch:
                     outcome = md.dispatch_entry(

{code_coordinator-0.5.230 → code_coordinator-0.5.231}/tests/test_cli_milestone_dispatch.py

@@ -491,6 +491,109 @@ class TestMilestoneDispatchGateA:
         assert "Gate A" not in result.output
 
 
+class TestMilestoneDispatchOracleLoopSerializes:
+    """#2542: under oracle-loop control (an acceptance driver configured —
+    Gate A already satisfied by the `config_file_with_gate_a` fixture's
+    mocked contract), bulk `coord milestone dispatch` must chain the WHOLE
+    milestone into the drive-queue one entry at a time — the #130/#132
+    coord-portal#122 collision this issue's correction describes had no
+    shared `group` at all, so only the drive-queue translation itself (not
+    the write-order validator) can close it."""
+
+    def test_group_cohort_gets_a_serializing_after_edge(
+        self, config_file_with_gate_a: Path,
+    ) -> None:
+        """#762/#763 share {group: A} — plain (non-oracle) dispatch queues
+        them with no edge between them (see TestMilestoneDispatchBulk); under
+        an acceptance driver, #763 additionally gets `after api#762`."""
+        open_issues = [
+            {"number": 762, "milestone": {"number": 9}},
+            {"number": 763, "milestone": {"number": 9}},
+            {"number": 765, "milestone": {"number": 9}},
+        ]
+        with patch("coord.github_ops.get_issue", side_effect=_get_issue), \
+             patch("coord.github_ops.get_open_issues", return_value=open_issues), \
+             patch("coord.github_ops.get_repo_file", return_value="# Contract\n"), \
+             patch("coord.board_service.read_board", return_value=Board()), \
+             patch("coord.dispatch.dispatch") as disp:
+            result = CliRunner().invoke(
+                main,
+                ["milestone", "dispatch", "api", "100", "--config",
+                 str(config_file_with_gate_a)],
+            )
+        assert result.exit_code == 0, result.output
+        disp.assert_not_called()
+
+        rows = state_mod.list_drive_queue()
+        by_issue = {r["issue_number"]: r for r in rows}
+        assert by_issue[762]["after_json"] == []
+        assert by_issue[763]["after_json"] == ["api#762"]
+        # #765 was already declared `after: #762,#763` — unaffected by the
+        # implicit chain (its immediate predecessor, #763, is already there).
+        assert by_issue[765]["after_json"] == ["api#762", "api#763"]
+
+    def test_ungrouped_independent_issues_still_get_chained(
+        self, config_file_with_gate_a: Path,
+    ) -> None:
+        """The SECOND coord-portal#122 collision (#130 vs. #132): no shared
+        group, no declared `after` between them at all — the drive-queue's
+        per-repo concurrency cap alone would launch both. Confirms the fix
+        isn't scoped to the explicit-group case."""
+        body = "## Work order\n- [ ] #762\n- [ ] #763\n"
+        open_issues = [
+            {"number": 762, "milestone": {"number": 9}},
+            {"number": 763, "milestone": {"number": 9}},
+        ]
+
+        def get_issue(repo, number):
+            return _get_issue(repo, number, bodies={100: body})
+
+        with patch("coord.github_ops.get_issue", side_effect=get_issue), \
+             patch("coord.github_ops.get_open_issues", return_value=open_issues), \
+             patch("coord.github_ops.get_repo_file", return_value="# Contract\n"), \
+             patch("coord.board_service.read_board", return_value=Board()), \
+             patch("coord.dispatch.dispatch") as disp:
+            result = CliRunner().invoke(
+                main,
+                ["milestone", "dispatch", "api", "100", "--config",
+                 str(config_file_with_gate_a)],
+            )
+        assert result.exit_code == 0, result.output
+        disp.assert_not_called()
+
+        rows = state_mod.list_drive_queue()
+        by_issue = {r["issue_number"]: r for r in rows}
+        assert by_issue[762]["after_json"] == []
+        assert by_issue[763]["after_json"] == ["api#762"]
+
+    def test_repo_without_acceptance_driver_is_not_chained(
+        self, config_file: Path,
+    ) -> None:
+        """No acceptance driver configured -> not under oracle-loop control
+        -> the group cohort dispatches exactly as before #2542 (no implicit
+        edge)."""
+        open_issues = [
+            {"number": 762, "milestone": {"number": 9}},
+            {"number": 763, "milestone": {"number": 9}},
+            {"number": 765, "milestone": {"number": 9}},
+        ]
+        with patch("coord.github_ops.get_issue", side_effect=_get_issue), \
+             patch("coord.github_ops.get_open_issues", return_value=open_issues), \
+             patch("coord.board_service.read_board", return_value=Board()), \
+             patch("coord.dispatch.dispatch") as disp:
+            result = CliRunner().invoke(
+                main,
+                ["milestone", "dispatch", "api", "100", "--config", str(config_file)],
+            )
+        assert result.exit_code == 0, result.output
+        disp.assert_not_called()
+
+        rows = state_mod.list_drive_queue()
+        by_issue = {r["issue_number"]: r for r in rows}
+        assert by_issue[762]["after_json"] == []
+        assert by_issue[763]["after_json"] == []
+
+
 class TestMilestoneDispatchGateControlled:
     """#1930 (epic #1440 S-2): a milestone under gate control (``coord
     milestone drive``) is drained exclusively by the daemon's gate tick.