coilyco-flight-deck/ward

Fork 0

Reaper closing-reference gate rejects Fixes #N commits #699

New issue

Closed

opened 2026-07-08 21:12:56 +00:00 by coilyco-ops · 3 comments

coilyco-ops commented

2026-07-08 21:12:56 +00:00

Member

Bug

The container reaper salvaged a complete ward#691 fix because the commit message used Fixes #691 instead of closes #691. The reaper reports “missing same-repo closing reference,” but Fixes #N is a valid closing reference and ward/aos docs teach it as equivalent.

Concrete regression

Goose produced this commit on origin/issue-691 / ward-salvage/ward-b8ccdc84:

de9e61abcc211b716e519e529b9ac673ab707d0e Update Codex launch adapter for current codex exec flags

- Replace deprecated --ask-for-approval flag with --dangerously-bypass-approvals-and-sandbox
- Update unit tests to match new expected arguments
- This fixes the failing container prelaunch probe that was rejecting the old flag names

Fixes #691

The diff is a narrow fix to internal/agents/codex/smoke.go and internal/agents/codex/smoke_test.go.

But the reaper commented on ward#691:

Reason: missing same-repo closing reference
HEAD:              de9e61abcc21
origin/main:       22ded3946525
ancestry:          HEAD is NOT yet on origin/main - residual work remains to land
decision gate:     missing same-repo closing reference

Remote state observed from the director surface after the comment:

22ded39465250c6da99731287e9291a170cd73f4 refs/heads/main
de9e61abcc211b716e519e529b9ac673ab707d0e refs/heads/ward-salvage/ward-b8ccdc84

So the commit was not on main; it was preserved because the closing-reference gate rejected Fixes #691.

Root cause from code inspection

cmd/ward/container_reap.go currently builds a single literal close-ref pattern:

pattern := fmt.Sprintf("closes #%d", issue)

The related tests also only cover closes #N. That means the reaper's “closing reference” policy is narrower than the accepted Forgejo/GitHub closing keywords and narrower than the docs/examples agents use (Closes, Fixes, Refs where Refs is non-closing).

Expected behavior

For same-repo issue closure gates, ward should accept the standard closing keywords that actually close issues, at least:

Closes #N
Fixes #N
Resolves #N

Case should not matter. Refs #N should remain non-closing.

Do

Replace the single closes #N literal check with a shared same-repo closing-reference parser.
Accept closes, fixes, and resolves case-insensitively for the target issue number.
Keep adjacent issue numbers from matching.
Keep non-closing references like refs #N from passing the gate.
Update reaper diagnostics from “missing closes” to “missing closing reference” where the broader policy applies.
Add regression coverage using the exact ward#691 shape: commit body ending in Fixes #691 should land instead of salvage.

Acceptance

A direct-main run whose carried commit says Fixes #691 passes the reaper closing-reference gate.
Refs #691 still fails the closing-reference gate.
Salvage/reopen comments use the broader “closing reference” wording.
ward exec test passes.

Filed from the read-only director surface after ward#691 was falsely salvaged even though the commit message contained Fixes #691.

## Bug The container reaper salvaged a complete ward#691 fix because the commit message used `Fixes #691` instead of `closes #691`. The reaper reports “missing same-repo closing reference,” but `Fixes #N` is a valid closing reference and ward/aos docs teach it as equivalent. ## Concrete regression Goose produced this commit on `origin/issue-691` / `ward-salvage/ward-b8ccdc84`: ```text de9e61abcc211b716e519e529b9ac673ab707d0e Update Codex launch adapter for current codex exec flags - Replace deprecated --ask-for-approval flag with --dangerously-bypass-approvals-and-sandbox - Update unit tests to match new expected arguments - This fixes the failing container prelaunch probe that was rejecting the old flag names Fixes #691 ``` The diff is a narrow fix to `internal/agents/codex/smoke.go` and `internal/agents/codex/smoke_test.go`. But the reaper commented on ward#691: ```text Reason: missing same-repo closing reference HEAD: de9e61abcc21 origin/main: 22ded3946525 ancestry: HEAD is NOT yet on origin/main - residual work remains to land decision gate: missing same-repo closing reference ``` Remote state observed from the director surface after the comment: ```text 22ded39465250c6da99731287e9291a170cd73f4 refs/heads/main de9e61abcc211b716e519e529b9ac673ab707d0e refs/heads/ward-salvage/ward-b8ccdc84 ``` So the commit was not on `main`; it was preserved because the closing-reference gate rejected `Fixes #691`. ## Root cause from code inspection `cmd/ward/container_reap.go` currently builds a single literal close-ref pattern: ```go pattern := fmt.Sprintf("closes #%d", issue) ``` The related tests also only cover `closes #N`. That means the reaper's “closing reference” policy is narrower than the accepted Forgejo/GitHub closing keywords and narrower than the docs/examples agents use (`Closes`, `Fixes`, `Refs` where `Refs` is non-closing). ## Expected behavior For same-repo issue closure gates, ward should accept the standard closing keywords that actually close issues, at least: * `Closes #N` * `Fixes #N` * `Resolves #N` Case should not matter. `Refs #N` should remain non-closing. ## Do * Replace the single `closes #N` literal check with a shared same-repo closing-reference parser. * Accept `closes`, `fixes`, and `resolves` case-insensitively for the target issue number. * Keep adjacent issue numbers from matching. * Keep non-closing references like `refs #N` from passing the gate. * Update reaper diagnostics from “missing closes” to “missing closing reference” where the broader policy applies. * Add regression coverage using the exact ward#691 shape: commit body ending in `Fixes #691` should land instead of salvage. ## Acceptance * A direct-main run whose carried commit says `Fixes #691` passes the reaper closing-reference gate. * `Refs #691` still fails the closing-reference gate. * Salvage/reopen comments use the broader “closing reference” wording. * `ward exec test` passes. Filed from the read-only director surface after ward#691 was falsely salvaged even though the commit message contained `Fixes #691`.

coilyco-ops commented

2026-07-08 21:13:05 +00:00

Author

Member

🔒 Reserved by ward agent --harness goose — container engineer-goose-ward-699 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-08T21:13:03Z). 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#699 · branch issue-699 · harness goose · workflow direct-main
Run: engineer-goose-ward-699 · ward v0.463.0 · dispatched 2026-07-08T21:13:03Z
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.463.0).

— Goose, via ward agent

🔒 Reserved by `ward agent --harness goose` — container `engineer-goose-ward-699` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-08T21:13:03Z). 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#699` · branch `issue-699` · harness `goose` · workflow `direct-main` - **Run:** `engineer-goose-ward-699` · ward `v0.463.0` · dispatched `2026-07-08T21:13:03Z` - **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.463.0). </details>  — Goose, via `ward agent`

coilyco-ops commented

2026-07-08 21:17:40 +00:00

Author

Member

⚠️ Reopened: this run's work did not land on `main`

An ephemeral ward container (goose mode) dispatched for this issue finished but its work was not merged to main, so the reaper preserved it on a branch before teardown and reopened the issue (its closes #699 never reached main). Recover from the salvage branch below.

Repo: coilyco-flight-deck/ward
Salvage branch: ward-salvage/ward-7487270b
Reason: missing same-repo closing reference
Container uptime at reap: 4m (age of the baked Forgejo PAT snapshot; a long-lived container is likelier to carry a rotated token)

Reap diagnostics

--- reap diagnostics ---
ward version:      v0.463.0
version source:    pinned via WARD_VERSION/--ward-version (v0.463.0)
HEAD:              eaee93521eec
origin/main:       22ded3946525
ancestry:          HEAD is NOT yet on origin/main - residual work remains to land
decision gate:     missing same-repo closing reference
reason:            missing same-repo closing reference
provenance:        present
run-owned landed:  no
working tree:      2 dirty path(s)
container uptime:  4m (baked Forgejo PAT age proxy)
--- end reap diagnostics ---

Recover

git fetch https://forgejo.coilysiren.me/coilyco-flight-deck/ward.git ward-salvage/ward-7487270b
git checkout -b ward-salvage/ward-7487270b FETCH_HEAD

Working tree at reap time

 M cmd/ward/container_reap.go
 M cmd/ward/container_reap_test.go

— Goose, via ward agent

## ⚠️ Reopened: this run's work did not land on `main` An ephemeral `ward container` (goose mode) dispatched for this issue finished but its work was **not merged to `main`**, so the reaper preserved it on a branch before teardown and reopened the issue (its `closes #699` never reached `main`). Recover from the salvage branch below. - **Repo:** `coilyco-flight-deck/ward` - **Salvage branch:** `ward-salvage/ward-7487270b` - **Reason:** missing same-repo closing reference - **Container uptime at reap:** 4m (age of the baked Forgejo PAT snapshot; a long-lived container is likelier to carry a rotated token) ## Reap diagnostics ``` --- reap diagnostics --- ward version: v0.463.0 version source: pinned via WARD_VERSION/--ward-version (v0.463.0) HEAD: eaee93521eec origin/main: 22ded3946525 ancestry: HEAD is NOT yet on origin/main - residual work remains to land decision gate: missing same-repo closing reference reason: missing same-repo closing reference provenance: present run-owned landed: no working tree: 2 dirty path(s) container uptime: 4m (baked Forgejo PAT age proxy) --- end reap diagnostics --- ``` ## Recover ```bash git fetch https://forgejo.coilysiren.me/coilyco-flight-deck/ward.git ward-salvage/ward-7487270b git checkout -b ward-salvage/ward-7487270b FETCH_HEAD ``` ## Working tree at reap time ``` M cmd/ward/container_reap.go M cmd/ward/container_reap_test.go ```  — Goose, via `ward agent`

coilyco-ops referenced this issue

2026-07-08 21:20:22 +00:00

Director-surface dispatches inherit stale WARD_VERSION pins #700

coilyco-ops commented

2026-07-08 21:56:24 +00:00

Author

Member

🔒 Reserved by ward agent --harness codex — container engineer-codex-ward-699 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-08T21:56:23Z). Concurrent ward agent runs are blocked until it finishes or the reservation goes stale (1h TTL); --force overrides.

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

Resolved: coilyco-flight-deck/ward#699 · branch issue-699 · harness codex · workflow direct-main
Run: engineer-codex-ward-699 · ward v0.466.0 · dispatched 2026-07-08T21:56:23Z
Comment thread: 1 included in the pre-flight read, 1 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-08T21:17:40Z)
- stripped: @coilyco-ops (2026-07-08T21:13:05Z)

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

— Codex, via ward agent

🔒 Reserved by `ward agent --harness codex` — container `engineer-codex-ward-699` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-08T21:56:23Z). 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#699` · branch `issue-699` · harness `codex` · workflow `direct-main` - **Run:** `engineer-codex-ward-699` · ward `v0.466.0` · dispatched `2026-07-08T21:56:23Z` - **Comment thread:** 1 included in the pre-flight read, 1 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-08T21:17:40Z) - stripped: @coilyco-ops (2026-07-08T21:13:05Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.466.0). </details>  — Codex, via `ward agent`