specatlas 0.1.0 → 0.1.1

package/dist/bin.js

@@ -8768,6 +8768,30 @@ function highlightCode(code, language, enabled) {
 function splitRow(line) {
   return line.trim().replace(/^\|/, "").replace(/\|$/, "").split("|").map((cell) => cell.trim());
 }
+function tableOfContents(markdown2, maxLevel = 2) {
+  const entries = [];
+  let inFence = false;
+  for (const line of markdown2.replace(/\r\n?/g, "\n").split("\n")) {
+    if (/^```/.test(line)) {
+      inFence = !inFence;
+      continue;
+    }
+    if (inFence) continue;
+    const match = /^(#{1,4})\s+(.*)$/.exec(line);
+    if (!match) continue;
+    const level = (match[1] ?? "").length;
+    if (level > maxLevel) continue;
+    const text = match[2] ?? "";
+    entries.push({ level, text, id: slugify(text) });
+  }
+  return entries;
+}
+function renderToc(entries, title) {
+  if (entries.length === 0) return "";
+  const items = entries.map((entry) => `<li class="toc-h${entry.level}"><a href="#${entry.id}">${inlineMarkdown(entry.text)}</a></li>`).join("");
+  return `<nav class="atlas-toc"><h2>${escapeHtml(title)}</h2><ul>${items}</ul></nav>
+`;
+}
 function renderMarkdown(markdown2, opts = {}) {
   const highlight = opts.highlight !== false;
   const mermaidMode = opts.mermaid ?? "code";
@@ -8900,7 +8924,11 @@ function renderMarkdown(markdown2, opts = {}) {
     i += 1;
   }
   flush();
-  return out.join("\n");
+  const html = out.join("\n");
+  if (opts.toc) {
+    return renderToc(tableOfContents(markdown2), opts.tocTitle ?? "\xCDndice") + html;
+  }
+  return html;
 }
 
 // ../core/dist/index.js
@@ -13757,7 +13785,14 @@ async function runInit(ctx) {
   });
   const compiled = [];
   const workflowDir = await resolveWorkflowDir();
-  if (workflowDir && !result.diagnostics.some((d) => d.severity === "error")) {
+  if (!workflowDir) {
+    result.diagnostics.push({
+      code: "ATLAS-ADAPTERS-003",
+      severity: "error",
+      message: "No se encontr\xF3 la carpeta workflow/phases con las fuentes de prompts: no se compilaron los adaptadores",
+      suggestion: "Verifica la instalaci\xF3n del CLI o define SPECATLAS_WORKFLOW_DIR apuntando a la carpeta workflow del paquete"
+    });
+  } else if (!result.diagnostics.some((d) => d.severity === "error")) {
     const loaded = await loadConfig(result.sddDir);
     const agentsFlag = flagString(ctx.flags, "agents");
     const requested = agentsFlag ? agentsFlag.split(",").map((t) => t.trim()).filter((t) => t.length > 0) : loaded.config.adapters.targets;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "specatlas",
-  "version": "0.1.0",
+  "version": "0.1.1",
   "description": "SpecAtlas: kernel determinista de Spec-Driven Development (CLI)",
   "license": "MIT",
   "type": "module",
@@ -10,7 +10,9 @@
   },
   "main": "dist/bin.js",
   "files": [
-    "dist"
+    "dist",
+    "workflow",
+    "profiles"
   ],
   "engines": {
     "node": ">=20"

package/profiles/dotnet-sqlserver.yaml

@@ -0,0 +1,36 @@
+name: dotnet-sqlserver
+display_name: .NET + SQL Server
+detection:
+  files:
+    - '**/*.cs'
+    - '**/*.csproj'
+    - '**/*.sln'
+  manifests:
+    - file: '*.sln'
+      contains: []
+    - file: '*.csproj'
+      contains: []
+  priority: 20
+domains:
+  - backend
+  - database
+commands:
+  build: dotnet build
+  test: dotnet test
+  lint: dotnet format --verify-no-changes
+  format: dotnet format
+verify:
+  executable:
+    - dotnet test
+  automatic:
+    - dotnet build
+  manual:
+    - Ejecución del flujo contra la base de datos de desarrollo
+rollback: Script SQL de rollback por objeto afectado + revertir el commit.
+antipatterns:
+  - DML directo sobre tablas históricas
+  - Endpoints sin autenticación
+  - Cambios de base de datos sin script de rollback
+assumptions:
+  - .NET LTS
+  - SQL Server accesible en desarrollo

package/profiles/generic.yaml

@@ -0,0 +1,19 @@
+name: generic
+display_name: Genérico (cualquier stack)
+detection:
+  files: []
+  manifests: []
+  priority: 0
+domains:
+  - other
+commands: {}
+verify:
+  executable: []
+  automatic: []
+  manual:
+    - Confirmación humana explícita del resultado observado
+rollback: Revierte los archivos tocados al estado anterior (git revert o restaurar backup).
+antipatterns:
+  - Inventar comandos de build/test que el proyecto no tiene
+assumptions:
+  - El stack no está cubierto por un perfil específico

package/profiles/node-ts.yaml

@@ -0,0 +1,38 @@
+name: node-ts
+display_name: Node + TypeScript
+detection:
+  files:
+    - '**/*.ts'
+    - '**/*.tsx'
+    - package.json
+  manifests:
+    - file: package.json
+      contains:
+        - typescript
+  priority: 10
+domains:
+  - backend
+  - frontend
+  - fullstack
+  - testing
+commands:
+  build: npm run build
+  lint: npm run lint
+  test: npm test
+  format: npm run format
+verify:
+  executable:
+    - npm test
+    - npm run lint
+  automatic:
+    - Búsqueda de efectos colaterales con grep
+  manual:
+    - Prueba manual del flujo principal en desarrollo
+rollback: Revierte el commit y deshaz migraciones si el cambio las incluye.
+antipatterns:
+  - SQL concatenado en lugar de consultas parametrizadas
+  - Secretos versionados o logueados
+  - console.log olvidados en producción
+assumptions:
+  - Node LTS
+  - El proyecto declara sus scripts en package.json

package/profiles/python.yaml

@@ -0,0 +1,36 @@
+name: python
+display_name: Python
+detection:
+  files:
+    - '**/*.py'
+    - pyproject.toml
+    - requirements.txt
+  manifests:
+    - file: pyproject.toml
+      contains: []
+    - file: requirements.txt
+      contains: []
+  priority: 10
+domains:
+  - backend
+  - other
+commands:
+  build: ''
+  lint: ruff check .
+  test: pytest
+  format: ruff format .
+verify:
+  executable:
+    - pytest
+    - ruff check .
+  automatic:
+    - Revisión de imports y efectos colaterales
+  manual:
+    - Ejecución manual del flujo principal
+rollback: Revierte el commit; si hay migraciones, aplica el downgrade correspondiente.
+antipatterns:
+  - Excepciones silenciadas sin log
+  - Credenciales en el código
+assumptions:
+  - Python 3.11+
+  - El proyecto declara dependencias (pyproject o requirements)

package/workflow/phases/adopt.md

@@ -0,0 +1,51 @@
+---
+id: adopt
+title: Adoptar (brownfield)
+description: >-
+  Recupera las specs de un proyecto existente: lee el inventario y las anclas, entrevista al usuario y redacta requisitos AS-IS.
+  Usar cuando el usuario pide adoptar, documentar o recuperar las specs de un proyecto que ya existe.
+requires: []
+produces:
+  - specs/<dominio>/spec.md
+  - changes/adopt-<dominio>/spec.md
+arguments: true
+agent:
+  mode: primary
+---
+
+# Fase: Adoptar (brownfield)
+
+El contenido se escribe en **{{LANGUAGE_NAME}}**.
+
+## Pasos
+
+1. Genera el inventario y las specs baseline:
+
+```
+satlas adopt
+```
+
+2. Lee `.sdd/adopt-report.md`, las anclas de cada `specs/<dominio>/spec.md` y el código real que esas anclas señalan.
+3. Por cada dominio, **entrevista al usuario** (máximo 5 preguntas) para confirmar el comportamiento actual antes de escribirlo. No inventes reglas: si el código no lo aclara, pregunta.
+4. Crea el cambio de adopción y redacta el delta con el comportamiento **actual** (AS-IS):
+
+```
+satlas new adopt-<dominio> --domain <dominio>
+```
+
+   - Requisitos `REQ-<DOMINIO>-NNN` con actor, prosa de negocio y reglas `BR-*`.
+   - Escenarios `CUANDO/ENTONCES` que describan lo que el sistema hace hoy, incluyendo errores y límites visibles.
+   - `## Anclas de implementación` con los archivos/símbolos que respaldan cada requisito (permite detectar drift después).
+5. Valida y pliega (la adopción documenta lo existente: no requiere tareas ni verificación):
+
+```
+satlas validate --change adopt-<dominio>
+satlas archive adopt-<dominio> --yes
+```
+
+6. Repite por dominio y reporta la cobertura: dominios adoptados, requisitos recuperados y zonas del código sin requisito (deuda de documentación).
+
+## Prohibido
+
+- Escribir requisitos de comportamiento que no exista hoy (eso es un cambio: usa `satlas new`).
+- Copiar nombres técnicos a la spec: la spec es de negocio aunque documente lo existente.

package/workflow/phases/archive.md

@@ -0,0 +1,43 @@
+---
+id: archive
+title: Archivar
+description: >-
+  Cierra el cambio: pliega los deltas en la spec viva y mueve el cambio al histórico.
+  Usar cuando el usuario pide archivar, cerrar o dar por terminado un cambio.
+requires:
+  - changes/<slug>/verify.md
+produces:
+  - specs/<dominio>/spec.md
+arguments: true
+agent:
+  mode: primary
+---
+
+# Fase: Archivar
+
+## Precondición
+
+- Sin tareas pendientes y con evidencia `pass` por escenario (`satlas trace --change {{SLUG}}`).
+- Sin hallazgos críticos abiertos en `review.md` (si el carril lo exige).
+
+## Pasos
+
+1. Revisa el plan (seco) antes de tocar nada:
+
+```
+satlas archive {{SLUG}} --dry-run
+```
+
+2. Si el plegado es correcto (agregados/modificados/eliminados/renombrados esperados), archiva:
+
+```
+satlas archive {{SLUG}} --yes
+```
+
+3. Verifica el resultado: `specs/<dominio>/spec.md` versionado y `changes/archive/AAAA-MM-{{SLUG}}/` con la historia; `INDEX.md` regenerado.
+4. Reporta: requisitos plegados, versión de la spec viva y ubicación del archivo.
+
+## Prohibido
+
+- Editar la spec viva a mano: el plegado lo hace el CLI de forma determinista.
+- Archivar con evidencia fallida o tareas pendientes.

package/workflow/phases/build.md

@@ -0,0 +1,52 @@
+---
+id: build
+title: Construir
+description: >-
+  Implementa las tareas del cambio por olas paralelas, con evidencia y sin tocar los artefactos aprobados.
+  Usar cuando el usuario pide construir, implementar o codificar las tareas.
+requires:
+  - changes/<slug>/tasks.md
+produces:
+  - código y pruebas del cambio
+arguments: true
+agent:
+  mode: primary
+---
+
+# Fase: Construir
+
+## Precondición
+
+- `satlas trace --change {{SLUG}}` sin errores y `satlas status` en "construyendo" (o "aprobado/planificado").
+- Si hay tareas pendientes y la spec cambió sin re-aprobar, detente.
+
+## Pasos
+
+1. Lee `tasks.md`. Calcula olas:
+
+```
+satlas waves --change {{SLUG}}
+```
+
+2. Ejecuta **bloque por bloque** y **ola por ola**:
+   - Confirma con el usuario el bloque y su mapa de olas antes de empezar.
+   - Dentro de una ola, ejecuta las tareas en paralelo solo si no comparten archivos; si comparten, secuéncialas.
+   - Cada tarea: implementa exactamente su `Archivos:`, respeta `Cubre:` y deja el código funcionando.
+   - Al cerrar cada tarea, marca `- [x]` en `tasks.md` (una sola edición por bloque).
+3. Tras cada bloque:
+   - Ejecuta la validación del perfil (build/lint/test) y captura el resultado.
+   - Commitea solo el código (nunca `.sdd/` en commits de build).
+4. Si una tarea falla: reintenta (máx. 3), si sigue fallando detén el bloque y reporta con el log.
+5. Al terminar todas las tareas, cierra con:
+
+```
+satlas trace --change {{SLUG}}
+satlas status
+```
+
+## Prohibido
+
+- Modificar `spec.md`, `plan.md` o `meta.yaml` (los artefactos aprobados son inmutables).
+- Ejecutar `git` dentro de subagentes.
+- Marcar tareas sin haber ejecutado la validación correspondiente.
+- Dar por terminado sin evidencia (esa es la fase de verificación).

package/workflow/phases/fix.md

@@ -0,0 +1,31 @@
+---
+id: fix
+title: Fix express
+description: >-
+  Carril express para incidentes (bug, hotfix, configuración): un solo artefacto, con causa raíz, cambio mínimo y evidencia.
+  Usar cuando el usuario pide arreglar un bug, un hotfix o un cambio pequeño sin ceremonia completa.
+requires: []
+produces:
+  - changes/<slug>/fix.md
+arguments: true
+agent:
+  mode: primary
+---
+
+# Fase: Fix express (incidente)
+
+Un solo artefacto: `.sdd/changes/{{SLUG}}/fix.md`. El contenido se escribe en **{{LANGUAGE_NAME}}**.
+
+## Pasos
+
+1. Reproduce el problema o reúne la evidencia de que ocurre (log, pantalla, datos).
+2. Investiga la causa raíz en el código real; cita `archivo:línea`.
+3. Aplica el **cambio mínimo** que corrige la causa (no aproveches para refactorizar).
+4. Escribe `fix.md` con: `## Síntoma`, `## Causa raíz`, `## Cambio`, `## Rollback` y un bloque `evidence`.
+5. Verifica que el síntoma ya no ocurre y que no rompiste nada alrededor (validación del perfil).
+6. Si el arreglo revela alcance de feature (no de incidente), **promuévelo**: crea un cambio normal con `satlas new` y pásalo a especificación.
+
+## Prohibido
+
+- Tocar la spec viva o los artefactos de otros cambios.
+- Mezclar en el mismo fix varios problemas no relacionados.

package/workflow/phases/mockup.md

@@ -0,0 +1,54 @@
+---
+id: mockup
+title: Mockups
+description: >-
+  Genera mockups profesionales (web/mobile) como contrato visual de la propuesta: alta fidelidad, estados, responsive y accesibles.
+  Usar cuando el usuario pide mockups, prototipos visuales o la propuesta visual del cambio.
+requires:
+  - changes/<slug>/spec.md
+produces:
+  - changes/<slug>/mockups/*.html
+arguments: true
+agent:
+  mode: primary
+---
+
+# Fase: Mockups (contrato visual)
+
+El contenido se escribe en **{{LANGUAGE_NAME}}**.
+
+## Pasos
+
+1. Prepara el plan y el manifiesto:
+
+```
+satlas mockup {{SLUG}}
+```
+
+2. Lee el plan (`changes/{{SLUG}}/mockups/plan.yaml`), la spec, el glosario y, si existen, `design/tokens.json` o `DESIGN.md` (sistema de diseño del proyecto).
+3. Genera **un HTML autocontenido por pantalla** (`changes/{{SLUG}}/mockups/<id>.html`) con calidad de producto:
+   - banner fijo visible: `MOCKUP · NO FUNCIONAL · vX · fecha`;
+   - datos reales del dominio (prohibido Lorem ipsum, "Item 1" o textos de relleno);
+   - estados completos conmutables (`data-state`): default, loading, vacío, error; en mobile también offline;
+   - responsive real (390 / 768 / 1440) y tema claro/oscuro si el proyecto lo define;
+   - accesibilidad: contraste AA, foco visible, áreas táctiles ≥ 44 px, jerarquía semántica;
+   - navegación entre pantallas con enlaces relativos entre archivos;
+   - sin recursos externos: sin CDN, sin fuentes remotas, sin `http(s)://`; embebe lo necesario.
+4. Valida y corrige hasta que no haya errores:
+
+```
+satlas mockup {{SLUG}} --check
+```
+
+5. Opcional (si hay Playwright instalado): captura de pantallas por breakpoint.
+
+```
+satlas mockup {{SLUG}} --capture
+```
+
+6. Reporta las pantallas generadas, los escenarios que ilustra cada una y el resultado de la validación.
+
+## Prohibido
+
+- Aprobar mockups sin estados ni responsive, o que no sigan los tokens del proyecto cuando existen.
+- Añadir lógica real o datos personales reales en el mockup.

package/workflow/phases/plan.md

@@ -0,0 +1,48 @@
+---
+id: plan
+title: Planificar
+description: >-
+  Crea el plan técnico y las tareas trazadas de un cambio ya aprobado.
+  Usar cuando el usuario pide planificar, diseñar la solución o desglosar tareas.
+requires:
+  - changes/<slug>/spec.md
+produces:
+  - changes/<slug>/plan.md
+  - changes/<slug>/tasks.md
+arguments: true
+agent:
+  mode: primary
+---
+
+# Fase: Planificar (técnico)
+
+El contenido se escribe en **{{LANGUAGE_NAME}}**. El plan es interno: puede (y debe) hablar de tecnología; la spec no se toca.
+
+## Precondición
+
+- La spec del cambio debe estar aprobada (`satlas status` no debe decir "esperando aprobación").
+- Si no lo está, detente y pide la aprobación.
+
+## Pasos
+
+1. Lee `.sdd/changes/{{SLUG}}/spec.md`, `.sdd/constitution.md`, `.sdd/profiles/detected.yaml`, `.sdd/profiles/custom/*` y el código real que vayas a tocar (anclas AS-IS: existe / no existe / blast radius).
+2. Escribe `plan.md` con las secciones canónicas:
+   1. Contexto AS-IS · 2. Enfoque técnico (con alternativas descartadas) · 3. **Diagramas** · 4. Diseño por capa/módulos · 5. Matriz de trazabilidad (REQ → tareas) · 6. Matriz de paridad AS-IS → TO-BE (solo refactors sustitutivos) · 7. Tareas (referencia) · 8. Riesgos y mitigaciones · 9. Rollback · 10. Dependencias y supuestos.
+3. En `## 3. Diagramas` incluye los diagramas mermaid que el cambio necesite: `erDiagram` si toca datos, `sequenceDiagram` si hay integración/API/jobs, `flowchart` si hay proceso o validaciones, `stateDiagram-v2` si hay estados, `classDiagram` si el dominio no es trivial, diagrama de arquitectura si hay módulos nuevos.
+4. Escribe `tasks.md` con la gramática canónica (separador ` · `):
+   - `## Bloque N — Título` y `- [ ] T<N>.<seq> Acción · Archivos: ruta · Cubre: REQ-…-S1 · Depende de: T<N>.<seq> · Reversión: cómo revertir`
+   - Tareas atómicas (una acción por tarea). Trabajo de infraestructura sin requisito: `· Infra`.
+5. Valida y planifica olas:
+
+```
+satlas trace --change {{SLUG}}
+satlas waves --change {{SLUG}}
+```
+
+6. Reporta: bloques, tareas, olas, riesgos y cualquier hueco de trazabilidad (debe quedar en 0 errores).
+
+## Prohibido
+
+- Tareas sin archivo concreto o sin requisito (salvo `· Infra`).
+- Modificar la spec aprobada (si falta algo, vuelve a especificar y re-aprueba).
+- Prometer horas: estima talla y confianza, con supuestos.

package/workflow/phases/review.md

@@ -0,0 +1,28 @@
+---
+id: review
+title: Revisar
+description: >-
+  Revisión de código con lentes por tamaño del diff y verificación adversarial de hallazgos.
+  Usar cuando el usuario pide revisar el código antes del PR.
+requires:
+  - changes/<slug>/tasks.md
+produces:
+  - changes/<slug>/review.md
+arguments: true
+agent:
+  mode: primary
+---
+
+# Fase: Revisar (código)
+
+## Pasos
+
+1. Obtén el diff completo del cambio (`git diff` contra la rama base).
+2. Elige el nivel:
+   - Diff pequeño: una pasada con dos lentes: **corrección** (¿hace lo que dice la spec?) y **estándares** (perfil + constitución).
+   - Diff grande (> 400 líneas) o ruta sensible: tres lentes (corrección, seguridad, mantenibilidad) y un verificador adversarial.
+3. **Verificación adversarial**: cada hallazgo se intenta refutar contra el código real. Etiquetas:
+   - `CONFIRMADO` (evidencia `archivo:línea`), `RENUNCIADO` (no se pudo refutar: mantener severidad), `REFUTADO` (con evidencia).
+   - Nunca marcar `REFUTADO` sin `archivo:línea`.
+4. Escribe `.sdd/changes/{{SLUG}}/review.md`: hallazgos con severidad, evidencia, decisión y estado.
+5. Crítico confirmado = bloquea el PR hasta corregirlo o registrar un override con motivo, autor y fecha.

package/workflow/phases/specify.md

@@ -0,0 +1,51 @@
+---
+id: specify
+title: Especificar
+description: >-
+  Escribe o refina la especificación funcional de un cambio (delta) en lenguaje de negocio.
+  Usar cuando el usuario pide especificar, definir requisitos, redactar la spec o crear un cambio.
+requires: []
+produces:
+  - changes/<slug>/spec.md
+arguments: true
+agent:
+  mode: primary
+---
+
+# Fase: Especificar (spec funcional y de negocio)
+
+{{>reglas-negocio}}
+
+## Objetivo
+
+Escribir el delta de especificación del cambio `{{SLUG}}` en `.sdd/changes/{{SLUG}}/spec.md`.
+El contenido se escribe en **{{LANGUAGE_NAME}}**.
+
+## Pasos
+
+1. Lee `.sdd/constitution.md`, `.sdd/glossary.md` y las specs vivas de `.sdd/specs/**/spec.md` que toquen el dominio.
+2. Si hay código existente relacionado, inspecciónalo solo para entender el comportamiento actual (AS-IS); no lo describas con tecnología en la spec.
+3. Si falta información de negocio, **pregunta** (máximo 5 preguntas concretas) antes de escribir. No inventes reglas.
+4. Redacta el delta con las secciones canónicas:
+   - `## Requisitos agregados` (`ADDED`), `## Requisitos modificados` (`MODIFIED`), `## Requisitos eliminados` (`REMOVED`), `## Requisitos renombrados` (`RENAMED`).
+   - Cada requisito: `### Requisito: REQ-<DOMINIO>-NNN — Título` (ids inmutables), prosa de negocio, reglas `- Regla BR-<DOMINIO>-NNN: ...` y escenarios `#### Escenario: REQ-<DOMINIO>-NNN-S1 — Título` con `- **CUANDO** ...` / `- **ENTONCES** ...`.
+   - Incluye siempre escenarios de error, vacío, sin permiso y límites.
+   - `MODIFIED` copia el bloque **completo** del requisito tal como está en la spec viva y lo edita.
+   - `REMOVED` declara `- Motivo:` y `- Migración:`.
+5. Verifica con el CLI y corrige hasta que no haya errores:
+
+```
+satlas validate --change {{SLUG}}
+```
+
+6. Reporta: número de requisitos y escenarios, supuestos, y las preguntas que quedaron abiertas.
+
+## Prohibido
+
+- Nombres de tablas, campos, endpoints, clases, archivos, frameworks o librerías.
+- Adjetivos vagos ("rápido", "fácil", "varios", "robusto") sin un valor medible.
+- Renumerar ids existentes o reescribir un requisito aprobado sin pasar por `MODIFIED`/`REMOVED`.
+
+## Salida
+
+`changes/{{SLUG}}/spec.md` validado, más un resumen para el usuario y la indicación de que la spec debe aprobarse (`satlas approve`) antes de planificar.

package/workflow/phases/verify.md

@@ -0,0 +1,41 @@
+---
+id: verify
+title: Verificar
+description: >-
+  Registra evidencia real por escenario (comando y resultado) en verify.md.
+  Usar cuando el usuario pide verificar, probar o demostrar que el cambio funciona.
+requires:
+  - changes/<slug>/tasks.md
+produces:
+  - changes/<slug>/verify.md
+arguments: true
+agent:
+  mode: primary
+---
+
+# Fase: Verificar (evidencia por escenario)
+
+{{>evidencia}}
+
+## Pasos
+
+1. Lee el delta y lista **todos** los escenarios (`### Escenario: REQ-…-S1`).
+2. Para cada escenario elige el método más fuerte posible:
+   - `executable`: prueba automatizada, petición HTTP, script SQL, Playwright, emulador.
+   - `automatic`: comprobación mecánica (grep/inspección) sobre el resultado.
+   - `semi`: verificación asistida con revisión humana.
+   - `manual`: último recurso, con justificación.
+3. Ejecuta realmente el comando y captura la salida. Hash de la salida:
+
+```
+satlas hash "<salida o archivo>"   # (F1: satlas verify --record lo hará por ti)
+```
+
+4. Escribe en `.sdd/changes/{{SLUG}}/verify.md` un bloque `evidence` por escenario con el formato exacto.
+5. Comprueba que no queden huecos:
+
+```
+satlas trace --change {{SLUG}} --require-evidence
+```
+
+6. Reporta la tabla escenario → método → resultado y cualquier fallo encontrado (un fallo se corrige y se vuelve a verificar; no se marca como pasado).

package/workflow/snippets/evidencia.md

@@ -0,0 +1,21 @@
+## Formato de evidencia (bloques `evidence`)
+
+Un bloque por escenario en `verify.md`, con YAML válido:
+
+````markdown
+### REQ-DOMINIO-001-S1 — Título del escenario
+
+```evidence
+method: executable        # executable | automatic | semi | manual
+command: npm test -- modulo
+result: pass              # pass | fail | skipped
+output_hash: sha256:…     # hash de la salida (satlas hash)
+date: 2026-01-01T00:00:00Z
+by: tu-nombre
+notes: 12/12 casos
+```
+````
+
+- `executable` exige `command` y que el comando se haya ejecutado de verdad.
+- Un resultado `fail` bloquea el PR; se corrige y se registra de nuevo (nuevo bloque con la fecha nueva).
+- No hay evidencia sin comando cuando el método es `executable`, ni "terminado" sin evidencia.

package/workflow/snippets/reglas-negocio.md

@@ -0,0 +1,10 @@
+## Reglas de la especificación de negocio
+
+- Se escribe para el usuario del sistema, no para programadores.
+- Cada requisito declara **qué** y **por qué**, nunca **cómo**.
+- Vocabulario: el del glosario (`.sdd/glossary.md`). Si un término no existe, agrégalo al glosario o pregunta.
+- Prohibido: nombres de tablas, campos, endpoints, clases, archivos, frameworks, librerías, SQL, diagramas técnicos y estimaciones.
+- Prohibido: adjetivos no medibles ("rápido", "fácil", "varios", "óptimo", "robusto", "adecuado", "simple").
+- Cada escenario tiene un resultado observable y verificable (`ENTONCES` medible).
+- Todo requisito incluye escenarios de error, caso vacío, falta de permiso y límites.
+- Los ids `REQ-*` y `BR-*` son inmutables: no se renumeran ni se reutilizan.