19  Spell of Bug Diagnosis from Logs

20 Spell of Bug Diagnosis from Logs

Working seal: spell://bug-diagnosis-from-logs/2BC4379FD0

Use when: Use when logs are available but the failure mechanism is still uncertain.

20.1 Copyable Template

Raw template: prompts/spells/bug-diagnosis-from-logs.txt

ROLE:
Act as a production incident engineer diagnosing a backend failure.

OBJECTIVE:
Determine the most likely root causes of the supplied error logs and propose the shortest safe path to confirmation and mitigation.

CONTEXT:
The service is a stateless containerized API backed by PostgreSQL and Redis. Latency SLO is 250 ms p95.

A recent deploy occurred within the last hour.

CONSTRAINTS:
Do not assume facts not present in the logs. Separate confirmed observations from hypotheses.

Prefer mitigations that are reversible and low-risk. Mention monitoring to watch during mitigation.

PROCEDURE:
Extract the timeline, cluster repeated errors, identify likely failure domain, and rank hypotheses.

For each hypothesis, give one confirming check and one mitigating action. Call out whether the problem looks like config, code, dependency, infrastructure, or data.

OUTPUT CONTRACT:
Return:

1\. confirmed observations,

2\. ranked hypotheses,

3\. immediate mitigation options,

4\. confirmation steps,

5\. rollback criteria.

VERIFICATION:
Tie every claim to a concrete log line or absence of an expected line.

FAILURE BEHAVIOR:
If the logs are insufficient, say what additional evidence would most reduce uncertainty.

20.2 Related Runes

• 1180 observability - Enough internal evidence exists that you can infer what the system is doing from the outside. Not logs alone: legible state under pressure.
• 1202 telemetry - Measurements leaving the system in a form other systems can compare, store, and alert on.
• 1204 trace {Proof} - A preserved path through execution. Use it when the question is not only what failed, but where the causal thread first bent.
• 0598 timeout {Ctrl} - Waiting is not free and patience must have a boundary. A timeout is a contract with reality about how long uncertainty is allowed to persist.
• 0943 rollback {DB} - Permission to retreat toward a previously trusted state. A system without rollback mistakes hope for safety.

20.3 Related Pages

• Canonical Spell Skeleton
• Cast Levels
• Failure Modes
• Canon Map
• Proof by Difference Case
• Recorded Evaluations

20.4 Source Form

20.5 Spell of Bug Diagnosis from Logs

ROLE:

Act as a production incident engineer diagnosing a backend failure.

OBJECTIVE:

Determine the most likely root causes of the supplied error logs and propose the shortest safe path to confirmation and mitigation.

CONTEXT:

The service is a stateless containerized API backed by PostgreSQL and Redis. Latency SLO is 250 ms p95.

A recent deploy occurred within the last hour.

CONSTRAINTS:

Do not assume facts not present in the logs. Separate confirmed observations from hypotheses.

Prefer mitigations that are reversible and low-risk. Mention monitoring to watch during mitigation.

PROCEDURE:

Extract the timeline, cluster repeated errors, identify likely failure domain, and rank hypotheses.

For each hypothesis, give one confirming check and one mitigating action. Call out whether the problem looks like config, code, dependency, infrastructure, or data.

OUTPUT CONTRACT:

Return:

1. confirmed observations,

2. ranked hypotheses,

3. immediate mitigation options,

4. confirmation steps,

5. rollback criteria.

VERIFICATION:

Tie every claim to a concrete log line or absence of an expected line.

FAILURE BEHAVIOR:

If the logs are insufficient, say what additional evidence would most reduce uncertainty.