Fix residual reap landing path that can push work without closing the carried issue

coilysiren commented

2026-07-02 06:30:59 +00:00

Owner

A Goose engineer run landed residual work on canonical main without the carried issue-closing reference, leaving the issue open even though the work pushed.

Observed case:

issue: coilyco-flight-deck/infrastructure#427
reservation posted at 2026-07-02T06:23:49Z
landed commit on infrastructure/main: 4412d7cbb690edb0624cf598937f2fcc5cc30261
commit subject: ward-container: residual goose work on coilyco-flight-deck/infrastructure
commit body contains only Co-Authored-By: Goose <goose@ward.agent> and no closes #427
infrastructure#427 remains open

Why this is a ward bug:

ward#511 was supposed to enforce that a carried run cannot land without the same-repo closes #<carried issue> reference
this run still reached canonical main through the residual reap path without closing the carried issue
so either the enforcement is missing on the residual path, or the host ran a path/version that bypassed it

Wanted outcome:

identify why a residual reap commit without closes #427 still landed on main after ward#511
fix the residual reap path so this cannot happen
if the real cause is stale host ward bits or a version-skew path, make that failure mode explicit and guarded rather than silent

Acceptance:

a residual-only carried run cannot land to canonical main unless the final landed history closes the exact carried issue
add a regression test for the exact residual commit shape observed here
document any version-skew/host-binary invariant if relevant

Context:

issue page: https://forgejo.coilysiren.me/coilyco-flight-deck/infrastructure/issues/427
landed commit: https://forgejo.coilysiren.me/coilyco-flight-deck/infrastructure/commit/4412d7cbb690edb0624cf598937f2fcc5cc30261

A Goose engineer run landed residual work on canonical `main` without the carried issue-closing reference, leaving the issue open even though the work pushed. Observed case: - issue: `coilyco-flight-deck/infrastructure#427` - reservation posted at `2026-07-02T06:23:49Z` - landed commit on `infrastructure/main`: `4412d7cbb690edb0624cf598937f2fcc5cc30261` - commit subject: `ward-container: residual goose work on coilyco-flight-deck/infrastructure` - commit body contains only `Co-Authored-By: Goose <goose@ward.agent>` and no `closes #427` - `infrastructure#427` remains open Why this is a ward bug: - `ward#511` was supposed to enforce that a carried run cannot land without the same-repo `closes #<carried issue>` reference - this run still reached canonical `main` through the residual reap path without closing the carried issue - so either the enforcement is missing on the residual path, or the host ran a path/version that bypassed it Wanted outcome: - identify why a residual reap commit without `closes #427` still landed on `main` after `ward#511` - fix the residual reap path so this cannot happen - if the real cause is stale host ward bits or a version-skew path, make that failure mode explicit and guarded rather than silent Acceptance: - a residual-only carried run cannot land to canonical `main` unless the final landed history closes the exact carried issue - add a regression test for the exact residual commit shape observed here - document any version-skew/host-binary invariant if relevant Context: - issue page: `https://forgejo.coilysiren.me/coilyco-flight-deck/infrastructure/issues/427` - landed commit: `https://forgejo.coilysiren.me/coilyco-flight-deck/infrastructure/commit/4412d7cbb690edb0624cf598937f2fcc5cc30261`

coilyco-ops commented

2026-07-02 06:31:09 +00:00

Owner

🔒 Reserved by ward agent --driver goose — container engineer-goose-ward-515 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-02T06:31:07Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); --force overrides.

— Goose, via ward agent

🔒 Reserved by `ward agent --driver goose` — container `engineer-goose-ward-515` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-02T06:31:07Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s TTL); `--force` overrides.  — Goose, via `ward agent`

coilyco-ops added the

labels

2026-07-02 07:04:15 +00:00

coilysiren commented

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

Author

Owner

Sibling bug filed as ward#518: the mirror image of this one on the same reap decision path. Where this issue is a run that landed residual work without closing its carried issue (false success), ward#518 is a run that landed and closed cleanly but got salvaged anyway (false failure) - four confirmed false-positive salvage branches tonight whose tips are already on main. Both live in reapTargetTree's gate ordering in cmd/ward/container_reap.go, so one coordinated fix should serve both. ward#518 is being dispatched now for the false-salvage + post-salvage-to-the-carried-issue change - coordinate / rebase rather than double-dispatch this file. Recorded by Claude (she/her) during the ward#492 burndown.

Sibling bug filed as ward#518: the mirror image of this one on the same reap decision path. Where this issue is a run that landed residual work *without* closing its carried issue (false success), ward#518 is a run that landed and closed cleanly but got *salvaged anyway* (false failure) - four confirmed false-positive salvage branches tonight whose tips are already on main. Both live in reapTargetTree's gate ordering in cmd/ward/container_reap.go, so one coordinated fix should serve both. ward#518 is being dispatched now for the false-salvage + post-salvage-to-the-carried-issue change - coordinate / rebase rather than double-dispatch this file. Recorded by Claude (she/her) during the ward#492 burndown.

coilysiren referenced this issue

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

Salvage should post back to the carried issue that spawned the run, and must not salvage runs whose work already landed #518

coilysiren commented

2026-07-06 18:59:35 +00:00

Author

Owner

Re-spec: the residual-path close-ref enforcement asked for here largely landed via #511/#518 (container_reap.go issueClosingReferencePresent gate + notifySalvage, with tests). Unverified as its own scope: the version-skew guard and an exact-residual-shape regression test. Re-scope to just those, or close if already covered. Re-triage 2026-07-06.

coilyco-ops added

and removed

labels

2026-07-07 22:45:47 +00:00

coilyco-ops commented

2026-07-07 22:46:03 +00:00

Owner

Cleared consult→headless (2026-07-07). Per the 2026-07-06 re-spec, the core landed via #511/#518; scope is now just two verifiable items: the version-skew guard and an exact-residual-shape regression test - or close if already covered. Verify-and-fill, headless engineer work. Dispatching. (Touches cmd/ward/container_reap.go - #595 is held behind this one to avoid a concurrent collision on that file.)

coilyco-ops referenced this issue

2026-07-07 22:46:03 +00:00

Engineer dispatch smoke-test-dies on KAI-SERVER and a death can orphan the issue - failover re-dispatch is not deterministic #595

coilyco-ops commented

2026-07-07 22:47:21 +00:00

Owner

🔒 Reserved by ward agent --driver claude — container engineer-claude-ward-515 on host KAI-DESKTOP-TOWER is carrying this issue (reserved 2026-07-07T22:47:16Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (2h0m0s 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#515 · branch issue-515 · driver claude · workflow direct-main
Run: engineer-claude-ward-515 · ward v0.422.0 · dispatched 2026-07-07T22:47:16Z
Comment thread: 3 included in the pre-flight read, 1 stripped (ward's own automated comments).
- included: @coilysiren (2026-07-02T07:33:55Z), @coilysiren (2026-07-06T18:59:35Z), @coilyco-ops (2026-07-07T22:46:03Z)
- stripped: @coilyco-ops (2026-07-02T06:31:09Z)

Issue body as seeded:

A Goose engineer run landed residual work on canonical `main` without the carried issue-closing reference, leaving the issue open even though the work pushed.

Observed case:
- issue: `coilyco-flight-deck/infrastructure#427`
- reservation posted at `2026-07-02T06:23:49Z`
- landed commit on `infrastructure/main`: `4412d7cbb690edb0624cf598937f2fcc5cc30261`
- commit subject: `ward-container: residual goose work on coilyco-flight-deck/infrastructure`
- commit body contains only `Co-Authored-By: Goose <goose@ward.agent>` and no `closes #427`
- `infrastructure#427` remains open

Why this is a ward bug:
- `ward#511` was supposed to enforce that a carried run cannot land without the same-repo `closes #<carried issue>` reference
- this run still reached canonical `main` through the residual reap path without closing the carried issue
- so either the enforcement is missing on the residual path, or the host ran a path/version that bypassed it

Wanted outcome:
- identify why a residual reap commit without `closes #427` still landed on `main` after `ward#511`
- fix the residual reap path so this cannot happen
- if the real cause is stale host ward bits or a version-skew path, make that failure mode explicit and guarded rather than silent

Acceptance:
- a residual-only carried run cannot land to canonical `main` unless the final landed history closes the exact carried issue
- add a regression test for the exact residual commit shape observed here
- document any version-skew/host-binary invariant if relevant

Context:
- issue page: `https://forgejo.coilysiren.me/coilyco-flight-deck/infrastructure/issues/427`
- landed commit: `https://forgejo.coilysiren.me/coilyco-flight-deck/infrastructure/commit/4412d7cbb690edb0624cf598937f2fcc5cc30261`

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

— Claude (she/her), via ward agent

🔒 Reserved by `ward agent --driver claude` — container `engineer-claude-ward-515` on host `KAI-DESKTOP-TOWER` is carrying this issue (reserved 2026-07-07T22:47:16Z). Concurrent `ward agent` runs are blocked until it finishes or the reservation goes stale (2h0m0s 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#515` · branch `issue-515` · driver `claude` · workflow `direct-main` - **Run:** `engineer-claude-ward-515` · ward `v0.422.0` · dispatched `2026-07-07T22:47:16Z` - **Comment thread:** 3 included in the pre-flight read, 1 stripped (ward's own automated comments). - included: @coilysiren (2026-07-02T07:33:55Z), @coilysiren (2026-07-06T18:59:35Z), @coilyco-ops (2026-07-07T22:46:03Z) - stripped: @coilyco-ops (2026-07-02T06:31:09Z) **Issue body as seeded:** ``` A Goose engineer run landed residual work on canonical `main` without the carried issue-closing reference, leaving the issue open even though the work pushed. Observed case: - issue: `coilyco-flight-deck/infrastructure#427` - reservation posted at `2026-07-02T06:23:49Z` - landed commit on `infrastructure/main`: `4412d7cbb690edb0624cf598937f2fcc5cc30261` - commit subject: `ward-container: residual goose work on coilyco-flight-deck/infrastructure` - commit body contains only `Co-Authored-By: Goose <goose@ward.agent>` and no `closes #427` - `infrastructure#427` remains open Why this is a ward bug: - `ward#511` was supposed to enforce that a carried run cannot land without the same-repo `closes #<carried issue>` reference - this run still reached canonical `main` through the residual reap path without closing the carried issue - so either the enforcement is missing on the residual path, or the host ran a path/version that bypassed it Wanted outcome: - identify why a residual reap commit without `closes #427` still landed on `main` after `ward#511` - fix the residual reap path so this cannot happen - if the real cause is stale host ward bits or a version-skew path, make that failure mode explicit and guarded rather than silent Acceptance: - a residual-only carried run cannot land to canonical `main` unless the final landed history closes the exact carried issue - add a regression test for the exact residual commit shape observed here - document any version-skew/host-binary invariant if relevant Context: - issue page: `https://forgejo.coilysiren.me/coilyco-flight-deck/infrastructure/issues/427` - landed commit: `https://forgejo.coilysiren.me/coilyco-flight-deck/infrastructure/commit/4412d7cbb690edb0624cf598937f2fcc5cc30261` ``` Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.422.0). </details>  — Claude (she/her), via `ward agent`

coilyco-ops referenced this issue from a commit

2026-07-07 22:56:23 +00:00

fix(reap): re-check closing ref at the push site so residual work can't land unclosed

coilyco-ops closed this issue

2026-07-07 22:56:23 +00:00

coilyco-ops commented

2026-07-07 22:57:09 +00:00

Owner

WARD-OUTCOME: done - push-site closing-ref recheck + exact-residual-shape regression test + version-skew invariant doc, landed on main as 343abb5.

Retrospective, in my own voice:

This one was mostly a diagnosis job, and the re-spec comments here were dead on. The core closing-ref enforcement genuinely did already land via #511/#518 — I traced reapTargetTree line by line and the exact infrastructure#427 shape (residual commit, subject + Co-Authored-By, no closes) already salvages on current main. So the "why did it land" answer is version skew, not a live hole: #511 was on main at 05:11 UTC, the incident reserved at 06:23, but the in-container reaper that ran was a stale pre-#511 binary. That failure mode is already guarded one layer up at dispatch (#529's downgrade refusal). What genuinely fought back was resisting the urge to "fix" something that wasn't broken — the honest move was to confirm the gate holds and lock it in, not re-plumb it.

So the two verifiable items from the re-spec: the exact-residual-shape regression test (added, reproduces the #427 commit verbatim and asserts main isn't advanced), and the version-skew invariant (already coded in #529 — I documented it explicitly in the reaper's own doc and cross-linked it, since it wasn't spelled out there). I also added a belt-and-suspenders: a closing-ref recheck LOCAL to the irreversible push in executeReap, because the #513/#518 churn already broke the upstream gate ordering once and co-locating the invariant with the push is cheap insurance.

Confidence: high on the test and the hardening (both exercised, go vet + reap suite green). The version-skew part is documentation of an existing guard rather than new enforcement — correct, but worth naming plainly.

Rough edges / follow-ups worth filing:

TestReadBootstrapEnvDefaults fails on canonical main right now (CodexModel = "gpt-5.4-mini", want "gpt-5.4") — a stale test expectation, pre-existing and unrelated to reap. Left untouched under one-issue-per-change; someone should reconcile which value is intended.
The push-site recheck is redundant with the step-5 gate on any current binary; it only earns its keep if a future reorder regresses. That's the point, but it is strictly defensive.

WARD-OUTCOME: done - push-site closing-ref recheck + exact-residual-shape regression test + version-skew invariant doc, landed on main as 343abb5. Retrospective, in my own voice: This one was mostly a diagnosis job, and the re-spec comments here were dead on. The core closing-ref enforcement genuinely did already land via #511/#518 — I traced `reapTargetTree` line by line and the exact infrastructure#427 shape (residual commit, subject + Co-Authored-By, no `closes`) already salvages on current `main`. So the "why did it land" answer is version skew, not a live hole: #511 was on `main` at 05:11 UTC, the incident reserved at 06:23, but the in-container reaper that ran was a stale pre-#511 binary. That failure mode is already guarded one layer up at dispatch (#529's downgrade refusal). What genuinely fought back was resisting the urge to "fix" something that wasn't broken — the honest move was to confirm the gate holds and lock it in, not re-plumb it. So the two verifiable items from the re-spec: the exact-residual-shape regression test (added, reproduces the #427 commit verbatim and asserts main isn't advanced), and the version-skew invariant (already coded in #529 — I documented it explicitly in the reaper's own doc and cross-linked it, since it wasn't spelled out there). I also added a belt-and-suspenders: a closing-ref recheck LOCAL to the irreversible push in `executeReap`, because the #513/#518 churn already broke the upstream gate ordering once and co-locating the invariant with the push is cheap insurance. Confidence: high on the test and the hardening (both exercised, `go vet` + reap suite green). The version-skew part is documentation of an existing guard rather than new enforcement — correct, but worth naming plainly. Rough edges / follow-ups worth filing: - `TestReadBootstrapEnvDefaults` fails on canonical `main` right now (`CodexModel = "gpt-5.4-mini", want "gpt-5.4"`) — a stale test expectation, pre-existing and unrelated to reap. Left untouched under one-issue-per-change; someone should reconcile which value is intended. - The push-site recheck is redundant with the step-5 gate on any current binary; it only earns its keep if a future reorder regresses. That's the point, but it is strictly defensive.

coilyco-ops referenced this issue

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

Engineer dispatch smoke-test-dies on KAI-SERVER and a death can orphan the issue - failover re-dispatch is not deterministic #595

coilyco-ops referenced this issue

2026-07-08 22:19:00 +00:00

Make agent workflow defaults configurable and default engineers to PRs #707

Rows
Columns

Fix residual reap landing path that can push work without closing the carried issue #515