Add agent capability fields + finish manifest-backed adapter lookup (from #508 scope 2) #552

New issue

Open

opened 2026-07-03 07:01:27 +00:00 by coilysiren · 0 comments

coilysiren commented

2026-07-03 07:01:27 +00:00

Owner

Follow-up from #508 (scope 2), split out so #508 could land its concrete slices (workflow modes + the docs reframe).

Goal

Finish manifest-backed agent adapter lookup and add capability-shape fields to the fleet manifest, so per-agent divergence lives in one place and no launch-path behavior needs a hardcoded switch mode { claude, codex, opencode, goose }.

Why deferred from #508

The launch-shape adapter (binary / context-level / stream / auth / argv) already projects off the embedded fleet config (cmd/ward/agent_adapter.go, ward#419). Adding capability fields (preflight, headless, interactive, stream, resume, supports_images, supports_mcp, auth_source) means extending the upstream cli-guard pkg/fleetconfig schema first (the manifest is embedded from ward-kdl.fleet.kdl, parsed by cli-guard), then projecting them in ward. That is a cross-module change (the ward#326 release dance), out of scope for #508's single-slice landing.

Acceptance (from #508)

Capability fields added to the fleet manifest schema (cli-guard fleetconfig + ward-kdl.fleet.kdl), distinct from argv (how to invoke) vs capabilities (what ward may expect).
Remaining driver-specific switches in launch/compute paths eliminated or isolated behind the manifest-backed registry.
Tests pin current Claude/Codex/OpenCode/Goose behavior before and after.
Adding a new driver requires manifest/config + tests, not scattered Go switch edits.
Error messages name the manifest/registry source on a malformed/unsupported agent.

Explicitly NOT in scope (per #508): velocity metrics, model-proxy integration, read-only credential hardening.

Follow-up from #508 (scope 2), split out so #508 could land its concrete slices (workflow modes + the docs reframe). ## Goal Finish manifest-backed agent adapter lookup and add **capability-shape** fields to the fleet manifest, so per-agent divergence lives in one place and no launch-path behavior needs a hardcoded `switch mode { claude, codex, opencode, goose }`. ## Why deferred from #508 The launch-shape adapter (binary / context-level / stream / auth / argv) already projects off the embedded fleet config (`cmd/ward/agent_adapter.go`, ward#419). Adding **capability** fields (`preflight`, `headless`, `interactive`, `stream`, `resume`, `supports_images`, `supports_mcp`, `auth_source`) means extending the upstream `cli-guard` `pkg/fleetconfig` schema first (the manifest is embedded from `ward-kdl.fleet.kdl`, parsed by cli-guard), then projecting them in ward. That is a cross-module change (the ward#326 release dance), out of scope for #508's single-slice landing. ## Acceptance (from #508) - Capability fields added to the fleet manifest schema (cli-guard `fleetconfig` + `ward-kdl.fleet.kdl`), distinct from `argv` (how to invoke) vs `capabilities` (what ward may expect). - Remaining driver-specific switches in launch/compute paths eliminated or isolated behind the manifest-backed registry. - Tests pin current Claude/Codex/OpenCode/Goose behavior before and after. - Adding a new driver requires manifest/config + tests, not scattered Go switch edits. - Error messages name the manifest/registry source on a malformed/unsupported agent. Explicitly NOT in scope (per #508): velocity metrics, model-proxy integration, read-only credential hardening.

coilysiren referenced this issue

2026-07-03 07:02:02 +00:00

feature request batch from codex convo #508