code-coordinator 0.5.62__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.62 → 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.62/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.62
+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.62 → 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.62
+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.62 → 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.62 → 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.62 → code_coordinator-0.5.64}/code_coordinator.egg-info/scm_version.json

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

{code_coordinator-0.5.62 → code_coordinator-0.5.64}/coord/acceptance.py

@@ -886,6 +886,75 @@ def find_ms_manifest_for_issue_via_api(
     return None
 
 
+def missing_expected_red_warning(
+    repo_github: str, branch: str, issue_number: int, *, gh_ops: Any = None,
+) -> str | None:
+    """#2191 — the writer/gate seam: is *issue_number* the signature of an
+    unwritten ``expected_red`` registry on *branch*'s manifest? That
+    signature is checkable without ever running the suite: the manifest
+    maps at least one test id to *issue_number* (a slice was authored for
+    it) but records ZERO ``expected_red`` entries for it, and the issue is
+    still open. #2164 shipped a reader (:func:`apply_expected_red`), a
+    clearer (:func:`clear_expected_red_via_pr`) and a lister
+    (:func:`list_expected_red_via_api`) for this registry but no writer —
+    :data:`coord.test_author.TEST_AUTHOR_SYSTEM_PROMPT` step 4b is the
+    writer (the test-author records what it observed FAIL in its step-4
+    run). This function is the gate half: it does not trust the prompt was
+    followed, so it re-derives "was anything recorded" from the manifest
+    itself at slice-PR-open time (:func:`coord.merge_queue.process`'s
+    "Open PRs first" loop, gated on ``assignment_type == "test-author"``)
+    and flags exactly the case a skipped step 4b produces.
+
+    Returns ``None`` — nothing to flag — when: *branch*'s manifest doesn't
+    reference *issue_number* at all (no slice authored yet, out of scope);
+    ``expected_red`` already has a non-empty entry for it (the writer did
+    its job, or the slice is genuinely all-green and needs none); the issue
+    is closed (its slice already served its purpose — flagging it now is
+    stale noise, not #2191's live deadlock); or any lookup fails. The last
+    case is deliberate fail-open, matching every other best-effort API
+    sweep in this module (:func:`find_ms_manifest_for_issue_via_api`,
+    :func:`coord.merge_queue._issue_has_expected_red_entries`) — this check
+    is advisory (see the "refused or warned" phrasing in #2191's acceptance
+    criteria; callers choose which), so an unreachable API must degrade to
+    "say nothing," never to blocking a PR the check itself couldn't
+    evaluate.
+
+    Otherwise returns a human-readable warning naming the missing ids.
+    """
+    ops = gh_ops or _default_github_ops()
+    found = find_ms_manifest_for_issue_via_api(
+        repo_github, branch, issue_number, gh_ops=ops,
+    )
+    if found is None:
+        return None
+    path, _text, _blob_sha, data = found
+    if data.expected_red.get(issue_number):
+        return None
+    test_ids = test_ids_for_issue(data.tests, issue_number)
+    if not test_ids:
+        return None
+    live_state = getattr(ops, "get_issues_live_state", None)
+    if live_state is None:
+        return None
+    try:
+        states = live_state(repo_github, [issue_number])
+    except Exception:  # noqa: BLE001 — best-effort, fail open (see docstring)
+        return None
+    if states.get(issue_number) != "open":
+        return None
+    return (
+        f"#{issue_number}: {path} maps {len(test_ids)} test-id(s) to this "
+        f"issue ({', '.join(sorted(test_ids))}) but records no "
+        "`expected_red` entries for it — the #2191 signature of an "
+        "unwritten registry (the test-author's step 4b never ran, or was "
+        "skipped). If this slice is genuinely all-green already, ignore; "
+        "otherwise every red id here fails CI with nothing telling "
+        "`coord acceptance run --all --ci` that's expected, and `coord "
+        "merge` will need `--force-merge` or a hand-edited manifest to "
+        "land it."
+    )
+
+
 def list_expected_red_via_api(
     repo_github: str, branch: str, *, gh_ops: Any = None,
 ) -> "dict[str, dict[int, frozenset[str]]]":

{code_coordinator-0.5.62 → code_coordinator-0.5.64}/coord/commands/drive_queue.py

@@ -43,6 +43,8 @@ from coord.drive_queue import (
     DEFAULT_MAX_ATTEMPTS,
     DEFAULT_MAX_PARALLEL_PER_REPO,
     HOLD_RELEASED,
+    HOLD_SCOPE_ENTRY,
+    HOLD_SCOPE_FLEET,
     QUEUE_ALERT_ISSUE,
     QUEUE_ALERT_REPO,
     QUEUE_ALERT_STAGE,
@@ -155,6 +157,19 @@ def drive_queue_group() -> None:
         "treated as a failure. Requires --hold-after."
     ),
 )
+@click.option(
+    "--scope",
+    "hold_scope",
+    type=click.Choice([HOLD_SCOPE_ENTRY, HOLD_SCOPE_FLEET]),
+    default=HOLD_SCOPE_ENTRY,
+    show_default=True,
+    help=(
+        "How far a fired gate reaches (#2186). `entry` holds only entries "
+        "whose own --after names THIS one. `fleet` is the whole-queue stop — "
+        "launch NOTHING anywhere, for the rare case (a rename, a schema "
+        "migration) where that is really what's needed. Requires --hold-after."
+    ),
+)
 @_CONFIG_OPTION
 def drive_queue_add(
     repo: str,
@@ -165,6 +180,7 @@ def drive_queue_add(
     hold_after: bool,
     hold_reason: str,
     resume_when: str,
+    hold_scope: str,
     config_path: Path,
 ) -> None:
     """Queue REPO ISSUE for `coord drive`, or update it if already queued.
@@ -175,14 +191,36 @@ def drive_queue_add(
     """
     from coord.state import enqueue_drive_queue, list_drive_queue  # noqa: PLC0415
 
+    existing_entries = entries_from_rows(list_drive_queue())
     try:
         after = parse_after_spec(after_specs, repo)
         validate_config_repo(config_path, repo)
-        validate_hold_flags(hold_after, hold_reason, resume_when)
-        validate_enqueue(entries_from_rows(list_drive_queue()), repo, issue, after)
+        validate_hold_flags(hold_after, hold_reason, resume_when, hold_scope)
+        validate_enqueue(existing_entries, repo, issue, after)
     except QueueError as exc:
         raise click.ClickException(str(exc)) from None
 
+    # #2186: the UPDATE path in `_enqueue_drive_queue_local` always writes
+    # whatever `hold_scope` THIS call passed (default `entry`) — so re-adding
+    # an already fleet-scoped gate without repeating `--scope fleet` silently
+    # narrows it. That fails toward the safer/narrower scope, not a
+    # correctness bug, but it is a real behaviour change an operator who only
+    # meant to touch `--machine`/`--after` would not expect, so it is echoed
+    # rather than left silent.
+    previous = next((e for e in existing_entries if e.key == entry_key(repo, issue)), None)
+    scope_downgrade_warning = ""
+    if (
+        previous is not None
+        and previous.hold_scope == HOLD_SCOPE_FLEET
+        and hold_after
+        and hold_scope != HOLD_SCOPE_FLEET
+    ):
+        scope_downgrade_warning = (
+            f"\nwarning: {entry_key(repo, issue)} was scope=fleet — this add did not "
+            f"repeat --scope {HOLD_SCOPE_FLEET}, so its gate is now scope={hold_scope} "
+            "(entries-only). Pass --scope fleet again if the fleet-wide stop was still needed."
+        )
+
     enqueue_drive_queue(
         repo,
         issue,
@@ -192,37 +230,51 @@ def drive_queue_add(
         hold_after=hold_after,
         hold_reason=hold_reason,
         resume_when=resume_when,
+        hold_scope=hold_scope,
     )
     suffix = f" after {', '.join(after)}" if after else ""
     pinned = f" on {machine}" if machine else ""
     gate = ""
     if hold_after:
         gate = " · holds the queue when done"
+        if hold_scope == HOLD_SCOPE_FLEET:
+            gate += " (fleet-wide — nothing anywhere launches)"
         if resume_when:
             gate += f" (auto-resume when `{resume_when}` passes)"
-    click.echo(f"queued {entry_key(repo, issue)}{pinned}{suffix}{gate}")
+    click.echo(f"queued {entry_key(repo, issue)}{pinned}{suffix}{gate}{scope_downgrade_warning}")
 
 
-def validate_hold_flags(hold_after: bool, hold_reason: str, resume_when: str) -> None:
-    """Refuse gate detail without a gate (#1757).
-
-    `--resume-when` / `--hold-reason` on an entry with no `--hold-after` would
-    be stored and then never read — a silent no-op on the ONE flag whose whole
-    job is to stop the queue.  An operator who mistyped that has no signal at
-    all that overnight sequencing will now blow straight through the deploy
-    step, so this is a usage error, not a warning.
+def validate_hold_flags(
+    hold_after: bool,
+    hold_reason: str,
+    resume_when: str,
+    hold_scope: str = HOLD_SCOPE_ENTRY,
+) -> None:
+    """Refuse gate detail without a gate (#1757, extended by #2186).
+
+    `--resume-when` / `--hold-reason` / a non-default `--scope` on an entry
+    with no `--hold-after` would be stored and then never read — a silent
+    no-op on the ONE flag whose whole job is to stop the queue (or narrow
+    what it stops).  An operator who mistyped that has no signal at all that
+    overnight sequencing will now blow straight through the deploy step, so
+    this is a usage error, not a warning.
     """
     if hold_after:
         return
     offenders = [
         flag
-        for flag, value in (("--resume-when", resume_when), ("--hold-reason", hold_reason))
+        for flag, value in (
+            ("--resume-when", resume_when),
+            ("--hold-reason", hold_reason),
+        )
         if value
     ]
+    if hold_scope == HOLD_SCOPE_FLEET:
+        offenders.append("--scope=fleet")
     if offenders:
         raise QueueError(
             f"{' and '.join(offenders)} require --hold-after "
-            "(without it there is no gate to resume or explain)"
+            "(without it there is no gate to resume, explain, or scope)"
         )
 
 
@@ -277,6 +329,8 @@ def drive_queue_list(repo: str | None, output_json: bool, config_path: Path) ->
             bits.append(f"deferrals={entry.deferrals}")
         if entry.hold_after:
             bits.append(f"hold={entry.hold_state or 'armed'}")
+            if entry.hold_scope == HOLD_SCOPE_FLEET:
+                bits.append("scope=fleet")
         click.echo("  ".join(bits))
         if entry.last_reason:
             click.echo(f"      last{_reason_age_suffix(entry, now)}: {entry.last_reason}")
@@ -325,7 +379,12 @@ def _hold_lines(entry: QueueEntry) -> list[str]:
     """
     if not entry.hold_after:
         return []
-    lines = [f"      hold-after: {entry.gate_reason}"]
+    scope_suffix = (
+        " [fleet-wide — holds everything, not just this entry's dependents]"
+        if entry.hold_scope == HOLD_SCOPE_FLEET
+        else ""
+    )
+    lines = [f"      hold-after: {entry.gate_reason}{scope_suffix}"]
     if entry.resume_when:
         probe = f"      resume-when: {entry.resume_when}"
         if entry.hold_probes:
@@ -416,6 +475,10 @@ def drive_queue_status(output_json: bool, config_path: Path) -> None:
                             "reason": e.gate_reason,
                             "resume_when": e.resume_when,
                             "probes": e.hold_probes,
+                            # #2186: typed, so a client reads what this gate
+                            # holds without parsing the `[fleet-wide ...]`
+                            # suffix back out of the rendered text.
+                            "scope": e.hold_scope,
                         }
                         for e in held
                     ],

{code_coordinator-0.5.62 → code_coordinator-0.5.64}/coord/db.py

@@ -401,6 +401,13 @@ def _ensure_schema(conn: sqlite3.Connection) -> None:
             hold_state    TEXT    NOT NULL DEFAULT '',
             hold_probes   INTEGER NOT NULL DEFAULT 0,
             launch_host   TEXT    NOT NULL DEFAULT '',
+            -- #2186: how far a FIRED gate reaches. 'entry' (the default) holds
+            -- only entries whose own after_json names this row's key; 'fleet'
+            -- is the pre-#2186 whole-queue stop, kept for an explicit
+            -- --scope=fleet. NOT NULL DEFAULT 'entry' so a row written before
+            -- this column existed reads as the narrower scope, never a silent
+            -- fleet-wide one — see coord.drive_queue.QueueEntry.hold_scope.
+            hold_scope    TEXT    NOT NULL DEFAULT 'entry',
             UNIQUE(repo_name, issue_number)
         );
 
@@ -717,6 +724,13 @@ def _migrate_add_columns(conn: sqlite3.Connection) -> None:
         # carries its age instead of rendering a stale snapshot as current
         # state. NULL for every row predating this migration.
         "ALTER TABLE drive_queue ADD COLUMN reason_at REAL",
+        # #2186: deploy-gate SCOPE — see the CREATE TABLE comment above and
+        # coord/drive_queue.py's HOLD_SCOPE_ENTRY/HOLD_SCOPE_FLEET. Every row
+        # predating this migration (and every armed-but-not-yet-fired gate)
+        # defaults to 'entry', the narrower reading — a fired gate on such a
+        # row holds only its own dependents rather than the whole queue, which
+        # is the #2186 fix itself, not just a schema detail.
+        "ALTER TABLE drive_queue ADD COLUMN hold_scope TEXT NOT NULL DEFAULT 'entry'",
     ]
     for sql in migrations:
         try: