code-coordinator 0.5.496__tar.gz → 0.5.498__tar.gz

{code_coordinator-0.5.496 → code_coordinator-0.5.498}/PKG-INFO

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

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

@@ -1,7 +1,7 @@
 {
-  "tag": "0.5.496",
+  "tag": "0.5.498",
   "distance": 0,
-  "node": "gdcf7e4331cfa3d1b0c95e0e3450402c3c49a6723",
+  "node": "g99081c11bad4947401aaeef6ccd4301a2b450952",
   "dirty": false,
   "branch": "HEAD",
   "node_date": "2026-09-19"

{code_coordinator-0.5.496 → code_coordinator-0.5.498}/coord/commands/drive_queue.py

@@ -35,7 +35,7 @@ import socket
 import subprocess
 import time
 from pathlib import Path
-from typing import TYPE_CHECKING, Any, Mapping
+from typing import TYPE_CHECKING, Any, Mapping, Sequence
 
 import click
 
@@ -111,6 +111,7 @@ from coord.overlap_predict import (
     EVENT_SCORED,
     OUTCOME_UNKNOWN,
     SOURCE_DECLARED,
+    Overlap,
     Prediction,
     classify_outcome,
     collect_candidate_files,
@@ -118,6 +119,7 @@ from coord.overlap_predict import (
     fanout_warnings,
     inflight_footprints,
     malformed_files_warning,
+    overlap_would_run_before,
     parse_declared_files,
     predict_overlap,
     predictions_from_audit,
@@ -465,12 +467,38 @@ def drive_queue_add(
     malformed_note = ""
     auto_after: list[str] = []
     rejected_after: list[str] = []
+    # #3395 rule 2: overlaps against an already-queued, not-yet-dispatched
+    # entry that THIS add is positioning ahead of — the edge for those goes
+    # on the INCUMBENT (`entry --after this add`), applied further down once
+    # this add's own row exists, never on `after` above (that would chain
+    # this add behind an entry it is about to run in front of).
+    reverse_candidates: list[tuple[QueueEntry, Overlap]] = []
+    reverse_rejected: list[str] = []
     if not no_predict_overlap:
         prediction, staleness_note, malformed_note = _predict_overlap(
             config_path, repo, issue, existing_entries
         )
+        effective_position = _resolve_effective_new_position(position, previous)
+        forward_keys, all_reverse = _partition_overlap_after(
+            existing_entries,
+            effective_position,
+            prediction,
+            previous_position=previous.position if previous is not None else None,
+        )
+        # #2603's --reject-after is the same narrower escape hatch for a
+        # REVERSED edge too — it names the OTHER entry's key either way, so
+        # an operator does not need to know which direction rule 2 picked to
+        # veto it.
+        reverse_candidates = [
+            (entry, overlap) for entry, overlap in all_reverse
+            if entry.key not in reject_after
+        ]
+        reverse_rejected = [
+            entry.key for entry, _overlap in all_reverse if entry.key in reject_after
+        ]
         candidate_after = _applicable_auto_after(
-            existing_entries, repo, issue, after, prediction
+            existing_entries, repo, issue, after, prediction,
+            candidate_keys=forward_keys,
         )
         # #2603: --reject-after is the narrower escape hatch — it drops only
         # the named edge(s) from what actually gets applied, never the whole
@@ -493,6 +521,18 @@ def drive_queue_add(
         no_acceptance=no_acceptance,
         plan_destructive=plan_destructive,
     )
+    # #3395: apply the REVERSED edges rule 2 selected — writing to the
+    # INCUMBENT entry's own row, now that this add's row exists to name as
+    # its `--after`. Must run after the write above: it names `entry_key
+    # (repo, issue)` as a pre-req, and while nothing here checks the row for
+    # existence, doing this first keeps the audit trail (both events land in
+    # enqueue order, not out of order relative to `queued ...`) intuitive to
+    # read back.
+    reverse_applied: list[tuple[QueueEntry, Overlap]] = []
+    if reverse_candidates:
+        reverse_applied = _apply_reversed_overlap_after(
+            existing_entries, entry_key(repo, issue), after, reverse_candidates,
+        )
     # #2839: queueing a drive is a strictly STRONGER statement than "send to
     # Pipeline" (`coord track`), so it must never leave the issue in a
     # weaker label state — apply the same `coord` + `status:ready` labels
@@ -542,13 +582,22 @@ def drive_queue_add(
     # --reject-after confirmation above: an author who wrote a declaration
     # that never took must not see output byte-identical to "declared
     # nothing".
+    # #3395: plus, for every REVERSED edge rule 2 applied, a line naming the
+    # INCUMBENT entry and why the direction is flipped from #2247's usual
+    # "ordered --after" reading — an unexplained edge on a row OTHER than
+    # the one this `add` named is exactly the kind of surprise an operator
+    # needs the reason for immediately, not by going and reading that row's
+    # own `last_reason` separately.
     overlap_notes: list[str] = []
     if auto_after:
         overlap_notes.append(prediction.reason)
         overlap_notes.extend(_declared_overlap_age_notes(prediction, auto_after))
-    if rejected_after:
+    for entry, overlap in reverse_applied:
+        overlap_notes.append(_reverse_overlap_reason(entry_key(repo, issue), overlap))
+    all_rejected = [*rejected_after, *reverse_rejected]
+    if all_rejected:
         overlap_notes.append(
-            "rejected via --reject-after (not applied): " + ", ".join(rejected_after)
+            "rejected via --reject-after (not applied): " + ", ".join(all_rejected)
         )
     overlap_notes.extend(fanout_warnings(prediction))
     if malformed_note:
@@ -925,6 +974,8 @@ def _applicable_auto_after(
     issue: int,
     after: list[str],
     prediction: Prediction,
+    *,
+    candidate_keys: Sequence[str] | None = None,
 ) -> list[str]:
     """The predicted pre-reqs that are actually safe to add.
 
@@ -933,9 +984,20 @@ def _applicable_auto_after(
     dropped if it would self-edge or close a cycle — the opposite posture to
     `validate_enqueue`'s treatment of an operator-declared `--after`, which is
     a typo worth reporting.
+
+    #3395: *candidate_keys* narrows which of `prediction.after_keys` this
+    call even considers — `None` (the default, unused by `drive_queue_add`'s
+    own call today but kept for a caller that wants pre-#3395 behaviour, or
+    a future direct test) keeps the pre-#3395 behaviour of trying all of
+    them. `drive_queue_add` passes the FORWARD subset only:
+    `_partition_overlap_after` has already routed the REVERSED ones (a
+    newcomer positioned ahead of an overlapping, not-yet-dispatched entry) to
+    `_apply_reversed_overlap_after` instead, and chaining this entry after
+    them TOO would apply rule 2's edge twice, in both directions.
     """
+    keys = prediction.after_keys if candidate_keys is None else tuple(candidate_keys)
     applied: list[str] = []
-    for candidate_key in prediction.after_keys:
+    for candidate_key in keys:
         if candidate_key in after or candidate_key in applied:
             continue
         try:
@@ -948,6 +1010,226 @@ def _applicable_auto_after(
     return applied
 
 
+def _resolve_effective_new_position(
+    position: int | None, previous: QueueEntry | None,
+) -> int | None:
+    """#3395: the position this `add` actually leaves the entry at, for
+    :func:`coord.overlap_predict.overlap_would_run_before` to compare against.
+
+    An explicit ``--position`` wins outright. Otherwise, re-adding an
+    already-queued entry keeps its CURRENT position — `enqueue_drive_queue`
+    never moves a row unless `position` is given — so that position is what
+    the entry will actually run at. A brand-new entry with no `--position`
+    appends at the tail (``None``, `overlap_would_run_before`'s own "never
+    ahead of anything" case) — there is no meaningful position yet.
+    """
+    if position is not None:
+        return position
+    if previous is not None:
+        return previous.position
+    return None
+
+
+def _partition_overlap_after(
+    existing_entries: list[QueueEntry],
+    effective_position: int | None,
+    prediction: Prediction,
+    *,
+    previous_position: int | None = None,
+) -> tuple[list[str], list[tuple[QueueEntry, Overlap]]]:
+    """#3395 rule 2: split predicted overlaps by which direction the
+    ``--after`` edge belongs in.
+
+    FORWARD (returned as plain keys, same shape `_applicable_auto_after`
+    always took) is correct whenever the other side either is already
+    running (`[branch]` — it started before this `add` regardless of queue
+    position) or is queued but will still dispatch no earlier than this
+    newcomer. REVERSE (returned paired with the other side's own
+    `QueueEntry`, since applying it means writing to THAT row, not this one)
+    is the case the issue is about: a `[declared]` overlap against an entry
+    that is still queued but is about to be pushed BEHIND this newcomer in
+    dispatch order. Chaining the newcomer after it there would force the
+    newcomer to run last despite the operator's own `--position`, while the
+    incumbent — now scheduled first — would carry no edge stopping it from
+    colliding with the newcomer's fresher files.
+
+    An overlap naming a key with no matching `QueueEntry` (the declared
+    footprint disappeared between prediction and this call — a `remove` race,
+    vanishingly rare) falls back to FORWARD: the safe, pre-#3395 default.
+
+    ``previous_position`` is the target's OWN position before this call —
+    `None` for a brand-new entry, the row's current position when this
+    `add` is REPOSITIONING an already-queued entry. Passed straight through
+    to `overlap_would_run_before`, which needs it to account for
+    `_move_drive_queue_entry_local`'s remove-then-reinsert shift: without
+    it, the direction decision compares `other`'s stale pre-removal
+    position and can pick the REVERSE edge when FORWARD is actually correct
+    (or vice versa) — see that function's docstring for the full case
+    analysis.
+    """
+    entries_by_key = {e.key: e for e in existing_entries}
+    forward: list[str] = []
+    reverse: list[tuple[QueueEntry, Overlap]] = []
+    for overlap in prediction.overlaps:
+        other = entries_by_key.get(overlap.key)
+        if (
+            overlap.source == SOURCE_DECLARED
+            and other is not None
+            and overlap_would_run_before(
+                effective_position,
+                other.position,
+                previous_position=previous_position,
+            )
+        ):
+            reverse.append((other, overlap))
+        else:
+            forward.append(overlap.key)
+    return forward, reverse
+
+
+def _apply_reversed_overlap_after(
+    existing_entries: list[QueueEntry],
+    new_key: str,
+    new_key_after: Sequence[str],
+    reverse_candidates: list[tuple[QueueEntry, Overlap]],
+) -> list[tuple[QueueEntry, Overlap]]:
+    """#3395: apply the REVERSED edges `_partition_overlap_after` identified
+    — chain each incumbent entry ``--after`` the newcomer, since the
+    newcomer is the one that will actually dispatch first.
+
+    Same fail-safe posture as `_applicable_auto_after`: a would-be cycle is
+    silently dropped rather than failing this `add` (an INFERRED edge must
+    never be able to refuse an operator's own `--position`), and an edge that
+    already exists on the incumbent is left alone (no redundant write).
+    Every OTHER operator-declared field on the incumbent's row (`machine`,
+    the hold gate, `max_fix_rounds`, ...) is carried through unchanged —
+    `enqueue_drive_queue` fully replaces those columns on every call, so
+    omitting one here would silently clear it off a row this `add` was never
+    asked to touch.
+
+    ``new_key_after`` is the newcomer's OWN final ``--after`` list from this
+    same `add` (operator-declared plus rule 1's forward auto-chains). The
+    cycle check below builds its own edge graph rather than reusing
+    `validate_enqueue` directly, because `existing_entries` is the pre-write
+    snapshot: it never contains the newcomer's row (a brand-new entry) and,
+    on a reposition, contains only its STALE pre-`add` edges — so a
+    `validate_enqueue` call scoped to just the incumbent's candidate edge
+    cannot see the newcomer's own outgoing edges and would miss a two-node
+    cycle this single `add` invocation introduces (rule 1 chains the
+    newcomer after an overlapping incumbent, rule 2 separately wants that
+    same incumbent chained after the newcomer). Including `new_key_after` as
+    the newcomer's node in the graph here closes that gap; the tick's own
+    full-graph `find_cycle` would otherwise be the only thing to catch it,
+    after the fact.
+    """
+    from coord.state import enqueue_drive_queue  # noqa: PLC0415
+
+    applied: list[tuple[QueueEntry, Overlap]] = []
+    base_edges: dict[str, list[str]] = {
+        e.key: list(e.after) for e in existing_entries if e.key != new_key
+    }
+    base_edges[new_key] = [str(a) for a in new_key_after]
+    for entry, overlap in reverse_candidates:
+        if new_key in entry.after:
+            applied.append((entry, overlap))
+            continue
+        new_after = [*entry.after, new_key]
+        trial_edges = dict(base_edges)
+        trial_edges[entry.key] = new_after
+        if find_cycle(trial_edges) is not None:
+            continue
+        enqueue_drive_queue(
+            entry.repo,
+            entry.issue,
+            machine=entry.machine or None,
+            after=new_after,
+            position=None,
+            hold_after=entry.hold_after,
+            hold_reason=entry.hold_reason,
+            resume_when=entry.resume_when,
+            hold_scope=entry.hold_scope,
+            max_fix_rounds=entry.max_fix_rounds,
+            no_acceptance=entry.no_acceptance,
+            plan_destructive=entry.plan_destructive,
+        )
+        applied.append((entry, overlap))
+        _record_reverse_overlap_prediction(entry.repo, entry.issue, new_key, overlap)
+    return applied
+
+
+def _reverse_overlap_reason(new_key: str, overlap: Overlap) -> str:
+    """#3395: the one sentence shared by `add`'s stdout, the audit summary,
+    and the INCUMBENT's own `last_reason` for a REVERSED edge — so all three
+    surfaces agree on why a row this `add` never named got a new `after=`.
+    """
+    return (
+        "predicted file overlap (#2247) — ordered "
+        + overlap.describe_reversed(new_key)
+        + " (#3395: this add was positioned ahead of an existing queued entry)"
+    )
+
+
+def _record_reverse_overlap_prediction(
+    repo: str, issue: int, new_key: str, overlap: Overlap,
+) -> None:
+    """#3395: the audit + `last_reason` twin of `_record_overlap_prediction`
+    for a REVERSED edge — recorded against *repo*/*issue*, the INCUMBENT
+    entry that actually got the new `after=` write, not the entry `add` was
+    called for. Mirrors `_record_overlap_prediction`'s two sinks (a durable
+    audit row, plus the `last_reason` column an operator reading `coord
+    drive-queue list` sees immediately) for the same reason: a `last_reason`
+    the next tick attempt will overwrite is not durable, so the claim also
+    needs a permanent home to be scored later.
+
+    Kept as its own event rather than reusing `Prediction.audit_details()`
+    verbatim: that payload's `after` list and `predicted_files` are framed
+    from the CANDIDATE's point of view (`_predict_overlap` computed them
+    that way), and reusing it here unedited would misrepresent whose files
+    were actually being ordered against whose.
+    """
+    reason = _reverse_overlap_reason(new_key, overlap)
+    details = {
+        "predicted_files": list(overlap.files),
+        "overlaps": [
+            {
+                "key": new_key,
+                "source": overlap.source,
+                "branch": overlap.branch,
+                "head_sha": overlap.head_sha,
+                "synced_at": overlap.synced_at,
+                "liveness_checked": overlap.liveness_checked,
+                "files": list(overlap.files),
+            }
+        ],
+        "after": [new_key],
+        # #3395: the one field with no forward-edge equivalent — lets a later
+        # reader (a human, `overlap-report`) tell this row's `after=` was
+        # rule 2's reversal, not an ordinary same-direction prediction.
+        "reversed": True,
+    }
+    try:
+        from coord.audit import record_audit  # noqa: PLC0415
+
+        record_audit(
+            tier="business",
+            category=AUDIT_CATEGORY,
+            event_type=EVENT_PREDICTED,
+            actor="drive-queue",
+            summary=reason,
+            repo=repo,
+            issue=issue,
+            details=details,
+        )
+    except Exception:  # noqa: BLE001 — recording must never fail the enqueue
+        pass
+    try:
+        from coord.state import update_drive_queue_entry  # noqa: PLC0415
+
+        update_drive_queue_entry(repo, issue, last_reason=reason)
+    except Exception:  # noqa: BLE001 — same
+        pass
+
+
 def _record_overlap_prediction(
     repo: str, issue: int, prediction: Prediction, applied: list[str],
 ) -> None:

{code_coordinator-0.5.496 → code_coordinator-0.5.498}/coord/commands/release.py

@@ -1722,8 +1722,32 @@ def release_propagate(  # noqa: PLR0912, PLR0915 — a pipeline; the decisions a
         # never touched would undo somebody else's deliberate state.
         from coord.agent_update import cli_initiator  # noqa: PLC0415
 
+        # #3364: narrow further, to the hosts the RED GATE ITSELF names.
+        # `--rollback-on-red` used to revert every host this run updated
+        # the moment ANY of them went red — four hosts that rolled and
+        # verified clean, reverted because a fifth could not roll at all.
+        # A host that rolled and verified is not part of the failure just
+        # because a sibling host's roll was; partial fleet convergence is
+        # strictly better than reverting everyone plus the fifth's own
+        # damage. `blocking_hosts` is `None` when the gate cannot attribute
+        # to specific hosts (a fleet-wide finding) — that must fail toward
+        # rolling back every updated host, the previous (safe) behavior,
+        # never toward rolling back none of them.
+        implicated = gate.blocking_hosts
+        targets = (
+            updated_hosts if implicated is None
+            else [h for h in updated_hosts if h in implicated]
+        )
+        spared = [h for h in updated_hosts if h not in targets]
+        if spared:
+            record.spared_rollback = spared
+            _out(
+                "  spared (rolled and verified, not named by the red gate): "
+                + ", ".join(spared)
+            )
+
         down: list[str] = []
-        for host in updated_hosts:
+        for host in targets:
             machine = by_name.get(host)
             if machine is None:
                 continue
@@ -2948,6 +2972,20 @@ def _rollback_host(
     take under systemd), and only then gives up — loudly, naming the host as
     DOWN rather than reporting a tidy "rolling back".
 
+    #3364: the agent answering ``/health`` again is not the end of the job
+    either. ``POST /rollback`` (``agent_app.py``'s ``rollback`` handler)
+    flips ``~/.coord-venv`` back and re-execs the AGENT — and, same gap
+    #2069 closed for the forward ``/update`` path, nothing about that
+    restarts ``coord-serve``/``coord-web``/``coord-drive-queue``. Left as
+    they were, those siblings keep running out of the slot the rollback
+    just deactivated — permanently orphaned on the slot the next ``/update``
+    must delete and rebuild, which is exactly the #2121 occupied-slot
+    deadlock this issue is about. So a confirmed agent restart here also
+    triggers the same ``_restart_sibling_services`` call `_roll_python` uses,
+    and a sibling that fails to come back on the reverted slot fails this
+    rollback's own verdict — "the venv flipped back" is not "the host is
+    back", same reasoning as #2095 for the forward roll.
+
     #2121: *initiator* names this call on the target host's audit trail, the
     same as ``_roll_python``'s own ``/update`` POST a few lines up — both are
     automation that fires during a fleet roll with nobody at a keyboard, so
@@ -2968,9 +3006,23 @@ def _rollback_host(
     if status != 202:
         return False, str(body.get("error") or f"HTTP {status}")
 
+    def _back_on_target(note: str) -> tuple[bool, str]:
+        """The agent answered ``/health`` on the reverted slot — re-home the
+        siblings onto it too (#3364) before this counts as done."""
+        sib_ok, sib_detail, _sib_failed = _restart_sibling_services(
+            machine, agent_port=agent_port
+        )
+        if sib_ok is False:
+            return False, f"{note}, but {sib_detail}"
+        # True (nothing failed) and None (this agent predates
+        # /restart-services — no channel to have restarted anything
+        # through) both still count as a rollback success: neither is a
+        # service THIS call took down.
+        return True, f"{note}; {sib_detail}"
+
     back, version = _wait_agent_back(machine, agent_port=agent_port, timeout=timeout)
     if back:
-        return True, f"rolled back; agent is serving again on v{version}"
+        return _back_on_target(f"rolled back; agent is serving again on v{version}")
 
     # The re-exec did not take. This is the documented systemd stall, and it
     # has a documented fix — apply it rather than handing the operator a
@@ -2981,7 +3033,7 @@ def _rollback_host(
             machine, agent_port=agent_port, timeout=min(timeout, 60.0)
         )
         if back:
-            return True, (
+            return _back_on_target(
                 f"rolled back; agent needed an SSH `systemctl --user restart "
                 f"coord-agent` but is serving again on v{version}"
             )

{code_coordinator-0.5.496 → code_coordinator-0.5.498}/coord/overlap_predict.py

@@ -92,6 +92,23 @@ detail because it is pure data with no wall-clock dependency; the cached-body
 age is a relative-time string and is therefore the CLI layer's job (see
 ``coord.commands.drive_queue``), the same split that module already draws
 for the candidate's own staleness note.
+
+#3395: this module already predicted against every non-terminal QUEUED entry,
+not just in-flight branches (:func:`coord.commands.drive_queue._predict_overlap`
+builds :class:`Footprint`\\ s from both) — the gap was DIRECTION, not
+coverage. Chaining every overlap the newcomer's own ``--after`` is only
+correct when the newcomer runs SECOND. When it is inserted ahead of an
+already-queued, not-yet-dispatched entry it overlaps with (``--position``
+placing it before that entry's slot), chaining it after that entry as well
+would force it to run LAST despite the operator's own ordering — while the
+incumbent, now scheduled to run FIRST, sails past the newcomer's fresher
+files with no edge stopping it, exactly vimcode#1117/#1090's shape.
+:func:`overlap_would_run_before` answers "who runs first" as a pure position
+comparison; :meth:`Overlap.describe_reversed` renders the edge the other way
+round when the answer says to reverse it. The decision of WHICH overlaps to
+reverse still lives in ``coord.commands.drive_queue`` (it needs the queue's
+positions and the write path to apply an edge onto an entry other than the
+one being added), so this module only supplies the pure primitives.
 """
 
 from __future__ import annotations
@@ -444,6 +461,24 @@ class Overlap:
         stale = ", liveness check failed" if not self.liveness_checked else ""
         return f" ({self.branch}{sha}{stale})"
 
+    def describe_reversed(self, new_key: str) -> str:
+        """#3395: the same rendering as :meth:`describe`, but for the
+        REVERSED chaining direction rule 2 requires when a newcomer is
+        positioned AHEAD of the entry this overlap names.
+
+        :meth:`describe` reads as "the OTHER entry, which the candidate is
+        chained after" — correct when the candidate runs second. Here it is
+        the other way around: ``self.key`` (the entry already sitting in the
+        queue) is the one that must now wait, and *new_key* is the newcomer
+        it waits ON. Only ever called for a :data:`SOURCE_DECLARED` overlap
+        (see :func:`overlap_would_run_before`'s caller) — a `[branch]` edge
+        is already running and can never be the one reversed.
+        """
+        shown = ", ".join(f"`{f}`" for f in self.files[:3])
+        if len(self.files) > 3:
+            shown += f" (+{len(self.files) - 3} more)"
+        return f"{self.key} --after {new_key} [{self.source}]{self._provenance()}: {shown}"
+
 
 @dataclass(frozen=True)
 class Prediction:
@@ -528,6 +563,57 @@ def paths_overlap(left: str, right: str) -> bool:
     return bool(right.endswith("/") and left.startswith(right))
 
 
+def overlap_would_run_before(
+    new_position: int | None,
+    other_position: int,
+    *,
+    previous_position: int | None = None,
+) -> bool:
+    """#3395: would the entry landing at *new_position* dispatch BEFORE the
+    already-queued entry sitting at *other_position*?
+
+    This is rule 2 of the issue's fix, in its testable pure form: an overlap
+    against a `[declared]` (still-queued, not-yet-dispatched) entry must be
+    chained the NORMAL way (newcomer ``--after`` the incumbent) UNLESS the
+    newcomer is being inserted ahead of it in queue order — in which case the
+    edge has to run the other way, or the incumbent's stale files would
+    collide with a newcomer that starts first. The caller
+    (`coord.commands.drive_queue._partition_overlap_after`) is what decides
+    WHICH direction to apply based on this answer; this function only answers
+    "who runs first".
+
+    ``new_position=None`` means "appends at the tail" — `coord.state.
+    enqueue_drive_queue`'s own contract for an omitted ``--position`` — which
+    can never be ahead of anything already queued, so this is unconditionally
+    ``False``. A tie (``new_position == other_position``) resolves to
+    ``True``: inserting AT an occupied slot pushes the incumbent back one
+    (`coord.state._move_drive_queue_entry_local`'s renumbering), so the
+    newcomer is the one that ends up running first.
+
+    ``previous_position`` is the entry's OWN position before this call, when
+    it is already queued and being repositioned (``None`` for a brand-new
+    entry). `_move_drive_queue_entry_local` implements a reposition as
+    remove-then-reinsert: removing the entry from its old slot shifts every
+    entry that was originally AFTER it down by one index, before the entry
+    is reinserted at the clamped destination. `other_position` (taken from
+    the pre-write snapshot) does not reflect that shift, so comparing it
+    directly against `new_position` is only correct when nothing was
+    removed first — i.e. a brand-new entry, where `previous_position` is
+    `None`. When repositioning, and `other_position` was originally after
+    `previous_position` (the entry's own old slot), the removal already
+    moved `other` one slot earlier — accounted for here by comparing against
+    ``other_position - 1`` instead. Getting this backwards does not just
+    miss an edge (the pre-#3395 failure mode) — it applies the REVERSE edge,
+    ordering the entry that will actually dispatch first to wait on the one
+    that dispatches second.
+    """
+    if new_position is None:
+        return False
+    if previous_position is not None and other_position > previous_position:
+        other_position -= 1
+    return int(new_position) <= int(other_position)
+
+
 def _intersect(candidate: Sequence[str], other: Sequence[str]) -> tuple[str, ...]:
     hits: list[str] = []
     for path in candidate:

{code_coordinator-0.5.496 → code_coordinator-0.5.498}/coord/release_propagate.py

@@ -419,6 +419,14 @@ OUT_OF_REACH_LANES: frozenset[str] = frozenset({"~/.coord-cli-venv", "webapp bun
 #: for a lane, and the only form a grouped finding names its lanes by.
 _LANE_LABEL = re.compile(r"^(?P<lane>.+?)\s+\((?P<host>[^()]+)\)$")
 
+#: The pseudo-host ``coord/release_verify.py``'s ``verify()`` stamps on a
+#: finding it cannot pin to one machine (a fleet-wide version-skew or
+#: no-data finding — every ``host="(fleet)"`` call there). Named here so
+#: :attr:`GateVerdict.blocking_hosts` recognises it as "not a real host" the
+#: same way :func:`lane_is_out_of_reach`'s allow-list keeps a lane's gaps
+#: explicit rather than inferred.
+_UNATTRIBUTABLE_HOST = "(fleet)"
+
 
 def parse_lane_label(label: str) -> tuple[str, str] | None:
     """``"~/.coord-venv (precision)"`` -> ``("precision", "~/.coord-venv")``.
@@ -487,6 +495,36 @@ class GateVerdict:
     def red(self) -> bool:
         return self.severity == "crit"
 
+    @property
+    def blocking_hosts(self) -> frozenset[str] | None:
+        """Real hosts a BLOCKING finding actually names (#3364).
+
+        ``--rollback-on-red`` used to revert every host a run updated the
+        instant ANY of them went red — a fifth host's failure rolling back
+        four that verified clean. This is what lets a caller narrow to just
+        the hosts the red gate is actually about, the same way
+        :func:`attempted_scope` already narrows which lanes count.
+
+        ``None`` means "could not attribute to specific hosts" — a
+        fleet-wide finding like the no-``--expected``-given skew case
+        (``host="(fleet)"``, see ``coord/release_verify.py``'s ``verify()``)
+        or a finding with no host at all. A caller must fail toward that
+        meaning "implicates everyone this run touched", never toward
+        "implicates nobody" — the same "an unattributable signal blocks
+        every host, never none of them" rule :attr:`Quiescence.
+        fleet_wide_busy` already follows for busy signals. A concrete
+        (possibly empty, when there are no blocking findings at all) set
+        means every blocking finding named a real host, and rollback may
+        scope to exactly those.
+        """
+        hosts: set[str] = set()
+        for finding in self.blocking:
+            for host, _lane in _finding_pairs(finding):
+                if not host or host == _UNATTRIBUTABLE_HOST:
+                    return None
+                hosts.add(host)
+        return frozenset(hosts)
+
     def to_dict(self) -> dict:
         return {
             "severity": self.severity,
@@ -1485,6 +1523,12 @@ class PropagationRecord:
     #: done so, or the resulting quiet fleet is indistinguishable from #2082.
     cordons: dict = field(default_factory=dict)
     rolled_back: list[str] = field(default_factory=list)
+    #: #3364: hosts this run updated and verified clean but did NOT roll back
+    #: even though the gate went red — because the red gate's blocking
+    #: findings (:attr:`GateVerdict.blocking_hosts`) named some OTHER host,
+    #: not this one. A host that rolled and verified is not part of the
+    #: failure just because a sibling host's roll was.
+    spared_rollback: list[str] = field(default_factory=list)
     released_holds: list[str] = field(default_factory=list)
     #: #2583: the min-releases-behind gate's own readings for this run —
     #: ``min_releases_behind`` is whatever this run resolved (flag > config >
@@ -1763,6 +1807,11 @@ def render_record(record: PropagationRecord | Mapping[str, Any]) -> list[str]:
 
     if data.get("rolled_back"):
         lines.append(f"    rolled back: {', '.join(data['rolled_back'])}")
+    if data.get("spared_rollback"):
+        lines.append(
+            "    spared (rolled and verified, not named by the red gate): "
+            + ", ".join(data["spared_rollback"])
+        )
     if data.get("released_holds"):
         lines.append(f"    released deploy gates: {', '.join(data['released_holds'])}")
     if data.get("error"):