Refactor: security-pure engine + thin KDL-expressed consumers (coily/ward/cli-guard) #123
Labels
No labels
burndown-2026-06
sunday-sprint
coherence-core
consult
headless
interactive
P0
P1
P2
P3
P4
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
coilyco-flight-deck/cli-guard#123
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Direction
Refactor the coily / ward / cli-guard family toward "security-pure engine + thin KDL-expressed consumers." Captured from a design discussion. Verdict: ~75% coherent, one internal contradiction to resolve before starting.
Two axes (don't conflate them)
The KDL move and the merge move are pure Axis A (good). "Strictly security tooling / remove general-purpose automation" and "more opt-in" are Axis B pushing toward narrower coverage - which is less security, fighting the "more strictly security" framing.
The contradiction
coily's security value is being the path of least resistance for everything (
Bash(coily:*)funnels all ops through one re-validating binary). The mundane dev verbs (coily exec test,.coily/coily.yaml) look like non-security automation but they ARE the hook - the bait that makes agents route through the funnel. Strip them and agents reach for baremake/sh -c/python -c, which are the exact escape hatches the funnel exists to close.Reframe "remove general-purpose automation":
Make it security-pure in implementation, security-comprehensive in coverage.
Per-move calls
ward/cmd/ward-kdlalready prove it. This is the move that earns the "security tooling" reframe (policy as reviewable plain sentences, not buried Go).examples/(one per primitive). A gallery of example guardfiles likely belongs there, next to the engine, not bloating a consumer back into the fat thing. Possible end state: cli-guard = engine + example guardfile gallery (the reference impl), coily/ward = the two real guardfiles (operator profile, contributor profile).Target state
Hardest pushback
Don't let "make it strictly security tooling" become "make it cover less." Those feel like the same instinct and they are opposites.
Next step
Turn this into a sequenced migration plan (repo moves + ordering) before any code moves.
Migration status (autonomous session, 2026-06-10)
Axis A is moving: the entire forgejo HTTP surface now lives as KDL sentences.
Landed today (cli-guard v0.7.0 -> v0.10.0, ward main):
Next, in sequence:
Per-decision record: ward survives the merge; coverage stays comprehensive (the funnel keeps its dev verbs); operator profile stays mandatory.
Backlog burndown 2026-06-17: closing low-priority (P3/P4) to bring the open count to a manageable level. Nothing lost — reopen if this resurfaces. Batch tag:
burndown-2026-06.allowinspect-list passthrough sugar (N read-only binaries per wrap) #157