Correct launch pre-flight seed reservation re-check status

coilyco-ops commented

2026-07-15 11:55:36 +00:00

Member

Problem

QA on PR #1407 for #1335 found that the launched-agent pre-flight seed block reports the reservation re-check as passed before that result is actually known.

Current PR #1407 builds the launch pre-flight seed block in launchAgentContainer before reserveIssue runs the remote reservation re-check. launchPreflightSeedContext then always renders:

reservation re-check: passed

That is inaccurate in at least two cases:

Normal launch path: the seed is composed before reservationRecheckLost confirms or yields, so the block is claiming a future result.
--skip-preflight path: reservationRecheckLost explicitly logs skipping reservation re-check (--skip-preflight), but the launched seed still says it passed.

This misses #1335's acceptance detail that the launched agent's pre-flight artifact should include what was checked and whether each relevant gate passed, deferred, or refused. The artifact must not report skipped or not-yet-run gates as passed.

Acceptance

Update the launched-agent pre-flight seed block so reservation re-check status is truthful.
Normal successful launches should show the re-check as passed only after it actually passes, or otherwise use a truthful pending/deferred phrasing if the seed cannot know the final result at construction time.
--skip-preflight / --no-preflight launches must not say the reservation re-check passed when ward skipped it.
Add or update tests that cover at least the skipped re-check path and the normal rendered status.
Re-check PR #1407 / #1335 after the fix before merging.

Related: #1335, #1407.

## Problem QA on PR #1407 for #1335 found that the launched-agent pre-flight seed block reports the reservation re-check as passed before that result is actually known. Current PR #1407 builds the launch pre-flight seed block in `launchAgentContainer` before `reserveIssue` runs the remote reservation re-check. `launchPreflightSeedContext` then always renders: ```text reservation re-check: passed ``` That is inaccurate in at least two cases: - Normal launch path: the seed is composed before `reservationRecheckLost` confirms or yields, so the block is claiming a future result. - `--skip-preflight` path: `reservationRecheckLost` explicitly logs `skipping reservation re-check (--skip-preflight)`, but the launched seed still says it passed. This misses #1335's acceptance detail that the launched agent's pre-flight artifact should include what was checked and whether each relevant gate passed, deferred, or refused. The artifact must not report skipped or not-yet-run gates as passed. ## Acceptance - Update the launched-agent pre-flight seed block so reservation re-check status is truthful. - Normal successful launches should show the re-check as passed only after it actually passes, or otherwise use a truthful pending/deferred phrasing if the seed cannot know the final result at construction time. - `--skip-preflight` / `--no-preflight` launches must not say the reservation re-check passed when ward skipped it. - Add or update tests that cover at least the skipped re-check path and the normal rendered status. - Re-check PR #1407 / #1335 after the fix before merging. Related: #1335, #1407.

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

2026-07-15 11:55:36 +00:00

coilyco-ops added the

headless

P2

labels

2026-07-15 11:55:36 +00:00

coilyco-ops commented

2026-07-15 11:56:05 +00:00

Author

Member

DISPATCH-DEFERRED: capacity blocked. Attempted warded engineer coilyco-flight-deck/ward#1417 --harness codex --workflow pull-request-and-merge at 2026-07-15T11:55Z from the director surface. Ward rejected the launch because coilyco-flight-deck/ward already has 3 active engineers at the repo limit. Broker evidence: repo engineer limit is reached for coilyco-flight-deck/ward: 3 active engineer(s) (limit 3). Dispatch log: /Users/kai/.ward/agent-logs/dispatch/20260715T115542Z-director-codex-jp85-coilyco-flight-deck-ward-1417.log. Retry this #1335/#1407 QA follow-up as soon as a slot opens.

coilyco-ops referenced this issue

2026-07-15 11:56:05 +00:00

Inject pre-flight launch logs into the launched agent context #1407

coilyco-ops referenced this issue

2026-07-15 12:05:06 +00:00

Inject pre-flight launch logs into the launched agent context #1407

coilyco-ops commented

2026-07-15 12:08:21 +00:00

Author

Member

WARDED_WORKFLOW: reservation-held

reservation details

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

Accepted by ward agent --harness codex (reserved 2026-07-15T12:08:20Z). 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#1417 · branch issue-1417 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-1417 · ward v0.710.0 · dispatched 2026-07-15T12:08:15Z
Comment thread: 1 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-15T11:56:05Z)

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-1417` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness codex` (reserved 2026-07-15T12:08:20Z). 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#1417` · branch `issue-1417` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-1417` · ward `v0.710.0` · dispatched `2026-07-15T12:08:15Z` - **Comment thread:** 1 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-15T11:56:05Z) 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 commit

2026-07-15 12:12:04 +00:00

Correct launch pre-flight seed re-check status (#1417)

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

2026-07-15 12:12:34 +00:00

Correct launch pre-flight seed reservation re-check status #1424

coilyco-ops referenced this issue

2026-07-15 12:17:25 +00:00

Inject pre-flight launch logs into the launched agent context #1335

coilyco-ops commented

2026-07-15 12:17:57 +00:00

Author

Member

Forgejo PR check failed on go test for commit 5b969fabb19c22c202213ff2a25875339520e6a4 (run 8531 / job 14285).

I reproduced the repo checks locally with make vet, make test, and make lint; they all pass here, so this looks like a runner/transient mismatch rather than a code regression. I am retriggering the PR workflow with a fresh push to confirm.

Forgejo PR check failed on `go test` for commit `5b969fabb19c22c202213ff2a25875339520e6a4` (run 8531 / job 14285). I reproduced the repo checks locally with `make vet`, `make test`, and `make lint`; they all pass here, so this looks like a runner/transient mismatch rather than a code regression. I am retriggering the PR workflow with a fresh push to confirm.

coilyco-ops referenced this issue from a commit

2026-07-15 12:18:10 +00:00

chore: retrigger PR #1417 checks

coilyco-ops closed this issue

2026-07-15 12:19:30 +00:00

Rows
Columns

Correct launch pre-flight seed reservation re-check status #1417

Problem

Acceptance