Fec Debug Framework

---
name: fec-debug-framework
description: Use when diagnosing frontend build failures, runtime errors, UI anomalies, API/data problems, white screens, request failures, or unexplained production exceptions; Chinese triggers include debugging, debug, troubleshooting, positioning, error reporting, exceptions, white screens, request failures.
---

# Front-end diagnostic framework

## Purpose

Use an evidence-driven triage, collection, hypothesis, verification, and remediation process to locate front-end faults and avoid relying on intuition to expand the scope of changes.

## Procedure

All front-end problem diagnosis follows a unified process:

### Step 1: Classify

Identify problem type and scope of impact:

| Type | Judgment basis | Diagnosis entrance |
| ------- | ---------------------------- | -------------- |
| build | Command exit is non-zero, stderr has error | → Build module |
| runtime | Console exception, white screen, function unavailable | → Runtime module |
| ui | Visual deviation, interaction not as expected | → UI module |
| api | Request status code exception, data inconsistency | → API module |

Cross-type problems (such as API failure leading to UI exceptions) start with the most superficial symptoms and drill down layer by layer.

### Step 2: Collect

Collect evidence by type (specific strategies for each module, see below).

### Step 3: Hypothesize

Propose possible root causes based on evidence, ranked by likelihood:

- Every hypothesis must be testable (have clear verification methods)
- Keep at most 3 hypotheses to avoid divergence
- Format: "Because X leads to Y, which can be verified by Z"

### Step 4: Verify

Test the hypotheses one by one:

- Start with the most likely hypothesis
- Only change one variable at a time
- Verification result record: confirmed / falsified / pending
- If all assumptions are falsified, return to Step 2 and collect again.

### Step 5: Fix & Validate

- Apply minimal fixes
- Run affected verification commands
- Confirmed no regression
- Output repair report

---

## Diagnostic module

### Build module

**Collect**: Run minimal failing commands, capture full stderr/stdout
**Assumptions**: Grouped by error type (type error, import failure, configuration resolution, missing dependency), match known patterns
**Verification**: Fix a type of root cause → rerun the command → confirm that errors are reduced
**Special handling**:

- Collect evidence for dependency version, peer dependency, ESM/CJS, and lockfile related failures first as build compatibility issues
- Log package manager, Node version, lockfile diff, related package version and full error log
- No longer upgrade dependencies, manually edit lockfiles when evidence is lacking, or mix dependency migrations with normal debug fixes in the same batch of changes
- If the task goal itself is version upgrade, CVE repair or lockfile risk review, it should be transferred to the dependency upgrade workflow
- CI exclusive failure check Node version, package manager, environment variable differences

### Runtime module

**Collect**:

- Recurrence path (sequence of user operations)
- Console errors and stack
- Component rendering tree status (check whether key components are mounted correctly)
- Relevant store/state snapshot

**Assumptions**:

- Stack reverse tracing: trace back from the exception location to the trigger source
- State flow analysis: Check whether state changes are as expected
- Life cycle analysis: whether uninitialized data is accessed at the wrong time

**Verification**:

- Add temporary log confirmation status value
- Add assertions on suspicious paths
- Recurrence path verification fix

### UI module

**Collect**:

- Current screenshot vs desired effect
- DOM structure check (whether the element exists and whether the level is correct)
- Computed style checks (actual applied CSS values)
- Responsive breakpoint testing

**Assumptions**:

- CSS specificity conflict (selector weight is not enough to be overridden)
- Component state mismatch (props/state not passed correctly)
- Layout model problem (flex/grid configuration error)
- Missing responsive breakpoints

**Verification**:

- Browser DevTools real-time adjustment verification
- Isolated component testing (excluding external style interference)
- Multiple breakpoints to verify one by one

### API module

**Collect**:

- Request URL, method, headers, body
- Respond to status, headers, body
- Network waterfall timing
- Cache data in related store/state

**Assumptions**:

- Request link hop-by-hop inspection (URL → Middleware → Interceptor → Server)
- Data conversion checks (response parsing, type mapping)
- Cache policy check (expiration, invalidation, race condition)
- Concurrent request race condition (race condition)

**Verification**:

- curl independent reproduction (excluding front-end interference)
- Mock layer by layer to locate the problem level
- End-to-end request validation fixes

---

## Detailed reference

When writing a diagnostic report, load [references/report-template.md](references/report-template.md).

## Constraints

- Don't guess at root cause when evidence is lacking
- Not "fixed" by turning off rules, removing tests, or reducing type safety
- Change only one variable at a time to test your hypothesis
- Do not expand the scope of changes before verification
- The same hypothesis fails verification 3 times in a row, stops and reports blocking

## Expected Output

- The diagnostic report is saved as `reports/debug-YYYY-MM-DD-HHmmss.md`
- The report includes issue type, key evidence, hypothesis verification records, root cause, fix content, verification results and remaining risk
- Build/runtime/ui/api problems can explain the reproduction path, verification command or next blocking point