## 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