code-coordinator 0.5.280__tar.gz → 0.5.281__tar.gz

{code_coordinator-0.5.280 → code_coordinator-0.5.281}/PKG-INFO

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

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

@@ -1,7 +1,7 @@
 {
-  "tag": "0.5.280",
+  "tag": "0.5.281",
   "distance": 0,
-  "node": "g440329673aaafcfbce9c973d90c42a775bc081e0",
+  "node": "g62c2200a45c988353a9ede462609c649a368b11d",
   "dirty": false,
   "branch": "HEAD",
   "node_date": "2026-08-29"

{code_coordinator-0.5.280 → code_coordinator-0.5.281}/coord/agent.py

@@ -4067,7 +4067,11 @@ composer on the client's side pauses on the most recent question only, so \
 a scattershot list gets a partial answer at best. Then:
 
     coord portal enqueue-question <submission_id> "<question>"
-    coord portal enqueue-status <submission_id> needs-input
+
+   This one command queues the question AND announces it to the customer \
+(#2901) — `enqueue-question` queues its own `needs-input` status right \
+behind the question, so there is no separate announcement step to remember \
+or forget.
 
    and STOP — end your final turn summarizing the question and why, and run \
 nothing else this iteration (no filing, no decisions). IL-3's consumer \

{code_coordinator-0.5.280 → code_coordinator-0.5.281}/coord/commands/portal.py

@@ -1351,18 +1351,30 @@ def portal_enqueue_preview(submission_id: str, preview_url: str) -> None:
 @click.argument("submission_id")
 @click.argument("question")
 def portal_enqueue_question(submission_id: str, question: str) -> None:
-    """Queue an open question for SUBMISSION_ID (sent on the next sync)."""
+    """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.
+    """
     _refuse_if_thin_client("enqueue-question")
 
     from coord.portal_sync import PortalSyncError, enqueue_question  # noqa: PLC0415
 
     try:
-        row = enqueue_question(submission_id, question)
+        question_row, status_row = enqueue_question(submission_id, question)
     except PortalSyncError as exc:
         click.secho(str(exc), fg="red")
         raise SystemExit(1) from exc
     click.secho(
-        f"queued: {row.submission_id} seq={row.seq} rev={row.revision} question",
+        f"queued: {question_row.submission_id} seq={question_row.seq} "
+        f"rev={question_row.revision} question",
+        fg="green",
+    )
+    click.secho(
+        f"queued: {status_row.submission_id} seq={status_row.seq} "
+        f"rev={status_row.revision} status=needs-input",
         fg="green",
     )
 

{code_coordinator-0.5.280 → code_coordinator-0.5.281}/coord/portal_sync.py

@@ -356,13 +356,36 @@ def enqueue_preview(
 
 def enqueue_question(
     submission_id: str, question: str, *, now: float | None = None
-) -> portal_store.OutboxRow:
-    """Queue an open question for the customer."""
+) -> tuple[portal_store.OutboxRow, portal_store.OutboxRow]:
+    """Queue an open question for the customer, plus the announcement of it.
+
+    Queuing the question alone sends no email — the portal only mails the
+    customer off a push that actually names ``status``
+    (coord-portal's `src/bridge/updates.ts`) — so a caller that asked a
+    question and forgot the follow-up `enqueue_status(..., "needs-input")`
+    left the customer never told (#2901, SUB-1EA1D3: exactly this happened
+    to a real submission). Folding the announcement in here, in the same
+    call, immediately after the question row, makes that omission
+    impossible rather than merely documented: the existing
+    `ANNOUNCING_STATUSES`/`ordering_block_reason` guard then holds the
+    status row until this question is confirmed applied, for free, because
+    it is seq N+1 behind the question's seq N.
+
+    A second question on a submission already at `needs-input` still gets
+    its own status row here — coord-portal deliberately does not coalesce
+    a repeat `needs-input` (`src/notifications.ts`), on the grounds that a
+    second question is plausibly real news, so re-announcing is intended,
+    not churn to suppress.
+
+    Returns ``(question_row, status_row)`` in that seq order.
+    """
     if not question or not question.strip():
         raise PortalSyncError("question must be non-empty")
-    return portal_store.enqueue(
+    question_row = portal_store.enqueue(
         submission_id, KIND_QUESTION, {"question": question}, now=now
     )
+    status_row = enqueue_status(submission_id, "needs-input", now=now)
+    return question_row, status_row
 
 
 def enqueue_status(

{code_coordinator-0.5.280 → code_coordinator-0.5.281}/tests/test_decomposition_chat.py

@@ -689,10 +689,18 @@ def test_system_prompt_describes_both_modes():
     assert "MODE: FILE" in DECOMPOSITION_CHAT_SYSTEM_PROMPT
 
 
-def test_system_prompt_ask_terminal_move_uses_enqueue_commands():
+def test_system_prompt_ask_terminal_move_uses_enqueue_question_only():
+    """#2901: `enqueue_question` now queues its own `needs-input`
+    announcement, so the ASK move's own step list must not tell the session
+    to run a second `enqueue-status` command — that was the exact
+    forgettable two-step sequence #2901 folded away (SUB-1EA1D3)."""
     assert "coord portal enqueue-question" in DECOMPOSITION_CHAT_SYSTEM_PROMPT
-    assert "coord portal enqueue-status" in DECOMPOSITION_CHAT_SYSTEM_PROMPT
     assert "needs-input" in DECOMPOSITION_CHAT_SYSTEM_PROMPT
+    ask_section = DECOMPOSITION_CHAT_SYSTEM_PROMPT.split("1. ASK")[1].split(
+        "2. PROPOSE"
+    )[0]
+    assert "enqueue-status" not in ask_section
+    assert "queues its own" in ask_section
 
 
 def test_system_prompt_propose_terminal_move_uses_decision_commands():

{code_coordinator-0.5.280 → code_coordinator-0.5.281}/tests/test_portal_sync.py

@@ -21,6 +21,7 @@ from coord.portal_sync import (
     enqueue_preview,
     enqueue_question,
     enqueue_status,
+    ordering_block_reason,
     sync_tick,
 )
 
@@ -222,12 +223,12 @@ def test_reallocation_converges_and_then_the_announcement_goes():
 
 
 def test_second_question_cannot_ride_on_the_first_questions_confirmation():
+    # enqueue_question (#2901) queues its own needs-input status right
+    # behind the question — no separate enqueue_status call needed here.
     enqueue_question(SUB, "which colour?")
-    enqueue_status(SUB, "needs-input")
     sync_tick(client=FakeClient())  # round 1 lands cleanly
 
     enqueue_question(SUB, "which font?")
-    enqueue_status(SUB, "needs-input")
     # The second question fails to send; its announcement must not overtake it.
     client = FakeClient(push_error=PortalBridgeError("boom"))
     sync_tick(client=client)
@@ -238,6 +239,46 @@ def test_second_question_cannot_ride_on_the_first_questions_confirmation():
     assert client2.pushed_kinds == ["question", "status"]
 
 
+def test_enqueue_question_queues_its_own_announcement():
+    """#2901: a question pushed without a status row behind it sends no
+    email (coord-portal's own rule — a push only mails the customer when it
+    actually names ``status``). `enqueue_question` must queue that status
+    itself, in the same call, so the announcement cannot be forgotten."""
+    question_row, status_row = enqueue_question(SUB, "which colour?")
+
+    assert question_row.kind == portal_sync.KIND_QUESTION
+    assert status_row.kind == portal_sync.KIND_STATUS
+    assert status_row.announces == "needs-input"
+    assert status_row.requires_kind == portal_sync.KIND_QUESTION
+    # The announcement is seq N+1 right behind its question — the ordering
+    # guard (`ANNOUNCING_STATUSES`/`ordering_block_reason`) keys off exactly
+    # this adjacency.
+    assert status_row.seq == question_row.seq + 1
+
+
+def test_enqueue_question_reproduces_sub_1ea1d3_second_question_also_announced():
+    """Regression for #2901 / SUB-1EA1D3: question (applied) -> status
+    (applied) -> a second question with NO status row behind it — the real
+    outbox shape that shipped with no email. With the fold, the second
+    `enqueue_question` call must also queue its own status, so the drain
+    sends question -> status -> question -> status in order, never a bare
+    trailing question."""
+    enqueue_question(SUB, "Two things to help us scope...")
+    sync_tick(client=FakeClient())  # first question + its announcement land
+
+    enqueue_question(SUB, "Thanks -- that covers who...")
+    client = FakeClient()
+    sync_tick(client=client)
+
+    assert client.pushed_kinds == ["question", "status"]
+    rows = portal_store.outbox_for_submission(SUB)
+    assert [r.kind for r in rows] == ["question", "status", "question", "status"]
+    assert [r.state for r in rows] == [portal_store.STATE_APPLIED] * 4
+    # The second question's announcement never sent ahead of its own
+    # question being confirmed applied.
+    assert ordering_block_reason(rows[3]) is None
+
+
 def test_a_stalled_submission_does_not_stall_another_customers():
     enqueue_design_round(SUB, _design())
     enqueue_status(SUB, "awaiting-signoff")
@@ -1875,9 +1916,9 @@ def _push_and_apply_question(question: str = "Offline-first, yes or no?"):
     path `mark_applied`'s `kind == "question"` branch runs for real once
     `_push` gets a 200 back, which is what writes the `question_pushed`
     ledger entry `_consume_questions` later pairs an answer against."""
-    row = enqueue_question(SUB, question)
-    portal_store.mark_applied(row)
-    return row
+    question_row, _status_row = enqueue_question(SUB, question)
+    portal_store.mark_applied(question_row)
+    return question_row
 
 
 class TestQuestionAnswerFields: