Make Goose engineer runs terminate after final completion output

coilyco-ops commented

2026-07-10 09:29:25 +00:00

Member

Problem

During the infrastructure#520 first-run acceptance loop, engineer-goose-infrastructure-520 repeatedly printed final completion output but remained a running container more than 25 minutes after startup, with no WARD-OUTCOME comment and no reaper completion.

Observed on 2026-07-10 UTC from the director surface:

Run: engineer-goose-infrastructure-520
Started: 2026-07-10T09:03:12Z
Still running at about 2026-07-10T09:28Z
Log tail includes final messages such as Issue #520 IMPLEMENTATION COMPLETE, All requirements satisfied and implementation complete, and file verification output.
The issue remained reserved, with no completed Ward outcome.

For the Ward first-run flow, a Goose engineer that reaches a terminal answer but keeps the container alive is a hard reliability bug. It burns capacity, leaves reservations held, prevents the reaper from landing or failing the work, and makes the director unable to tell completion from a hung session.

Do

Inspect the Goose harness launch/stdio mode and determine why terminal model output does not exit the process.
Make headless Goose engineer runs exit cleanly after a final response, or add an explicit Ward-side termination condition that is safe and deterministic.
Ensure normal reaper handling still runs after Goose exits.
Preserve failure behavior: if Goose exits nonzero or times out before a valid outcome, Ward should report failure rather than success.
Add logging or audit evidence that distinguishes model produced final answer from process exited and reaper ran.

Acceptance

A Goose engineer fixture or integration test proves a terminal completion path exits the container and reaches reaper handling.
A hanging Goose process is timed out or classified clearly, without holding the reservation indefinitely.
The issue gets either a normal WARD-OUTCOME or a failure/deferred comment instead of staying silently reserved.
warded list no longer shows a Goose run as running long after its final answer has been emitted.
ward exec test passes, or the issue comment names the exact failing check.

## Problem During the infrastructure#520 first-run acceptance loop, `engineer-goose-infrastructure-520` repeatedly printed final completion output but remained a running container more than 25 minutes after startup, with no `WARD-OUTCOME` comment and no reaper completion. Observed on 2026-07-10 UTC from the director surface: * Run: `engineer-goose-infrastructure-520` * Started: `2026-07-10T09:03:12Z` * Still running at about `2026-07-10T09:28Z` * Log tail includes final messages such as `Issue #520 IMPLEMENTATION COMPLETE`, `All requirements satisfied and implementation complete`, and file verification output. * The issue remained reserved, with no completed Ward outcome. For the Ward first-run flow, a Goose engineer that reaches a terminal answer but keeps the container alive is a hard reliability bug. It burns capacity, leaves reservations held, prevents the reaper from landing or failing the work, and makes the director unable to tell completion from a hung session. ## Do * Inspect the Goose harness launch/stdio mode and determine why terminal model output does not exit the process. * Make headless Goose engineer runs exit cleanly after a final response, or add an explicit Ward-side termination condition that is safe and deterministic. * Ensure normal reaper handling still runs after Goose exits. * Preserve failure behavior: if Goose exits nonzero or times out before a valid outcome, Ward should report failure rather than success. * Add logging or audit evidence that distinguishes `model produced final answer` from `process exited and reaper ran`. ## Acceptance * A Goose engineer fixture or integration test proves a terminal completion path exits the container and reaches reaper handling. * A hanging Goose process is timed out or classified clearly, without holding the reservation indefinitely. * The issue gets either a normal `WARD-OUTCOME` or a failure/deferred comment instead of staying silently reserved. * `warded list` no longer shows a Goose run as running long after its final answer has been emitted. * `ward exec test` passes, or the issue comment names the exact failing check. Related: coilyco-flight-deck/infrastructure#520 and coilyco-flight-deck/ward#978.

coilyco-ops added the

headless

P1

labels

2026-07-10 09:29:25 +00:00

coilyco-ops commented

2026-07-10 09:29:35 +00:00

Author

Member

WARD-DISPATCH: deferred ⏸

deferred details

This forwarded dispatch was deferred after the issue was already reserved.

Attempted harness: codex
Attempted run: ward agent engineer coilyco-flight-deck/ward#990 --harness codex --ward-version v0.573.0
Container: engineer-codex-ward-990
Container created: no running engineer was observed.
Host log: /Users/kai/.ward/agent-logs/dispatch/20260710T092933Z-director-codex-vg55-coilyco-flight-deck-ward-990.log
Capacity: ward agent engineer --harness codex: global engineer limit is reached: 12 running (limit 12); wait for a run to finish or run ward agent reap for stale engineers

Retry: the issue stays queued and the director will try again when a slot opens.

— Codex, via ward agent

WARD-DISPATCH: deferred ⏸ <details><summary>deferred details</summary> This forwarded dispatch was deferred after the issue was already reserved. Attempted harness: `codex` Attempted run: `ward agent engineer coilyco-flight-deck/ward#990 --harness codex --ward-version v0.573.0` Container: `engineer-codex-ward-990` Container created: no running engineer was observed. Host log: `/Users/kai/.ward/agent-logs/dispatch/20260710T092933Z-director-codex-vg55-coilyco-flight-deck-ward-990.log` Capacity: `ward agent engineer --harness codex: global engineer limit is reached: 12 running (limit 12); wait for a run to finish or run `ward agent reap` for stale engineers` Retry: the issue stays queued and the director will try again when a slot opens. </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue

2026-07-10 09:31:40 +00:00

Ensure engineer residual work can land instead of salvaging for missing close trailers #993

coilyco-ops commented

2026-07-10 09:32:03 +00:00

Author

Member

WARD-DISPATCH: deferred ⏸

deferred details

This forwarded dispatch was deferred after the issue was already reserved.

Attempted harness: codex
Attempted run: ward agent engineer coilyco-flight-deck/ward#990 --harness codex --ward-version v0.573.0 --force
Container: engineer-codex-ward-990
Container created: no running engineer was observed.
Host log: /Users/kai/.ward/agent-logs/dispatch/20260710T093159Z-director-codex-vg55-coilyco-flight-deck-ward-990.log
Capacity: ward agent engineer --harness codex: global engineer limit is reached: 12 running (limit 12); wait for a run to finish or run ward agent reap for stale engineers

Retry: the issue stays queued and the director will try again when a slot opens.

— Codex, via ward agent

WARD-DISPATCH: deferred ⏸ <details><summary>deferred details</summary> This forwarded dispatch was deferred after the issue was already reserved. Attempted harness: `codex` Attempted run: `ward agent engineer coilyco-flight-deck/ward#990 --harness codex --ward-version v0.573.0 --force` Container: `engineer-codex-ward-990` Container created: no running engineer was observed. Host log: `/Users/kai/.ward/agent-logs/dispatch/20260710T093159Z-director-codex-vg55-coilyco-flight-deck-ward-990.log` Capacity: `ward agent engineer --harness codex: global engineer limit is reached: 12 running (limit 12); wait for a run to finish or run `ward agent reap` for stale engineers` Retry: the issue stays queued and the director will try again when a slot opens. </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-10 09:35:31 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T09:35:30Z). 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#990 · branch issue-990 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-990 · ward v0.573.0 · dispatched 2026-07-10T09:35:30Z
Comment thread: 2 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-10T09:29:35Z), @coilyco-ops (2026-07-10T09:32:03Z)

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-990` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T09:35:30Z). 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#990` · branch `issue-990` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-990` · ward `v0.573.0` · dispatched `2026-07-10T09:35:30Z` - **Comment thread:** 2 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T09:29:35Z), @coilyco-ops (2026-07-10T09:32:03Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.573.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue

2026-07-10 09:59:02 +00:00

Restore director-surface Docker socket access for reap and dispatch #1001

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

2026-07-10 10:05:20 +00:00

Make Goose engineer runs terminate after final completion output #1004

coilyco-ops referenced this issue

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

Replace closed-unmerged Goose termination PR with a landing fix #1005

coilyco-ops commented

2026-07-10 17:26:28 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T17:26:28Z). 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#990 · branch issue-990 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-990 · ward v0.584.0 · dispatched 2026-07-10T17:26:28Z
Comment thread: 2 included in the pre-flight read, 1 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-10T09:29:35Z), @coilyco-ops (2026-07-10T09:32:03Z)
- stripped: @coilyco-ops (2026-07-10T09:35:31Z)

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-990` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T17:26:28Z). 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#990` · branch `issue-990` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-990` · ward `v0.584.0` · dispatched `2026-07-10T17:26:28Z` - **Comment thread:** 2 included in the pre-flight read, 1 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T09:29:35Z), @coilyco-ops (2026-07-10T09:32:03Z) - stripped: @coilyco-ops (2026-07-10T09:35:31Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.584.0). </details> </details>  — Codex, via `ward agent`

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

2026-07-10 17:40:20 +00:00

fix goose completion watchdog #1060

coilyco-ops closed this issue

2026-07-10 18:08:51 +00:00

coilyco-ops commented

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

Author

Member

WARD-OUTCOME: merge-ready

details

workflow: pull-requests-and-merge; review summary: review gate skipped by ~/.ward/config.yaml default
felt: the change settled once the Goose exit watchdog and backlog feed split were aligned with the live Forgejo shape.
confidence: high.
surprise: main had moved far enough ahead that a merge-back was required before Forgejo would accept the PR.
follow-ups: none.

WARD-OUTCOME: merge-ready <details><summary>details</summary> workflow: pull-requests-and-merge; review summary: review gate skipped by `~/.ward/config.yaml` default felt: the change settled once the Goose exit watchdog and backlog feed split were aligned with the live Forgejo shape. confidence: high. surprise: `main` had moved far enough ahead that a merge-back was required before Forgejo would accept the PR. follow-ups: none. </details>

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

Rows
Columns

Make Goose engineer runs terminate after final completion output #990

Problem

Do

Acceptance