coilyco-flight-deck/ward

Fork 0

Add a warded ops role for bounded live operations #817

New issue

Open

opened 2026-07-09 16:56:13 +00:00 by coilyco-ops · 3 comments

coilyco-ops commented

2026-07-09 16:56:13 +00:00

Member

Recommendation: add a warded ops role rather than widening engineer/advisor. The role should be live-observe first, bounded-mutate second. It should fit ser8 and o11y work where the agent needs tailnet, kube contexts, SSM reads, and observability panes, while preserving hard fences around destructive actions.

Initial scope:

read live state from ser8 and kai-server through existing guardfiles
query VictoriaMetrics, SigNoz, and deploy runbooks
inspect Kubernetes resources and Helm releases
perform reversible operational actions only through explicit ward/ward-kdl verbs
file and dispatch implementation work when the fix belongs in a repo

Non-goals:

no force-pushes or history rewriting
no ad hoc secret printing
no unguarded kubectl/helm/aws access
no replacing engineer for repo changes

Design questions:

should ops be a startup role beside engineer/director/advisor, or a guardfile profile that director can dispatch into?
what exact mutation verbs are safe for v1: rollout restart, helm diff/template, secret force-sync, alert silence, pipeline apply?
how should ops report evidence back to an issue: links, commands run, query snippets, status snapshots?

Deploy-side references to read before design: coilyco-bridge/deploy docs/o11y.md, docs/o11y-sources.md, services/ser8-observability/docs/ser8-k3s.md, services/ser8-observability/docs/ser8-signoz.md, and services/fleet-reachability/docs/gatus.md.

Context from deploy director surface on 2026-07-09. ser8 is now the canonical ops/o11y plane, with deploy owning the service manifests and warded agents increasingly needing to inspect live state without pretending that an engineer role is the right shape. Recommendation: add a warded ops role rather than widening engineer/advisor. The role should be live-observe first, bounded-mutate second. It should fit ser8 and o11y work where the agent needs tailnet, kube contexts, SSM reads, and observability panes, while preserving hard fences around destructive actions. Initial scope: * read live state from ser8 and kai-server through existing guardfiles * query VictoriaMetrics, SigNoz, and deploy runbooks * inspect Kubernetes resources and Helm releases * perform reversible operational actions only through explicit ward/ward-kdl verbs * file and dispatch implementation work when the fix belongs in a repo Non-goals: * no force-pushes or history rewriting * no ad hoc secret printing * no unguarded kubectl/helm/aws access * no replacing engineer for repo changes Design questions: * should ops be a startup role beside engineer/director/advisor, or a guardfile profile that director can dispatch into? * what exact mutation verbs are safe for v1: rollout restart, helm diff/template, secret force-sync, alert silence, pipeline apply? * how should ops report evidence back to an issue: links, commands run, query snippets, status snapshots? Deploy-side references to read before design: coilyco-bridge/deploy docs/o11y.md, docs/o11y-sources.md, services/ser8-observability/docs/ser8-k3s.md, services/ser8-observability/docs/ser8-signoz.md, and services/fleet-reachability/docs/gatus.md.

coilyco-ops commented

2026-07-09 16:58:41 +00:00

Author

Member

🔎 ward agent advisor

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

Read the issue title, body, and comment thread below as the research brief. Identify the decisions, options, open questions, and risks, then give a clear advisory recommendation that can be posted back on the issue.

Recommendation

Add ops as a first-class warded startup role, not as a hidden guardfile profile on director or advisor.

The reason is structural, not cosmetic:

ward already models behavior at the role layer and permissions at the guardfile layer.
advisor is explicitly answer-only and comment/fanout oriented.
director is a backlog supervisor that dispatches engineer work and owns the drain surface.
The proposed ops lane has a different contract: inspect live state first, take tightly bounded reversible actions second, then report evidence and file/dispatch repo work when the fix belongs in code.

That is role-shaped behavior, not just a different permission bundle.

A good v1 shape is:

warded ops <ref> for issue-bound live investigation.
No code changes, no merge path, no repo landing.
Same answer format discipline as advisor research, but with an explicit live-ops evidence section.
Later, director can learn to dispatch ops for issues labeled or triaged as operational. That should be a follow-up, not the first slice.

What the repo already says

The current repo already points toward this split:

docs/agent.md defines a startup-role roster: engineer, director, advisor, qa.
director and advisor already carry the live-observe set through role wiring in .ward/ward-kdl/ward-kdl.fleet.kdl.
That same fleet file shows the right abstraction boundary: roles choose guardfiles.
The deploy docs confirm the need for a live-ops lane. ser8 is now the canonical ops/o11y plane, with:
- VictoriaMetrics at ser8:30428
- SigNoz at ser8:30808
- k3s contexts for ser8 and kai-server
- SSM-backed credentials and parameters

So the issue is not whether a live-ops surface is needed. It is whether ward should represent it explicitly. The answer is yes.

Advisory design

1. Make `ops` a startup role

Recommended behavior contract:

Primary mode: issue-bound, one-shot live investigation.
Non-goal: no code edits, no commit/push/merge.
Escalation path: when the fix belongs in a repo, ops files and dispatches implementation work instead of editing code itself.
Freeform mode is optional for v1. If it exists, keep it attached and read-only-by-default, closer to advisor than engineer.

Why not a director profile:

A profile only changes reachable commands.
The hard problem here is also prompting, evidence reporting, mutation doctrine, and handoff behavior.
Those are role semantics.

2. Split observe from mutate in the surfaced verbs, not just in the prompt

This is the biggest implementation risk.

Today the existing guardfiles are too broad to reuse unchanged for a "live-observe first" role:

ward-kdl ops aws includes reads, but also ssm put-parameter, s3 cp, and s3 sync.
ward-kdl ops kubectl includes reads, but also apply, scale, rollout restart, and rollout undo.
ward-kdl ops signoz already includes both read-like query paths and mutating paths such as pipeline/dashboard/rule create/edit.

If ops simply inherits those guardfiles, the role will not actually be bounded the way the issue asks.

Recommended pattern:

Follow the existing ward-kdl-read / ward-kdl-write / ward-kdl-admin split already used for Forgejo and SigNoz.
Give ops a read-first default bundle.
Add a small explicit write bundle only for the specific reversible verbs accepted for v1.

That keeps the safety property in the compiled surface, not in agent obedience alone.

3. Prefer purpose-built operator verbs over generic raw tooling for mutations

The issue body already hints at the right principle: reversible live actions should go through explicit ward / ward-kdl verbs.

That argues against exposing generic mutation-heavy tools as the main write path.

For v1, prefer verbs like these over broad kubectl apply or ad hoc helm use:

rollout restart for a named workload
rollout status / rollout history / rollout undo
a bounded force-sync-secret wrapper modeled on deploy/scripts/force-sync-secret.sh
read-only Helm inspection verbs such as template, diff, list, status, get values, get manifest

This gives the audit log a stable intent vocabulary and avoids turning ops into "engineer with kube access".

Recommended v1 verb set

Safe to include in v1

These fit the "live-observe first, bounded-mutate second" brief well:

Read-only cluster inspection
- kubectl get, describe, logs, events, top, config current-context, config get-contexts
Read-only observability inspection
- SigNoz query-range
- SigNoz list/get dashboards and rules
- VictoriaMetrics query surface, if added as a dedicated read API
Read-only deploy/runbook access
- deploy docs and runbooks from the repo clone
Bounded reversible mutations
- kubectl rollout restart
- kubectl rollout status
- kubectl rollout history
- kubectl rollout undo
- explicit secret reconcile / force-sync verb that waits for Ready and reports result
Read-only Helm
- helm template
- helm diff or equivalent preview
- helm list, helm status, helm get values, helm get manifest

Defer from v1

These are either too broad, insufficiently audited, or conflict with the current design intent:

kubectl apply
generic kubectl scale
generic Helm upgrade/install/uninstall
alert silence / enable-disable toggles
direct Tailscale ACL mutation
SSM writes as part of normal ops runs
SigNoz dashboard/rule authoring from the ops role
SigNoz pipeline apply, unless the repo-backed source-of-truth and rollback story are tightened first

Answers to the issue's design questions

Should `ops` be a startup role or a guardfile profile?

Recommendation: startup role.

Keep the internal implementation as role -> guardfile bundles, but expose ops as a first-class role beside engineer / director / advisor / qa.

That gives ward a clean place for:

no-code doctrine
live-ops prompt framing
evidence/reporting schema
mutation discipline
future director dispatch policy

What mutation verbs are safe for v1?

Recommended yes:

rollout restart
rollout status
rollout history
rollout undo
Helm diff/template and other read-only Helm inspection
explicit secret force-sync verb with wait-and-verify behavior

Recommended no for v1:

alert silence
generic pipeline apply
generic kubectl apply
generic Helm upgrade/install

Rationale:

rollout restart and rollout undo are operationally common, scoped, and reversible.
helm diff/template are read-only and align with the brief.
force-sync-secret already has a concrete deploy-side operational model.
alert silence is easy to abuse and currently unsurfaced for similar reasons in existing guardfile design.
pipeline apply changes live parsing behavior and today belongs closer to repo-backed config change than emergency ops.

How should ops report evidence back to an issue?

Use a structured markdown comment with fixed sections.

Recommended shape:

Summary
- one-paragraph answer: what is broken, healthy, or inconclusive
Evidence
- exact ward / ward-kdl commands run
- UTC timestamps
- target cluster/context/namespace/service
- query snippets or body-file paths used
Snapshots
- concise status excerpts: pod phase, rollout revision, alert/rule state, query result counts, error strings
Action taken
- either none or the explicit bounded mutation performed
- before/after state
Next step
- resolved operationally, needs human follow-up, or file + dispatch implementation work

Rules worth baking into the prompt/docs:

never paste secrets or full secret material
prefer links/paths to runbooks and checked-in manifests over long pasted blobs
include the exact ward verb path, not raw tool paraphrase
distinguish observed fact from inference

Gaps the issue should account for

These are the concrete holes between the desired role and the current repo state:

There is no dedicated VictoriaMetrics operator surface in ward today.
There is no Helm operator surface in ward-kdl today.
Current aws and kubectl surfaces are too broad to reuse unchanged for an observe-first role.
Existing read/write/admin tiering is incomplete across the ops areas that this role needs.
The prompt/doctrine for advisor is research-oriented, not action-oriented, so widening advisor would blur responsibilities.

Risks

Role confusion: if ops is not clearly no-code, it will drift into engineer territory.
Permission drift: if ops reuses current broad guardfiles, the safety model will be mostly social, not compiled.
Audit ambiguity: raw generic kubectl/aws mutations make it harder to tell intent from logs than purpose-built ops verbs do.
Source-of-truth bypass: live changes to dashboards, rules, or pipelines can diverge from the deploy repo unless explicitly constrained.
Director overreach: auto-dispatching ops too early could create live-mutation automation before the role's fences are proven.

Final recommendation

Post back on the issue with this direction:

Add warded ops as a new startup role.
Keep it no-code and issue/evidence driven.
Build it on read-first guardfile bundles, with a tiny explicit reversible-write set.
For v1, include live inspection plus bounded actions like rollout restart/undo and secret force-sync.
Defer broad config-authoring mutations like alert silence, generic apply, and pipeline writes until the repo/source-of-truth story is tighter.
Treat future director -> ops dispatch as a second slice after the standalone role and verb fences exist.

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: > Read the issue title, body, and comment thread below as the research brief. Identify the decisions, options, open questions, and risks, then give a clear advisory recommendation that can be posted back on the issue. --- ## Recommendation Add **`ops` as a first-class `warded` startup role**, not as a hidden guardfile profile on `director` or `advisor`. The reason is structural, not cosmetic: - `ward` already models behavior at the **role** layer and permissions at the **guardfile** layer. - `advisor` is explicitly answer-only and comment/fanout oriented. - `director` is a backlog supervisor that dispatches `engineer` work and owns the drain surface. - The proposed `ops` lane has a different contract: **inspect live state first, take tightly bounded reversible actions second, then report evidence and file/dispatch repo work when the fix belongs in code**. That is role-shaped behavior, not just a different permission bundle. A good v1 shape is: - `warded ops <ref>` for issue-bound live investigation. - No code changes, no merge path, no repo landing. - Same answer format discipline as advisor research, but with an explicit live-ops evidence section. - Later, `director` can learn to dispatch `ops` for issues labeled or triaged as operational. That should be a follow-up, not the first slice. ## What the repo already says The current repo already points toward this split: - `docs/agent.md` defines a startup-role roster: `engineer`, `director`, `advisor`, `qa`. - `director` and `advisor` already carry the **live-observe** set through role wiring in `.ward/ward-kdl/ward-kdl.fleet.kdl`. - That same fleet file shows the right abstraction boundary: **roles choose guardfiles**. - The deploy docs confirm the need for a live-ops lane. `ser8` is now the canonical ops/o11y plane, with: - VictoriaMetrics at `ser8:30428` - SigNoz at `ser8:30808` - k3s contexts for `ser8` and `kai-server` - SSM-backed credentials and parameters So the issue is not whether a live-ops surface is needed. It is whether ward should represent it explicitly. The answer is yes. ## Advisory design ### 1. Make `ops` a startup role Recommended behavior contract: - **Primary mode**: issue-bound, one-shot live investigation. - **Non-goal**: no code edits, no commit/push/merge. - **Escalation path**: when the fix belongs in a repo, `ops` files and dispatches implementation work instead of editing code itself. - **Freeform mode** is optional for v1. If it exists, keep it attached and read-only-by-default, closer to advisor than engineer. Why not a director profile: - A profile only changes reachable commands. - The hard problem here is also **prompting, evidence reporting, mutation doctrine, and handoff behavior**. - Those are role semantics. ### 2. Split observe from mutate in the surfaced verbs, not just in the prompt This is the biggest implementation risk. Today the existing guardfiles are too broad to reuse unchanged for a "live-observe first" role: - `ward-kdl ops aws` includes reads, but also `ssm put-parameter`, `s3 cp`, and `s3 sync`. - `ward-kdl ops kubectl` includes reads, but also `apply`, `scale`, `rollout restart`, and `rollout undo`. - `ward-kdl ops signoz` already includes both read-like query paths and mutating paths such as pipeline/dashboard/rule create/edit. If `ops` simply inherits those guardfiles, the role will not actually be bounded the way the issue asks. Recommended pattern: - Follow the existing **`ward-kdl-read` / `ward-kdl-write` / `ward-kdl-admin`** split already used for Forgejo and SigNoz. - Give `ops` a **read-first default bundle**. - Add a **small explicit write bundle** only for the specific reversible verbs accepted for v1. That keeps the safety property in the compiled surface, not in agent obedience alone. ### 3. Prefer purpose-built operator verbs over generic raw tooling for mutations The issue body already hints at the right principle: reversible live actions should go through **explicit `ward` / `ward-kdl` verbs**. That argues against exposing generic mutation-heavy tools as the main write path. For v1, prefer verbs like these over broad `kubectl apply` or ad hoc `helm` use: - `rollout restart` for a named workload - `rollout status` / `rollout history` / `rollout undo` - a bounded `force-sync-secret` wrapper modeled on `deploy/scripts/force-sync-secret.sh` - read-only Helm inspection verbs such as `template`, `diff`, `list`, `status`, `get values`, `get manifest` This gives the audit log a stable intent vocabulary and avoids turning `ops` into "engineer with kube access". ## Recommended v1 verb set ### Safe to include in v1 These fit the "live-observe first, bounded-mutate second" brief well: - **Read-only cluster inspection** - `kubectl get`, `describe`, `logs`, `events`, `top`, `config current-context`, `config get-contexts` - **Read-only observability inspection** - SigNoz query-range - SigNoz list/get dashboards and rules - VictoriaMetrics query surface, if added as a dedicated read API - **Read-only deploy/runbook access** - deploy docs and runbooks from the repo clone - **Bounded reversible mutations** - `kubectl rollout restart` - `kubectl rollout status` - `kubectl rollout history` - `kubectl rollout undo` - explicit secret reconcile / force-sync verb that waits for Ready and reports result - **Read-only Helm** - `helm template` - `helm diff` or equivalent preview - `helm list`, `helm status`, `helm get values`, `helm get manifest` ### Defer from v1 These are either too broad, insufficiently audited, or conflict with the current design intent: - `kubectl apply` - generic `kubectl scale` - generic Helm upgrade/install/uninstall - alert silence / enable-disable toggles - direct Tailscale ACL mutation - SSM writes as part of normal ops runs - SigNoz dashboard/rule authoring from the ops role - SigNoz pipeline apply, unless the repo-backed source-of-truth and rollback story are tightened first ## Answers to the issue's design questions ### Should `ops` be a startup role or a guardfile profile? **Recommendation: startup role.** Keep the internal implementation as role -> guardfile bundles, but expose `ops` as a first-class role beside `engineer` / `director` / `advisor` / `qa`. That gives ward a clean place for: - no-code doctrine - live-ops prompt framing - evidence/reporting schema - mutation discipline - future director dispatch policy ### What mutation verbs are safe for v1? **Recommended yes:** - rollout restart - rollout status - rollout history - rollout undo - Helm diff/template and other read-only Helm inspection - explicit secret force-sync verb with wait-and-verify behavior **Recommended no for v1:** - alert silence - generic pipeline apply - generic `kubectl apply` - generic Helm upgrade/install Rationale: - `rollout restart` and `rollout undo` are operationally common, scoped, and reversible. - `helm diff/template` are read-only and align with the brief. - `force-sync-secret` already has a concrete deploy-side operational model. - alert silence is easy to abuse and currently unsurfaced for similar reasons in existing guardfile design. - pipeline apply changes live parsing behavior and today belongs closer to repo-backed config change than emergency ops. ### How should ops report evidence back to an issue? Use a **structured markdown comment** with fixed sections. Recommended shape: 1. **Summary** - one-paragraph answer: what is broken, healthy, or inconclusive 2. **Evidence** - exact `ward` / `ward-kdl` commands run - UTC timestamps - target cluster/context/namespace/service - query snippets or body-file paths used 3. **Snapshots** - concise status excerpts: pod phase, rollout revision, alert/rule state, query result counts, error strings 4. **Action taken** - either `none` or the explicit bounded mutation performed - before/after state 5. **Next step** - `resolved operationally`, `needs human follow-up`, or `file + dispatch implementation work` Rules worth baking into the prompt/docs: - never paste secrets or full secret material - prefer links/paths to runbooks and checked-in manifests over long pasted blobs - include the exact ward verb path, not raw tool paraphrase - distinguish observed fact from inference ## Gaps the issue should account for These are the concrete holes between the desired role and the current repo state: - There is **no dedicated VictoriaMetrics operator surface** in ward today. - There is **no Helm operator surface** in ward-kdl today. - Current `aws` and `kubectl` surfaces are **too broad** to reuse unchanged for an observe-first role. - Existing read/write/admin tiering is **incomplete** across the ops areas that this role needs. - The prompt/doctrine for advisor is research-oriented, not action-oriented, so widening advisor would blur responsibilities. ## Risks - **Role confusion**: if `ops` is not clearly no-code, it will drift into engineer territory. - **Permission drift**: if `ops` reuses current broad guardfiles, the safety model will be mostly social, not compiled. - **Audit ambiguity**: raw generic `kubectl`/`aws` mutations make it harder to tell intent from logs than purpose-built ops verbs do. - **Source-of-truth bypass**: live changes to dashboards, rules, or pipelines can diverge from the deploy repo unless explicitly constrained. - **Director overreach**: auto-dispatching ops too early could create live-mutation automation before the role's fences are proven. ## Final recommendation Post back on the issue with this direction: - Add **`warded ops` as a new startup role**. - Keep it **no-code** and **issue/evidence driven**. - Build it on **read-first guardfile bundles**, with a **tiny explicit reversible-write set**. - For v1, include live inspection plus bounded actions like **rollout restart/undo** and **secret force-sync**. - Defer broad config-authoring mutations like **alert silence**, **generic apply**, and **pipeline writes** until the repo/source-of-truth story is tighter. - Treat future **director -> ops dispatch** as a second slice after the standalone role and verb fences exist. --- 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`

coilysiren commented

2026-07-09 17:03:06 +00:00

Owner

I think the way we do this is via downgrading director / engineer / advisor / qa to ward KDL "read" tier, and having ops be the only one we gets "write"

Except... director and engineer need simple writes like issue status...

So we probably need to do pre-work around the ward KDL security tiers they maybe well here, its just that their names are off

And doing THAT probably wants us to swap ward KDL to be aos released

I think the way we do this is via downgrading director / engineer / advisor / qa to ward KDL "read" tier, and having ops be the only one we gets "write" Except... director and engineer need simple writes like issue status... So we probably need to do pre-work around the ward KDL security tiers they maybe well here, its just that their names are off And doing THAT probably wants us to swap ward KDL to be aos released

coilyco-ops commented

2026-07-09 17:04:35 +00:00

Author

Member

Appraisal after the advisor answer and Kai's follow-up:

The advisor is directionally right that ops is role-shaped behavior, not just a hidden profile. Its strongest point is the role contract: live investigation, bounded reversible action, evidence report, then file or dispatch repo work. That should stay.

Kai's follow-up catches the deeper prerequisite: the current tier names and bundles are not quite the security model we want. The real split is not simply read/write/admin per API. It is role capability posture:

director, engineer, advisor, and qa mostly need observe plus issue-thread writes.
engineer also needs git/repo writes inside its owned feature container, but that is different from live ops mutation.
director needs dispatch and issue status/comment writes, but not cluster mutation.
ops is the first role that should intentionally receive live operational write verbs.

So the next slice should not be "add ops and point it at existing write guardfiles." The next slice should be a tier taxonomy pass that separates:

observe/read surfaces
forge coordination writes, such as issue comments, status, reservations, dispatch bookkeeping
repo-sandbox writes, scoped to engineer containers
live-ops writes, scoped to bounded operational verbs
admin/destructive writes, normally absent from agent roles

That means the advisor's proposed ops v1 is a good destination, but its implementation should depend on this tier cleanup. Otherwise ops will inherit today's broad aws, kubectl, or signoz surfaces and the safety story will be mostly prompt discipline.

On "swap ward KDL to be aos released": that looks mostly done or at least already tracked by ward#503. The aos docs say the coilyco ward-spec bundle is authored in aos and overlaid into ward release builds as of the 2026-07-07 cutover. I would treat that as a dependency check, not a new design direction. The still-open architectural sibling is ward#721, which says KDL should remain edge-surface authoring and not become ward core's runtime control plane.

Recommended dependency chain:

Use ward#721 as the boundary guardrail: KDL owns guarded edge surfaces, ward owns role behavior and core runtime semantics.
Add a pre-work issue for role capability tiers if this issue should not grow that scope inline.
Then implement warded ops as a first-class role using the cleaned tier model: observe by default, forge coordination writes where needed, and only tiny live-ops writes.
Defer director auto-dispatching to ops until the standalone role and tier fences have held up.

Bottom line: keep the advisor's role recommendation, but accept Kai's correction that tier cleanup comes first. ops should be the role that proves the new tier model, not the role that papers over the old one.

Appraisal after the advisor answer and Kai's follow-up: The advisor is directionally right that `ops` is role-shaped behavior, not just a hidden profile. Its strongest point is the role contract: live investigation, bounded reversible action, evidence report, then file or dispatch repo work. That should stay. Kai's follow-up catches the deeper prerequisite: the current tier names and bundles are not quite the security model we want. The real split is not simply read/write/admin per API. It is role capability posture: * `director`, `engineer`, `advisor`, and `qa` mostly need observe plus issue-thread writes. * `engineer` also needs git/repo writes inside its owned feature container, but that is different from live ops mutation. * `director` needs dispatch and issue status/comment writes, but not cluster mutation. * `ops` is the first role that should intentionally receive live operational write verbs. So the next slice should not be "add `ops` and point it at existing write guardfiles." The next slice should be a tier taxonomy pass that separates: * observe/read surfaces * forge coordination writes, such as issue comments, status, reservations, dispatch bookkeeping * repo-sandbox writes, scoped to engineer containers * live-ops writes, scoped to bounded operational verbs * admin/destructive writes, normally absent from agent roles That means the advisor's proposed `ops` v1 is a good destination, but its implementation should depend on this tier cleanup. Otherwise `ops` will inherit today's broad `aws`, `kubectl`, or `signoz` surfaces and the safety story will be mostly prompt discipline. On "swap ward KDL to be aos released": that looks mostly done or at least already tracked by ward#503. The aos docs say the coilyco ward-spec bundle is authored in aos and overlaid into ward release builds as of the 2026-07-07 cutover. I would treat that as a dependency check, not a new design direction. The still-open architectural sibling is ward#721, which says KDL should remain edge-surface authoring and not become ward core's runtime control plane. Recommended dependency chain: 1. Use ward#721 as the boundary guardrail: KDL owns guarded edge surfaces, ward owns role behavior and core runtime semantics. 2. Add a pre-work issue for role capability tiers if this issue should not grow that scope inline. 3. Then implement `warded ops` as a first-class role using the cleaned tier model: observe by default, forge coordination writes where needed, and only tiny live-ops writes. 4. Defer director auto-dispatching to `ops` until the standalone role and tier fences have held up. Bottom line: keep the advisor's role recommendation, but accept Kai's correction that tier cleanup comes first. `ops` should be the role that proves the new tier model, not the role that papers over the old one.

coilyco-ops added the

consult

labels

2026-07-09 18:09:20 +00:00

coilyco-ops referenced this issue

2026-07-09 18:26:49 +00:00

Add composable semantic capabilities for warded roles #846

coilyco-ops referenced this issue

2026-07-09 18:26:53 +00:00

Design warded role capability tiers before adding ops #819

coilyco-ops referenced this issue

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