40 lines
2.8 KiB
Markdown
40 lines
2.8 KiB
Markdown
## 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
|