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

coilyco-ops commented

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

Member

Problem

During the infrastructure#520 first-run acceptance loop, one engineer run produced residual work and the reaper preserved it on ward-salvage/infrastructure-b6103c7a instead of landing it.

The observed run happened to use the Goose harness, but this issue is harness-neutral. Do not implement this as a harness-name branch such as if harness == goose. The same close-trailer and residual-landing contract should apply through the shared agent/reaper path.

Evidence from infrastructure#523 on 2026-07-10 UTC:

Reaper status: WARD-REAP: reopened
Reason: missing same-repo closing reference
HEAD: a0060d9d88a1
origin/main: 6a8b1787722a
Working tree at reap time: Makefile, README.md, scripts/launch-ward-eval.sh, scripts/test-ward-eval.sh, scripts/ward-eval-executable.sh
The run log showed the model claimed the issue was complete, then reaper created a residual commit without a same-repo closing reference.

The backstop correctly avoided a false close, but the first-run flow still degrades: model work that should be landed becomes salvage, the issue remains open, and the director needs a human or another run to recover it.

Do

Inspect why the engineer reached reaper with dirty residual work instead of an intentional commit containing closes #523.
Fix the shared seed prompt, harness wrapper contract, or reaper path so same-repo issue work has a deterministic way to commit with a valid close trailer before teardown.
If the reaper creates a residual commit, make the failure message clearly distinguish agent did not commit from commit existed but lacked close trailer.
Do not weaken the safety gate: Ward must still refuse to close or land work that cannot be tied to the same repo issue.

Acceptance

A test or broker-level fixture covers an engineer run that modifies files and should land same-repo work.
The normal successful path produces a commit message with closes #N or equivalent same-repo trailer before reaper landing.
Residual dirty work without a close trailer still fails closed, but the diagnostics name the missing agent commit or close-trailer cause precisely.
A repeat of the infrastructure#523 shape would either land with a valid close trailer or produce a clearer failure without implying the issue was complete.
The implementation is harness-neutral and does not special-case one harness by name.
ward exec test passes, or the issue comment names the exact failing check.

Decision for headless carry

Kai confirmed the title and implementation prompt must stay harness-neutral so engineers do not hardcode incorrect harness switches.

## Problem During the infrastructure#520 first-run acceptance loop, one engineer run produced residual work and the reaper preserved it on `ward-salvage/infrastructure-b6103c7a` instead of landing it. The observed run happened to use the Goose harness, but this issue is harness-neutral. Do not implement this as a harness-name branch such as `if harness == goose`. The same close-trailer and residual-landing contract should apply through the shared agent/reaper path. Evidence from infrastructure#523 on 2026-07-10 UTC: * Reaper status: `WARD-REAP: reopened` * Reason: `missing same-repo closing reference` * HEAD: `a0060d9d88a1` * origin/main: `6a8b1787722a` * Working tree at reap time: `Makefile`, `README.md`, `scripts/launch-ward-eval.sh`, `scripts/test-ward-eval.sh`, `scripts/ward-eval-executable.sh` * The run log showed the model claimed the issue was complete, then reaper created a residual commit without a same-repo closing reference. The backstop correctly avoided a false close, but the first-run flow still degrades: model work that should be landed becomes salvage, the issue remains open, and the director needs a human or another run to recover it. ## Do * Inspect why the engineer reached reaper with dirty residual work instead of an intentional commit containing `closes #523`. * Fix the shared seed prompt, harness wrapper contract, or reaper path so same-repo issue work has a deterministic way to commit with a valid close trailer before teardown. * If the reaper creates a residual commit, make the failure message clearly distinguish `agent did not commit` from `commit existed but lacked close trailer`. * Do not weaken the safety gate: Ward must still refuse to close or land work that cannot be tied to the same repo issue. ## Acceptance * A test or broker-level fixture covers an engineer run that modifies files and should land same-repo work. * The normal successful path produces a commit message with `closes #N` or equivalent same-repo trailer before reaper landing. * Residual dirty work without a close trailer still fails closed, but the diagnostics name the missing agent commit or close-trailer cause precisely. * A repeat of the infrastructure#523 shape would either land with a valid close trailer or produce a clearer failure without implying the issue was complete. * The implementation is harness-neutral and does not special-case one harness by name. * `ward exec test` passes, or the issue comment names the exact failing check. ## Decision for headless carry Kai confirmed the title and implementation prompt must stay harness-neutral so engineers do not hardcode incorrect harness switches. Related: coilyco-flight-deck/infrastructure#520, coilyco-flight-deck/infrastructure#523, and coilyco-flight-deck/ward#990.

coilyco-ops added the

headless

P2

labels

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

coilyco-ops commented

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

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T09:31:49Z). 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#993 · branch issue-993 · harness codex · workflow pull-requests-and-merge
Run: engineer-codex-ward-993 · ward v0.573.0 · dispatched 2026-07-10T09:31:49Z
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.573.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-993` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T09:31:49Z). 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#993` · branch `issue-993` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-993` · ward `v0.573.0` · dispatched `2026-07-10T09:31:49Z` - **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.573.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-10 09:48:22 +00:00

fix: distinguish Goose residual commit states

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

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

fix: distinguish Goose residual commit states #997

coilyco-ops commented

2026-07-10 09:51:36 +00:00

Author

Member

ward exec test still fails in this container. cmd/ward/setup_test.go and cmd/ward/smartdefaults_test.go report that WARD_CONFIG_REF stays at the baked neutral default instead of pointing at the coilyco bundle for coilyco-flight-deck/ward. Action: investigate ward exec config-source bootstrap so repo verbs see the coilyco bundle.

coilyco-ops referenced this issue from a commit

2026-07-10 10:03:35 +00:00

fix: distinguish Goose residual commit states

coilyco-ops referenced this issue

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

Replace closed-unmerged dirty-only Goose residual landing PR #1006

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

coilyco-ops commented

2026-07-15 01:12:35 +00:00

Author

Member

WARDED_WORKFLOW: reservation-held

reservation details

Holder: launch intent for container engineer-codex-ward-993 on host kais-macbook-pro-2.local.

Accepted by ward agent --harness codex (reserved 2026-07-15T01:12:34Z). Concurrent ward agent runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). --override-reservation 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#993 · branch issue-993 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-993 · ward v0.693.0 · dispatched 2026-07-15T01:12:21Z
Comment thread: 1 included in the pre-flight read, 1 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-10T09:51:36Z)
- stripped: @coilyco-ops (2026-07-10T09:31:50Z)

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

— Codex, via ward agent

WARDED_WORKFLOW: reservation-held <details><summary>reservation details</summary> Holder: launch intent for container `engineer-codex-ward-993` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness codex` (reserved 2026-07-15T01:12:34Z). Concurrent `ward agent` runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). `--override-reservation` 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#993` · branch `issue-993` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-993` · ward `v0.693.0` · dispatched `2026-07-15T01:12:21Z` - **Comment thread:** 1 included in the pre-flight read, 1 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T09:51:36Z) - stripped: @coilyco-ops (2026-07-10T09:31:50Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.693.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-15 01:27:54 +00:00

Fix Goose residual close-trailer repair

~~coilyco-ops referenced this issue 2026-07-15 01:28:16 +00:00~~

Fix Goose residual close-trailer repair #1298

coilyco-ops commented

2026-07-15 01:31:01 +00:00

Author

Member

WARDED_WORKFLOW: failed ❌

details

workflow: pull-request-and-merge; review summary: skipped (temporary ward default pending brokered QA)

The Goose residual close-trailer path is fixed and the focused cmd/ward tests pass, but the repo-wide ward exec test gate still fails in this container on the pre-existing config-source and capability baseline: TestCapabilityGuardfilesExist, TestEngineerContainerLimitBelowAndAtLimit, TestBacklogRefreshReservationStates, TestSweepStaleContainerAssets, TestSweepStaleLaunchEnvFiles, TestOverrideForgejoCreateIssueAddsQuietFlag, TestForgejoGraftInventory, TestOverrideForgejoViewIssueSwapsLeaf, TestRunSetupWithUnsetRef, TestSmartDefaultsBaked, TestMountWardKdlExecMountsNewSurfaces.

Retrospective: the Goose fix felt straightforward once the wrong salvage gates were isolated. The blocker is external to this patch. Confidence: medium. Follow-up: fix the bundle/config-source baseline so ward exec test can turn green.

WARDED_WORKFLOW: failed ❌ <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skipped (temporary ward default pending brokered QA) The Goose residual close-trailer path is fixed and the focused `cmd/ward` tests pass, but the repo-wide `ward exec test` gate still fails in this container on the pre-existing config-source and capability baseline: `TestCapabilityGuardfilesExist`, `TestEngineerContainerLimitBelowAndAtLimit`, `TestBacklogRefreshReservationStates`, `TestSweepStaleContainerAssets`, `TestSweepStaleLaunchEnvFiles`, `TestOverrideForgejoCreateIssueAddsQuietFlag`, `TestForgejoGraftInventory`, `TestOverrideForgejoViewIssueSwapsLeaf`, `TestRunSetupWithUnsetRef`, `TestSmartDefaultsBaked`, `TestMountWardKdlExecMountsNewSurfaces`. Retrospective: the Goose fix felt straightforward once the wrong salvage gates were isolated. The blocker is external to this patch. Confidence: medium. Follow-up: fix the bundle/config-source baseline so `ward exec test` can turn green. </details>

coilyco-ops added this to the warded control plane coherence milestone

2026-07-15 05:14:56 +00:00

coilyco-ops changed title from ~~Ensure Goose engineer residual work can land instead of salvaging for missing close trailers~~ to Ensure engineer residual work can land instead of salvaging for missing close trailers

2026-07-15 06:51:26 +00:00

coilyco-ops commented

2026-07-15 07:16:32 +00:00

Author

Member

WARD-TRIAGE: warded control plane coherence milestone

This issue is part of the warded control plane coherence sprint. The release thesis is to make warded feel like one dependable control plane for agent work: higher safe parallelism, coherent config defaults, reliable broker/container behavior, human-feedback gates, and enough structured evidence for the next actor after a paused or failed run.

For this sprint, headless means an engineer should be able to carry the issue from current issue context to a merged change without new human decisions. If the issue discovers a missing decision, split or demote the unclear part instead of guessing.

WARD-TRIAGE: warded control plane coherence milestone This issue is part of the `warded control plane coherence` sprint. The release thesis is to make `warded` feel like one dependable control plane for agent work: higher safe parallelism, coherent config defaults, reliable broker/container behavior, human-feedback gates, and enough structured evidence for the next actor after a paused or failed run. For this sprint, `headless` means an engineer should be able to carry the issue from current issue context to a merged change without new human decisions. If the issue discovers a missing decision, split or demote the unclear part instead of guessing.

coilyco-ops commented

2026-07-15 13:22:44 +00:00

Author

Member

WARDED_WORKFLOW: reservation-held

reservation details

Holder: launch intent for container engineer-codex-ward-993 on host 74a70515a491.

Accepted by ward agent --harness codex (reserved 2026-07-15T13:22:43Z). Concurrent ward agent runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). --override-reservation 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#993 · branch issue-993 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-993 · ward v0.767.0 · dispatched 2026-07-15T13:22:39Z
Reservation: held
Comment thread: 3 included in the pre-flight read, 2 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-10T09:51:36Z), @coilyco-ops (2026-07-15T01:31:01Z), @coilyco-ops (2026-07-15T07:16:32Z)
- stripped: @coilyco-ops (2026-07-10T09:31:50Z), @coilyco-ops (2026-07-15T01:12:35Z)

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

— Codex, via ward agent

WARDED_WORKFLOW: reservation-held <details><summary>reservation details</summary> Holder: launch intent for container `engineer-codex-ward-993` on host `74a70515a491`. Accepted by `ward agent --harness codex` (reserved 2026-07-15T13:22:43Z). Concurrent `ward agent` runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). `--override-reservation` 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#993` · branch `issue-993` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-993` · ward `v0.767.0` · dispatched `2026-07-15T13:22:39Z` - **Reservation:** held - **Comment thread:** 3 included in the pre-flight read, 2 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T09:51:36Z), @coilyco-ops (2026-07-15T01:31:01Z), @coilyco-ops (2026-07-15T07:16:32Z) - stripped: @coilyco-ops (2026-07-10T09:31:50Z), @coilyco-ops (2026-07-15T01:12:35Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.767.0). </details> </details>  — Codex, via `ward agent`

Rows
Columns

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

Problem

Do

Acceptance

Decision for headless carry