# Technical Debt

Debt discipline for deciding what to fix, defer, or accept.

## Rules

1. **Name the debt explicitly.** "This is hacky" is not debt tracking. Write what the shortcut is, why it was taken, and what the proper fix costs. Undocumented debt is debt nobody will ever pay.

2. **Interest rate matters.** Some debt slows every future change in that area. Some debt is ugly but isolated. Pay the debt that compounds, not the debt that's merely embarrassing.

3. **Don't pay debt during a feature sprint.** Refactoring the auth system while building checkout creates two half-done things. Debt paydown gets its own scope and its own PR.

4. **Don't defer forever.** "We'll fix it later" without a ticket and a rough cost estimate is "we accepted it permanently" with extra steps.

5. **New code doesn't add debt to pay old debt.** Fixing a hack with another hack doubles the problem. The fix must actually move toward the target architecture.

6. **Some debt is correct.** Shipping a validated prototype with known shortcuts beats polishing code for a product that might not survive contact with users. Debt is a tool — know when you're using it intentionally.

## What This Replaces

Unnamed shortcuts that compound silently, debt paydown that never happens, and refactors that expand scope until the original task is lost.