code-coordinator 0.5.329__tar.gz → 0.5.331__tar.gz

{code_coordinator-0.5.329 → code_coordinator-0.5.331}/PKG-INFO

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

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

@@ -1,7 +1,7 @@
 {
-  "tag": "0.5.329",
+  "tag": "0.5.331",
   "distance": 0,
-  "node": "g620161040c983239a8258b25aa0e4e1fc5cf3c8a",
+  "node": "g73f327b8112ca3cfc50ce512371659afb1a4c411",
   "dirty": false,
   "branch": "HEAD",
   "node_date": "2026-08-31"

{code_coordinator-0.5.329 → code_coordinator-0.5.331}/coord/commands/drive_queue.py

@@ -80,9 +80,12 @@ from coord.drive_queue import (
     find_cycle,
     fired_holds,
     is_dispatch_failure_reason,
+    is_merge_gate_block_reason,
     is_permanent_block_reason,
     is_pre_dispatch_block_reason,
     is_unsatisfiable_prereq_reason,
+    merge_gate_remedy_command,
+    merge_plan_inspect_command,
     parse_after_spec,
     parse_key,
     pending_probe_targets,
@@ -4526,6 +4529,30 @@ def _requeue_command(entry: QueueEntry | None, key: str) -> str:
     )
 
 
+def _blocked_escalation_command(entry: QueueEntry | None, key: str, reason: str) -> str:
+    """The command a `blocked`/`oscillating` escalation should propose
+    (#3016) — `_requeue_command` ONLY for a genuinely never-dispatched entry;
+    a gate-specific remedy (or the safe read-only inspect fallback) whenever
+    *reason* already names a merge-gate block.
+
+    `_requeue_command` is right exactly once: nothing was ever dispatched
+    for this row (or every dispatch attempt died before an assignment
+    existed), so there is nothing left to lose by dropping and re-adding it.
+    But `is_merge_gate_block_reason` names the other shape — Work/Test/
+    Review already completed and it is the MERGE stage that is stuck — where
+    the same requeue would discard that completed cycle instead of fixing
+    the one gate actually blocking it. `merge_gate_remedy_command` is the
+    one place that maps a merge-gate reason to its safe one-line fix (or, if
+    none is known blind, the inspect command); this only decides WHICH of
+    the two families applies.
+    """
+    if is_merge_gate_block_reason(reason):
+        parsed = parse_key(key)
+        if parsed is not None:
+            return merge_gate_remedy_command(reason, parsed[0], parsed[1])
+    return _requeue_command(entry, key)
+
+
 @drive_queue_group.command("tick")
 @click.option(
     "--max-parallel",
@@ -5071,7 +5098,7 @@ def drive_queue_tick(
                     f"{entry.position if entry else '?'} | after="
                     f"{','.join(entry.after) if entry and entry.after else '(none)'}"
                 ),
-                command=_requeue_command(entry, item.key),
+                command=_blocked_escalation_command(entry, item.key, item.reason),
             )
 
         # #2230: an entry #2230's sweep would have resumed, but has already
@@ -5098,7 +5125,7 @@ def drive_queue_tick(
                     f"/{MAX_BLOCKED_RESUMES} | position="
                     f"{entry.position if entry else '?'}"
                 ),
-                command=_requeue_command(entry, item.key),
+                command=_blocked_escalation_command(entry, item.key, item.reason),
             )
 
         # #2806: a `blocked` entry #2230's sweep targeted this tick, but whose
@@ -5117,6 +5144,14 @@ def drive_queue_tick(
             if parsed is None:
                 continue
             entry = by_key.get(item.key)
+            # #3016: NEVER the `remove && add` requeue here — `item.reason`
+            # already says "the next tick re-probes rather than guessing"
+            # (#2806); a destructive requeue directly contradicts that, and
+            # would additionally discard a completed Work/Test/Review cycle
+            # for no reason connected to what actually failed (a probe, not
+            # a gate). The read-only inspect command is the only thing safe
+            # to propose when the tick itself does not yet know what shape
+            # this block is.
             _escalate(
                 parsed[0],
                 parsed[1],
@@ -5125,7 +5160,7 @@ def drive_queue_tick(
                     f"queue_state=blocked | gate_reading=unreadable | "
                     f"position={entry.position if entry else '?'}"
                 ),
-                command=_requeue_command(entry, item.key),
+                command=merge_plan_inspect_command(parsed[0]),
             )
 
         if plan.alert is not None:

{code_coordinator-0.5.329 → code_coordinator-0.5.331}/coord/drive_queue.py

@@ -94,6 +94,7 @@ from coord.gate_a import is_gate_a_refusal_reason
 from coord.github_ops import is_throttle_skip_reason, parse_throttle_skip_until
 from coord.issues_sync_status import STALENESS_WARN_SECONDS as ISSUE_CACHE_STALE_CEILING_S
 from coord.merge_queue import (
+    CI_STALE_PREFIX,
     PLAN_READY,
     ci_rollup_all_clear,
     is_ci_flaky_reason,
@@ -2746,6 +2747,74 @@ def _is_merge_gate_block_reason(reason: str | None) -> bool:
     return "merge_status=" in lowered
 
 
+def merge_plan_inspect_command(repo: str) -> str:
+    """The read-only ``coord merge --plan`` fallback (#3016) — safe to
+    propose whenever no specific, blind-runnable remedy is known, because it
+    never mutates anything. Used both as :func:`merge_gate_remedy_command`'s
+    own fallback and directly by callers escalating a #2806 ``gate_unreadable``
+    outcome, whose reason text already says "the next tick re-probes" — the
+    destructive `remove && add` requeue would directly contradict that.
+    """
+    return f"coord merge --plan --repo {repo}"
+
+
+def merge_gate_remedy_command(reason: str | None, repo: str, issue: int) -> str:
+    """The gate-specific one-line fix for a `_is_merge_gate_block_reason`
+    block (#3016) — never the blanket ``drive-queue remove && add`` requeue
+    a synthetic escalation writer would otherwise reach for by default.
+
+    A requeue is not merely useless for a merge-gate block, it is actively
+    destructive: it discards a completed Work/Test/Review cycle to re-run it
+    from scratch, when the real fix is a single, targeted merge-lane command
+    — exactly the misdirection `_is_merge_gate_block_reason`'s own docstring
+    already names two live escalations (claude-coordinator#2405, coord-web#2)
+    as having produced, and #2424 only fixed on the prose (``reason``) side,
+    leaving this — the field a one-click "Run proposed fix" menu actually
+    executes — untouched.
+
+    Only the CI-stale / stale-but-passed-smoke shape has a remedy that is
+    both KNOWN and SAFE to run blind: ``coord merge --revalidate --only
+    <repo>#<issue>``, the exact command :func:`coord.merge_queue.
+    ci_stale_reason`'s own prose already tells the operator to run (matched
+    textually here — via :data:`coord.merge_queue.CI_STALE_PREFIX` and
+    :func:`is_stale_smoke_reason` — rather than re-derived, so the two can
+    never diverge on what "CI stale" means).
+
+    Every other shape this matches — red CI (``checks failed``), a
+    review/smoke gate divergence (``review_required —``/``smoke_required
+    —``), an opaque terminal ``merge_status=`` — has no single command that
+    is always both correct and safe to run without a human first reading
+    the actual gate state (fixing a named CI check, recovering or re-running
+    a review, deciding a UAT verdict). Guessing wrong there is worse than
+    not guessing: the menu this feeds runs the command on one click. So
+    every one of those falls back to the read-only inspect command instead
+    — see #3016's design note ("a wrong 'Recommended' is worse than no
+    recommendation").
+
+    Callers are expected to gate on :func:`_is_merge_gate_block_reason`
+    first; called on a reason that ISN'T a merge-gate block at all, this
+    still returns the safe inspect fallback rather than raising — there is
+    no reason this text-matching helper needs to enforce that precondition
+    itself when a wrong answer here is never destructive.
+    """
+    if reason and (
+        CI_STALE_PREFIX.lower() in reason.lower() or is_stale_smoke_reason(reason)
+    ):
+        return f"coord merge --revalidate --only {entry_key(repo, issue)}"
+    return merge_plan_inspect_command(repo)
+
+
+def is_merge_gate_block_reason(reason: str | None) -> bool:
+    """Public alias for :func:`_is_merge_gate_block_reason` (#3016).
+
+    Same convention as ``is_empty_branch_death_reason``/
+    ``is_unsatisfiable_prereq_reason``: the classifier is shared with the
+    synthetic escalation writers in ``coord.commands.drive_queue``, so it
+    gets a non-underscored name rather than a second copy of the text match.
+    """
+    return _is_merge_gate_block_reason(reason)
+
+
 def _is_empty_branch_death_reason(reason: str | None) -> bool:
     """#2363: does *reason* name the "claimed success, wrote nothing"
     signature — an acceptance-author or plain work session that exited

{code_coordinator-0.5.329 → code_coordinator-0.5.331}/coord/serve_app.py

@@ -2547,7 +2547,8 @@ def _board_response_schema(components: dict) -> dict:
                     "#550: server-computed per-issue stage/gate badges "
                     "(work/review/smoke/test/merge status, has_approved_review) — "
                     "generalizes the #776/#778 pattern so coord-tui's "
-                    "pipeline.rs stops re-deriving this from raw rows"
+                    "pipeline.rs stops re-deriving this from raw rows. #3013 adds "
+                    "a per-stage leg count (`stage_counts`) alongside the status."
                 ),
                 "items": {
                     "type": "object",
@@ -2560,6 +2561,24 @@ def _board_response_schema(components: dict) -> dict:
                             "description": "stage name -> pending|active|done|failed|stale|skipped",
                             "additionalProperties": {"type": "string"},
                         },
+                        "stage_counts": {
+                            "type": "object",
+                            "description": (
+                                "#3013: stage name -> count of separate dispatched "
+                                "legs at that stage (e.g. a stage re-dispatched 4 "
+                                "times reads 4, not 1) — lets a client render "
+                                "'Work (2)' / 'Review (5)' and suppress the suffix "
+                                "at 1. Same key set as `stages` (including "
+                                "`acceptance`). Caveat: `merge` uses a different "
+                                "convention from every other key — it counts "
+                                "conflict-fix RETRIES (0 for a clean single merge, "
+                                "not 1 for 'one attempt happened'), so a uniform "
+                                "'suppress at <= 1' rule will also suppress a "
+                                "single conflict-fix retry, which is usually the "
+                                "most useful count to surface."
+                            ),
+                            "additionalProperties": {"type": "integer"},
+                        },
                         "has_approved_review": {"type": "boolean"},
                         "uat_preview_url": {
                             "type": ["string", "null"],
@@ -2571,7 +2590,13 @@ def _board_response_schema(components: dict) -> dict:
                             ),
                         },
                     },
-                    "required": ["repo_name", "issue_number", "stages", "has_approved_review"],
+                    "required": [
+                        "repo_name",
+                        "issue_number",
+                        "stages",
+                        "stage_counts",
+                        "has_approved_review",
+                    ],
                 },
             },
             "plan_roster": {

{code_coordinator-0.5.329 → code_coordinator-0.5.331}/coord/stage_projection.py

@@ -31,9 +31,10 @@ plain values — no I/O, no side effects.
 
 from __future__ import annotations
 
+import dataclasses
 from typing import Any, Protocol, runtime_checkable
 
-from coord.models import CLOSES_ISSUE_TYPES
+from coord.models import CLOSES_ISSUE_TYPES, WORK_LIKE_TYPES, effective_issue_number
 
 # ── Stage-status vocabulary — mirrors tui/src/app/pipeline.rs::StageStatus ──
 PENDING = "pending"
@@ -172,6 +173,102 @@ def assignments_for_stage(
     return out
 
 
+def _leg_count_for_stage(
+    assignments_for_issue: list,
+    stage: str,
+    *,
+    require_plan: bool,
+) -> int:
+    """How many separate dispatched attempts ("legs") this issue has had at
+    *stage* (#3013) — "attempts a human would recognise as separate", not a
+    raw row count. Each retry/redispatch is already its own board row (a
+    retry dispatches a fresh assignment id rather than mutating the failed
+    one, see ``coord.reconcile._reassign``), so counting rows already gives
+    the right number for stages backed by their own dedicated assignment
+    ``type`` — this only needs to special-case the stages that aren't:
+
+    * ``"work"`` is widened from a literal ``type == "work"`` (plus the
+      existing plan-fold) to the full :data:`WORK_LIKE_TYPES` — an
+      oracle-loop acceptance slice's repeated ``test-author``/``mock-author``
+      legs (#3013's coord-portal#164 example: 4 ``test-author`` legs, 5
+      ``review`` legs on one branch) are exactly the kind of repetition this
+      field exists to surface, and a strict ``type == "work"`` match would
+      never see them.
+    * ``"test"`` has no ``type="test"`` assignment — the Test-stage's
+      dispatched worker is ``type="smoke"`` (``coord.smoke``).
+    * ``"merge"`` has no ``type="merge"`` assignment either — repeated
+      landing attempts show up as ``type="conflict-fix"`` legs (#241). Note
+      the counting convention this implies differs from every other stage:
+      a clean single merge with no conflict reports ``0`` (no *retry* was
+      needed), whereas one ordinary ``"work"``/``"review"``/``"test"`` leg
+      reports ``1`` (one attempt happened). A client applying one uniform
+      "suppress the number at <= 1" rule across every stage — as the
+      ``/board`` schema description implies — will suppress a single
+      conflict-fix leg (``count == 1``, arguably the most useful case to
+      surface: "this needed a rebase") exactly like "no problem at all". No
+      code path here can distinguish the two without a wire-schema change,
+      so this is flagged for the client rather than fixed on this side.
+    * ``"acceptance"`` (review fix, #3013) has no dedicated assignment type
+      either — like ``test_state``/``uat_state``, ``acceptance_state`` is
+      stamped directly onto the ``type="work"`` row a
+      ``coord acceptance record`` verdict belongs to (see
+      :func:`acceptance_stage_status_for`, which reads the same rows), so a
+      generic ``assignments_for_stage(..., "acceptance", ...)`` scan would
+      always return zero.
+
+    Every other stage (``"plan"``, ``"review"``, ``"uat"``, ...) already has
+    a 1:1 assignment ``type``, so :func:`assignments_for_stage` alone gives
+    the right count.
+    """
+    if stage == "work":
+        matching = assignments_for_stage(assignments_for_issue, "work", require_plan=require_plan)
+        seen = {id(a) for a in matching}
+        extra = [
+            a
+            for a in assignments_for_issue
+            if id(a) not in seen and (a.type or "work") in WORK_LIKE_TYPES
+        ]
+        return len(matching) + len(extra)
+    if stage == "test":
+        return sum(1 for a in assignments_for_issue if (a.type or "work") == "smoke")
+    if stage == "merge":
+        return sum(1 for a in assignments_for_issue if (a.type or "work") == "conflict-fix")
+    if stage == "acceptance":
+        return sum(
+            1
+            for a in assignments_for_issue
+            if (a.type or "work") == "work" and (a.acceptance_state or "") != ""
+        )
+    return len(assignments_for_stage(assignments_for_issue, stage, require_plan=require_plan))
+
+
+def _widen_work_like_types(assignments: list) -> list:
+    """Return *assignments* with every :data:`WORK_LIKE_TYPES` row (#3013:
+    ``mock-author``/``test-author``, not just literal ``type="work"``)
+    presented as ``type="work"`` to the generic per-stage dispatcher
+    (:func:`stage_status_for`, :func:`assignments_for_stage`,
+    :func:`acceptance_stage_status_for`, ...), all of which key strictly off
+    ``a.type``.
+
+    Used ONLY by :func:`compute_board_stage_projection`'s phantom-entry
+    fallback (see that function's docstring) — without it, a slice whose
+    only rows are ``test-author``/``mock-author`` legs got
+    ``stage_counts["work"] == 4`` (via :func:`_leg_count_for_stage`, which
+    already widens the same way) sitting next to ``stages["work"] ==
+    "pending"`` forever, since the strict-``type`` dispatcher never
+    recognised those rows as "work" activity. Every other field (status,
+    dispatched_at, test_state, acceptance_state, ...) is preserved
+    unchanged — this only relabels the ``type`` a downstream ``==`` check
+    sees.
+    """
+    out = []
+    for a in assignments:
+        t = a.type or "work"
+        widen = t in WORK_LIKE_TYPES and t != "work"
+        out.append(dataclasses.replace(a, type="work") if widen else a)
+    return out
+
+
 def upstream_max_dispatched_at(
     assignments_for_issue: list,
     stage: str,
@@ -698,6 +795,7 @@ def compute_issue_projection(
     ci_store: Any | None = None,
     uat_enabled: bool = False,
     uat_preview_url: str | None = None,
+    stage_count_assignments: list | None = None,
 ) -> dict[str, Any]:
     """Compute the full per-issue stage badge dict.
 
@@ -717,6 +815,15 @@ def compute_issue_projection(
     carried through unconditionally so a caller can show it next to the
     badge instead of sending the operator to ``coord merge``'s refusal
     message to find it (#2951 item 3).
+
+    ``stage_count_assignments`` (#3013) is the assignment list
+    :func:`_leg_count_for_stage` scans to fill ``stage_counts`` — a client
+    can then render ``Work (2)`` / ``Review (5)`` next to the status badge
+    and suppress the suffix at 1. Defaults to *assignments_for_issue* (the
+    same list ``stages`` uses) when omitted, which is correct for an
+    ordinary issue; :func:`compute_board_stage_projection` passes a
+    separately-keyed list for the #1553 oracle-loop epic/slice case — see
+    that function's docstring.
     """
     names = issue_stage_names(assignments_for_issue, default_gates, uat_enabled=uat_enabled)
     stages: dict[str, str] = {}
@@ -741,8 +848,29 @@ def compute_issue_projection(
     # excluded from the per-issue stage-strip ordering that `default_gates`
     # drives, since it only applies to oracle-loop milestones.
     stages["acceptance"] = acceptance_stage_status_for(assignments_for_issue)
+
+    count_source = (
+        assignments_for_issue if stage_count_assignments is None else stage_count_assignments
+    )
+    stage_counts: dict[str, int] = {
+        name: _leg_count_for_stage(count_source, name, require_plan=require_plan) for name in names
+    }
+    stage_counts.setdefault(
+        "merge", _leg_count_for_stage(count_source, "merge", require_plan=require_plan)
+    )
+    # Review fix (#3013): `stages` always carries "acceptance" (added
+    # unconditionally above, outside `names`/`default_gates`), but
+    # `stage_counts` was built only from `names` plus an explicit "merge"
+    # fallback — so it silently dropped "acceptance", contradicting the
+    # `/board` schema's documented "same key set as `stages`" guarantee
+    # (coord/serve_app.py) and leaving a client that indexes `stage_counts`
+    # by every key in `stages` with a plain `KeyError`.
+    stage_counts.setdefault(
+        "acceptance", _leg_count_for_stage(count_source, "acceptance", require_plan=require_plan)
+    )
     return {
         "stages": stages,
+        "stage_counts": stage_counts,
         "acceptance_progress": acceptance_progress_for(assignments_for_issue),
         "uat_preview_url": uat_preview_url if uat_enabled else None,
         "has_approved_review": issue_has_any_approved_review(
@@ -779,6 +907,44 @@ def compute_board_stage_projection(
     ``None`` (the default — e.g. a caller with no config loaded) means no
     repo is treated as opted in, matching :func:`pipeline_stage_names`'s own
     fail-toward-hidden default.
+
+    ``stage_counts`` (#3013) is deliberately built from a SECOND index keyed
+    by ``coord.models.effective_issue_number`` rather than the raw
+    ``assignments_by_key`` below: an oracle-loop acceptance slice's
+    ``test-author``/``mock-author``/``review`` legs are booked
+    (``issue_number``) to the milestone's *tracking* issue, with the child
+    they're actually FOR named in ``for_issue_number`` (see
+    ``coord gates <repo> <slice>``, which resolves the same way). Reusing
+    ``assignments_by_key`` for the count would leave a slice's own
+    ``stage_counts`` reading 0 forever — the same keying trap noted in the
+    #3013 issue's "drive-queue sweep bug" reference. For an issue that ALSO
+    has its own raw-keyed rows, this does NOT touch ``stages``: that stays
+    keyed on the raw ``issue_number`` on purpose (#1652 — re-attributing
+    status by ``for_issue_number`` moved a false "merged" green from the
+    epic onto a child that already had its own, separately-tracked state; a
+    leg *count* carries no such false-green risk, so the two fields are
+    allowed to disagree on which issue owns which rows in that case).
+
+    Review fix (#3013): a *phantom* entry — ANY key whose raw-keyed
+    assignment list is empty, whether it exists in ``issues`` with no
+    assignments of its own (the coord-portal#164 test below: the slice IS
+    already synced, but every one of its legs is booked to the tracking
+    issue) or exists ONLY via the effective-key union (never synced at all:
+    not yet caught up by ``_sync_issues_tick``, or a closed slice pruned
+    from ``issues`` after 7 days while assignment retention runs 14, see
+    ``coord/state.py``) — has nothing raw-keyed to protect from the #1652
+    clobber, because there IS no separately-tracked state for it to
+    conflict with. Rendering ``stages`` from the empty raw list anyway
+    produced a self-contradictory row: every stage PENDING (acceptance
+    SKIPPED) right next to a ``stage_counts`` proving real legs ran. So for
+    that case only, ``stages``/``acceptance``/``has_approved_review`` fall
+    back to the same effective-keyed list ``stage_counts`` already uses,
+    widened through :func:`_widen_work_like_types` so a `test-author`/
+    `mock-author` leg registers as "work" activity to the generic
+    per-stage dispatcher — see the ``projection_assignments`` fallback
+    below. ``issue_title`` still reads ``""`` for a phantom entry that
+    isn't itself in ``issues`` (genuinely unknown — not fabricated from the
+    tracking issue's own title, which would be actively wrong).
     """
     is_closed_by_key: dict[tuple[str, int], bool] = {
         (i["repo_name"], i["number"]): str(i.get("state", "")).lower() == "closed"
@@ -794,6 +960,17 @@ def compute_board_stage_projection(
             continue
         assignments_by_key.setdefault((a.repo_name, a.issue_number), []).append(a)
 
+    # #3013: effective-issue-keyed index — see docstring above. Used only to
+    # fill `stage_counts`, never `stages`.
+    assignments_by_effective_key: dict[tuple[str, int], list] = {}
+    for a in assignments:
+        if not a.repo_name:
+            continue
+        eff = effective_issue_number(a)
+        if not eff:
+            continue
+        assignments_by_effective_key.setdefault((a.repo_name, eff), []).append(a)
+
     merge_by_key: dict[tuple[str, int], Any] = {}
     for m in merge_queue_items:
         assignment_type = getattr(m, "assignment_type", "work") or "work"
@@ -815,7 +992,11 @@ def compute_board_stage_projection(
         # `load_queue()`/`board_projection()` both order by `id` ascending.
         merge_by_key.setdefault(key, m)
 
-    keys = set(is_closed_by_key) | set(assignments_by_key)
+    # #3013: also union in the effective-key index so an acceptance slice
+    # whose only board rows are booked to the tracking issue (nothing keyed
+    # to the slice's own issue_number, e.g. never separately synced) still
+    # gets a projection row for stage_counts to land in.
+    keys = set(is_closed_by_key) | set(assignments_by_key) | set(assignments_by_effective_key)
 
     uat_enabled_by_repo: dict[str, bool] = {}
 
@@ -823,12 +1004,25 @@ def compute_board_stage_projection(
     for repo_name, issue_number in keys:
         key = (repo_name, issue_number)
         issue_assignments = assignments_by_key.get(key, [])
+        effective_assignments = assignments_by_effective_key.get(key, [])
+        # Review fix (#3013): a phantom entry (see docstring) has no
+        # raw-keyed rows at all, so falling back to the effective-keyed list
+        # here — instead of leaving `stages` computed from `[]` — keeps
+        # `stages`/`acceptance`/`has_approved_review` consistent with the
+        # non-zero `stage_counts` this same entry reports below. Widened
+        # through `_widen_work_like_types` so a `test-author`/`mock-author`
+        # leg (WORK_LIKE_TYPES, not literal `type="work"`) registers with
+        # the generic per-stage dispatcher's strict `type` check the same
+        # way `_leg_count_for_stage` already widens it for `stage_counts`.
+        # A no-op for every ordinary issue: `issue_assignments or ...` only
+        # reaches the fallback when the raw list is empty.
+        projection_assignments = issue_assignments or _widen_work_like_types(effective_assignments)
         merge_entry = merge_by_key.get(key)
         if repo_name not in uat_enabled_by_repo:
             uat_enabled_by_repo[repo_name] = repo_has_uat_preview(repo_name, config)
         uat_enabled = uat_enabled_by_repo[repo_name]
         entry = compute_issue_projection(
-            issue_assignments,
+            projection_assignments,
             merge_entry,
             is_closed=is_closed_by_key.get(key, False),
             require_plan=require_plan,
@@ -840,6 +1034,7 @@ def compute_board_stage_projection(
                 if uat_enabled
                 else None
             ),
+            stage_count_assignments=effective_assignments,
         )
         entry["repo_name"] = repo_name
         entry["issue_number"] = issue_number

{code_coordinator-0.5.329 → code_coordinator-0.5.331}/tests/test_cli_drive_queue.py

@@ -1987,6 +1987,78 @@ def test_a_dead_drives_own_exit_reason_reaches_the_queue_row(
     assert state._get_drive_escalation_local(REPO, 1762) is not None
 
 
+def test_exhausted_ci_stale_escalation_proposes_revalidate_not_a_requeue(
+    cli, seed, launches, coord_db, config_file
+):
+    """#3016 regression fixture — the exact claude-coordinator#2983 shape
+    (2026-08-31), rendered end-to-end through the real `coord drive-queue
+    tick` -> escalation write -> `coord escalate list` path: a merge-gate
+    death whose OWN reason already names `coord merge --revalidate` as the
+    fix must not have the escalation's `proposed_command` — the ONE field a
+    one-click "Run proposed fix" menu actually runs — propose the blanket
+    `drive-queue remove && add` requeue instead. #2424 already fixed the
+    parallel misdirection in the `reason` prose; this pins the field that
+    executes.
+    """
+    from coord.audit import record_audit
+
+    seed(issues={2983: "open"})
+    cli("add", REPO, "2983")
+    cli("tick")
+
+    def _own_reason(n: int) -> str:
+        return (
+            f"drive exited for {REPO}#2983 (exit_code=1): merge attempted "
+            f"3 times without landing.\n"
+            "   Last board state: status='PENDING' reason='CI stale: checks "
+            "predate the current base (...); auto-rerun budget exhausted "
+            "(2/2) — re-run CI (`coord merge --revalidate`) before merging'"
+            f" (attempt {n})"
+        )
+
+    launched_at = queued(2983)["launched_at"]
+    _backdate(2983, DRIVE_STARTUP_GRACE_SECONDS + 60)
+    record_audit(
+        tier="business", category="drive", event_type="drive_exited",
+        actor="drive", summary=_own_reason(1), repo=REPO, issue=2983,
+        ts=launched_at + 5,
+    )
+    cli("tick")
+
+    _backdate_reason(coord_db, 2983, DRIVE_STARTUP_GRACE_SECONDS + 60)
+    relaunch = cli("tick")
+    assert relaunch.exit_code == 0, relaunch.output
+    assert queued(2983)["state"] == "running"
+
+    launched_at = queued(2983)["launched_at"]
+    _backdate(2983, DRIVE_STARTUP_GRACE_SECONDS + 60)
+    record_audit(
+        tier="business", category="drive", event_type="drive_exited",
+        actor="drive", summary=_own_reason(2), repo=REPO, issue=2983,
+        ts=launched_at + 5,
+    )
+    second_retry = cli("tick")
+    assert second_retry.exit_code == 0, second_retry.output
+
+    entry = queued(2983)
+    assert entry["state"] == "blocked"
+
+    listing = CliRunner().invoke(
+        main, ["escalate", "list", "--config", str(config_file)]
+    )
+    assert listing.exit_code == 0, listing.output
+    assert f"{REPO} #2983" in listing.output
+    assert "coord merge --revalidate" in listing.output
+    assert f"--only {REPO}#2983" in listing.output
+    assert "drive-queue remove" not in listing.output
+    assert "drive-queue add" not in listing.output
+
+    escalation = state._get_drive_escalation_local(REPO, 2983)
+    assert escalation is not None
+    proposed = escalation["proposed_command"]
+    assert proposed == f"coord merge --revalidate --only {REPO}#2983"
+
+
 def test_a_permanent_dispatch_refusal_blocks_on_the_first_tick_no_attempt_spent(
     cli, seed, launches,
 ):