rca

name	rca
description	Structured Root Cause Analysis for incidents. Agent runs on dev server with NO production access — proactively asks user for logs, metrics, and observations instead of trying to search/grep itself. Use when analyzing bugs, outages, or unexpected behavior.

Root Cause Analysis (RCA)

CRITICAL: You run on a development server without any access to production — no SSH, no log files, no metrics dashboards, no production DB. You CANNOT grep logs, curl production endpoints, or query production databases. DO NOT attempt to read log files or connect to production services. Instead, ask the user proaktif for every piece of data you need.

When to Use

• User reports a bug, incident, or unexpected behavior
• User asks "why did this happen?" / "what caused this?"
• Post-mortem or blameless RCA

Process

Phase 1: Problem Statement (tulis dulu)

1. Ask the user to describe the problem in their own words
2. Write down a concise problem statement: "What is broken? Since when? What is the impact?"
3. Confirm the statement back to the user before moving on

Phase 2: Timeline

Ask the user:

• When was the issue FIRST observed? (timestamp/timezone)
• When was it LAST known to work normally?
• Is it ongoing right now, or did it stop?
• Any deploys, config changes, or infrastructure changes in that window?
• Any traffic spikes, cron jobs, or external events in that window?

Build a rough timeline from the answers.

Phase 3: Symptoms & Scope

Ask the user for:

• Error messages — exact error text, stack traces (ask user to copy-paste)
• Metrics — error rate, latency, throughput, CPU/memory (ask user to screenshot or copy numbers from their dashboard)
• Scope — which users/services/regions are affected? All or subset?
• Reproduction — can the user still reproduce it? Steps?

Phase 4: Code Investigation (ini kamu bisa)

Now you CAN use your available tools (read, grep, git log) on the local codebase:

1. Search for the error message text in the codebase (grep)
2. Trace the code path from entry point to the failing line
3. Check git log for recent changes to those files (git log --oneline -10 -- <file>)
4. Look for related tests, edge cases, missing null checks

Phase 5: Root Cause Hypothesis

1. Based on symptoms + code analysis, form a hypothesis: "The root cause is likely X because Y"
2. Present it to the user
3. Ask: "Does this match what you see? Is there data that contradicts this?"
4. If confirmed: move to Phase 6. If not: loop back to Phase 3 with new questions.

Phase 6: Timeline 5 Whys (jangan terlalu kaku, secukupnya)

Start with the direct cause, then ask "why?" up to 5 times:

1. Why did the error happen? (direct technical cause)
2. Why was that condition present? (code/configuration)
3. Why wasn't it caught? (testing/monitoring gap)
4. Why was the process insufficient? (process/ownership)
5. Why was the process designed that way? (systemic)

Stop when you reach a systemic/process-level cause. Don't force 5 if the root cause is clear at 3.

Phase 7: Report

Write an RCA report to RCA_REPORT.md with these sections:

# RCA: [Problem Statement]

**Date:** YYYY-MM-DD
**Incident Window:** [start] – [end]
**Severity:** [SEV1/SEV2/SEV3]

## Summary
[1-2 sentences: what happened, impact, root cause]

## Timeline
| Time | Event |
|------|-------|
| HH:MM | ... |

## Root Cause
[Detailed explanation of what caused the issue, with code references]

## Why Wasn't It Caught?
[Testing gaps, monitoring gaps, review gaps]

## Resolution
[What fixed it, if already resolved]

## Action Items
- [ ] [actionable item, assignee, priority]

## 5 Whys
1. ...
2. ...

Phase 8: Follow-up

Ask the user:

• Should I create tickets for the action items?
• Should I write a regression test for the root cause? (offer to do it)
• Should I add monitoring/alerting suggestions to the report?

Anti-patterns (jangan dilakukan)

• ❌ Jangan coba grep log files di /var/log/ atau journalctl — gak ada akses
• ❌ Jangan coba curl production URL atau IP production
• ❌ Jangan coba query production database
• ❌ Jangan berasumsi tanpa konfirmasi ke user
• ✅ Tanya user untuk screenshots, copy-paste error, dan metric dashboards
• ✅ Gunakan read dan grep hanya di codebase lokal