Recover PR #1452 merge 405 after green checks

coilyco-ops commented

2026-07-15 13:38:59 +00:00

Owner

Problem

PR #1452 for #1443 is green, but the ward-native merge path hit a Forgejo 405 while the PR remained green.

Evidence from the director surface on 2026-07-15:

ward agent pr status coilyco-flight-deck/ward#1452
combined status: success
  test / test (pull_request) = success

ward agent pr merge coilyco-flight-deck/ward#1452
pr merge: coilyco-flight-deck/ward#1452: forgejo merge stayed on 405 after 3 settle attempt(s) while the PR remained green (success on 5e93f3499b1206acd80be28a5164dc841186364c); retry later or check the Forgejo merge queue: forgejo merge PR returned 405 Method Not Allowed: {"message":"Please try again later"...}

Acceptance

Re-check PR #1452 at head 5e93f3499b1206acd80be28a5164dc841186364c or a newer explicitly pushed head.
If checks remain green and the PR is mergeable, merge it with the ward-native path.
If Forgejo continues returning 405, leave exact evidence and either retry through the supported path or repair the merge/retry handling with a focused change.
Ensure #1443 closes only after the PR contents land on main.

Related: #1443, #1452.

## Problem PR #1452 for #1443 is green, but the ward-native merge path hit a Forgejo 405 while the PR remained green. Evidence from the director surface on 2026-07-15: ```text ward agent pr status coilyco-flight-deck/ward#1452 combined status: success test / test (pull_request) = success ward agent pr merge coilyco-flight-deck/ward#1452 pr merge: coilyco-flight-deck/ward#1452: forgejo merge stayed on 405 after 3 settle attempt(s) while the PR remained green (success on 5e93f3499b1206acd80be28a5164dc841186364c); retry later or check the Forgejo merge queue: forgejo merge PR returned 405 Method Not Allowed: {"message":"Please try again later"...} ``` ## Acceptance - Re-check PR #1452 at head `5e93f3499b1206acd80be28a5164dc841186364c` or a newer explicitly pushed head. - If checks remain green and the PR is mergeable, merge it with the ward-native path. - If Forgejo continues returning 405, leave exact evidence and either retry through the supported path or repair the merge/retry handling with a focused change. - Ensure #1443 closes only after the PR contents land on main. Related: #1443, #1452.

coilyco-ops added this to the warded control plane coherence milestone

2026-07-15 13:38:59 +00:00

coilyco-ops added the

labels

2026-07-15 13:38:59 +00:00

coilyco-ops commented

2026-07-15 13:39:43 +00:00

Author

Owner

Resolved by director triage. PR #1452 was green but mergeable=false because merged PR #1450 had already landed the same release-action recovery with the default-image repair. The 405 was therefore not a transient merge queue condition. PR #1452 was closed as superseded at head 5e93f3499b; no recovery dispatch is warranted. Source issue #1443 remains open until a post-#1450 release.yml run succeeds.

Resolved by director triage. PR #1452 was green but mergeable=false because merged PR #1450 had already landed the same release-action recovery with the default-image repair. The 405 was therefore not a transient merge queue condition. PR #1452 was closed as superseded at head 5e93f3499b1206acd80be28a5164dc841186364c; no recovery dispatch is warranted. Source issue #1443 remains open until a post-#1450 release.yml run succeeds.

coilyco-ops closed this issue

2026-07-15 13:39:43 +00:00

coilyco-ops commented

2026-07-15 13:39:45 +00:00

Author

Owner

FOLLOW-UP: after the initial merge 405, PR #1452 is now closed unmerged (merged=false, merged_at=null) and #1443 remains open. Recovery should reopen #1452 or recreate the same fix on a new PR, then merge it after green checks.

FOLLOW-UP: after the initial merge 405, PR #1452 is now closed unmerged (`merged=false`, `merged_at=null`) and #1443 remains open. Recovery should reopen #1452 or recreate the same fix on a new PR, then merge it after green checks.

coilyco-ops reopened this issue

2026-07-15 13:39:52 +00:00

coilyco-ops commented

2026-07-15 13:40:34 +00:00

Author

Owner

WARDED_WORKFLOW: reservation-held

reservation details

Holder: launch intent for container engineer-codex-ward-1453 on host kais-macbook-pro-2.local.

Accepted by ward agent --harness codex (reserved 2026-07-15T13:40:34Z). Concurrent ward agent runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). --override-reservation 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#1453 · branch issue-1453 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-1453 · ward v0.710.0 · dispatched 2026-07-15T13:40:28Z
Comment thread: 2 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-15T13:39:43Z), @coilyco-ops (2026-07-15T13:39:45Z)

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

— Codex, via ward agent

WARDED_WORKFLOW: reservation-held <details><summary>reservation details</summary> Holder: launch intent for container `engineer-codex-ward-1453` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness codex` (reserved 2026-07-15T13:40:34Z). Concurrent `ward agent` runs are blocked until this intent becomes visible or the intent is released. The stale-intent fallback is still TTL-bounded (3h TTL). `--override-reservation` 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#1453` · branch `issue-1453` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-1453` · ward `v0.710.0` · dispatched `2026-07-15T13:40:28Z` - **Comment thread:** 2 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-15T13:39:43Z), @coilyco-ops (2026-07-15T13:39:45Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.710.0). </details> </details>  — Codex, via `ward agent`

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

2026-07-15 13:47:43 +00:00

fix(release): remove shared action fetch from setup #1456

coilyco-ops commented

2026-07-15 13:51:15 +00:00

Author

Owner

WARDED_WORKFLOW: blocked 🛑

details

manual close/update snapshot at 2026-07-15T13:47:43Z is newer than the latest ward acknowledgement at 2026-07-15T13:40:34Z

This action is blocked until the feedback is visibly acknowledged.

— Codex, via ward agent

WARDED_WORKFLOW: blocked 🛑 <details><summary>details</summary> manual close/update snapshot at 2026-07-15T13:47:43Z is newer than the latest ward acknowledgement at 2026-07-15T13:40:34Z This action is blocked until the feedback is visibly acknowledged. </details>  — Codex, via `ward agent`

coilyco-ops closed this issue

2026-07-15 13:52:15 +00:00

coilyco-ops commented

2026-07-15 13:52:40 +00:00

Author

Owner

WARDED_WORKFLOW: #1456

details

workflow: pull-request-and-merge; review summary: skipped (temporary ward default pending brokered QA)

Implementation felt like a straight replay once the branch was rehydrated; the only surprise was the human-feedback timestamp gate after the PR went green.

confidence: high
surprises: the branch already carried the exact recovery fix; the merge blocker was purely comment-timestamp hygiene.
follow-ups: none

WARDED_WORKFLOW: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/pulls/1456 <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skipped (temporary ward default pending brokered QA) Implementation felt like a straight replay once the branch was rehydrated; the only surprise was the human-feedback timestamp gate after the PR went green. confidence: high surprises: the branch already carried the exact recovery fix; the merge blocker was purely comment-timestamp hygiene. follow-ups: none </details>

coilyco-ops referenced this issue

2026-07-15 13:56:41 +00:00

Repair release-tag helper on internal Forgejo origin URL #1460

Rows
Columns

Recover PR #1452 merge 405 after green checks #1453

Problem

Acceptance