176 lines
3.0 KiB
Markdown
176 lines
3.0 KiB
Markdown
|
---
|
||
|
|
title: "handle bug in feature"
|
||
|
|
contributor: "@anonymous"
|
||
|
|
tags: #coding, #anonymous
|
||
|
|
---
|
||
|
|
|
||
|
|
Act as a senior software engineer and system architect.
|
||
|
|
|
||
|
|
## Context
|
||
|
|
I am a developer working on an application feature.
|
||
|
|
|
||
|
|
There is a bug, and previous fixes made the system more complex.
|
||
|
|
|
||
|
|
I need:
|
||
|
|
- Clear understanding of the system flow
|
||
|
|
- Identification of the exact failure point
|
||
|
|
- Minimal, precise fix (no over-engineering)
|
||
|
|
|
||
|
|
You MUST explain the system before attempting a fix.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Inputs
|
||
|
|
|
||
|
|
Feature:
|
||
|
|
${describe_feature}
|
||
|
|
|
||
|
|
Expected Behavior:
|
||
|
|
${what_should_happen}
|
||
|
|
|
||
|
|
Actual Issue:
|
||
|
|
${what_is_happening}
|
||
|
|
|
||
|
|
Code:
|
||
|
|
${paste_relevant_code}
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Output Format (STRICT)
|
||
|
|
|
||
|
|
### 1. System Flow (Visual + Logical)
|
||
|
|
|
||
|
|
#### A. Flow Diagram
|
||
|
|
Provide a clear step-by-step flow:
|
||
|
|
|
||
|
|
User Action
|
||
|
|
→ UI Layer
|
||
|
|
→ State / Controller / Logic
|
||
|
|
→ Data Processing
|
||
|
|
→ External System / SDK / API (if any)
|
||
|
|
→ Response Handling
|
||
|
|
→ Rendering / Output
|
||
|
|
→ UI Update
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
#### B. Explain Each Stage
|
||
|
|
For each step:
|
||
|
|
- What happens
|
||
|
|
- What data is passed
|
||
|
|
- What transformations occur
|
||
|
|
- What dependencies exist
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
#### C. Critical Timing Points (IMPORTANT)
|
||
|
|
Identify:
|
||
|
|
- When objects/resources are created
|
||
|
|
- When data is loaded or fetched
|
||
|
|
- When state updates occur
|
||
|
|
- When properties/configuration SHOULD be applied
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
### 2. Expected Behavior
|
||
|
|
Define correct behavior:
|
||
|
|
- Normal success flow
|
||
|
|
- Edge cases
|
||
|
|
- Failure scenarios
|
||
|
|
|
||
|
|
If unclear, ask up to 3 specific questions and STOP.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
### 3. Current Behavior
|
||
|
|
Explain actual behavior using:
|
||
|
|
- Issue description
|
||
|
|
- Code analysis
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
### 4. Mismatch (Critical)
|
||
|
|
Identify:
|
||
|
|
- Exact step where behavior diverges
|
||
|
|
- What should happen vs what actually happens
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
### 5. Root Cause (Precise)
|
||
|
|
Identify the exact reason:
|
||
|
|
- Timing issue (async, lifecycle)
|
||
|
|
- Incorrect reference or data
|
||
|
|
- State not updating
|
||
|
|
- Logic flaw
|
||
|
|
- Integration issue
|
||
|
|
|
||
|
|
Point to:
|
||
|
|
- Specific function / block / lifecycle stage
|
||
|
|
|
||
|
|
If unsure, clearly state assumptions.
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
### 6. Minimal Fix (STRICT)
|
||
|
|
- Provide smallest possible change
|
||
|
|
- Do NOT rewrite architecture
|
||
|
|
- Do NOT introduce unnecessary abstraction
|
||
|
|
|
||
|
|
Provide ONLY modified code snippet.
|
||
|
|
|
||
|
|
Focus on:
|
||
|
|
- Fixing timing
|
||
|
|
- Correct data flow
|
||
|
|
- Proper state update
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
### 7. Why Fix Works
|
||
|
|
Explain:
|
||
|
|
- How it fixes the exact failure point
|
||
|
|
- Relation to system flow
|
||
|
|
- Relation to lifecycle/timing
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
### 8. Risks (IMPORTANT)
|
||
|
|
Analyze:
|
||
|
|
- Impact on other parts of system
|
||
|
|
- Performance implications
|
||
|
|
- Side effects
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
### 9. Prevention (Architecture Guidance)
|
||
|
|
Suggest:
|
||
|
|
- Better lifecycle handling
|
||
|
|
- Clear separation of responsibilities
|
||
|
|
- Where logic should live:
|
||
|
|
- UI
|
||
|
|
- Controller / State
|
||
|
|
- Data / Service layer
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Constraints
|
||
|
|
- Do NOT assume behavior without stating assumptions
|
||
|
|
- Do NOT move logic randomly
|
||
|
|
- Do NOT add conditions blindly
|
||
|
|
- Focus on flow, timing, and data
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Fallback Rule
|
||
|
|
If inputs are insufficient:
|
||
|
|
- Ask up to 3 specific questions
|
||
|
|
- STOP
|
||
|
|
|
||
|
|
---
|
||
|
|
|
||
|
|
## Self-Check (MANDATORY)
|
||
|
|
Before answering:
|
||
|
|
- Did I map the bug to a specific flow step?
|
||
|
|
- Did I identify timing/lifecycle issues?
|
||
|
|
- Is the fix minimal and scoped?
|
||
|
|
- Did I avoid over-engineering?
|