@trycore/spec-build-harness 0.8.0 → 0.8.2

package/skills/setup-architecture/assets/adr-add.template.md

@@ -0,0 +1,84 @@
+---
+id: NNNN
+title: "<Título de la decisión>"
+date: YYYY-MM-DD
+status: proposed   # proposed | accepted | superseded | deprecated
+authors:
+  - <Equipo / persona>
+tags: []
+add:
+  iteracion: <n>
+  fase_prd: "<Fase X>"
+---
+
+# ADR NNNN — <Título>
+
+> Plantilla alineada al método **ADD** (Attribute-Driven Design, Len Bass — *Software Architecture in
+> Practice*). Cada sección numerada corresponde a un paso del método. Las decisiones deben trazar a
+> [0000-drivers-y-asrs.md](0000-drivers-y-asrs.md) y actualizar
+> [_backlog-arquitectonico.md](_backlog-arquitectonico.md). Generada por la skill `setup-architecture`
+> (`/build:architect`); un humano la promueve `proposed → accepted`.
+
+## 1. Objetivo de la iteración y drivers seleccionados (Pasos 2–3)
+
+- **Objetivo de la iteración:** <qué se busca resolver en esta ronda>.
+- **Elemento(s) a refinar:** <sistema completo | servicio X | módulo Y>.
+- **Drivers abordados:**
+  - Funcionales: UC-…
+  - Atributos de calidad: QA-… (con su medida de respuesta)
+  - Restricciones: CON-…
+  - Concerns: CRN-…
+
+## 2. Conceptos de diseño elegidos (Paso 4)
+
+> Patrones arquitectónicos, **tácticas** (sentido Bass), componentes externos o arquitecturas de
+> referencia evaluados y elegidos para satisfacer los drivers. Registra las alternativas descartadas:
+> ese es el valor del ADR.
+
+| Driver | Concepto / Táctica | Alternativas descartadas | Razón |
+|--------|--------------------|--------------------------|-------|
+| QA-… | … | … | … |
+
+## 3. Instanciación: responsabilidades e interfaces (Paso 5)
+
+> Cómo se convierten los conceptos en estructuras reales: componentes/módulos, sus responsabilidades y
+> los contratos (interfaces) por los que se comunican.
+
+- **Elementos instanciados:** …
+- **Responsabilidades:** …
+- **Interfaces / contratos:** …
+
+## 4. Vistas y registro de la decisión (Paso 6)
+
+> Boceto de vista(s) estructural(es) — de módulos, de componentes-y-conectores o de asignación física —
+> y el rationale + trade-offs.
+
+```mermaid
+%% vista estructural / de despliegue / de secuencia
+```
+
+**Decisión:** …
+
+**Trade-offs aceptados:** …
+
+## 5. Análisis del diseño (Paso 7)
+
+> ¿La decisión satisface el objetivo de la iteración? Cada driver con veredicto y evidencia/medida.
+
+| Driver | ¿Satisfecho? | Evidencia / medida | Riesgo residual |
+|--------|--------------|--------------------|-----------------|
+| QA-… | ✅/⚠️/❌ | … | … |
+
+**Drivers no resueltos en esta iteración:** … (se devuelven al backlog arquitectónico).
+
+## 6. Consecuencias
+
+- Positivas: …
+- Negativas / riesgos: …
+- Operacionales: …
+
+## 7. Trazabilidad
+
+- Drivers: [0000-drivers-y-asrs.md](0000-drivers-y-asrs.md)
+- PRD / HU / Flows: …
+- Stack operacionalizado en: `.claude/config/stack-allowlist.json` (si esta ADR decide stack)

package/skills/setup-architecture/references/add-method.md

@@ -0,0 +1,53 @@
+# Método ADD — iterar el diseño (Pasos 2–7) — referencia
+
+ADD (Attribute-Driven Design, Len Bass) diseña por **rondas**. Cada ronda ejecuta 7 pasos sobre un
+subconjunto priorizado de drivers del catálogo `0000`. Una ronda produce **un ADR** (a veces refactoriza
+uno previo). Usa la plantilla `assets/adr-add.template.md` de esta skill —instalada junto a estas
+references— (7 secciones = los 7 pasos, con su frontmatter `id/title/date/status/authors/tags/add`).
+
+## Los 7 pasos por iteración
+
+1. **Review inputs** — ya está en `0000-drivers-y-asrs.md`.
+2. **Establecer el objetivo de la iteración** — elige la fase/release y el subconjunto de drivers
+   (empieza por los ASRs críticos, cuadrante (A,A) de la matriz). → §1 del ADR.
+3. **Elegir el elemento a refinar** — sistema completo (primera ronda, top-down) o un módulo/servicio
+   interno (rondas posteriores). → §1 del ADR.
+4. **Elegir conceptos de diseño** — **tácticas** (Bass), **patrones**/estilos, componentes externos o
+   arquitecturas de referencia. Registra las **alternativas descartadas** y por qué. → §2 del ADR.
+5. **Instanciar** — convierte los conceptos en componentes/módulos reales con responsabilidades e
+   **interfaces/contratos**. → §3 del ADR.
+6. **Bocetar vistas y registrar la decisión** — al menos una vista (módulos, C&C o despliegue) en
+   `mermaid`, con la **decisión** y sus **trade-offs**. → §4 del ADR.
+7. **Analizar** (ATAM-lite) — cada driver con veredicto y evidencia; drivers no resueltos vuelven al
+   backlog. → §5 del ADR (delegado a `architecture-evaluator`; ver `atam-lite.md`).
+
+## Tácticas ↔ atributos (guía rápida, no exhaustiva)
+
+| Atributo (QA) | Tácticas típicas (Bass) | Estilos/patrones que las agrupan |
+|---|---|---|
+| Disponibilidad | redundancia, detección (heartbeat/ping), recuperación (rollback, reintento con backoff) | activo-pasivo, health-check, circuit breaker |
+| Rendimiento | gestión de recursos (índices, caché), gestión de demanda (paginación, rate-limit) | CQRS de lectura, caché-aside |
+| Seguridad | resistir (authN/authZ, secretos fuera de código), detectar (auditoría), recuperar | RBAC central, gateway de seguridad, WORM/SIEM |
+| Modificabilidad | encapsular, intermediario, restringir dependencias | capas, hexagonal/puertos-adaptadores, contrato OpenAPI como fuente |
+| Integrabilidad | adaptador, orquestación, límite (bulkhead) | adaptadores por integración, anti-corruption layer |
+| Escalabilidad | replicación, particionamiento, trabajo asíncrono | workers, colas, outbox |
+| Integridad transaccional | transacción, compensación (saga), idempotencia | saga orquestada + outbox |
+
+## Estrategia de iteración
+
+- **Ancho antes que profundo**: primera ronda decide el estilo estructural y el stack del **sistema
+  completo**; rondas posteriores refinan piezas (worker, motor de notificaciones, servicio de RBAC…).
+- **Cimiento primero**: las decisiones fundacionales (identidad/authN, acceso a datos, arquitectura base,
+  design-system) van en las primeras iteraciones — son las que el DoR exigirá antes de abrir épicas de
+  negocio (`layer: foundational`).
+- **Un ADR por decisión coherente**, no por archivo tocado. Si una decisión supersede a otra, marca la
+  vieja `superseded` y enlaza; no borres.
+- **Stack como decisión trazada**: las elecciones de lenguaje/framework/BD/infra son ADRs con su §2
+  (alternativas descartadas). En la fase 5 se consolidan en `stack-allowlist.json`. Si el stack elegido
+  **diverge** del PRD §técnica, regístralo explícitamente como riesgo/restricción (no lo escondas).
+
+## Salida por ronda
+
+1. Escribe `docs/adr/000N-<slug>.md` desde la plantilla, con §1–§4 completas.
+2. Corre `architecture-evaluator` sobre el ADR → completa §5 y §6.
+3. Actualiza `_backlog-arquitectonico.md`: estado de cada driver, riesgos nuevos, fila de bitácora.

package/skills/setup-architecture/references/atam-lite.md

@@ -0,0 +1,44 @@
+# ATAM-lite — evaluación de la arquitectura en papel (ADD Paso 7) — referencia
+
+Análisis de cada ADR **antes de programar**, para descubrir riesgos y trade-offs. Es una versión ligera
+de ATAM (Architecture Tradeoff Analysis Method): no se hace un taller formal con stakeholders, sino un
+barrido adversarial delegado en el agente `architecture-evaluator` (read-only). Alimenta §5/§6 del ADR y
+la sección de riesgos del backlog (estructura completa del backlog — tablero por driver, riesgos
+abiertos, bitácora — en `assets/_backlog-arquitectonico.template.md` de esta skill).
+
+## Qué produce el evaluador, por ADR
+
+- **Veredicto por driver**: para cada driver que el ADR dice satisfacer, ✅/⚠️/❌ con la **evidencia o
+  medida** que lo respalda (o la que falta). Un ⚠️/❌ es un riesgo, no un rechazo.
+- **Puntos de sensibilidad**: propiedades del diseño donde una decisión afecta fuertemente a un atributo
+  (p.ej. "el tamaño del pool de conexiones determina QA-1 rendimiento de lectura").
+- **Trade-offs**: puntos donde una decisión mejora un atributo y empeora otro (p.ej. "el backoff
+  1s/3s/9s da robustez pero puede exceder el P99 ≤ 10 s de la integración externa").
+- **Riesgos**: decisiones sin evidencia, drivers no cubiertos, supuestos sin validar. Cada uno con
+  driver, mitigación planificada e iteración.
+- **Drivers no resueltos**: se devuelven explícitamente al backlog (estado `PENDIENTE`/`EN DISEÑO`).
+
+## Conceptos ATAM que se usan
+
+- **Sensitivity point** — una decisión de la que depende crítica­mente una respuesta de calidad.
+- **Tradeoff point** — un sensitivity point que afecta a más de un atributo en direcciones opuestas.
+- **Risk** — una decisión (o su ausencia) que puede impedir alcanzar la medida de respuesta.
+- **Non-risk** — una decisión que, analizada, se confirma segura para los drivers en juego.
+
+## Reglas del análisis
+
+- **Adversarial y honesto**: el evaluador busca **refutar** que el ADR satisface sus drivers. Ante la
+  duda, marca riesgo, no lo omitas. Es más barato un riesgo en papel que un rediseño en código.
+- **Medida, no opinión**: un driver solo se marca ✅ si hay una medida verificable o un plan de
+  verificación (k6, prueba de carga, matriz de RBAC, etc.). "Parece suficiente" es ⚠️.
+- **No decide negocio**: si el riesgo se resuelve con una decisión de negocio (exponer o no un dato,
+  fijar o aplazar un objetivo de DR), lo marca como **trade-off de negocio** → sube a la revisión única
+  (fase 5), no lo resuelve el modelo.
+- **Cierre trazable**: al mitigar un riesgo en una iteración posterior, se marca ✅ CERRADO en el backlog
+  con el ADR que lo cerró; no se borra la fila.
+
+## Cobertura (invariante del backlog)
+
+Al cerrar la capa, **todo driver del 0000 debe tener estado ≥ ABORDADO** o un riesgo abierto explícito
+que explique por qué no. Un driver crítico (A,A) en `PENDIENTE` sin riesgo declarado es un fallo de la
+capa: no está lista para habilitar el build.

package/skills/setup-architecture/references/drivers-extraction.md

@@ -0,0 +1,39 @@
+# Extracción de drivers / ASRs (ADD Paso 1) — referencia
+
+Objetivo de la fase: producir `docs/adr/0000-drivers-y-asrs.md` **leyendo `docs/`** (solo lectura),
+sobre la plantilla `assets/0000-drivers-y-asrs.template.md` de esta skill (frontmatter + §1–§7). Se
+delega el barrido a `asr-extractor` (fan-out) y la sesión principal consolida. Un **ASR**
+(Architecturally Significant Requirement) es un requisito que, si cambia, cambia la arquitectura.
+
+## De dónde sale cada bloque del 0000
+
+| Bloque del 0000 | Fuente en `docs/` | Cómo derivarlo |
+|---|---|---|
+| **OE** (objetivos de negocio) | `01-prd/` §objetivos, `02-user-story-map/` | Copiar los objetivos específicos + su métrica/meta. Si el PRD no da métrica, proponerla y marcarla como *a validar*. |
+| **UC** (funcionales significativos) | `03-backlog/epicas.md`, `04-historias/HU-*.md` | **Solo** los casos que moldean la arquitectura (integraciones externas, transaccionalidad, RBAC, asincronía, auditoría). No es el backlog completo. |
+| **QA** (escenarios de calidad) | PRD §requisitos no funcionales, AC de las HUs, §técnica | Un escenario de **6 partes** por atributo (rendimiento, disponibilidad, seguridad, integrabilidad, modificabilidad, observabilidad, escalabilidad…). La **medida** debe ser cuantificable. |
+| **CON** (restricciones) | PRD §técnica/§7, política de datos, identidad | Lo que **no** es negociable (stack impuesto, prohibiciones, headers, gates de CI). |
+| **CRN** (concerns) | PRD riesgos, capacidades del equipo, costos | Preocupaciones que condicionan el diseño aunque no sean requisitos formales. |
+| **Prioridad** | juicio + importancia del PRD | Par `(Importancia de negocio, Impacto arquitectónico)` en {A,M,B}. El cuadrante (A,A) son los **ASRs críticos**. |
+| **Plan de iteraciones** | fases del PRD / líneas de release del story map | Una iteración por fase; lista los drivers que ataca cada una. |
+
+## Escenario QA de 6 partes (formato Bass)
+
+Cada QA-N se escribe con exactamente estas seis partes:
+
+- **Fuente** del estímulo (quién/qué lo genera)
+- **Estímulo** (el evento)
+- **Artefacto** (qué parte del sistema recibe el estímulo)
+- **Entorno** (condiciones: normal, pico, degradado)
+- **Respuesta** (qué hace el sistema)
+- **Medida de respuesta** (cuantificable: P95 ≤ X ms, uptime ≥ X%, 0 incidentes…)
+
+Sin medida cuantificable no es un ASR: es un deseo. Si el PRD no la da, **propón** una razonable y déjala
+marcada para validación en la revisión (fase 5), no bloquees.
+
+## Reglas
+
+- **Traza siempre**: cada UC/QA cita las HU/OE/§PRD de las que sale (columna Trazabilidad).
+- **No inventes dominio**: si un atributo no tiene sustento en `docs/`, no lo agregues; si es un hueco
+  real (p.ej. el PRD no fija disponibilidad), decláralo como CRN o riesgo, no como QA fabricado.
+- **Documento vivo**: en re-corridas, añade drivers nuevos de HUs/épicas nuevas; no borres los previos.

package/docs/flujo-harness-funcional.md

@@ -1,42 +0,0 @@
-# Cómo trabaja el arnés — flujo funcional
-
-Vista única y sencilla del flujo de trabajo, para explicar a los devs **qué pasa con cada cambio**.
-(Versión detallada/técnica en [flujo-harness.md](./flujo-harness.md).)
-
-```mermaid
-flowchart TD
-    A([Llega un trabajo]) --> B{"¿Qué tipo de cambio es?"}
-
-    B -->|"Arreglo pequeño<br/>(typo, copy, config)"| C["Carril rápido:<br/>rama → cambio → PR"]
-    C --> Z([PR listo para mergear])
-
-    B -->|"Funcionalidad nueva<br/>(una épica)"| D{"¿Está lista para construir?<br/>historias claras, criterios definidos,<br/>base ya construida"}
-    D -->|"No"| E["Vuelve a discovery<br/>a completar la historia"]
-    D -->|"Sí"| F["Construir con pruebas<br/>(escribo el test, luego el código)"]
-
-    F --> G{"¿La app funciona<br/>de punta a punta?"}
-    G -->|"No"| F
-    G -->|"Sí"| H["Revisión final del cambio<br/>+ pantallas iguales al diseño (si hay UI)"]
-
-    H --> I["Abrir PR y dejar todo enlazado<br/>(historia ↔ cambio ↔ código)"]
-    I --> J{"¿Esta épica cierra<br/>una entrega/release?"}
-
-    J -->|"No, sigue otra épica"| A
-    J -->|"Sí"| K["Revisión profunda de la entrega:<br/>seguridad · calidad · UX ·<br/>coherencia · arquitectura"]
-
-    K --> L{"¿Todo el journey completo<br/>funciona con dependencias reales?"}
-    L -->|"No, hay hallazgos"| M["Corregir como un cambio normal"]
-    M --> K
-    L -->|"Sí"| N([Release lista ✅])
-
-    classDef q fill:#fff3cd,stroke:#d39e00,color:#000;
-    classDef ok fill:#d4edda,stroke:#155724,color:#000;
-    class B,D,G,J,L q;
-    class N,Z ok;
-```
-
-## La idea en una frase
-
-- **Cambios chicos** van por un carril rápido.
-- **Cada funcionalidad nueva** se construye completa, con pruebas, verificando que la app **funcione de punta a punta** antes de cerrarla.
-- **De vez en cuando** (al cerrar una entrega) se hace una **revisión profunda** de todo lo acumulado antes de liberar.

package/docs/flujo-harness.md

@@ -1,192 +0,0 @@
-# Flujo del arnés de construcción — `@trycore/spec-build-harness`
-
-Diagrama de flujo end-to-end del harness, modelado al estilo BPMN:
-
-- **◆ XOR** (rombo) = compuerta **exclusiva** (un solo camino).
-- **⬡ AND** (hexágono) = compuerta **paralela** (fork: todos los caminos; join: convergencia/barrera).
-- **▭ Tarea** con su **gate** entre `[ ]`.
-- Aristas punteadas `-.->` = retroceso (gate monótono que vuelve a `false`).
-
-Fuente de verdad: [METODOLOGIA.md](../METODOLOGIA.md). Si algo contradice ese documento, gana la metodología.
-
----
-
-## 1. Vista global (router → inner loop → outer loop)
-
-```mermaid
-flowchart TD
-    START([Trabajo entrante]) --> PRE{{"⬡ Preflight<br/>¿instalado?"}}
-    PRE -->|NOT_INSTALLED| INIT[trycore-build init] --> ROUTER
-    PRE -->|ok| ROUTER
-
-    ROUTER[/"/build:work — Router (classify-and-act)<br/>solo ruteo: no toca estado ni ramas"/]
-    ROUTER --> GW1{"◆ XOR — Decision gate<br/>¿qué carril?"}
-
-    %% --- Rama 1: micro-change ---
-    GW1 -->|"mantenimiento<br/>sin capacidad nueva"| HARD{"◆ XOR — ¿cruza límite duro?<br/>dep nueva / API nueva / dominio·datos"}
-    HARD -->|"sí → escala"| INNER
-    HARD -->|no| MICRO["building-a-micro-change<br/>fix/* | chore/* → cambio → PR<br/>(sin abrir active_slice)"]
-    MICRO --> ENDM([PR mergeado])
-
-    %% --- Rama 2: épica / producto nuevo ---
-    GW1 -->|"capacidad nueva<br/>o límite duro"| INNER[["INNER LOOP<br/>building-a-slice<br/>(ver §2)"]]
-
-    %% --- Rama 3: release gate ---
-    GW1 -->|"cierra línea de release<br/>o ≥2 épicas archivadas"| OUTER[["OUTER LOOP<br/>releasing-a-version<br/>(ver §3)"]]
-
-    INNER --> DEC{"◆ XOR — fase 8<br/>¿correr Release Gate ahora?<br/>(default computado, decide humano)"}
-    DEC -->|"sí (cierra release<br/>o nudge ≥2)"| OUTER
-    DEC -->|no| NEXT([Siguiente épica]) -.-> INNER
-
-    OUTER --> OUTGW{"◆ XOR — ¿todos los gates ✓?"}
-    OUTGW -->|"passed"| REL([Release lista])
-    OUTGW -->|"failed (hallazgos)"| FIX["Fix como slice normal<br/>(building-a-slice)"] -.->|re-corre| OUTER
-
-    classDef xor fill:#fff3cd,stroke:#d39e00,color:#000;
-    classDef andg fill:#d1ecf1,stroke:#0c5460,color:#000;
-    classDef loop fill:#e2e3f3,stroke:#383d6b,color:#000;
-    class GW1,HARD,DEC,OUTGW xor;
-    class PRE andg;
-    class INNER,OUTER loop;
-```
-
----
-
-## 2. Inner loop — `building-a-slice` (pipeline secuencial por épica)
-
-Precondición dura: **scaffold confirmado** (`scaffold.confirmed`) antes de abrir cualquier slice.
-Secuencial (un `active_slice` a la vez), divulgación progresiva, ningún gate se salta.
-
-```mermaid
-flowchart TD
-    S0([Épica EP-XXX entrante]) --> SCAF{"◆ XOR — gate proyecto<br/>scaffold.confirmed?"}
-    SCAF -->|"false"| STOPS["STOP — exige scaffold runnable<br/>(scaffold-guard.sh)"]
-    SCAF -->|"true"| F1
-
-    %% Fase 1: DoR
-    F1["F1 · dor — Definition of Ready<br/>delega: dor-dod-gatekeeper"]
-    F1 --> DORGW{"◆ XOR — ¿DoR ✓?<br/>épica+HU, AC G/W/T, INVEST,<br/>cimiento, tamaño, stack, fixtures"}
-    DORGW -->|"✗"| BACKDISC["Vuelve a discovery<br/>(/trycore:*) — no se abre slice"]
-    DORGW -->|"✓ [gate: dor]"| SIZE{"◆ XOR — gate tamaño<br/>>3 HU ó ≥3 capas?"}
-
-    SIZE -->|"sí"| SUB["Descompone en sub_slices[]<br/>se construyen de a uno<br/>(journey_smoke verde entre cada uno)"]
-    SIZE -->|"no (atómica)"| F2
-    SUB --> F2
-
-    %% Fase 2: change
-    F2["F2 · change — opsx:new + ## Trazabilidad<br/>delega: change-epic-coherence"]
-    F2 --> F2GW{"◆ XOR — ¿enlace change↔épica ✓?"}
-    F2GW -->|"✓ [gate: coherence_link]"| F3
-    F2GW -.->|"✗ retroceso"| F2
-
-    %% Fase 3: TDD
-    F3["F3 · red→green→refactor<br/>TDD por cada escenario AC de cada HU<br/>delega: superpowers:test-driven-development"]
-    F3 --> F3GW{"◆ XOR — ¿suite verde?"}
-    F3GW -.->|"✗ retroceso"| F3
-    F3GW -->|"✓ [gate: tdd]"| F4
-
-    %% Fase 4: smoke + fidelity (UI)
-    F4["F4 · smoke — journey-hasta-aquí end-to-end<br/>runner determinista fuera-de-chat (sesión virgen)"]
-    F4 --> UIGW{"◆ XOR — ¿la épica toca UI?"}
-    UIGW -->|"no"| F4OUT["fidelity = null"]
-    UIGW -->|"sí"| FID["Verificación visual real (MCP chrome-devtools)<br/>screenshot app vs prototipo<br/>delega: ux-fidelity-reviewer"]
-    FID --> FIDGW{"◆ XOR — ¿fidelidad ESTRICTA ✓?<br/>INCONCLUSO = false"}
-    FIDGW -.->|"✗ → false"| FID
-    FIDGW -->|"✓ [gate: fidelity]"| F4OUT
-    F4OUT -->|"[gate: journey_smoke]"| F5FORK
-
-    %% Fase 5: api / data en paralelo (condicional/null)
-    F5FORK{{"⬡ AND — fork (fase api/data)"}}
-    F5FORK --> APIB["api — contratos endpoints<br/>Newman 100% (delega: api-contract-tester)<br/>null si no hay endpoints"]
-    F5FORK --> DATAB["data — invariantes de datos<br/>(delega: data-consistency-checker)<br/>N/A si no toca datos"]
-    APIB --> F5JOIN
-    DATAB --> F5JOIN
-    F5JOIN{{"⬡ AND — join (convergencia)<br/>[gates: api, data]"}}
-
-    %% Fase 6: dod — adversarial THEN dod
-    F5JOIN --> WIRE["F6a · Verificación ADVERSARIAL independiente<br/>(subagente contexto virgen)<br/>asume slice incompleto e intenta refutarlo<br/>delega: wiring-adversarial-verifier"]
-    WIRE --> WIREGW{"◆ XOR — ¿wiring_checklist[] sin items failing?"}
-    WIREGW -.->|"✗ huecos (stub/ruta/AC sin test)"| F3
-    WIREGW -->|"✓ [gate: wiring_verified]"| DOD["F6b · DoD reducido<br/>delega: dor-dod-gatekeeper<br/>(piso declarativo, no el arreglo)"]
-    DOD --> DODGW{"◆ XOR — ¿DoD ✓?<br/>tdd·journey_smoke·coherence_link·<br/>data·api·fidelity·wiring_verified·hooks"}
-    DODGW -.->|"✗ retroceso"| F3
-    DODGW -->|"✓ [gate: dod]"| F7
-
-    %% Fase 7: PR + archive
-    F7["F7 · pr — abrir PR + archivar change EN EL MISMO PR<br/>opsx:archive + opsx:sync<br/>back-reference en épica y HU"]
-    F7 --> ARCH["active_slice → history[] (phase: archived)<br/>active_slice = null"]
-    ARCH --> F8([F8 · decisión Release Gate → §1])
-
-    classDef xor fill:#fff3cd,stroke:#d39e00,color:#000;
-    classDef andg fill:#d1ecf1,stroke:#0c5460,color:#000;
-    classDef stop fill:#f8d7da,stroke:#842029,color:#000;
-    class SCAF,DORGW,SIZE,F2GW,F3GW,UIGW,FIDGW,WIREGW,DODGW xor;
-    class F5FORK,F5JOIN andg;
-    class STOPS,BACKDISC stop;
-```
-
-> **Disciplina de horizonte largo:** cada iteración nace headless / contexto virgen y reconstruye estado
-> desde disco (`build-state.json` + git + logs). `wiring_checklist[]` (1 item por escenario AC y por punto
-> de integración entre capas) nace `failing` y solo pasa a `passing` **tras prueba real ejecutada**.
-> Mientras quede un item `failing`, el cableado NO está hecho.
-
----
-
-## 3. Outer loop — `releasing-a-version` (Release Gate)
-
-Alcance = **diff acumulado** de todas las épicas de la release (merge anterior → `main`).
-Los reviewers se disparan **en paralelo** y devuelven síntesis (protegen el contexto).
-
-```mermaid
-flowchart TD
-    R0([Línea de release identificada]) --> R1["Crear/actualizar releases[] (status: pending)<br/>cruzar con docs/02-user-story-map/"]
-    R1 --> FORK{{"⬡ AND — fork (reviewers en paralelo<br/>sobre el diff acumulado)"}}
-
-    FORK --> SEC["security — sin CRÍTICO/ALTO;<br/>claves server-side; PII no cruda;<br/>salida IA = input no confiable<br/>(security-reviewer)"]
-    FORK --> SME["smell — 4 reglas de Beck<br/>+ code smells sin bloqueantes<br/>(simple-design-reviewer)"]
-    FORK --> UX["ux — Krug + Lighthouse<br/>(null si sin UI)<br/>(ux-krug-reviewer)"]
-    FORK --> COH["coherence — trazabilidad triple<br/>AC↔change↔código, sin huérfanos<br/>(coherence-three-way · opus)"]
-    FORK --> ARCH["stack_arch — arquitectura PRD:<br/>capa IA en frontera server-side;<br/>decisión determinista sin IA<br/>(stack-guardian)"]
-
-    SEC --> JOIN
-    SME --> JOIN
-    UX --> JOIN
-    COH --> JOIN
-    ARCH --> JOIN
-
-    JOIN{{"⬡ AND — join (convergencia de reviewers)"}}
-    JOIN --> INTEG["integration — journey COMPLETO end-to-end<br/>con DEPENDENCIAS REALES (no stubs)<br/>skill verify/run + MCP chrome-devtools"]
-
-    INTEG --> RGW{"◆ XOR — ¿todos los gates ✓ (o null N/A)?"}
-    RGW -->|"✓"| PASS["status: passed<br/>escribir gates + updated_by: releasing-a-version"]
-    RGW -->|"✗ hallazgos bloqueantes"| FAIL["status: failed"]
-    PASS --> RELOK([Release ✅])
-    FAIL --> FIXLOOP["Humano corrige como slice normal<br/>(building-a-slice)"]
-    FIXLOOP -.->|"re-corre Release Gate"| R1
-
-    classDef xor fill:#fff3cd,stroke:#d39e00,color:#000;
-    classDef andg fill:#d1ecf1,stroke:#0c5460,color:#000;
-    classDef gate fill:#d4edda,stroke:#155724,color:#000;
-    class RGW xor;
-    class FORK,JOIN andg;
-    class INTEG gate;
-```
-
-> **`integration` es el gate no negociable.** Sin journey completo con dependencias reales **no hay release**.
-> No se acepta con todo stubbeado.
-
----
-
-## 4. Leyenda de loops y gates
-
-| | Inner loop | Outer loop |
-|---|---|---|
-| Skill | `building-a-slice` | `releasing-a-version` |
-| Unidad | una épica `EP-XXX` | una línea de release |
-| Cadencia | muchas (1 por épica) | pocas (1 por release) |
-| Costo | barato (≤ ~20 min/épica) | pesado (subagentes profundos) |
-| Gates | dor · coherence_link · tdd · journey_smoke · fidelity · api · data · wiring_verified · dod | security · smell · ux · coherence · stack_arch · integration |
-| Estado | `active_slice` + `history[]` | `releases[]` |
-
-**Regla de no duplicación:** cada gate vive en exactamente un loop. El outer no hace TDD ni gates por slice;
-el inner no dispara reviewers pesados.