upgrade sm-flow v3.1 workflow
This commit is contained in:
zhuyongxin
+39
@@ -0,0 +1,39 @@
|
||||
## 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
|
||||
@@ -0,0 +1,49 @@
|
||||
## 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
|
||||
+23
@@ -0,0 +1,23 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Devflow context lookup uses an index-first strategy
|
||||
SM Flow SHALL use a stable index-first devflow lookup order to find relevant context.
|
||||
|
||||
#### Scenario: Phase 0.5 starts
|
||||
- **WHEN** Phase 0.5 collects devflow context
|
||||
- **THEN** the flow checks `devflow/index.md` first, then `devflow/glossary/CONTEXT.md`, then related project brief/acceptance/ADR files, then `devflow/compound/`
|
||||
|
||||
#### Scenario: Index is missing during lookup
|
||||
- **WHEN** `devflow/index.md` does not exist
|
||||
- **THEN** the flow initializes a lightweight index from known project directories, falls back to targeted search for the current lookup, and records that the index was bootstrapped
|
||||
|
||||
### Requirement: Phase 4 maintains devflow index
|
||||
SM Flow SHALL update devflow index metadata during Phase 4 when a project archive is created or updated.
|
||||
|
||||
#### Scenario: Project is backfilled
|
||||
- **WHEN** Phase 4 creates or updates `devflow/projects/YYYY-MM-DD-{slug}/`
|
||||
- **THEN** the flow updates `devflow/index.md` with date, slug, domain, keywords, related OpenSpec change, and status
|
||||
|
||||
#### Scenario: Phase 4 completes without index update
|
||||
- **WHEN** Phase 4 has created or updated project backfill files but has not updated `devflow/index.md`
|
||||
- **THEN** the flow is incomplete and must update the index before reporting completion
|
||||
+46
@@ -0,0 +1,46 @@
|
||||
## ADDED Requirements
|
||||
|
||||
### Requirement: Interface changes have impact records
|
||||
SM Flow SHALL require every interface-related change to record interface impact before Phase 3.
|
||||
|
||||
#### Scenario: Internal interface field changes
|
||||
- **WHEN** a change adds, removes, renames, or changes the semantics of a field, DTO, service method, event, API, callback, database contract, or command contract
|
||||
- **THEN** the flow records the affected interface, affected consumers, compatibility expectation, and validation method in OpenSpec design/specs/tasks or devflow evidence/decisions
|
||||
|
||||
#### Scenario: Interface uncertainty
|
||||
- **WHEN** the agent cannot determine whether a change affects an interface contract
|
||||
- **THEN** the flow treats it as an interface-impact question and asks for confirmation before Phase 3
|
||||
|
||||
#### Scenario: Internal decision logic changes observable behavior
|
||||
- **WHEN** a change modifies internal decision logic inside an interface and the result can change returned data, status, error code, permission result, validation result, ordering, filtering, idempotency, timing, or side effects
|
||||
- **THEN** the flow treats the change as interface impact even if the interface shape and field names are unchanged
|
||||
|
||||
### Requirement: Interface documentation is level-gated
|
||||
SM Flow SHALL create an independent interface document only when the interface impact level requires it.
|
||||
|
||||
#### Scenario: Low-risk internal interface change
|
||||
- **WHEN** an interface change is limited to internal implementation or an internal module boundary and has no external consumers
|
||||
- **THEN** the flow records the interface impact inline without requiring a standalone interface document
|
||||
|
||||
#### Scenario: External or breaking interface change
|
||||
- **WHEN** an interface change affects external APIs, SDKs, callbacks, events, database contracts, cross-team consumers, or breaks backward compatibility
|
||||
- **THEN** the flow requires a standalone interface document or equivalent explicit section covering consumers, compatibility, migration, rollback, and validation
|
||||
|
||||
### Requirement: Interface impact levels use risk-based classification
|
||||
SM Flow SHALL classify interface impact by consumer boundary, contract semantics, and compatibility risk.
|
||||
|
||||
#### Scenario: L1 internal implementation
|
||||
- **WHEN** a change does not alter any consumer-visible interface shape, field, status, error, data range, ordering, permission result, state transition, side effect, or documented behavior
|
||||
- **THEN** the flow classifies it as L1 and records validation in tasks or acceptance without requiring interface impact documentation
|
||||
|
||||
#### Scenario: L2 internal interface
|
||||
- **WHEN** a change affects internal DTOs, service methods, internal events, internal RPC, or internal decision logic and all consumers are inside the same implementation scope
|
||||
- **THEN** the flow classifies it as L2 and records interface impact inline
|
||||
|
||||
#### Scenario: L3 collaboration interface
|
||||
- **WHEN** a change affects other modules, services, frontend callers, external systems, cross-team consumers, database contracts, events, callbacks, or SDK users
|
||||
- **THEN** the flow classifies it as L3 and requires a standalone interface document or equivalent explicit section
|
||||
|
||||
#### Scenario: L4 breaking interface
|
||||
- **WHEN** old consumers can fail, receive less data, receive more data, observe different statuses or errors, require migration, require rollback, or lose backward compatibility
|
||||
- **THEN** the flow classifies it as L4 and requires standalone interface documentation plus migration and rollback notes
|
||||
Reference in New Issue
Block a user