Spec dynamic downstream roles from roles.kdl without hardcoding them into this release #1328

New issue

Open

opened 2026-07-15 05:51:00 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-07-15 05:51:00 +00:00

Member

Ward needs a design for dynamic downstream roles, but that is outside the warded control plane coherence release.

Reference draft:

https://forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/src/branch/main/.ward/roles.kdl

The current draft includes engineer, director, qa, advisor, ops, and pm. The release should keep its focus on the existing control plane. Work that makes advisor/QA/ops/PM first-class or dynamically configured should be designed separately and pulled into a later release when the role contract is clear.

Design goals:

Treat downstream roles as data from the selected bundle or downstream config, not as a fixed set compiled into ward command code forever.
Define which parts are role behavior, which parts are guardfile capability, and which parts are harness/model policy.
Preserve built-in roles needed for the current control plane, especially engineer and director.
Let downstream bundles introduce roles such as advisor, QA, ops, and PM without each role requiring a bespoke Go command path when the behavior can share a generic role runner.
Decide how dynamic roles expose help, prompts, permissions, model overrides, and dispatch/landing policy.
Keep advisor-specific and QA-specific implementation out of the current control-plane release unless it is required for engineer/director correctness.

Open questions:

Which roles are core built-ins and which are downstream bundle roles?
Does each role need a behavior kind, for example implement, coordinate, review, advise, operate, triage?
How do role-local guardfiles compose with common forge read/comment/write capabilities?
How does warded <role> <ref> validate that the selected bundle actually defines that role?
What is the migration path for existing advisor and QA commands?

Acceptance:

Produce a written design for dynamic downstream roles grounded in the roles.kdl draft.
Identify the minimal ward core API needed to load, validate, and expose downstream roles.
Split concrete implementation issues for advisor, QA, ops, or PM only after the generic role model is agreed.
Keep this work outside the warded control plane coherence milestone until explicitly pulled in.

Ward needs a design for dynamic downstream roles, but that is outside the `warded control plane coherence` release. Reference draft: https://forgejo.coilysiren.me/coilyco-flight-deck/agentic-os/src/branch/main/.ward/roles.kdl The current draft includes `engineer`, `director`, `qa`, `advisor`, `ops`, and `pm`. The release should keep its focus on the existing control plane. Work that makes advisor/QA/ops/PM first-class or dynamically configured should be designed separately and pulled into a later release when the role contract is clear. Design goals: * Treat downstream roles as data from the selected bundle or downstream config, not as a fixed set compiled into ward command code forever. * Define which parts are role behavior, which parts are guardfile capability, and which parts are harness/model policy. * Preserve built-in roles needed for the current control plane, especially engineer and director. * Let downstream bundles introduce roles such as advisor, QA, ops, and PM without each role requiring a bespoke Go command path when the behavior can share a generic role runner. * Decide how dynamic roles expose help, prompts, permissions, model overrides, and dispatch/landing policy. * Keep advisor-specific and QA-specific implementation out of the current control-plane release unless it is required for engineer/director correctness. Open questions: * Which roles are core built-ins and which are downstream bundle roles? * Does each role need a behavior kind, for example implement, coordinate, review, advise, operate, triage? * How do role-local guardfiles compose with common forge read/comment/write capabilities? * How does `warded <role> <ref>` validate that the selected bundle actually defines that role? * What is the migration path for existing advisor and QA commands? Acceptance: * Produce a written design for dynamic downstream roles grounded in the `roles.kdl` draft. * Identify the minimal ward core API needed to load, validate, and expose downstream roles. * Split concrete implementation issues for advisor, QA, ops, or PM only after the generic role model is agreed. * Keep this work outside the `warded control plane coherence` milestone until explicitly pulled in.

coilyco-ops added the

consult

labels

2026-07-15 05:51:00 +00:00