Vinayaka

Vinayaka — Remover of Obstacles (Production Readiness)

Vinayaka clears every obstacle before launch so nothing blocks the path in production.

Pre-deploy checklist (blocking)

• All required env vars exist in the target environment — verify against a checked-in schema (pydantic-settings / zod-parsed process.env), fail fast at boot if any are missing.
• DB migrations are reversible: every migration has a tested down, and is backward-compatible with the currently running code (expand → migrate → contract).
• Risky changes ship behind a feature flag, default off. Flag can be flipped without a deploy.
• Rollback plan documented in the PR/release notes: exact command, who runs it, and how long it takes. If rollback needs a migration reversal, rehearse it in staging.
• Staging mirrors prod: same runtime versions, same infra shape, realistic data volume. "Works in staging" means nothing if staging is a toy.

Service hardening

• Liveness and readiness probes are separate: readiness checks dependencies (DB, cache, queue); liveness checks only the process. Never point liveness at the DB.
• Graceful shutdown: trap SIGTERM, stop accepting new requests, drain in-flight work (uvicorn --timeout-graceful-shutdown, server.close() in Node), then exit. Set terminationGracePeriod above your slowest request.
• Rate limiting on every public endpoint (per-user and per-IP), returning 429 with Retry-After.
• Input validation on all endpoints — every body, query param, and header parsed through pydantic/zod. Unvalidated input never reaches business logic (see muruka).
• Structured logs with request IDs; errors go to Sentry (or equivalent) with release tagging so a bad deploy is attributable in minutes.

Deploy execution

• Deploy during low-traffic windows; never Friday evening, never right before the team goes offline.
• Roll out progressively where possible (canary or 10% → 100%).
• Monitor for 30 minutes post-deploy: error rate, p95 latency, and one core business metric. Whoever deployed watches the dashboards — the deploy is not done when CI goes green.
• Any sustained error-rate or latency regression → roll back first, debug after.

AI-native specifics

• Configure a fallback model (or degraded non-LLM path) for provider outages; verify the failover actually triggers, in staging, before launch.
• Prompts are versioned artifacts: pin the prompt version and model ID per release so behavior changes are attributable and rollbackable.
• Output guardrails before anything user-facing or side-effecting: schema-validate LLM output, enforce max length, and moderate/filter unsafe content. On guardrail failure, retry once then fall back — never ship raw failure to the user.
• Set hard spend and token-rate limits per environment so a retry loop can't burn the API budget.

Before every release — checklist

• Env vars validated at boot; migrations reversible and rehearsed
• Rollback command documented; risky paths behind a flag
• Readiness/liveness probes and graceful shutdown verified
• Rate limits + input validation on all public endpoints
• LLM fallback, prompt version pin, and output guardrails in place
• 30-minute post-deploy watch assigned to a named person