coilyco-flight-deck/ward

Watch

Remove flexible roles and KDL runtime configuration from Ward #1615

New issue

Closed

opened 2026-07-29 03:23:24 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-07-29 03:23:24 +00:00

Member

Outcome

Ward removes its flexible role-permission system and all KDL-backed runtime configuration.

Ward retains:

fixed agent workflow commands such as engineer, director, and qa
container isolation, lifecycle, dispatch, and repository workflow mechanics
the fixed hardcoded broker boundary for privileged Ward operations
consumer configuration through YAML, explicit flags, and environment inputs

Ward no longer treats behavioral roles as security principals. A role value must not change broker grants, credentials, mounts, network reach, merge authority, or other runtime permission.

Why

Ward currently carries two overlapping concepts:

fixed product workflows implemented as Ward commands
flexible KDL roles that add semantic capabilities, guardfile bindings, per-harness overlays, execution defaults, and permission-derived container behavior

The flexible layer duplicates agent-compose's behavioral role model and creates a second authorization system beside Ward's hardcoded broker. It also supports a KDL profile pipeline whose production path reads Ward's own embedded files through parsing, provider, merge, and projection layers.

The settled direction is simpler:

Ward owns fixed workflow mechanics and one brokered security boundary.
Agent-compose owns behavioral roles.
AOS and harness adapters own role composition, model, reasoning, identity, and seat selection.
Consumers configure supported Ward behavior through YAML.
Product defaults are typed Go values.
Per-launch values use flags or environment inputs.

Scope

Remove role-derived authority

The implementation removes every path where a flexible role changes:

guardfile or broker operation availability
credentials or secret projection
Tailnet, Kubernetes, AWS, or other network and host reach
container mounts, binaries, daemons, or topology
merge authority
agent capability claims presented as runtime authorization

Ward's fixed broker validates its own hardcoded operations and scope. Ward does not consult a flexible role catalog to grant or attenuate them.

Keep fixed workflows without a role ontology

Ward may retain ward agent engineer, ward agent director, and ward agent qa as fixed command workflows.

The implementation moves any legitimate command defaults, such as execution limits, into command-local typed defaults or the consumer YAML schema. Ward does not load those values from a configurable role definition.

A role slug needed by agent-compose may pass through Ward as opaque launch metadata. Ward does not define, validate, or authorize that role.

Remove all Ward KDL

The implementation removes Ward's KDL runtime and local configuration surface, including:

embedded .ward/roles.kdl
embedded .ward/fleet.kdl
embedded .ward/defaults.kdl
embedded .ward/topology.kdl
operator-local fleet.local.kdl
the embedded role catalog and semantic capability algebra
role roster and role-overlay projection machinery
role-to-guardfile and role-to-host-capability resolution
KDL bundle discovery, selection, parsing, and re-emission
configSource, ProfileProvider, and single-provider caching whose purpose is transporting embedded KDL
KDL-specific fixtures, validation, generated documentation, and compatibility paths
direct Ward dependencies on kdl-go and the fleet-config role/profile schema

Typed domain objects may remain where Ward still needs them. Ward constructs them from typed defaults plus YAML overrides rather than routing embedded data through a KDL provider pipeline.

Consolidate supported consumer configuration into YAML

The implementation does not mechanically rename fleet.kdl to fleet.yaml.

The implementation identifies the settings that remain supported consumer contracts and gives them narrow YAML homes. Expected examples include:

workflow defaults and repository exceptions
trusted owners and repository or forge routing
concurrency and lifecycle limits
default harness
director default scope
agent image and release channel, if Ward consumers still control them

Repository-scoped values should extend the existing .ward/ward.yaml contract. Operator-wide preferences may use a deliberately small XDG-level YAML document. Flags and environment variables remain the highest-precedence per-launch inputs.

Model names, reasoning effort, personality, display identity, and role composition do not become Ward YAML fields. AOS, agent-compose, and harness adapters own them.

Migrate directly

Ward is pre-1.0. The implementation may make this a documented minor-version configuration break.

Do not retain a KDL compatibility parser, dual-read period, or automatic KDL-to-YAML migration inside Ward. Documentation should give consumers a bounded before-and-after mapping for settings that survive.

Acceptance evidence

Ward contains no tracked .kdl file.
Ward has no runtime dependency on kdl-go or the fleet-config role/profile schema.
No flexible role value changes broker operations, credentials, mounts, network reach, topology, merge authority, or container bring-up.
The fixed broker remains the only Ward operation-level permission boundary.
engineer, director, and qa workflows retain their documented product behavior without loading role definitions.
Supported consumer overrides load from documented YAML, flags, or environment inputs with one tested precedence order.
A configured and an unconfigured generic Ward launch both pass focused integration coverage.
Tests cover one repository-scoped YAML override and one operator-wide preference.
Documentation identifies removed fields, surviving fields, new ownership, and the direct migration path.
The implementation records gross deletion, replacement additions, and net LOC removed.
Ward's declared test, vet, lint, and pre-commit surfaces pass.

Non-goals

Removing agent-compose roles
Removing AOS role composition
Removing or redesigning AOSguard
Removing Ward's fixed broker
Renaming the fixed agent workflow commands solely for this migration
Preserving arbitrary third-party KDL role definitions
Translating every old KDL field into YAML
Adding a second generic plugin or profile-provider system

Existing work this decision absorbs or supersedes

#1498 is absorbed. This issue replaces an open-ended audit with the settled removal outcome.
#1328 is superseded. Ward will not add dynamic downstream roles from roles.kdl.
#1265 is absorbed and broadened. Ward removes the embedded profile/KDL path rather than retaining a provider seam for it.
#1072 is superseded. Ward will not consume role-tier bindings to select runtime capabilities.
#1029 is superseded. Per-role and per-harness model tuning belongs outside Ward.
#1326 remains useful evidence for which smart defaults are real product settings, but surviving consumer settings move to YAML.
#650 records the older config-driven KDL direction. This issue replaces that direction for Ward runtime configuration.

Downstream

AOS adaptation is tracked in coilyco-flight-deck/agentic-os#778. The Ward issue owns the target contract and closes only after the downstream issue can cite a usable released Ward boundary.

## Outcome Ward removes its flexible role-permission system and all KDL-backed runtime configuration. Ward retains: * fixed agent workflow commands such as `engineer`, `director`, and `qa` * container isolation, lifecycle, dispatch, and repository workflow mechanics * the fixed hardcoded broker boundary for privileged Ward operations * consumer configuration through YAML, explicit flags, and environment inputs Ward no longer treats behavioral roles as security principals. A role value must not change broker grants, credentials, mounts, network reach, merge authority, or other runtime permission. ## Why Ward currently carries two overlapping concepts: * fixed product workflows implemented as Ward commands * flexible KDL roles that add semantic capabilities, guardfile bindings, per-harness overlays, execution defaults, and permission-derived container behavior The flexible layer duplicates agent-compose's behavioral role model and creates a second authorization system beside Ward's hardcoded broker. It also supports a KDL profile pipeline whose production path reads Ward's own embedded files through parsing, provider, merge, and projection layers. The settled direction is simpler: * Ward owns fixed workflow mechanics and one brokered security boundary. * Agent-compose owns behavioral roles. * AOS and harness adapters own role composition, model, reasoning, identity, and seat selection. * Consumers configure supported Ward behavior through YAML. * Product defaults are typed Go values. * Per-launch values use flags or environment inputs. ## Scope ### Remove role-derived authority The implementation removes every path where a flexible role changes: * guardfile or broker operation availability * credentials or secret projection * Tailnet, Kubernetes, AWS, or other network and host reach * container mounts, binaries, daemons, or topology * merge authority * agent capability claims presented as runtime authorization Ward's fixed broker validates its own hardcoded operations and scope. Ward does not consult a flexible role catalog to grant or attenuate them. ### Keep fixed workflows without a role ontology Ward may retain `ward agent engineer`, `ward agent director`, and `ward agent qa` as fixed command workflows. The implementation moves any legitimate command defaults, such as execution limits, into command-local typed defaults or the consumer YAML schema. Ward does not load those values from a configurable role definition. A role slug needed by agent-compose may pass through Ward as opaque launch metadata. Ward does not define, validate, or authorize that role. ### Remove all Ward KDL The implementation removes Ward's KDL runtime and local configuration surface, including: * embedded `.ward/roles.kdl` * embedded `.ward/fleet.kdl` * embedded `.ward/defaults.kdl` * embedded `.ward/topology.kdl` * operator-local `fleet.local.kdl` * the embedded role catalog and semantic capability algebra * role roster and role-overlay projection machinery * role-to-guardfile and role-to-host-capability resolution * KDL bundle discovery, selection, parsing, and re-emission * `configSource`, `ProfileProvider`, and single-provider caching whose purpose is transporting embedded KDL * KDL-specific fixtures, validation, generated documentation, and compatibility paths * direct Ward dependencies on `kdl-go` and the fleet-config role/profile schema Typed domain objects may remain where Ward still needs them. Ward constructs them from typed defaults plus YAML overrides rather than routing embedded data through a KDL provider pipeline. ### Consolidate supported consumer configuration into YAML The implementation does not mechanically rename `fleet.kdl` to `fleet.yaml`. The implementation identifies the settings that remain supported consumer contracts and gives them narrow YAML homes. Expected examples include: * workflow defaults and repository exceptions * trusted owners and repository or forge routing * concurrency and lifecycle limits * default harness * director default scope * agent image and release channel, if Ward consumers still control them Repository-scoped values should extend the existing `.ward/ward.yaml` contract. Operator-wide preferences may use a deliberately small XDG-level YAML document. Flags and environment variables remain the highest-precedence per-launch inputs. Model names, reasoning effort, personality, display identity, and role composition do not become Ward YAML fields. AOS, agent-compose, and harness adapters own them. ### Migrate directly Ward is pre-1.0. The implementation may make this a documented minor-version configuration break. Do not retain a KDL compatibility parser, dual-read period, or automatic KDL-to-YAML migration inside Ward. Documentation should give consumers a bounded before-and-after mapping for settings that survive. ## Acceptance evidence * Ward contains no tracked `.kdl` file. * Ward has no runtime dependency on `kdl-go` or the fleet-config role/profile schema. * No flexible role value changes broker operations, credentials, mounts, network reach, topology, merge authority, or container bring-up. * The fixed broker remains the only Ward operation-level permission boundary. * `engineer`, `director`, and `qa` workflows retain their documented product behavior without loading role definitions. * Supported consumer overrides load from documented YAML, flags, or environment inputs with one tested precedence order. * A configured and an unconfigured generic Ward launch both pass focused integration coverage. * Tests cover one repository-scoped YAML override and one operator-wide preference. * Documentation identifies removed fields, surviving fields, new ownership, and the direct migration path. * The implementation records gross deletion, replacement additions, and net LOC removed. * Ward's declared test, vet, lint, and pre-commit surfaces pass. ## Non-goals * Removing agent-compose roles * Removing AOS role composition * Removing or redesigning AOSguard * Removing Ward's fixed broker * Renaming the fixed agent workflow commands solely for this migration * Preserving arbitrary third-party KDL role definitions * Translating every old KDL field into YAML * Adding a second generic plugin or profile-provider system ## Existing work this decision absorbs or supersedes * #1498 is absorbed. This issue replaces an open-ended audit with the settled removal outcome. * #1328 is superseded. Ward will not add dynamic downstream roles from `roles.kdl`. * #1265 is absorbed and broadened. Ward removes the embedded profile/KDL path rather than retaining a provider seam for it. * #1072 is superseded. Ward will not consume role-tier bindings to select runtime capabilities. * #1029 is superseded. Per-role and per-harness model tuning belongs outside Ward. * #1326 remains useful evidence for which smart defaults are real product settings, but surviving consumer settings move to YAML. * #650 records the older config-driven KDL direction. This issue replaces that direction for Ward runtime configuration. ## Downstream AOS adaptation is tracked in [coilyco-flight-deck/agentic-os#778](https://forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/issues/778). The Ward issue owns the target contract and closes only after the downstream issue can cite a usable released Ward boundary.

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

2026-07-29 03:24:00 +00:00

Adapt AOS to Ward's role and KDL removal #778

coilyco-ops added the

autonomy

async-consult

priority

labels

2026-07-29 03:47:41 +00:00

coilyco-ops referenced this issue from a commit

2026-07-29 04:16:11 +00:00

refactor: remove Ward KDL runtime configuration