code-coordinator 0.5.63__tar.gz → 0.5.65__tar.gz

code_coordinator-0.5.65/.github/coord-ci-acceptance.yml

@@ -0,0 +1,94 @@
+# #2180: a minimal, CI-ONLY coordinator.yml so `.github/workflows/*.yml` can
+# invoke `coord acceptance run --all --ci` (#2164's CI wrapper, PR #2173).
+#
+# This is deliberately NOT the fleet's real coordinator.yml. That file lives
+# outside this repo (~/.coord/coordinator.yml on the coordinator host,
+# "updated out-of-band" per scripts/coord-test-runner.sh's own header) and is
+# unreachable from a GitHub Actions runner. `coord acceptance run` needs
+# SOME coordinator.yml to resolve `acceptance.drivers.claude-coordinator`
+# (and, being the same parser as the fleet config, a non-empty `repos:` /
+# `machines:` list even though nothing here is a real machine) — this file
+# is that, scoped to exactly what CI needs and nothing else.
+#
+# The three routes below mirror the fleet's real
+# `acceptance.drivers.claude-coordinator.routes` (#1125 in-repo path
+# routing: coord/dashboard/webapp/** -> web-playwright, coord/** ->
+# cli-pytest, tui/** -> tui-tuidriver) with ONE deliberate difference: none
+# of these `run:` commands reference the `{ms}` template.
+#
+# `{ms}` only gets substituted when `coord acceptance run` is scoped to one
+# issue (`--issue N`, resolved via the issue's manifest-mapped ms-NN dir,
+# coord/commands/acceptance.py). `--all` (Gate C, what `--ci` requires)
+# always passes `ms=None` — coord.acceptance_drivers.render_run_command
+# documents that it leaves `{ms}` UNSUBSTITUTED (literal) in that case,
+# by design, for a driver whose `run:` never references it at all (like
+# tui-tuidriver's below). A route written for `--issue` scoping, like the
+# fleet's real `pytest tests/acceptance/{ms}`, would try to literally
+# collect a path named `tests/acceptance/{ms}` under `--all` and crash
+# outright — confirmed locally 2026-08-14 authoring this file:
+#   $ pytest 'tests/acceptance/{ms}' -q
+#   ERROR: file or directory not found: tests/acceptance/{ms}
+# So the two use cases need different `run:` commands over the SAME
+# underlying suite: the fleet config's per-issue routes stay as they are
+# (a worker's own `--issue N` self-check, unaffected by this file), and
+# this file's routes are written to always cover every ms-NN under that
+# route in one pass — exactly what the accumulated Gate C suite needs.
+repos:
+  - name: claude-coordinator
+    github: JDonaghy/claude-coordinator
+    default_branch: main
+
+# Not a real fleet machine — just enough for coord.config.load() to parse.
+# `coord.acceptance.acceptance_capability_gap` gives an unrecognized host
+# (any GitHub Actions runner, which will never match `host:` below) the
+# benefit of the doubt and proceeds rather than refusing, so this entry is
+# never actually matched against anything at run time.
+machines:
+  - name: ci-runner
+    host: ci-runner
+
+acceptance:
+  drivers:
+    claude-coordinator:
+      routes:
+        # #1540: coord/dashboard/webapp/** MUST stay above coord/** below —
+        # driver_for() resolves the first matching route (fnmatch,
+        # first-match not most-specific), and coord/dashboard/webapp/** is a
+        # strict subset of coord/**.
+        - match: coord/dashboard/webapp/**
+          kind: web-playwright
+          # No `setup:` here — the CI job that uses this route provisions
+          # explicitly (npm ci, playwright install chromium --with-deps)
+          # before invoking the wrapper, matching the shape that job already
+          # had before #2180 wired the wrapper in.
+          # The trailing `--` matters: _run_web_playwright appends
+          # ` --reporter=json` verbatim (coord/acceptance_drivers.py), so
+          # without it npm would try to interpret --reporter=json as an npm
+          # CLI flag instead of forwarding it to the playwright binary.
+          run: "cd coord/dashboard/webapp && npm run test:acceptance --"
+          mock: "*.html"
+          capability: browser
+        - match: coord/**
+          kind: cli-pytest
+          # Whole tree, not one ms-NN dir -- see the file header.
+          run: "pytest tests/acceptance"
+          mock: "*.out"
+          capability: python
+        - match: tui/**
+          kind: tui-tuidriver
+          # Unlike the two routes above, this one is identical to the
+          # fleet's real route: it never referenced `{ms}` even for
+          # `--issue` scoping, since `cargo test --test acceptance` always
+          # runs the whole tui/tests/acceptance.rs entrypoint (which
+          # `include!`s every ms-NN/*.rs slice) regardless of `{ms}`.
+          # RUSTC_BOOTSTRAP=1 + -Z unstable-options: --format json is
+          # nightly-gated; verified working on stable rustc (#1042).
+          # --features test-support: tui/Cargo.toml's `acceptance` test
+          # target has `required-features = ["test-support"]`, so a plain
+          # `cargo test` (no flag) silently skips building/running it
+          # altogether -- that gap is exactly what made this route
+          # unreachable from CI before #2180.
+          run: "cd tui && RUSTC_BOOTSTRAP=1 cargo test --test acceptance --features test-support -- -Z unstable-options --format json"
+          mock: "*.screen"
+          capability: rust
+          entrypoint: tui/tests/acceptance.rs

code_coordinator-0.5.65/.github/workflows/cargo-test.yml

@@ -0,0 +1,122 @@
+name: Rust tests
+
+# Closes the gap documented in GOAL.md (2026-06-11):
+#   "CI is pytest-only, so Rust repos (tui/quadraui/vimcode) still have no
+#    automated gate; they need an explicit cargo build && cargo test gate."
+# Issue #741 called for either resolving or tracking the gap — this resolves it
+# for the coord-tui crate (the tui/ subdirectory of this repo).
+#
+# #1973: tui/Cargo.toml pins quadraui by `git`/`rev` rather than a sibling
+# path dependency, so `cargo test` here fetches quadraui straight from
+# GitHub at the pinned rev — there is nothing left to check out or reproduce
+# a sibling-directory layout for. That also retired this workflow's original
+# #1865 role: the schedule/workflow_dispatch "canary" triggers below used to
+# build tui/ against quadraui's *moving* `develop` branch specifically to
+# catch a quadraui-side break before it reached coord-tui. Since the pin, a
+# scheduled run here would just rebuild the same pinned rev every time and
+# report green regardless of what quadraui's develop is doing — a canary
+# that can't smell smoke. Per #1973's decision, vimcode (which keeps the
+# floating path dep on purpose) is the sole canary for quadraui breaks going
+# forward; this workflow is back to being a plain gate on tui/** changes.
+on:
+  push:
+    branches: [main]
+    paths:
+      - 'tui/**'
+      # #2180: tui/tests/acceptance.rs (the sealed oracle's crate root,
+      # `include!`d into `cargo test --test acceptance`) is under tui/** and
+      # already covered above, but the JIT-authored slices it `include!`s
+      # live at the REPO ROOT (tests/acceptance/ms-33/, ms-38/), outside
+      # tui/**. Without this, a worker's fix to a red-by-design slice would
+      # never re-trigger this workflow at all.
+      - 'tests/acceptance/**'
+      # Self-trigger so edits to this workflow are exercised by their own PR.
+      - '.github/workflows/cargo-test.yml'
+      # Same reasoning as tests/acceptance/** above, for the CI-local config
+      # the new acceptance step (below) reads its driver command from.
+      - '.github/coord-ci-acceptance.yml'
+  pull_request:
+    branches: [main]
+    paths:
+      - 'tui/**'
+      - 'tests/acceptance/**'
+      # Self-trigger so edits to this workflow are exercised by their own PR.
+      - '.github/workflows/cargo-test.yml'
+      - '.github/coord-ci-acceptance.yml'
+  # Manual re-run convenience — no longer a "check tui/ against quadraui
+  # develop" canary (see #1973 note above); it now just builds tui/ at
+  # whatever ref is checked out, same as push/pull_request.
+  workflow_dispatch:
+
+jobs:
+  cargo-test:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+
+      - uses: dtolnay/rust-toolchain@stable
+
+      - uses: Swatinem/rust-cache@v2
+        with:
+          workspaces: tui
+
+      # A few tui integration tests (commands::tests) spawn the real `coord`
+      # CLI (e.g. `coord --version`) via Command::new("coord") and assert it
+      # succeeds, so the Python package must be installed and on PATH inside
+      # this otherwise Rust-only job.
+      - uses: actions/setup-python@v5
+        with:
+          python-version: '3.12'
+
+      - name: Install coord CLI (tui integration tests spawn it)
+        run: pip install -e .
+
+      - name: cargo test (tui)
+        working-directory: tui
+        run: cargo test
+
+      # #2180: the tui-tuidriver sealed acceptance route (acceptance.drivers
+      # routes "tui/**" -> tui-tuidriver -> tui/tests/acceptance.rs, which
+      # `include!`s tests/acceptance/ms-33/ and ms-38/) run through the
+      # #2164 CI wrapper. Plain `cargo test` above does NOT exercise this —
+      # the `acceptance` test target has `required-features = ["test-
+      # support"]` (tui/Cargo.toml), so cargo silently skips building it
+      # without that flag. Before #2180 nothing in CI ran this route at all.
+      # Working directory is the repo root (not `tui`, unlike the step
+      # above): the driver's own `run:` command does its own `cd tui`.
+      #
+      # TEMPORARILY continue-on-error (STEP level only — same reasoning and
+      # same shape as the `windows` job in test.yml, see its header comment
+      # for why step-level and not job-level): running this route for the
+      # very first time (verified locally, 2026-08-14, authoring this PR)
+      # surfaced SIX pre-existing failures that predate #2180 and are not
+      # yet declared in either manifest's `expected_red:` —
+      #   - ms-38/manifest.yml's own comment already documents all five
+      #     `plans_detail_1122::*` tests as blocked on a harness gap (no
+      #     public fixture seam for a seeded plan row) — #2164's
+      #     `expected_red:` mechanism didn't exist when that comment was
+      #     written; it's the natural home for these now.
+      #   - ms-33's `audit_1039::populated_list_rows_are_relative_time` is a
+      #     newly-discovered ticking-time-bomb regression: its fixture pins
+      #     timestamps "~1 year in the past" (a fixed epoch, ts~=1752156191)
+      #     so `format_unix_time()` always renders an "... ago" suffix — true
+      #     when ms-33 was authored, false today (now >13 months stale) now
+      #     that format_unix_time() has crossed whatever threshold stops
+      #     appending "ago" for very old timestamps. This one is NOT already
+      #     documented as expected — it looks like a genuine, ordinary bug a
+      #     test-author/fix session should look at, not just declare red.
+      # Both `tests/acceptance/` and its `manifest.yml` files are SEALED
+      # (coord.config.AcceptanceConfig.sealed_paths) — a `type="work"`
+      # session (this one) editing them trips the oracle-tamper gate at
+      # review, so this PR deliberately does not add `expected_red:` entries
+      # itself. REVISIT: once a test-author/fix session addresses the six
+      # failures above (declaring the five documented ones in
+      # `expected_red:`, fixing or re-baselining the sixth), drop this
+      # continue-on-error and this becomes a real, blocking gate like the
+      # `acceptance` (ms-51) and cli-pytest (ms-37) routes already are.
+      - name: coord acceptance run --all --ci (tui-tuidriver route, ms-33/ms-38)
+        run: >-
+          coord acceptance run --repo claude-coordinator --all --ci
+          --for-path tui/src/main.rs
+          --config .github/coord-ci-acceptance.yml --path .
+        continue-on-error: true

{code_coordinator-0.5.63 → code_coordinator-0.5.65}/.github/workflows/test.yml

@@ -18,7 +18,33 @@ jobs:
         with:
           python-version: ${{ matrix.python-version }}
       - run: pip install -e ".[dev]"
-      - run: pytest
+      # #2180: `--ignore=tests/acceptance` — the sealed oracle-loop suite
+      # (tests/acceptance/ms-NN/) is split out of the ordinary suite and
+      # gated separately, through `coord acceptance run --all --ci` (see the
+      # `acceptance-cli` step below and the `acceptance` job further down),
+      # which honours each ms-NN/manifest.yml's `expected_red:` registry
+      # (#2164). Left in here, a red-by-design slice would fail this job
+      # outright — every ordinary PR in the repo, not just the one the slice
+      # belongs to — exactly the quadraui#554/#490 failure mode #2180 exists
+      # to close. ms-33/ms-38 (Rust, feature-gated behind test-support) and
+      # ms-51 (Playwright, not .py) were never swept in here; ms-37 (plain
+      # .py files under testpaths=["tests"]) was the one accidental gap.
+      - run: pytest --ignore=tests/acceptance
+      # #2180: the cli-pytest sealed route (acceptance.drivers routes
+      # "coord/**" -> cli-pytest -> tests/acceptance/ms-37) run through the
+      # #2164 CI wrapper instead of a raw `pytest tests/acceptance` call, so
+      # expected_red is honoured. One matrix leg only — the suite result
+      # doesn't depend on the Python version any differently than the
+      # ordinary suite above does, so running it twice would just double the
+      # cost for no new signal. See .github/coord-ci-acceptance.yml's header
+      # for why this points at a CI-local config rather than
+      # ~/.coord/coordinator.yml (unreachable from a runner).
+      - name: coord acceptance run --all --ci (cli-pytest route, ms-37)
+        if: matrix.python-version == '3.12'
+        run: >-
+          coord acceptance run --repo claude-coordinator --all --ci
+          --for-path coord/cli.py
+          --config .github/coord-ci-acceptance.yml --path .
 
   # #1895 (CP-4 slice of #1159): real Windows verification — the repo is
   # public, so `windows-latest` runners cost nothing.
@@ -83,7 +109,10 @@ jobs:
       # visible in the log as a failed test.
       - run: pip install -e ".[dev]"
         continue-on-error: true
-      - run: pytest
+      # #2180: same split as the `test` job above — the sealed acceptance
+      # suite is gated separately through the #2164 CI wrapper, not swept
+      # into this job's ordinary pytest run.
+      - run: pytest --ignore=tests/acceptance
         continue-on-error: true
 
   # #1484: run the full suite with `gh` made unresolvable on PATH.
@@ -113,7 +142,9 @@ jobs:
         with:
           python-version: "3.12"
       - run: pip install -e ".[dev]"
-      - run: scripts/run_tests_without_gh.sh python -m pytest tests/ -q
+      # #2180: same split as the `test` job — the sealed acceptance suite is
+      # gated separately through the #2164 CI wrapper.
+      - run: scripts/run_tests_without_gh.sh python -m pytest tests/ -q --ignore=tests/acceptance
 
   # #2170: run the full suite in the environment of a REAL FLEET MACHINE — a
   # populated `~/.coord/` (thin-client shaped), no `sqlite3` on PATH, and a
@@ -154,7 +185,9 @@ jobs:
         with:
           python-version: "3.12"
       - run: pip install -e ".[dev]"
-      - run: scripts/run_tests_in_populated_home.sh python -m pytest tests/ -q
+      # #2180: same split as the `test` job — the sealed acceptance suite is
+      # gated separately through the #2164 CI wrapper.
+      - run: scripts/run_tests_in_populated_home.sh python -m pytest tests/ -q --ignore=tests/acceptance
       - name: What a red result here means
         if: failure()
         run: |
@@ -271,6 +304,20 @@ jobs:
   # full path/title on failure, so the ms-NN + issue are already in the
   # job's own output; the failure-hint step below just spells out the two
   # possible causes so whoever triages it doesn't have to rediscover them.
+  #
+  # #2180: the `npm run test:acceptance` step now runs THROUGH `coord
+  # acceptance run --all --ci` (#2164) instead of calling Playwright
+  # directly. Same suite, same reporter under the hood — the wrapper's
+  # web-playwright driver shape appends `--reporter=json` and reads
+  # PLAYWRIGHT_JSON_OUTPUT_FILE itself (coord/acceptance_drivers.py) — but
+  # now a test-id listed in a manifest's `expected_red:` that fails does not
+  # redden this job (a sealed slice authored red before its fix exists,
+  # #2164's whole point), while one that unexpectedly PASSES does, loudly
+  # (#1965's vacuous-assertion case). Before this, ms-51 going red for any
+  # reason failed this job exactly the same as every other kind of red —
+  # there was no way to merge a red-by-design slice without `--force-merge`.
+  # .github/coord-ci-acceptance.yml's header explains why this points at a
+  # CI-local config instead of the fleet's real ~/.coord/coordinator.yml.
   acceptance:
     runs-on: ubuntu-latest
     defaults:
@@ -288,7 +335,12 @@ jobs:
           node-version: '20'
       - run: npm ci
       - run: npx playwright install chromium --with-deps
-      - run: npm run test:acceptance
+      - name: coord acceptance run --all --ci (web-playwright route, ms-51)
+        working-directory: .
+        run: >-
+          coord acceptance run --repo claude-coordinator --all --ci
+          --for-path coord/dashboard/webapp/src/App.tsx
+          --config .github/coord-ci-acceptance.yml --path .
       - name: A red result here is attributable, not a mystery
         if: failure()
         run: |

{code_coordinator-0.5.63/code_coordinator.egg-info → code_coordinator-0.5.65}/PKG-INFO

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

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: code-coordinator
-Version: 0.5.63
+Version: 0.5.65
 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.63 → code_coordinator-0.5.65}/code_coordinator.egg-info/SOURCES.txt

@@ -14,6 +14,7 @@ pyproject.toml
 .githooks/post-checkout
 .githooks/post-commit
 .githooks/post-merge
+.github/coord-ci-acceptance.yml
 .github/ISSUE_TEMPLATE/bug_report.md
 .github/workflows/auto-release.yml
 .github/workflows/cargo-test.yml

{code_coordinator-0.5.63 → code_coordinator-0.5.65}/code_coordinator.egg-info/scm_file_list.json

@@ -8,6 +8,7 @@
     ".githooks/post-commit",
     ".githooks/post-merge",
     ".github/ISSUE_TEMPLATE/bug_report.md",
+    ".github/coord-ci-acceptance.yml",
     ".github/workflows/auto-release.yml",
     ".github/workflows/cargo-test.yml",
     ".github/workflows/publish.yml",

{code_coordinator-0.5.63 → code_coordinator-0.5.65}/code_coordinator.egg-info/scm_version.json

@@ -1,7 +1,7 @@
 {
-  "tag": "0.5.63",
+  "tag": "0.5.65",
   "distance": 0,
-  "node": "gb547d297bb611bfa65077c4a7d42c08edbf3cd8c",
+  "node": "g58dde32efe3e0c9e230599f9c2fa0eeb9f41671a",
   "dirty": false,
   "branch": "HEAD",
   "node_date": "2026-08-14"

{code_coordinator-0.5.63 → code_coordinator-0.5.65}/coord/commands/drive_queue.py

@@ -50,6 +50,7 @@ from coord.drive_queue import (
     QUEUE_ALERT_STAGE,
     RESUME_PROBE_TIMEOUT_SECONDS,
     STATE_BLOCKED,
+    STATE_FAILED,
     STATE_PARKED,
     STATE_RUNNING,
     STATE_WAITING,
@@ -59,8 +60,10 @@ from coord.drive_queue import (
     QueueError,
     TickPlan,
     build_board_view,
+    diagnose_blocked_after,
     entries_from_rows,
     entry_key,
+    find_cycle,
     fired_holds,
     parse_after_spec,
     parse_key,
@@ -300,6 +303,50 @@ def validate_config_repo(config_path: Path, repo: str) -> None:
 
 # ── list ─────────────────────────────────────────────────────────────────────
 
+# `blocked`/`failed` are the two states #2183's re-diagnosis applies to: both
+# are in `TERMINAL_QUEUE_STATES` (the tick will never look at this row's
+# `after=` graph again), so both are exactly where a stale `after=` reading
+# can survive indefinitely. `done` is also terminal but carries no live
+# "why is this stuck" question — nothing to re-diagnose.
+_DIAGNOSABLE_STATES = (STATE_BLOCKED, STATE_FAILED)
+
+# How much of a (possibly multi-line, possibly paragraph-length) `last_reason`
+# fits on the summary row itself, next to `attempts=`/`deferrals=`, without
+# wrapping a normal terminal. The FULL text always still prints on the `last:`
+# continuation line right below — this is only the on-row teaser.
+_ROW_CAUSE_MAX_CHARS = 88
+
+_BLOCKED_REMEDY = (
+    "remedy: {state} is terminal — the queue will not re-check this row "
+    "on its own; `coord drive-queue remove` + `add` only helps once the "
+    "cause above is actually fixed, not merely because a pre-req merged"
+)
+
+
+def _row_cause(reason: str) -> str:
+    """The first line of *reason*, clipped to fit the summary row (#2183)."""
+    first_line = reason.strip().splitlines()[0] if reason.strip() else ""
+    if len(first_line) > _ROW_CAUSE_MAX_CHARS:
+        return first_line[: _ROW_CAUSE_MAX_CHARS - 1].rstrip() + "…"
+    return first_line
+
+
+def _board_for_list_diagnosis() -> BoardView | None:
+    """The board, for `list`'s #2183 re-diagnosis — ``None`` when unreachable.
+
+    Unlike `tick`, `list` is a read-only inspection command an operator runs
+    often and expects to be fast and always available, so an unreachable
+    board must never make it fail or hang the way `tick`'s fail-closed abort
+    does. ``None`` here means "skip the re-diagnosis" — every row falls back
+    to exactly today's rendering (the `after=` list unfiltered, no cause on
+    the row itself), never a crash or a misleading empty board's worth of
+    "everything is unsatisfied".
+    """
+    try:
+        return _fetch_board_view()
+    except Exception:  # noqa: BLE001 — see docstring: this must never fail `list`
+        return None
+
 
 @drive_queue_group.command("list")
 @click.option("--repo", "repo", default=None, help="Restrict to one repo (default: every repo).")
@@ -317,12 +364,61 @@ def drive_queue_list(repo: str | None, output_json: bool, config_path: Path) ->
         click.echo("(drive queue is empty)")
         return
     now = time.time()
-    for entry in entries_from_rows(rows):
-        bits = [f"{entry.position:>2}  {entry.key:<28} {entry.state}"]
+    entries = entries_from_rows(rows)
+
+    # #2183: a `blocked`/`failed` row's `after=` graph needs to be re-checked
+    # against the FULL queue (cross-repo pre-reqs), not just whatever `--repo`
+    # filtered down to — otherwise a `--repo` view would misdiagnose an
+    # out-of-repo pre-req as "unknown to the queue" purely from the filter,
+    # not from anything actually true.
+    all_entries = entries if repo is None else entries_from_rows(list_drive_queue())
+    # A row with no `after=` at all has nothing for #2183's re-diagnosis to
+    # do — criterion "entries with no after= are unaffected" — so both the
+    # board fetch and the per-row diagnosis below are gated on `entry.after`
+    # being non-empty, not just on the state being terminal.
+    needs_diagnosis = any(
+        e.state in _DIAGNOSABLE_STATES and e.after for e in entries
+    )
+    board = _board_for_list_diagnosis() if needs_diagnosis else None
+    states = {e.key: e.state for e in all_entries}
+    cycle_keys: dict[str, str] = {}
+    cycle = find_cycle({e.key: list(e.after) for e in all_entries})
+    if cycle is not None:
+        message = "dependency cycle: " + " -> ".join(cycle)
+        for key in cycle:
+            cycle_keys[key] = message
+
+    for entry in entries:
+        diagnosed = (
+            board is not None and entry.state in _DIAGNOSABLE_STATES and bool(entry.after)
+        )
+        unsatisfied = entry.after
+        dependency_reason = ""
+        if diagnosed:
+            diagnosis = diagnose_blocked_after(entry, board, states, cycle_keys)
+            unsatisfied = diagnosis.unsatisfied
+            dependency_reason = diagnosis.dependency_reason
+
+        # A diagnosed row whose block is NOT (or no longer) caused by its
+        # `after=` graph gets its own cause on the state token itself — #2183
+        # point 2: the terminal reason leads, not a dependency list that may
+        # have nothing to do with it. A row that IS dependency-caused (or
+        # wasn't diagnosed at all) keeps the plain state token unchanged.
+        state_label = entry.state
+        if diagnosed and not dependency_reason and entry.last_reason:
+            state_label = f"{entry.state}: {_row_cause(entry.last_reason)}"
+
+        bits = [f"{entry.position:>2}  {entry.key:<28} {state_label}"]
         if entry.machine:
             bits.append(f"machine={entry.machine}")
-        if entry.after:
-            bits.append(f"after={','.join(entry.after)}")
+        # Suppress `after=` entirely on a diagnosed row that is NOT
+        # dependency-caused: every named pre-req is either satisfied or was
+        # never the reason this row is stuck, so showing it invites exactly
+        # the misreading #2183 exists to stop. Otherwise (not diagnosed, or
+        # genuinely dependency-caused) show whatever is still unsatisfied.
+        show_after = () if (diagnosed and not dependency_reason) else unsatisfied
+        if show_after:
+            bits.append(f"after={','.join(show_after)}")
         if entry.attempts:
             bits.append(f"attempts={entry.attempts}")
         if entry.deferrals:
@@ -334,6 +430,11 @@ def drive_queue_list(repo: str | None, output_json: bool, config_path: Path) ->
         click.echo("  ".join(bits))
         if entry.last_reason:
             click.echo(f"      last{_reason_age_suffix(entry, now)}: {entry.last_reason}")
+        if diagnosed:
+            # #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)}")
         for line in _hold_lines(entry):
             click.echo(line)
 

{code_coordinator-0.5.63 → code_coordinator-0.5.65}/coord/drive_queue.py

@@ -1182,6 +1182,63 @@ def _resolve_prereqs(
     return _Verdict(True)
 
 
+@dataclass(frozen=True)
+class BlockedAfterDiagnosis:
+    """How #2183's rendering should treat a terminal row's `after=` graph.
+
+    ``unsatisfied`` is *entry*'s declared ``after=`` list with every
+    now-landed pre-req dropped. ``dependency_reason`` is the CURRENT
+    ``_resolve_prereqs`` verdict against that same graph — ``''`` when the
+    graph is not (or no longer) why the entry is stuck.
+    """
+
+    unsatisfied: tuple[str, ...] = ()
+    dependency_reason: str = ""
+
+
+def diagnose_blocked_after(
+    entry: QueueEntry,
+    board: BoardView,
+    states: Mapping[str, str],
+    cycle_keys: Mapping[str, str],
+) -> BlockedAfterDiagnosis:
+    """Re-check a `blocked`/`failed` row's `after=` graph against the CURRENT
+    board, fresh on every render (#2183).
+
+    ``entry.after`` is what ``add`` declared, frozen at enqueue time — and a
+    `blocked`/`failed` entry's own state never re-evaluates it again
+    (:data:`TERMINAL_QUEUE_STATES` is exactly "the tick will not look at this
+    row again"). By the time an operator reads the row, a pre-req that has
+    since merged is stale information still rendered as if current — the
+    quadraui#542 incident this closes: the row's `after=` named a pre-req
+    that had merged an hour earlier, reading as "blocked on a dependency
+    that is already satisfied" when the real cause was an unrelated red
+    slice PR.
+
+    Two things are recomputed, never read off the entry's own frozen
+    ``last_reason``:
+
+    * which of ``entry.after`` are still NOT landed — the merged ones drop
+      out entirely; a satisfied ``after=`` entry displayed on a terminal row
+      is not a dependency, it is a caption for a fact that no longer holds;
+    * whether the CURRENT pre-req graph is even a plausible cause —
+      delegated to :func:`_resolve_prereqs`, the exact function a live tick
+      uses to decide this, so a render can never disagree with what the tick
+      itself would conclude. An empty ``dependency_reason`` means the
+      answer is no: every named pre-req is now satisfied (or the entry
+      declared none), so whatever originally blocked this row — a red build,
+      an exhausted retry budget, a refused pre-dispatch guard — was NOT its
+      ``after=`` list, and the row's own ``last_reason`` is the real story.
+    """
+    unsatisfied = tuple(dep for dep in entry.after if not board.facts(dep).landed)
+    if not entry.after:
+        return BlockedAfterDiagnosis(unsatisfied)
+    verdict = _resolve_prereqs(entry, board, states, cycle_keys, held_gates={})
+    return BlockedAfterDiagnosis(
+        unsatisfied, "" if verdict.satisfied else verdict.reason
+    )
+
+
 # ── reconciliation ───────────────────────────────────────────────────────────