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

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

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

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

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

{code_coordinator-0.5.323 → code_coordinator-0.5.324}/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.324}/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.324}/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")

{code_coordinator-0.5.323 → code_coordinator-0.5.324}/coord/portal_store.py

@@ -1749,6 +1749,13 @@ def list_milestone_links() -> list[PortalLink]:
     return [link for link in links if link is not None]
 
 
+def _get_link_by_submission_local(submission_id: str) -> PortalLink | None:
+    for link in list_milestone_links():
+        if link.submission_id == submission_id:
+            return link
+    return None
+
+
 def get_link_by_submission(submission_id: str) -> PortalLink | None:
     """Reverse lookup: the link for a portal ``submission_id``, if any —
     whether it is scoped to a milestone or (#2665) a single issue.
@@ -1761,11 +1768,29 @@ def get_link_by_submission(submission_id: str) -> PortalLink | None:
     against. Links are few enough (one per submission a customer has ever
     been sent to) that a linear scan of :func:`list_milestone_links` is
     simply the read path — no new index, no new table.
+
+    Every caller until #2995 ran exclusively on the daemon (the tick loop's
+    own consumers, plus ``/portal-answer``'s status fold), so this read
+    stayed local-only. ``coord portal enqueue-status``'s #2996 "no link on
+    file" warning changed that: it is the one CLI-reachable call site, and
+    once ``enqueue-status`` itself started routing through the daemon on a
+    thin client (#2995), a local-only read here would silently check that
+    machine's own empty ``~/.coord/coord.db`` and warn every time, whether or
+    not a link actually exists. Routed through the daemon's
+    ``GET /portal-link-by-submission`` when ``board_service`` is configured,
+    same as :func:`get_portal_link`; fails soft to ``None`` on a routing
+    hiccup for the same reason that function does — "couldn't ask"
+    collapsing to "not linked" is the safe default for a warning-only read.
     """
-    for link in list_milestone_links():
-        if link.submission_id == submission_id:
-            return link
-    return None
+    from coord import board_service  # noqa: PLC0415
+
+    svc = board_service.resolve()
+    if svc is not None:
+        from coord.client import fetch_portal_link_by_submission  # noqa: PLC0415
+
+        raw = fetch_portal_link_by_submission(svc, submission_id)
+        return PortalLink.from_dict(raw) if raw is not None else None
+    return _get_link_by_submission_local(submission_id)
 
 
 # ── the running-context ledger (#2749, IL-3, epic #2746) ────────────────────

{code_coordinator-0.5.323 → code_coordinator-0.5.324}/coord/portal_sync.py

@@ -458,6 +458,52 @@ def enqueue_preview(
     )
 
 
+def _route_enqueue_question(payload: dict[str, Any]) -> dict[str, Any] | None:
+    """POST *payload* to the daemon's ``/portal-enqueue-question`` seam, or
+    ``None`` if this process IS the daemon host (#2995) — the enqueue-
+    question twin of :func:`coord.portal_store._route_decision`.
+
+    ``coord portal decompose-chat --interactive`` is dispatched to any
+    machine that claims a submission's mapped repo(s) (#2750), not just the
+    daemon host, and the Ask move — the one thin-client gap #2751/#2867/
+    #2986 left open — needs `enqueue-question` from exactly that machine.
+    """
+    from coord import board_service  # noqa: PLC0415
+
+    svc = board_service.resolve()
+    return board_service.route_write(svc, "/portal-enqueue-question", payload)
+
+
+def _enqueue_question_local(
+    submission_id: str,
+    question: str,
+    *,
+    config: Any = None,
+    now: float | None = None,
+) -> tuple[portal_store.OutboxRow, portal_store.OutboxRow]:
+    """The actual two-row write :func:`enqueue_question` performs — local to
+    whichever process runs it (the daemon itself, or this same process when
+    it IS the daemon host). Never call this directly for a routed write: the
+    #2995 atomicity guarantee (both rows applied in one request, so a thin
+    client can never observe the question without its announcement) depends
+    on it running inside `post_portal_enqueue_question`'s single request,
+    not as two separate calls from a thin client.
+    """
+    if not question or not question.strip():
+        raise PortalSyncError("question must be non-empty")
+    question_row = portal_store.enqueue(
+        submission_id,
+        KIND_QUESTION,
+        {"question": question},
+        state=initial_outbox_state(KIND_QUESTION, config=config),
+        now=now,
+    )
+    status_row = _enqueue_status_local(
+        submission_id, "needs-input", config=config, now=now
+    )
+    return question_row, status_row
+
+
 def enqueue_question(
     submission_id: str,
     question: str,
@@ -485,22 +531,41 @@ def enqueue_question(
     second question is plausibly real news, so re-announcing is intended,
     not churn to suppress.
 
+    Routed to the daemon's ``/portal-enqueue-question`` seam when
+    ``board_service`` is configured (#2995), else applied locally — see
+    :func:`_route_enqueue_question`. Routed as ONE request carrying both
+    rows: the alternative (this function separately routing the question
+    row, then separately routing the `enqueue_status` call below) would let
+    a thin client observe — or a crash leave behind — a question with no
+    status row behind it, exactly the #2901 mute-question failure this
+    function exists to prevent. `_enqueue_question_local` is what actually
+    runs on whichever side ends up doing the write.
+
     Returns ``(question_row, status_row)`` in that seq order.
     """
-    if not question or not question.strip():
-        raise PortalSyncError("question must be non-empty")
-    question_row = portal_store.enqueue(
-        submission_id,
-        KIND_QUESTION,
-        {"question": question},
-        state=initial_outbox_state(KIND_QUESTION, config=config),
-        now=now,
+    routed = _route_enqueue_question(
+        {"submission_id": submission_id, "question": question}
     )
-    status_row = enqueue_status(submission_id, "needs-input", config=config, now=now)
-    return question_row, status_row
+    if routed is not None:
+        return (
+            portal_store._outbox_from_row(routed["question_row"]),
+            portal_store._outbox_from_row(routed["status_row"]),
+        )
+    return _enqueue_question_local(submission_id, question, config=config, now=now)
 
 
-def enqueue_status(
+def _route_enqueue_status(payload: dict[str, Any]) -> dict[str, Any] | None:
+    """POST *payload* to the daemon's ``/portal-enqueue-status`` seam, or
+    ``None`` if this process IS the daemon host (#2995) — same shape and
+    same reason as :func:`_route_enqueue_question` right above.
+    """
+    from coord import board_service  # noqa: PLC0415
+
+    svc = board_service.resolve()
+    return board_service.route_write(svc, "/portal-enqueue-status", payload)
+
+
+def _enqueue_status_local(
     submission_id: str,
     status: str,
     *,
@@ -508,21 +573,17 @@ def enqueue_status(
     now: float | None = None,
     requires_kind: str | None = None,
 ) -> portal_store.OutboxRow:
-    """Queue an up-mapped customer status for *submission_id*.
-
-    Refuses, **at enqueue time**, an announcing status with nothing queued to
-    announce (see :data:`ANNOUNCING_STATUSES`). The drain enforces the same
-    rule again against *confirmed* state, so this early check is not the
-    safety property — it is the difference between a caller learning it has
-    the order wrong immediately, and a row sitting held in the queue while
-    someone wonders why the customer was never told.
-
-    *requires_kind*, when given, overrides :data:`ANNOUNCING_STATUSES`'s
-    default for *status* — needed because more than one kind can share the
-    same announcing status (#2987: `needs-input` announces either a
-    `question` or a relayed `answer`, and only the caller enqueueing THIS
-    row knows which). ``None`` (the default) keeps the existing
-    one-status-one-kind lookup every other caller relies on.
+    """The actual write :func:`enqueue_status` performs — local to whichever
+    process runs it. See that function's own docstring for the routing
+    contract; this is also what backs `_enqueue_question_local`'s own
+    `needs-input` row directly. `sync_submission_statuses` and
+    `enqueue_relayed_answer` do **not** call this directly — they call the
+    public, routing-aware `enqueue_status()` like any other caller. That
+    routing is a no-op for them in practice (the daemon process itself has
+    no `board_service` configured, so `_route_enqueue_status` always returns
+    `None` there and every call falls through to this same local write) but
+    it means this function does not, by itself, "back" those two callers —
+    `enqueue_status()` does.
     """
     if status not in SUBMISSION_STATUSES:
         raise PortalSyncError(
@@ -556,6 +617,51 @@ def enqueue_status(
     )
 
 
+def enqueue_status(
+    submission_id: str,
+    status: str,
+    *,
+    config: Any = None,
+    now: float | None = None,
+    requires_kind: str | None = None,
+) -> portal_store.OutboxRow:
+    """Queue an up-mapped customer status for *submission_id*.
+
+    Refuses, **at enqueue time**, an announcing status with nothing queued to
+    announce (see :data:`ANNOUNCING_STATUSES`). The drain enforces the same
+    rule again against *confirmed* state, so this early check is not the
+    safety property — it is the difference between a caller learning it has
+    the order wrong immediately, and a row sitting held in the queue while
+    someone wonders why the customer was never told.
+
+    *requires_kind*, when given, overrides :data:`ANNOUNCING_STATUSES`'s
+    default for *status* — needed because more than one kind can share the
+    same announcing status (#2987: `needs-input` announces either a
+    `question` or a relayed `answer`, and only the caller enqueueing THIS
+    row knows which). ``None`` (the default) keeps the existing
+    one-status-one-kind lookup every other caller relies on.
+
+    Routed to the daemon's ``/portal-enqueue-status`` seam when
+    ``board_service`` is configured (#2995), else applied locally by
+    :func:`_enqueue_status_local` — the ``enqueue-status`` half of the same
+    gap :func:`enqueue_question` closes: an attended `decompose-chat
+    --interactive` session's Ask-shaped exit needs this from any machine
+    that claims the submission's repo(s), not just the daemon host.
+    """
+    routed = _route_enqueue_status(
+        {
+            "submission_id": submission_id,
+            "status": status,
+            "requires_kind": requires_kind,
+        }
+    )
+    if routed is not None:
+        return portal_store._outbox_from_row(routed["row"])
+    return _enqueue_status_local(
+        submission_id, status, config=config, now=now, requires_kind=requires_kind
+    )
+
+
 def _iso_date(recorded_at: float) -> str:
     """``recorded_at`` (a wall-clock epoch stamp) as a bare ``YYYY-MM-DD``,
     UTC — the "date" half of the relayed-answer wire shape (#2987,