code-coordinator 0.5.108__tar.gz → 0.5.110__tar.gz

{code_coordinator-0.5.108 → code_coordinator-0.5.110}/.github/workflows/test.yml

@@ -56,35 +56,44 @@ jobs:
   # 2026-08-08 stall (`parked — CI running: windows`): each drive parked on it
   # and handed off, which is how five PRs piled up unmerged.
   #
-  # What that latency bought per-PR was ~nothing. The job is deliberately red
-  # and non-blocking (see below), so nothing gates on its result; its output
-  # is one number (`368 failed, ...`) that only moves when someone works on
-  # #1156. Running it per-merge keeps that baseline just as current.
+  # What that latency bought per-PR was ~nothing while the job was red by
+  # design; running it per-merge keeps the baseline just as current. Now that
+  # it is a real gate (below), per-PR coverage is worth revisiting — and the
+  # right move there is probably to keep it per-PR but shrink it to the import
+  # smoke #1895's own title describes, rather than the full suite.
   #
-  # REVISIT WHEN #1156 LANDS. Once the suite is genuinely green and blocking,
-  # per-PR coverage is worth its duration again — and at that point the right
-  # move is probably to keep it per-PR but shrink it to the import smoke
-  # #1895's own title describes, rather than the full suite.
+  # NO `continue-on-error` — THIS IS A REAL GATE NOW (#2000).
   #
-  # This job is EXPECTED TO BE RED when it lands: `coord.cli` cannot import
-  # on Windows today (`cli.py` -> `coord/interactive.py`'s unconditional
-  # `import fcntl`, a POSIX-only stdlib module). #1156 (CP-1, the import
-  # guards) is what makes this suite green — and #1156 is the one that
-  # removes the `continue-on-error` below. Until then this is a
-  # visible-but-non-blocking signal, not a real gate.
+  # History: when #1895 landed this job this was EXPECTED TO BE RED, because
+  # `coord.cli` could not import on Windows (`cli.py` -> `coord/interactive.py`
+  # unconditionally `import fcntl`, a POSIX-only stdlib module), so both steps
+  # carried `continue-on-error: true` and the job was a visible-but-
+  # non-blocking signal. Two things closed that out:
   #
-  # `continue-on-error` MUST stay on the *step*, not the job (#2026).
-  # At job level it only softens the *workflow run* conclusion; the `windows`
-  # **check** still reports `failure` to the Checks API. GitHub's own branch
-  # protection tolerates that, but `coord merge`'s CI gate does not —
-  # `coord.ci_store._PASSING_CONCLUSIONS` is {success, skipped, neutral} with
-  # no notion of a non-blocking check, so a job-level flag left every
-  # claude-coordinator PR unmergeable and stalled the drive queue overnight
-  # on 2026-08-08 (four finished PRs, everything else green). At step level
-  # the step's failure is recorded but the job exits 0, so the check is
-  # `success` and #1895's actual acceptance criterion — "it does not block
-  # merges while red" — finally holds. The failures stay fully visible in the
-  # job log; that log IS the #1156 specification and the pass/fail baseline.
+  #   1. #1156 (CP-1) landed the import guards, killing the `fcntl` failure.
+  #   2. #2000 put `tzdata; sys_platform == 'win32'` in the BASE `[project]
+  #      dependencies` (NOT a CI-only `pip install`) — Windows ships no IANA
+  #      time-zone database, so `zoneinfo` could not resolve `America/Chicago`
+  #      and the suite died during *collection*. coord/config.py,
+  #      coord/models.py, coord/failure_class.py and coord/machine_pause.py all
+  #      resolve named zones at runtime, so that was a shipped defect for every
+  #      `pip install code-coordinator` Windows user, not a test artefact.
+  #      tests/test_client_base_install.py pins it in the base deps.
+  #
+  # With both fixed the flags are gone and a Windows failure reddens this job
+  # for real. tests/test_windows_job_is_a_real_gate_2000.py is the regression
+  # guard against them creeping back.
+  #
+  # Why re-arming this cannot re-block the repo: `if: github.event_name ==
+  # 'push'` (below) means the job is SKIPPED on every `pull_request` event, and
+  # `skipped` is already in `coord.ci_store._PASSING_CONCLUSIONS` — so a red
+  # Windows run shows up on main, never on a PR's merge gate. That guard is
+  # what makes removing `continue-on-error` safe; it did not exist during the
+  # 2026-08-08 stall, when a *job-level* flag (#2026) left every
+  # claude-coordinator PR unmergeable overnight because the `windows` **check**
+  # still reported `failure` to the Checks API even though the workflow run's
+  # conclusion was softened. If this job is ever made per-PR again, that
+  # interaction is the thing to re-check first.
   #
   # Python 3.12 only, deliberately not the 3.12/3.13 matrix `test` runs above
   # — the matrix axis there is Python versions on Linux; this job's axis is
@@ -102,18 +111,15 @@ jobs:
       - uses: actions/setup-python@v5
         with:
           python-version: "3.12"
-      # Both steps carry the flag, not just pytest: a Windows-only *install*
-      # failure would otherwise redden the job and re-block the whole repo
-      # exactly as a test failure did. Until #1156, this job's contract is
-      # "always report, never block" — and a failed install is every bit as
-      # visible in the log as a failed test.
+      # #2000: no `continue-on-error` on either step any more — a Windows-only
+      # install failure (a base dep that does not resolve on win32, say) is
+      # exactly as much of a real defect as a test failure, and this job now
+      # exists to fail on it. See the header for why re-arming it is safe.
       - run: pip install -e ".[dev]"
-        continue-on-error: true
       # #2180: same split as the `test` job above — the sealed acceptance
       # suite is gated separately through the #2164 CI wrapper, not swept
       # into this job's ordinary pytest run.
       - run: pytest --ignore=tests/acceptance
-        continue-on-error: true
 
   # #1484: run the full suite with `gh` made unresolvable on PATH.
   #

{code_coordinator-0.5.108 → code_coordinator-0.5.110}/CLAUDE.md

@@ -1,4 +1,4 @@
-# claude-coordinator
+# code-coordinator
 
 CLI tool + per-machine agent server that coordinates Claude Code workers across multiple machines and repos over Tailscale.
 

{code_coordinator-0.5.108 → code_coordinator-0.5.110}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: code-coordinator
-Version: 0.5.108
+Version: 0.5.110
 Summary: Coordinate Claude Code workers across multiple machines and repos.
 Author-email: John Donaghy <johnfdonaghy@gmail.com>
 License-Expression: LicenseRef-FSL-1.1-MIT
@@ -38,11 +38,11 @@ Requires-Dist: setuptools-scm>=8; extra == "dev"
 Requires-Dist: wheel; extra == "dev"
 Dynamic: license-file
 
-# claude-coordinator
+# code-coordinator
 
 Coordinate a fleet of Claude Code workers — and human-attended interactive `claude` sessions — from a single board.
 
-Claude Code is great at one task at a time. Real projects have dozens of issues, spread across repos, that each want their own session, their own scoping, and their own review. `claude-coordinator` runs many workers in parallel — on one machine or across several over Tailscale — behind a coordinator that picks the model, avoids file conflicts, routes by capability, and drives the full **Work → Test → Review → Merge** pipeline. Each stage can run as a cheap `claude -p` worker *or* as a human-attended interactive session you launch and steer from the board.
+Claude Code is great at one task at a time. Real projects have dozens of issues, spread across repos, that each want their own session, their own scoping, and their own review. `code-coordinator` runs many workers in parallel — on one machine or across several over Tailscale — behind a coordinator that picks the model, avoids file conflicts, routes by capability, and drives the full **Work → Test → Review → Merge** pipeline. Each stage can run as a cheap `claude -p` worker *or* as a human-attended interactive session you launch and steer from the board.
 
 ## The problem
 
@@ -110,7 +110,7 @@ Two rules shape the flow:
 ## Quick demo
 
 ```bash
-pip install claude-coordinator     # from PyPI
+pip install code-coordinator     # from PyPI
 coord init                         # interactive setup: detects repos, writes coordinator.yml
 coord agent &                      # start the agent server (port 7433) — see Quick Start for the systemd setup
 
@@ -139,7 +139,7 @@ Prefer to drive it by hand? Launch any stage as an interactive session from `coo
 ### 1. Install
 
 ```bash
-pip install claude-coordinator
+pip install code-coordinator
 ```
 
 The `coord` CLI is now on your PATH. The same package provides the agent server (`coord agent`), so the coordinator side and the worker side share one install.
@@ -168,7 +168,7 @@ coord agent &     # port 7433; auto-detects the machine from hostname
 For anything beyond a trial, use the installer (systemd user service, auto-restart, survives reboots, separate worker logs):
 
 ```bash
-curl -sSL https://raw.githubusercontent.com/JDonaghy/claude-coordinator/main/install-agent.sh | bash
+curl -sSL https://raw.githubusercontent.com/JDonaghy/code-coordinator/main/install-agent.sh | bash
 ```
 
 The same script sets up remote worker machines — see [Worker node setup](#worker-node-setup).
@@ -549,7 +549,7 @@ The tool encodes a pattern from real multi-agent sessions: **separate the tech l
 
 1. On the new machine, run the installer (venv + systemd service in one shot):
    ```bash
-   curl -sSL https://raw.githubusercontent.com/JDonaghy/claude-coordinator/main/install-agent.sh | bash -s -- --machine <name>
+   curl -sSL https://raw.githubusercontent.com/JDonaghy/code-coordinator/main/install-agent.sh | bash -s -- --machine <name>
    ```
    No git clone needed — `install-agent.sh` pulls from PyPI.
 2. Add the machine to `coordinator.yml` under `machines:` with its Tailscale hostname and capabilities.
@@ -562,9 +562,9 @@ For Tailscale setup, see [tailscale.com/kb](https://tailscale.com/kb/). The agen
 To add a worker machine (no repo checkout needed):
 
 ```bash
-curl -sSL https://raw.githubusercontent.com/JDonaghy/claude-coordinator/main/install-agent.sh | bash
+curl -sSL https://raw.githubusercontent.com/JDonaghy/code-coordinator/main/install-agent.sh | bash
 # or with options:
-curl -sSL https://raw.githubusercontent.com/JDonaghy/claude-coordinator/main/install-agent.sh | bash -s -- --machine myserver --port 7433
+curl -sSL https://raw.githubusercontent.com/JDonaghy/code-coordinator/main/install-agent.sh | bash -s -- --machine myserver --port 7433
 ```
 
 This installs coord, sets up a systemd service with auto-restart, and starts the agent. Then add the machine to `coordinator.yml` and run `coord status` to verify connectivity.

{code_coordinator-0.5.108 → code_coordinator-0.5.110}/README.md

@@ -1,8 +1,8 @@
-# claude-coordinator
+# code-coordinator
 
 Coordinate a fleet of Claude Code workers — and human-attended interactive `claude` sessions — from a single board.
 
-Claude Code is great at one task at a time. Real projects have dozens of issues, spread across repos, that each want their own session, their own scoping, and their own review. `claude-coordinator` runs many workers in parallel — on one machine or across several over Tailscale — behind a coordinator that picks the model, avoids file conflicts, routes by capability, and drives the full **Work → Test → Review → Merge** pipeline. Each stage can run as a cheap `claude -p` worker *or* as a human-attended interactive session you launch and steer from the board.
+Claude Code is great at one task at a time. Real projects have dozens of issues, spread across repos, that each want their own session, their own scoping, and their own review. `code-coordinator` runs many workers in parallel — on one machine or across several over Tailscale — behind a coordinator that picks the model, avoids file conflicts, routes by capability, and drives the full **Work → Test → Review → Merge** pipeline. Each stage can run as a cheap `claude -p` worker *or* as a human-attended interactive session you launch and steer from the board.
 
 ## The problem
 
@@ -70,7 +70,7 @@ Two rules shape the flow:
 ## Quick demo
 
 ```bash
-pip install claude-coordinator     # from PyPI
+pip install code-coordinator     # from PyPI
 coord init                         # interactive setup: detects repos, writes coordinator.yml
 coord agent &                      # start the agent server (port 7433) — see Quick Start for the systemd setup
 
@@ -99,7 +99,7 @@ Prefer to drive it by hand? Launch any stage as an interactive session from `coo
 ### 1. Install
 
 ```bash
-pip install claude-coordinator
+pip install code-coordinator
 ```
 
 The `coord` CLI is now on your PATH. The same package provides the agent server (`coord agent`), so the coordinator side and the worker side share one install.
@@ -128,7 +128,7 @@ coord agent &     # port 7433; auto-detects the machine from hostname
 For anything beyond a trial, use the installer (systemd user service, auto-restart, survives reboots, separate worker logs):
 
 ```bash
-curl -sSL https://raw.githubusercontent.com/JDonaghy/claude-coordinator/main/install-agent.sh | bash
+curl -sSL https://raw.githubusercontent.com/JDonaghy/code-coordinator/main/install-agent.sh | bash
 ```
 
 The same script sets up remote worker machines — see [Worker node setup](#worker-node-setup).
@@ -509,7 +509,7 @@ The tool encodes a pattern from real multi-agent sessions: **separate the tech l
 
 1. On the new machine, run the installer (venv + systemd service in one shot):
    ```bash
-   curl -sSL https://raw.githubusercontent.com/JDonaghy/claude-coordinator/main/install-agent.sh | bash -s -- --machine <name>
+   curl -sSL https://raw.githubusercontent.com/JDonaghy/code-coordinator/main/install-agent.sh | bash -s -- --machine <name>
    ```
    No git clone needed — `install-agent.sh` pulls from PyPI.
 2. Add the machine to `coordinator.yml` under `machines:` with its Tailscale hostname and capabilities.
@@ -522,9 +522,9 @@ For Tailscale setup, see [tailscale.com/kb](https://tailscale.com/kb/). The agen
 To add a worker machine (no repo checkout needed):
 
 ```bash
-curl -sSL https://raw.githubusercontent.com/JDonaghy/claude-coordinator/main/install-agent.sh | bash
+curl -sSL https://raw.githubusercontent.com/JDonaghy/code-coordinator/main/install-agent.sh | bash
 # or with options:
-curl -sSL https://raw.githubusercontent.com/JDonaghy/claude-coordinator/main/install-agent.sh | bash -s -- --machine myserver --port 7433
+curl -sSL https://raw.githubusercontent.com/JDonaghy/code-coordinator/main/install-agent.sh | bash -s -- --machine myserver --port 7433
 ```
 
 This installs coord, sets up a systemd service with auto-restart, and starts the agent. Then add the machine to `coordinator.yml` and run `coord status` to verify connectivity.

{code_coordinator-0.5.108 → code_coordinator-0.5.110}/code_coordinator.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: code-coordinator
-Version: 0.5.108
+Version: 0.5.110
 Summary: Coordinate Claude Code workers across multiple machines and repos.
 Author-email: John Donaghy <johnfdonaghy@gmail.com>
 License-Expression: LicenseRef-FSL-1.1-MIT
@@ -38,11 +38,11 @@ Requires-Dist: setuptools-scm>=8; extra == "dev"
 Requires-Dist: wheel; extra == "dev"
 Dynamic: license-file
 
-# claude-coordinator
+# code-coordinator
 
 Coordinate a fleet of Claude Code workers — and human-attended interactive `claude` sessions — from a single board.
 
-Claude Code is great at one task at a time. Real projects have dozens of issues, spread across repos, that each want their own session, their own scoping, and their own review. `claude-coordinator` runs many workers in parallel — on one machine or across several over Tailscale — behind a coordinator that picks the model, avoids file conflicts, routes by capability, and drives the full **Work → Test → Review → Merge** pipeline. Each stage can run as a cheap `claude -p` worker *or* as a human-attended interactive session you launch and steer from the board.
+Claude Code is great at one task at a time. Real projects have dozens of issues, spread across repos, that each want their own session, their own scoping, and their own review. `code-coordinator` runs many workers in parallel — on one machine or across several over Tailscale — behind a coordinator that picks the model, avoids file conflicts, routes by capability, and drives the full **Work → Test → Review → Merge** pipeline. Each stage can run as a cheap `claude -p` worker *or* as a human-attended interactive session you launch and steer from the board.
 
 ## The problem
 
@@ -110,7 +110,7 @@ Two rules shape the flow:
 ## Quick demo
 
 ```bash
-pip install claude-coordinator     # from PyPI
+pip install code-coordinator     # from PyPI
 coord init                         # interactive setup: detects repos, writes coordinator.yml
 coord agent &                      # start the agent server (port 7433) — see Quick Start for the systemd setup
 
@@ -139,7 +139,7 @@ Prefer to drive it by hand? Launch any stage as an interactive session from `coo
 ### 1. Install
 
 ```bash
-pip install claude-coordinator
+pip install code-coordinator
 ```
 
 The `coord` CLI is now on your PATH. The same package provides the agent server (`coord agent`), so the coordinator side and the worker side share one install.
@@ -168,7 +168,7 @@ coord agent &     # port 7433; auto-detects the machine from hostname
 For anything beyond a trial, use the installer (systemd user service, auto-restart, survives reboots, separate worker logs):
 
 ```bash
-curl -sSL https://raw.githubusercontent.com/JDonaghy/claude-coordinator/main/install-agent.sh | bash
+curl -sSL https://raw.githubusercontent.com/JDonaghy/code-coordinator/main/install-agent.sh | bash
 ```
 
 The same script sets up remote worker machines — see [Worker node setup](#worker-node-setup).
@@ -549,7 +549,7 @@ The tool encodes a pattern from real multi-agent sessions: **separate the tech l
 
 1. On the new machine, run the installer (venv + systemd service in one shot):
    ```bash
-   curl -sSL https://raw.githubusercontent.com/JDonaghy/claude-coordinator/main/install-agent.sh | bash -s -- --machine <name>
+   curl -sSL https://raw.githubusercontent.com/JDonaghy/code-coordinator/main/install-agent.sh | bash -s -- --machine <name>
    ```
    No git clone needed — `install-agent.sh` pulls from PyPI.
 2. Add the machine to `coordinator.yml` under `machines:` with its Tailscale hostname and capabilities.
@@ -562,9 +562,9 @@ For Tailscale setup, see [tailscale.com/kb](https://tailscale.com/kb/). The agen
 To add a worker machine (no repo checkout needed):
 
 ```bash
-curl -sSL https://raw.githubusercontent.com/JDonaghy/claude-coordinator/main/install-agent.sh | bash
+curl -sSL https://raw.githubusercontent.com/JDonaghy/code-coordinator/main/install-agent.sh | bash
 # or with options:
-curl -sSL https://raw.githubusercontent.com/JDonaghy/claude-coordinator/main/install-agent.sh | bash -s -- --machine myserver --port 7433
+curl -sSL https://raw.githubusercontent.com/JDonaghy/code-coordinator/main/install-agent.sh | bash -s -- --machine myserver --port 7433
 ```
 
 This installs coord, sets up a systemd service with auto-restart, and starts the agent. Then add the machine to `coordinator.yml` and run `coord status` to verify connectivity.

{code_coordinator-0.5.108 → code_coordinator-0.5.110}/code_coordinator.egg-info/SOURCES.txt

@@ -745,6 +745,7 @@ tests/test_usage_rollup.py
 tests/test_venv_live_install_2121.py
 tests/test_version_single_source.py
 tests/test_watch.py
+tests/test_windows_job_is_a_real_gate_2000.py
 tests/test_worker_events.py
 tests/test_worker_image_pin_sync.py
 tests/test_worker_safety.py

{code_coordinator-0.5.108 → code_coordinator-0.5.110}/code_coordinator.egg-info/scm_file_list.json

@@ -775,6 +775,7 @@
     "tests/test_venv_live_install_2121.py",
     "tests/test_version_single_source.py",
     "tests/test_watch.py",
+    "tests/test_windows_job_is_a_real_gate_2000.py",
     "tests/test_worker_events.py",
     "tests/test_worker_image_pin_sync.py",
     "tests/test_worker_safety.py",

{code_coordinator-0.5.108 → code_coordinator-0.5.110}/code_coordinator.egg-info/scm_version.json

@@ -1,7 +1,7 @@
 {
-  "tag": "0.5.108",
+  "tag": "0.5.110",
   "distance": 0,
-  "node": "g88b0fe133f2629aebc4acb6c0cd2f756be9213dc",
+  "node": "g587648b558cece37b10d0ceb9906cec225d8ceab",
   "dirty": false,
   "branch": "HEAD",
   "node_date": "2026-08-16"

{code_coordinator-0.5.108 → code_coordinator-0.5.110}/coord/agent.py

@@ -7121,6 +7121,20 @@ class AgentServer:
             assert proc.stdin is not None
             proc.stdin.write(initial_input)
             proc.stdin.flush()
+            # #2306: a provider that does not support stdin message injection
+            # (``capabilities().inject == False``, e.g. OpenCodeProvider,
+            # which takes its briefing on argv) never writes to or closes
+            # this pipe again.  Leaving it open blocks the worker forever —
+            # it never sees an EOF on stdin — until the 600s TTFT watchdog
+            # kills it having emitted zero bytes.  Close it here so such a
+            # worker gets its EOF immediately after the (empty) initial
+            # write.  ``provider_obj`` is ``None`` on the legacy path
+            # (``spec.provider is None``, pre-#324 behaviour) — treat that
+            # as claude/inject-capable and leave stdin open, matching
+            # ``inject_message``'s existing "no provider info => allow"
+            # fallback.
+            if provider_obj is not None and not provider_obj.capabilities().inject:  # type: ignore[attr-defined]
+                proc.stdin.close()
         except (BrokenPipeError, OSError) as e:
             log_fh.write(f"\n# failed to send initial briefing: {e}\n")
 

{code_coordinator-0.5.108 → code_coordinator-0.5.110/coord}/deploy/coord-db-backup.service

@@ -46,7 +46,7 @@
 
 [Unit]
 Description=Snapshot coord.db to the external SSD (interim, pending #1822)
-Documentation=https://github.com/JDonaghy/claude-coordinator/issues/1822
+Documentation=https://github.com/JDonaghy/code-coordinator/issues/1822
 
 [Service]
 Type=oneshot

{code_coordinator-0.5.108 → code_coordinator-0.5.110}/coord/deploy/coord-drive-queue.service

@@ -43,7 +43,7 @@
 #   pip show code-coordinator | grep -i editable     # must print NOTHING
 #
 # An editable checkout (e.g. elitebook's dev box, where ~/.local/bin/coord
-# points at ~/src/claude-coordinator) lets a worker's branch churn rewrite the
+# points at ~/src/code-coordinator) lets a worker's branch churn rewrite the
 # runner's own code out from under a live tick. Do not install this unit
 # there. See docs/DRIVE_QUEUE.md.
 #

{code_coordinator-0.5.108 → code_coordinator-0.5.110}/coord/deploy/coord-serve.service

@@ -45,7 +45,7 @@ Type=simple
 #   error rather than a red suite — because a PATH= line here fixes this
 #   host and leaves the next one broken silently, which is the same failure
 #   shape as the bug. Keep both.
-# - #1117 added the repo venv (%h/src/claude-coordinator/.venv/bin) so
+# - #1117 added the repo venv (%h/src/code-coordinator/.venv/bin) so
 #   acceptance.drivers subprocesses shelled out via
 #   subprocess.run(shell=True) (e.g. the cli-pytest driver's `pytest
 #   tests/acceptance/{ms}`) resolve `pytest`/`python3` with the repo's
@@ -64,7 +64,7 @@ Type=simple
 # the structural fix — see the `coord health`/`coord doctor` unit_drift
 # check (#1831), which flags any unit whose PATH puts a `.venv/bin` entry
 # ahead of ~/.local/bin or ~/.coord-venv/bin.
-Environment=PATH=%h/.cargo/bin:%h/.local/bin:%h/src/claude-coordinator/.venv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
+Environment=PATH=%h/.cargo/bin:%h/.local/bin:%h/src/code-coordinator/.venv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
 ExecStart=%h/.coord-venv/bin/coord serve --config %h/.coord/coordinator.yml --host 0.0.0.0 --port 7435
 Restart=on-failure
 RestartSec=3

{code_coordinator-0.5.108 → code_coordinator-0.5.110}/coord/deploy/coord-web-dist-build.service

@@ -5,7 +5,7 @@
 # A systemd *user* unit, Type=oneshot, mirroring coord-drive-queue.service's
 # tick pattern (timer-fired, its own flock so a slow run can't stack).  Runs
 # deploy/coord-web-dist-build.sh, which:
-#   - fetches origin/main into ~/src/claude-coordinator (read-only — only
+#   - fetches origin/main into ~/src/code-coordinator (read-only — only
 #     `git fetch` + `rev-parse`, never touches that checkout's working tree
 #     or whatever branch an operator has it parked on),
 #   - builds coord/dashboard/webapp from that SHA inside a DEDICATED worktree

{code_coordinator-0.5.108/coord → code_coordinator-0.5.110}/deploy/coord-db-backup.service

@@ -46,7 +46,7 @@
 
 [Unit]
 Description=Snapshot coord.db to the external SSD (interim, pending #1822)
-Documentation=https://github.com/JDonaghy/claude-coordinator/issues/1822
+Documentation=https://github.com/JDonaghy/code-coordinator/issues/1822
 
 [Service]
 Type=oneshot

{code_coordinator-0.5.108 → code_coordinator-0.5.110}/deploy/coord-drive-queue.service

@@ -43,7 +43,7 @@
 #   pip show code-coordinator | grep -i editable     # must print NOTHING
 #
 # An editable checkout (e.g. elitebook's dev box, where ~/.local/bin/coord
-# points at ~/src/claude-coordinator) lets a worker's branch churn rewrite the
+# points at ~/src/code-coordinator) lets a worker's branch churn rewrite the
 # runner's own code out from under a live tick. Do not install this unit
 # there. See docs/DRIVE_QUEUE.md.
 #

{code_coordinator-0.5.108 → code_coordinator-0.5.110}/deploy/coord-serve.service

@@ -45,7 +45,7 @@ Type=simple
 #   error rather than a red suite — because a PATH= line here fixes this
 #   host and leaves the next one broken silently, which is the same failure
 #   shape as the bug. Keep both.
-# - #1117 added the repo venv (%h/src/claude-coordinator/.venv/bin) so
+# - #1117 added the repo venv (%h/src/code-coordinator/.venv/bin) so
 #   acceptance.drivers subprocesses shelled out via
 #   subprocess.run(shell=True) (e.g. the cli-pytest driver's `pytest
 #   tests/acceptance/{ms}`) resolve `pytest`/`python3` with the repo's
@@ -64,7 +64,7 @@ Type=simple
 # the structural fix — see the `coord health`/`coord doctor` unit_drift
 # check (#1831), which flags any unit whose PATH puts a `.venv/bin` entry
 # ahead of ~/.local/bin or ~/.coord-venv/bin.
-Environment=PATH=%h/.cargo/bin:%h/.local/bin:%h/src/claude-coordinator/.venv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
+Environment=PATH=%h/.cargo/bin:%h/.local/bin:%h/src/code-coordinator/.venv/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin
 ExecStart=%h/.coord-venv/bin/coord serve --config %h/.coord/coordinator.yml --host 0.0.0.0 --port 7435
 Restart=on-failure
 RestartSec=3

{code_coordinator-0.5.108 → code_coordinator-0.5.110}/deploy/coord-web-dist-build.service

@@ -5,7 +5,7 @@
 # A systemd *user* unit, Type=oneshot, mirroring coord-drive-queue.service's
 # tick pattern (timer-fired, its own flock so a slow run can't stack).  Runs
 # deploy/coord-web-dist-build.sh, which:
-#   - fetches origin/main into ~/src/claude-coordinator (read-only — only
+#   - fetches origin/main into ~/src/code-coordinator (read-only — only
 #     `git fetch` + `rev-parse`, never touches that checkout's working tree
 #     or whatever branch an operator has it parked on),
 #   - builds coord/dashboard/webapp from that SHA inside a DEDICATED worktree

{code_coordinator-0.5.108 → code_coordinator-0.5.110}/deploy/coord-web-dist-build.sh

@@ -25,7 +25,7 @@
 # once, THEN start/enable coord-web.
 #
 # Safe to run unattended on a timer (see coord-web-dist-build.timer): it
-# never touches ~/.coord-venv, ~/src/claude-coordinator's own checkout (it
+# never touches ~/.coord-venv, ~/src/code-coordinator's own checkout (it
 # uses a DEDICATED `git worktree`, so it can't collide with whatever branch
 # an operator has that checkout parked on — same reasoning as `coord drive`'s
 # worktree isolation), or any running coord-agent/coord-serve/coord-web
@@ -97,7 +97,7 @@
 set -uo pipefail
 
 SRC_ROOT="${SRC_ROOT:-$HOME/src}"
-REPO_NAME="${REPO_NAME:-claude-coordinator}"
+REPO_NAME="${REPO_NAME:-code-coordinator}"
 BASE_CHECKOUT="${BASE_CHECKOUT:-$SRC_ROOT/$REPO_NAME}"
 BRANCH="${BRANCH:-main}"
 

{code_coordinator-0.5.108 → code_coordinator-0.5.110}/docs/AGENT_OPERATIONS.md

@@ -227,7 +227,7 @@ Neither one leads reliably. Ask "can pip resolve it?", not "is it
 published?":
 
 ```bash
-curl -s https://pypi.org/simple/claude-coordinator/ | grep -q 'claude_coordinator-X\.Y\.Z' && echo installable
+curl -s https://pypi.org/simple/code-coordinator/ | grep -q 'code_coordinator-X\.Y\.Z' && echo installable
 ```
 
 Expect per-machine variation even after that: a mirror/resolver on one
@@ -311,10 +311,10 @@ version/PID first, then choose between a drift-fix and a plain
 On the target machine:
 
 ```bash
-curl -sSL https://raw.githubusercontent.com/JDonaghy/claude-coordinator/main/install-agent.sh | bash -s -- --machine <name> --port 7433
+curl -sSL https://raw.githubusercontent.com/JDonaghy/code-coordinator/main/install-agent.sh | bash -s -- --machine <name> --port 7433
 ```
 
-This creates `~/.coord-venv`, installs `claude-coordinator` from **PyPI**, writes a `coord-agent` systemd user unit, and starts it. The agent does NOT need a git clone of the repo — the `~/src/claude-coordinator` directory should only exist on the machine where you actually develop the coordinator itself.
+This creates `~/.coord-venv`, installs `code-coordinator` from **PyPI**, writes a `coord-agent` systemd user unit, and starts it. The agent does NOT need a git clone of the repo — the `~/src/claude-coordinator` directory should only exist on the machine where you actually develop the coordinator itself.
 
 Verify:
 
@@ -1116,7 +1116,7 @@ From the coordinator machine:
 coord agent update --all
 ```
 
-This POSTs to `/update` on every machine in `coordinator.yml`, telling each agent exactly which version the coordinator wants (`target_version`). Each agent pins its pip install to that exact release (`pip install --upgrade --no-cache-dir claude-coordinator==<target_version>`) and restarts.
+This POSTs to `/update` on every machine in `coordinator.yml`, telling each agent exactly which version the coordinator wants (`target_version`). Each agent pins its pip install to that exact release (`pip install --upgrade --no-cache-dir code-coordinator==<target_version>`) and restarts.
 
 **#1886: `target_version` is resolved from PyPI's simple index — the same source `pip install -U` itself resolves against — NOT from this CLI's own `__version__`.** A stale operator install (PyPI already has a newer release than the CLI running `coord agent update`) used to silently pin the whole fleet to that stale, older version while still printing a clean `✓` on every machine. If this CLI's own version is behind PyPI's latest, the command now prints a loud warning and targets the *newer* PyPI release instead — never its own age. Pass `--version X.Y.Z` to pin to something else on purpose (a rollback, a pre-release); that skips the PyPI lookup entirely.
 
@@ -1171,7 +1171,7 @@ same machine *and* from the editable CLI in `~/src/claude-coordinator`. It is
 upgraded by exactly one thing: someone remembering to do it.
 
 ```bash
-~/.coord-cli-venv/bin/pip install --upgrade --no-cache-dir claude-coordinator==X.Y.Z
+~/.coord-cli-venv/bin/pip install --upgrade --no-cache-dir code-coordinator==X.Y.Z
 ~/.coord-cli-venv/bin/coord --version    # verify — never infer from pip's exit code
 ```
 
@@ -1631,7 +1631,7 @@ echo "agent is on <new-version>"
 Behaviour worth knowing:
 
 - The endpoint **runs `pip install --upgrade --no-cache-dir
-  claude-coordinator`** (or `git pull --ff-only` for an editable
+  code-coordinator`** (or `git pull --ff-only` for an editable
   install) in a daemon-less background thread, then `os.execv`-restarts
   **only if the version actually changed**.
 - If the installed version is already current it records
@@ -1674,8 +1674,8 @@ When `last_update.mode` is `editable (git pull)`, the agent's venv has a `pip in
 
 ```bash
 ssh <host>
-~/.coord-venv/bin/pip uninstall -y claude-coordinator
-~/.coord-venv/bin/pip install --upgrade claude-coordinator
+~/.coord-venv/bin/pip uninstall -y code-coordinator
+~/.coord-venv/bin/pip install --upgrade code-coordinator
 XDG_RUNTIME_DIR=/run/user/$(id -u) systemctl --user restart coord-agent
 ```
 
@@ -1714,7 +1714,7 @@ If you have several editable installs to convert, you can script it (assumes SSH
 
 ```bash
 for host in precision elitebook dellserver; do
-  ssh $host '~/.coord-venv/bin/pip uninstall -y claude-coordinator && ~/.coord-venv/bin/pip install --upgrade claude-coordinator && XDG_RUNTIME_DIR=/run/user/$(id -u) systemctl --user restart coord-agent'
+  ssh $host '~/.coord-venv/bin/pip uninstall -y code-coordinator && ~/.coord-venv/bin/pip install --upgrade code-coordinator && XDG_RUNTIME_DIR=/run/user/$(id -u) systemctl --user restart coord-agent'
 done
 ```
 
@@ -1815,4 +1815,4 @@ chmod 600 ~/.ssh/authorized_keys   # on each agent
 
 For background on why rsync-over-SSH was chosen over direct HTTP download
 (signed URL vs key-auth tradeoffs, GC behaviour, TTL defaults), see the
-original design in [GitHub issue #305](https://github.com/JDonaghy/claude-coordinator/issues/305).
+original design in [GitHub issue #305](https://github.com/JDonaghy/code-coordinator/issues/305).

{code_coordinator-0.5.108 → code_coordinator-0.5.110}/docs/ARCHITECTURE.md

@@ -77,7 +77,7 @@ The `coord agent` server exposes a small, JSON-only HTTP API on port 7433. Any c
 | `GET  /stream/<id>` | Server-sent events: tails the worker log |
 | `POST /cancel/<id>` | Send SIGTERM to a running worker |
 | `POST /restart` | Restart the agent process (waits for active workers up to `cancel_timeout`) |
-| `POST /update` | `pip install --upgrade claude-coordinator` then re-exec |
+| `POST /update` | `pip install --upgrade code-coordinator` then re-exec |
 | `POST /worktree-clean` | Prune stale worktrees for completed assignments |
 
 Example: dispatch a worker with curl.
@@ -273,7 +273,7 @@ Two consequences worth stating plainly, because both have cost real work:
 - **It only runs on the `coord plan` → `coord approve` path.** The drive queue dispatches
   through `coord drive` → `coord assign` and never consults the brain, so unattended work —
   which is most work — got no overlap check at all. Both same-file collisions on
-  2026-08-14 (quadraui #306/#309 against #307/#308, and claude-coordinator #2234 against
+  2026-08-14 (quadraui #306/#309 against #307/#308, and code-coordinator #2234 against
   #2230, all four appending to a single file) arrived through the queue.
 
 `claim.py` does not close this gap: it is issue-level only (an active board assignment, or

{code_coordinator-0.5.108 → code_coordinator-0.5.110}/docs/CROSS_PLATFORM.md

@@ -1,7 +1,7 @@
 # Cross-Platform — porting coord to macOS & Windows
 
 > **Status:** design draft / RFC (2026-07-13). Captures the target architecture for running
-> claude-coordinator natively on macOS and Windows, and for the single-machine "just my laptop"
+> code-coordinator natively on macOS and Windows, and for the single-machine "just my laptop"
 > topology. Not committed direction — a thinking artifact to react to, decomposable into a milestone
 > when we pick it up.
 >

{code_coordinator-0.5.108 → code_coordinator-0.5.110}/docs/CUSTOMER_PORTAL.md

@@ -15,7 +15,7 @@
 A small, authenticated, public web site where a customer describes what they want, and later comes
 back to **review a design and sign off on it**. Sign-off produces an **outcome definition** — a
 plain-language acceptance contract — plus an epic/milestone decomposition, which is handed to
-claude-coordinator and driven by the existing `Work → Test → Review → Merge` pipeline. Progress
+code-coordinator and driven by the existing `Work → Test → Review → Merge` pipeline. Progress
 reports back in git-free language.
 
 The customer never sees git, never sees an issue number, and never talks to a live agent.
@@ -223,7 +223,7 @@ be resisted: it would buy obscurity in exchange for a second release lane.
 live in GitHub Actions secrets and `wrangler secret put` — never in `wrangler.toml`, never in a
 committed `.dev.vars`.
 
-**MIT.** Note the asymmetry, and that it is deliberate: `claude-coordinator` is **FSL-1.1-MIT**
+**MIT.** Note the asymmetry, and that it is deliberate: `code-coordinator` is **FSL-1.1-MIT**
 (source-available, no competing service for two years, then MIT), while the portal is permissive from
 day one. The portal is an intake and sign-off surface for a coordinator fleet — without one it is a
 form that talks to nothing. The defensible part is the pipeline it feeds (gates, oracle, review), and