Scoped correction of an established BUG
A scoped BUG correction restores behavior that violates an established requirement, stays within the authorized change boundary and proves the fix through revalidation. It is not permission to redesign adjacent functionality or quietly change what the requirement means.
This is a correction practice within IMPLEMENTATION in AI Architect Mastery's AI Driven Development Methodology. The BUG Work Type presupposes an established expectation.
How a correction stays reviewable
- State the expected behavior and capture the failure evidence.
- Identify the cause and confirm that its correction fits the approved scope.
- Change the relevant implementation and regression checks.
- Recheck the original failure, the required successful behavior and affected invariants.
- Present the diff, results and limitations for a human decision.
Why scope matters even for a small defect
A seemingly convenient refactor can change contracts that the current tests never exercised. Keeping the correction tied to the requirement makes it possible to distinguish the fix from new design decisions. Bounded does not mean superficial: fix the cause, not only the visible symptom.
Constructed correction: a missing authorization check
The established rule permits only owners to export. The handler omits the existing authorization helper. The correction applies that helper and verifies owner success, non-owner denial and unchanged output format. It does not introduce a new sharing policy.
When to stop correcting and return
If the helper cannot express the requirement, or the expected policy is itself uncertain, report that finding rather than expanding the fix. A human may return to PLAN or PRD. The original BUG can remain recorded while a related PROB captures the uncertainty.