code-coordinator 0.5.150__tar.gz → 0.5.153__tar.gz

{code_coordinator-0.5.150 → code_coordinator-0.5.153}/PKG-INFO

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: code-coordinator
-Version: 0.5.150
+Version: 0.5.153
 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.153/code_coordinator.egg-info/scm_version.json

@@ -0,0 +1,8 @@
+{
+  "tag": "0.5.153",
+  "distance": 0,
+  "node": "g2968c6a10a7c3b15da201f4fd9049f641c23b3ee",
+  "dirty": false,
+  "branch": "HEAD",
+  "node_date": "2026-08-19"
+}

{code_coordinator-0.5.150 → code_coordinator-0.5.153}/coord/commands/drive_queue.py

@@ -71,6 +71,7 @@ from coord.drive_queue import (
     find_cycle,
     fired_holds,
     is_permanent_block_reason,
+    is_unsatisfiable_prereq_reason,
     parse_after_spec,
     parse_key,
     pending_probe_targets,
@@ -562,13 +563,31 @@ _BLOCKED_REMEDY = (
     "actually fixed, not merely because a pre-req merged"
 )
 
-# #2230: `blocked`'s MERGE GATE (as opposed to its `after=` graph, which
-# `_BLOCKED_REMEDY` above still correctly calls never-re-checked) is no
-# longer unconditionally terminal — see `coord.drive_queue.
-# is_permanent_block_reason`/`_reconcile_blocked`. Shown only for `blocked`
-# (never `failed`, which #2230 does not touch at all) so an operator reading
-# `list` right after this ships doesn't have to go read the issue to learn
-# their remove+add might be about to race an automatic resume.
+# #2362: a `blocked` row (never `failed` — the tick's `after=` resume sweep,
+# `coord.drive_queue._reconcile_blocked_after`, is scoped to `blocked` only)
+# whose OWN `last_reason` IS `_resolve_prereqs`'s "queued but blocked/failed
+# — it will never satisfy" verdict is auto re-checked every tick, and
+# resumes to `waiting` on its own the moment every named pre-req lands.
+# `_BLOCKED_REMEDY` above is flatly wrong for exactly this row shape (it is
+# in fact re-checked, on its own, without an operator) — this note replaces
+# it there instead of merely appending, mirroring #2230's own concern: an
+# operator told "never re-checked" for a row about to self-resume would
+# either do a needless remove+add or race the automatic one.
+_BLOCKED_AFTER_NOTE = (
+    "remedy: {state}'s `after=` graph above IS re-checked automatically "
+    "every tick (#2362) — once every named pre-req lands (`facts.landed`), "
+    "this row resumes to `waiting` on its own, attempt budget reset; no "
+    "operator remove+add needed. See `resumes=` above if it has already "
+    "self-resumed and re-blocked for an unrelated reason."
+)
+
+# #2230: `blocked`'s MERGE GATE (as opposed to its `after=` graph, handled by
+# `_BLOCKED_AFTER_NOTE`/`_BLOCKED_REMEDY` above) is no longer unconditionally
+# terminal — see `coord.drive_queue.is_permanent_block_reason`/
+# `_reconcile_blocked`. Shown only for `blocked` (never `failed`, which
+# #2230 does not touch at all) so an operator reading `list` right after this
+# ships doesn't have to go read the issue to learn their remove+add might be
+# about to race an automatic resume.
 _BLOCKED_GATE_NOTE = (
     "note: a re-evaluable blocked cause (i.e. not a #1844/#2019 permanent "
     "refusal) IS re-checked against the merge gate automatically (#2230) — "
@@ -693,12 +712,37 @@ def drive_queue_list(repo: str | None, output_json: bool, config_path: Path) ->
             # #2183 point 4: `blocked`/`failed` is terminal — say so where the
             # operator is already reading the row, not just in an unrelated
             # operator's hand-written `--hold-after` note.
-            click.echo(f"      {_BLOCKED_REMEDY.format(state=entry.state)}")
+            #
+            # #2404: EXCEPT when this row's own `last_reason` is exactly the
+            # unsatisfiable-`after=`-pre-req verdict on a `blocked` (not
+            # `failed`) entry — that shape auto-resumes on its own every tick
+            # (#2362), so the generic "never re-checked on its own" remedy
+            # would be actively wrong for it; swap in the note that says so.
+            if entry.state == STATE_BLOCKED and is_unsatisfiable_prereq_reason(
+                entry.last_reason
+            ):
+                click.echo(f"      {_BLOCKED_AFTER_NOTE.format(state=entry.state)}")
+            else:
+                click.echo(f"      {_BLOCKED_REMEDY.format(state=entry.state)}")
         # #2230: independent of the `after=` diagnosis above (most `blocked`
         # rows have no `after=` at all — they blocked on attempts, not a
         # pre-req), so gated on the row's OWN state and cause, not `diagnosed`.
-        if entry.state == STATE_BLOCKED and not is_permanent_block_reason(
-            entry.last_reason
+        #
+        # #2404 review: EXCLUDE the unsatisfiable-`after=`-pre-req shape
+        # `_BLOCKED_AFTER_NOTE` above already covers. #2230's sweep
+        # (`_blocked_gate_reading`) returns `None` — "no evidence" — for an
+        # entry that never reached the merge queue at all, which is exactly
+        # what a purely `after=`-caused block is; showing this note there
+        # would stack two auto-recheck notes citing two different issue
+        # numbers under one row, one of which has nothing to say about that
+        # row's actual cause. `is_permanent_block_reason` rows already skip
+        # this note on their own; this adds the sibling exclusion so the two
+        # notes stay mutually exclusive, matching what each mechanism can
+        # actually promise for a given row.
+        if (
+            entry.state == STATE_BLOCKED
+            and not is_permanent_block_reason(entry.last_reason)
+            and not is_unsatisfiable_prereq_reason(entry.last_reason)
         ):
             click.echo(f"      {_BLOCKED_GATE_NOTE}")
         for line in _hold_lines(entry):

{code_coordinator-0.5.150 → code_coordinator-0.5.153}/coord/drive_queue.py

@@ -1600,6 +1600,19 @@ def _is_unsatisfiable_prereq_reason(text: str | None) -> bool:
     return bool(text) and _UNSATISFIABLE_PREREQ_MARKER in text
 
 
+def is_unsatisfiable_prereq_reason(text: str | None) -> bool:
+    """Public alias for :func:`_is_unsatisfiable_prereq_reason`.
+
+    `coord drive-queue list`'s rendering (#2404) needs to tell whether a
+    `blocked` row's frozen ``last_reason`` is the exact shape
+    :func:`_reconcile_blocked_after` (#2362) auto-resumes once every named
+    pre-req lands, so it can stop telling the operator the ``after=`` graph
+    "is never re-checked on its own" for a row where that has stopped being
+    true — see ``coord.commands.drive_queue._BLOCKED_AFTER_NOTE``.
+    """
+    return _is_unsatisfiable_prereq_reason(text)
+
+
 def _reconcile_blocked_after(
     entry: QueueEntry,
     board: BoardView,

{code_coordinator-0.5.150 → code_coordinator-0.5.153}/tests/test_cli_drive_queue.py

@@ -692,6 +692,65 @@ def test_blocked_row_purely_by_an_unsatisfiable_prereq_is_unchanged(cli, seed):
     assert dep_reason in result.output
 
 
+def test_blocked_row_purely_by_an_unsatisfiable_prereq_gets_the_2362_note(
+    cli, seed
+):
+    """#2404: unlike a `blocked` row whose own cause is unrelated to its
+    `after=` graph (genuinely "never re-checked on its own" — see the #542
+    control case above), a row blocked purely because a named pre-req is
+    itself `blocked`/`failed` DOES get re-checked automatically every tick
+    (#2362): the moment that pre-req lands, this row resumes to `waiting` on
+    its own. `list`'s remedy line must say so instead of sending an operator
+    to a needless (or racing) manual `remove`+`add`."""
+    seed(issues={1650: "open"})
+    # 1650: blocked for its own, unrelated reason — nothing re-checks this.
+    cli("add", REPO, "1650")
+    state._update_drive_queue_entry_local(
+        REPO, 1650, state="blocked", last_reason="drive session died"
+    )
+    # 1654 (the #492 shape): blocked ONLY because its pre-req (1650) is
+    # itself blocked — the exact shape #2362's tick sweep auto-resumes.
+    cli("add", REPO, "1654", "--after", "1650")
+    dep_reason = f"pre-req {REPO}#1650 is queued but blocked — it will never satisfy"
+    state._update_drive_queue_entry_local(
+        REPO, 1654, state="blocked", last_reason=dep_reason
+    )
+
+    result = cli("list")
+    assert result.exit_code == 0, result.output
+
+    # 1650 has no `after=` at all, so #2183's diagnosis (and any remedy
+    # line) never applies to it — nothing to assert there beyond it existing.
+    assert _row_for(result.output, f"{REPO}#1650")
+
+    # Split the transcript at 1654's own row header — 1654 is the last
+    # (only remaining) row, so everything from there on is exactly ITS
+    # block (summary/last:/note lines), never 1650's.
+    idx_1654 = result.output.index(f"{REPO}#1654")
+    block_1650 = result.output[:idx_1654]
+    block_1654 = result.output[idx_1654:]
+
+    # 1654's remedy line is the new #2362 note, not the stale "never
+    # re-checked on its own" advice — this row auto-resumes without an
+    # operator.
+    assert "IS re-checked automatically every tick (#2362)" in block_1654
+    assert "no operator remove+add needed" in block_1654
+    assert "never re-checked on its own" not in block_1654
+
+    # #2404 review (non-blocking finding): #2230's merge-gate note must NOT
+    # also print for this row. `_blocked_gate_reading` returns `None` — no
+    # evidence — for an entry that never reached the merge queue, which is
+    # exactly what a purely `after=`-caused block is; showing it here would
+    # stack two auto-recheck notes citing two different issue numbers under
+    # one row, one of which has nothing to say about this row's real cause.
+    assert "re-checked against the merge gate automatically (#2230)" not in block_1654
+
+    # …but an ordinary blocked row whose cause is unrelated to its `after=`
+    # graph (1650, blocked on "drive session died") still gets #2230's note
+    # exactly as before — this exclusion is scoped to the #2362 shape only.
+    assert "re-checked against the merge gate automatically (#2230)" in block_1650
+
+
 def test_list_with_no_after_is_unaffected_by_the_2183_diagnosis(cli):
     """A `blocked` entry that never declared any `after=` at all keeps
     rendering exactly as it always has — no board dependency, no remedy

{code_coordinator-0.5.150 → code_coordinator-0.5.153}/tests/test_drive_queue.py

@@ -2433,6 +2433,116 @@ def test_a_permanently_blocked_entry_is_not_resumed_even_once_its_after_lands():
     assert plan.launch is None
 
 
+# ── #2404 review: a CHAINED (two-hop) after= block, not just single-hop ────
+#
+# The live incident this issue is about (claude-coordinator#2284-#2288) was
+# never a single `after=` edge: #2284-#2288 all declared `after=2283`, and
+# #2283 was ITSELF `blocked` on `after=2282` — a two-hop chain (root 2282 ->
+# middle 2283 -> leaf 2284..2288), not the one-hop shape every test above
+# pins. `_reconcile_blocked_after`'s resume check is driven entirely by
+# `board.facts(dep).landed` — a real, board-derived merge fact, never by a
+# dependency's in-tick `states` entry — so in principle each hop should
+# resolve independently the moment ITS OWN named pre-req actually lands,
+# with no special-casing needed for the chain shape. These two tests are the
+# repro the review asked for: they exercise `plan_tick` against an actual
+# two-hop graph to confirm that holds (it does), and pin the one subtlety a
+# naive "chain" fix could get wrong — a leaf must not resume just because
+# its immediate pre-req was ITSELF re-queued to `waiting` this same tick;
+# only that pre-req actually landing (merged/closed) may resume the leaf.
+
+
+def test_a_two_hop_after_chain_resumes_in_one_tick_once_both_hops_have_landed():
+    """The exact live-incident shape: by the time anyone looked, BOTH the
+    root (2282-analog) and the middle (2283-analog) pre-reqs had already
+    merged — the middle's queue row just hadn't been reconciled yet. A
+    single tick must resolve the WHOLE chain: the middle reconciles to
+    `done` via #2055's landed check, and the leaf (2284..2288-analog),
+    reading the middle's REAL board fact rather than its stale on-disk
+    `blocked` state, resumes to `waiting` in that same tick — no operator
+    action, and no second tick needed once both merges are real."""
+    root = entry_key(REPO, 1650)
+    middle = entry_key(REPO, 1654)
+    entries = [
+        entry(1650, position=0, state=STATE_DONE),
+        entry(
+            1654,
+            position=1,
+            after=(root,),
+            state=STATE_BLOCKED,
+            attempts=2,
+            last_reason=f"pre-req {root} is queued but blocked — it will never satisfy",
+        ),
+        entry(
+            1658,
+            position=2,
+            after=(middle,),
+            state=STATE_BLOCKED,
+            attempts=1,
+            last_reason=f"pre-req {middle} is queued but blocked — it will never satisfy",
+        ),
+    ]
+    # Both the root AND the middle have actually merged — mirrors the live
+    # incident, where #2283 (middle) itself showed `done — issue already
+    # merged while blocked (#2055)` once anyone looked.
+    plan = plan_tick(entries, board(merged=(1650, 1654)), capacity=3)
+
+    middle_reconcile = next(r for r in plan.reconciles if r.key == middle)
+    assert middle_reconcile.outcome == "done"
+    assert middle_reconcile.updates["state"] == STATE_DONE
+
+    leaf_reconcile = next(r for r in plan.reconciles if r.key == entry_key(REPO, 1658))
+    assert leaf_reconcile.outcome == "resumed"
+    assert leaf_reconcile.updates["state"] == STATE_WAITING
+    assert leaf_reconcile.updates["attempts"] == 0
+    assert leaf_reconcile.updates["resumes"] == 1
+
+    # …and, exactly like the single-hop case, the freshly-resumed leaf falls
+    # straight into this SAME tick's launch selection.
+    assert plan.launch is not None and plan.launch.issue == 1658
+
+
+def test_a_two_hop_after_chain_leaf_is_not_resumed_until_its_own_pre_req_lands():
+    """Guard against the false-resume a naive "propagate through `states`"
+    chain fix would introduce: once the root lands, the middle correctly
+    resumes to `waiting` THIS tick (single-hop #2362 behaviour) — but the
+    leaf's own named pre-req is the MIDDLE, which has only been re-queued,
+    not merged. The leaf must stay `blocked` until the middle itself
+    actually lands, even though `states[middle]` already reads `waiting` by
+    the time the leaf is walked in this same tick."""
+    root = entry_key(REPO, 1650)
+    middle = entry_key(REPO, 1654)
+    entries = [
+        entry(1650, position=0, state=STATE_DONE),
+        entry(
+            1654,
+            position=1,
+            after=(root,),
+            state=STATE_BLOCKED,
+            attempts=2,
+            last_reason=f"pre-req {root} is queued but blocked — it will never satisfy",
+        ),
+        entry(
+            1658,
+            position=2,
+            after=(middle,),
+            state=STATE_BLOCKED,
+            attempts=1,
+            last_reason=f"pre-req {middle} is queued but blocked — it will never satisfy",
+        ),
+    ]
+    # Only the root has landed — the middle has not (it is only about to be
+    # re-queued to `waiting` THIS tick, not merged).
+    plan = plan_tick(entries, board(merged=(1650,)), capacity=3)
+
+    middle_reconcile = next(r for r in plan.reconciles if r.key == middle)
+    assert middle_reconcile.outcome == "resumed"
+    assert middle_reconcile.updates["state"] == STATE_WAITING
+
+    # The leaf gets NO reconcile at all this tick — it stays blocked, with
+    # its existing (still-true) "it will never satisfy" reason untouched.
+    assert all(r.key != entry_key(REPO, 1658) for r in plan.reconciles)
+
+
 def test_is_unsatisfiable_prereq_reason_recognises_only_the_exact_verdict_shape():
     from coord.drive_queue import _is_unsatisfiable_prereq_reason
 

{code_coordinator-0.5.150 → code_coordinator-0.5.153}/tui/src/app/data.rs

@@ -2626,7 +2626,19 @@ pub(crate) fn start_data_load() -> std::sync::mpsc::Receiver<BoardData> {
     // the real local SQLite DB and overwrite pipeline_issues / data.assignments
     // with whatever the developer's coord.db currently contains, making
     // TuiDriver tests non-deterministic and machine-dependent.
-    #[cfg(test)]
+    //
+    // #2284 (ms-65 §3, manifest finding 7): gated on `feature = "test-support"`
+    // too, not just `cfg(test)` — the sealed `tests/acceptance/**` suite
+    // (`tui/tests/acceptance.rs`, the #1042 seam) is a separate integration-test
+    // crate, so the `coord_tui` it links against is built *without* `cfg(test)`
+    // (only the top-level `cargo test` binary gets that cfg). Without this
+    // widening, entering the Pipeline panel in that suite kicks
+    // `maybe_kick_pipeline_loader` -> `refresh` -> this function, which fell
+    // through to the real network/SQLite path and wholesale-replaced the
+    // seeded fixture on the very next dispatched event (a RACE — whichever
+    // finished first) — mirrors the exact same trap `resolve_board_service`
+    // above already widened for (#1039).
+    #[cfg(any(test, feature = "test-support"))]
     {
         let _ = tx.send(BoardData::default());
         return rx;

{code_coordinator-0.5.150 → code_coordinator-0.5.153}/tui/src/app/dialogs.rs

@@ -894,6 +894,49 @@ impl CoordApp {
                     items.push(ContextMenuItem::separator());
                 }
             }
+
+            // #2402: "Re-verify (revalidate)" — a Pipeline row whose Merge
+            // stage is BLOCKED with no automatic retry coming (#2397: the
+            // daemon's auto-drain tick never touches a BLOCKED entry) had no
+            // in-TUI recovery action at all; the only fix was `coord merge
+            // --revalidate` typed by hand. Shown regardless of `lifecycle`
+            // for the same reason the escalation block above is — a stuck
+            // merge still reads as "in progress" — so this can't be nested
+            // under one specific `match lifecycle` arm below.
+            //
+            // Eligibility mirrors `coord.merge_queue.revalidation_candidates`
+            // / `ci_revalidation_candidates` EXACTLY
+            // (`format::merge_revalidate_eligible`, gated on the entry's raw
+            // `reason` text): a review/CI-failure/conflict/missing-verdict
+            // block never offers this action, only a stale-but-passed local
+            // verdict or a stale-but-green CI check does. `repo_name` here is
+            // the coord-local name (`PipelineIssue::coord_repo`); the
+            // merge-plan lookup needs the GitHub `owner/repo` slug instead,
+            // so the matching `PipelineIssue` is re-resolved repo-precisely
+            // (#983 discipline — same reasoning as `has_running`/`has_zombie`
+            // above) rather than reusing `epic_issue`, which only matches on
+            // issue number.
+            if let (Some(n), Some(repo)) = (issue_number, repo_name) {
+                let repo_slug = self.pipeline_issues.iter().find_map(|iss| {
+                    (iss.number == n && iss.coord_repo.as_deref() == Some(repo))
+                        .then_some(iss.repo_slug.as_str())
+                });
+                if let Some(repo_slug) = repo_slug {
+                    if let Some(entry) = self.merge_plan_entry_for_issue(repo_slug, n) {
+                        if entry.status == "BLOCKED" {
+                            if let Some(reason) = entry.reason.as_deref() {
+                                if merge_revalidate_eligible(reason) {
+                                    items.push(ContextMenuItem::action(
+                                        "merge-revalidate",
+                                        "Re-verify (revalidate)",
+                                    ));
+                                    items.push(ContextMenuItem::separator());
+                                }
+                            }
+                        }
+                    }
+                }
+            }
         }
         match lifecycle {
             PipelineRowLifecycle::New => {
@@ -2551,6 +2594,51 @@ impl CoordApp {
             });
         }
 
+        // ── #2402: Re-verify (revalidate) confirm ───────────────────────
+        // State plainly what it will do (#1214 precedent): `--revalidate`
+        // runs a real build+test locally on the daemon host — cheap, no
+        // tokens, but not instant, so it gets the same confirm-before-spawn
+        // shape as `pending_force_merge` rather than a bare click-and-go.
+        if let Some(ref p) = self.pending_merge_revalidate {
+            return Some(Dialog {
+                table: None,
+                id: WidgetId::new("dialog:merge-revalidate"),
+                title: StyledText::plain("Re-verify (revalidate)"),
+                body: vec![
+                    StyledText::plain(format!(
+                        "Re-test #{} against the current base?",
+                        p.issue_num,
+                    )),
+                    StyledText::plain(
+                        "Runs `coord merge --revalidate --only <assignment>` — a real \
+                         build+test (or CI re-run) locally on the daemon host before \
+                         merging. Only re-tests a stale-but-passed verdict; a genuine \
+                         review/CI/conflict block is left untouched."
+                            .to_string(),
+                    ),
+                ],
+                buttons: vec![
+                    DialogButton {
+                        id: WidgetId::new("yes"),
+                        label: "y  Revalidate".into(),
+                        is_default: true,
+                        is_cancel: false,
+                        tint: None,
+                    },
+                    DialogButton {
+                        id: WidgetId::new("cancel"),
+                        label: "Cancel".into(),
+                        is_default: false,
+                        is_cancel: true,
+                        tint: None,
+                    },
+                ],
+                severity: Some(DialogSeverity::Question),
+                vertical_buttons: false,
+                input: None,
+            });
+        }
+
         // ── #956: Kill terminal confirm ───────────────────────────────────
         if let Some(ref p) = self.pending_kill_terminal {
             return Some(Dialog {
@@ -3077,6 +3165,13 @@ impl CoordApp {
                 "CI gate stays in place",
                 ToastSeverity::Info,
             );
+        } else if self.pending_merge_revalidate.is_some() {
+            self.pending_merge_revalidate = None;
+            self.push_toast(
+                "Revalidate cancelled",
+                "entry stays blocked — nothing changed",
+                ToastSeverity::Info,
+            );
         } else if self.pending_restart.is_some() {
             self.pending_restart = None;
         } else if self.pending_kill_terminal.is_some() {
@@ -3662,6 +3757,26 @@ impl CoordApp {
             return;
         }
 
+        // ── #2402: Re-verify (revalidate) ──────────────────────────────────
+        if let Some(p) = self.pending_merge_revalidate.clone() {
+            match id {
+                "yes" => {
+                    self.pending_merge_revalidate = None;
+                    self.confirm_merge_revalidate(p);
+                }
+                _ => {
+                    self.pending_merge_revalidate = None;
+                    self.push_toast(
+                        "Revalidate cancelled",
+                        "entry stays blocked — nothing changed",
+                        ToastSeverity::Info,
+                    );
+                }
+            }
+            *self.dialog_layout.borrow_mut() = None;
+            return;
+        }
+
         // ── #956: Kill terminal ────────────────────────────────────────────
         if let Some(p) = self.pending_kill_terminal.clone() {
             if id == "yes" {
@@ -6675,6 +6790,38 @@ impl CoordApp {
                 self.dispatch_merge_automated_for_selected_pipeline_issue();
                 true
             }
+            // #2402: Pipeline row → "Re-verify (revalidate)" — arms the
+            // confirm dialog (`pending_merge_revalidate`, resolved by
+            // `confirm_merge_revalidate`) rather than spawning directly, the
+            // same posture `pending_force_merge` takes for a gate-bypass
+            // action (#1214 precedent): `--revalidate` runs a real
+            // build+test locally on the daemon host, so it isn't a bare
+            // click-and-go. `context_menu_items_for_pipeline_row` already
+            // confirmed BLOCKED + a revalidate-eligible reason before
+            // offering this item, so this arm only resolves the
+            // `assignment_id` to pass — it does not re-check eligibility.
+            "merge-revalidate" => {
+                if let ContextMenuTarget::PipelineRow {
+                    issue_number: Some(n),
+                    repo_name: Some(r),
+                    ..
+                } = target
+                {
+                    let repo_slug = self.pipeline_issues.iter().find_map(|iss| {
+                        (iss.number == *n && iss.coord_repo.as_deref() == Some(r.as_str()))
+                            .then_some(iss.repo_slug.clone())
+                    });
+                    if let Some(entry) = repo_slug
+                        .and_then(|slug| self.merge_plan_entry_for_issue(&slug, *n).cloned())
+                    {
+                        self.pending_merge_revalidate = Some(PendingMergeRevalidate {
+                            assignment_id: entry.assignment_id,
+                            issue_num: *n,
+                        });
+                    }
+                }
+                true
+            }
             // #1398: "Drive (automated)" — `coord drive <repo> <issue>
             // --tmux`, detached so it survives the TUI restarting.
             "start-drive" => {

{code_coordinator-0.5.150 → code_coordinator-0.5.153}/tui/src/app/doc_tabs.rs

@@ -14,8 +14,10 @@
 //! A document key is `(repo, issue_number)`. Each [`PanelScope`] owns its own
 //! [`DocTabGroup`]: an ordered `Vec<DocKey>`, the index of the active tab, and
 //! optionally the index of the single preview tab. The scope split is what
-//! keeps Board's and Pipeline's sets from merging (contract §3b) — this slice
-//! only wires `Board`, but the shape is the one #2284 inherits.
+//! keeps Board's and Pipeline's sets from merging (contract §3b) — #2282
+//! wired `Board`; #2284 wires `Pipeline` against this same shape, one
+//! `DocTabGroup` per scope, so the two never merge, reorder or drop into
+//! each other when the active panel switches.
 //!
 //! # Open semantics (contract §2e)
 //!
@@ -50,11 +52,10 @@ use crate::app::format::trunc;
 #[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
 pub(crate) enum PanelScope {
     Board,
-    /// Reserved for #2284, which gives the Pipeline panel its own tab set.
-    /// [`DocTabs::group`]/[`DocTabs::group_mut`] already route to it, but no
-    /// caller constructs this variant until that slice lands — hence the
-    /// allow, which should be deleted (not widened) by #2284.
-    #[allow(dead_code)]
+    /// #2284: the Pipeline panel's own independent tab set — same
+    /// preview/pin semantics as Board, stored and revealed against the
+    /// Pipeline sidebar (never the Board's). See `pipeline.rs`'s
+    /// "#2284 (ms-65 §3): Pipeline document tabs" section.
     Pipeline,
 }