40 lines
1.6 KiB
Markdown
40 lines
1.6 KiB
Markdown
# Validate SM Flow Standard Change
|
|
|
|
## Why
|
|
|
|
The previous validation covered a micro change. A standard change has stricter expectations: an independent `design.md`, complete OpenSpec artifacts, and a separate `evidence.md` in devflow.
|
|
|
|
This validation checks whether the current `sm-flow` skill can still describe and validate a normal standard change after the recent simplification work.
|
|
|
|
## What Changes
|
|
|
|
- Create a standard-scale validation fixture for `sm-flow`.
|
|
- Verify standard OpenSpec artifacts exist and are aligned: `proposal.md`, `design.md`, `specs/`, and `tasks.md`.
|
|
- Verify standard devflow archive artifacts exist: `brief.md`, `evidence.md`, `decisions.md`, and `acceptance.md`.
|
|
- Verify standard still uses the same four visible checkpoints and nine internal phases without exposing phase names as user commands.
|
|
|
|
## Scope
|
|
|
|
In scope:
|
|
|
|
- Standard-scale validation records.
|
|
- Static checks over `.agents/skills/sm-flow`.
|
|
- Narrow fixes to the skill if standard validation reveals inconsistency.
|
|
|
|
Out of scope:
|
|
|
|
- Business code changes.
|
|
- Reworking archived historical changes.
|
|
- Changing the current trigger policy.
|
|
|
|
## Non-Goals
|
|
|
|
- This change does not test a complex migration, rollback, or cross-team interface change.
|
|
- This change does not require independent browser/manual validation.
|
|
- This change does not replace the micro validation already archived.
|
|
|
|
## Risks
|
|
|
|
- A standard validation fixture can become noise if left unarchived; status must be explicit.
|
|
- If standard rules are only validated by file presence, semantic drift may still require future forward-testing.
|