# Validate SM Flow Explicit Trigger

## Why

Recent edits simplified `sm-flow` so it should only run when the user explicitly invokes it. The same cleanup also centralized scale rules in `references/scales.md`, removed time-based metrics, and split fallback/glossary concepts out of the top-level skill.

This change validates those protocol decisions through a real micro `sm-flow` run instead of another informal review.

## What Changes

- Verify `sm-flow` only triggers on `/sm-flow`, `/sm-flow explore`, `/sm-flow apply`, `/sm-flow archive`, or an explicit natural-language request to use sm-flow.
- Verify task type alone does not trigger `sm-flow`, even when the task mentions OpenSpec, devflow, cross-module work, or clarification.
- Verify `micro / standard / complex` definitions live only in `references/scales.md`.
- Verify the skill has no time/minute-based metrics.
- Verify fallback usage is recorded when external OpenSpec capabilities are unavailable.

## Design Notes

- Scale: `micro`.
- Interface impact: L1 internal documentation/protocol validation only.
- No business code changes.
- Independent `design.md` is intentionally omitted; this section is the micro design artifact.
- OpenSpec CLI and external OpenSpec child skills are not directly callable in the current tool surface, so this run uses `references/fallbacks.md` and records that capability source in devflow.

## Scope

In scope:

- `.agents/skills/sm-flow/SKILL.md`
- `.agents/skills/sm-flow/references/*.md`
- Validation OpenSpec and devflow records for this change

Out of scope:

- Business code
- Rewriting historical OpenSpec archives
- Changing the four visible checkpoints or nine internal phases
- Adding automatic trigger heuristics

## Risks

- A future edit may duplicate scale rules outside `references/scales.md`.
- The frontmatter description may drift from the top-level trigger rule.
- Validation can prove current text consistency, but cannot force future agents to obey it without continued review.