Deferred Improvements

deferred_improvement.md in the main repository tracks concrete improvements that were deliberately postponed during implementation. Each entry represents a known-better solution that was skipped for a specific reason (time, complexity, dependency on something not yet built).

How to use the tracker

Each entry in deferred_improvement.md has:

Field	Description
ID	Stable identifier (e.g., DI-001)
Status	open, in progress, or done
Source	Where the decision was made (commit, PR, design session)
Area	Which subsystem this affects
Deferred reason	Why the better solution wasn't implemented yet
Better solution	What should eventually be done
Acceptance criteria	How you know the improvement is complete
Implementation notes	Technical guidance for whoever picks it up
Search terms	Keywords to find related code

Top open items (as of last update)

1. Worker/v16 integration — full end-to-end scan completion with complete event schema documentation
2. Enforce max_active_scans_per_user — the quota is defined but not fully enforced at all entry points
3. Threat profile bug classes not enforced — bug_classes and severity_threshold from the wizard aren't passed through to the analyzer
4. Rich finding fields from v16 — confidence, suggested_fix, and evidence aren't fully surfaced in the UI
5. Frontend findings inbox wiring — several UI items for the cross-project inbox aren't connected to the API

Using the tracker when planning work

1. Search for the relevant subsystem or file path in deferred_improvement.md
2. Read the acceptance criteria — this tells you exactly what "done" means
3. Update the entry's status when you start work (in progress)
4. Remove or mark the entry done after completing it
5. Leave unrelated entries untouched

Relationship to known gaps

Known Gaps covers documentation and structural gaps. Deferred improvements cover implementation gaps — places where the code works but a better approach was explicitly postponed.