architecture-conformancelisted

# Architecture Conformance Bundled commands use `$PLUGIN_ROOT` (`$env:PLUGIN_ROOT` in PowerShell; same path suffix) for the plugin root. Set it once: use the host's plugin-root variable when defined (Claude Code: `PLUGIN_ROOT="$CLAUDE_PLUGIN_ROOT"`), otherwise the absolute path of this plugin's root directory. Use when the question is whether implementation still matches intended architecture. Triggers: compare code to ADR/docs/policy, detect drift or erosion, turn intent into checks, classify edges as convergence/divergence/absence/unknown, recover observed architecture before updating docs. ## Inputs - Intended model: ADRs, diagrams, README architecture sections, package rules, service boundaries, CODEOWNERS/OWNERS, ownership docs, explicit constraints. - Observed model: source tree, imports, manifests, build graph, tests, runtime config, deployment/IaC, recent changes. - Policy scope: modules, services, packages, data stores, topics, runtime paths. - Exception path: waivers, migration windows, legacy constraints, owners. If intent is thin, label it incomplete. Do not convert recovered source shape into design intent. ## AI-Produced Architecture Changes Apply the same conformance standard to human- and agent-authored patches. For an AI-produced change, derive issue-specific review axes from source: components and responsibilities, dependency direction and layering, public APIs and extension points, cross-cutting conventions, critical boundaries, and cross-module pro