1 min read
Production Debugging
Kevin's production-debugging context is not just incident experience; it is the expectation that failures leave guardrails, tests, ledgers, dashboards, postmortems, or automation behind.
Open this page when a task touches production behavior, billing, auth, fraud, reliability, infrastructure, or reviewer-facing code quality.
Debugging Model
| Principle | Operational meaning |
|---|---|
| Reproduce before patching | Prefer failing tests, traces, logs, or direct runtime proof before changing the mechanism. |
| Name the invariant | State what must remain true across states, retries, users, tenants, or billing periods. |
| Preserve evidence | Keep command output, screenshots, logs, traces, source links, or timeline entries. |
| Fail closed | Avoid best-effort gates on value-granting, auth, billing, onboarding, or security paths. |
| Codify the lesson | Add a postmortem, check, doctor, lint rule, dashboard, alert, or workflow when a failure can recur. |
Where It Shows Up
- private page: auth, billing, admin tooling, fraud/bot/security, and agent-infra production surfaces.
- private page and related postmortems: ledger correctness and value-granting flows.
- Security and Review Skills: high-risk code quality gate and score-to-100 review posture.
- Production Safety and Agent Guardrails Architecture: reusable production and guardrail concepts.
Agent Use
If a task could affect money, auth, customer data, admin access, sandbox isolation, or production reliability, do not treat lint as proof. Use invariant tests, surface checks, and no-sus review. Say exactly what was not verified.
Timeline
- 2026-07-01 | Rebuilt production debugging around the current no-sus/production-safety model and Dedalus production surfaces. private page
- 2026-05-31 | Production debugging strength noted from USER.md. Source: public wiki expansion, 2026-05-31