goose/opencode have no smoke gate and no documented failure path when the local Ollama endpoint is unreachable

coilyco-ops commented

2026-07-01 23:09:10 +00:00

Owner

Why

Persona: oss-agent-power-user, angle failure-paths. docs/agent-local-harnesses.md is a two-line stub index pointing at agent-opencode.md / agent-goose.md, with zero troubleshooting content of its own.

Both local-harness pages explicitly document the absence of any pre-launch check: agent-goose.md - "## Smoke gate: None. The launch is local-model only, so the GO/NO-GO read bows out." agent-opencode.md - "## Smoke gate: None. The model is local to the container, so dispatch proceeds without a host GO/NO-GO check." Compare to docs/agent-credentials.md's claude section, which documents a specific, deliberate failure mode and its handling: "A headless claude whose seeded credential cannot authenticate emits zero output and either exits 0 or blocks forever... Before launching the real agent the entrypoint probes claude -p once... on timeout or empty output it aborts the container with a clear error." No equivalent exists for goose/opencode - if the host has no Ollama running, or WARD_GOOSE_OLLAMA_HOST_B64 resolves to an unreachable address, the docs give no answer for what the dispatched container actually does: hang like the undetected-claude case the credentials doc describes as the exact failure mode a smoke gate exists to prevent, fail with an opaque error, or something else. docs/doctor.md also has no host-side Ollama reachability probe.

For the persona this sweep is built around checking symmetry for, this is the sharpest possible instance: claude gets a documented, deliberate anti-hang safeguard; the two OSS/local harnesses explicitly opt out of one, with no substitute failure-path documentation to compensate.

Deliverable

Either add a lightweight host-side Ollama-reachability probe (mirroring the claude auth smoke test's intent, gated similarly) to ward doctor or pre-dispatch, or - at minimum - document what actually happens today when Ollama is unreachable for a goose/opencode dispatch, so a user can recognize and recover from it without guessing.

Done condition

A user whose local Ollama endpoint is down before a warded goose (or opencode) run gets a documented, recognizable failure signal instead of an undocumented hang or opaque error.

Severity: major-friction · persona: oss-agent-power-user · angle: failure-paths
Filed by Claude Code during a cold-read release pressure test (run 23).

## Why Persona: `oss-agent-power-user`, angle `failure-paths`. `docs/agent-local-harnesses.md` is a two-line stub index pointing at `agent-opencode.md` / `agent-goose.md`, with zero troubleshooting content of its own. Both local-harness pages explicitly document the absence of any pre-launch check: `agent-goose.md` - "## Smoke gate: None. The launch is local-model only, so the GO/NO-GO read bows out." `agent-opencode.md` - "## Smoke gate: None. The model is local to the container, so dispatch proceeds without a host GO/NO-GO check." Compare to `docs/agent-credentials.md`'s claude section, which documents a specific, deliberate failure mode and its handling: "A headless claude whose seeded credential cannot authenticate emits zero output and either exits 0 or blocks forever... Before launching the real agent the entrypoint probes `claude -p` once... on timeout or empty output it **aborts the container with a clear error**." No equivalent exists for goose/opencode - if the host has no Ollama running, or `WARD_GOOSE_OLLAMA_HOST_B64` resolves to an unreachable address, the docs give no answer for what the dispatched container actually does: hang like the undetected-claude case the credentials doc describes as the exact failure mode a smoke gate exists to prevent, fail with an opaque error, or something else. `docs/doctor.md` also has no host-side Ollama reachability probe. For the persona this sweep is built around checking symmetry for, this is the sharpest possible instance: claude gets a documented, deliberate anti-hang safeguard; the two OSS/local harnesses explicitly opt out of one, with no substitute failure-path documentation to compensate. ## Deliverable Either add a lightweight host-side Ollama-reachability probe (mirroring the claude auth smoke test's intent, gated similarly) to `ward doctor` or pre-dispatch, or - at minimum - document what actually happens today when Ollama is unreachable for a goose/opencode dispatch, so a user can recognize and recover from it without guessing. ## Done condition A user whose local Ollama endpoint is down before a warded goose (or opencode) run gets a documented, recognizable failure signal instead of an undocumented hang or opaque error. --- **Severity: major-friction** · persona: oss-agent-power-user · angle: failure-paths Filed by Claude Code during a cold-read release pressure test (run 23).

coilyco-ops added the

pressure-test

label

2026-07-01 23:09:10 +00:00

coilyco-ops referenced this issue

2026-07-01 23:09:28 +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:20 +00:00

coilyco-ops added the

labels

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

coilyco-ops commented

2026-07-01 23:58:53 +00:00

Author

Owner

DECISION - implement probe parity: the entrypoint probes the resolved Ollama endpoint once before launching goose/opencode and aborts the container with a clear error on unreachable, mirroring the claude credential probe. Plus a troubleshooting row (#447's index). Recorded by Claude Code (Fable) during the 2026-07-01 ward launch triage session with Kai.

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 02:21:53 +00:00

Author

Owner

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-487 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T02:21:51Z). 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-487` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T02:21:51Z). 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 02:42:53 +00:00

feat(agents): gate goose/opencode launch on ollama reachability (closes #487)

coilysiren closed this issue

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

coilysiren commented

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

Owner

WARD-OUTCOME: done - goose/opencode now get a pre-launch Ollama-reachability smoke gate (both the entrypoint and the Go LaunchGate), with the failure path documented.

Honest retro: this was a satisfying one because the shape was already latent in the codebase. claude's LaunchGate + smoke test gave me an exact template, and the agentsapi capability seam meant goose/opencode just needed to implement PreLaunchCheck and be feature-tested automatically. The recorded decision in the thread ("probe parity, abort on unreachable") matched where I'd landed before I read it, which was reassuring.

What fought back: the two-bootstrap-path reality. The live path is still entrypoint.sh (the Go bootstrap is opt-in), so the gate had to exist in both bash and Go to actually protect production and stay tested. The bash awk extraction bit me - -F': *' split http://tower:11434 at every colon and handed me http; caught it only by running the snippet in isolation. And the docs cap is unforgiving: FEATURES.md and agentsapi.md both sat one char under 4000, so I dropped the FEATURES bullet (the claude smoke test has none either - clean precedent) and kept the agentsapi row.

Confidence: high on the Go side (unit-tested against live/closed listeners) and the bash logic (simulated under set -euo pipefail). The one thing I did not exercise is a real dispatched goose/opencode container against a down tower - no Ollama or docker here - so the end-to-end abort is verified by construction, not by a live run.

Rough edges worth a follow-up: (1) the bash compose_opencode_config and launch case still gate on WARD_MODE = qwen while WARD_MODE is now canonical opencode - a pre-existing latent mismatch I gated defensively around but did not fix. (2) No ward doctor host-side probe yet; I put the gate at launch, which is the tighter mirror, but a doctor check would help before dispatch. Both are small and out of this issue's scope.

WARD-OUTCOME: done - goose/opencode now get a pre-launch Ollama-reachability smoke gate (both the entrypoint and the Go LaunchGate), with the failure path documented. Honest retro: this was a satisfying one because the shape was already latent in the codebase. claude's `LaunchGate` + smoke test gave me an exact template, and the `agentsapi` capability seam meant goose/opencode just needed to implement `PreLaunchCheck` and be feature-tested automatically. The recorded decision in the thread ("probe parity, abort on unreachable") matched where I'd landed before I read it, which was reassuring. What fought back: the two-bootstrap-path reality. The live path is still `entrypoint.sh` (the Go bootstrap is opt-in), so the gate had to exist in *both* bash and Go to actually protect production and stay tested. The bash `awk` extraction bit me - `-F': *'` split `http://tower:11434` at every colon and handed me `http`; caught it only by running the snippet in isolation. And the docs cap is unforgiving: `FEATURES.md` and `agentsapi.md` both sat one char under 4000, so I dropped the FEATURES bullet (the claude smoke test has none either - clean precedent) and kept the agentsapi row. Confidence: high on the Go side (unit-tested against live/closed listeners) and the bash logic (simulated under `set -euo pipefail`). The one thing I did *not* exercise is a real dispatched goose/opencode container against a down tower - no Ollama or docker here - so the end-to-end abort is verified by construction, not by a live run. Rough edges worth a follow-up: (1) the bash `compose_opencode_config` and launch case still gate on `WARD_MODE = qwen` while `WARD_MODE` is now canonical `opencode` - a pre-existing latent mismatch I gated defensively around but did not fix. (2) No `ward doctor` host-side probe yet; I put the gate at launch, which is the tighter mirror, but a doctor check would help before dispatch. Both are small and out of this issue's scope.

coilysiren referenced this issue

2026-07-02 02:45:33 +00:00

container bootstrap: bash opencode path still gates on WARD_MODE=qwen (canonical is opencode) #498

coilysiren referenced this issue

2026-07-02 02:45:38 +00:00

ward doctor: host-side Ollama-reachability probe for goose/opencode dispatch #499

coilysiren referenced this issue

2026-07-02 02:45:45 +00:00

advance the aos documentation-layout pin so the per-file caps bind (post-#427), narrow the README exclude #500

coilyco-ops referenced this issue

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

Externalize infra topology hardcoded in ward: hosts, SSM, registry, telemetry (audit bucket C) #395