docs(rfcs): add RFC 0001 — plugin architecture for custom agents

[PAMulligan]

Summary

RFC 0001 — the design doc for the v2.0.0 plugin architecture for custom agents (#79), the milestone's highest-risk item. Per the issue, this is committed before implementation and must be reviewed and accepted first.

docs/rfcs/ is established here (this is the first RFC), with a short process + index README.

Grounded in what already exists

Aurelius already ships a v1 local plugin system (manifest schema, four CLIs, transitive semver dependency resolution, management-lifecycle hooks, installed.json) — see docs/guides/agent-plugins.md. It deliberately deferred the riskiest concerns as non-goals: sandboxing, distribution, runtime hooks. The RFC ratifies that foundation and designs the v2 evolution rather than reinventing it.

What the RFC covers (acceptance criteria)

• Committed under docs/rfcs/0001-plugin-architecture.md
• Plugin discovery — local scan, installed-state provenance, remote sources (git/tarball/registry), a lockfile for reproducible offline installs
• Manifest format — reaffirms the strict v1 schema and adds optional, backward-compatible v2 fields (compatibility/engines, capabilities, integrity, signature, distribution metadata)
• Lifecycle hooks — separates management hooks (exist) from harness settings.json hooks (operator-consented); no invocation-time hooks (Claude Code can't fire them)
• Sandboxing — a default-deny trust model (untrusted / trusted / verified): untrusted plugins run no install hooks, get tools intersected against an allow-list, and cannot use bypassPermissions; integrity via sha256, signatures for the verified tier; honest about bash not being a real sandbox
• Versioning — semver + framework compatibility range; single installed version
• Distribution — phased local → remote (mandatory integrity) → curated registry (publish + signing)
• Compatibility with the built-in agents — shared .claude/agents/ namespace, reserved built-in names / no silent shadowing, built-ins as versioned dependencies via a generated agents.catalog.json, identical frontmatter contract; the model is count-independent (the "48 vs 56" delta is irrelevant)

Plus security-threats table, a phased migration that never breaks v1 plugins, alternatives, and open questions for reviewers.

Status

Proposed. Acceptance is recorded in §14 on maintainer approval; no implementation beyond the shipped v1 tooling should merge until then. This satisfies "reviewed and accepted before any implementation work starts."

Note: the issue references the "built-in 48 agents"; the catalog is 56 today. The RFC's compatibility model keys off agent names + versions, not a count, and notes the delta explicitly.

Refs #79