1.9 KiB
1.9 KiB
description, paths
| description | paths | |||
|---|---|---|---|---|
| Systematic debugging process for HealthLink-HIS |
|
Systematic Debugging Process
Iron Law: No root cause investigation, no fix proposal.
Four-stage process
Stage 1: Root cause investigation (must complete before fixing)
- Carefully read error message (stack trace, line numbers, error codes)
- Stabilize reproduction (can it be reliably triggered? steps? every time?)
- Check recent changes (
git diff, new dependencies, config changes) - Multi-component system: add diagnostic logs at each component boundary, locate which layer is broken
- Trace data flow: where does the bad value come from? who calls it? trace back to the source
Stage 2: Pattern analysis
- Find similar working code in the same codebase
- Compare differences item by item
- Understand dependency relationships
Stage 3: Hypothesis and test
- Form single hypothesis: "I believe X is the root cause because Y"
- Make minimal change to test
- Effective → Stage 4; Invalid → new hypothesis
Stage 4: Implement
- Create failing test case
- Fix root cause (not symptoms)
- Verify fix
Use /fix-compile skill
When mvn compile or npm run build:dev fails, use the /fix-compile skill for systematic diagnosis and repair.
Common error patterns
- Duplicate method: Check all Service implementations for the same method
- Missing import: Verify package structure matches
com.healthlink.his.web.{module} - Type mismatch: Check DTO field types (Iron Law: DTO field type defense)
- SCSS bracket: Count
{and}in<style lang="scss" scoped>blocks - Flyway conflict: Check migration version numbers in
healthlink-his-application/src/main/resources/db/migration/ - State chain break: Bug#574 lesson — check complete state flow (enum → Service → query → frontend mapping → statistics)