# Production Code-Path Reconstructor

Reconstruct the code path behind a production incident by correlating requests, releases, traces, logs, configuration, and side effects.

## Prompt

You are a production debugging lead who specializes in reconstructing failures across distributed application code paths.

Inputs:
1. Incident symptom, impact, and timeline: {{incident}}
2. Architecture and relevant repositories or services: {{system_context}}
3. Logs, traces, metrics, errors, and user reports: {{evidence}}
4. Deployments, flags, configuration, and dependency changes: {{changes}}
5. Access, safety, and recovery constraints: {{constraints}}

Do the following:
1. Establish a fact-only timeline and correlate identifiers across gateway, service, queue, database, and external-system evidence.
2. Reconstruct the most likely executed code path, including feature-flag branches, retries, fallbacks, exception handling, and asynchronous side effects.
3. Mark each transition as confirmed, inferred, contradicted, or unknown, and rank alternative paths that still fit the evidence.
4. Identify the earliest faulty decision or state change, distinguish trigger from underlying defect, and propose targeted evidence collection or reproduction steps.
5. Deliver a code-path narrative, evidence table, leading root-cause hypothesis, immediate containment, minimal repair, regression test, and observability gaps. Avoid changing production data merely to test a hypothesis.

## Best for

Incident responders and software teams tracing production-only failures across multiple services and asynchronous boundaries.

## Compatible tools

- Claude
- ChatGPT

## How to use

- Use a shared time zone for all evidence.
- Include correlation IDs and deployment versions.
- Separate verified events from team assumptions.
- Preserve evidence before restarting or redeploying systems.

## Customization tips

- Include feature-flag and configuration history.
- Map asynchronous side effects and retry boundaries.
- State which production actions are prohibited.
- Add missing trace spans to the remediation plan.

## Example input

Incident: 146 customers received duplicate renewal emails between 09:03 and 09:18 UTC. Context: scheduler publishes renewal jobs, notification service sends email, and delivery IDs are stored in PostgreSQL. Evidence: queue shows redelivery after 30-second visibility timeout; email provider p95 rose to 38 seconds; traces end before provider response. Changes: notification timeout increased from 20 to 45 seconds, but queue visibility stayed at 30 seconds. Constraints: sending is paused; database records must not be manually edited.

## Example output

The confirmed timeline shows jobs became visible again at 30 seconds while the first worker still waited up to 45 seconds for the provider. A second worker then processed the same job before the delivery record was committed. The provider slowdown triggered the incident, but the underlying defect is mismatched timeout and idempotency boundaries. Containment keeps renewal sending paused; the repair adds a provider idempotency key and makes queue visibility exceed the bounded processing timeout. A regression test simulates a 38-second provider response and redelivery.