vibe-production-mindset

The gap between "works on my machine" and "works in production" is where incidents live. The goal is to avoid under-engineering the critical paths, not to add every hardening pattern to every feature. Pair it with vibe-scope-guard.

When to Use This Skill

• Implementing API endpoints, data processing, or user-facing features that will run in production
• Before declaring a production feature "done"
• When the user cares about production quality

When NOT to Use This Skill

• Prototypes or spikes explicitly marked as throwaway
• Internal scripts that run once
• Test code (different quality criteria)
• When the user says "just get it working"

Calibrate First

Before running the checklist, establish the stakes and the conventions:

• What already exists? Use the project's existing logger, metrics, retry, and validation libraries. Don't introduce a second one.
• What's the real scale and blast radius? An internal admin tool and a public payments API need different answers.
• Only flag an item if it applies at this project's scale. A missing circuit breaker is not a gap in a service with one dependency and ten users.

The Checklist

1. Observability

• Logs at key decision points use the project's structured logger
• Request/correlation IDs are propagated, if the project already uses them
• Metrics for key operations, if the project has a metrics pipeline

2. Error Handling at System Boundaries

• External calls (HTTP, DB, queues) have timeouts
• Retries with backoff where the operation is idempotent
• Specific handling for expected failures (not found, permission denied, conflict)
• Errors carry enough context to debug, and no secrets

3. Input Validation

• External input is validated before processing
• Size limits on strings, arrays, and uploads
• Parameterized queries and output encoding (injection, XSS)
• Authentication before authorization, and authorization on every access path

4. Graceful Degradation (only where dependencies justify it)

• Defined behavior when a dependency is down
• Graceful shutdown (drain in-flight work)
• Health check, if the deploy target uses one

5. Resource Management

• Connections, files, and handles are closed or returned to the pool
• Goroutines, threads, and tasks have bounded lifetimes
• No unbounded in-memory growth (caches, queues, buffers)

6. Performance Budgets (when performance is a requirement)

• Budgets are targets from the spec (published thresholds, competitor medians), not today's measurement plus a margin
• Named profiles: a constrained one for CI (slow link, throttled CPU) and a typical target device
• Per-route or per-endpoint budgets: payload sizes (JS, CSS, HTML, fonts, total) and timings (e.g., LCP, CLS, TBT, p95 latency)
• Overrides carry a written reason; raising a default requires a spec change
• Enforced in CI; a failing budget is fixed in code, never raised to pass
• Performance changes report "no budgets loosened", and call out mechanical key renames so they aren't mistaken for loosening

Steps

1. Calibrate (above)
2. Read the implementation
3. Run the checklist, skipping items that don't apply
4. Flag gaps with file:line and a specific fix that uses existing project conventions

Output Format

Production Readiness: [Feature Name]

Stakes: [e.g., public API, ~10k req/min] · Overall: READY / NEEDS_WORK / NOT_READY

Category	Status	Gaps
Observability	✓/◐/✗/n/a	[count]
Error Handling	✓/◐/✗/n/a	[count]
Input Validation	✓/◐/✗/n/a	[count]
Graceful Degradation	✓/◐/✗/n/a	[count]
Resource Management	✓/◐/✗/n/a	[count]
Performance Budgets	✓/◐/✗/n/a	[count]

Critical Gaps

1. [gap with file:line and the fix]