coilyco-flight-deck/ward

Fork 0

Finish dispatch-path partial-launch guarantees after #1359 #1360

New issue

Closed

opened 2026-07-15 08:50:59 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-15 08:50:59 +00:00

Member

Replacement QA issue after PR #1359 / issue #1353.

PR #1359 landed useful visibility work:

ward agent list can mark a running engineer as partial-launch when the issue thread lacks a reservation-held marker.
ward agent dispatch-health now carries a partial_launch count and partial-launch signal.
Focused local verification passed: go test ./cmd/ward -run 'PartialLaunch|DispatchHealth|AgentList|Reservation|RunningEngineer' -count=1.
Forgejo test run 8387 passed and PR #1359 merged at 2026-07-15T08:49:57Z.

However, the original #1353 acceptance was broader than the visibility surfaces. The merged patch does not appear to fix or pin the dispatch path that produced the incident:

A dispatch path must not both launch a container and report only repo-capacity failure to the director.
There should be focused coverage for the success-after-capacity-check path.
There should be focused coverage for the comment-failure/partial-launch path at launch/final dispatch output, not only later list/health inspection.

Observed scope gap in #1359:

Changed files were cmd/ward/agent_list.go, cmd/ward/agent_list_test.go, cmd/ward/agent_dispatch_health.go, and cmd/ward/agent_dispatch_health_test.go.
No dispatch launch/broker path changed, so a launch that succeeds after a capacity check can still plausibly return only the capacity failure that misled the director in #1353.

Acceptance:

Identify the dispatch path that allowed a running container to be paired with capacity-blocked director output.
Add a regression proving Ward cannot launch an engineer and report only repo-capacity failure for that same attempt.
If reservation comment creation fails after launch, the immediate dispatch output must include an actionable partial-launch state with repo, issue, container, and remediation.
Keep the #1359 agent list / dispatch-health visibility behavior intact.
Add focused tests for both the success-after-capacity-check and comment-failure-after-launch cases.

This carries the same labels and milestone as #1353 because #1359 did not fully satisfy the linked issue criteria.

Replacement QA issue after PR #1359 / issue #1353. PR #1359 landed useful visibility work: - `ward agent list` can mark a running engineer as `partial-launch` when the issue thread lacks a reservation-held marker. - `ward agent dispatch-health` now carries a `partial_launch` count and `partial-launch` signal. - Focused local verification passed: `go test ./cmd/ward -run 'PartialLaunch|DispatchHealth|AgentList|Reservation|RunningEngineer' -count=1`. - Forgejo test run 8387 passed and PR #1359 merged at `2026-07-15T08:49:57Z`. However, the original #1353 acceptance was broader than the visibility surfaces. The merged patch does not appear to fix or pin the dispatch path that produced the incident: - A dispatch path must not both launch a container and report only repo-capacity failure to the director. - There should be focused coverage for the success-after-capacity-check path. - There should be focused coverage for the comment-failure/partial-launch path at launch/final dispatch output, not only later list/health inspection. Observed scope gap in #1359: - Changed files were `cmd/ward/agent_list.go`, `cmd/ward/agent_list_test.go`, `cmd/ward/agent_dispatch_health.go`, and `cmd/ward/agent_dispatch_health_test.go`. - No dispatch launch/broker path changed, so a launch that succeeds after a capacity check can still plausibly return only the capacity failure that misled the director in #1353. Acceptance: - Identify the dispatch path that allowed a running container to be paired with capacity-blocked director output. - Add a regression proving Ward cannot launch an engineer and report only repo-capacity failure for that same attempt. - If reservation comment creation fails after launch, the immediate dispatch output must include an actionable partial-launch state with repo, issue, container, and remediation. - Keep the #1359 `agent list` / `dispatch-health` visibility behavior intact. - Add focused tests for both the success-after-capacity-check and comment-failure-after-launch cases. This carries the same labels and milestone as #1353 because #1359 did not fully satisfy the linked issue criteria.

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

2026-07-15 08:50:59 +00:00

coilyco-ops added the

coherence-core

headless

labels

2026-07-15 08:50:59 +00:00

coilyco-ops referenced this issue

2026-07-15 08:51:11 +00:00

Record partial launches when a running engineer lacks an issue reservation marker #1353

coilyco-ops commented

2026-07-15 08:51:22 +00:00

Author

Member

WARDED_WORKFLOW: reservation-held

reservation details

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

Accepted by ward agent --harness codex (reserved 2026-07-15T08:51:21Z). 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#1360 · branch issue-1360 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-1360 · ward v0.710.0 · dispatched 2026-07-15T08:51:18Z
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-1360` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness codex` (reserved 2026-07-15T08:51:21Z). 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#1360` · branch `issue-1360` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-1360` · ward `v0.710.0` · dispatched `2026-07-15T08:51:18Z` - **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:09:48 +00:00

Finish dispatch-path partial-launch guarantees after #1359 #1362

coilyco-ops closed this issue

2026-07-15 09:11:07 +00:00

coilyco-ops commented

2026-07-15 09:11:27 +00:00

Author

Member

WARDED_WORKFLOW: #1362

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).

Implementation felt narrow but slightly brittle around the launch/reservation seam; the main surprise was the lint gate forcing the broker launch handler to be split before merge.

Confidence: high.
Follow-ups: none.

WARDED_WORKFLOW: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/pulls/1362 <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). Implementation felt narrow but slightly brittle around the launch/reservation seam; the main surprise was the lint gate forcing the broker launch handler to be split before merge. Confidence: high. Follow-ups: none. </details>

coilyco-ops referenced this issue

2026-07-15 09:18:27 +00:00

Repair failed promote run after PR #1362 #1364