sdlc-fix
sdlc-fix
Repair a bounded existing flow without opening intent/<slug>/. The fix request normally authorizes a commit containing only this concern, subject to explicit user restrictions and the host's permission policy. It does not authorize a push or external action.
Choose the workflow by scope and consequence
This path fits a concrete bug in an existing readable flow or a behavior-preserving refactor. Judge both the size of the change and the impact if it is wrong; a small patch can be high consequence and a large mechanical change can be low consequence.
Choose assurance by consequence, not line count. A bounded label, capitalization or layout repair with no change to facts, selection, permissions, persisted data or shared behavior uses focused regression and the affected render/preview check; no routine independent reviewer. A localized behavioral repair adds checks for its affected contracts and relevant main/error paths. Independent review is required for consequential changes, a concrete unresolved high-impact risk or a binding user/repository rule; state that reason in the existing fix record. Do not turn every small fix into a feature intent or full verification workflow. Reassess if investigation exposes broader consequences; new capabilities still use sdlc-plan.
Use sdlc-plan if investigation reveals a new capability, unresolved product choice, architectural decision, or work spanning multiple subsystems. Do not disguise expanded scope as a fix. Preserve the actual requested outcome: a manual substitute does not satisfy requested automation or integration. Extra screens, mandatory inputs, acknowledgements or enablement gates need user authority or an evidenced binding constraint; a guard invented during the fix does not supply it. Keep necessary internal validation, security and error handling, and choose the smallest complete repair for the stated users and deployment. Present a genuinely necessary new product decision before implementing it; broad autonomy does not authorize it.
Apply YAGNI after understanding the affected flow: reuse suitable existing code and patterns, then prefer standard-library, native-platform or installed-dependency capabilities when they meet the requirements. Add custom code or a dependency only for a demonstrated gap. Avoid speculative configuration, extension points and scaffolding for future features; retain abstractions justified by current contracts or clarity. This is a quick design choice, not a new research or review stage. Minimize implementation complexity, not requested capability: preserve explicit outcomes, compatibility, validation, error handling, security and accessibility. Readable, complete code wins over fewer lines; simplification cannot silently substitute a lesser outcome.
Escalate assurance for changes affecting authorization, sensitive data, irreversible operations or migrations, financial calculations, safety-critical behavior, or another consequential invariant. Before editing, establish an independent reviewer route at the stable completed-fix boundary. Use the host's available delegation mechanism without inherited implementation history, or a separate fresh session with a bounded handoff. No named agent profile or particular model is required. Confirm actual isolation; review with inherited implementation history cannot pass as independent. If the host cannot provide that capability, do not make an autonomous consequential fix; state the blocker. Use a disposable checkout and a limited test environment for the independent check when the change could damage data or depend on privileged access. No review route makes the work blocked, not verified.
Keep an independently complete fix bounded. Clarifications of the current outcome and inseparable root-cause repairs belong with it; unrelated incoming fixes wait unless explicitly reprioritized or batched. Once checks pass, commit and perform an already-authorized release before starting unrelated implementation when the fix is independently deployable. Do not hold a finished fix merely to fill a larger release, or split inseparable changes by file. Preserve already-started work; change an existing approved bundle only at a safe committed checkpoint with required reconciliation.