coilyco-flight-deck/ward

Fork 0

Config-driven ward: built-in defaults for frontier harnesses - fleet blocks compress, frontier agents need no KDL (#650-7) #659

New issue

Open

opened 2026-07-08 03:40:46 +00:00 by coilyco-ops · 2 comments

coilyco-ops commented

2026-07-08 03:40:46 +00:00

Member

Sibling of the config-driven ward epic (#650), raised by Kai reading the landed .ward/ward-kdl.fleet.kdl (aos#332). Design fork, labeled consult. Sibling to #658 (model validity) - both reshape the per-agent block.

The ask

The per-agent blocks in fleet.kdl carry explicit config that should be smart defaults. Three levels of compression, Kai's framing:

Kai's POV - today's claude block

agent claude {
    binary claude
    context-level 2
    stream stream-json
    auth claude-keychain
    model claude-sonnet-4-6
    reasoning-effort medium
    argv {
        preflight claude -p
        headless claude -p --verbose --output-format stream-json
        interactive claude
    }
}

should shrink to just the divergences:

agent claude {
    context-level 2
    model claude-sonnet-4-6
    reasoning-effort medium
}

End-user POV - even those default:
```
agent claude {}
```
Frontier POV - the frontier harnesses (claude, codex, gemini, and others as Kai adds them) should require no KDL entry at all. ward carries built-in launch definitions for the well-known frontier set.

What this means in the tree

Today every field is explicit in fleet.kdl and mirrored into container_bootstrap.go env-defaults via cmd/ward/fleet.go / pkg/fleetconfig. ward#616 already made model / reasoning-effort override-only for claude (empty model "" = bare launch = harness default). This issue extends that same principle to binary, stream, auth, and argv: ward embeds a built-in table of frontier-harness launch defs, and the fleet.kdl spec becomes a sparse override layer over it.

What still needs explicit spec: non-frontier / local harnesses. opencode runs against a local ollama endpoint and goose uses ollama auth (ward-kdl.fleet.kdl:60-83) - ward cannot know their argv/endpoint, so they stay fully specified. So the rule is: built-in defaults for the known frontier set, explicit spec only for custom harnesses or deliberate overrides.

Design forks to settle (why this is `consult`)

Where do the built-in harness defs live? An embedded Go table in pkg/fleetconfig, vs a baked neutral KDL that the spec overlays (dovetails with #650's "baked neutral default"). The Go-table route keeps the frontier launch shapes in code next to agent_adapter.go, the neutral-KDL route keeps one parse path.
How does the two-way pin adapt? TestFleetSwitchesTwoWayPin (agent_adapter_test.go) pins fleet.generated.kdl <-> the parseMode roster. When the roster can be empty/sparse, the pin has to key off the built-in table, not the file.
Precedence. Slot the built-in default into the existing override chain (docs/agent-config-overrides.md): built-in default < bundle spec < role overlay < WARD_* env.

#650 (the epic), #658 (model validity - the validity layer under this compression), ward#616 / ward#620 (the override-only precedent), docs/agent-config-overrides.md. Filed from the read-only director surface (she/her).

Sibling of the [config-driven ward epic (#650)](https://forgejo.coilysiren.me/coilyco-flight-deck/ward/issues/650), raised by Kai reading the landed `.ward/ward-kdl.fleet.kdl` (aos#332). Design fork, labeled `consult`. Sibling to #658 (model validity) - both reshape the per-agent block. ## The ask The per-agent blocks in fleet.kdl carry explicit config that should be **smart defaults**. Three levels of compression, Kai's framing: * **Kai's POV** - today's claude block ``` agent claude { binary claude context-level 2 stream stream-json auth claude-keychain model claude-sonnet-4-6 reasoning-effort medium argv { preflight claude -p headless claude -p --verbose --output-format stream-json interactive claude } } ``` should shrink to just the divergences: ``` agent claude { context-level 2 model claude-sonnet-4-6 reasoning-effort medium } ``` * **End-user POV** - even those default: ``` agent claude {} ``` * **Frontier POV** - the frontier harnesses (claude, codex, gemini, and others as Kai adds them) should require **no KDL entry at all**. ward carries built-in launch definitions for the well-known frontier set. ## What this means in the tree Today every field is explicit in fleet.kdl and mirrored into `container_bootstrap.go` env-defaults via `cmd/ward/fleet.go` / `pkg/fleetconfig`. ward#616 already made **model / reasoning-effort override-only** for claude (empty `model ""` = bare launch = harness default). This issue **extends that same principle** to `binary`, `stream`, `auth`, and `argv`: ward embeds a built-in table of frontier-harness launch defs, and the fleet.kdl spec becomes a **sparse override layer** over it. **What still needs explicit spec:** non-frontier / local harnesses. `opencode` runs against a local ollama `endpoint` and `goose` uses ollama auth (`ward-kdl.fleet.kdl:60-83`) - ward cannot know their argv/endpoint, so they stay fully specified. So the rule is: **built-in defaults for the known frontier set, explicit spec only for custom harnesses or deliberate overrides.** ## Design forks to settle (why this is `consult`) * **Where do the built-in harness defs live?** An embedded Go table in `pkg/fleetconfig`, vs a baked neutral KDL that the spec overlays (dovetails with #650's "baked neutral default"). The Go-table route keeps the frontier launch shapes in code next to `agent_adapter.go`, the neutral-KDL route keeps one parse path. * **How does the two-way pin adapt?** `TestFleetSwitchesTwoWayPin` (agent_adapter_test.go) pins `fleet.generated.kdl` <-> the `parseMode` roster. When the roster can be empty/sparse, the pin has to key off the built-in table, not the file. * **Precedence.** Slot the built-in default into the existing override chain (`docs/agent-config-overrides.md`): `built-in default < bundle spec < role overlay < WARD_* env`. ## Related #650 (the epic), #658 (model validity - the validity layer under this compression), ward#616 / ward#620 (the override-only precedent), `docs/agent-config-overrides.md`. Filed from the read-only director surface (she/her).

coilyco-ops added the

consult

labels

2026-07-08 03:40:46 +00:00

~~coilyco-ops referenced this issue 2026-07-08 03:40:46 +00:00~~

ward agent: accept both --harness and --agent for the harness pick (retire --driver to deprecated alias) #660

coilyco-ops referenced this issue

2026-07-08 03:40:57 +00:00

[epic] Config-driven ward: one precompiled binary, personal config resolved live from a git ref (supersedes the build-variant matrix) #650

coilyco-ops referenced this issue

2026-07-08 04:49:15 +00:00

[epic] Config-driven ward: one precompiled binary, personal config resolved live from a git ref (supersedes the build-variant matrix) #650

coilyco-ops commented

2026-07-08 09:35:44 +00:00

Author

Member

🔎 ward agent advisor

ward agent advisor --harness codex ran a one-shot standard research pass on this question:

Recommend the concrete design for built-in frontier harness defaults and sparse fleet.kdl overrides: where the defaults should live, exact precedence, test updates, and the next engineering issue. Post the answer as a concise issue comment.

Recommend the ward-owned Go-table route, not a second baked KDL overlay.

Why this is the better fit

The current parser in cli-guard/pkg/fleetconfig still treats a top-level agent as a full definition and fails closed when binary is missing. So agent claude {} does not fit the current grammar without loosening the generic parser.
The fields this issue wants to default (binary, stream, auth, argv, and often context-level) are the launcher shape that ward consumes directly in agent_adapter.go, parseMode, readBootstrapEnv, and buildAgentArgv. That makes them ward product policy, not shared cli-guard parser policy.
The repo already has a "baked neutral default" seam for whole config bundles via WARD_CONFIG_REF, but that is a bundle source selector, not a good fit for a second internal merge layer just to recover well-known frontier harness launch shapes.

Concrete design

Add a ward-local built-in frontier table, as typed Go data, keyed by agent name.
Suggested home: cmd/ward/frontier_defaults.go or adjacent to agent_adapter.go, not in shared cli-guard.
Represent each built-in as the same shape ward already consumes: effectively a fleetconfig.Agent-like record with binary, context-level, stream, auth, argv, plus the tuning defaults (model, endpoint, reasoning-effort, verbosity) when ward wants product defaults.
Treat the parsed ward-kdl.fleet.kdl as a sparse override layer over that built-in table for frontier names.
Keep non-frontier / local harnesses explicit in KDL. If an agent name is not in the frontier built-ins, its merged result must still be complete after parse + override resolution or ward fails loud.
Keep the bundle file authoritative for:
- custom harness definitions
- deliberate overrides to frontier defaults
- roles / role overlays
- defaults.attribution and other non-agent bundle config

Merge rule

For each effective agent record:

If the agent name is in the built-in frontier set, start from the built-in record.
Overlay any top-level agent <name> fields from the selected bundle.
If the agent name is not built-in, require the bundle record to resolve to a complete agent.
After merge, validate the effective roster exactly as today: binary present, context-level in range, headless argv present, headless argv starts with binary, etc.

That gives all three compression levels cleanly:

agent claude { context-level 2 model claude-sonnet-4-6 reasoning-effort medium }
agent claude {}
no agent claude node at all

with the same resolver.

Exact precedence

Highest first:

--config / emitted WARD_* env
role overlay (roles { role X { agent <name> { ... } } })
top-level bundle agent <name> { ... } sparse override
ward built-in frontier default
for non-frontier agents only: no built-in exists, so the top-level bundle must already be complete

That is the right extension of the existing documented chain in docs/agent-config-overrides.md. The only change is inserting the bundle's top-level sparse override above the built-in default.

One nuance: role overlays should stay limited to the existing tuning subset (model, endpoint, reasoning-effort, verbosity). Structural fields (binary, stream, auth, argv, context-level) should remain top-level-only.

Parser / typing recommendation

Do not put ward's frontier roster into cli-guard/pkg/fleetconfig.

Instead:

Loosen fleetconfig just enough to permit partial top-level agent nodes as data, rather than requiring binary during parse.
Move the completeness check from parse time to ward's post-merge effective-agent validation.

That preserves the generic parser boundary while letting ward apply its own built-ins. Without this change, agent claude {} cannot parse.

Test updates

Update the pin from "raw parsed fleet file is the roster" to "effective resolved roster is the roster":

TestFleetSwitchesTwoWayPin
- stop keying roster membership off raw fleet.Agents
- key it off the resolved effective roster = built-in frontier set plus explicit custom agents from the bundle
- keep the two-way check with parseMode
TestAgentManifestParses / TestRegistryRecordMatchesManifest
- load the manifest from the resolved roster, not the raw parsed fleet list
add sparse-frontier tests:
- agent claude {} resolves to the full built-in launch shape
- agent claude { context-level 1 } overrides only that field
- omitting agent codex entirely still leaves codex available
- a custom non-frontier agent with missing binary still fails loud after resolution
- role overlay still beats bundle default, and WARD_* still beats role overlay
keep fleetassets_test.go unchanged as a byte-for-byte drift pin on the source bundle mirror

What should stay in ward-kdl.fleet.kdl after this change

claude / codex only when overriding defaults
opencode / goose fully explicit, because they depend on local-model / operator-specific wiring ward cannot safely invent
future frontier agents like gemini can land with zero KDL entry until an operator wants a divergence

Next engineering issue

Title: Resolve frontier built-ins into an effective fleet roster before bootstrap and adapter projection

Scope:

add ward-local built-in frontier definitions
add an effectiveFleet / resolveAgents merge step
relax parser completeness so sparse top-level frontier overrides parse
switch parseMode, loadAgentManifest, and bootstrap default resolution to the effective roster
update the two-way pin and add sparse-override tests

That is the smallest coherent implementation slice. It lands the built-in-default model end to end without mixing ward product policy into shared cli-guard code beyond the minimal parser relaxation.

Researched and posted automatically by ward agent advisor --harness codex (ward#179). This is one-shot research, not a carried change - verify before acting on it.

— Codex, via ward agent

### 🔎 ward agent advisor `ward agent advisor --harness codex` ran a one-shot **standard** research pass on this question: > Recommend the concrete design for built-in frontier harness defaults and sparse fleet.kdl overrides: where the defaults should live, exact precedence, test updates, and the next engineering issue. Post the answer as a concise issue comment. --- Recommend the **ward-owned Go-table route**, not a second baked KDL overlay. **Why this is the better fit** - The current parser in `cli-guard/pkg/fleetconfig` still treats a top-level `agent` as a **full definition** and fails closed when `binary` is missing. So `agent claude {}` does **not** fit the current grammar without loosening the generic parser. - The fields this issue wants to default (`binary`, `stream`, `auth`, `argv`, and often `context-level`) are the **launcher shape** that ward consumes directly in `agent_adapter.go`, `parseMode`, `readBootstrapEnv`, and `buildAgentArgv`. That makes them ward product policy, not shared `cli-guard` parser policy. - The repo already has a "baked neutral default" seam for whole config bundles via `WARD_CONFIG_REF`, but that is a **bundle source selector**, not a good fit for a second internal merge layer just to recover well-known frontier harness launch shapes. **Concrete design** 1. Add a ward-local built-in frontier table, as typed Go data, keyed by agent name. Suggested home: `cmd/ward/frontier_defaults.go` or adjacent to `agent_adapter.go`, not in shared `cli-guard`. 2. Represent each built-in as the same shape ward already consumes: effectively a `fleetconfig.Agent`-like record with `binary`, `context-level`, `stream`, `auth`, `argv`, plus the tuning defaults (`model`, `endpoint`, `reasoning-effort`, `verbosity`) when ward wants product defaults. 3. Treat the parsed `ward-kdl.fleet.kdl` as a **sparse override layer** over that built-in table for frontier names. 4. Keep **non-frontier / local harnesses** explicit in KDL. If an agent name is not in the frontier built-ins, its merged result must still be complete after parse + override resolution or ward fails loud. 5. Keep the bundle file authoritative for: - custom harness definitions - deliberate overrides to frontier defaults - roles / role overlays - defaults.attribution and other non-agent bundle config **Merge rule** For each effective agent record: - If the agent name is in the built-in frontier set, start from the built-in record. - Overlay any top-level `agent <name>` fields from the selected bundle. - If the agent name is not built-in, require the bundle record to resolve to a complete agent. - After merge, validate the effective roster exactly as today: binary present, context-level in range, headless argv present, headless argv starts with binary, etc. That gives all three compression levels cleanly: - `agent claude { context-level 2 model claude-sonnet-4-6 reasoning-effort medium }` - `agent claude {}` - no `agent claude` node at all with the same resolver. **Exact precedence** Highest first: 1. `--config` / emitted `WARD_*` env 2. role overlay (`roles { role X { agent <name> { ... } } }`) 3. top-level bundle `agent <name> { ... }` sparse override 4. ward built-in frontier default 5. for non-frontier agents only: no built-in exists, so the top-level bundle must already be complete That is the right extension of the existing documented chain in `docs/agent-config-overrides.md`. The only change is inserting the bundle's top-level sparse override above the built-in default. One nuance: role overlays should stay limited to the existing **tuning** subset (`model`, `endpoint`, `reasoning-effort`, `verbosity`). Structural fields (`binary`, `stream`, `auth`, `argv`, `context-level`) should remain top-level-only. **Parser / typing recommendation** Do **not** put ward's frontier roster into `cli-guard/pkg/fleetconfig`. Instead: - Loosen `fleetconfig` just enough to permit **partial top-level agent nodes** as data, rather than requiring `binary` during parse. - Move the completeness check from parse time to ward's **post-merge effective-agent validation**. That preserves the generic parser boundary while letting ward apply its own built-ins. Without this change, `agent claude {}` cannot parse. **Test updates** Update the pin from "raw parsed fleet file is the roster" to "effective resolved roster is the roster": - `TestFleetSwitchesTwoWayPin` - stop keying roster membership off raw `fleet.Agents` - key it off the **resolved effective roster** = built-in frontier set plus explicit custom agents from the bundle - keep the two-way check with `parseMode` - `TestAgentManifestParses` / `TestRegistryRecordMatchesManifest` - load the manifest from the **resolved** roster, not the raw parsed fleet list - add sparse-frontier tests: - `agent claude {}` resolves to the full built-in launch shape - `agent claude { context-level 1 }` overrides only that field - omitting `agent codex` entirely still leaves codex available - a custom non-frontier agent with missing `binary` still fails loud after resolution - role overlay still beats bundle default, and `WARD_*` still beats role overlay - keep `fleetassets_test.go` unchanged as a byte-for-byte drift pin on the source bundle mirror **What should stay in `ward-kdl.fleet.kdl` after this change** - `claude` / `codex` only when overriding defaults - `opencode` / `goose` fully explicit, because they depend on local-model / operator-specific wiring ward cannot safely invent - future frontier agents like `gemini` can land with zero KDL entry until an operator wants a divergence **Next engineering issue** Title: **Resolve frontier built-ins into an effective fleet roster before bootstrap and adapter projection** Scope: - add ward-local built-in frontier definitions - add an `effectiveFleet` / `resolveAgents` merge step - relax parser completeness so sparse top-level frontier overrides parse - switch `parseMode`, `loadAgentManifest`, and bootstrap default resolution to the effective roster - update the two-way pin and add sparse-override tests That is the smallest coherent implementation slice. It lands the built-in-default model end to end without mixing ward product policy into shared `cli-guard` code beyond the minimal parser relaxation. --- Researched and posted automatically by `ward agent advisor --harness codex` (ward#179). This is one-shot research, not a carried change - verify before acting on it.   — Codex, via `ward agent`

coilyco-ops referenced this issue

2026-07-08 09:49:40 +00:00

Resolve frontier built-ins into an effective fleet roster before bootstrap #671

coilyco-ops commented

2026-07-08 09:51:57 +00:00

Author

Member

Converted the advisor recommendation into implementation issue #671 and dispatched a Codex engineer with coilyco-flight-deck/cli-guard granted.

Decision captured there: frontier harness defaults live in ward-owned typed Go data, and ward-kdl.fleet.kdl becomes a sparse override layer over the effective roster. Keep this consult open until #671 lands, then close it as resolved by #671.

Converted the advisor recommendation into implementation issue #671 and dispatched a Codex engineer with `coilyco-flight-deck/cli-guard` granted. Decision captured there: frontier harness defaults live in ward-owned typed Go data, and `ward-kdl.fleet.kdl` becomes a sparse override layer over the effective roster. Keep this consult open until #671 lands, then close it as resolved by #671.

coilyco-ops referenced this issue

2026-07-08 09:51:57 +00:00

[epic] Config-driven ward: one precompiled binary, personal config resolved live from a git ref (supersedes the build-variant matrix) #650

coilyco-ops referenced this issue

2026-07-10 00:36:27 +00:00

Make ward agent roles config-defined presets instead of hard-coded names #895

coilyco-ops added

interactive

and removed

consult

labels

2026-07-10 09:00:37 +00:00