@trycore/spec-build-harness 0.1.0

package/skills/openspec-verify-change/SKILL.md

@@ -0,0 +1,168 @@
+---
+name: openspec-verify-change
+description: Verify implementation matches change artifacts. Use when the user wants to validate that implementation is complete, correct, and coherent before archiving.
+license: MIT
+compatibility: Requires openspec CLI.
+metadata:
+  author: openspec
+  version: "1.0"
+  generatedBy: "1.0.2"
+---
+
+Verify that an implementation matches the change artifacts (specs, tasks, design).
+
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run `openspec list --json` to get available changes. Use the **AskUserQuestion tool** to let the user select.
+
+   Show changes that have implementation tasks (tasks artifact exists).
+   Include the schema used for each change if available.
+   Mark changes with incomplete tasks as "(In Progress)".
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Check status to understand the schema**
+   ```bash
+   openspec status --change "<name>" --json
+   ```
+   Parse the JSON to understand:
+   - `schemaName`: The workflow being used (e.g., "spec-driven")
+   - Which artifacts exist for this change
+
+3. **Get the change directory and load artifacts**
+
+   ```bash
+   openspec instructions apply --change "<name>" --json
+   ```
+
+   This returns the change directory and context files. Read all available artifacts from `contextFiles`.
+
+4. **Initialize verification report structure**
+
+   Create a report structure with three dimensions:
+   - **Completeness**: Track tasks and spec coverage
+   - **Correctness**: Track requirement implementation and scenario coverage
+   - **Coherence**: Track design adherence and pattern consistency
+
+   Each dimension can have CRITICAL, WARNING, or SUGGESTION issues.
+
+5. **Verify Completeness**
+
+   **Task Completion**:
+   - If tasks.md exists in contextFiles, read it
+   - Parse checkboxes: `- [ ]` (incomplete) vs `- [x]` (complete)
+   - Count complete vs total tasks
+   - If incomplete tasks exist:
+     - Add CRITICAL issue for each incomplete task
+     - Recommendation: "Complete task: <description>" or "Mark as done if already implemented"
+
+   **Spec Coverage**:
+   - If delta specs exist in `openspec/changes/<name>/specs/`:
+     - Extract all requirements (marked with "### Requirement:")
+     - For each requirement:
+       - Search codebase for keywords related to the requirement
+       - Assess if implementation likely exists
+     - If requirements appear unimplemented:
+       - Add CRITICAL issue: "Requirement not found: <requirement name>"
+       - Recommendation: "Implement requirement X: <description>"
+
+6. **Verify Correctness**
+
+   **Requirement Implementation Mapping**:
+   - For each requirement from delta specs:
+     - Search codebase for implementation evidence
+     - If found, note file paths and line ranges
+     - Assess if implementation matches requirement intent
+     - If divergence detected:
+       - Add WARNING: "Implementation may diverge from spec: <details>"
+       - Recommendation: "Review <file>:<lines> against requirement X"
+
+   **Scenario Coverage**:
+   - For each scenario in delta specs (marked with "#### Scenario:"):
+     - Check if conditions are handled in code
+     - Check if tests exist covering the scenario
+     - If scenario appears uncovered:
+       - Add WARNING: "Scenario not covered: <scenario name>"
+       - Recommendation: "Add test or implementation for scenario: <description>"
+
+7. **Verify Coherence**
+
+   **Design Adherence**:
+   - If design.md exists in contextFiles:
+     - Extract key decisions (look for sections like "Decision:", "Approach:", "Architecture:")
+     - Verify implementation follows those decisions
+     - If contradiction detected:
+       - Add WARNING: "Design decision not followed: <decision>"
+       - Recommendation: "Update implementation or revise design.md to match reality"
+   - If no design.md: Skip design adherence check, note "No design.md to verify against"
+
+   **Code Pattern Consistency**:
+   - Review new code for consistency with project patterns
+   - Check file naming, directory structure, coding style
+   - If significant deviations found:
+     - Add SUGGESTION: "Code pattern deviation: <details>"
+     - Recommendation: "Consider following project pattern: <example>"
+
+8. **Generate Verification Report**
+
+   **Summary Scorecard**:
+   ```
+   ## Verification Report: <change-name>
+
+   ### Summary
+   | Dimension    | Status           |
+   |--------------|------------------|
+   | Completeness | X/Y tasks, N reqs|
+   | Correctness  | M/N reqs covered |
+   | Coherence    | Followed/Issues  |
+   ```
+
+   **Issues by Priority**:
+
+   1. **CRITICAL** (Must fix before archive):
+      - Incomplete tasks
+      - Missing requirement implementations
+      - Each with specific, actionable recommendation
+
+   2. **WARNING** (Should fix):
+      - Spec/design divergences
+      - Missing scenario coverage
+      - Each with specific recommendation
+
+   3. **SUGGESTION** (Nice to fix):
+      - Pattern inconsistencies
+      - Minor improvements
+      - Each with specific recommendation
+
+   **Final Assessment**:
+   - If CRITICAL issues: "X critical issue(s) found. Fix before archiving."
+   - If only warnings: "No critical issues. Y warning(s) to consider. Ready for archive (with noted improvements)."
+   - If all clear: "All checks passed. Ready for archive."
+
+**Verification Heuristics**
+
+- **Completeness**: Focus on objective checklist items (checkboxes, requirements list)
+- **Correctness**: Use keyword search, file path analysis, reasonable inference - don't require perfect certainty
+- **Coherence**: Look for glaring inconsistencies, don't nitpick style
+- **False Positives**: When uncertain, prefer SUGGESTION over WARNING, WARNING over CRITICAL
+- **Actionability**: Every issue must have a specific recommendation with file/line references where applicable
+
+**Graceful Degradation**
+
+- If only tasks.md exists: verify task completion only, skip spec/design checks
+- If tasks + specs exist: verify completeness and correctness, skip design
+- If full artifacts: verify all three dimensions
+- Always note which checks were skipped and why
+
+**Output Format**
+
+Use clear markdown with:
+- Table for summary scorecard
+- Grouped lists for issues (CRITICAL/WARNING/SUGGESTION)
+- Code references in format: `file.ts:123`
+- Specific, actionable recommendations
+- No vague suggestions like "consider reviewing"

package/skills/releasing-a-version/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: releasing-a-version
+description: Use when closing a release of the product — runs the heavy review gates ONCE over the accumulated diff of a release line (security, design/smell, UX/Krug, three-way coherence, architecture, and full end-to-end integration with real deps), instead of per epic. This is the outer loop; the per-epic inner loop lives in building-a-slice. Trigger after archiving an epic when the user accepts the Release Gate, or when a Story Map release line is complete. Records results in build-state.json releases[].
+---
+
+# Release Gate (outer loop) — Build
+
+El **outer loop** del arnés. Mientras `building-a-slice` (inner loop) construye épica a épica de
+forma barata y rápida, esta skill ejecuta las **revisiones profundas una sola vez por release**,
+sobre el **diff acumulado** de todas las épicas de esa release. Así el costo de los agentes pesados
+pasa de `O(épicas)` a `O(releases)`.
+
+## Qué es una release
+Una **línea de release del Story Map** (`docs/02-user-story-map/`). P.ej. **R1-mvp** = EP-001 +
+EP-002 + EP-003 + EP-004 ("Resolver un caso de punta a punta con resultado explicable"). El conjunto
+de épicas de la release son las que vas a auditar en bloque.
+
+## Cuándo se invoca
+- Tras archivar una épica, `building-a-slice` pregunta con un default computado y el usuario acepta.
+- O explícitamente: "corre el Release Gate de R1".
+
+## Principio de operación
+- **Una sola fuente de verdad**: `.claude/state/build-state.json` → array `releases[]`. Lee antes,
+  escribe una entrada por release.
+- **Sobre el diff acumulado**: el alcance es el rango de commits de todas las épicas de la release
+  (desde el merge anterior a la primera épica de la release hasta `main`).
+- **Delega en subagentes** (devuelven síntesis, protegen el contexto).
+
+## Pipeline del Release Gate
+
+| Gate | Acción | Delega en | Referencia |
+|---|---|---|---|
+| `security` | Vectores generales + foco de dominio del consumidor (PII/secretos/authz, claves de servicios externos server-side) sobre todo el diff | `security-reviewer` | — |
+| `smell` | 4 reglas de Beck + code smells sobre el diff acumulado | `simple-design-reviewer` | `building-a-slice/references/simple-design.md` |
+| `ux` | Krug + lighthouse sobre la UI ensamblada de la release (o `null` si sin UI) | `ux-krug-reviewer` | `building-a-slice/references/krug-ux.md` |
+| `coherence` | Trazabilidad triple AC↔change↔código de **todas** las HU de la release | `coherence-three-way` | — |
+| `stack_arch` | Arquitectura del PRD del consumidor (capa de servicios externos en la frontera declarada, capa de decisión determinista del dominio sin IA) | `stack-guardian` | — |
+| `integration` | Recorrer el **journey completo** de la release con **deps reales** del proyecto, no stubs | skill `verify` / `run` (+ MCP chrome-devtools) | `release-dod.md` |
+
+Checklist de cierre: `references/release-dod.md`.
+
+## Cómo proceder
+1. Lee `build-state.json`; identifica la release y sus épicas (cruza con `docs/02-user-story-map/`).
+2. Crea/actualiza la entrada en `releases[]` con `status: pending`.
+3. Dispara los subagentes **en paralelo** sobre el diff acumulado (devuelven síntesis).
+4. Corre el gate de **integración** con la skill `verify`/`run`: el journey completo, deps reales.
+5. Cuando todos los gates pasan (o `null` cuando N/A) → `status: passed`, escribe los `gates` y
+   `updated_by: releasing-a-version`. Si algo falla → `status: failed` y lista los hallazgos
+   bloqueantes; el usuario los corrige como un slice normal (fix en `building-a-slice`) y se
+   re-corre el Release Gate.
+
+## Reglas duras
+- **No dupliques el inner loop.** Aquí no se hace TDD ni se cierran gates por slice.
+- **Integración con deps reales es obligatoria** para `status: passed` — es el gate que faltaba y
+  por el que el producto "no funcionaba al terminar". No se acepta con todo stubbeado.
+- Si una regla aquí contradice la metodología Trycore (`METODOLOGIA.md`), **gana la metodología**.

package/skills/releasing-a-version/references/release-dod.md

@@ -0,0 +1,20 @@
+# Release Gate — checklist de salida (outer loop)
+
+Una **release** (línea de release del Story Map) no se da por cerrada hasta cumplir TODO esto. Se
+corre **una vez** sobre el diff acumulado de todas sus épicas. Resultado en `build-state.json` →
+`releases[]`.
+
+- [ ] **`security`** — `security-reviewer` sin hallazgos CRÍTICO/ALTO sobre el diff completo de la release; claves de servicios externos solo server-side; datos sensibles / PII regulados (según el PRD del consumidor) no persistidos crudos; salida de cualquier servicio externo/IA tratada como input no confiable y validada contra esquema antes de alimentar la capa de decisión.
+- [ ] **`smell`** — `simple-design-reviewer` sin bloqueantes sobre el diff acumulado; 4 reglas de Beck respetadas.
+- [ ] **`ux`** — `ux-krug-reviewer` ok sobre la UI ensamblada (o `null` si la release no tiene UI). Lighthouse/accesibilidad si la app corre.
+- [ ] **`coherence`** — `coherence-three-way` confirma trazabilidad AC↔change↔código de **todas** las HU de **todas** las épicas de la release, sin huérfanos.
+- [ ] **`stack_arch`** — `stack-guardian` confirma la arquitectura del PRD del consumidor: la capa de servicios externos/IA en la frontera declarada server-side (no decide), la capa de decisión determinista del dominio sin IA, sin claves de servicios externos en cliente.
+- [ ] **`integration`** — el **journey completo** de la release se recorre end-to-end con **dependencias reales** del proyecto (servicios externos/IA y capa de decisión reales, según el PRD del consumidor), no stubs. Verificado con la skill `verify`/`run` (+ MCP `chrome-devtools`).
+
+**Todo ✓ (o `null` cuando N/A)** → `releases[].status: "passed"`, escribe `gates` y `updated_by:
+releasing-a-version`. **Algo ✗** → `status: "failed"`, lista hallazgos bloqueantes; se corrigen como
+un slice normal en `building-a-slice` y se re-corre el Release Gate.
+
+> El gate `integration` es el que faltaba en la era anterior: todos los gates por-slice estaban en
+> verde y aun así el producto no caminaba de punta a punta. Sin `integration` con deps reales no hay
+> release.

package/state/README.md

@@ -0,0 +1,56 @@
+# Estado del arnés de construcción (`build-state.json`)
+
+`build-state.json` es la **única fuente de verdad** del slice (épica) en construcción y el medio por
+el que los agentes se sincronizan en modo **secuencial**. La unidad de construcción es la **épica
+(`EP-XXX`)**; las HU que cubre el change se listan en `hus[]` (trazabilidad al alcance interno).
+Cada gate del pipeline transiciona el estado; el siguiente agente lo lee antes de actuar.
+
+- **Esquema**: `build-state.schema.json` (versionado, draft 2020-12). Valida con:
+  ```bash
+  # Recomendado (funciona sin plugins de formato):
+  python3 -c "import jsonschema,json; jsonschema.Draft202012Validator(json.load(open('.claude/state/build-state.schema.json'))).validate(json.load(open('.claude/state/build-state.json'))); print('OK')"
+  # Alternativa con ajv (requiere spec + formatos):
+  npx --yes ajv-cli@5 validate --spec=draft2020 -c ajv-formats -s .claude/state/build-state.schema.json -d .claude/state/build-state.json
+  ```
+- **No versionar el estado vivo**: `build-state.json` está en `.gitignore` (working state). El
+  schema y este README sí se versionan.
+
+## Protocolo de lectura/escritura
+
+1. **Leer antes de actuar.** Todo agente del pipeline lee `active_slice` y `gates` antes de
+   trabajar. Si `active_slice` es `null`, no hay slice en curso → solo `dor-dod-gatekeeper` puede
+   abrir uno.
+2. **Una sola escritura por transición.** Quien completa una fase actualiza `phase`, el gate
+   correspondiente, `updated_at` (ISO 8601 UTC) y `updated_by` (su nombre). No tocar otros campos.
+3. **Gates monótonos hacia adelante.** Un gate solo pasa de `false`→`true` cuando su agente lo
+   aprueba. Si una revisión posterior falla, se vuelve a `false` y `phase` retrocede.
+4. **`ux`/`api` admiten `null`** cuando el slice no tiene UI o endpoints (N/A, no bloquea DoD).
+5. **Archivar**: al completar `opsx:archive`, mover el `active_slice` a `history[]` con
+   `phase: "archived"` y dejar `active_slice: null`.
+6. **Dos loops**: el slice (inner loop) cierra gates baratos por épica; los gates pesados viven en
+   `releases[]` (outer loop), que escribe la skill `releasing-a-version` una vez por release.
+
+## Ciclo de fases
+
+**Inner loop (por slice):**
+```
+dor → change → red → green → refactor → smoke → api → data → dod → pr → archived
+```
+Luego se pregunta el **Release Gate** (outer loop, skill `releasing-a-version`) con default
+computado desde las líneas de release del Story Map.
+
+`harness_phase` arranca en `authoring` y lo cambia `load-build-state.sh` a `active` cuando
+detecta `package.json` en la raíz (aparición del scaffold Next.js).
+
+## Quién escribe qué
+
+| Campo / gate | Lo escribe | Cadencia |
+|---|---|---|
+| `active_slice` (alta) · `gates.dor` · `gates.dod` | `dor-dod-gatekeeper` | slice |
+| `gates.coherence_link` | `change-epic-coherence` | slice |
+| `gates.tdd` | flujo `superpowers:test-driven-development` (vía `build-orchestrator`) | slice |
+| `gates.journey_smoke` · `phase` (transiciones) · `history[]` (archivado) | `build-orchestrator` | slice |
+| `gates.api` | `api-contract-tester` | slice |
+| `gates.data` | `data-consistency-checker` | slice |
+| `releases[]` (`security`, `smell`, `ux`, `coherence`, `stack_arch`, `integration`, `status`) | `releasing-a-version` (delega en `security-reviewer`, `simple-design-reviewer`, `ux-krug-reviewer`, `coherence-three-way`, `stack-guardian`) | release |
+| `harness_phase` | `load-build-state.sh` (SessionStart) | — |

package/state/build-state.schema.json

@@ -0,0 +1,111 @@
+{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "$id": "https://trycore.com/spec-build-harness/build-state.schema.json",
+  "title": "Build Harness State",
+  "description": "Single source of truth para el handoff secuencial entre agentes de construcción. Lo escriben build-orchestrator y los gates; lo lee load-build-state.sh.",
+  "type": "object",
+  "additionalProperties": false,
+  "required": ["version", "harness_phase", "active_slice", "history", "releases"],
+  "properties": {
+    "version": { "type": "string", "const": "1.0" },
+    "harness_phase": {
+      "type": "string",
+      "enum": ["authoring", "active"],
+      "description": "authoring = aún no hay package.json; active = scaffold de código presente."
+    },
+    "active_slice": {
+      "description": "El slice (épica) en construcción. null si no hay ninguno activo.",
+      "oneOf": [
+        { "type": "null" },
+        { "$ref": "#/$defs/slice" }
+      ]
+    },
+    "history": {
+      "type": "array",
+      "description": "Slices archivados, en orden cronológico.",
+      "items": { "$ref": "#/$defs/slice" }
+    },
+    "releases": {
+      "type": "array",
+      "description": "Release Gates (outer loop). Una entrada por línea de release del Story Map auditada en bloque.",
+      "items": { "$ref": "#/$defs/release" }
+    }
+  },
+  "$defs": {
+    "slice": {
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["epica", "hus", "openspec_change", "branch", "phase", "gates", "updated_at", "updated_by"],
+      "properties": {
+        "epica": { "type": "string", "pattern": "^EP-[0-9]{3}$", "description": "Unidad de construcción del slice." },
+        "hus": {
+          "type": "array",
+          "description": "HU de la épica cubiertas por este change. Trazabilidad al alcance interno; al menos una.",
+          "items": { "type": "string", "pattern": "^HU-[0-9]{3}$" },
+          "minItems": 1,
+          "uniqueItems": true
+        },
+        "openspec_change": { "type": "string", "pattern": "^[a-z0-9]+(-[a-z0-9]+)*$" },
+        "branch": { "type": "string", "pattern": "^(feature|fix|chore)/[a-z0-9._-]+$" },
+        "phase": {
+          "type": "string",
+          "enum": ["dor", "change", "red", "green", "refactor", "smoke", "api", "data", "dod", "pr", "archived"]
+        },
+        "gates": {
+          "type": "object",
+          "additionalProperties": false,
+          "description": "Inner loop (por slice): dor, tdd, journey_smoke, data, api(null), coherence_link, dod. Los gates pesados (stack, security, smell, ux, coherence) se cerraron por slice en la era anterior y hoy viven en releases[]; se mantienen como propiedades opcionales para validar historial.",
+          "required": ["dor", "tdd", "dod"],
+          "properties": {
+            "dor": { "type": "boolean" },
+            "tdd": { "type": "boolean" },
+            "journey_smoke": { "type": "boolean", "description": "El backbone-hasta-aquí camina end-to-end (verificado con la skill verify/run)." },
+            "coherence_link": { "type": "boolean", "description": "Enlace change↔épica válido (change-epic-coherence, barato, por slice)." },
+            "data": { "type": "boolean" },
+            "api": { "type": ["boolean", "null"], "description": "null = N/A (slice sin endpoints)." },
+            "ux": { "type": ["boolean", "null"], "description": "null = N/A (slice sin UI). Legado: hoy se audita en releases[]." },
+            "stack": { "type": "boolean", "description": "Legado por-slice; deps las cubre el hook stack-guard.sh, la arquitectura se audita en releases[]." },
+            "security": { "type": "boolean", "description": "Legado por-slice; hoy se audita en releases[]." },
+            "smell": { "type": "boolean", "description": "Legado por-slice; hoy se audita en releases[]." },
+            "coherence": { "type": "boolean", "description": "Legado por-slice (trazabilidad 3-way completa); hoy se audita en releases[]." },
+            "dod": { "type": "boolean" }
+          }
+        },
+        "updated_at": { "type": "string", "format": "date-time" },
+        "updated_by": { "type": "string", "description": "Agente o hook que escribió el estado." },
+        "notes": { "type": "string", "description": "Nota libre opcional (p.ej. changes/branches adicionales de una épica construida en varios pasos)." }
+      }
+    },
+    "release": {
+      "type": "object",
+      "additionalProperties": false,
+      "required": ["release_id", "epicas", "status", "created_at", "updated_by"],
+      "properties": {
+        "release_id": { "type": "string", "description": "Mapea a una línea de release del Story Map (p.ej. R1-mvp)." },
+        "epicas": {
+          "type": "array",
+          "description": "Épicas cubiertas por esta release.",
+          "items": { "type": "string", "pattern": "^EP-[0-9]{3}$" },
+          "minItems": 1,
+          "uniqueItems": true
+        },
+        "status": { "type": "string", "enum": ["pending", "passed", "failed"] },
+        "gates": {
+          "type": "object",
+          "additionalProperties": false,
+          "description": "Gates pesados del Release Gate (outer loop). Ausentes mientras status=pending.",
+          "properties": {
+            "security": { "type": ["boolean", "null"] },
+            "smell": { "type": ["boolean", "null"] },
+            "ux": { "type": ["boolean", "null"], "description": "null = N/A (release sin UI)." },
+            "coherence": { "type": ["boolean", "null"] },
+            "stack_arch": { "type": ["boolean", "null"] },
+            "integration": { "type": ["boolean", "null"], "description": "Journey completo recorrido con deps reales." }
+          }
+        },
+        "created_at": { "type": "string", "format": "date-time" },
+        "updated_by": { "type": "string" }
+      }
+    }
+  }
+}

package/state/build-state.template.json

@@ -0,0 +1,7 @@
+{
+  "version": "1.0",
+  "harness_phase": "authoring",
+  "active_slice": null,
+  "history": [],
+  "releases": []
+}

package/templates/CLAUDE.md.template

@@ -0,0 +1,57 @@
+# CLAUDE.md
+
+<!-- BEGIN trycore-build-harness v{{BUILD_HARNESS_VERSION}} -->
+## Arnés de construcción (Trycore Build Harness)
+
+Este proyecto usa el arnés `@trycore/spec-build-harness` para **construir** sobre la discovery
+(compañero de `@trycore/spec-product-flow`: Discovery → Construcción). Modelo de **dos loops**:
+
+```
+Inner loop (por épica EP-XXX):  DoR → OpenSpec change → TDD → journey-smoke → api/data → DoD → PR + archive
+Outer loop (por release):       Release Gate (seguridad · diseño · UX · coherencia triple · arquitectura · integración)
+```
+
+- **Unidad de construcción**: la épica (`EP-XXX`). Un slice = una épica = un OpenSpec change = una rama = un PR.
+- **Una sola fuente de verdad**: `.claude/state/build-state.json` (schema + protocolo en `.claude/state/README.md`).
+- **Skills**: `building-a-slice` (inner loop), `releasing-a-version` (outer loop), `openspec-*` (ciclo de changes).
+- **Agentes** en `.claude/agents/build/`; **comandos** `/opsx:*`; gates automatizados por **hooks** en `.claude/hooks/build/`.
+
+### Slash commands
+
+| Comando | Propósito |
+|---|---|
+| `/build:onboard` | Parametriza el dominio del arnés (rellena el bloque de dominio de abajo) y escribe memoria |
+| `/opsx:explore` `/opsx:new` `/opsx:continue` `/opsx:apply` | Ciclo OpenSpec: explorar → crear change → artefactos → implementar |
+| `/opsx:verify` `/opsx:archive` `/opsx:sync` `/opsx:ff` `/opsx:bulk-archive` | Verificar, archivar, sincronizar specs |
+
+### Reglas duras (no negociables)
+
+1. **GitHub Flow estricto**: `main` siempre desplegable; integración solo por PR (el hook `gitflow-guard.sh` bloquea commit/push directo a `main`).
+2. El enlace change↔épica va en el bloque `## Trazabilidad` del `proposal.md`, **nunca** en frontmatter YAML (rompe `openspec validate`).
+3. Las dependencias se vigilan contra `.claude/config/stack-allowlist.json` (hook `stack-guard.sh`), derivado de la sección de requisitos técnicos del PRD.
+4. Las revisiones pesadas (seguridad/diseño/UX/coherencia triple/arquitectura/integración) corren **una vez por release** (outer loop), no por épica.
+5. Si una regla del arnés contradice la metodología Trycore (`METODOLOGIA.md`), **gana la metodología**.
+
+### Bloque de dominio (lo resuelve `/build:onboard`)
+
+Estos puntos de extensión los leen los agentes `security-reviewer`, `stack-guardian`,
+`data-consistency-checker`, `ux-krug-reviewer` y `simple-design-reviewer`:
+
+- **PRD técnico (fuente del stack)**: {{PRD_TECH_PATH}}
+- **Capa de servicios externos / IA (frontera)**: {{EXTERNAL_SERVICE_LAYER}}
+- **Lógica que debe ser determinista (no-IA)**: {{DETERMINISTIC_LAYER}}
+- **Categorías de datos sensibles / PII reguladas**: {{SENSITIVE_DATA_CATEGORIES}}
+- **Secretos server-side**: {{SERVER_SIDE_SECRETS}}
+- **Decisiones de alto impacto que exigen explicabilidad UX**: {{HIGH_STAKES_DECISIONS}}
+
+(Si aparecen como `{{...}}`, ejecuta `/build:onboard` para parametrizarlos.)
+
+### Requisitos
+
+- `openspec` CLI instalado (`npm i -g @fission-ai/openspec`) — lo usan `/opsx:*` y las skills `openspec-*`.
+- `python3` y `git` disponibles — los usan los hooks de `.claude/hooks/build/`.
+- Verifica con `trycore-build doctor`.
+
+<!-- END trycore-build-harness -->
+
+<!-- A partir de aquí, el equipo del proyecto puede agregar instrucciones específicas del cliente. -->

package/templates/newman.collection.template.json

@@ -0,0 +1,28 @@
+{
+  "info": {
+    "name": "<proyecto> — contratos API",
+    "description": "Plantilla de colección Postman/Newman. Sustituye con los endpoints y aserciones del contrato del consumidor. La usa el agente api-contract-tester.",
+    "schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json"
+  },
+  "item": [
+    {
+      "name": "<endpoint de ejemplo>",
+      "request": {
+        "method": "GET",
+        "url": "{{base_url}}/<ruta>"
+      },
+      "event": [
+        {
+          "listen": "test",
+          "script": {
+            "exec": [
+              "pm.test('status 200', () => pm.response.to.have.status(200));",
+              "// Añade aserciones del contrato del consumidor (forma de la respuesta, casos borde)."
+            ]
+          }
+        }
+      ]
+    }
+  ],
+  "variable": [{ "key": "base_url", "value": "http://localhost:3000" }]
+}

package/templates/settings-hooks.template.json

@@ -0,0 +1,25 @@
+{
+  "_comment": "ESPEJO DOCUMENTAL del bloque que `trycore-build init` mergea en el settings.json del consumidor (canal CLI). La fuente de verdad es src/lib/settings-merge.ts. Misma cadena de comando que hooks/build-harness.json (canal plugin) → si se instalan ambos canales, Claude Code deduplica y el hook dispara UNA vez. Permisos MÍNIMOS y enumerados (sin mcp__* ni rutas absolutas).",
+  "permissions": {
+    "allow": [
+      "Bash(openspec validate *)",
+      "Bash(openspec list *)",
+      "Bash(openspec show *)"
+    ]
+  },
+  "hooks": {
+    "SessionStart": [
+      { "matcher": "startup|clear|compact", "hooks": [ { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/load-build-state.sh\"" } ] }
+    ],
+    "PreToolUse": [
+      { "matcher": "Bash", "hooks": [ { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/gitflow-guard.sh\"" } ] },
+      { "matcher": "Write|Edit|MultiEdit", "hooks": [ { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/stack-guard.sh\"" } ] }
+    ],
+    "PostToolUse": [
+      { "matcher": "Write|Edit|MultiEdit", "hooks": [ { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/lint-typecheck.sh\"" }, { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/coherence-flag.sh\"" } ] }
+    ],
+    "Stop": [
+      { "matcher": ".*", "hooks": [ { "type": "command", "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/build-gate-check.sh\"" } ] }
+    ]
+  }
+}

package/templates/waivers/WAIVER.template.md

@@ -0,0 +1,27 @@
+# Waiver — Release <RELEASE_ID> (<EP-XXX..EP-YYY>)
+
+> Plantilla. Un waiver documenta una excepción CONSCIENTE a un gate (típicamente seguridad)
+> aceptada para una release concreta, con su mitigación y fecha de caducidad.
+
+## Contexto
+
+<Por qué se acepta la excepción para esta release — ej. demo, entorno sin datos reales.>
+
+## Hallazgos exceptuados
+
+| Severidad | Hallazgo | Acción de remediación | Responsable | Vence |
+|---|---|---|---|---|
+| ALTO | <descripción> | <qué se hará y cuándo> | <rol/persona> | <release/fecha> |
+
+## Mitigaciones aplicadas
+
+- <mitigación 1>
+- <mitigación 2>
+
+## Hallazgos NO exceptuados (al backlog)
+
+- <medio/bajo que no bloquean pero quedan registrados>
+
+## Vigencia
+
+Este waiver aplica SOLO a la release **<RELEASE_ID>**. Caduca al <condición/fecha>.