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

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

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

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

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

{code_coordinator-0.5.496 → code_coordinator-0.5.497}/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.497}/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.497}/tests/test_cli_drive_queue.py

@@ -6097,3 +6097,152 @@ def test_diagnose_does_not_call_a_never_polled_machine_unreachable(
     assert "agent-unreachable" not in result.output
     assert "dead-leg" not in result.output
     assert "/health dellserver: not read" in result.output
+
+
+# ── #3395: direction-aware overlap ordering against a QUEUED entry ──────────
+#
+# vimcode#1117 / vimcode#1090: both declared `src/harness.rs` and
+# `src/tui_main/shell_app.rs`. #1090 was queued first and sat `waiting`
+# behind a chain; #1117 was added later at `--position 0`, ahead of it. The
+# predictor found the overlap but chained #1117 `--after` #1090 — the normal
+# direction, correct only when the newcomer runs SECOND. Here it runs FIRST
+# (that is the whole point of `--position 0`), so #1090 carried no edge
+# naming #1117 and both ran concurrently: #1117 merged first and emptied a
+# list in `src/harness.rs`; #1090's stale copy conflicted on merge (PR #1121,
+# `HUMAN_REQUIRED`). These assert the edge lands on the INCUMBENT (#1090)
+# instead, fixing the direction rather than merely detecting the collision
+# (which unfixed `main` already does — see the module docstring's #3395
+# paragraph).
+
+
+def test_inserting_ahead_of_a_queued_overlap_orders_the_incumbent_after_it(
+    cli, declare,
+):
+    # Queue A (files X, Y) — queued first, sits at position 0.
+    declare(1090, "src/harness.rs", "src/tui_main/shell_app.rs")
+    assert cli("add", REPO, "1090").exit_code == 0
+
+    # Queue B (files X, Z) at --position 0, ahead of A. Fails against
+    # unfixed main: the edge previously landed on B (`1117 after 1090`), not
+    # on A — the newcomer positioned to run FIRST was the one made to wait.
+    declare(1117, "src/harness.rs", "src/tui_main/shell_app.rs")
+    result = cli("add", REPO, "1117", "--position", "0")
+
+    assert result.exit_code == 0, result.output
+    # The edge exists, and on the correct side: A (already queued, now
+    # pushed behind B in dispatch order) waits on B, not the other way
+    # around.
+    assert queued(1090)["after_json"] == [f"{REPO}#1117"]
+    assert queued(1117)["after_json"] == []
+    # B is genuinely positioned first.
+    positions = {r["issue_number"]: r["position"] for r in state._list_drive_queue_local()}
+    assert positions[1117] < positions[1090]
+    # The reason is recorded on the row that actually changed, and names why
+    # the direction is reversed.
+    assert "predicted file overlap (#2247)" in result.output
+    assert f"ordered {REPO}#1090 --after {REPO}#1117" in result.output
+    assert "positioned ahead of an existing queued entry" in result.output
+    assert "predicted file overlap (#2247)" in queued(1090)["last_reason"]
+
+
+def test_appending_after_a_queued_overlap_keeps_the_normal_forward_direction(
+    cli, declare,
+):
+    # Same two declarations, but B appended at the tail (no --position) —
+    # the ordinary case #2247's original tests already cover. Direction must
+    # stay forward: B waits on A, since B genuinely runs second.
+    declare(1090, "src/harness.rs", "src/tui_main/shell_app.rs")
+    assert cli("add", REPO, "1090").exit_code == 0
+
+    declare(1117, "src/harness.rs", "src/tui_main/shell_app.rs")
+    result = cli("add", REPO, "1117")
+
+    assert result.exit_code == 0, result.output
+    assert queued(1117)["after_json"] == [f"{REPO}#1090"]
+    assert queued(1090)["after_json"] == []
+
+
+def test_reject_after_drops_a_reversed_edge_too(cli, declare):
+    declare(1090, "src/harness.rs")
+    assert cli("add", REPO, "1090").exit_code == 0
+
+    declare(1117, "src/harness.rs")
+    result = cli(
+        "add", REPO, "1117", "--position", "0", "--reject-after", "1090",
+    )
+
+    assert result.exit_code == 0, result.output
+    # Named by the OTHER entry's key either way — the operator doesn't need
+    # to know which direction rule 2 picked to veto it.
+    assert queued(1090)["after_json"] == []
+    assert queued(1117)["after_json"] == []
+    assert f"rejected via --reject-after (not applied): {REPO}#1090" in result.output
+
+
+def test_repositioning_an_already_queued_entry_reevaluates_the_direction(
+    cli, declare,
+):
+    # #3395 review: none of the tests above reposition an entry that is
+    # ALREADY queued — they only insert a brand-new one at `--position 0`,
+    # where there is nothing to remove first. Repositioning is exactly rule
+    # 3's case, and it needs its own comparison: `_move_drive_queue_entry_
+    # local` removes the target from its OLD slot before reinserting it,
+    # shifting every entry originally after it down by one — a comparison
+    # against the other entry's STALE, pre-removal position picks the WRONG
+    # direction here.
+    #
+    # T queued first (position 0), O queued second (position 1), same
+    # declared file. O's own `add` would normally auto-chain `O --after T`
+    # (the ordinary forward case, correct at the time — T ran first) —
+    # `--reject-after` skips that here so the queue starts with NO edge
+    # between them, isolating what this test is actually about: the
+    # direction rule 2 picks when T is repositioned, not whatever edge O's
+    # own earlier `add` happened to leave behind.
+    #
+    # Re-adding T with `--position 1` is a SWAP, not "T stays ahead of O": O
+    # ends up dispatching FIRST, T SECOND. The correct edge is therefore the
+    # ordinary forward one (T --after O). Unfixed code compares T's
+    # requested --position (1) against O's raw pre-move position (also 1),
+    # calls that a tie, and reverses it (O --after T) — ordering the entry
+    # that actually dispatches first to wait on the one that actually
+    # dispatches second.
+    declare(2001, "src/shared.rs")
+    assert cli("add", REPO, "2001").exit_code == 0  # T, lands at position 0
+
+    declare(2002, "src/shared.rs")
+    assert (
+        cli("add", REPO, "2002", "--reject-after", "2001").exit_code == 0
+    )  # O, lands at position 1, no edge yet
+
+    result = cli("add", REPO, "2001", "--position", "1")
+
+    assert result.exit_code == 0, result.output
+    positions = {r["issue_number"]: r["position"] for r in state._list_drive_queue_local()}
+    assert positions[2002] < positions[2001]  # O genuinely runs first now
+    assert queued(2001)["after_json"] == [f"{REPO}#2002"]  # forward: T after O
+    assert queued(2002)["after_json"] == []
+
+
+def test_a_reversed_edge_is_never_applied_against_an_in_flight_branch(
+    cli, declare, seed, branch_diff,
+):
+    # A `[branch]` overlap (already running) must never reverse — it started
+    # before this add regardless of queue position, so the newcomer always
+    # waits on it, exactly like before #3395.
+    seed(
+        issues={2230: "open"},
+        assignments=[{"issue_number": 2230, "status": "running"}],
+    )
+    from coord.db import get_connection
+
+    get_connection().execute(
+        "UPDATE assignments SET branch = 'issue-2230' WHERE issue_number = 2230"
+    )
+    get_connection().commit()
+    branch_diff({"issue-2230": ["coord/drive_queue.py"]})
+    declare(2234, "coord/drive_queue.py")
+
+    result = cli("add", REPO, "2234", "--position", "0")
+
+    assert result.exit_code == 0, result.output
+    assert queued(2234)["after_json"] == [f"{REPO}#2230"]