## ADDED Requirements

### Requirement: OpenSpec drafts are not executable
SM Flow SHALL distinguish Draft OpenSpec from Committed OpenSpec.

#### Scenario: Phase 1 proposal created
- **WHEN** Phase 1 creates or updates proposal, design, specs, and tasks
- **THEN** the flow treats those artifacts as Draft OpenSpec until Phase 2, Phase 2.5, and Phase 2.9 checks are complete

#### Scenario: Draft has unresolved questions
- **WHEN** Draft OpenSpec contains unresolved user-interview questions, unreported evidence-driven conclusions, architecture conflicts, or unrecorded interface impact
- **THEN** the flow SHALL NOT enter Phase 3

### Requirement: Phase 2.9 commits executable OpenSpec
SM Flow SHALL include a Phase 2.9 Commit OpenSpec gate before Phase 3.

#### Scenario: Commit gate passes
- **WHEN** proposal explains scope and non-goals, design captures implementation constraints, specs describe observable behavior, tasks are executable vertical slices, interface impact is recorded, and devflow conflicts are resolved
- **THEN** the flow marks the OpenSpec change as Committed OpenSpec and may ask the user to proceed to Phase 3

#### Scenario: Commit gate fails
- **WHEN** any required executable OpenSpec condition is missing
- **THEN** the flow returns to Phase 1, Phase 2, or Phase 2.5 to repair the missing artifact before implementation

### Requirement: Grill questions require explicit human confirmation
SM Flow SHALL treat Phase 2 grill as a human-in-the-loop process that requires explicit user confirmation for user-interview questions.

#### Scenario: User-interview grill question is asked
- **WHEN** Phase 2 raises a user-interview question about terminology, scope, acceptance, risk, priority, or product preference
- **THEN** the flow asks exactly one question, waits for the user's answer, records the answer, and only then continues to the next user-interview question

#### Scenario: Grill confirmation is missing
- **WHEN** a user-interview question has no explicit user answer
- **THEN** the flow SHALL NOT mark the question resolved, SHALL NOT commit OpenSpec, and SHALL NOT enter Phase 3

### Requirement: Grill confirmation does not authorize apply
SM Flow SHALL distinguish confirmation of an individual grill decision from authorization to enter Phase 3.

#### Scenario: User confirms a grill decision
- **WHEN** the user answers a Phase 2 user-interview question with confirmation such as "可以", "确认", or equivalent
- **THEN** the flow records that decision and updates OpenSpec/devflow, but SHALL NOT treat the answer as authorization to modify execution target files

#### Scenario: OpenSpec has been updated after grill
- **WHEN** Phase 2 or Phase 2.5 findings have been written back to proposal, design, specs, or tasks
- **THEN** the flow stops at Phase 2.9, reports the Committed OpenSpec check result, and waits for explicit user authorization to enter Phase 3

#### Scenario: Apply authorization is missing
- **WHEN** the user has not explicitly said to enter apply, start implementation, execute the changes, continue Phase 3, or equivalent
- **THEN** the flow may update OpenSpec and devflow decision records, but SHALL NOT modify execution target files