code-coordinator 0.5.323__tar.gz → 0.5.325__tar.gz

{code_coordinator-0.5.323 → code_coordinator-0.5.325}/PKG-INFO

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

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

@@ -1,7 +1,7 @@
 {
-  "tag": "0.5.323",
+  "tag": "0.5.325",
   "distance": 0,
-  "node": "g6d62d0b99d361f200c0329792182a2f8918b2864",
+  "node": "ge5cc30ddda55f8f402bf6ce19c05a479a58ec944",
   "dirty": false,
   "branch": "HEAD",
   "node_date": "2026-08-31"

{code_coordinator-0.5.323 → code_coordinator-0.5.325}/coord/agent.py

@@ -4178,9 +4178,10 @@ never this session's own.
 - Do NOT run `git push`, `git commit`, or any command that writes to a repo \
 checkout — this session files issues and queues work, it does not touch code.
 - If an `enqueue-question`/`enqueue-status`/`decision` command refuses with \
-a thin-client error (this machine isn't the daemon host and isn't routed \
-yet — #2751), say so explicitly to the operator rather than silently \
-dropping the Ask/Propose; do not retry it as some other command.
+a thin-client error (this machine does not claim every repo the submission \
+maps to — #2995/#2751; it should not happen, since you were only dispatched \
+here because it does), say so explicitly to the operator rather than \
+silently dropping the Ask/Propose; do not retry it as some other command.
 - Keep the operator informed: summarize your plan before writing anything, \
 and report back what you asked/proposed/filed/queued/linked (and any gap) \
 when done.\

{code_coordinator-0.5.323 → code_coordinator-0.5.325}/coord/ci_fix.py

@@ -50,6 +50,18 @@ _log = logging.getLogger(__name__)
 # same exhausted budget the way an unbounded conflict-fix retry would.
 MAX_CI_FIX_DISPATCHES = 2
 
+# #3011: a ci-fix leg that finishes with the branch HEAD unchanged (see
+# `dispatch_was_noop`) is refunded and does NOT count toward
+# MAX_CI_FIX_DISPATCHES above — but that refund must itself be bounded, or
+# two workers that keep (correctly) declining could cycle forever without
+# ever reaching a verdict. Same magnitude as MAX_CI_FIX_DISPATCHES for the
+# same "a couple of genuine signals is enough" reasoning: once this many
+# CONSECUTIVE legs come back having pushed nothing, that itself is the
+# verdict — the failure is not attributable to this branch — and
+# `coord.commands.merge._dispatch_ci_fixes` escalates to HUMAN_REQUIRED
+# with a reason that says so, distinct from the generic retry-cap message.
+MAX_CI_FIX_NOOP_STREAK = 2
+
 # Prefix on the dispatched fix worker's issue_title — mirrors
 # `conflict_fix.SEMANTIC_FIX_TITLE_PREFIX`'s visibility purpose: the TUI
 # Pipeline row and the fix briefing itself both make it obvious WHY this
@@ -123,6 +135,47 @@ def _has_active_fix(board: Board, entry: QueuedMerge) -> bool:
     return False
 
 
+def dispatch_was_noop(entry: QueuedMerge) -> bool:
+    """True when the LAST ci-fix dispatch for *entry* completed with the
+    branch HEAD unchanged — the worker correctly concluded the CI failure
+    wasn't its to fix and pushed no commit, rather than genuinely attempting
+    a fix. Compares the live, per-tick-refreshed ``entry.branch_head_sha``
+    (see ``coord.merge_queue.process``'s freshness-anchor refresh, which
+    runs before a ``checks_failed`` event is ever emitted) against
+    ``entry.ci_fix_head_sha``, the sha :func:`dispatch_ci_fix` snapshotted
+    at the moment of that dispatch.
+
+    Both empty (no ci-fix ever dispatched for this streak, or a probe
+    failure left the current SHA unknown) reads as ``False`` — fails
+    closed, same as every other SHA-staleness check in this codebase
+    (#821): "we can't tell" must never be treated as "we can tell it
+    didn't move".
+    """
+    return (
+        bool(entry.ci_fix_head_sha)
+        and bool(entry.branch_head_sha)
+        and entry.ci_fix_head_sha == entry.branch_head_sha
+    )
+
+
+def refund_noop_ci_fix(entry: QueuedMerge) -> None:
+    """Undo the attempt :func:`dispatch_ci_fix` speculatively spent for a
+    leg that turned out to be a no-op (:func:`dispatch_was_noop` is
+    ``True``), and track the no-op streak separately so it cannot cycle
+    forever without ever reaching a verdict — see
+    :data:`MAX_CI_FIX_NOOP_STREAK`.
+
+    Called by ``coord.commands.merge._dispatch_ci_fixes`` BEFORE it decides
+    whether to dispatch again for this entry's event; the caller is
+    responsible for checking ``entry.ci_fix_noop_streak`` against the cap
+    afterwards and escalating/persisting as needed, same division of
+    responsibility as :func:`dispatch_ci_fix` itself.
+    """
+    entry.ci_fix_dispatches = max(0, entry.ci_fix_dispatches - 1)
+    entry.ci_fix_noop_streak += 1
+    entry.ci_fix_head_sha = ""
+
+
 def dispatch_ci_fix(
     entry: QueuedMerge,
     board: Board,
@@ -146,6 +199,14 @@ def dispatch_ci_fix(
     only a successful dispatch spends the budget, mirroring how
     ``ci_infra_reruns``/``ci_flaky_reruns`` are only bumped when their
     respective remedy actually fired.
+
+    #3011: a successful dispatch also snapshots ``entry.branch_head_sha``
+    into ``entry.ci_fix_head_sha`` so a later tick can tell whether this
+    leg actually moved the branch — see ``dispatch_was_noop``/
+    ``refund_noop_ci_fix``. Callers are expected to check
+    ``dispatch_was_noop(entry)`` and route through ``refund_noop_ci_fix``
+    BEFORE calling this function again for the same entry, so a worker
+    that pushed nothing doesn't silently spend a second real attempt.
     """
     if entry.ci_fix_dispatches >= MAX_CI_FIX_DISPATCHES:
         return None
@@ -181,6 +242,29 @@ def dispatch_ci_fix(
     # purpose as conflict_fix's SEMANTIC_FIX_TITLE_PREFIX.
     fix.issue_title = f"{CI_FIX_TITLE_PREFIX} {work.issue_title}"
 
+    # #3011: if a PRIOR dispatch's snapshot is still on the entry and the
+    # branch has since moved past it, that prior leg was a genuine attempt
+    # (not a no-op) — clear any no-op streak it may have left behind so it
+    # doesn't linger into this fresh attempt. (When the branch has NOT
+    # moved, the caller — `coord.commands.merge._dispatch_ci_fixes` — is
+    # expected to have already routed through `dispatch_was_noop`/
+    # `refund_noop_ci_fix` instead of reaching here; this is a harmless
+    # no-op in that case too, since `entry.ci_fix_noop_streak` would already
+    # be 0 for a caller that follows the intended sequencing.)
+    if (
+        entry.ci_fix_head_sha
+        and entry.branch_head_sha
+        and entry.ci_fix_head_sha != entry.branch_head_sha
+    ):
+        entry.ci_fix_noop_streak = 0
+
+    # Snapshot the current branch HEAD so a later tick can tell whether
+    # THIS dispatch's leg actually moved the branch (see
+    # `dispatch_was_noop`). `branch_head_sha` may itself be None (a probe
+    # failure) — falls back to "" so an unknown SHA never spuriously reads
+    # as "no ci-fix dispatch pending" on the next comparison.
+    entry.ci_fix_head_sha = entry.branch_head_sha or ""
+
     entry.ci_fix_dispatches += 1
 
     from coord.audit import record_audit  # noqa: PLC0415

{code_coordinator-0.5.323 → code_coordinator-0.5.325}/coord/client.py

@@ -835,6 +835,36 @@ def fetch_portal_link(
     return link if isinstance(link, dict) else None
 
 
+def fetch_portal_link_by_submission(
+    svc: ServiceConfig, submission_id: str, *, timeout: float = _DEFAULT_TIMEOUT
+) -> dict | None:
+    """GET the portal link for *submission_id* by reverse lookup (#2995) —
+    the submission-keyed counterpart to :func:`fetch_portal_link`'s
+    ``(repo_name, milestone_number/issue_number)``-keyed one.
+
+    Backs :func:`coord.portal_store.get_link_by_submission` on a thin
+    client — needed once ``coord portal enqueue-status``'s #2996 "no link on
+    file" warning became reachable from one. Fail-soft to ``None`` on any
+    transport/HTTP/decode error, same reasoning as :func:`fetch_portal_link`:
+    a daemon hiccup degrades to the same "not linked" a genuinely unlinked
+    submission would show, rather than a traceback, for a read that only
+    ever gates a warning.
+    """
+    try:
+        resp = httpx.get(
+            f"{svc.url}/portal-link-by-submission",
+            params={"submission_id": submission_id},
+            headers=_headers(svc),
+            timeout=timeout,
+        )
+        resp.raise_for_status()
+        data = resp.json()
+    except (httpx.HTTPError, ValueError):
+        return None
+    link = data.get("link") if isinstance(data, dict) else None
+    return link if isinstance(link, dict) else None
+
+
 def fetch_portal_ledger(
     svc: ServiceConfig, submission_id: str, *, timeout: float = _DEFAULT_TIMEOUT
 ) -> dict:

{code_coordinator-0.5.323 → code_coordinator-0.5.325}/coord/commands/merge.py

@@ -569,13 +569,43 @@ def _dispatch_ci_fixes(events, config, *, dry_run: bool) -> None:
     is never reprocessed by a later ``process()`` call (it only acts on
     ``PENDING`` entries) so whichever caller sees the event first must also
     be the one to act on it.
+
+    #3011: before dispatching again, checks whether the entry's LAST ci-fix
+    leg was a no-op — the branch HEAD is unchanged from
+    ``entry.ci_fix_head_sha``, the snapshot ``dispatch_ci_fix`` took when it
+    dispatched that leg. A no-op means a fresh worker looked at this
+    failure and pushed no commit — evidence the failure isn't attributable
+    to this branch, not evidence a fix attempt failed — so it is refunded
+    (``coord.ci_fix.refund_noop_ci_fix``) rather than counted toward
+    ``MAX_CI_FIX_DISPATCHES``. Consecutive no-ops are bounded separately by
+    ``MAX_CI_FIX_NOOP_STREAK``, escalating to ``HUMAN_REQUIRED`` with a
+    distinct reason once THAT cap is hit — the goal being that a human is
+    called in because a worker genuinely tried and failed, or because the
+    failure is provably not this branch's, never because two correct
+    declines were miscounted as two failed attempts.
+
+    Before trusting ``dispatch_was_noop`` at all, first checks ``coord.
+    ci_fix._has_active_fix`` — the SHA comparison alone cannot distinguish
+    "the fix worker finished and declined to push" from "the fix worker is
+    still running and just hasn't pushed yet" (a dispatched leg stays
+    PENDING for its whole lifetime, so the very next tick after dispatch
+    would otherwise read as a noop). While a fix is still active, the entry
+    is left untouched — no refund, no streak bump, no new dispatch — for
+    the next tick to re-check.
     """
     ci_events = [ev for ev in events if ev.kind == "checks_failed"]
     if not ci_events or dry_run:
         return
 
     from coord.audit import record_audit  # noqa: PLC0415
-    from coord.ci_fix import MAX_CI_FIX_DISPATCHES, dispatch_ci_fix  # noqa: PLC0415
+    from coord.ci_fix import (  # noqa: PLC0415
+        MAX_CI_FIX_DISPATCHES,
+        MAX_CI_FIX_NOOP_STREAK,
+        _has_active_fix,
+        dispatch_ci_fix,
+        dispatch_was_noop,
+        refund_noop_ci_fix,
+    )
     from coord.merge_queue import HUMAN_REQUIRED  # noqa: PLC0415
     from coord.state import load_board, save_board  # noqa: PLC0415
 
@@ -585,6 +615,83 @@ def _dispatch_ci_fixes(events, config, *, dry_run: bool) -> None:
     dispatched_any = False
     for ev in ci_events:
         entry = ev.entry
+        # #3011 follow-up: `dispatch_was_noop` only compares the SHA
+        # snapshotted at dispatch time against the current branch head — it
+        # cannot tell "the fix worker finished and declined to push" apart
+        # from "the fix worker is still running and just hasn't pushed yet".
+        # A dispatched leg stays PENDING for its whole lifetime (`process()`
+        # never mutates entry.state for this path), so on the very next tick
+        # after dispatch the SHA still matches and `dispatch_was_noop` would
+        # read `True` for a leg that hasn't even had a chance to push.
+        # `_has_active_fix` is the same in-flight guard `dispatch_ci_fix`
+        # itself checks before dispatching — treat "still running" as "still
+        # pending" here too: skip the noop/refund accounting entirely and
+        # leave the entry untouched for the next tick, exactly like the
+        # generic "already in flight" decline below.
+        if _has_active_fix(fix_board, entry):
+            click.echo(
+                f"  {entry.repo_name} #{entry.issue_number}: "
+                "ci-fix already in flight — will re-check next run"
+            )
+            continue
+        if dispatch_was_noop(entry):
+            refund_noop_ci_fix(entry)
+            dispatched_any = True
+            if entry.ci_fix_noop_streak >= MAX_CI_FIX_NOOP_STREAK:
+                entry.state = HUMAN_REQUIRED
+                click.echo(
+                    f"  {entry.repo_name} #{entry.issue_number}: "
+                    f"{entry.ci_fix_noop_streak} consecutive ci-fix workers "
+                    "pushed no commit — not attributable to this branch, "
+                    "manual resolution required"
+                )
+                record_audit(
+                    tier="operational",
+                    category="merge",
+                    event_type="ci_fix_not_attributable",
+                    actor="daemon",
+                    summary=(
+                        f"ci-fix not attributable to branch: "
+                        f"{entry.repo_name}#{entry.issue_number} — "
+                        f"{entry.ci_fix_noop_streak} consecutive fix "
+                        "workers pushed no commit; manual resolution "
+                        "required"
+                    ),
+                    repo=entry.repo_name,
+                    issue=entry.issue_number,
+                    assignment_id=entry.assignment_id,
+                    details={
+                        "reason": "ci_fix_noop_streak",
+                        "ci_fix_noop_streak": entry.ci_fix_noop_streak,
+                        "error": entry.error,
+                    },
+                )
+            else:
+                click.echo(
+                    f"  {entry.repo_name} #{entry.issue_number}: "
+                    "ci-fix leg pushed no commit — refunding attempt "
+                    f"({entry.ci_fix_dispatches}/{MAX_CI_FIX_DISPATCHES} "
+                    "real attempts spent), will retry next run"
+                )
+                record_audit(
+                    tier="operational",
+                    category="merge",
+                    event_type="ci_fix_noop_refunded",
+                    actor="daemon",
+                    summary=(
+                        f"ci-fix leg was a no-op (branch head unchanged): "
+                        f"{entry.repo_name}#{entry.issue_number} — attempt "
+                        "refunded, not counted toward the retry cap"
+                    ),
+                    repo=entry.repo_name,
+                    issue=entry.issue_number,
+                    assignment_id=entry.assignment_id,
+                    details={
+                        "ci_fix_dispatches": entry.ci_fix_dispatches,
+                        "ci_fix_noop_streak": entry.ci_fix_noop_streak,
+                    },
+                )
+            continue
         fix = dispatch_ci_fix(entry, fix_board, config, checks_summary=ev.message)
         if fix is not None:
             click.echo(

{code_coordinator-0.5.323 → code_coordinator-0.5.325}/coord/commands/portal.py

@@ -64,6 +64,23 @@ exactly like an inbound ``question.answered`` event does, flags it relayed
 so it never reads as the client's own words, and folds the submission off
 ``needs-input``. Same daemon-routed shape (``POST /portal-note`` /
 ``POST /portal-answer``) and the same reason.
+
+**``enqueue-question`` and ``enqueue-status`` are the last two, and the odd
+ones out (#2995).** Every exception above routes unconditionally — any
+machine in the fleet may be where the operator is typing. These two widen
+the routed set instead of dropping the guard: ``coord portal decompose-chat
+--interactive`` is dispatched only to a machine that claims the
+submission's mapped repo(s) (#2750), and the Ask move — the one exit that
+session could not take from a thin client, the gap this issue closes — is
+exactly what these two commands queue. So they route through the daemon
+(``POST /portal-enqueue-question`` / ``POST /portal-enqueue-status``) only
+when :func:`_refuse_unless_claiming_machine` confirms the calling machine
+claims every mapped repo; a non-claiming thin client still refuses, same as
+every command at the top of this file. ``enqueue-question`` queues two rows
+(the question and its ``needs-input`` announcement, #2901) — the daemon
+applies both in the ONE request, so a partial application can never leave a
+question with no status row behind it (the mute-question failure #2901
+exists to prevent).
 """
 
 from __future__ import annotations
@@ -98,10 +115,11 @@ def _actor() -> str:
 def _refuse_if_thin_client(cmd_name: str) -> None:
     """Refuse *cmd_name* when this machine isn't the daemon host (#2336).
 
-    ``sync``/``outbox``/``events``/``enqueue-*``/``requeue`` read and write
-    the daemon's own ``~/.coord/coord.db`` directly — there is no daemon
-    proxy for portal state yet (unlike ``coord status``/``coord log``/etc,
-    which already route through ``board_service`` when it's configured; see
+    ``sync``/``outbox``/``events``/``enqueue-design-round``/
+    ``enqueue-preview``/``requeue`` read and write the daemon's own
+    ``~/.coord/coord.db`` directly — there is no daemon proxy for portal
+    state yet (unlike ``coord status``/``coord log``/etc, which already
+    route through ``board_service`` when it's configured; see
     ``coord/client.py``'s module docstring for the bootstrap contract). Run
     on a machine that has ``board_service`` set in ``~/.coord/client.toml``
     (a thin client, by definition — every other machine in the fleet that
@@ -111,6 +129,10 @@ def _refuse_if_thin_client(cmd_name: str) -> None:
     unnoticed on the daemon host for over an hour because every portal
     command run from a thin client reported nothing pending).
 
+    ``enqueue-question``/``enqueue-status`` used to be in that list too —
+    see :func:`_refuse_unless_claiming_machine` below (#2995) for why they
+    no longer call this at all.
+
     Mirrors the guard already used for the same reason in
     ``coord.commands.drive_queue``'s ``diagnose`` command (#615/#906), which
     refuses rather than "diagnose an empty queue" on a thin client. The
@@ -137,6 +159,101 @@ def _refuse_if_thin_client(cmd_name: str) -> None:
     )
 
 
+def _missing_claimed_repos(machine, repos: list[str]) -> list[str]:
+    """Repos in REPOS that MACHINE does not claim — the "does this machine
+    claim every repo this submission maps to" predicate, in exactly one
+    place (#2995 review, #2085/#2096 "one question, one answer").
+
+    ``machine is None`` (this box isn't a configured machine in
+    ``coordinator.yml`` at all) counts every repo as unclaimed — an
+    unconfigured machine claims nothing. Shared by
+    :func:`_refuse_unless_claiming_machine` (above) and
+    ``_run_decompose_chat_interactive`` (further down this module): both
+    ask this exact question before letting a thin/local client touch a
+    submission's mapped repo(s), and before this helper existed they asked
+    it with two independently-written comprehensions that happened to agree
+    only because they were written together in the same commit — nothing
+    kept them in sync if either changed later. Callers keep their own
+    branching for the ``machine is None`` case where they want a distinct
+    message/exit path (``_run_decompose_chat_interactive`` does); this only
+    answers "which repos are missing," never how to report it.
+    """
+    if machine is None:
+        return list(repos)
+    return [r for r in repos if not machine.can_work_on(r)]
+
+
+def _refuse_unless_claiming_machine(cfg, submission_id: str, cmd_name: str) -> None:
+    """Refuse *cmd_name* on a thin client that does not claim every repo
+    SUBMISSION_ID maps to (#2995). A no-op on the daemon host itself.
+
+    ``enqueue-question``/``enqueue-status`` are the Ask move's exit — the
+    one thing `coord portal decompose-chat --interactive` could not do from
+    a thin client that claims the submission's repo(s), even though that
+    session is explicitly allowed to run there (#2750). Unlike ``note``/
+    ``decision``/``link``/``answer`` (#2751/#2867/#2986), which route
+    unconditionally — any machine in the fleet may be where the operator is
+    typing — this widens the refused set rather than dropping it: a
+    ``type="decomposition-chat"`` session is never dispatched to a machine
+    that doesn't claim the submission's repo(s) in the first place
+    (:func:`coord.decomposition_chat.pick_decomposition_chat_machine`), so a
+    caller invoking these commands directly from one that *doesn't* claim
+    them is either a mistake or a machine that has no business writing
+    against this submission's outbox — that machine still refuses, exactly
+    like every other state-touching command in this file.
+
+    Repos are resolved the same thin-client-safe way
+    ``_run_decompose_chat_interactive`` already does before ever launching a
+    session (see that function, further down in this module), and for the
+    identical reason:
+    :func:`coord.decomposition_chat.resolve_approved_submission`, itself
+    routed through the daemon's ``GET /board``. A submission that isn't
+    currently a recorded ``approved`` sign-off — the only shape that
+    projection carries — cannot be claim-checked from here at all, and this
+    refuses rather than guess at a repo list it cannot verify.
+    """
+    from coord.board_service import resolve  # noqa: PLC0415
+
+    svc = resolve()
+    if svc is None:
+        return
+    from urllib.parse import urlparse  # noqa: PLC0415
+
+    from coord.decomposition_chat import resolve_approved_submission  # noqa: PLC0415
+    from coord.test_orchestrator import local_machine  # noqa: PLC0415
+
+    host = urlparse(svc.url).hostname or svc.url
+    submission = resolve_approved_submission(cfg, submission_id)
+    if submission is None:
+        raise click.ClickException(
+            f"coord portal {cmd_name} refuses: submission {submission_id!r} is "
+            "not a currently-approved portal submission, so its mapped "
+            "repo(s) cannot be resolved from this thin client to verify a "
+            "claim. Run it over `ssh` on the daemon host "
+            f"({host}) instead. See coord/skills/portal-followup/SKILL.md."
+        )
+    repos: list[str] = submission.get("repos") or []
+    machine = local_machine(cfg)
+    missing = _missing_claimed_repos(machine, repos)
+    if not repos or missing:
+        reason = (
+            f"submission {submission_id!r} has no mapped repo (portal."
+            "project_repos in coordinator.yml)"
+            if not repos
+            else (
+                f"this machine ({machine.name if machine is not None else 'unconfigured'}) "
+                f"does not claim repo(s) {', '.join(missing)} that submission "
+                f"{submission_id!r} maps to ({', '.join(repos)})"
+            )
+        )
+        raise click.ClickException(
+            f"coord portal {cmd_name} refuses: {reason}. Run it over `ssh` on "
+            f"the daemon host ({host}) instead, or from a machine that claims "
+            "every repo the submission maps to. See "
+            "coord/skills/portal-followup/SKILL.md."
+        )
+
+
 @click.group("portal")
 def portal_group() -> None:
     """coord-portal sync bridge — status, manual push, heartbeat (#2179)."""
@@ -439,11 +556,11 @@ def portal_link(
         "headless dispatch. Local-only for now (Track B / #486 is remote): "
         "refuses when this machine does not claim every repo SUBMISSION_ID "
         "maps to. On a thin client (this machine has `board_service` "
-        "configured), `coord portal decision`/`ledger`/`link` route through "
-        "the daemon (#2751) but `enqueue-question`/`enqueue-status` do not "
-        "yet — an Ask-shaped iteration will refuse loudly mid-conversation "
-        "on those; ssh to the daemon host instead for that case. Mutually "
-        "exclusive with --wait/--machine/--timeout/--interval."
+        "configured), `coord portal decision`/`ledger`/`link`/`note`/"
+        "`answer` and (#2995) `enqueue-question`/`enqueue-status` — "
+        "including the Ask move — all route through the daemon, so every "
+        "exit an iteration can take works from here. Mutually exclusive "
+        "with --wait/--machine/--timeout/--interval."
     ),
 )
 @click.option(
@@ -657,7 +774,7 @@ def _run_decompose_chat_interactive(
             err=True,
         )
         raise SystemExit(2)
-    missing = [r for r in repos if not machine.can_work_on(r)]
+    missing = _missing_claimed_repos(machine, repos)
     if missing:
         click.echo(
             f"error: --interactive is local-only for now (Track B / #486 is "
@@ -669,19 +786,12 @@ def _run_decompose_chat_interactive(
         )
         raise SystemExit(2)
 
-    from coord import board_service as _board_service  # noqa: PLC0415
-
-    if _board_service.resolve() is not None:
-        click.secho(
-            "note: this machine is a thin client — `coord portal decision`/"
-            "`ledger`/`link`/`note` route through the daemon (#2751/#2867), "
-            "but `coord "
-            "portal enqueue-question`/`enqueue-status` (the Ask move) do "
-            "not yet and will refuse loudly if this iteration needs them. "
-            "ssh to the daemon host for that case (#2750's own stated "
-            "limit).",
-            fg="yellow",
-        )
+    # #2995: no thin-client caveat left to print here — `decision`/`ledger`/
+    # `link`/`note`/`answer` (#2751/#2867/#2986) and now `enqueue-question`/
+    # `enqueue-status` (the Ask move's exit) all route through the daemon
+    # from exactly this machine, which the claim check above just verified
+    # claims every repo SUBMISSION_ID maps to. A prior revision warned here
+    # that the Ask move would "refuse loudly" — no longer true.
 
     topology_context = repo_topology_context(cfg, repos)
     discuss_mode, discuss_reason = select_discuss_mode(cfg, submission, discuss_override=discuss)
@@ -1335,9 +1445,10 @@ def _echo_enqueued(row: "OutboxRow", label: str) -> None:
 
 
 @portal_group.command("enqueue-status")
+@_CONFIG_OPTION
 @click.argument("submission_id")
 @click.argument("status", type=click.Choice(SUBMISSION_STATUSES))
-def portal_enqueue_status(submission_id: str, status: str) -> None:
+def portal_enqueue_status(config_path, submission_id: str, status: str) -> None:
     """Queue an up-mapped status for SUBMISSION_ID (sent on the next sync).
 
     Unlike `push`, this allocates the revision for you and refuses a status
@@ -1359,8 +1470,15 @@ def portal_enqueue_status(submission_id: str, status: str) -> None:
     sends the push regardless — there are legitimate reasons to set any of
     these by hand (a correction, a re-sync, an out-of-band delivery) — it
     only makes the consequence visible first.
+
+    **#2995: routes through the daemon on a thin client that claims
+    SUBMISSION_ID's mapped repo(s)**, instead of refusing outright like
+    every other state-touching ``enqueue-*`` command — see
+    :func:`_refuse_unless_claiming_machine`. This is the ``enqueue-status``
+    half of the Ask move's exit; ``enqueue-question`` below is the other.
     """
-    _refuse_if_thin_client("enqueue-status")
+    cfg = _load_config(config_path)
+    _refuse_unless_claiming_machine(cfg, submission_id, "enqueue-status")
 
     from coord.approved_work import is_pulled_status  # noqa: PLC0415
     from coord.portal_sync import PortalSyncError, enqueue_status  # noqa: PLC0415
@@ -1385,9 +1503,19 @@ def portal_enqueue_status(submission_id: str, status: str) -> None:
                 fg="yellow",
             )
 
+    import httpx  # noqa: PLC0415
+
     try:
-        row = enqueue_status(submission_id, status)
-    except PortalSyncError as exc:
+        row = enqueue_status(submission_id, status, config=cfg)
+    except (PortalSyncError, httpx.HTTPStatusError) as exc:
+        # #2995 fix-round: routed through the daemon (see
+        # `_refuse_unless_claiming_machine` above), a rejection comes back
+        # as `httpx.HTTPStatusError` (`board_service.route_write` →
+        # `client.post_record`), not `PortalSyncError` — the daemon-host
+        # path's identical rejection (e.g. an announcing status with
+        # nothing queued) never reaches `post_record` at all. Without this,
+        # a thin-client caller saw a raw traceback where a daemon-host
+        # caller got this same clean red message.
         click.secho(str(exc), fg="red")
         raise SystemExit(1) from exc
     _echo_enqueued(row, f"status={status}")
@@ -1444,23 +1572,38 @@ def portal_enqueue_preview(submission_id: str, preview_url: str) -> None:
 
 
 @portal_group.command("enqueue-question")
+@_CONFIG_OPTION
 @click.argument("submission_id")
 @click.argument("question")
-def portal_enqueue_question(submission_id: str, question: str) -> None:
+def portal_enqueue_question(config_path, submission_id: str, question: str) -> None:
     """Queue an open question for SUBMISSION_ID (sent on the next sync).
 
     Also queues the `needs-input` status that announces it (#2901) — a
     question with no status row behind it sends no email, so this command
     always queues both rows in one call rather than leaving the second one
-    to a caller who might forget it.
+    to a caller who might forget it. When routed through the daemon (see
+    below), both rows are applied in that one request, so a crash or a
+    dropped response can never leave the question queued without its
+    announcement.
+
+    **#2995: routes through the daemon on a thin client that claims
+    SUBMISSION_ID's mapped repo(s)**, instead of refusing outright — see
+    :func:`_refuse_unless_claiming_machine`. This is the Ask move's other
+    half; ``enqueue-status`` above is the one a plain status push uses.
     """
-    _refuse_if_thin_client("enqueue-question")
+    cfg = _load_config(config_path)
+    _refuse_unless_claiming_machine(cfg, submission_id, "enqueue-question")
 
     from coord.portal_sync import PortalSyncError, enqueue_question  # noqa: PLC0415
 
+    import httpx  # noqa: PLC0415
+
     try:
-        question_row, status_row = enqueue_question(submission_id, question)
-    except PortalSyncError as exc:
+        question_row, status_row = enqueue_question(submission_id, question, config=cfg)
+    except (PortalSyncError, httpx.HTTPStatusError) as exc:
+        # #2995 fix-round: see the matching comment in `portal_enqueue_status`
+        # above — a routed rejection surfaces as `httpx.HTTPStatusError`, not
+        # `PortalSyncError`.
         click.secho(str(exc), fg="red")
         raise SystemExit(1) from exc
     _echo_enqueued(question_row, "question")