Add ward doctor config validation command

coilyco-ops commented

2026-07-10 04:42:59 +00:00

Member

Add a top-level ward doctor command that validates the runtime configuration ward must have in order to operate safely.

Problem:

Ward can currently fall back to neutral/example configuration or accept malformed deployment configuration until a later command fails.
Kai specifically called out example repos / example owners as a class of config that must not survive in an operating deployment.
AOS now supplies the coilyco config bundle through WARD_CONFIG_REF=forgejo.coilysiren.me/coilyco-flight-deck/agentic-os@main//.ward; ward needs a first-class way to assert that the selected config is both present and valid.

Scope:

Add ward doctor as a user-facing command, near ward setup in command shape.
Resolve the same config inputs real ward commands use, including WARD_CONFIG_REF and embedded defaults.
Validate every config surface that controls whether ward can operate safely, including at least:
- smart-defaults / required operational defaults,
- repo-authority trusted owners and repo routing,
- fleet/agent/role config,
- guarded ops / spec bundle inputs where they are selected by the runtime config.
Fail loudly when required deployment values are still placeholders or examples. Reference #930 for the narrower placeholder repo cleanup, but doctor should catch this class generally.
Validate values and schema strictly: no unknown keys, no unknown blocks, valid enum values, valid durations/numbers, valid owner/repo patterns, valid forge names, no duplicate/conflicting entries, and no missing required blocks.
Keep output concise and actionable: print grouped PASS/FAIL lines and exit non-zero on any failure.
Add tests that exercise both a valid config and representative failures: unknown keys, bad enum, missing required block, placeholder/example owner or repo, malformed repo pattern, invalid duration/number.
Document the command in the appropriate ward docs/command help.

Acceptance:

ward doctor exits 0 against a valid coilyco WARD_CONFIG_REF bundle.
ward doctor exits non-zero against neutral/example/default placeholder config when that config would not be acceptable for an operating coilyco deployment.
The validator reports unknown or extra keys/blocks rather than ignoring them.
Tests cover strict validation and placeholder/example detection.

Follow-on: agentic-os needs to run this during the dev-base Docker build once a ward release includes the command.

Add a top-level `ward doctor` command that validates the runtime configuration ward must have in order to operate safely. Problem: * Ward can currently fall back to neutral/example configuration or accept malformed deployment configuration until a later command fails. * Kai specifically called out example repos / example owners as a class of config that must not survive in an operating deployment. * AOS now supplies the coilyco config bundle through `WARD_CONFIG_REF=forgejo.coilysiren.me/coilyco-flight-deck/agentic-os@main//.ward`; ward needs a first-class way to assert that the selected config is both present and valid. Scope: * Add `ward doctor` as a user-facing command, near `ward setup` in command shape. * Resolve the same config inputs real ward commands use, including `WARD_CONFIG_REF` and embedded defaults. * Validate every config surface that controls whether ward can operate safely, including at least: * smart-defaults / required operational defaults, * repo-authority trusted owners and repo routing, * fleet/agent/role config, * guarded ops / spec bundle inputs where they are selected by the runtime config. * Fail loudly when required deployment values are still placeholders or examples. Reference #930 for the narrower placeholder repo cleanup, but `doctor` should catch this class generally. * Validate values and schema strictly: no unknown keys, no unknown blocks, valid enum values, valid durations/numbers, valid owner/repo patterns, valid forge names, no duplicate/conflicting entries, and no missing required blocks. * Keep output concise and actionable: print grouped PASS/FAIL lines and exit non-zero on any failure. * Add tests that exercise both a valid config and representative failures: unknown keys, bad enum, missing required block, placeholder/example owner or repo, malformed repo pattern, invalid duration/number. * Document the command in the appropriate ward docs/command help. Acceptance: * `ward doctor` exits 0 against a valid coilyco `WARD_CONFIG_REF` bundle. * `ward doctor` exits non-zero against neutral/example/default placeholder config when that config would not be acceptable for an operating coilyco deployment. * The validator reports unknown or extra keys/blocks rather than ignoring them. * Tests cover strict validation and placeholder/example detection. Follow-on: agentic-os needs to run this during the dev-base Docker build once a ward release includes the command.

coilyco-ops referenced this issue from coilyco-flight-deck/agentic-os

2026-07-10 04:43:14 +00:00

Run ward doctor during dev-base Docker build #408

coilyco-ops commented

2026-07-10 04:43:27 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T04:43:26Z). 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#940 · branch issue-940 · harness codex · workflow pull-requests
Run: engineer-codex-ward-940 · ward v0.555.0 · dispatched 2026-07-10T04:43:26Z
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.555.0).

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-940` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T04:43:26Z). 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#940` · branch `issue-940` · harness `codex` · workflow `pull-requests` - **Run:** `engineer-codex-ward-940` · ward `v0.555.0` · dispatched `2026-07-10T04:43:26Z` - **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.555.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops referenced this issue

2026-07-10 04:46:49 +00:00

Fail early when coilyco surfaces resolve neutral example ops config #942

coilyco-ops commented

2026-07-10 05:01:47 +00:00

Author

Member

WARD-RESERVATION: released 🛑

release details

Run never started. ward container reap released container ward (--harness codex): it exited without launching the agent (smoke-test death, ward#222/#264/#595), so it did no work and the hold it took is retracted. Nothing is running on this issue. It needs re-dispatch. A ward agent director re-queues it automatically. A manual ward agent retry no longer needs --force.

— Codex, via ward agent

WARD-RESERVATION: released 🛑 <details><summary>release details</summary> Run never started. `ward container reap` released container `ward` (`--harness codex`): it exited without launching the agent (smoke-test death, ward#222/#264/#595), so it did no work and the hold it took is retracted. Nothing is running on this issue. It needs re-dispatch. A `ward agent director` re-queues it automatically. A manual `ward agent` retry no longer needs `--force`. </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-10 05:02:05 +00:00

Author

Member

WARD-RESERVATION: released 🛑

release details

Run never started. ward container reap released container ward (--harness codex): it exited without launching the agent (smoke-test death, ward#222/#264/#595), so it did no work and the hold it took is retracted. Nothing is running on this issue. It needs re-dispatch. A ward agent director re-queues it automatically. A manual ward agent retry no longer needs --force.

— Codex, via ward agent

WARD-RESERVATION: released 🛑 <details><summary>release details</summary> Run never started. `ward container reap` released container `ward` (`--harness codex`): it exited without launching the agent (smoke-test death, ward#222/#264/#595), so it did no work and the hold it took is retracted. Nothing is running on this issue. It needs re-dispatch. A `ward agent director` re-queues it automatically. A manual `ward agent` retry no longer needs `--force`. </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-10 05:02:47 +00:00

Author

Member

WARD-RESERVATION: released 🛑

release details

Run never started. ward container reap released container ward (--harness codex): it exited without launching the agent (smoke-test death, ward#222/#264/#595), so it did no work and the hold it took is retracted. Nothing is running on this issue. It needs re-dispatch. A ward agent director re-queues it automatically. A manual ward agent retry no longer needs --force.

— Codex, via ward agent

WARD-RESERVATION: released 🛑 <details><summary>release details</summary> Run never started. `ward container reap` released container `ward` (`--harness codex`): it exited without launching the agent (smoke-test death, ward#222/#264/#595), so it did no work and the hold it took is retracted. Nothing is running on this issue. It needs re-dispatch. A `ward agent director` re-queues it automatically. A manual `ward agent` retry no longer needs `--force`. </details>  — Codex, via `ward agent`

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

2026-07-10 05:09:17 +00:00

feat: add ward doctor config validation #949

coilyco-ops commented

2026-07-10 05:12:04 +00:00

Author

Member

WARD-OUTCOME: failed ❌

details

workflow: pull-requests; review summary: review gate skipped by ~/.ward/config.yaml default
The branch is pushed and PR #949 is open, but the required CI failed at golangci-lint with no space left on device during Go typecheck. I could not make the run green in this container without external disk-space relief.

WARD-OUTCOME: failed ❌ <details><summary>details</summary> workflow: pull-requests; review summary: review gate skipped by ~/.ward/config.yaml default The branch is pushed and PR #949 is open, but the required CI failed at `golangci-lint` with `no space left on device` during Go typecheck. I could not make the run green in this container without external disk-space relief. </details>

coilyco-ops commented

2026-07-10 05:48:54 +00:00

Author

Member

WARD-RESERVATION: held 🔒

reservation details

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

Reserved by ward agent --harness codex (reserved 2026-07-10T05:48:53Z). 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#940 · branch issue-940 · harness codex · workflow pull-requests
Run: engineer-codex-ward-940 · ward v0.555.0 · dispatched 2026-07-10T05:48:53Z
Comment thread: 4 included in the pre-flight read, 1 stripped (ward's own automated comments).
- included: @coilyco-ops (2026-07-10T05:01:47Z), @coilyco-ops (2026-07-10T05:02:05Z), @coilyco-ops (2026-07-10T05:02:47Z), @coilyco-ops (2026-07-10T05:12:04Z)
- stripped: @coilyco-ops (2026-07-10T04:43:27Z)

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

— Codex, via ward agent

WARD-RESERVATION: held 🔒 <details><summary>reservation details</summary> Holder: container `engineer-codex-ward-940` on host `kais-macbook-pro-2.local`. Reserved by `ward agent --harness codex` (reserved 2026-07-10T05:48:53Z). 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#940` · branch `issue-940` · harness `codex` · workflow `pull-requests` - **Run:** `engineer-codex-ward-940` · ward `v0.555.0` · dispatched `2026-07-10T05:48:53Z` - **Comment thread:** 4 included in the pre-flight read, 1 stripped (ward's own automated comments). - included: @coilyco-ops (2026-07-10T05:01:47Z), @coilyco-ops (2026-07-10T05:02:05Z), @coilyco-ops (2026-07-10T05:02:47Z), @coilyco-ops (2026-07-10T05:12:04Z) - stripped: @coilyco-ops (2026-07-10T04:43:27Z) Static container doctrine and seed boilerplate are identical every run and omitted here (they ride ward v0.555.0). </details> </details>  — Codex, via `ward agent`

coilyco-ops commented

2026-07-10 05:53:38 +00:00

Author

Member

WARD-RESERVATION: released 🛑

release details

Run never started. ward container reap released container ward (--harness codex): it exited without launching the agent (smoke-test death, ward#222/#264/#595), so it did no work and the hold it took is retracted. Nothing is running on this issue. It needs re-dispatch. A ward agent director re-queues it automatically. A manual ward agent retry no longer needs --force.

— Codex, via ward agent

WARD-RESERVATION: released 🛑 <details><summary>release details</summary> Run never started. `ward container reap` released container `ward` (`--harness codex`): it exited without launching the agent (smoke-test death, ward#222/#264/#595), so it did no work and the hold it took is retracted. Nothing is running on this issue. It needs re-dispatch. A `ward agent director` re-queues it automatically. A manual `ward agent` retry no longer needs `--force`. </details>  — Codex, via `ward agent`

coilyco-ops closed this issue

2026-07-10 06:20:55 +00:00

Rows
Columns

Add ward doctor config validation command #940