Goose docs disagree on whether detached runs get the GO/NO-GO preflight

coilyco-ops commented

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

Owner

Why

Persona: oss-agent-power-user / angle docs-ia. This user is comparing the OSS/local harnesses against the Claude path and needs to know which safety checks actually run.

Cold trail: docs/agent-local-harnesses.md -> docs/agent-goose.md -> docs/agent-preflight.md.

docs/agent-goose.md says the goose launch dialect has Host preflight: none and its smoke gate is None. But docs/agent-preflight.md says the detached GO/NO-GO gate runs for both full carry-to-merge harnesses, claude and goose, with goose answering via goose run -t.

Those cannot both be true. For an OSS/local-harness adopter, the difference is material: either goose has parity with Claude for the pre-launch GO/NO-GO decision, or goose dispatch proceeds without that safety read. The docs currently make the reader choose which page to believe.

Deliverable

Make the goose preflight story single-sourced and consistent. Either:

update docs/agent-goose.md to state the host preflight exists and link docs/agent-preflight.md; or
update docs/agent-preflight.md to remove goose from the parity claim and explain that goose dispatch currently proceeds without host preflight.

If the answer differs by role or launch mode, include that distinction explicitly in both places.

Done condition

A reader comparing docs/agent-goose.md and docs/agent-preflight.md gets one unambiguous answer to: "does warded --driver goose run the GO/NO-GO preflight before detached engineer dispatch?"

Severity: major-friction · 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 is comparing the OSS/local harnesses against the Claude path and needs to know which safety checks actually run. Cold trail: `docs/agent-local-harnesses.md` -> `docs/agent-goose.md` -> `docs/agent-preflight.md`. `docs/agent-goose.md` says the goose launch dialect has `Host preflight: none` and its smoke gate is `None`. But `docs/agent-preflight.md` says the detached GO/NO-GO gate runs for both full carry-to-merge harnesses, `claude and goose`, with goose answering via `goose run -t`. Those cannot both be true. For an OSS/local-harness adopter, the difference is material: either goose has parity with Claude for the pre-launch GO/NO-GO decision, or goose dispatch proceeds without that safety read. The docs currently make the reader choose which page to believe. ## Deliverable Make the goose preflight story single-sourced and consistent. Either: - update `docs/agent-goose.md` to state the host preflight exists and link `docs/agent-preflight.md`; or - update `docs/agent-preflight.md` to remove goose from the parity claim and explain that goose dispatch currently proceeds without host preflight. If the answer differs by role or launch mode, include that distinction explicitly in both places. ## Done condition A reader comparing `docs/agent-goose.md` and `docs/agent-preflight.md` gets one unambiguous answer to: "does `warded --driver goose` run the GO/NO-GO preflight before detached engineer dispatch?" --- **Severity: major-friction** · 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:38:05 +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:28 +00:00

coilyco-ops added the

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 02:59:32 +00:00

Author

Owner

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

docs(agent): single-source the goose GO/NO-GO preflight story

coilysiren closed this issue

2026-07-02 03:01:39 +00:00

coilysiren commented

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

Owner

WARD-OUTCOME: done - agent-goose.md's Launch dialect now states the GO/NO-GO preflight exists at parity with claude and single-sources through agent-preflight.md.

This one was less a doc edit than a fact-check. The trap was that agent-goose.md was already half-fixed: its Smoke gate section correctly claimed parity, but the Launch dialect bullet still flatly said Host preflight: none, so the page contradicted itself on top of contradicting agent-preflight.md. I didn't want to just pick the louder page, so I went to the code - hostPreflightArgv returns goose run -t <prompt>, true for modeGoose, right next to claude's -p slot - which settled it cleanly: goose does get the gate, agent-preflight.md was right, the stray bullet was the bug.

The one nuance worth carrying was that the gate keys on the dispatch being interactive while the run it gates is detached, and it honors the same skip rules as claude (scripted/piped, --print, --no-preflight). I folded that into the rewritten bullet so the answer stays unambiguous without a reader having to reconcile 'detached' with 'preflight'. Confident in the result - it's a docs-only change, pre-commit is green, and both pages now agree. No follow-ups; the codex/opencode 'no host one-shot yet' story is already documented and out of scope here.

WARD-OUTCOME: done - agent-goose.md's Launch dialect now states the GO/NO-GO preflight exists at parity with claude and single-sources through agent-preflight.md. This one was less a doc edit than a fact-check. The trap was that agent-goose.md was already half-fixed: its Smoke gate section correctly claimed parity, but the Launch dialect bullet still flatly said `Host preflight: none`, so the page contradicted *itself* on top of contradicting agent-preflight.md. I didn't want to just pick the louder page, so I went to the code - `hostPreflightArgv` returns `goose run -t <prompt>, true` for `modeGoose`, right next to claude's `-p` slot - which settled it cleanly: goose does get the gate, agent-preflight.md was right, the stray bullet was the bug. The one nuance worth carrying was that the gate keys on the *dispatch* being interactive while the *run* it gates is detached, and it honors the same skip rules as claude (scripted/piped, --print, --no-preflight). I folded that into the rewritten bullet so the answer stays unambiguous without a reader having to reconcile 'detached' with 'preflight'. Confident in the result - it's a docs-only change, pre-commit is green, and both pages now agree. No follow-ups; the codex/opencode 'no host one-shot yet' story is already documented and out of scope here.

coilyco-ops commented

2026-07-02 08:10:53 +00:00

Author

Owner

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-471 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T08:10:50Z). 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-471` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T08:10:50Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilyco-ops commented

2026-07-02 08:10:56 +00:00

Author

Owner

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-471 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T08:10:50Z). 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-471` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T08:10:50Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Claude (she/her), via `ward agent`

coilyco-ops commented

2026-07-02 08:11:00 +00:00

Author

Owner

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-471 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T08:10:50Z). 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-471` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T08:10:50Z). 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 commented

2026-07-02 08:13:17 +00:00

Owner

WARD-OUTCOME: done - goose preflight already single-sourced and verified consistent; both docs agree goose runs the GO/NO-GO gate at parity with claude.

Candid note: this run found the work already landed. A prior ward agent pass on this same issue (commit dbb9879, ~03:02 today) had already rewritten agent-goose.md's Launch dialect and Smoke gate to state the host preflight exists at parity with claude, and agent-preflight.md already named claude and goose together. This container was a duplicate re-dispatch (two reservation cycles on the thread, 02:59 and 08:10), landing on a closed, already-fixed issue.

Rather than fabricate a no-op closes #471 commit, I re-verified against the source of truth: internal/agents/goose/goose.go sets Preflight: {"goose","run","-t"} and PreflightArgv returns true, while codex/opencode return false. So the docs asserting parity are correct, not just internally agreed. I grepped every goose+preflight mention across docs/ (agent-goose.md, agent-preflight.md, agent-engineer.md all consistent; agent-local-harnesses.md only covers the separate Ollama reachability probe) and found no residual contradiction.

Done condition is met: a reader gets one unambiguous answer - yes, warded --driver goose runs the GO/NO-GO preflight before detached engineer dispatch when dispatched from a TTY, with the same skip rules as claude. No changes to make, tree clean, nothing to push. No follow-ups.

WARD-OUTCOME: done - goose preflight already single-sourced and verified consistent; both docs agree goose runs the GO/NO-GO gate at parity with claude. Candid note: this run found the work already landed. A prior `ward agent` pass on this same issue (commit dbb9879, ~03:02 today) had already rewritten agent-goose.md's Launch dialect and Smoke gate to state the host preflight exists at parity with claude, and agent-preflight.md already named claude and goose together. This container was a duplicate re-dispatch (two reservation cycles on the thread, 02:59 and 08:10), landing on a closed, already-fixed issue. Rather than fabricate a no-op `closes #471` commit, I re-verified against the source of truth: `internal/agents/goose/goose.go` sets `Preflight: {"goose","run","-t"}` and `PreflightArgv` returns true, while codex/opencode return false. So the docs asserting parity are correct, not just internally agreed. I grepped every goose+preflight mention across docs/ (agent-goose.md, agent-preflight.md, agent-engineer.md all consistent; agent-local-harnesses.md only covers the separate Ollama reachability probe) and found no residual contradiction. Done condition is met: a reader gets one unambiguous answer - yes, `warded --driver goose` runs the GO/NO-GO preflight before detached engineer dispatch when dispatched from a TTY, with the same skip rules as claude. No changes to make, tree clean, nothing to push. No follow-ups.

Rows
Columns

Goose docs disagree on whether detached runs get the GO/NO-GO preflight #471

Why

Deliverable

Done condition