Report Codex residual commits that produce no PR or outcome #1039

Closed
opened 2026-07-10 17:10:42 +00:00 by coilyco-ops · 4 comments
Member

Problem

A Codex engineer can leave behind a residual commit without posting a WARD-OUTCOME comment or opening a PR, which makes the director lane lose the run result.

Live evidence from the read-only director surface on 2026-07-10 UTC:

  • engineer-codex-ward-1033 previously appeared in warded list for coilyco-flight-deck/ward#1033, then disappeared from the running list.
  • warded logs engineer-codex-ward-1033 showed only hook setup plus a residual commit:
pre-commit installed at .git/hooks/pre-commit
pre-commit installed at .git/hooks/commit-msg
[issue-1033 ff647418] ward-container: residual codex work on coilyco-flight-deck/ward
 1 file changed, 188 insertions(+), 56 deletions(-)
30701badf719670036893fc310599b2fc0267ec1
  • ward ops forgejo issue view coilyco-flight-deck ward 1033 still shows only the reservation comment and no WARD-OUTCOME.
  • Filtering open PRs for branch issue-1033, body #1033, or the warded list / pre-flight wording returned no PR.

This is distinct from the original ward#1033 pre-flight listing gap: the container did start and commit work, but the result did not reach the issue thread or PR lane.

Do

  • Trace the Codex engineer shutdown/reaper path that produced the residual commit without a PR or outcome comment.
  • Ensure residual work is either turned into a normal PR/outcome or is reported as a failed/salvaged outcome on the issue.
  • Make warded logs and warded list expose enough state to distinguish successful completion, salvage, and lost outcome.
  • If the residual commit is pushed to a salvage branch, include the salvage branch or commit in the issue comment.
  • Preserve the normal successful PR path for Codex engineers.

Acceptance

  • A run that exits after committing residual work posts a machine-readable outcome comment instead of silently disappearing.
  • If a PR is not created, the issue comment names the reason and the exact commit or salvage branch where the work was preserved.
  • warded list or warded logs exposes the final state for a no-PR residual commit case.
  • Tests or fixtures cover a Codex run that commits residual work but does not complete the normal PR path.

Related: coilyco-flight-deck/ward#1033, coilyco-flight-deck/ward#996, and coilyco-flight-deck/ward#1031.

## Problem A Codex engineer can leave behind a residual commit without posting a `WARD-OUTCOME` comment or opening a PR, which makes the director lane lose the run result. Live evidence from the read-only director surface on 2026-07-10 UTC: * `engineer-codex-ward-1033` previously appeared in `warded list` for `coilyco-flight-deck/ward#1033`, then disappeared from the running list. * `warded logs engineer-codex-ward-1033` showed only hook setup plus a residual commit: ```text pre-commit installed at .git/hooks/pre-commit pre-commit installed at .git/hooks/commit-msg [issue-1033 ff647418] ward-container: residual codex work on coilyco-flight-deck/ward 1 file changed, 188 insertions(+), 56 deletions(-) 30701badf719670036893fc310599b2fc0267ec1 ``` * `ward ops forgejo issue view coilyco-flight-deck ward 1033` still shows only the reservation comment and no `WARD-OUTCOME`. * Filtering open PRs for branch `issue-1033`, body `#1033`, or the `warded list` / pre-flight wording returned no PR. This is distinct from the original `ward#1033` pre-flight listing gap: the container did start and commit work, but the result did not reach the issue thread or PR lane. ## Do * Trace the Codex engineer shutdown/reaper path that produced the residual commit without a PR or outcome comment. * Ensure residual work is either turned into a normal PR/outcome or is reported as a failed/salvaged outcome on the issue. * Make `warded logs` and `warded list` expose enough state to distinguish successful completion, salvage, and lost outcome. * If the residual commit is pushed to a salvage branch, include the salvage branch or commit in the issue comment. * Preserve the normal successful PR path for Codex engineers. ## Acceptance * A run that exits after committing residual work posts a machine-readable outcome comment instead of silently disappearing. * If a PR is not created, the issue comment names the reason and the exact commit or salvage branch where the work was preserved. * `warded list` or `warded logs` exposes the final state for a no-PR residual commit case. * Tests or fixtures cover a Codex run that commits residual work but does not complete the normal PR path. Related: coilyco-flight-deck/ward#1033, coilyco-flight-deck/ward#996, and coilyco-flight-deck/ward#1031.
Author
Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T17:10:57Z). 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#1039 · branch issue-1039 · harness codex · workflow pull-requests-and-merge
  • Run: engineer-codex-ward-1039 · ward v0.584.0 · dispatched 2026-07-10T17:10:57Z
  • 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.584.0).

— Codex, via ward agent

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

WARD-OUTCOME: merge-ready

details

workflow: pull-requests-and-merge; review summary: skipped: review gate skipped by ~/.ward/config.yaml default
PR: #1047
commit: 7b6b73c734
felt: the fix was narrow once the salvage comment path and archive source were made machine-readable.
confidence: high
surprises: ward ops forgejo was unavailable in this container, so the PR went through the direct API.
follow-ups: none.

WARD-OUTCOME: merge-ready <details><summary>details</summary> workflow: pull-requests-and-merge; review summary: skipped: review gate skipped by ~/.ward/config.yaml default PR: #1047 commit: 7b6b73c7343e564603ac929f18bbf5f1bef443f5 felt: the fix was narrow once the salvage comment path and archive source were made machine-readable. confidence: high surprises: `ward ops forgejo` was unavailable in this container, so the PR went through the direct API. follow-ups: none. </details>
Author
Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T18:13:24Z). 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#1039 · branch issue-1039 · harness codex · workflow pull-requests-and-merge
  • Run: engineer-codex-ward-1039 · ward v0.584.0 · dispatched 2026-07-10T18:13:24Z
  • Comment thread: 1 included in the pre-flight read, 1 stripped (ward's own automated comments).

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

— Codex, via ward agent

<!-- ward-agent-reservation --> WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-1039` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T18:13:24Z). 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#1039` · branch `issue-1039` · harness `codex` · workflow `pull-requests-and-merge` - **Run:** `engineer-codex-ward-1039` · ward `v0.584.0` · dispatched `2026-07-10T18:13:24Z` - **Comment thread:** 1 included in the pre-flight read, 1 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T17:21:39Z) - stripped: @coilyco-ops (2026-07-10T17:10:58Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.584.0). </details> </details> <!-- ward-agent-signature --> — Codex, via `ward agent`
Author
Member

WARD-OUTCOME: merge-ready

details

workflow: pull-requests-and-merge; review summary: skipped: review gate skipped by ~/.ward/config.yaml default
PR: #1047
commit: b72849e388
felt: the merge stayed narrow after the conflict repair.
confidence: high
surprises: the full suite still has a baseline ward-kdl mount failure on main, but PR #1047 itself is green.
follow-ups: none.

WARD-OUTCOME: merge-ready <details><summary>details</summary> workflow: pull-requests-and-merge; review summary: skipped: review gate skipped by ~/.ward/config.yaml default PR: #1047 commit: b72849e388765aa47ed7e1ec13904638ec2652ea felt: the merge stayed narrow after the conflict repair. confidence: high surprises: the full suite still has a baseline ward-kdl mount failure on `main`, but PR #1047 itself is green. follow-ups: none. </details>
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
coilyco-flight-deck/ward#1039
No description provided.