code-coordinator 0.5.244__tar.gz → 0.5.245__tar.gz

{code_coordinator-0.5.244 → code_coordinator-0.5.245}/CLAUDE.md

@@ -223,10 +223,9 @@ versus keep in the coordinator session) are in
   bypassed by the one class of session most likely to reach for `gh` out of habit. Reads are
   covered too — `coord issue list` and `coord issue view` shipped in #2484, so a plain issue
   listing/search or an issue-plus-comments lookup has no excuse to reach for `gh`. Where no
-  `coord` subcommand covers what's needed — still a real gap in places as of 2026-08 (e.g. #2643:
-  `coord issue` can create/edit/label/close but cannot post a plain comment on an issue that stays
-  open) — falling back to `gh` for that one call is fine, but say so and treat it as a gap to flag
-  or file, not a silent workaround.
+  `coord` subcommand covers what's needed — the seam is wide but not total, so check
+  `coord <group> --help` before concluding either way — falling back to `gh` for that one call is
+  fine, but say so and treat it as a gap to flag or file, not a silent workaround.
 
 ## Testing — black-box coverage is the acceptance bar
 

{code_coordinator-0.5.244 → code_coordinator-0.5.245}/PKG-INFO

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

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

@@ -136,6 +136,7 @@ coord/serve_app.py
 coord/smoke.py
 coord/spend_ceiling.py
 coord/split_work.py
+coord/sql.py
 coord/stage_projection.py
 coord/state.py
 coord/test_author.py
@@ -472,6 +473,7 @@ tests/test_cli_track.py
 tests/test_cli_tui_update.py
 tests/test_cli_wait.py
 tests/test_client_base_install.py
+tests/test_commands_common.py
 tests/test_comments.py
 tests/test_completion_summary.py
 tests/test_config.py
@@ -662,6 +664,7 @@ tests/test_release_verify.py
 tests/test_release_window.py
 tests/test_remote_auto_prune.py
 tests/test_remote_interactive_reaper.py
+tests/test_repo_add.py
 tests/test_repo_edit_2220.py
 tests/test_repo_graph_fleet_2237.py
 tests/test_repo_onboard_2220.py
@@ -694,6 +697,7 @@ tests/test_spend_ceiling.py
 tests/test_spend_ceiling_coordinator.py
 tests/test_split.py
 tests/test_split_work.py
+tests/test_sql_dialect.py
 tests/test_stage_projection.py
 tests/test_stalled_pipeline.py
 tests/test_state.py

{code_coordinator-0.5.244 → code_coordinator-0.5.245}/code_coordinator.egg-info/scm_file_list.json

@@ -243,6 +243,7 @@
     "coord/smoke.py",
     "coord/spend_ceiling.py",
     "coord/split_work.py",
+    "coord/sql.py",
     "coord/stage_projection.py",
     "coord/state.py",
     "coord/test_author.py",
@@ -544,6 +545,7 @@
     "tests/test_cli_tui_update.py",
     "tests/test_cli_wait.py",
     "tests/test_client_base_install.py",
+    "tests/test_commands_common.py",
     "tests/test_comments.py",
     "tests/test_completion_summary.py",
     "tests/test_config.py",
@@ -734,6 +736,7 @@
     "tests/test_release_window.py",
     "tests/test_remote_auto_prune.py",
     "tests/test_remote_interactive_reaper.py",
+    "tests/test_repo_add.py",
     "tests/test_repo_edit_2220.py",
     "tests/test_repo_graph_fleet_2237.py",
     "tests/test_repo_onboard_2220.py",
@@ -766,6 +769,7 @@
     "tests/test_spend_ceiling_coordinator.py",
     "tests/test_split.py",
     "tests/test_split_work.py",
+    "tests/test_sql_dialect.py",
     "tests/test_stage_projection.py",
     "tests/test_stalled_pipeline.py",
     "tests/test_state.py",

code_coordinator-0.5.245/code_coordinator.egg-info/scm_version.json

@@ -0,0 +1,8 @@
+{
+  "tag": "0.5.245",
+  "distance": 0,
+  "node": "g8f3ba2ceb3a5edd25c795a8fe295601edef37db5",
+  "dirty": false,
+  "branch": "HEAD",
+  "node_date": "2026-08-26"
+}

{code_coordinator-0.5.244 → code_coordinator-0.5.245}/coord/acceptance_drivers.py

@@ -49,6 +49,20 @@ from pathlib import Path
 # adapter landing, but running it must fail loudly rather than silently no-op.
 SUPPORTED_KINDS = ("tui-tuidriver", "cli-pytest", "web-playwright")
 
+# #2748 (IL-2): driver kinds whose `run` produces a real pass/fail verdict
+# but NOT yet a deterministic one, because an input they depend on hasn't
+# shipped. `web-playwright` is the one case today — the driver itself
+# landed (#1539), but the seeded-board fixture server it needs to run
+# against a fixed, known state (#1538) has not, so a run against a live
+# fleet observes whatever that fleet happens to be doing rather than a
+# pinned fixture (CLAUDE.md's web-playwright section: "a smoke net, not a
+# deterministic oracle"). `coord.repo_onboard`'s oracle-readiness layer
+# reads this to report the gap explicitly instead of a driver-present repo
+# silently reading as fully oracle-ready. Kept here (not in coord.config)
+# because it is exactly the kind of "which medium behaves how" fact this
+# module already owns — see the module docstring.
+FIXTURE_SERVER_DEPENDENT_KINDS = frozenset({"web-playwright"})
+
 # libtest's ``--format json`` per-line test-event stream (`cargo test -- -Z
 # unstable-options --format json`) event -> our normalized status.
 _LIBTEST_EVENT_STATUS = {"ok": "pass", "failed": "fail", "ignored": "skip"}

{code_coordinator-0.5.244 → code_coordinator-0.5.245}/coord/agent.py

@@ -3945,25 +3945,44 @@ MILESTONE_CHAT_DENY_COMMANDS: list[str] = [
 
 DECOMPOSITION_CHAT_SYSTEM_PROMPT = """\
 You are a decomposition steward for a customer's APPROVED portal submission \
-that an operator just pulled into this session from the TUI's "Approved \
-work items" panel (#2533, ms-67 contract §4). Unlike `milestone-chat` above \
-(which proposes and waits for confirmation before writing anything), this \
-session's WHOLE JOB is to actually decompose the submission into real \
-coordinator work — there is no separate confirm-then-write step here \
-because pulling the row into this session already IS the operator's \
-confirmation.
-
-The first user message carries: the submission's OUTCOME, AUDIENCE, DONE \
-DEFINITION, and CONSTRAINTS (the four fields the customer described); its \
-mapped repo(s); and `coordinator.yml` topology context for those repo(s) \
-(depends_on, which machines claim each repo).
-
-Your job, in order:
+that an operator just pulled into this session (#2533, ms-67 contract §4; \
+#2750, IL-4 — "the intake session"). This is ONE ITERATION of a possibly \
+multi-day, multi-session intake — a client round-trip takes days, so no \
+single session can sit and wait for one. Every iteration is disposable; the \
+`coord portal` ledger (Q&A, decisions, narrative) is what's durable, and it \
+is what makes it safe for a LATER iteration on a DIFFERENT machine to pick \
+up exactly where this one left off with no memory of this conversation.
+
+The first user message carries, in order: a MODE line (`MODE: FILE` or \
+`MODE: DISCUSS`) naming which posture this iteration runs in and WHY it was \
+picked — say so yourself, verbatim, as the first line of your own final \
+response (a session that silently chose to file instead of asking is \
+exactly the failure this design exists to prevent); the submission's \
+OUTCOME, AUDIENCE, DONE DEFINITION, and CONSTRAINTS; its mapped repo(s); \
+`coordinator.yml` topology context for those repo(s) (depends_on, which \
+machines claim each repo); and a RUNNING CONTEXT section rendering the \
+submission's full ledger so far — every question asked and (if answered) \
+its answer, every decision on record (current and archived, archived ones \
+carrying WHY they were ruled out), and the current narrative. Read \
+RUNNING CONTEXT before doing anything else: never re-ask a question already \
+answered there, and never re-propose a decision already archived there \
+without new information that changes the calculus — cite the existing \
+entry's seq/reason if the operator or a re-briefed fact brings it up again.
+
+You can always re-fetch the live ledger mid-session with:
+
+    coord portal ledger <submission_id>
+
+(add `--json` for the raw structured form) — useful in a long-running \
+`--interactive` conversation where the operator may answer something out of \
+band while you're mid-thought.
+
+── Filing a decomposition (MODE: FILE, or MODE: DISCUSS's "Decompose" exit) ──
+
 1. Decide whether this is ORACLE-LOOP-SHAPED work (docs/ORACLE_LOOP.md) — \
 big or cross-cutting enough to warrant a Gate-A contract + independent \
-test-author, or small enough to skip straight to normal dispatch. Discuss \
-this with the operator if it's not obvious; you don't need to wait for \
-explicit confirmation before filing, but flag your reasoning.
+test-author, or small enough to skip straight to normal dispatch. Flag your \
+reasoning even when it's obvious.
 2. Produce one or more GitHub issues describing the work, using:
 
     coord issue create <repo> --title '<title>' --body '<body>'
@@ -3997,31 +4016,116 @@ silently. Say so explicitly in your final summary to the operator (e.g. \
 "this submission has no recorded portal link — coord portal link only \
 covers milestones, and #2533's own dispatcher found no equivalent for a \
 one-off issue"), so the gap is visible rather than silently lost.
+5. Archive the decision trail onto the epic (#2750 — "every iteration must \
+record its rejections with reasons", surfaced where the next human to read \
+the epic will actually see it, not just in `coord portal ledger`). When a \
+milestone/epic was filed in step 2: run `coord portal ledger <submission_id>` \
+(read-only), take its "## Decisions" and "## Archive (superseded / \
+rejected)" sections verbatim, and splice them onto the epic's body under a \
+`## Decisions` heading — read the epic's current body (e.g. `gh issue view \
+<epic> --json body -q .body`), append the section (or replace a pre-existing \
+`## Decisions` heading in place — do not duplicate it), and write it back \
+with `coord issue edit <repo> <epic> --body-file <tmpfile>` (never raw `gh \
+issue edit`). Skip this step only when the ledger has no decisions at all \
+(a submission that never went through a MODE: DISCUSS iteration) — say so \
+rather than writing an empty section.
+
+── MODE: DISCUSS — ask / propose / decompose ──
+
+Your first user message said `MODE: DISCUSS` because the submission is \
+under-specified or the mapped repo is greenfield (#2750's own mechanical \
+triggers — missing done-definition/audience, or no commits/no CLAUDE.md on \
+the mapped repo yet). Filing straight through here means inventing an \
+architecture or a done-definition on the client's behalf and queuing real \
+work against the guess. Instead, THIS iteration ends in EXACTLY ONE of \
+three terminal moves — never zero, never more than one:
+
+1. ASK — when what's missing can only come from the CLIENT (not from the \
+operator, not from repo history, not from a reasonable judgment call you \
+could make yourself). Prefer ONE well-formed question: the portal's \
+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
+
+   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 \
+wakes the next iteration once the client answers.
+
+2. PROPOSE — when you CAN make a reasonable judgment call on the client's \
+behalf (an architecture/stack/framework choice, a scope cut, anything a \
+competent operator could just decide) but it deserves OPERATOR sign-off \
+before it becomes load-bearing — this is OPERATOR-facing, never portal-\
+facing; the client is never asked to adjudicate a framework choice. Record \
+your recommendation:
+
+    coord portal decision propose <submission_id> "<decision text>"
+
+   Then, in the SAME iteration, record every alternative you seriously \
+considered and ruled OUT — with a reason — so a later iteration doesn't \
+re-litigate it (#2750: "without recorded rejections you re-litigate"):
+
+    coord portal decision propose <submission_id> "<alternative text>"
+    coord portal decision reject <submission_id> <alt_seq> "<why ruled out>"
+
+   If you're REVISING a decision an earlier iteration already proposed or \
+confirmed (not a same-iteration alternative), use supersede instead of \
+reject so the earlier text stays on record rather than reading as an \
+outright mistake:
+
+    coord portal decision supersede <submission_id> <old_seq> <new_seq>
+
+   Then STOP — summarize every proposal and rejection for the operator and \
+run nothing else. Do NOT confirm your own proposal (`coord portal decision \
+confirm` is the operator's move, taken outside this session) and do NOT \
+file or queue anything until a later iteration is briefed with a confirmed \
+decision. Confirmation is what starts that next iteration.
+
+3. DECOMPOSE — when done_definition/audience are captured (directly, or \
+settled via decisions now CONFIRMED in RUNNING CONTEXT) and every mapped \
+repo has something to decompose against. Follow "Filing a decomposition" \
+above in full, including step 5's decision archive.
+
+If genuinely nothing has changed since the last iteration (re-briefed with \
+no new answer and no new information), say so explicitly and re-Ask or \
+re-Propose rather than inventing new work to look productive.
 
 Rules:
 - Do NOT run raw `gh issue create`/`gh issue edit`/`gh pr *`/`gh api -X \
 POST|PATCH|DELETE` or any other mutating `gh` command — the write paths \
-above (`coord issue create`, `coord milestone create/add-child`, `coord \
-drive-queue add`, `coord portal link`) are the only ones you may use.
+above (`coord issue create`, `coord issue edit --body-file`, `coord \
+milestone create/add-child`, `coord drive-queue add`, `coord portal link`, \
+`coord portal enqueue-question`, `coord portal enqueue-status`, `coord \
+portal decision propose/reject/supersede`) are the only ones you may use. \
+`gh issue view` and other read-only `gh`/`coord` lookups are fine.
 - Do NOT run `coord assign <machine> <repo> <issue>` or `coord drive \
 --tmux` — always `coord drive-queue add`.
 - Do NOT run `coord approve` or `coord merge` — outside this session's job.
+- Do NOT run `coord portal decision confirm` — that is the OPERATOR's move, \
+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.
-- Keep the operator informed: summarize your decomposition plan before \
-filing, and report back what you filed/queued/linked (and any link gap) \
+- 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.
+- 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.\
 """
 
-# Deny list applied to decomposition-chat workers (#2533). Unlike
-# milestone-chat, this type's WHOLE job is to write (issue create /
-# milestone create+add-child / drive-queue add / portal link), so this list
-# is deliberately narrow — it blocks raw `gh` mutations, repo-write git
-# commands, destructive git ops, and the three unrelated `coord` write
-# commands (approve/merge/assign) explicitly out of scope, while every write
-# path this session actually needs (`coord issue create`, `coord milestone
-# create`/`add-child`, `coord drive-queue add`, `coord portal link`) is
-# allowed by omission.
+# Deny list applied to decomposition-chat workers (#2533; extended #2750
+# IL-4 for the ask/propose/decompose intake loop). Unlike milestone-chat,
+# this type's WHOLE job is to write (issue create / issue edit / milestone
+# create+add-child / drive-queue add / portal link / enqueue-question /
+# enqueue-status / decision propose|reject|supersede), so this list is
+# deliberately narrow — it blocks raw `gh` mutations, repo-write git
+# commands, destructive git ops, the three unrelated `coord` write commands
+# (approve/merge/assign) explicitly out of scope, and `coord portal decision
+# confirm` (the OPERATOR's move, never this session's own — #2750's "Propose"
+# terminal move must not self-confirm), while every write path this session
+# actually needs is allowed by omission.
 DECOMPOSITION_CHAT_DENY_COMMANDS: list[str] = [
     "Bash(gh issue edit *)",
     "Bash(gh issue create *)",
@@ -4047,6 +4151,7 @@ DECOMPOSITION_CHAT_DENY_COMMANDS: list[str] = [
     "Bash(coord approve *)",
     "Bash(coord merge *)",
     "Bash(coord assign *)",
+    "Bash(coord portal decision confirm *)",
 ]
 
 MOCK_AUTHOR_SYSTEM_PROMPT = """\

{code_coordinator-0.5.244 → code_coordinator-0.5.245}/coord/audit.py

@@ -31,6 +31,7 @@ import threading
 import time
 from typing import Any
 
+from coord import sql
 from coord.db import get_connection, is_lock_contention_error, retry_on_locked
 
 _log = logging.getLogger(__name__)
@@ -138,7 +139,8 @@ def _record_audit_unsafe(
     conn = get_connection()
 
     def _write() -> None:
-        conn.execute(
+        sql.execute(
+            conn,
             """INSERT INTO audit_log (
                 ts, tier, category, event_type, actor,
                 repo, issue, assignment_id, machine, summary, details_json
@@ -282,7 +284,8 @@ def _maybe_trim(conn) -> None:
     max_rows = _resolve_max_rows()
     if max_rows <= 0:
         return
-    conn.execute(
+    sql.execute(
+        conn,
         "DELETE FROM audit_log WHERE id NOT IN "
         "(SELECT id FROM audit_log ORDER BY id DESC LIMIT ?)",
         (max_rows,),
@@ -465,7 +468,8 @@ def query_audit_log(
     where = f"WHERE {' AND '.join(clauses)}" if clauses else ""
     conn = get_connection()
     # Fetch one extra row to detect has_more without a second COUNT query.
-    rows = conn.execute(
+    rows = sql.execute(
+        conn,
         f"SELECT {', '.join(_AUDIT_COLUMNS)} FROM audit_log {where} "
         "ORDER BY ts DESC, id DESC LIMIT ?",
         (*params, limit + 1),

{code_coordinator-0.5.244 → code_coordinator-0.5.245}/coord/client.py

@@ -576,6 +576,81 @@ def fetch_gate_a_approval(
     return None
 
 
+def fetch_portal_link(
+    svc: ServiceConfig,
+    repo_name: str,
+    *,
+    milestone_number: int | None = None,
+    issue_number: int | None = None,
+    timeout: float = _DEFAULT_TIMEOUT,
+) -> dict | None:
+    """GET one milestone's (or, with ``issue_number``, one issue's) portal
+    ``submission_id`` link (#2751). Pass exactly one of ``milestone_number``
+    / ``issue_number`` — same contract as :func:`coord.state.get_portal_link`.
+
+    Fail-soft to ``None`` on any transport/HTTP/decode error, mirroring
+    :func:`fetch_gate_a_approval`. "Couldn't ask" collapsing to "not linked"
+    matches the CLI's own pre-existing read for a genuinely unlinked
+    milestone/issue, so a daemon hiccup degrades to the same message an
+    operator would already see rather than a traceback.
+    """
+    params: dict[str, str | int] = {"repo_name": repo_name}
+    if milestone_number is not None:
+        params["milestone_number"] = milestone_number
+    if issue_number is not None:
+        params["issue_number"] = issue_number
+    try:
+        resp = httpx.get(
+            f"{svc.url}/portal-link",
+            params=params,
+            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:
+    """GET ``/portal-ledger`` from the daemon *svc* points at — the running-
+    context payload :func:`coord.portal_store.render_ledger_payload` builds
+    locally, routed through the daemon for a thin client (#2751).
+
+    Factored out of two independent near-verbatim copies (#2750 fix round):
+    `coord.commands.portal._fetch_ledger_payload_remote` (the ``coord
+    portal ledger`` CLI render) and `coord.decomposition_chat.
+    _fetch_ledger_payload_remote` (the intake session's own briefing
+    builder, `fetch_running_context`) agreed on the same GET/params/
+    header/timeout/``resp.json()["payload"]`` wire shape but maintained it
+    in two places — exactly the split-brain-waiting-to-happen this repo's
+    own rule warns about ("if two surfaces answer the same question, they
+    must call the same function"). Both already reach into this module for
+    other daemon calls, so this is the natural shared home.
+
+    Deliberately does **not** follow the fail-soft-to-``None`` convention
+    most of this module's other ``fetch_*`` helpers use (mirroring
+    :func:`fetch_milestone_gate`'s reasoning): a briefing that silently
+    rendered as "empty" on a daemon hiccup would be indistinguishable from
+    "genuinely nothing on file yet", which is actively misleading rather
+    than merely unavailable. Raises ``httpx.HTTPError`` on a transport/HTTP
+    failure and ``KeyError``/``ValueError`` on a malformed body; callers
+    let the failure surface rather than swallowing it.
+    """
+    resp = httpx.get(
+        f"{svc.url}/portal-ledger",
+        params={"submission_id": submission_id},
+        headers=_headers(svc),
+        timeout=timeout,
+    )
+    resp.raise_for_status()
+    return resp.json()["payload"]
+
+
 def fetch_milestone_gate(
     svc: ServiceConfig,
     repo_name: str,