@jaimevalasek/aioson 1.8.0 → 1.9.1

package/template/.aioson/skills/process/aioson-spec-driven/references/analyst.md

@@ -1,30 +1,30 @@
-# Spec-Driven Reference — @analyst
-
-> Router file. Do not duplicate logic from the generic references — load those directly.
-
-## Which references to load for discovery and feature requirements
-
-### Always load when this skill is active
-
-- `classification-map.md` — use during discovery to score complexity and declare MICRO/SMALL/MEDIUM before any other decision
-- `artifact-map.md` — use to know exactly what artifacts @analyst owns vs what belongs to @architect or @dev
-- `approval-gates.md` — use Gate A criteria to know when requirements are ready to hand off
-
-### Load when input is vague or exploratory
-
-- `hardening-lane.md` — use to detect whether input is still in vibe mode and route accordingly before producing requirements
-
-### Do not load for @analyst
-
-- `maintenance-and-state.md` — this is for execution/continuation sessions, not discovery
-- `ui-language.md` — load only when producing a checkpoint or gate status presentation
-
-## Behavioral notes
-
-- Declare classification (MICRO/SMALL/MEDIUM) early — it controls depth of requirements, AC verbosity, and whether Gate A is blocking
-- Gate A must be explicitly evaluated before handing off to @architect or @dev
-- `requirements-{slug}.md` is @analyst's primary output — see `artifact-map.md` for ownership chain
-
-### Conformance contract (MEDIUM only)
-
-For MEDIUM features, generate `.aioson/context/conformance-{slug}.yaml` alongside `requirements-{slug}.md`. This YAML file structures each AC into machine-readable preconditions, actions, expected outcomes, and negative cases. @qa and @dev consume this for precise verification and test writing.
+# Spec-Driven Reference — @analyst
+
+> Router file. Do not duplicate logic from the generic references — load those directly.
+
+## Which references to load for discovery and feature requirements
+
+### Always load when this skill is active
+
+- `classification-map.md` — use during discovery to score complexity and declare MICRO/SMALL/MEDIUM before any other decision
+- `artifact-map.md` — use to know exactly what artifacts @analyst owns vs what belongs to @architect or @dev
+- `approval-gates.md` — use Gate A criteria to know when requirements are ready to hand off
+
+### Load when input is vague or exploratory
+
+- `hardening-lane.md` — use to detect whether input is still in vibe mode and route accordingly before producing requirements
+
+### Do not load for @analyst
+
+- `maintenance-and-state.md` — this is for execution/continuation sessions, not discovery
+- `ui-language.md` — load only when producing a checkpoint or gate status presentation
+
+## Behavioral notes
+
+- Declare classification (MICRO/SMALL/MEDIUM) early — it controls depth of requirements, AC verbosity, and whether Gate A is blocking
+- Gate A must be explicitly evaluated before handing off to @architect or @dev
+- `requirements-{slug}.md` is @analyst's primary output — see `artifact-map.md` for ownership chain
+
+### Conformance contract (MEDIUM only)
+
+For MEDIUM features, generate `.aioson/context/conformance-{slug}.yaml` alongside `requirements-{slug}.md`. This YAML file structures each AC into machine-readable preconditions, actions, expected outcomes, and negative cases. @qa and @dev consume this for precise verification and test writing.

package/template/.aioson/skills/process/aioson-spec-driven/references/approval-gates.md

@@ -1,109 +1,109 @@
-# Approval Gates — Spec-Driven Phase Transitions
-
-> Use when preparing a handoff or checking if a phase is ready to proceed.
-> Gates are blocking in MEDIUM. Informational in MICRO/SMALL.
-
-## Gate A — Requirements approval
-
-**Before leaving @product / @analyst → @architect or @dev**
-
-Required for the gate to pass:
-- [ ] Objectives are clear and unambiguous
-- [ ] Expected behaviors are described (not just features — what happens when X)
-- [ ] Constraints are explicit (what this version does NOT do)
-- [ ] Out of scope is listed
-- [ ] Open ambiguities are documented (not silently ignored)
-- [ ] Requirement IDs exist for all business rules: `REQ-{slug}-{N}`
-- [ ] Acceptance criteria exist for all behavioral requirements: `AC-{slug}-{N}`
-
-**Signal in `spec-{slug}.md`:** set `phase_gates.requirements: approved`
-
-**Not ready if:**
-- Requirements reference behavior that hasn't been decided
-- ACs are not independently verifiable (e.g., "works correctly" is not an AC)
-- There are contradictions between PRD and requirements
-
----
-
-## Gate B — Design approval
-
-**Before leaving @architect → @dev**
-
-Required for the gate to pass:
-- [ ] Technical approach is chosen and documented
-- [ ] Module/folder structure is defined
-- [ ] Dependencies between components are explicit
-- [ ] Risks and non-goals are documented
-- [ ] Decision rationale exists for non-obvious choices
-- [ ] @dev can start without having to invent business logic or architecture
-
-**Signal in `spec-{slug}.md`:** set `phase_gates.design: approved`
-**Signal in `architecture.md`:** closing line `> **Gate B:** Architecture approved — @dev can proceed.`
-
-**Not ready if:**
-- There are open decisions that @dev would need to make up during implementation
-- The architecture introduces patterns not supported by the project's stack
-- There are circular dependencies in the module structure
-
----
-
-## Gate C — Plan approval
-
-**Before @dev or @deyvin executes a significant batch**
-
-Required for the gate to pass:
-- [ ] Execution sequence is defined
-- [ ] Checkpoints are listed with criteria of done
-- [ ] Context package is listed (which files to read before each phase)
-- [ ] Review / QA requirements are noted
-- [ ] Decisions marked "pre-taken" are FINAL — @dev does not re-discuss
-
-**Signal in `spec-{slug}.md`:** set `phase_gates.plan: approved`
-**Signal in `implementation-plan-{slug}.md`:** status field = `approved`
-
-**Not ready if:**
-- The plan has phases with unclear done criteria
-- There are external dependencies not yet resolved
-- @dev would need to re-read the full spec from scratch to start
-
----
-
-## Gate D — Execution verification (must_haves)
-
-**Before marking a phase or feature as complete**
-
-Required:
-- [ ] All truths verified (behavioral — not just "I think it works")
-- [ ] All artifacts verified (substantive — not stubs)
-- [ ] All key_links verified (wiring — imports, registrations, middleware)
-
-**Not complete if:**
-- Any truth has no passing test or manual verification step
-- Any artifact is empty, a stub, or missing required exports
-- Any key_link shows the code exists but isn't connected
-
-**Signal:** update `last_checkpoint` in `spec-{slug}.md` with which must_haves passed and which failed.
-
----
-
-## Checkpoint taxonomy reference
-
-Quando qualquer agente precisa de interação humana durante execução:
-
-| Tipo | Quando | Frequência esperada |
-|------|--------|---------------------|
-| `verify` | Confirmar comportamento visível | Comum — após cada entrega testável |
-| `decision` | Bifurcação arquitetural ou de produto | Rara — apenas quando não especificado |
-| `action` | Passo que o agente não consegue executar | Muito rara — <1% dos steps |
-
-Regra: se o agente consegue executar sem risco, execute. Não peça confirmação desnecessária.
-
----
-
-## How agents communicate gate status
-
-Each agent, at session end, should:
-1. Update `phase_gates` in `spec-{slug}.md`
-2. Tell the user clearly: "Gate [A/B/C] passed — activate [@next-agent]" OR "Gate [A/B/C] blocked — [reason]. Resolve before continuing."
-
-Never silently assume a gate is passed.
+# Approval Gates — Spec-Driven Phase Transitions
+
+> Use when preparing a handoff or checking if a phase is ready to proceed.
+> Gates are blocking in MEDIUM. Informational in MICRO/SMALL.
+
+## Gate A — Requirements approval
+
+**Before leaving @product / @analyst → @architect or @dev**
+
+Required for the gate to pass:
+- [ ] Objectives are clear and unambiguous
+- [ ] Expected behaviors are described (not just features — what happens when X)
+- [ ] Constraints are explicit (what this version does NOT do)
+- [ ] Out of scope is listed
+- [ ] Open ambiguities are documented (not silently ignored)
+- [ ] Requirement IDs exist for all business rules: `REQ-{slug}-{N}`
+- [ ] Acceptance criteria exist for all behavioral requirements: `AC-{slug}-{N}`
+
+**Signal in `spec-{slug}.md`:** set `phase_gates.requirements: approved`
+
+**Not ready if:**
+- Requirements reference behavior that hasn't been decided
+- ACs are not independently verifiable (e.g., "works correctly" is not an AC)
+- There are contradictions between PRD and requirements
+
+---
+
+## Gate B — Design approval
+
+**Before leaving @architect → @dev**
+
+Required for the gate to pass:
+- [ ] Technical approach is chosen and documented
+- [ ] Module/folder structure is defined
+- [ ] Dependencies between components are explicit
+- [ ] Risks and non-goals are documented
+- [ ] Decision rationale exists for non-obvious choices
+- [ ] @dev can start without having to invent business logic or architecture
+
+**Signal in `spec-{slug}.md`:** set `phase_gates.design: approved`
+**Signal in `architecture.md`:** closing line `> **Gate B:** Architecture approved — @dev can proceed.`
+
+**Not ready if:**
+- There are open decisions that @dev would need to make up during implementation
+- The architecture introduces patterns not supported by the project's stack
+- There are circular dependencies in the module structure
+
+---
+
+## Gate C — Plan approval
+
+**Before @dev or @deyvin executes a significant batch**
+
+Required for the gate to pass:
+- [ ] Execution sequence is defined
+- [ ] Checkpoints are listed with criteria of done
+- [ ] Context package is listed (which files to read before each phase)
+- [ ] Review / QA requirements are noted
+- [ ] Decisions marked "pre-taken" are FINAL — @dev does not re-discuss
+
+**Signal in `spec-{slug}.md`:** set `phase_gates.plan: approved`
+**Signal in `implementation-plan-{slug}.md`:** status field = `approved`
+
+**Not ready if:**
+- The plan has phases with unclear done criteria
+- There are external dependencies not yet resolved
+- @dev would need to re-read the full spec from scratch to start
+
+---
+
+## Gate D — Execution verification (must_haves)
+
+**Before marking a phase or feature as complete**
+
+Required:
+- [ ] All truths verified (behavioral — not just "I think it works")
+- [ ] All artifacts verified (substantive — not stubs)
+- [ ] All key_links verified (wiring — imports, registrations, middleware)
+
+**Not complete if:**
+- Any truth has no passing test or manual verification step
+- Any artifact is empty, a stub, or missing required exports
+- Any key_link shows the code exists but isn't connected
+
+**Signal:** update `last_checkpoint` in `spec-{slug}.md` with which must_haves passed and which failed.
+
+---
+
+## Checkpoint taxonomy reference
+
+Quando qualquer agente precisa de interação humana durante execução:
+
+| Tipo | Quando | Frequência esperada |
+|------|--------|---------------------|
+| `verify` | Confirmar comportamento visível | Comum — após cada entrega testável |
+| `decision` | Bifurcação arquitetural ou de produto | Rara — apenas quando não especificado |
+| `action` | Passo que o agente não consegue executar | Muito rara — <1% dos steps |
+
+Regra: se o agente consegue executar sem risco, execute. Não peça confirmação desnecessária.
+
+---
+
+## How agents communicate gate status
+
+Each agent, at session end, should:
+1. Update `phase_gates` in `spec-{slug}.md`
+2. Tell the user clearly: "Gate [A/B/C] passed — activate [@next-agent]" OR "Gate [A/B/C] blocked — [reason]. Resolve before continuing."
+
+Never silently assume a gate is passed.

package/template/.aioson/skills/process/aioson-spec-driven/references/architect.md

@@ -1,23 +1,23 @@
-# Spec-Driven Reference — @architect
-
-> Router file. Do not duplicate logic from the generic references — load those directly.
-
-## Which references to load for architecture work
-
-### Always load when this skill is active
-
-- `classification-map.md` — use to determine architecture depth: MICRO skips most of this, MEDIUM requires full `architecture.md`
-- `approval-gates.md` — Gate B criteria define what @architect must produce before @dev can start; Gate A must already be passed before @architect begins
-- `artifact-map.md` — use to confirm which artifacts @architect owns (`architecture.md`, `design-doc*.md`) and which feed into it
-
-### Do not load for @architect
-
-- `hardening-lane.md` — input is expected to be already past vibe mode when @architect is activated
-- `maintenance-and-state.md` — this is for execution/continuation sessions
-
-## Behavioral notes
-
-- Classification depth from `classification-map.md` controls whether `architecture.md` is required, selective, or skippable
-- Gate B is the handoff signal — @dev must not start implementation without Gate B passing (MEDIUM) or being explicitly waived (SMALL)
-- Decision rationale is mandatory for non-obvious choices — `approval-gates.md` Gate B checklist item applies
-- `design-doc*.md` is @architect's scope-specific decision document — see `artifact-map.md`
+# Spec-Driven Reference — @architect
+
+> Router file. Do not duplicate logic from the generic references — load those directly.
+
+## Which references to load for architecture work
+
+### Always load when this skill is active
+
+- `classification-map.md` — use to determine architecture depth: MICRO skips most of this, MEDIUM requires full `architecture.md`
+- `approval-gates.md` — Gate B criteria define what @architect must produce before @dev can start; Gate A must already be passed before @architect begins
+- `artifact-map.md` — use to confirm which artifacts @architect owns (`architecture.md`, `design-doc*.md`) and which feed into it
+
+### Do not load for @architect
+
+- `hardening-lane.md` — input is expected to be already past vibe mode when @architect is activated
+- `maintenance-and-state.md` — this is for execution/continuation sessions
+
+## Behavioral notes
+
+- Classification depth from `classification-map.md` controls whether `architecture.md` is required, selective, or skippable
+- Gate B is the handoff signal — @dev must not start implementation without Gate B passing (MEDIUM) or being explicitly waived (SMALL)
+- Decision rationale is mandatory for non-obvious choices — `approval-gates.md` Gate B checklist item applies
+- `design-doc*.md` is @architect's scope-specific decision document — see `artifact-map.md`

package/template/.aioson/skills/process/aioson-spec-driven/references/artifact-map.md

@@ -1,44 +1,44 @@
-# Artifact Map — AIOSON Spec-Driven
-
-> Source of truth: which artifact lives where, who writes it, who reads it.
-
-## Artifact chain
-
-```
-prd*.md
-  → sheldon-enrichment-{slug}.md   (optional enrichment layer)
-  → requirements-{slug}.md         (entities, rules, ACs — @analyst)
-  → spec-{slug}.md                 (feature memory — @analyst seeds, @dev fills)
-  → architecture.md                (tech decisions — @architect)
-  → design-doc*.md                 (scope-specific decisions — @architect)
-  → implementation-plan-{slug}.md  (execution sequence — @dev)
-  → spec-{slug}.md (updated)       (living state during execution — @dev)
-```
-
-## Artifact ownership
-
-| Artifact | Written by | Enriched by | Read by |
-|----------|-----------|-------------|---------|
-| `prd.md` / `prd-{slug}.md` | @product | @sheldon (via sheldon-enrichment) | all downstream |
-| `sheldon-enrichment-{slug}.md` | @sheldon | @sheldon | @sheldon (re-entry), @analyst |
-| `sheldon-validation.md` | @sheldon | — | all agents before starting MEDIUM |
-| `discovery.md` | @analyst | — | @architect, @dev |
-| `requirements-{slug}.md` | @analyst | — | @architect, @dev, @qa |
-| `spec-{slug}.md` | @analyst (skeleton) | @dev (execution state) | @dev, @deyvin, @qa |
-| `spec.md` | @dev | @dev | @dev, @deyvin |
-| `architecture.md` | @architect | — | @dev, @ux-ui |
-| `design-doc*.md` | @architect | — | @dev, @ux-ui |
-| `implementation-plan-{slug}.md` | @dev | — | @dev, @deyvin |
-
-## Naming conventions
-
-- Project-level artifacts: `prd.md`, `discovery.md`, `spec.md`, `architecture.md`
-- Feature-level artifacts: always use `{slug}` suffix — `prd-{slug}.md`, `requirements-{slug}.md`, `spec-{slug}.md`
-- Enrichment: `sheldon-enrichment.md` (project) or `sheldon-enrichment-{slug}.md` (feature)
-- Plans: `.aioson/plans/{slug}/manifest.md` + `plan-{slug-fase}.md` files
-
-## What NOT to create
-
-- Do not create `.specs/` folders — use the artifact names above
-- Do not rename existing artifacts to match TLC conventions
-- Do not create a new artifact if an existing one covers the same purpose
+# Artifact Map — AIOSON Spec-Driven
+
+> Source of truth: which artifact lives where, who writes it, who reads it.
+
+## Artifact chain
+
+```
+prd*.md
+  → sheldon-enrichment-{slug}.md   (optional enrichment layer)
+  → requirements-{slug}.md         (entities, rules, ACs — @analyst)
+  → spec-{slug}.md                 (feature memory — @analyst seeds, @dev fills)
+  → architecture.md                (tech decisions — @architect)
+  → design-doc*.md                 (scope-specific decisions — @architect)
+  → implementation-plan-{slug}.md  (execution sequence — @dev)
+  → spec-{slug}.md (updated)       (living state during execution — @dev)
+```
+
+## Artifact ownership
+
+| Artifact | Written by | Enriched by | Read by |
+|----------|-----------|-------------|---------|
+| `prd.md` / `prd-{slug}.md` | @product | @sheldon (via sheldon-enrichment) | all downstream |
+| `sheldon-enrichment-{slug}.md` | @sheldon | @sheldon | @sheldon (re-entry), @analyst |
+| `sheldon-validation.md` | @sheldon | — | all agents before starting MEDIUM |
+| `discovery.md` | @analyst | — | @architect, @dev |
+| `requirements-{slug}.md` | @analyst | — | @architect, @dev, @qa |
+| `spec-{slug}.md` | @analyst (skeleton) | @dev (execution state) | @dev, @deyvin, @qa |
+| `spec.md` | @dev | @dev | @dev, @deyvin |
+| `architecture.md` | @architect | — | @dev, @ux-ui |
+| `design-doc*.md` | @architect | — | @dev, @ux-ui |
+| `implementation-plan-{slug}.md` | @dev | — | @dev, @deyvin |
+
+## Naming conventions
+
+- Project-level artifacts: `prd.md`, `discovery.md`, `spec.md`, `architecture.md`
+- Feature-level artifacts: always use `{slug}` suffix — `prd-{slug}.md`, `requirements-{slug}.md`, `spec-{slug}.md`
+- Enrichment: `sheldon-enrichment.md` (project) or `sheldon-enrichment-{slug}.md` (feature)
+- Plans: `.aioson/plans/{slug}/manifest.md` + `plan-{slug-fase}.md` files
+
+## What NOT to create
+
+- Do not create `.specs/` folders — use the artifact names above
+- Do not rename existing artifacts to match TLC conventions
+- Do not create a new artifact if an existing one covers the same purpose

package/template/.aioson/skills/process/aioson-spec-driven/references/classification-map.md

@@ -1,37 +1,37 @@
-# Classification Map — Phase Depth by Project Size
-
-> Use this when deciding which phases to run and how deep to go.
-
-## Depth table
-
-| Phase | MICRO (0–1) | SMALL (2–3) | MEDIUM (4–6) |
-|-------|-------------|-------------|--------------|
-| Specify (PRD) | 1 conversation, lite template | Full PRD conversation | Full PRD + `## Specify depth` section |
-| Research (@sheldon) | Skip unless links/external sources provided | Recommended — run before @analyst | Required — run Modo C (full validation) |
-| Requirements (@analyst) | Skip — go @product → @dev | Required — `requirements-{slug}.md` | Required — with requirement IDs + ACs |
-| Design (@architect) | Skip unless auth or external integration | Selective — only if new architecture pattern | Required — full `architecture.md` |
-| Plan (implementation-plan) | Optional — suggest only if @dev asks | Recommended | Required — with gate approval + verification criteria |
-| Execute (@dev) | Direct from PRD | From requirements + spec | From approved plan only |
-| State (@dev, @deyvin) | Minimal `spec.md` note | `spec-{slug}.md` with phase_gates | Full spec pack — phase_gates + checkpoints + maintenance notes |
-
-## Scoring (from @analyst)
-
-| Dimension | Score |
-|-----------|-------|
-| User types: 1 | 0 |
-| User types: 2 | 1 |
-| User types: 3+ | 2 |
-| External integrations: 0 | 0 |
-| External integrations: 1–2 | 1 |
-| External integrations: 3+ | 2 |
-| Business rule complexity: none | 0 |
-| Business rule complexity: some | 1 |
-| Business rule complexity: complex | 2 |
-
-**0–1 = MICRO / 2–3 = SMALL / 4–6 = MEDIUM**
-
-## Gate behavior by classification
-
-- **MICRO**: gates are informational, never blocking. @dev may proceed without explicit approval.
-- **SMALL**: Gate A (requirements) is recommended before design. Gate B is optional.
-- **MEDIUM**: Gates A, B, C are required. Do not proceed to next phase without explicit user confirmation.
+# Classification Map — Phase Depth by Project Size
+
+> Use this when deciding which phases to run and how deep to go.
+
+## Depth table
+
+| Phase | MICRO (0–1) | SMALL (2–3) | MEDIUM (4–6) |
+|-------|-------------|-------------|--------------|
+| Specify (PRD) | 1 conversation, lite template | Full PRD conversation | Full PRD + `## Specify depth` section |
+| Research (@sheldon) | Skip unless links/external sources provided | Recommended — run before @analyst | Required — run Modo C (full validation) |
+| Requirements (@analyst) | Skip — go @product → @dev | Required — `requirements-{slug}.md` | Required — with requirement IDs + ACs |
+| Design (@architect) | Skip unless auth or external integration | Selective — only if new architecture pattern | Required — full `architecture.md` |
+| Plan (implementation-plan) | Optional — suggest only if @dev asks | Recommended | Required — with gate approval + verification criteria |
+| Execute (@dev) | Direct from PRD | From requirements + spec | From approved plan only |
+| State (@dev, @deyvin) | Minimal `spec.md` note | `spec-{slug}.md` with phase_gates | Full spec pack — phase_gates + checkpoints + maintenance notes |
+
+## Scoring (from @analyst)
+
+| Dimension | Score |
+|-----------|-------|
+| User types: 1 | 0 |
+| User types: 2 | 1 |
+| User types: 3+ | 2 |
+| External integrations: 0 | 0 |
+| External integrations: 1–2 | 1 |
+| External integrations: 3+ | 2 |
+| Business rule complexity: none | 0 |
+| Business rule complexity: some | 1 |
+| Business rule complexity: complex | 2 |
+
+**0–1 = MICRO / 2–3 = SMALL / 4–6 = MEDIUM**
+
+## Gate behavior by classification
+
+- **MICRO**: gates are informational, never blocking. @dev may proceed without explicit approval.
+- **SMALL**: Gate A (requirements) is recommended before design. Gate B is optional.
+- **MEDIUM**: Gates A, B, C are required. Do not proceed to next phase without explicit user confirmation.

package/template/.aioson/skills/process/aioson-spec-driven/references/dev.md

@@ -1,47 +1,47 @@
-# Spec-Driven Reference — @dev
-
-> Router file. Do not duplicate logic from the generic references — load those directly.
-
-## Which references to load for implementation
-
-### Always load when this skill is active
-
-- `maintenance-and-state.md` — use to write and update `spec-{slug}.md` correctly: `phase_gates`, `last_checkpoint`, `pending_review`, and `Key decisions` format
-- `approval-gates.md` — Gate C (plan approval) must be checked before executing a significant batch; Gate D (execution verification) defines done criteria for each phase
-
-### Load when starting a new feature with classification context
-
-- `classification-map.md` — use to confirm whether an implementation plan is optional (MICRO), recommended (SMALL), or required (MEDIUM) before starting
-
-### Load when resuming or checking artifact chain
-
-- `artifact-map.md` — use to verify which upstream artifacts exist and which @dev should read before implementing
-
-### Do not load for @dev
-
-- `hardening-lane.md` — @dev activates after hardening; if the spec is still in vibe mode, stop and route back
-- `ui-language.md` — load only when producing a checkpoint or gate status presentation for the user
-
-## Spec drift detection
-
-At session start, after reading `spec-{slug}.md`:
-
-1. Compare `spec_version` in `spec-{slug}.md` with the version recorded in `dev-state.md` (`last_spec_version` field)
-2. If versions differ:
-   > "⚠ Spec changed since last session (version {old} → {new}). Reading the changes before continuing."
-   - Read the diff (Key decisions, Entities added, Edge cases sections)
-   - Update `dev-state.md` with new `last_spec_version`
-3. If versions match: proceed normally
-
-Additionally, at session start for SMALL/MEDIUM:
-4. Check if any `AC-{slug}-{N}` from `requirements-{slug}.md` has a corresponding test file
-5. If coverage is < 50%:
-   > "⚠ AC coverage is low ({N}/{M} ACs have tests). Consider writing missing tests before adding new behavior."
-   This is informational, not blocking.
-
-## Behavioral notes
-
-- `spec-{slug}.md` must be updated at the end of every implementation session — see `maintenance-and-state.md` for format
-- Gate C from `approval-gates.md` means the implementation plan is locked — do not re-discuss pre-taken decisions
-- Gate D verification must happen before marking a phase complete — not just "I think it works"
-- If `phase_gates.plan` is `pending` and classification is SMALL/MEDIUM, suggest generating an implementation plan before proceeding
+# Spec-Driven Reference — @dev
+
+> Router file. Do not duplicate logic from the generic references — load those directly.
+
+## Which references to load for implementation
+
+### Always load when this skill is active
+
+- `maintenance-and-state.md` — use to write and update `spec-{slug}.md` correctly: `phase_gates`, `last_checkpoint`, `pending_review`, and `Key decisions` format
+- `approval-gates.md` — Gate C (plan approval) must be checked before executing a significant batch; Gate D (execution verification) defines done criteria for each phase
+
+### Load when starting a new feature with classification context
+
+- `classification-map.md` — use to confirm whether an implementation plan is optional (MICRO), recommended (SMALL), or required (MEDIUM) before starting
+
+### Load when resuming or checking artifact chain
+
+- `artifact-map.md` — use to verify which upstream artifacts exist and which @dev should read before implementing
+
+### Do not load for @dev
+
+- `hardening-lane.md` — @dev activates after hardening; if the spec is still in vibe mode, stop and route back
+- `ui-language.md` — load only when producing a checkpoint or gate status presentation for the user
+
+## Spec drift detection
+
+At session start, after reading `spec-{slug}.md`:
+
+1. Compare `spec_version` in `spec-{slug}.md` with the version recorded in `dev-state.md` (`last_spec_version` field)
+2. If versions differ:
+   > "⚠ Spec changed since last session (version {old} → {new}). Reading the changes before continuing."
+   - Read the diff (Key decisions, Entities added, Edge cases sections)
+   - Update `dev-state.md` with new `last_spec_version`
+3. If versions match: proceed normally
+
+Additionally, at session start for SMALL/MEDIUM:
+4. Check if any `AC-{slug}-{N}` from `requirements-{slug}.md` has a corresponding test file
+5. If coverage is < 50%:
+   > "⚠ AC coverage is low ({N}/{M} ACs have tests). Consider writing missing tests before adding new behavior."
+   This is informational, not blocking.
+
+## Behavioral notes
+
+- `spec-{slug}.md` must be updated at the end of every implementation session — see `maintenance-and-state.md` for format
+- Gate C from `approval-gates.md` means the implementation plan is locked — do not re-discuss pre-taken decisions
+- Gate D verification must happen before marking a phase complete — not just "I think it works"
+- If `phase_gates.plan` is `pending` and classification is SMALL/MEDIUM, suggest generating an implementation plan before proceeding

package/template/.aioson/skills/process/aioson-spec-driven/references/deyvin.md

@@ -1,27 +1,27 @@
-# Spec-Driven Reference — @deyvin
-
-> Router file. Do not duplicate logic from the generic references — load those directly.
-
-## Which references to load for continuation and resume flows
-
-### Always load when this skill is active
-
-- `maintenance-and-state.md` — @deyvin's primary job is resumption; use this to read `phase_gates`, `last_checkpoint`, and `pending_review` correctly before any action
-- `approval-gates.md` — use to check which gates are already approved before proceeding; never advance past a gate that is not yet passed
-
-### Load when the continuation context is unclear
-
-- `artifact-map.md` — use to quickly orient which artifacts exist and which are missing when resuming a session with incomplete context
-
-### Do not load for @deyvin
-
-- `hardening-lane.md` — by the time @deyvin is active, the spec pack should already be hardened
-- `classification-map.md` — classification was set in the spec and should not be re-evaluated during continuation
-- `ui-language.md` — load only when producing a checkpoint or gate status presentation for the user
-
-## Behavioral notes
-
-- `last_checkpoint` in `spec-{slug}.md` is the first thing @deyvin reads — see `maintenance-and-state.md` for format
-- Do not re-read the full spec pack unless `last_checkpoint` is null or contradictory
-- `phase_gates` from `approval-gates.md` defines what is locked — @deyvin does not re-open locked decisions
-- `pending_review` items must be surfaced to the user before proceeding past them
+# Spec-Driven Reference — @deyvin
+
+> Router file. Do not duplicate logic from the generic references — load those directly.
+
+## Which references to load for continuation and resume flows
+
+### Always load when this skill is active
+
+- `maintenance-and-state.md` — @deyvin's primary job is resumption; use this to read `phase_gates`, `last_checkpoint`, and `pending_review` correctly before any action
+- `approval-gates.md` — use to check which gates are already approved before proceeding; never advance past a gate that is not yet passed
+
+### Load when the continuation context is unclear
+
+- `artifact-map.md` — use to quickly orient which artifacts exist and which are missing when resuming a session with incomplete context
+
+### Do not load for @deyvin
+
+- `hardening-lane.md` — by the time @deyvin is active, the spec pack should already be hardened
+- `classification-map.md` — classification was set in the spec and should not be re-evaluated during continuation
+- `ui-language.md` — load only when producing a checkpoint or gate status presentation for the user
+
+## Behavioral notes
+
+- `last_checkpoint` in `spec-{slug}.md` is the first thing @deyvin reads — see `maintenance-and-state.md` for format
+- Do not re-read the full spec pack unless `last_checkpoint` is null or contradictory
+- `phase_gates` from `approval-gates.md` defines what is locked — @deyvin does not re-open locked decisions
+- `pending_review` items must be surfaced to the user before proceeding past them