coilyco-flight-deck/ward

Fork 0

Make cleanup/reaper workflow-aware and start reports with WARD-REAP #724

New issue

Closed

opened 2026-07-09 00:44:44 +00:00 by coilyco-ops · 4 comments

coilyco-ops commented

2026-07-09 00:44:44 +00:00

Member

Problem

The cleanup/reaper path treats pull-request workflow runs as failed reap because they did not land on main. That is mechanically understandable, but wrong for workflows whose intended done-condition is not a main push.

The cleanup logic needs to understand "this got as far as its workflow wanted it to go."

Desired behavior

Workflow-specific success conditions:

direct-main - success means the change landed on main and the issue can close.
pull-requests - success means the branch was pushed and the PR was opened. No main merge is expected.
pull-requests-and-merge - success means the PR was opened, checks/review passed, and the PR merged.
patch-only - success means the patch artifact/comment was produced. No push is expected.

A run should not be reported as failed cleanup just because it stopped at the intended workflow boundary.

Message format

The first line of the user-visible cleanup/reaper report should match other ward messages and start with a marker, not a Markdown title. Use:

WARD-REAP: ...

Drop the initial Markdown title format.

Naming direction

Audit user-facing reap / reaper language while changing this. reap is not a friendly product word. Prefer cleanup for user-facing docs/messages where it reads naturally, while keeping internal function/package names only if renaming them would create avoidable churn.

Do not rename the marker in this issue; the requested first-line marker is WARD-REAP:. If a broader WARD-CLEANUP: marker is desired, file a separate compatibility plan.

Acceptance

Cleanup/reaper classifies each workflow by its intended done-condition.
pull-requests runs that opened a PR do not get reported as failed because main was untouched.
patch-only runs that produced the patch do not get reported as failed because main was untouched.
The first user-visible report line starts with WARD-REAP:.
User-facing docs/messages prefer cleanup over reap where practical.
Tests cover workflow-aware cleanup classification and the first-line message format.

Filed after the workflow dispatch wave created PRs and cleanup treated them as failed reap.

## Problem The cleanup/reaper path treats pull-request workflow runs as failed reap because they did not land on `main`. That is mechanically understandable, but wrong for workflows whose intended done-condition is not a `main` push. The cleanup logic needs to understand "this got as far as its workflow wanted it to go." ## Desired behavior Workflow-specific success conditions: * `direct-main` - success means the change landed on `main` and the issue can close. * `pull-requests` - success means the branch was pushed and the PR was opened. No `main` merge is expected. * `pull-requests-and-merge` - success means the PR was opened, checks/review passed, and the PR merged. * `patch-only` - success means the patch artifact/comment was produced. No push is expected. A run should not be reported as failed cleanup just because it stopped at the intended workflow boundary. ## Message format The first line of the user-visible cleanup/reaper report should match other ward messages and start with a marker, not a Markdown title. Use: ```text WARD-REAP: ... ``` Drop the initial Markdown title format. ## Naming direction Audit user-facing `reap` / `reaper` language while changing this. `reap` is not a friendly product word. Prefer `cleanup` for user-facing docs/messages where it reads naturally, while keeping internal function/package names only if renaming them would create avoidable churn. Do not rename the marker in this issue; the requested first-line marker is `WARD-REAP:`. If a broader `WARD-CLEANUP:` marker is desired, file a separate compatibility plan. ## Acceptance * Cleanup/reaper classifies each workflow by its intended done-condition. * `pull-requests` runs that opened a PR do not get reported as failed because `main` was untouched. * `patch-only` runs that produced the patch do not get reported as failed because `main` was untouched. * The first user-visible report line starts with `WARD-REAP:`. * User-facing docs/messages prefer `cleanup` over `reap` where practical. * Tests cover workflow-aware cleanup classification and the first-line message format. Filed after the workflow dispatch wave created PRs and cleanup treated them as failed reap.

coilyco-ops added the

headless

labels

2026-07-09 00:44:44 +00:00

coilyco-ops commented

2026-07-09 00:45:12 +00:00

Author

Member

🔒 Reserved by ward agent --harness codex — container engineer-codex-ward-724 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-09T00:45:10Z). 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#724 · branch issue-724 · harness codex · workflow pr
Run: engineer-codex-ward-724 · ward v0.470.0 · dispatched 2026-07-09T00:45:10Z
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.470.0).

— Codex, via ward agent

🔒 Reserved by `ward agent --harness codex` — container `engineer-codex-ward-724` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-09T00:45:10Z). 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#724` · branch `issue-724` · harness `codex` · workflow `pr` - **Run:** `engineer-codex-ward-724` · ward `v0.470.0` · dispatched `2026-07-09T00:45:10Z` - **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.470.0). </details>  — Codex, via `ward agent`

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

2026-07-09 01:02:05 +00:00

Make cleanup/reaper workflow-aware and start reports with WARD-REAP #726

coilyco-ops commented

2026-07-09 01:04:03 +00:00

Author

Member

WARD-OUTCOME: blocked - review summary: blocked: codex: exit status 1

Review panel verdicts:

codex: ERROR: codex: exit status 1 (conf 0.00)
claude: ERROR: claude: exit status 1 (conf 0.00)
goose: ERROR: goose: exit status 1 (conf 0.00)

— Codex, via ward agent

WARD-OUTCOME: blocked - review summary: blocked: codex: exit status 1 Review panel verdicts: - codex: ERROR: codex: exit status 1 (conf 0.00) - claude: ERROR: claude: exit status 1 (conf 0.00) - goose: ERROR: goose: exit status 1 (conf 0.00)  — Codex, via `ward agent`

coilyco-ops commented

2026-07-09 01:04:50 +00:00

Author

Member

WARD-OUTCOME: blocked - the review panel could not run in this container because the reviewer endpoints were unavailable.
blocked: codex: exit status 1
The implementation landed cleanly and the repo validation passed, but the required review gate failed closed before a landable verdict. The only rough edge left is the reviewer availability/auth path in this environment.

WARD-OUTCOME: blocked - the review panel could not run in this container because the reviewer endpoints were unavailable. blocked: codex: exit status 1 The implementation landed cleanly and the repo validation passed, but the required review gate failed closed before a landable verdict. The only rough edge left is the reviewer availability/auth path in this environment.

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

2026-07-09 01:05:04 +00:00

ward salvage: ward-salvage/ward-1ee9be1c #728

coilyco-ops commented

2026-07-09 01:05:05 +00:00

Author

Member

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

An ephemeral ward container (codex 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 (a closing reference for #724 never reached main). Recover from the salvage branch below.

Repo: coilyco-flight-deck/ward
Salvage branch: ward-salvage/ward-1ee9be1c
Pull request: not opened - PR creation failed: forgejo: parse created pull request: unexpected end of JSON input
Reason: run workflow does not land on main (--workflow pr/patch-only)
Container uptime at reap: 19m (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.470.0
version source:    pinned via WARD_VERSION/--ward-version (v0.470.0)
HEAD:              56f58df8f63b
origin/main:       a2a544f1a892
ancestry:          HEAD is NOT yet on origin/main - residual work remains to land
decision gate:     workflow does not land on main (--workflow pr/patch-only)
reason:            run workflow does not land on main (--workflow pr/patch-only)
provenance:        not read (workflow hold)
run-owned landed:  no
working tree:      clean
container uptime:  19m (baked Forgejo PAT age proxy)
--- end reap diagnostics ---

Recover

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

— Codex, via ward agent

## ⚠️ Reopened: this run's work did not land on `main` An ephemeral `ward container` (codex 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 (a closing reference for #724 never reached `main`). Recover from the salvage branch below. - **Repo:** `coilyco-flight-deck/ward` - **Salvage branch:** `ward-salvage/ward-1ee9be1c` - **Pull request:** not opened - PR creation failed: forgejo: parse created pull request: unexpected end of JSON input - **Reason:** run workflow does not land on main (--workflow pr/patch-only) - **Container uptime at reap:** 19m (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.470.0 version source: pinned via WARD_VERSION/--ward-version (v0.470.0) HEAD: 56f58df8f63b origin/main: a2a544f1a892 ancestry: HEAD is NOT yet on origin/main - residual work remains to land decision gate: workflow does not land on main (--workflow pr/patch-only) reason: run workflow does not land on main (--workflow pr/patch-only) provenance: not read (workflow hold) run-owned landed: no working tree: clean container uptime: 19m (baked Forgejo PAT age proxy) --- end reap diagnostics --- ``` ## Recover ```bash git fetch https://forgejo.coilysiren.me/coilyco-flight-deck/ward.git ward-salvage/ward-1ee9be1c git checkout -b ward-salvage/ward-1ee9be1c FETCH_HEAD ```  — Codex, via `ward agent`