warded ignores selected bundle agents.kdl default harness, so aos config appears active but does nothing

coilyco-ops commented

2026-07-14 05:56:53 +00:00

Member

Problem

warded director defaults to Claude even when the selected aos bundle declares Codex as the fleet default.

Observed on 2026-07-13 from coilyco-flight-deck/agentic-os:

shell bootstrap exports WARD_CONFIG_REF=file:///Users/kai/projects/coilyco-flight-deck/agentic-os/.ward.
ward doctor reports that same config source and passes.
aos .ward/agents.kdl contains defaults { agent codex }.
warded director --repo coilyco-flight-deck/agentic-os --print still resolves director harness: claude, engineer-harness: claude, and dispatch: ward agent engineer ... --harness claude.
ward agents list --json also reports baked defaults with agent: claude, even with WARD_CONFIG_REF set to the aos bundle.

This makes the aos bundle misleading: it carries and validates agents.kdl, but the core warded launch path does not use that default for the actual harness selection.

Why this is confusing

The operator sees a selected bundle in ward doctor and in warded --print, so it is reasonable to expect the bundle fleet default to drive the run. Instead, ward splits behavior:

edge/operator surfaces use the selected WARD_CONFIG_REF bundle
core agent/container paths use ward baked fleet defaults

That split may be intentional today, but it makes aos config look like it controls launch behavior when it does not.

Evidence in code

cmd/ward/fleet.go loads fleet config from coreRuntimeConfigSource().
cmd/ward/configsource.go says core agent/container paths do not depend on WARD_CONFIG_REF parsing.
cmd/ward/agent.go builds the --harness flag default from defaultAgentMode().
cmd/ward/agent_adapter.go resolves defaultAgentMode() from the core fleet default.

Ask

Pick and enforce one contract:

Make selected bundle agents.kdl and roles.kdl drive ward agent defaults, including warded director default harness and inherited engineer harness.
Or explicitly reject or ignore those fields for warded, and remove or rename the aos-side shape so it cannot look like launch config.

Acceptance

If the selected bundle says defaults { agent codex }, warded director --print resolves director harness: codex unless the user passes --harness or --agent.
If ward intentionally keeps core defaults baked, ward doctor or warded --print makes the ignored bundle fields visible so the operator does not debug shell env that is already correct.
Docs explain which config source owns harness defaults.

Filed from the agentic-os investigation after Kai noticed warded director defaulting to Claude despite aos declaring Codex.

Decision for headless carry

Chosen contract: the selected bundle should drive warded defaults when it defines them. If the selected bundle says defaults { agent codex }, warded director --print should resolve director harness codex unless the user passes --harness or --agent.

Required shape:

Make selected bundle agents.kdl and roles.kdl defaults visible to warded launch resolution.
Preserve explicit CLI flag precedence over bundle defaults.
If any field remains intentionally ignored, print that ignored status in warded --print and document why.
Add regression coverage for selected-bundle default harness and inherited engineer harness.
Keep baked defaults only as fallback when no selected bundle value exists.

## Problem `warded director` defaults to Claude even when the selected aos bundle declares Codex as the fleet default. Observed on 2026-07-13 from `coilyco-flight-deck/agentic-os`: * shell bootstrap exports `WARD_CONFIG_REF=file:///Users/kai/projects/coilyco-flight-deck/agentic-os/.ward`. * `ward doctor` reports that same config source and passes. * aos `.ward/agents.kdl` contains `defaults { agent codex }`. * `warded director --repo coilyco-flight-deck/agentic-os --print` still resolves `director harness: claude`, `engineer-harness: claude`, and `dispatch: ward agent engineer ... --harness claude`. * `ward agents list --json` also reports baked defaults with `agent: claude`, even with `WARD_CONFIG_REF` set to the aos bundle. This makes the aos bundle misleading: it carries and validates `agents.kdl`, but the core `warded` launch path does not use that default for the actual harness selection. ## Why this is confusing The operator sees a selected bundle in `ward doctor` and in `warded --print`, so it is reasonable to expect the bundle fleet default to drive the run. Instead, ward splits behavior: * edge/operator surfaces use the selected `WARD_CONFIG_REF` bundle * core agent/container paths use ward baked fleet defaults That split may be intentional today, but it makes aos config look like it controls launch behavior when it does not. ## Evidence in code * `cmd/ward/fleet.go` loads fleet config from `coreRuntimeConfigSource()`. * `cmd/ward/configsource.go` says core agent/container paths do not depend on `WARD_CONFIG_REF` parsing. * `cmd/ward/agent.go` builds the `--harness` flag default from `defaultAgentMode()`. * `cmd/ward/agent_adapter.go` resolves `defaultAgentMode()` from the core fleet default. ## Ask Pick and enforce one contract: 1. Make selected bundle `agents.kdl` and `roles.kdl` drive `ward agent` defaults, including `warded director` default harness and inherited engineer harness. 2. Or explicitly reject or ignore those fields for `warded`, and remove or rename the aos-side shape so it cannot look like launch config. ## Acceptance * If the selected bundle says `defaults { agent codex }`, `warded director --print` resolves `director harness: codex` unless the user passes `--harness` or `--agent`. * If ward intentionally keeps core defaults baked, `ward doctor` or `warded --print` makes the ignored bundle fields visible so the operator does not debug shell env that is already correct. * Docs explain which config source owns harness defaults. Filed from the agentic-os investigation after Kai noticed `warded director` defaulting to Claude despite aos declaring Codex. --- ## Decision for headless carry Chosen contract: the selected bundle should drive `warded` defaults when it defines them. If the selected bundle says `defaults { agent codex }`, `warded director --print` should resolve director harness `codex` unless the user passes `--harness` or `--agent`. Required shape: * Make selected bundle `agents.kdl` and `roles.kdl` defaults visible to warded launch resolution. * Preserve explicit CLI flag precedence over bundle defaults. * If any field remains intentionally ignored, print that ignored status in `warded --print` and document why. * Add regression coverage for selected-bundle default harness and inherited engineer harness. * Keep baked defaults only as fallback when no selected bundle value exists.

coilysiren commented

2026-07-14 05:58:20 +00:00

Owner

we should make unknown keys fail ward doctor

we should make unknown keys fail `ward doctor`

coilysiren commented

2026-07-14 05:58:41 +00:00

Owner

unknown values too, in the cases where we can enumerate possible values

coilyco-ops added the

P1

consult

labels

2026-07-14 06:50:00 +00:00

coilysiren referenced this issue

2026-07-14 15:27:09 +00:00

director should emit colorized, space buffered, visually distinct messages about the categories of actions its performing on startup #1283

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

2026-07-15 05:14:52 +00:00

coilyco-ops added

headless

and removed

consult

labels

2026-07-15 06:03:44 +00:00

coilyco-ops commented

2026-07-15 07:08:46 +00:00

Author

Member

P1 clarity note from Kai on 2026-07-15: treat this as a config inheritance/precedence question. The engineer should explicitly inspect urfave/cli default/env/file handling before inventing custom precedence. The likely tree to make explicit is config file defaults, env overrides, and CLI flags, with CLI flags winning.

coilyco-ops commented

2026-07-15 07:16:35 +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:03:32 +00:00

Author

Member

WARDED_WORKFLOW: reservation-held

reservation details

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

Accepted by ward agent --harness codex (reserved 2026-07-15T10:03:31Z). 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#1227 · branch issue-1227 · harness codex · workflow pull-request-and-merge
Run: engineer-codex-ward-1227 · ward v0.710.0 · dispatched 2026-07-15T10:03:23Z
Comment thread: 4 included in the pre-flight read, 0 stripped (ward's own automated comments).
- included: @coilysiren (2026-07-14T05:58:20Z), @coilysiren (2026-07-14T05:58:41Z), @coilyco-ops (2026-07-15T07:08:46Z), @coilyco-ops (2026-07-15T07:16:35Z)

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-1227` on host `kais-macbook-pro-2.local`. Accepted by `ward agent --harness codex` (reserved 2026-07-15T10:03:31Z). 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#1227` · branch `issue-1227` · harness `codex` · workflow `pull-request-and-merge` - **Run:** `engineer-codex-ward-1227` · ward `v0.710.0` · dispatched `2026-07-15T10:03:23Z` - **Comment thread:** 4 included in the pre-flight read, 0 stripped (ward's own automated comments). - included: @coilysiren (2026-07-14T05:58:20Z), @coilysiren (2026-07-14T05:58:41Z), @coilyco-ops (2026-07-15T07:08:46Z), @coilyco-ops (2026-07-15T07:16:35Z) 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 10:18:49 +00:00

Use selected bundle defaults for warded

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

2026-07-15 10:19:02 +00:00

Use selected bundle defaults for warded #1383

coilyco-ops referenced this issue from a commit

2026-07-15 10:23:07 +00:00

Fix roster fixture bundle catalog

coilyco-ops closed this issue

2026-07-15 10:25:54 +00:00

coilyco-ops commented

2026-07-15 10:34:51 +00:00

Author

Member

QA follow-up: PASS. PR #1383 merged at afd3b815db. PR test run 8455 succeeded, promote run 8457 succeeded, and release run 8458 succeeded.

Evidence checked:

agentHarness now resolves the no-flag default through the selected bundle via selectedAgentMode(), while explicit --harness / --agent still win.
directorEngineerHarness still inherits the resolved director mode unless --engineer-harness is explicitly set.
ward agents list --json and role definitions now read selected bundle fleet/role defaults, with baked defaults as fallback.
Focused tests passed: TestAgentHarnessUsesSelectedBundleDefault, TestAgentsListJSONUsesSelectedBundleDefaults, TestAgentRoleDefinitionsUseSelectedBundleCatalog, TestBacklogPrintDirectorPlanIncludesCLIConfig, and TestDirectorEngineerHarness.
Command smoke test against a scratch selected bundle with defaults { agent codex } printed director harness: codex, engineer-harness: codex, and dispatch argv with --harness codex.

The issue criteria are met; no follow-up issue needed.

QA follow-up: PASS. PR #1383 merged at afd3b815dbbb151981406fa9c21b37189085193e. PR test run 8455 succeeded, promote run 8457 succeeded, and release run 8458 succeeded. Evidence checked: - `agentHarness` now resolves the no-flag default through the selected bundle via `selectedAgentMode()`, while explicit `--harness` / `--agent` still win. - `directorEngineerHarness` still inherits the resolved director mode unless `--engineer-harness` is explicitly set. - `ward agents list --json` and role definitions now read selected bundle fleet/role defaults, with baked defaults as fallback. - Focused tests passed: `TestAgentHarnessUsesSelectedBundleDefault`, `TestAgentsListJSONUsesSelectedBundleDefaults`, `TestAgentRoleDefinitionsUseSelectedBundleCatalog`, `TestBacklogPrintDirectorPlanIncludesCLIConfig`, and `TestDirectorEngineerHarness`. - Command smoke test against a scratch selected bundle with `defaults { agent codex }` printed `director harness: codex`, `engineer-harness: codex`, and dispatch argv with `--harness codex`. The issue criteria are met; no follow-up issue needed.

Rows
Columns

warded ignores selected bundle agents.kdl default harness, so aos config appears active but does nothing #1227

Problem

Why this is confusing

Evidence in code

Ask

Acceptance

Decision for headless carry