Local harness docs never explain how to use a non-Coily Ollama endpoint

coilyco-ops commented

2026-07-01 22:37:32 +00:00

Member

Why

Persona: oss-agent-power-user / angle docs-ia. This user runs goose/opencode/local models and is specifically evaluating the README promise that ward drives open harnesses, not just Claude/Codex.

Cold trail: README -> docs/agent.md -> docs/agent-local-harnesses.md -> docs/agent-goose.md / docs/agent-opencode.md -> docs/agent-host-net.md / docs/agent-ts-sidecar.md.

The docs name local harnesses, but they never give a bring-your-own-local-model path:

docs/agent-goose.md says ward resolves the host Ollama endpoint and seeds WARD_GOOSE_OLLAMA_HOST_B64, then composes GOOSE_PROVIDER, GOOSE_MODEL, and OLLAMA_HOST.
docs/agent-opencode.md says the config pins a local Ollama provider at $WARD_OLLAMA_URL with $WARD_QWEN_MODEL.
Neither page says how a user sets those values, what defaults are, whether localhost:11434 on the host works from the container, or how Docker Desktop users should reach their own Ollama.
The only concrete network docs for Ollama are Coily-specific: kai-tower-3026, mac-proxy, ward-tailnet, SSM, --aws, and ~/.aws mounts.

A local-model user therefore cannot tell whether ward supports their existing Ollama setup or only the author's tailnet tower. For this persona, that is the adoption question.

Deliverable

Add a public local-model setup path for goose/opencode, linked from docs/agent-local-harnesses.md and the per-driver pages. It should cover either:

the supported bring-your-own-Ollama configuration: env vars, defaults, Docker Desktop/native Linux networking, host.docker.internal or host-net behavior, model selection, and --print verification; or
an explicit current limitation that local harnesses only work against Coily's tower/tailnet setup today, with #395 as the implementation anchor.

Keep the Coily tower/tailnet docs as an advanced/internal route, not the only concrete local-model story.

Done condition

An OSS user with Ollama already running locally can read the public docs and know exactly what to set before launching warded --driver goose or warded --driver opencode, or can correctly decide that their setup is not supported yet before trying it.

Severity: adoption-fatal · persona: oss-agent-power-user · angle: docs-ia
Filed by Codex during a cold-read release pressure test (run 31).

## Why Persona: `oss-agent-power-user` / angle `docs-ia`. This user runs goose/opencode/local models and is specifically evaluating the README promise that ward drives open harnesses, not just Claude/Codex. Cold trail: README -> `docs/agent.md` -> `docs/agent-local-harnesses.md` -> `docs/agent-goose.md` / `docs/agent-opencode.md` -> `docs/agent-host-net.md` / `docs/agent-ts-sidecar.md`. The docs name local harnesses, but they never give a bring-your-own-local-model path: - `docs/agent-goose.md` says ward resolves the host Ollama endpoint and seeds `WARD_GOOSE_OLLAMA_HOST_B64`, then composes `GOOSE_PROVIDER`, `GOOSE_MODEL`, and `OLLAMA_HOST`. - `docs/agent-opencode.md` says the config pins a local Ollama provider at `$WARD_OLLAMA_URL` with `$WARD_QWEN_MODEL`. - Neither page says how a user sets those values, what defaults are, whether `localhost:11434` on the host works from the container, or how Docker Desktop users should reach their own Ollama. - The only concrete network docs for Ollama are Coily-specific: `kai-tower-3026`, `mac-proxy`, `ward-tailnet`, SSM, `--aws`, and `~/.aws` mounts. A local-model user therefore cannot tell whether ward supports their existing Ollama setup or only the author's tailnet tower. For this persona, that is the adoption question. ## Deliverable Add a public local-model setup path for goose/opencode, linked from `docs/agent-local-harnesses.md` and the per-driver pages. It should cover either: - the supported bring-your-own-Ollama configuration: env vars, defaults, Docker Desktop/native Linux networking, `host.docker.internal` or host-net behavior, model selection, and `--print` verification; or - an explicit current limitation that local harnesses only work against Coily's tower/tailnet setup today, with #395 as the implementation anchor. Keep the Coily tower/tailnet docs as an advanced/internal route, not the only concrete local-model story. ## Done condition An OSS user with Ollama already running locally can read the public docs and know exactly what to set before launching `warded --driver goose` or `warded --driver opencode`, or can correctly decide that their setup is not supported yet before trying it. --- **Severity: adoption-fatal** · persona: oss-agent-power-user · angle: docs-ia Filed by Codex during a cold-read release pressure test (run 31).

coilyco-ops added the

pressure-test

label

2026-07-01 22:37:32 +00:00

coilyco-ops referenced this issue

2026-07-01 22:38:15 +00:00

meta: release pressure-test run log (cold-read usability sweeps) #428

coilyco-ops added this to the ward launch milestone

2026-07-01 23:29:29 +00:00

coilyco-ops added the

headless

P1

labels

2026-07-01 23:30:23 +00:00

coilyco-ops referenced this issue

2026-07-02 00:01:42 +00:00

meta: jul 1st evening sprint - launch burndown session 1 #492

coilyco-ops commented

2026-07-02 03:02:48 +00:00

Author

Member

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-470 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T03:02:44Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-470` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T03:02:44Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilysiren referenced this issue from a commit

2026-07-02 03:14:15 +00:00

docs(agent): add a public bring-your-own-Ollama page for local harnesses

coilysiren closed this issue

2026-07-02 03:14:15 +00:00

coilysiren commented

2026-07-02 03:14:53 +00:00

Owner

WARD-OUTCOME: done - added docs/agent-local-model.md, the public bring-your-own-Ollama page, linked from the local-harness index, both driver pages, the drivers comparison, and the docs index.

This one turned out to be more code-read than doc-write. The honest answer wasn't discoverable from the prose - I had to trace it through the Go: the endpoint/model live in the embedded fleet manifest, wardEnv() never threads WARD_OLLAMA_URL/WARD_QWEN_MODEL from the host into the container, and fleet.local.kdl rejects the fleet block. That trio is what makes BYO-Ollama genuinely unsupported today rather than just undocumented, so the page had to say so plainly and anchor on #395.

The one thing that surprised me: there is a working route for a native-Linux user - --tailnet-mode host-net shares the host netns, so the baked-in localhost:11434 incidentally lands on their local Ollama. It's real but rough (model pinned to qwen3-coder:30b, --tailnet drags in --aws), so I documented it as the supported-today path with its caveats rather than overselling it.

Confident in the accuracy - every claim is grounded in the source I read, not the existing docs. Fights: the 80-line/4000-char doc cap forced two rounds of trimming (landed at 78 lines / 3997 chars), and I re-merged main twice because it moved under me mid-run. Possible follow-up: once #395 lands, this page needs a rewrite from limitation to how-to, and the ward#487 probe's recovery hint still names WARD_OLLAMA_URL as if it were host-settable, which is slightly misleading until then.

WARD-OUTCOME: done - added docs/agent-local-model.md, the public bring-your-own-Ollama page, linked from the local-harness index, both driver pages, the drivers comparison, and the docs index. This one turned out to be more code-read than doc-write. The honest answer wasn't discoverable from the prose - I had to trace it through the Go: the endpoint/model live in the embedded fleet manifest, `wardEnv()` never threads `WARD_OLLAMA_URL`/`WARD_QWEN_MODEL` from the host into the container, and `fleet.local.kdl` rejects the `fleet` block. That trio is what makes BYO-Ollama genuinely unsupported today rather than just undocumented, so the page had to say so plainly and anchor on #395. The one thing that surprised me: there *is* a working route for a native-Linux user - `--tailnet-mode host-net` shares the host netns, so the baked-in `localhost:11434` incidentally lands on their local Ollama. It's real but rough (model pinned to qwen3-coder:30b, `--tailnet` drags in `--aws`), so I documented it as the supported-today path with its caveats rather than overselling it. Confident in the accuracy - every claim is grounded in the source I read, not the existing docs. Fights: the 80-line/4000-char doc cap forced two rounds of trimming (landed at 78 lines / 3997 chars), and I re-merged main twice because it moved under me mid-run. Possible follow-up: once #395 lands, this page needs a rewrite from limitation to how-to, and the ward#487 probe's recovery hint still names `WARD_OLLAMA_URL` as if it were host-settable, which is slightly misleading until then.

coilysiren referenced this issue

2026-07-02 08:46:15 +00:00

fix(director): defer dispatch-time infra failures instead of parking them failed (backlog wedge) #524

coilysiren referenced this issue

2026-07-02 08:57:34 +00:00

fix(director): self-heal legacy dispatch-error strandings + give declines a distinct status (ward#524 follow-up) #527

coilysiren referenced this issue

2026-07-02 09:21:23 +00:00

director: heartbeat livelocks in a permanent DISPATCH: none hold on stale infra-failure history (no live forge-health probe) #528

coilysiren referenced this issue

2026-07-14 15:27:09 +00:00

director should emit colorized, space buffered, visually distinct messages about the categories of actions its performing on startup #1283