coilyco-flight-deck/ward

Fork 0

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

New issue

Closed

opened 2026-07-15 06:33:59 +00:00 by coilyco-ops · 3 comments

coilyco-ops commented

2026-07-15 06:33:59 +00:00

Member

Parent

ward#1077

What to build

Route pre-flight output to the launched agent, not only to host logs. The dispatchee should start with the launch checks that applied to its own run, including gates, re-checks, and resolved context.

Acceptance criteria

The launched agent receives its own pre-flight log in its seed context or equivalent startup artifact.
The log includes what pre-flight checked and whether each relevant gate passed, deferred, or refused.
The log includes resolved launch context needed by the dispatchee, such as issue or PR ref, branch mode, workflow, and reservation state.
The implementation keeps dispatcher broker logs and dispatchee pre-flight logs as separate audiences.
A test or fixture proves pre-flight output is visible to the launched agent without reading host logs.

Decision for headless carry

This was split out of ward#1077 because it is the missing second direction: pre-flight to dispatchee.

## Parent ward#1077 ## What to build Route pre-flight output to the launched agent, not only to host logs. The dispatchee should start with the launch checks that applied to its own run, including gates, re-checks, and resolved context. ## Acceptance criteria - [ ] The launched agent receives its own pre-flight log in its seed context or equivalent startup artifact. - [ ] The log includes what pre-flight checked and whether each relevant gate passed, deferred, or refused. - [ ] The log includes resolved launch context needed by the dispatchee, such as issue or PR ref, branch mode, workflow, and reservation state. - [ ] The implementation keeps dispatcher broker logs and dispatchee pre-flight logs as separate audiences. - [ ] A test or fixture proves pre-flight output is visible to the launched agent without reading host logs. ## Decision for headless carry This was split out of ward#1077 because it is the missing second direction: pre-flight to dispatchee.

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

2026-07-15 06:33:59 +00:00

coilyco-ops added the

headless

labels

2026-07-15 06:33:59 +00:00

coilyco-ops commented

2026-07-15 07:16:43 +00:00

Author

Member

WARD-TRIAGE: warded control plane coherence milestone

This issue is part of the warded control plane coherence sprint. The release thesis is to make warded feel like one dependable control plane for agent work: higher safe parallelism, coherent config defaults, reliable broker/container behavior, human-feedback gates, and enough structured evidence for the next actor after a paused or failed run.

For this sprint, headless means an engineer should be able to carry the issue from current issue context to a merged change without new human decisions. If the issue discovers a missing decision, split or demote the unclear part instead of guessing.

WARD-TRIAGE: warded control plane coherence milestone This issue is part of the `warded control plane coherence` sprint. The release thesis is to make `warded` feel like one dependable control plane for agent work: higher safe parallelism, coherent config defaults, reliable broker/container behavior, human-feedback gates, and enough structured evidence for the next actor after a paused or failed run. For this sprint, `headless` means an engineer should be able to carry the issue from current issue context to a merged change without new human decisions. If the issue discovers a missing decision, split or demote the unclear part instead of guessing.

coilyco-ops commented

2026-07-15 11:18:14 +00:00

Author

Member

WARDED_WORKFLOW: reservation-held

reservation details

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

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

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-1335` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness codex` (reserved 2026-07-15T11:18:13Z). 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#1335` · branch `issue-1335` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-1335` · ward `v0.710.0` · dispatched `2026-07-15T11:18:09Z` - **Comment thread:** 1 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-15T07:16:43Z) 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 11:31:34 +00:00

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

coilyco-ops referenced this issue

2026-07-15 11:42:31 +00:00

Recover stuck PR #1407 check after runner context cancellation #1413

coilyco-ops referenced this issue

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

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

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:00:13 +00:00

Diagnose broker-forwarded dispatches that leave no reservation or running engineer #1418

coilyco-ops closed this issue

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

coilyco-ops referenced this issue

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

Repair failed promote run after PR #1407 #1422

coilyco-ops commented

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

Author

Member

QA FAIL post-merge check on 2026-07-15: PR #1407 closed this issue, but the merged seed still rendered reservation re-check: passed before the remote reservation re-check result was known, and also for skipped pre-flight launches. That misses the acceptance requirement that launched-agent pre-flight output report each relevant gate as passed, deferred, or refused truthfully.

Follow-up was already filed as #1417 with the same headless and P2 labels and dispatched as engineer-codex-ward-1417. Current PR #1424 changes the seed wording to reservation re-check: deferred and covers normal plus --skip-preflight, but it is waiting on the separate CI tempdir cleanup failure tracked by #1423 before merge.

QA FAIL post-merge check on 2026-07-15: PR #1407 closed this issue, but the merged seed still rendered `reservation re-check: passed` before the remote reservation re-check result was known, and also for skipped pre-flight launches. That misses the acceptance requirement that launched-agent pre-flight output report each relevant gate as passed, deferred, or refused truthfully. Follow-up was already filed as #1417 with the same `headless` and `P2` labels and dispatched as `engineer-codex-ward-1417`. Current PR #1424 changes the seed wording to `reservation re-check: deferred` and covers normal plus `--skip-preflight`, but it is waiting on the separate CI tempdir cleanup failure tracked by #1423 before merge.