rename: cli-guard -> agent-guard (the engine guards more than CLIs now) + retire "ward-kdl" #200

New issue

Open

opened 2026-07-07 10:00:52 +00:00 by coilysiren · 0 comments

coilysiren commented

2026-07-07 10:00:52 +00:00

Owner

Why

The opcore extraction (cli-guard#196 / #197-199) made the engine transport-neutral - it now guards MCP surfaces (ward-mcp) as well as CLIs, so "cli-guard" is a misnomer. "agent-guard" names what it actually is: the security boundary between semi-trusted agents and the host/APIs, any transport. It matches the repo's own README ("sits between AI agents and the host system"). Context and the fuller naming POV: coilysiren/inbox#173.

Do not headless-fire this. It is a coordinated, high-blast-radius, multi-repo rename (Go module path + every importer in lockstep). Kai runs it deliberately on a clear day. Filed now so it is captured and scoped, execution is hers to schedule.

Scope - the rename sweep

The repo - rename cli-guard → agent-guard on canonical Forgejo and on the GitHub mirror. Confirm Forgejo leaves a redirect for the old path (web + git remote).
The Go module path - .../coilyco-flight-deck/cli-guard → .../agent-guard in cli-guard's own go.mod and every internal import. On Forgejo the module path tracks the repo name, so this is a real path change, not a redirect Go will follow.
Importers, in lockstep (this is why it is coordinated, and why it wants a clear day):
- ward - go.mod require + every cli-guard/... import (cli/dispatch, http/specverb, http/opcore, pkg/policy, ...).
- ward-mcp - same, and note its import is being pinned right now by ward-mcp#7, so that pin updates as part of this rename.
- Verify no other Go consumer. deploy configs reference the engine only through the guardfile grammar, not a Go import, so they are likely unaffected - confirm.
Release / distribution - cli-guard's release CI, tags, and any homebrew formula or binary name carrying "cli-guard".
Docs + cross-repo prose - the [cli-guard] links and the layer-gradient passages in aos AGENTS.md / CLAUDE.md (they name cli-guard repeatedly), ward docs/architecture.md (the 3-layer model), the pre-commit catalog / cross-repo-contract refs, and the substrate manifest (/substrate/cli-guard).
Companion: retire "ward-kdl" - same mechanical pass. The KDL guardfile dialect is the engine's authoring layer, so it becomes "agent-guard guardfiles" (or just "guardfiles"), never "ward-kdl". Update the prose where .ward/ward-kdl/ and ward ops read as a ward-owned dialect. The .guardfile.kdl / .mcp.kdl file suffixes are fine - they name the format, not the owner.

Out of scope (sequence separately)

ward → ward-cli - deferred. It is coupled to the ward#630 de-monolith (warded-the-platform vs the guardfile→CLI projection). Rename ward only after #630 splits those, so "cli" labels the projection, not the platform. Reasoning on coilysiren/inbox#173.
Issue-number references (cli-guard#N) - Forgejo keeps these resolvable through the rename redirect, no rewrite needed.

Done

agent-guard is the repo (Forgejo + mirror), the module path, and the name throughout cli-guard's own tree.
ward and ward-mcp build green against the new path (their go.mod + imports updated in the same coordinated change).
No "cli-guard" or "ward-kdl" left in tracked prose except historical / changelog records.
Release CI and homebrew (if any) build under the new name.

coilysiren/inbox#173 (the naming POV), cli-guard#196 / #197-199 (opcore - what made "cli" wrong), ward#630 (the de-monolith that gates the ward → ward-cli rename), cli-guard#163 (neutralize consumer names in engine comments/fixtures) and cli-guard#164 (generator naming soup) - both align with and are partly subsumed by this sweep.

## Why The opcore extraction (cli-guard#196 / #197-199) made the engine **transport-neutral** - it now guards MCP surfaces (ward-mcp) as well as CLIs, so **"cli-guard" is a misnomer**. "agent-guard" names what it actually is: the security boundary between semi-trusted agents and the host/APIs, any transport. It matches the repo's own README ("sits between AI agents and the host system"). Context and the fuller naming POV: coilysiren/inbox#173. **Do not headless-fire this.** It is a coordinated, high-blast-radius, multi-repo rename (Go module path + every importer in lockstep). Kai runs it deliberately on a clear day. Filed now so it is captured and scoped, execution is hers to schedule. ## Scope - the rename sweep 1. **The repo** - rename `cli-guard` → `agent-guard` on canonical Forgejo and on the GitHub mirror. Confirm Forgejo leaves a redirect for the old path (web + git remote). 2. **The Go module path** - `.../coilyco-flight-deck/cli-guard` → `.../agent-guard` in cli-guard's own `go.mod` and every internal import. On Forgejo the module path tracks the repo name, so this is a real path change, not a redirect Go will follow. 3. **Importers, in lockstep** (this is why it is coordinated, and why it wants a clear day): - **ward** - `go.mod` require + every `cli-guard/...` import (`cli/dispatch`, `http/specverb`, `http/opcore`, `pkg/policy`, ...). - **ward-mcp** - same, and note its import is being pinned **right now** by ward-mcp#7, so that pin updates as part of this rename. - Verify no other Go consumer. deploy configs reference the engine only through the guardfile grammar, not a Go import, so they are likely unaffected - confirm. 4. **Release / distribution** - cli-guard's release CI, tags, and any homebrew formula or binary name carrying "cli-guard". 5. **Docs + cross-repo prose** - the `[cli-guard]` links and the layer-gradient passages in aos `AGENTS.md` / `CLAUDE.md` (they name cli-guard repeatedly), ward `docs/architecture.md` (the 3-layer model), the pre-commit catalog / cross-repo-contract refs, and the substrate manifest (`/substrate/cli-guard`). 6. **Companion: retire "ward-kdl"** - same mechanical pass. The KDL guardfile dialect is the **engine's** authoring layer, so it becomes "agent-guard guardfiles" (or just "guardfiles"), never "ward-kdl". Update the prose where `.ward/ward-kdl/` and `ward ops` read as a ward-owned dialect. The `.guardfile.kdl` / `.mcp.kdl` file suffixes are fine - they name the format, not the owner. ## Out of scope (sequence separately) - **ward → ward-cli** - deferred. It is coupled to the ward#630 de-monolith (warded-the-platform vs the guardfile→CLI projection). Rename ward only after #630 splits those, so "cli" labels the projection, not the platform. Reasoning on coilysiren/inbox#173. - Issue-number references (`cli-guard#N`) - Forgejo keeps these resolvable through the rename redirect, no rewrite needed. ## Done - `agent-guard` is the repo (Forgejo + mirror), the module path, and the name throughout cli-guard's own tree. - ward and ward-mcp build green against the new path (their `go.mod` + imports updated in the same coordinated change). - No "cli-guard" or "ward-kdl" left in tracked prose except historical / changelog records. - Release CI and homebrew (if any) build under the new name. ## Related coilysiren/inbox#173 (the naming POV), cli-guard#196 / #197-199 (opcore - what made "cli" wrong), ward#630 (the de-monolith that gates the ward → ward-cli rename), cli-guard#163 (neutralize consumer names in engine comments/fixtures) and cli-guard#164 (generator naming soup) - both align with and are partly subsumed by this sweep.