after we build · part three · worked example
Worked example — the wallet balance bug
A user opens their dashboard and sees $0.00 in their wallet. Their actual balance is −$125.50. Technically, one line of code:
balance.amount > 0 ? balance.amount : 0A developer trying to prevent null from displaying, who instead clamped every negative balance to zero. The fix is trivial. The lesson is not.
The six-dimension classification
Severity · severity/high — financial data displayed incorrectly. Not a system outage, but wrong numbers in a financial product.
Impact · impact/high — users make decisions based on incorrect balance. Severely degraded trust in every number on the screen.
Priority · P1 — high × high. Fix same day.
Type · type/bug — logic error in rendering.
Environment · env/staging — caught in UAT before production. Had it shipped: ~8% of active users affected.
Area + Root · area/frontend · root-cause/logic-error
The 5 Whys — where the chain failed
- Why did the component clamp negatives? The developer assumed balances are non-negative.
- Why? The story's acceptance criteria didn't include negative scenarios.
- Why? The story was written from a happy-path perspective — boundary values were not in the amigos checklist.
The systemic root cause is at Why #4: the amigos template had no prompt for boundary-value scenarios on financial fields. Fixing the code fixes this bug. Fixing the template prevents this class of bug.
The chain-aware label
Operational root cause: logic-error. Chain-aware root cause: scenario-gap — the amigos session didn't write a scenario for negative balances. The structural fix: a new prompt in the amigos template — "For any financial display: what happens at zero, negative, and very large values?" One prompt, added once, prevents every future bug in this class.
Trust is the product. A user who sees a wrong balance questions every number on every screen, even the ones that are correct. Financial display bugs have emotional blast radius, not just functional.