Enforce issue-closing commit discipline in ward so Goose cannot bypass it #511

Closed

opened 2026-07-02 05:03:50 +00:00 by coilysiren · 2 comments

coilysiren commented

2026-07-02 05:03:50 +00:00

Owner

Goose-driven ward agent engineer --driver goose runs can land commits that do not carry the required same-repo issue-closing reference, even though ward installs pre-commit and commit-msg hooks in the clone.

Observed symptom:

a Goose engineer landed a commit in agent-proxy without the issue-closing hook content the operator expects
example supplied by the operator: coilyco-flight-deck/agent-proxy commit 95355872b962fc7ff9232c747b22d1409c9e52b6
operator statement: this is happening with Goose engineers and not with the other engineer drivers

What ward already does:

installPreCommitHooks() installs both default hooks and --hook-type commit-msg in the target clone and each extra repo clone
so this is not solved reliably by clone bootstrap alone

Required outcome:

ward itself enforces the issue-closing commit discipline for carried issue work, independent of harness behavior
Goose must not be able to land a same-repo issue without the required closing reference in the commit path

Acceptance criteria:

reproduce and identify the exact bypass path for Goose engineers
implement ward-side enforcement at a load-bearing point, not just a best-effort prompt instruction
enforce for target repo and granted extra repos when the run is carrying a specific issue
add tests that prove Goose cannot land a carried issue without the required closing reference
update the relevant ward docs around commit/push discipline if the enforcement point changes

Design direction to evaluate:

validate the commit messages before merge/push and fail the carry if the same-repo closing reference is absent
if a stricter earlier interception is cleaner, that is acceptable, but the guarantee must belong to ward rather than the harness prompt

Goose-driven `ward agent engineer --driver goose` runs can land commits that do not carry the required same-repo issue-closing reference, even though ward installs `pre-commit` and `commit-msg` hooks in the clone. Observed symptom: - a Goose engineer landed a commit in `agent-proxy` without the issue-closing hook content the operator expects - example supplied by the operator: `coilyco-flight-deck/agent-proxy` commit `95355872b962fc7ff9232c747b22d1409c9e52b6` - operator statement: this is happening with Goose engineers and not with the other engineer drivers What ward already does: - `installPreCommitHooks()` installs both default hooks and `--hook-type commit-msg` in the target clone and each extra repo clone - so this is not solved reliably by clone bootstrap alone Required outcome: - ward itself enforces the issue-closing commit discipline for carried issue work, independent of harness behavior - Goose must not be able to land a same-repo issue without the required closing reference in the commit path Acceptance criteria: - reproduce and identify the exact bypass path for Goose engineers - implement ward-side enforcement at a load-bearing point, not just a best-effort prompt instruction - enforce for target repo and granted extra repos when the run is carrying a specific issue - add tests that prove Goose cannot land a carried issue without the required closing reference - update the relevant ward docs around commit/push discipline if the enforcement point changes Design direction to evaluate: - validate the commit messages before merge/push and fail the carry if the same-repo closing reference is absent - if a stricter earlier interception is cleaner, that is acceptable, but the guarantee must belong to ward rather than the harness prompt

coilyco-ops commented

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

Owner

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

— Codex, via ward agent

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

coilysiren referenced this issue from a commit

2026-07-02 05:12:08 +00:00

fix(agent): enforce closing refs in reap

coilysiren closed this issue

2026-07-02 05:12:08 +00:00

coilysiren commented

2026-07-02 05:12:25 +00:00

Author

Owner

WARD-OUTCOME: done - ward now blocks carried issues from landing without the same-repo closes #N reference in reap, including granted repos.

This felt mostly mechanical once I found the landing point, but the repo fought back in the docs budgets and a drifting fleet fixture. I’m fairly confident in the enforcement path and the tests around it, with the main rough edge being that the reaper now makes a hard judgment on commit history instead of trusting hook setup alone.

WARD-OUTCOME: done - ward now blocks carried issues from landing without the same-repo closes #N reference in reap, including granted repos. This felt mostly mechanical once I found the landing point, but the repo fought back in the docs budgets and a drifting fleet fixture. I’m fairly confident in the enforcement path and the tests around it, with the main rough edge being that the reaper now makes a hard judgment on commit history instead of trusting hook setup alone.

coilyco-ops referenced this issue

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

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

coilyco-ops referenced this issue

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

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

Commenting is not possible because the repository is archived.