47 lines
3.4 KiB
Markdown
47 lines
3.4 KiB
Markdown
## 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
|