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

code_coordinator-0.5.64/.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.64/.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.64}/.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.64}/PKG-INFO

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

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

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

{code_coordinator-0.5.63 → code_coordinator-0.5.64}/scripts/coord-test-runner.sh

@@ -480,6 +480,50 @@ CARGO_SEARCHED='PATH, ${CARGO_HOME:-$HOME/.cargo}/bin/cargo, `rustup which cargo
 
 # ── python ───────────────────────────────────────────────────────────────────
 
+# #2180 (review fix): run the sealed cli-pytest acceptance route (ms-37)
+# through the SAME #2164 `--ci` wrapper CI's `test` job uses
+# (.github/workflows/test.yml's "coord acceptance run --all --ci
+# (cli-pytest route, ms-37)" step), instead of just excluding it. Excluding
+# it outright (the original #2180 change) left a gap the reviewer caught:
+# an `expected_red`-listed test that unexpectedly PASSES (the #1965
+# vacuous-assertion case #2164 exists to catch) would be silently waved
+# through by the Test stage — it never ran that suite at all — while CI's
+# `test` job (no continue-on-error on this step) correctly reddens for the
+# same branch. That is exactly the "Test stage tolerates what CI rejects"
+# split the issue's acceptance criteria forbid. The wrapper is what closes
+# it: `--ci` still tolerates a red-by-design slice (so a concurrent branch
+# isn't punished for someone else's in-flight fix, the quadraui#554/#490
+# failure mode #2180 exists to close) while turning a test that passes when
+# it shouldn't into a hard failure.
+#
+# Deliberately no `--config`: unlike CI (a GitHub Actions runner with no
+# access to the fleet's coordinator.yml, hence the CI-only
+# .github/coord-ci-acceptance.yml fragment), this script runs ON the
+# daemon host, whose real ~/.coord/coordinator.yml already declares
+# `acceptance.drivers.claude-coordinator`'s routes — the CI-only fragment's
+# own header says it mirrors them verbatim. `coord acceptance run`'s
+# default `--config` resolution ($COORD_CONFIG -> ~/.coord/coordinator.yml
+# -> ./coordinator.yml) picks that up the same way every other `coord`
+# invocation on this host does.
+#
+# Called only after the ordinary suite above has already passed (or been
+# judged a tolerated flake) — same order CI enforces implicitly by running
+# this as a later, unguarded step: a genuinely broken ordinary suite must
+# not be masked by (or additionally blamed on) the acceptance route.
+run_python_acceptance_ci() {
+    local venv="$1"
+    local acc_out="$WT/.pytest-acceptance.out"
+    log "running: coord acceptance run --all --ci (cli-pytest route, ms-37)"
+    if ("$venv/bin/coord" acceptance run --repo claude-coordinator --all --ci \
+            --for-path coord/cli.py --path "$WT") >"$acc_out" 2>&1; then
+        say "PASS(python): ordinary suite + sealed acceptance suite (ms-37, cli-pytest) both green"
+        return 0
+    fi
+    say "FAIL(python): sealed acceptance suite (cli-pytest route, ms-37) failed under --ci — either a test-id NOT listed in expected_red failed for real, or one listed in expected_red unexpectedly passed (see .github/workflows/test.yml's 'A red result here is attributable, not a mystery' step for the two-cause triage)"
+    tail -n 40 "$acc_out" | sed 's/^/      /'
+    return 1
+}
+
 run_python() {
     local venv="$WT/.venv"
     if [[ ! -x "$venv/bin/python" ]]; then
@@ -509,11 +553,27 @@ run_python() {
 
     local out="$WT/.pytest.out"
     log "running: pytest -q ${par[*]:-(serial)} (full suite)"
+    # #2180: --ignore=tests/acceptance — the sealed oracle-loop suite
+    # (tests/acceptance/ms-NN/) is split out of the ORDINARY suite here and
+    # gated separately, below, through `coord acceptance run --all --ci`
+    # (#2164, run_python_acceptance_ci — see its header comment), which
+    # honours each ms-NN/manifest.yml's `expected_red:` registry. Left in
+    # this plain `pytest` invocation, a red-by-design slice would fail the
+    # Test stage for every concurrent branch in the repo, not just the one
+    # the slice belongs to (the quadraui#554/#490 failure mode #2180 exists
+    # to close). Matches CI's own .github/workflows/test.yml split — same
+    # reasoning applies verbatim, see that file's comments. ms-33/ms-38
+    # (Rust) and ms-51 (Playwright) were already outside this pytest arm's
+    # reach; ms-37 (plain .py files under testpaths=["tests"]) was the one
+    # accidental gap — and the one this arm still covers, just through the
+    # wrapper instead of directly.
+    #
     # ${par[@]+...} so an empty array is not an unbound-variable error under
     # `set -u` on older bash.
-    if (cd "$WT" && "$venv/bin/python" -m pytest -q --tb=short ${par[@]+"${par[@]}"}) >"$out" 2>&1; then
-        say "PASS(python): $(grep -oE '[0-9]+ passed[^)]*' "$out" | tail -1)"
-        return 0
+    if (cd "$WT" && "$venv/bin/python" -m pytest -q --tb=short --ignore=tests/acceptance ${par[@]+"${par[@]}"}) >"$out" 2>&1; then
+        log "ordinary suite: $(grep -oE '[0-9]+ passed[^)]*' "$out" | tail -1)"
+        run_python_acceptance_ci "$venv"
+        return $?
     fi
 
     # A collection/import error is never a flake — the suite could not even run.
@@ -539,7 +599,8 @@ run_python() {
         say "FLAKE(python): $count test(s) failed in the full run but PASS in isolation"
         printf '%s\n' "$failed" | sed 's/^/      /'
         FLAKES+=("python:$count")
-        return 0
+        run_python_acceptance_ci "$venv"
+        return $?
     fi
 
     # Not a flake. Before calling it the branch's fault, ask the question the
@@ -566,6 +627,43 @@ run_python() {
 
 # ── rust / coord-tui ─────────────────────────────────────────────────────────
 
+# #2180 (review fix): attempt the sealed tui-tuidriver acceptance route
+# (ms-33/ms-38) through the #2164 `--ci` wrapper, same shape as
+# run_python_acceptance_ci above — but NON-BLOCKING, deliberately, to match
+# .github/workflows/cargo-test.yml's own step, which carries
+# `continue-on-error: true` (STEP level, not job level — see that file's
+# comment for why). That workflow's continue-on-error is itself temporary:
+# running this route for the first time (2026-08-14) surfaced six
+# pre-existing failures that predate #2180 and aren't yet declared in
+# either manifest's `expected_red:` — writing that is the test-author
+# role's job (#2191), not this fix's, since tests/acceptance/ and its
+# manifest.yml files are sealed paths.
+#
+# NOTE(follow-up needed): unlike the `windows` job's non-blocking gap
+# (tracked as #1156), this one has no tracking issue yet — file one so
+# "REVISIT" doesn't quietly become permanent (review nit on #2180).
+#
+# Until that lands, blocking the Test stage on this route while CI itself
+# doesn't block on it would be the OPPOSITE split from the one #2180 exists
+# to close (Test stage rejecting what CI tolerates) — so this call reports
+# its result visibly but never fails the suite. Once the six failures above
+# are triaged (declared expected_red or fixed), both this function and
+# cargo-test.yml's continue-on-error should be dropped together.
+run_rust_acceptance_ci() {
+    local acc_out="$WT/.cargo-acceptance.out"
+    log "running: coord acceptance run --all --ci (tui-tuidriver route, ms-33/ms-38) — non-blocking, see comment above"
+    # RUSTC_BOOTSTRAP=1 is set by the driver's own `run:` command (see
+    # .github/coord-ci-acceptance.yml's tui-tuidriver route) — not needed
+    # here.
+    if (coord acceptance run --repo claude-coordinator --all --ci \
+            --for-path tui/src/main.rs --path "$WT") >"$acc_out" 2>&1; then
+        say "ACCEPTANCE(rust, non-blocking): sealed suite (ms-33/ms-38, tui-tuidriver) green under --ci"
+    else
+        say "ACCEPTANCE(rust, non-blocking): sealed suite (ms-33/ms-38, tui-tuidriver) red under --ci — NOT failing the Test stage (matches cargo-test.yml's continue-on-error, see run_rust_acceptance_ci's header comment)"
+        tail -n 40 "$acc_out" | sed 's/^/      /'
+    fi
+}
+
 run_rust() {
     # Resolve the toolchain BEFORE the symlink/build work: a missing cargo is
     # not a property of the branch, and finding out about it first keeps the
@@ -598,8 +696,17 @@ run_rust() {
     export CARGO_TARGET_DIR="$CARGO_TARGET"
     local out="$WT/.cargo.out"
     log "running: cargo test (cold ~3m, warm ~30s)"
+    # #2180: plain `cargo test` (no `--features test-support`) already
+    # excludes the sealed tui-tuidriver acceptance target — its `acceptance`
+    # test has `required-features = ["test-support"]` in tui/Cargo.toml, so
+    # cargo silently skips building it without that flag. That suite is
+    # attempted separately below, through run_rust_acceptance_ci — see its
+    # header comment for why that call is non-blocking (matches
+    # cargo-test.yml's continue-on-error) rather than duplicated here as a
+    # hard gate.
     if (cd "$WT/tui" && "$cargo" test) >"$out" 2>&1; then
         say "PASS(rust): $(grep -oE '[0-9]+ passed[^;]*' "$out" | head -1)"
+        run_rust_acceptance_ci
         return 0
     fi
 
@@ -635,6 +742,7 @@ run_rust() {
         say "FLAKE(rust): $count test(s) failed under full parallelism but PASS isolated (#1260 class)"
         printf '%s\n' "$failed" | sed 's/^/      /'
         FLAKES+=("rust:$count")
+        run_rust_acceptance_ci
         return 0
     fi
 

{code_coordinator-0.5.63 → code_coordinator-0.5.64}/scripts/next_release_tag.py

@@ -167,6 +167,12 @@ NON_SHIPPING_PREFIXES: tuple[str, ...] = (
     # range was one file, `.github/workflows/test.yml`: a release that shipped
     # nothing and moved the fleet's expected version for no payload.
     ".github/workflows/",
+    # #2180: a CI-only coordinator.yml fragment (see its own header) that
+    # `.github/workflows/*.yml` steps pass to `coord acceptance run --config`
+    # — same reasoning as `.github/workflows/` immediately above: it's read
+    # by a workflow step, not shipped to any wheel, binary, or host's unit
+    # directory. A tag changes nothing about what a CI run sees.
+    ".github/coord-ci-acceptance.yml",
 )
 
 #: SHIPPING_PREFIXES entries that ship a release (a tag, a GitHub Release)