coilyco-flight-deck/ward

Fork 0

Broaden --skip-preflight to launch-adjacent network and reservation checks #695

New issue

Closed

opened 2026-07-08 20:47:10 +00:00 by coilyco-ops · 3 comments

coilyco-ops commented

2026-07-08 20:47:10 +00:00

Member

Goal

Make --skip-preflight cover the full launch-adjacent preflight bucket, not only the narrow issue feasibility/preflight gate.

Context

Kai noticed this while looking at a dispatch that prints reservation re-check waiting. That wait belongs in the same functional bucket as --skip-preflight: it is a launch-adjacent guard that can block or delay startup before the engineer is doing work.

The same applies to other launch-time checks that perform network requests or external state probes, including checks around updating the ward binary, pulling a new image, probing launch viability, and similar setup gates. This is tangential to the current failing dispatches.

Current problem

--skip-preflight reads like an operator escape hatch for pre-start checks, but some preflighty work still happens outside that flag. That makes the flag less predictable when a director or operator intentionally wants to bypass startup probes and get to the run attempt.

Do

Inventory launch-adjacent preflight steps in ward agent, including:
- issue feasibility/preflight checks
- reservation re-check waits such as reservation re-check waiting
- binary update checks
- image pull/update checks
- harness launch probes
- other network or external-state checks before the task prompt starts
Define which steps are covered by --skip-preflight and which are mandatory safety boundaries that must never be skipped.
Wire the covered checks through the existing skip flag.
Make skipped output explicit enough to diagnose, e.g. ward agent: skipping reservation re-check (--skip-preflight).
Preserve hard safety invariants: do not use this to skip trust/credential boundaries, destructive-action protections, or closed-issue handling unless the repo already treats those as preflight-skippable.
Update docs for --skip-preflight so the scope matches behavior.
Add regression tests for at least the reservation re-check path and one network/update-check path.

Acceptance

Running ward agent ... --skip-preflight skips the reservation re-check wait.
The same flag skips covered binary/image/network pre-start probes.
Mandatory safety checks still run and are documented as non-skippable.
User-visible output says which covered preflight checks were skipped.
ward exec test passes.

Filed from the read-only director surface after Kai identified the reservation re-check wait as part of the same functional bucket as --skip-preflight.

## Goal Make `--skip-preflight` cover the full launch-adjacent preflight bucket, not only the narrow issue feasibility/preflight gate. ## Context Kai noticed this while looking at a dispatch that prints `reservation re-check waiting`. That wait belongs in the same functional bucket as `--skip-preflight`: it is a launch-adjacent guard that can block or delay startup before the engineer is doing work. The same applies to other launch-time checks that perform network requests or external state probes, including checks around updating the ward binary, pulling a new image, probing launch viability, and similar setup gates. This is tangential to the current failing dispatches. ## Current problem `--skip-preflight` reads like an operator escape hatch for pre-start checks, but some preflighty work still happens outside that flag. That makes the flag less predictable when a director or operator intentionally wants to bypass startup probes and get to the run attempt. ## Do * Inventory launch-adjacent preflight steps in `ward agent`, including: * issue feasibility/preflight checks * reservation re-check waits such as `reservation re-check waiting` * binary update checks * image pull/update checks * harness launch probes * other network or external-state checks before the task prompt starts * Define which steps are covered by `--skip-preflight` and which are mandatory safety boundaries that must never be skipped. * Wire the covered checks through the existing skip flag. * Make skipped output explicit enough to diagnose, e.g. `ward agent: skipping reservation re-check (--skip-preflight)`. * Preserve hard safety invariants: do not use this to skip trust/credential boundaries, destructive-action protections, or closed-issue handling unless the repo already treats those as preflight-skippable. * Update docs for `--skip-preflight` so the scope matches behavior. * Add regression tests for at least the reservation re-check path and one network/update-check path. ## Acceptance * Running `ward agent ... --skip-preflight` skips the reservation re-check wait. * The same flag skips covered binary/image/network pre-start probes. * Mandatory safety checks still run and are documented as non-skippable. * User-visible output says which covered preflight checks were skipped. * `ward exec test` passes. Filed from the read-only director surface after Kai identified the reservation re-check wait as part of the same functional bucket as `--skip-preflight`.

coilyco-ops commented

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

Author

Member

🔒 Reserved by ward agent --harness codex — container engineer-codex-ward-695 on host kais-macbook-pro-2.local is carrying this issue (reserved 2026-07-08T21:56:11Z). 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#695 · branch issue-695 · harness codex · workflow direct-main
Run: engineer-codex-ward-695 · ward v0.466.0 · dispatched 2026-07-08T21:56:11Z
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.466.0).

— Codex, via ward agent

🔒 Reserved by `ward agent --harness codex` — container `engineer-codex-ward-695` on host `kais-macbook-pro-2.local` is carrying this issue (reserved 2026-07-08T21:56:11Z). 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#695` · branch `issue-695` · harness `codex` · workflow `direct-main` - **Run:** `engineer-codex-ward-695` · ward `v0.466.0` · dispatched `2026-07-08T21:56:11Z` - **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.466.0). </details>  — Codex, via `ward agent`

coilyco-ops added the

headless

labels

2026-07-09 06:38:30 +00:00

coilyco-ops commented

2026-07-09 17:55:50 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-09T17:55:48Z). 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#695 · branch issue-695 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-695 · ward v0.493.0 · dispatched 2026-07-09T17:55:48Z
Comment thread: 0 included in the pre-flight read, 1 stripped (ward's own automated comments).
- stripped: @coilyco-ops (2026-07-08T21:56:12Z)

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-695` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-09T17:55:48Z). 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#695` · branch `issue-695` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-695` · ward `v0.493.0` · dispatched `2026-07-09T17:55:48Z` - **Comment thread:** 0 included in the pre-flight read, 1 stripped (ward's own automated comments). - stripped: @coilyco-ops (2026-07-08T21:56:12Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.493.0). </details> </details>  — Codex, via `ward agent`

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

2026-07-09 18:09:36 +00:00

Broaden --skip-preflight to launch-adjacent network and reservation checks #837

coilyco-ops closed this issue

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

coilyco-ops commented

2026-07-09 18:18:19 +00:00

Author

Member

WARD-OUTCOME: done ✅

details

workflow: pull-request-and-merge; review summary: review gate skipped by --skip-review / --no-review-gate

The implementation felt straightforward after the lint feedback: the behavior change stayed small, and the only real wrinkle was keeping golangci-lint happy without dropping coverage.
Confidence: high.
Surprises: Forgejo reran the PR on a new run number after the repush, and the local workspace hit disk pressure until caches were cleared.
Follow-ups: none.

WARD-OUTCOME: done ✅ <details><summary>details</summary> workflow: pull-request-and-merge; review summary: review gate skipped by --skip-review / --no-review-gate The implementation felt straightforward after the lint feedback: the behavior change stayed small, and the only real wrinkle was keeping golangci-lint happy without dropping coverage. Confidence: high. Surprises: Forgejo reran the PR on a new run number after the repush, and the local workspace hit disk pressure until caches were cleared. Follow-ups: none. </details>