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

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

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

@@ -403,6 +403,7 @@ tests/test_approve_dependency_busy_2804.py
 tests/test_approve_reject_plan.py
 tests/test_approve_usage_gate.py
 tests/test_approved_work_2532.py
+tests/test_approved_work_2996.py
 tests/test_assignment_already_recorded_daemon.py
 tests/test_audit_log.py
 tests/test_audit_outcome.py

{code_coordinator-0.5.322 → code_coordinator-0.5.324}/code_coordinator.egg-info/scm_file_list.json

@@ -429,6 +429,7 @@
     "tests/test_approve_reject_plan.py",
     "tests/test_approve_usage_gate.py",
     "tests/test_approved_work_2532.py",
+    "tests/test_approved_work_2996.py",
     "tests/test_assignment_already_recorded_daemon.py",
     "tests/test_audit_log.py",
     "tests/test_audit_outcome.py",

{code_coordinator-0.5.322 → code_coordinator-0.5.324}/code_coordinator.egg-info/scm_version.json

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

{code_coordinator-0.5.322 → 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.322 → code_coordinator-0.5.324}/coord/approved_work.py

@@ -256,6 +256,47 @@ def approved_submission_ids() -> set[str]:
     return {sid for sid, verdict in _fold_signoff_verdicts().items() if verdict == "approved"}
 
 
+def is_pulled_status(status: str) -> bool:
+    """Whether *status* is one of :data:`_PULLED_STATUSES` — the public,
+    non-underscore way for another module (:mod:`coord.commands.portal`,
+    #2996) to ask "would pushing this status withdraw a submission from
+    :func:`approved_submissions`?" without reaching into this module's
+    private constant.
+    """
+    return status in _PULLED_STATUSES
+
+
+def disqualifying_status(submission_id: str) -> str | None:
+    """The ``last_status`` responsible for *submission_id* being missing
+    from :func:`approved_submissions` despite an ``approved`` sign-off
+    verdict on file — or ``None`` when that is not why it is missing (never
+    approved, no record at all, or genuinely not pulled) (#2996).
+
+    Reads local :mod:`coord.portal_store` directly, same as
+    :func:`approved_submissions` itself — so, like that function, this is
+    only meaningful when called on the daemon host (the caller is
+    responsible for that; see :func:`coord.commands.portal.
+    _refuse_if_thin_client` and :func:`coord.decomposition_chat.
+    resolve_approved_submission`'s own thin-client routing).
+
+    Exists so a "why isn't this on the queue" failure message
+    (:func:`coord.decomposition_chat.resolve_approved_submission`'s callers)
+    can name the actual cause — a status an operator pushed by hand, most
+    often via ``coord portal enqueue-status`` — instead of the generic
+    "is not a currently-approved portal submission", which names neither.
+    """
+    from coord import portal_store  # noqa: PLC0415 — avoid import cycle
+
+    record = portal_store.get_submission(submission_id)
+    if record is None:
+        return None
+    if record.submission_id not in approved_submission_ids():
+        return None
+    if record.last_status in _PULLED_STATUSES:
+        return record.last_status
+    return None
+
+
 def approved_submissions(config: "Config") -> list[dict[str, Any]]:
     """The ``/board`` ``approved_submissions`` payload, **oldest first**.
 

{code_coordinator-0.5.322 → 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.322 → 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(
@@ -612,6 +729,7 @@ def _run_decompose_chat_interactive(
     )
     from coord.decomposition_chat import (  # noqa: PLC0415
         build_decomposition_chat_briefing,
+        describe_unapproved_submission,
         fetch_running_context,
         render_running_context_section,
         repo_topology_context,
@@ -633,8 +751,7 @@ def _run_decompose_chat_interactive(
     submission = resolve_approved_submission(cfg, submission_id)
     if submission is None:
         click.secho(
-            f"error: submission {submission_id!r} is not a currently-approved "
-            "portal submission — nothing to decompose",
+            f"error: {describe_unapproved_submission(cfg, submission_id)}",
             fg="red",
         )
         raise SystemExit(1)
@@ -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,22 +1445,77 @@ 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
     that would summon the customer to an empty screen — `awaiting-signoff`
     with no design round queued, `needs-input` with no question (#835).
+
+    **#2996: warns, never refuses, before a `_PULLED_STATUSES` push that
+    would silently withdraw SUBMISSION_ID from decomposition.**
+    `coord.approved_work.approved_submissions` (the "Approved work items"
+    panel's data source) drops any submission whose `last_status` moves to
+    `planned` / `in-progress` / `quality-check` / `shipped` — those four
+    values are only ever supposed to mean "already pulled into a linked
+    milestone/issue and dispatch has begun". Pushing one of them here on a
+    submission with no `coord portal link` on file does that removal anyway,
+    with nothing to say so — the observed failure mode (#2996's own filing)
+    was a status pushed purely to update the customer-facing wording, which
+    happened to also empty the queue and only surfaced later as an unrelated
+    "not a currently-approved portal submission" error. This command still
+    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
 
+    if is_pulled_status(status):
+        from coord import portal_store  # noqa: PLC0415
+
+        if portal_store.get_link_by_submission(submission_id) is None:
+            click.secho(
+                f"warning: {submission_id} has no linked milestone/issue on "
+                "file (no `coord portal link` recorded) and no decomposition "
+                f"on record — pushing status={status!r} will still be sent, "
+                "but coord treats that status as \"already pulled into "
+                f"decomposition and delivery\": {submission_id} will vanish "
+                "from the TUI's Approved work items panel, and `coord portal "
+                "decompose-chat` will refuse it as no longer approved. If "
+                "the work has not actually been decomposed yet and you just "
+                "want an honest \"we know what's next\" status for the "
+                f"customer, use `coord portal enqueue-status {submission_id} "
+                "in-design` instead — it stays on the queue and announces "
+                "nobody.",
+                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}")
@@ -1407,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.322 → code_coordinator-0.5.324}/coord/decomposition_chat.py

@@ -38,6 +38,7 @@ posture every other dispatcher in this file already uses.
 from __future__ import annotations
 
 import datetime
+import logging
 import time
 import uuid
 from typing import TYPE_CHECKING, Any
@@ -46,6 +47,8 @@ if TYPE_CHECKING:  # pragma: no cover - typing only
     from coord.config import Config
     from coord.models import Machine
 
+_log = logging.getLogger(__name__)
+
 #: Sentinel `issue_title` this module writes onto the dispatched assignment
 #: — mirrors `dispatch_new_issue_chat`'s own `"(new issue draft)"` sentinel
 #: for a chat type with no real GitHub issue yet. The TUI's own bind path
@@ -546,6 +549,71 @@ def resolve_approved_submission(config: "Config", submission_id: str) -> dict[st
     )
 
 
+def describe_unapproved_submission(config: "Config", submission_id: str) -> str:
+    """Human-readable reason :func:`resolve_approved_submission` returned
+    ``None`` for *submission_id* (#2996).
+
+    Names the disqualifying ``last_status`` when that is actually why — most
+    often an operator's own ``coord portal enqueue-status`` push to a
+    :data:`coord.approved_work._PULLED_STATUSES` value on a submission that
+    had not, in fact, been decomposed yet — instead of the generic "is not a
+    currently-approved portal submission", which names neither the cause nor
+    the status that caused it (the whole complaint in #2996's issue body).
+
+    Best-effort: the disqualifying-status lookup
+    (:func:`coord.approved_work.disqualifying_status`) needs to read the
+    daemon's own local :mod:`coord.portal_store` directly, so it is skipped
+    (falling back to the plain generic message) when this machine is a thin
+    client — the same constraint :func:`resolve_approved_submission` itself
+    already works around by routing through the daemon's ``/board`` instead
+    of reading the wrong box's empty tables.
+
+    **This function must never raise.** It exists only to phrase a failure
+    its callers have already decided on — ``dispatch_decomposition_chat``
+    raises ``RuntimeError(describe_unapproved_submission(...))`` and
+    ``_run_decompose_chat_interactive`` prints it — so an exception escaping
+    the *enrichment* lookup would replace a clear, actionable error with a
+    traceback about a completely different subsystem. The store read is
+    therefore best-effort: any failure (an unreadable/locked portal store, a
+    schema older than :func:`coord.approved_work.disqualifying_status`
+    expects, a thin client that slipped past the ``board_service`` check)
+    degrades to the plain generic message, which is exactly the pre-#2996
+    behaviour and still correct — just less specific.
+    """
+    base = f"submission {submission_id!r} is not a currently-approved portal submission"
+
+    reason: str | None = None
+    try:
+        from coord import board_service  # noqa: PLC0415
+
+        if board_service.resolve() is None:
+            from coord.approved_work import disqualifying_status  # noqa: PLC0415
+
+            reason = disqualifying_status(submission_id)
+    except Exception:  # noqa: BLE001 — best-effort enrichment, never break the message
+        _log.debug(
+            "describe_unapproved_submission: disqualifying-status lookup failed "
+            "for %s; falling back to the generic message",
+            submission_id,
+            exc_info=True,
+        )
+        reason = None
+
+    if reason:
+        return (
+            f"{base} — its last_status is {reason!r}, which coord already treats "
+            "as pulled into decomposition/delivery (coord.approved_work."
+            "_PULLED_STATUSES), so it no longer shows up in the TUI's Approved "
+            "work items panel and this command refuses it. If it was pushed to "
+            f"that status before decomposition actually happened, `coord portal "
+            f"enqueue-status {submission_id} in-design` puts it back on the "
+            "queue without re-mailing the customer. Nothing to decompose."
+        )
+    return (
+        f"{base} (coord.approved_work.approved_submissions) — nothing to decompose"
+    )
+
+
 def dispatch_decomposition_chat(
     submission_id: str,
     config: "Config",
@@ -576,10 +644,7 @@ def dispatch_decomposition_chat(
     """
     submission = resolve_approved_submission(config, submission_id)
     if submission is None:
-        raise RuntimeError(
-            f"submission {submission_id!r} is not a currently-approved portal "
-            "submission (coord.approved_work.approved_submissions) — nothing to decompose"
-        )
+        raise RuntimeError(describe_unapproved_submission(config, submission_id))
 
     repos: list[str] = submission.get("repos") or []
     if not repos:

{code_coordinator-0.5.322 → 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) ────────────────────