| name | readiness-audit |
| description | Audit corp-llm-gateway's operational/product readiness — config resolution, management CLI, Helm/Docker deploy, observability, docs, packaging — and produce a prioritized gap report with a top-5 build list. Use for "readiness audit", "is this deployable", "what's missing to ship", "productionization gaps". Not for code correctness (use security-audit for leaks). |
Readiness audit
Assess whether corp-llm-gateway is a deployable product an operator can install, configure, run, and manage — not just a library. Output is a gap report, not code changes.
Depth
- Quick (default): one pass, inline, over the six dimensions below.
- Thorough: fan out parallel Explore agents (one per dimension), then synthesize. Use when the caller says "thorough"/"comprehensive" or after a big change.
What to examine (six dimensions)
- Config —
config.py (resolution chain env → $CORP_LLM_GATEWAY_CONFIG_FILE → ~/.corp-llm-gateway → /etc → default), config.example.toml, settings.py if present. Every key documented? Single source of truth? Any os.environ read at a call site (forbidden)? Startup validation? Undocumented server keys?
- Management surfaces —
cli/{status,admin,proxy}.py. What can operators actually DO (team CRUD, token issue/revoke, extensions list/health, config check, rules reload, audit query, quota)? What's a print() stub vs wired to a real store?
- Deployment —
helm/corp-llm-gateway/ + Dockerfile*. Does the chart run the gateway image with the guardrail callback (corp_llm_gateway.bootstrap.guardrail) or stock LiteLLM? Secrets, resource limits, HPA/PDB, probes (/healthz/*), NetworkPolicy, Vector source (kubernetes_logs not stdin), values-staging. CPU-only (no GPU).
- Observability —
healthz/ served or just classes? Metrics emitted (do siem-alerts.yaml/runbook metric names exist in code)? /metrics, ServiceMonitor, dashboards, runbooks in docs/ops/.
- Docs —
docs/ + docs/ops/ + docs/remaining-steps.md. Install/prereqs/secret-contract, config reference, admin-CLI reference, troubleshooting, upgrade/migration.
- Packaging —
pyproject.toml ([project.scripts], extras), scripts/install.sh, .github/workflows/ (does CI build+publish the image/chart, or only the wheel?).
Grounding rules
Cite exact file:line. Be specific to THIS repo — no generic "add monitoring". Respect conventions: default branch master, CI is GitHub Actions, interface-registry pattern (ABC in <module>/<base>.py → impls → __init__.py re-export). Distinguish "class exists but nothing serves/consumes it" from "missing entirely" — that gap recurs here.
Output
- Current state (2–3 sentences: how mature, library-vs-product).
- Gap table: Gap | Why it matters | Effort (S/M/L) | Category (config/mgmt/deploy/obs/docs/packaging).
- Top 5 to build first, each with a concrete deliverable (a file, a command, a chart addition).
- Concrete file/module list for the new work, following repo conventions.
Cross-check against the live plan docs/plans/*ga-readiness* before reporting a gap as open — much may already be done or in flight.
