Operational Readiness Checklist

Comprehensive checklist to validate services before production launch. Analyzes codebase + asks interactive questions for items that cannot be detected from code.

Workflow Overview

1. •Gather context - Identify service type, tech stack, and traffic expectations
2. •Analyze codebase - Scan for CI/CD configs, infrastructure code, security patterns
3. •Interactive verification - Ask about items that cannot be detected from code
4. •Generate report - Produce checklist report with priorities and remediation guidance

Step 1: Gather Context

Ask the user these questions using AskUserQuestion:

Service Classification:

• •Service type: Backend API, Frontend/Web App, Infrastructure/Platform, or Hybrid
• •Expected traffic: <100 req/min (low), 100-1000 req/min (medium), >1000 req/min (high)
• •Data handling: Stores user data (yes/no), Processes PII (yes/no)
• •Public-facing: Yes/No
• •Has email functionality: Yes/No
• •Uses database: Yes/No (if yes, which: PostgreSQL, Supabase, DynamoDB, etc.)

Tech Stack Detection: Auto-detect from files:

• •Cargo.toml → Rust service
• •package.json → Node.js/TypeScript
• •*.tf or *.tfvars → Terraform
• •cdk.json or *.cdk.ts → AWS CDK
• •.github/workflows/*.yml → GitHub Actions CI/CD
• •next.config.js → Next.js frontend
• •Dockerfile → Containerized service

Step 2: Codebase Analysis

Analyze the codebase for evidence of checklist items. Use Glob and Grep to find:

CI/CD Detection:

.github/workflows/*.yml - GitHub Actions
Cargo.toml + [profile.release] - Rust build config
jest.config.* / vitest.config.* - Test configuration
*.tf - Terraform files
cdk.json - CDK configuration

Security Detection:

**/security*.yml - Security scanning workflows
dependabot.yml - Dependency updates
CODEOWNERS - Code ownership
*.lock files - Dependency locking

Observability Detection:

**/tracing*.rs or opentelemetry* - Distributed tracing
sentry.* or @sentry/* - Error tracking
prometheus* or metrics* - Metrics collection
**/logging*.* or log4* or tracing* - Logging config

Infrastructure Detection:

**/autoscaling* in .tf files - Autoscaling config
**/secretsmanager* or **/ssm* - Secrets management
health* endpoints in code - Health checks

Step 3: Interactive Verification

For items that cannot be detected from code, ask yes/no questions. Group questions by category to avoid overwhelming the user.

Step 4: Generate Report

Output format:

# Operational Readiness Report: [Service Name]

**Service Type:** [Backend API / Frontend / Infrastructure]
**Tech Stack:** [Detected stack]
**Generated:** [Date]

## Summary
- **Overall Readiness:** [X/Y items passing] ([Z%])
- **Launch Blockers (P0):** [count]
- **High Priority (P1):** [count]
- **Medium Priority (P2):** [count]
- **Low Priority (P3):** [count]

## Observability
| Item | Status | Priority | Notes |
|------|--------|----------|-------|
| ... | ✅/❌/⚠️ | P0-P3 | ... |

[Repeat for each category]

## Remediation Summary
[List failing items with links to remediation guidance]

Checklist Items by Category

Observability (O11Y)

Remediation: See references/remediation-o11y.md

CI/CD & Testing

Remediation: See references/remediation-cicd.md

Primitives (Infrastructure)

Remediation: See references/remediation-primitives.md

Security

Remediation: See references/remediation-security.md

3rd Party Services

Remediation: See references/remediation-dependencies.md

Service Dependencies

Remediation: See references/remediation-dependencies.md

Data Retention & Privacy

Remediation: See references/remediation-privacy.md

Efficiency & Frugality

Remediation: See references/remediation-efficiency.md

Priority Definitions

Status Indicators

• •✅ Pass - Item verified as compliant
• •❌ Fail - Item not compliant, needs remediation
• •⚠️ Partial - Partially compliant, improvements needed
• •➖ N/A - Not applicable to this service type