Define validation ladder after ward exec retirement #1271

New issue

Open

opened 2026-07-14 10:09:21 +00:00 by coilyco-ops · 0 comments

coilyco-ops commented

2026-07-14 10:09:21 +00:00

Member

Parent

coilysiren/inbox#212

What to decide

Clarify the validation-loop friction finding after the planned retirement of ward exec.

The parent issue agrees that validation churn is real, but the suggested mitigation of adding more ward exec verbs is obsolete. This issue should define the future validation ladder and ownership model before implementation tickets try to encode new command doctrine.

Acceptance criteria

The design explains what replaces the current ward exec validation path for targeted, package-level, full-suite, and pre-commit checks.
The design separates harness-shell exploration from repo-declared validation in the post-ward exec world.
The design identifies which repos need local validation docs or command metadata updates.
The design states how agents should choose the narrowest useful validation command without hardcoding config values into tests.
Follow-up implementation tickets are created or named for each repo or tooling layer that needs changes.

Blocked by

Needs ownership clarification. Kai questioned whether this belongs in ward rather than cross-repo agentic-os doctrine.

Non-goals

Do not add new ward exec verbs.
Do not treat repeated validation as a bug by itself. The goal is to make the right validation path obvious and cheap.

Decision for release inclusion

Removed from warded control plane coherence for now. This smells like cross-repo validation doctrine unless a later pass identifies a specific ward-owned command or help surface that needs the change.

## Parent coilysiren/inbox#212 ## What to decide Clarify the validation-loop friction finding after the planned retirement of `ward exec`. The parent issue agrees that validation churn is real, but the suggested mitigation of adding more `ward exec` verbs is obsolete. This issue should define the future validation ladder and ownership model before implementation tickets try to encode new command doctrine. ## Acceptance criteria - [ ] The design explains what replaces the current `ward exec` validation path for targeted, package-level, full-suite, and pre-commit checks. - [ ] The design separates harness-shell exploration from repo-declared validation in the post-`ward exec` world. - [ ] The design identifies which repos need local validation docs or command metadata updates. - [ ] The design states how agents should choose the narrowest useful validation command without hardcoding config values into tests. - [ ] Follow-up implementation tickets are created or named for each repo or tooling layer that needs changes. ## Blocked by Needs ownership clarification. Kai questioned whether this belongs in ward rather than cross-repo agentic-os doctrine. ## Non-goals - Do not add new `ward exec` verbs. - Do not treat repeated validation as a bug by itself. The goal is to make the right validation path obvious and cheap. --- ## Decision for release inclusion Removed from `warded control plane coherence` for now. This smells like cross-repo validation doctrine unless a later pass identifies a specific ward-owned command or help surface that needs the change.

coilyco-ops added the

consult

labels

2026-07-14 10:09:21 +00:00