coilyco-flight-deck/ward

Fork 0

Recover green PR #1369 from Forgejo merge 405 #1372

New issue

Closed

opened 2026-07-15 09:41:17 +00:00 by coilyco-ops · 4 comments

coilyco-ops commented

2026-07-15 09:41:17 +00:00

Member

Problem

PR #1369 is green after the #1371 repair, but Ward cannot merge it because Forgejo's merge endpoint is returning a transient-looking 405.

Evidence from two Ward merge attempts:

coilyco-flight-deck/ward#1369 head 1456f05378a91aee5bbca3cefd96276aa74d9cd0
status success: test / test (pull_request)=success
forgejo merge stayed on 405 after 3 settle attempt(s)
forgejo merge PR returned 405 Method Not Allowed: {"message":"Please try again later","url":"https://forgejo.coilysiren.me/api/swagger"}

Forgejo still reports mergeable=false, while ward agent pr recover coilyco-flight-deck/ward#1369 says the next safe action is to merge once checks are green.

Acceptance

Recover PR #1369 to a merged state once Forgejo allows it, without changing the green head unless needed.
If Forgejo continues to refuse, leave exact diagnostics on this issue and #1369.
Confirm the post-merge promote/release path or capture any follow-on failure separately.

Related: #1016, #1369, #1371.

## Problem PR #1369 is green after the #1371 repair, but Ward cannot merge it because Forgejo's merge endpoint is returning a transient-looking 405. Evidence from two Ward merge attempts: ```text coilyco-flight-deck/ward#1369 head 1456f05378a91aee5bbca3cefd96276aa74d9cd0 status success: test / test (pull_request)=success forgejo merge stayed on 405 after 3 settle attempt(s) forgejo merge PR returned 405 Method Not Allowed: {"message":"Please try again later","url":"https://forgejo.coilysiren.me/api/swagger"} ``` Forgejo still reports `mergeable=false`, while `ward agent pr recover coilyco-flight-deck/ward#1369` says the next safe action is to merge once checks are green. ## Acceptance - Recover PR #1369 to a merged state once Forgejo allows it, without changing the green head unless needed. - If Forgejo continues to refuse, leave exact diagnostics on this issue and #1369. - Confirm the post-merge promote/release path or capture any follow-on failure separately. Related: #1016, #1369, #1371.

coilyco-ops added the

coherence-core

headless

labels

2026-07-15 09:41:17 +00:00

coilyco-ops commented

2026-07-15 09:41:39 +00:00

Author

Member

WARDED_WORKFLOW: reservation-held

reservation details

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

Accepted by ward agent --harness codex (reserved 2026-07-15T09:41:38Z). 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#1372 · branch issue-1372 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-1372 · ward v0.710.0 · dispatched 2026-07-15T09:41:31Z
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.710.0).

— Codex, via ward agent

WARDED_WORKFLOW: reservation-held <details><summary>reservation details</summary> Holder: launch intent for container `engineer-codex-ward-1372` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness codex` (reserved 2026-07-15T09:41:38Z). 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#1372` · branch `issue-1372` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-1372` · ward `v0.710.0` · dispatched `2026-07-15T09:41:31Z` - **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.710.0). </details> </details>  — Codex, via `ward agent`

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

2026-07-15 09:48:36 +00:00

fix: widen transient forgejo merge retry window #1374

coilyco-ops commented

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

Author

Member

WARDED_WORKFLOW: blocked 🛑

details

manual close/update snapshot at 2026-07-15T09:48:36Z is newer than the latest ward acknowledgement at 2026-07-15T09:41:39Z

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-15T09:48:36Z is newer than the latest ward acknowledgement at 2026-07-15T09:41:39Z This action is blocked until the feedback is visibly acknowledged. </details>  — Codex, via `ward agent`

coilyco-ops closed this issue

2026-07-15 09:50:13 +00:00

coilyco-ops commented

2026-07-15 09:50:51 +00:00

Author

Member

WARDED_WORKFLOW: #1374

details

workflow: pull-request-and-merge; review summary: skipped: the in-container review gate was intentionally skipped because the temporary ward default pending brokered QA
felt: mostly mechanical, with one sharp edge: Forgejo's 405 kept hanging around long enough to need a wider settle window, and the PR-thread freshness guard had to be acknowledged before merge
confidence: medium-high
surprises: PR #1369 still refused with 405 after the wider retry window, so the exact diagnostics are left on #1369 and this issue for later follow-up
follow-ups: watch #1369 for a later merge opportunity; keep the retry window change if the queue lag repeats

WARDED_WORKFLOW: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/pulls/1374 <details><summary>details</summary> workflow: pull-request-and-merge; review summary: skipped: the in-container review gate was intentionally skipped because the temporary ward default pending brokered QA felt: mostly mechanical, with one sharp edge: Forgejo's 405 kept hanging around long enough to need a wider settle window, and the PR-thread freshness guard had to be acknowledged before merge confidence: medium-high surprises: PR #1369 still refused with 405 after the wider retry window, so the exact diagnostics are left on #1369 and this issue for later follow-up follow-ups: watch #1369 for a later merge opportunity; keep the retry window change if the queue lag repeats </details>

coilyco-ops referenced this issue

2026-07-15 09:52:05 +00:00

Recover PR #1369 after widened retry still 405 #1378

coilyco-ops commented

2026-07-15 09:54:05 +00:00

Author

Member

QA after merge #1374:

PR #1374 improved Ward's retry window for transient Forgejo 405 responses, but it did not complete this issue's acceptance. PR #1369 remains open and green but unmerged:

PR #1369 state=open merged=false mergeable=false
head 1456f05378a91aee5bbca3cefd96276aa74d9cd0
combined status success: test / test (pull_request)=success

The workflow comment on this issue also notes that #1369 still refused with 405 after the wider retry window. Filed follow-up #1378 with the same labels to continue the recovery. Initial dispatch of #1378 was capacity-deferred because the repo engineer limit was full.

QA after merge #1374: PR #1374 improved Ward's retry window for transient Forgejo 405 responses, but it did not complete this issue's acceptance. PR #1369 remains open and green but unmerged: ```text PR #1369 state=open merged=false mergeable=false head 1456f05378a91aee5bbca3cefd96276aa74d9cd0 combined status success: test / test (pull_request)=success ``` The workflow comment on this issue also notes that #1369 still refused with 405 after the wider retry window. Filed follow-up #1378 with the same labels to continue the recovery. Initial dispatch of #1378 was capacity-deferred because the repo engineer limit was full.