scope-and-change-controllisted

# Scope and Change Control Two drifts destroy deliveries. Scope drift: the project grows by small improvements nobody asked for. Architecture drift: the built system stops matching the approved design, one reasonable decision at a time. Both feel like good engineering while they happen. ## 1. The classification Every discovery during implementation is one of four things. Classify before acting. | Class | Definition | Action | |---|---|---| | in scope | serves an approved requirement | do it, it is the work | | follow up | an improvement nobody asked for | register it, do not do it | | urgent | a security, data integrity or correctness risk | fix now, report it | | change | contradicts the approved architecture or scope | change protocol | The classification is written before the fix, not after. Deciding retrospectively that a two hour improvement was in scope is how the boundary disappears. ## 2. Follow ups The default answer to a discovered improvement is: register it, do not do it. ``` | # | What | Where | Why not now | Effort | |---|---|---|---|---| | FU7 | orders list has no index on customer_id | db/schema | not in scope, no measured impact at current volume | small | | FU8 | the date formatter is duplicated in 4 files | lib/ | cosmetic, no defect | small | | FU9 | the settings page has no empty state | components/ | outside the approved scope for this delivery | medium | ``` Registered improvements are delivered as a list at handover. That is more valuable to