agent-compose: Windows load-point (~/.claude/CLAUDE.md) points at dead X:\projects-x path; role has no Windows root branch #445

New issue

Closed

opened 2026-07-03 02:18:12 +00:00 by coilysiren · 2 comments

coilysiren commented

2026-07-03 02:18:12 +00:00

Owner

Summary

On the Windows host, ~/.claude/CLAUDE.md (the ansible-managed agent-compose load-point) points at a dead path. It currently reads:

@X:/projects-x/coilyco-bridge/agentic-os-kai/AGENTS.md

The fleet checkout on Windows just moved from X:\projects-x to X:\projects (org dirs directly under the umbrella; projects-x is now empty). So the single @-include resolves to a nonexistent file and the entire Kai operating context (agentic-os-kai/AGENTS.md) silently fails to load into the session. Companion doc/script sweep for the move: coilyco-bridge/agentic-os-kai@51cf8d3.

Deeper: agent-compose has no Windows support

Re-converging won't fix it as-is, because the role isn't wired for Windows:

ansible/roles/agent-compose/defaults/main.yml roots every load-point at {{ ansible_facts['env'].HOME }}/projects/... with no OS branch (agent_compose_kai_root, agent_compose_aos_root, lines 3-4). On Windows HOME is C:\Users\firem, so that computes C:\Users\firem\projects\... — but Kai's checkouts live on the X: drive (X:\projects), not under the home dir.
There is no windows group_vars (ansible/inventory/group_vars/ has base/personal/work + linux.yml, mac.yml only), so no place currently overrides the projects root for the X: drive.
The live X:/projects-x/... value therefore was not produced by this role on Windows (the role would emit C:\Users\firem/projects/...); it's a hand-written / stale artifact now pointing at the abandoned root.

Proposed fix

Make the agent-compose projects root OS-branched and overridable — e.g. a windows group_vars setting the root to X:\projects (default), feeding agent_compose_kai_root / agent_compose_aos_root. Mirrors how agentic-os-pin-converge already parameterizes aos_pin_projects_root ({{ HOME }}/projects, env-overridable via AOS_PIN_PROJECTS_ROOT).
Regenerate ~/.claude/CLAUDE.md on the Windows host so the load-point resolves to X:\projects\coilyco-bridge\agentic-os-kai\AGENTS.md.
Until Windows is wired in, the Windows ~/.claude/CLAUDE.md must be hand-maintained; note that in the role/README so it isn't assumed converged.

Context

The path move (projects-x -> projects) also touched the repo-root helpers and docs in agentic-os-kai (up-to-date.py, repo-tests.py, merge-*.py, kai-windows-env, etc.), landed in coilyco-bridge/agentic-os-kai@51cf8d3.
Shell startup cwd on the host (~/.bashrc + both PowerShell $PROFILEs) already repointed to X:\projects.

## Summary On the Windows host, `~/.claude/CLAUDE.md` (the ansible-managed agent-compose load-point) points at a dead path. It currently reads: ``` @X:/projects-x/coilyco-bridge/agentic-os-kai/AGENTS.md ``` The fleet checkout on Windows just moved from `X:\projects-x` to `X:\projects` (org dirs directly under the umbrella; `projects-x` is now empty). So the single `@`-include resolves to a nonexistent file and the entire Kai operating context (`agentic-os-kai/AGENTS.md`) silently fails to load into the session. Companion doc/script sweep for the move: coilyco-bridge/agentic-os-kai@51cf8d3. ## Deeper: agent-compose has no Windows support Re-converging won't fix it as-is, because the role isn't wired for Windows: - `ansible/roles/agent-compose/defaults/main.yml` roots every load-point at `{{ ansible_facts['env'].HOME }}/projects/...` with no OS branch (`agent_compose_kai_root`, `agent_compose_aos_root`, lines 3-4). On Windows `HOME` is `C:\Users\firem`, so that computes `C:\Users\firem\projects\...` — but Kai's checkouts live on the **`X:` drive** (`X:\projects`), not under the home dir. - There is no `windows` group_vars (`ansible/inventory/group_vars/` has base/personal/work + `linux.yml`, `mac.yml` only), so no place currently overrides the projects root for the `X:` drive. - The live `X:/projects-x/...` value therefore was not produced by this role on Windows (the role would emit `C:\Users\firem/projects/...`); it's a hand-written / stale artifact now pointing at the abandoned root. ## Proposed fix 1. Make the agent-compose projects root OS-branched and overridable — e.g. a `windows` group_vars setting the root to `X:\projects` (default), feeding `agent_compose_kai_root` / `agent_compose_aos_root`. Mirrors how `agentic-os-pin-converge` already parameterizes `aos_pin_projects_root` (`{{ HOME }}/projects`, env-overridable via `AOS_PIN_PROJECTS_ROOT`). 2. Regenerate `~/.claude/CLAUDE.md` on the Windows host so the load-point resolves to `X:\projects\coilyco-bridge\agentic-os-kai\AGENTS.md`. 3. Until Windows is wired in, the Windows `~/.claude/CLAUDE.md` must be hand-maintained; note that in the role/README so it isn't assumed converged. ## Context - The path move (`projects-x` -> `projects`) also touched the repo-root helpers and docs in agentic-os-kai (up-to-date.py, repo-tests.py, merge-*.py, kai-windows-env, etc.), landed in coilyco-bridge/agentic-os-kai@51cf8d3. - Shell startup cwd on the host (`~/.bashrc` + both PowerShell `$PROFILE`s) already repointed to `X:\projects`.

coilyco-ops added the

consult

labels

2026-07-03 07:58:42 +00:00

coilyco-ops commented

2026-07-05 03:21:49 +00:00

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-infrastructure-445 on host KAI-DESKTOP-TOWER is carrying this issue (reserved 2026-07-05T03:21:41Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

Do not comment on or edit this issue to steer the run while it is reserved. The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a new issue, dispatched fresh — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-infrastructure-445` on host `KAI-DESKTOP-TOWER` is carrying this issue (reserved 2026-07-05T03:21:41Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides. **Do not comment on or edit this issue to steer the run while it is reserved.** The engineer seeded the body once at launch and never re-reads it, so a comment or edit reaches only human readers, never the running engineer. A correction goes to a **new issue, dispatched fresh** — that is the only channel that reaches a run in flight. Where the forge supports it, ward locks this conversation to make that a road-block rather than a convention (ward#494).  — Claude (she/her), via `ward agent`

coilysiren referenced this issue from a commit

2026-07-05 03:28:08 +00:00

fix(agent-compose): branch projects root per-OS, stage Windows X:/projects

coilysiren closed this issue

2026-07-05 03:28:08 +00:00

coilysiren commented

2026-07-05 03:29:35 +00:00

Author

Owner

WARD-OUTCOME: done - agent-compose kai/aos roots now branch off one agent_compose_projects_root knob, with a staged windows.yml override to X:/projects; pushed to main (335d62b), CI green, closes #445.

Honest retro: this one was more archaeology than surgery. The actual code change is tiny - one derived variable in defaults/main.yml - but the real work was reading enough of the inventory to know why the Windows path was dead and where the fix honestly belongs. The trap I nearly fell into was wiring sync.yml's group_by to form a windows group so windows.yml would actually converge. Reading further showed native-Windows ansible is a whole blocked foundation (#356, WinRM + ansible.windows), and the repo already has a precedent - fleet-reachability-tower-win - for staging Windows config ahead of that foundation with loud "do not live-apply" headers. So I matched that: windows.yml is committed but keyed to a group that never forms yet, and every doc says the Windows load-point stays hand-maintained until #356. That keeps the config honest instead of pretending Windows converges.

One thing fought back: pre-commit's pylint hook failed on a sandbox quirk (UV_PYTHON_INSTALL_DIR pointed at a root-owned /opt/uv/python), not my diff - I redirected it to a writable path and it passed clean, no --no-verify.

Confidence is high on the parts a machine can verify (ansible refactor is behavior-preserving on every Unix host, all catalog hooks + CI green). The one thing this container cannot close is step 2 of the issue - regenerating the actual ~/.claude/CLAUDE.md on the Windows host - because that box isn't reachable from here and has no converge path. That remains a hand-edit on the host, which is exactly what the docs now say. Worth a follow-up only when #356 lands: fold the windows group into group_by and drop the hand-maintenance note.

WARD-OUTCOME: done - agent-compose kai/aos roots now branch off one `agent_compose_projects_root` knob, with a staged `windows.yml` override to `X:/projects`; pushed to main (335d62b), CI green, closes #445. Honest retro: this one was more archaeology than surgery. The actual code change is tiny - one derived variable in `defaults/main.yml` - but the real work was reading enough of the inventory to know **why** the Windows path was dead and where the fix honestly belongs. The trap I nearly fell into was wiring `sync.yml`'s `group_by` to form a `windows` group so `windows.yml` would actually converge. Reading further showed native-Windows ansible is a whole blocked foundation (#356, WinRM + `ansible.windows`), and the repo already has a precedent - `fleet-reachability-tower-win` - for staging Windows config ahead of that foundation with loud "do not live-apply" headers. So I matched that: `windows.yml` is committed but keyed to a group that never forms yet, and every doc says the Windows load-point stays hand-maintained until #356. That keeps the config honest instead of pretending Windows converges. One thing fought back: pre-commit's pylint hook failed on a sandbox quirk (`UV_PYTHON_INSTALL_DIR` pointed at a root-owned `/opt/uv/python`), not my diff - I redirected it to a writable path and it passed clean, no `--no-verify`. Confidence is high on the parts a machine can verify (ansible refactor is behavior-preserving on every Unix host, all catalog hooks + CI green). The one thing this container **cannot** close is step 2 of the issue - regenerating the actual `~/.claude/CLAUDE.md` on the Windows host - because that box isn't reachable from here and has no converge path. That remains a hand-edit on the host, which is exactly what the docs now say. Worth a follow-up only when #356 lands: fold the `windows` group into `group_by` and drop the hand-maintenance note.