coilyco-flight-deck/ward

Fork 0

Support local ward config file refs for setup-generated config #1340

New issue

Closed

opened 2026-07-15 06:39:25 +00:00 by coilyco-ops · 4 comments

coilyco-ops commented

2026-07-15 06:39:25 +00:00

Member

Parent

ward#1059

What to build

Support pointing the ward config resolver at a local config file produced by setup, without requiring a remote bundle ref on the first-run path.

Acceptance criteria

The config resolver accepts a documented local file ref or path for setup-generated config.
Local file config resolution uses the same parser and validation as remote config.
Missing local files fail with an actionable message.
The first-setup docs or help output show the local config path form.
Tests cover successful local config resolution and missing-file failure.

Decision for headless carry

Kai confirmed ward#1059 needs fine-grained issues. This child covers only local config file resolution for setup.

## Parent ward#1059 ## What to build Support pointing the ward config resolver at a local config file produced by setup, without requiring a remote bundle ref on the first-run path. ## Acceptance criteria - [ ] The config resolver accepts a documented local file ref or path for setup-generated config. - [ ] Local file config resolution uses the same parser and validation as remote config. - [ ] Missing local files fail with an actionable message. - [ ] The first-setup docs or help output show the local config path form. - [ ] Tests cover successful local config resolution and missing-file failure. ## Decision for headless carry Kai confirmed ward#1059 needs fine-grained issues. This child covers only local config file resolution for setup.

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

2026-07-15 06:39:25 +00:00

coilyco-ops added the

headless

labels

2026-07-15 06:39:25 +00:00

coilyco-ops commented

2026-07-15 07:16:45 +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 10:49:51 +00:00

Author

Member

WARDED_WORKFLOW: reservation-held

reservation details

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

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

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-1340` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness codex` (reserved 2026-07-15T10:49:50Z). 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#1340` · branch `issue-1340` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-1340` · ward `v0.710.0` · dispatched `2026-07-15T10:49:42Z` - **Comment thread:** 1 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-15T07:16:45Z) 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 10:55:37 +00:00

Support local ward config file refs for setup-generated config #1394

coilyco-ops commented

2026-07-15 10:57:04 +00:00

Author

Member

WARDED_WORKFLOW: #1394

details

workflow: pull-request-and-merge; review summary: review gate intentionally skipped because the temporary ward default pending brokered QA
felt: straightforward; the resolver already had the local-file seam, so this was mostly tightening the user-facing path and coverage
confidence: high
surprises: none
follow-ups: none

WARDED_WORKFLOW: https://forgejo.coilysiren.me/coilyco-flight-deck/ward/pulls/1394 <details><summary>details</summary> workflow: pull-request-and-merge; review summary: review gate intentionally skipped because the temporary ward default pending brokered QA felt: straightforward; the resolver already had the local-file seam, so this was mostly tightening the user-facing path and coverage confidence: high surprises: none follow-ups: none </details>

coilyco-ops closed this issue

2026-07-15 10:57:41 +00:00

coilyco-ops commented

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

Author

Member

QA review after PR #1394 (0ae06d661bdb32538346d05d0ccdce5f155d52e5): code-level PASS, release verification pending/blocked by #1393.

Evidence checked:

PR #1394 merged through ward agent pr merge with head 73eb45829d1d6127b94e40fdc0f22013c0a80d67 and green test / test (pull_request).
selectConfigSource already routes local files through localConfigSource, which uses bundleFileConfigSource, preserving the same KDL parsing/validation path used by setup surfaces.
The change tightens missing local file diagnostics to name WARD_CONFIG_REF and the setup-generated local config path.
Existing setup tests cover successful relative local file resolution; #1394 adds missing-file coverage and first-setup help/docs text for /path/to/ward-config.kdl and file:///path/to/ward-config.kdl.
Focused local test on origin/main: env WARD_READONLY=0 WARD_DISPATCH_BROKER_ADDR= WARD_DISPATCH_BROKER_TOKEN= WARD_CONFIG_REF=file:///scratch/ward-main-qa/.ward/ward-kdl go test ./cmd/ward -run 'TestSelectConfigSource|TestSetup' -count=1 passed.

Caveat: promote run 8481 started for this merge, but the release path is already known blocked by #1393 until the draft-release creation bug is repaired.

QA review after PR #1394 (`0ae06d661bdb32538346d05d0ccdce5f155d52e5`): code-level PASS, release verification pending/blocked by #1393. Evidence checked: - PR #1394 merged through `ward agent pr merge` with head `73eb45829d1d6127b94e40fdc0f22013c0a80d67` and green `test / test (pull_request)`. - `selectConfigSource` already routes local files through `localConfigSource`, which uses `bundleFileConfigSource`, preserving the same KDL parsing/validation path used by setup surfaces. - The change tightens missing local file diagnostics to name `WARD_CONFIG_REF` and the setup-generated local config path. - Existing setup tests cover successful relative local file resolution; #1394 adds missing-file coverage and first-setup help/docs text for `/path/to/ward-config.kdl` and `file:///path/to/ward-config.kdl`. - Focused local test on `origin/main`: `env WARD_READONLY=0 WARD_DISPATCH_BROKER_ADDR= WARD_DISPATCH_BROKER_TOKEN= WARD_CONFIG_REF=file:///scratch/ward-main-qa/.ward/ward-kdl go test ./cmd/ward -run 'TestSelectConfigSource|TestSetup' -count=1` passed. Caveat: promote run 8481 started for this merge, but the release path is already known blocked by #1393 until the draft-release creation bug is repaired.