Goose engineer can answer in logs and exit clean without carrying the issue #697

New issue

Closed

opened 2026-07-08 20:54:00 +00:00 by coilyco-ops · 1 comment

coilyco-ops commented

2026-07-08 20:54:00 +00:00

Member

Bug

A Goose engineer can reach the task prompt, produce a plausible advisory answer in the container log, then exit with no file changes, no commit, and no issue comment. The reaper finds a clean tree, so the tracker still looks reserved/in-flight until a human reads Docker logs.

Concrete run

engineer-goose-ward-692 was dispatched for coilyco-flight-deck/ward#692 after Claude, Codex, and OpenCode launch paths failed. Goose booted far enough to analyze the issue, but instead of carrying the implementation it wrote an advisory response to the container log:

## Problem Summary

The opencode harness is correctly implemented in ward as a supported agent (it appears in the roster, CLI choices, documentation), but the dev-base Docker image doesn't include the opencode binary itself.
...
But since I can't modify files in the base system directly through this command context, I can create the correct documentation for fixing the issue:

Then the reaper ran:

ward container reap: residual status snapshot for /workspace/ward: ""
ward container reap: residual commit count against origin/main = 0
ward container reap: nothing to reap (tree clean, HEAD on origin/main)

No work landed and no failure/outcome comment was posted to the issue.

Expected behavior

An engineer harness should either carry the issue through code changes and landing, or fail in a way ward can surface back to the issue. A pure advisory answer in logs should not count as a successful engineer run, and it should not leave only a reservation comment behind.

Do

Inspect the Goose launch/oneshot prompt shape for engineer runs.
Determine why Goose believed it could only provide documentation/advice instead of editing the workspace.
Tighten the Goose engineer seed or launch mode so it has an explicit implement/commit/push mandate and understands /workspace/<repo> is writable in engineer mode.
Add outcome detection for clean-tree/no-comment/no-commit engineer exits so ward marks the run as failed or no-op on the issue.
Integrate with coilyco-flight-deck/ward#689 so this class produces a visible failure comment.

Acceptance

A Goose engineer run that exits with no diff and no issue comment is surfaced as a failed/no-op run, not left as a live-looking reservation.
Goose engineer prompt/launch mode is adjusted so it attempts implementation when the workspace is writable.
Tests cover the clean-tree/no-outcome failure path where practical.
ward exec test passes.

Filed from the read-only director surface after Kai pasted the engineer-goose-ward-692 log snippet.

## Bug A Goose engineer can reach the task prompt, produce a plausible advisory answer in the container log, then exit with no file changes, no commit, and no issue comment. The reaper finds a clean tree, so the tracker still looks reserved/in-flight until a human reads Docker logs. ## Concrete run `engineer-goose-ward-692` was dispatched for coilyco-flight-deck/ward#692 after Claude, Codex, and OpenCode launch paths failed. Goose booted far enough to analyze the issue, but instead of carrying the implementation it wrote an advisory response to the container log: ```text ## Problem Summary The opencode harness is correctly implemented in ward as a supported agent (it appears in the roster, CLI choices, documentation), but the dev-base Docker image doesn't include the opencode binary itself. ... But since I can't modify files in the base system directly through this command context, I can create the correct documentation for fixing the issue: ``` Then the reaper ran: ```text ward container reap: residual status snapshot for /workspace/ward: "" ward container reap: residual commit count against origin/main = 0 ward container reap: nothing to reap (tree clean, HEAD on origin/main) ``` No work landed and no failure/outcome comment was posted to the issue. ## Expected behavior An engineer harness should either carry the issue through code changes and landing, or fail in a way ward can surface back to the issue. A pure advisory answer in logs should not count as a successful engineer run, and it should not leave only a reservation comment behind. ## Do * Inspect the Goose launch/oneshot prompt shape for engineer runs. * Determine why Goose believed it could only provide documentation/advice instead of editing the workspace. * Tighten the Goose engineer seed or launch mode so it has an explicit implement/commit/push mandate and understands `/workspace/<repo>` is writable in engineer mode. * Add outcome detection for clean-tree/no-comment/no-commit engineer exits so ward marks the run as failed or no-op on the issue. * Integrate with coilyco-flight-deck/ward#689 so this class produces a visible failure comment. ## Acceptance * A Goose engineer run that exits with no diff and no issue comment is surfaced as a failed/no-op run, not left as a live-looking reservation. * Goose engineer prompt/launch mode is adjusted so it attempts implementation when the workspace is writable. * Tests cover the clean-tree/no-outcome failure path where practical. * `ward exec test` passes. Filed from the read-only director surface after Kai pasted the `engineer-goose-ward-692` log snippet.

coilyco-ops referenced this issue from coilyco-flight-deck/agentic-os

2026-07-08 20:55:27 +00:00

Bake opencode into the dev-base image for ward engineers #342

coilyco-ops added the

headless

labels

2026-07-09 18:09:23 +00:00

coilyco-ops commented

2026-07-09 22:42:47 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

Holder: container engineer-codex-ward-697 on host kais-macbook-pro-2.local.

Reserved by ward agent --harness codex (reserved 2026-07-09T22:42:45Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h 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).

run seed context — what this run is carrying (ward#609)

Resolved: coilyco-flight-deck/ward#697 · branch issue-697 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-697 · ward v0.540.0 · dispatched 2026-07-09T22:42:45Z
Comment thread: 0 included in the pre-flight read, 0 stripped (ward's own automated comments).

Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.540.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-697` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T22:42:45Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (1h 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). <details><summary>run seed context — what this run is carrying (ward#609)</summary> - **Resolved:** `coilyco-flight-deck/ward#697` · branch `issue-697` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-697` · ward `v0.540.0` · dispatched `2026-07-09T22:42:45Z` - **Comment thread:** 0 included in the pre-flight read, 0 stripped (ward's own automated comments). Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.540.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a pull request that will close it,

2026-07-09 23:26:06 +00:00

Goose engineer can answer in logs and exit clean without carrying the issue #886

coilyco-ops referenced this issue

2026-07-10 00:49:21 +00:00

Repair ward PR merge queue from failed prior runs #903

coilyco-ops referenced this issue

2026-07-10 00:58:26 +00:00

Repair merge conflicts on PR #886 from its existing branch #917

coilyco-ops closed this issue

2026-07-10 06:25:45 +00:00