git-learn/openspec/archive/2026-05-21-sm-flow-v3-1-upgrade/specs/sm-flow-apply-conflict-handling/spec.md

ADDED Requirements

Requirement: Phase 3 classifies implementation-time conflicts

SM Flow SHALL classify implementation-time conflicts before changing code or OpenSpec.

Scenario: User challenges implementation during apply

• WHEN the user questions or changes implementation behavior during Phase 3 and the request conflicts with Committed OpenSpec
• THEN the flow classifies the issue as implementation deviation, spec omission, design conflict, or user scope change before continuing

Scenario: Code suggests a different approach

• WHEN code inspection, tests, or runtime behavior suggests a different approach than Committed OpenSpec
• THEN the flow reports the evidence and classification instead of silently accepting the code-side suggestion

Scenario: Conflict is implementation deviation

• WHEN Committed OpenSpec remains correct and implementation diverges from proposal, design, specs, or tasks
• THEN the flow classifies the issue as implementation deviation and fixes the code without changing executable OpenSpec except task status or acceptance notes

Scenario: Conflict is spec omission

• WHEN Committed OpenSpec lacks a real boundary, behavior, validation rule, interface impact, or acceptance case discovered during implementation
• THEN the flow classifies the issue as spec omission and returns to OpenSpec repair before continuing apply

Scenario: Conflict is design conflict

• WHEN Committed OpenSpec conflicts with architecture, ADR, historical acceptance, data ownership, lifecycle, or module boundaries
• THEN the flow classifies the issue as design conflict, pauses implementation, reports the conflict, and asks the user to confirm the design direction

Scenario: Conflict is user scope change

• WHEN the user changes the goal, scope, priority, acceptance expectation, or risk tolerance during implementation
• THEN the flow classifies the issue as user scope change and updates proposal, specs, and tasks before continuing

Requirement: Spec-affecting conflicts return to OpenSpec repair

SM Flow SHALL repair OpenSpec before continuing when implementation-time conflicts affect the executable specification.

Scenario: Conflict is a spec omission or design conflict

• WHEN a Phase 3 conflict changes scope, externally observable behavior, interface compatibility, architecture decisions, or task slicing
• THEN the flow pauses apply, obtains required user confirmation, updates proposal/design/specs/tasks, reruns the commit gate, and only then resumes Phase 3

Scenario: Conflict is implementation deviation

• WHEN the committed specification is still correct and the code diverges from it
• THEN the flow fixes the implementation without changing OpenSpec except for task status or acceptance notes