architecture-runtime-topology

# Architecture Runtime Topology 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 how the system runs, communicates, fails, scales, or is operated. ## Inputs - Deployment: Docker, Compose, Kubernetes, Helm, Terraform, serverless, Procfile, platform manifests, CI/CD, release config. - Runtime config: env/config directories, service discovery, feature flags, schedulers/jobs. - Integrations: HTTP, gRPC, GraphQL, queues, topics, cache, database, external APIs, webhooks, batch. - Observability: logs, metrics, traces, dashboards, alerts, SLOs, health checks, incidents. - Resilience: timeout, retry, circuit breaker, fallback, bulkhead, rate limit, idempotency, backpressure, degradation. - Ownership: service owners, CODEOWNERS/OWNERS, runbooks, escalation paths, review gates. Record paths and signal names only; never repeat secret values. ## Probe ```bash python3 "$PLUGIN_ROOT/scripts/architecture_probe.py" <repo-path> --json ``` Use `runtime_topology` as evidence inventory. It detects deployment artifacts and runtime signal names, not production truth. ## Lenses - Topology: what deploys, what calls what, and which runtime edges matter. - Failure behavior: slow/down/partial/overloaded/inconsistent dependency response. ...