@trycore/spec-build-harness 0.8.1 → 0.8.3

package/.claude-plugin/plugin.json

@@ -2,7 +2,7 @@
   "$schema": "https://json.schemastore.org/claude-code-plugin-manifest.json",
   "name": "trycore-spec-build-harness",
   "displayName": "Trycore — Spec & Build Harness",
-  "version": "0.8.1",
+  "version": "0.8.3",
   "description": "Arnés de construcción de dos loops (slice por épica + release gate) para Claude Code, con gates de calidad, estado compartido y OpenSpec. Compañero de @trycore/spec-product-flow. Agnóstico al proyecto.",
   "author": {
     "name": "Trycore",
@@ -22,7 +22,10 @@
     "trycore"
   ],
   "skills": "./skills/",
-  "commands": ["./commands/opsx/", "./commands/build/"],
+  "commands": [
+    "./commands/opsx/",
+    "./commands/build/"
+  ],
   "agents": "./agents/build/",
   "hooks": "./hooks/build-harness.json"
 }

package/GOVERNANCE.md

@@ -8,7 +8,7 @@ evoluciona con el modelo y el proyecto. No es "instalar y olvidar".
 |---|---|---|
 | Contexto | sección Construcción de CLAUDE.md, `openspec/project.md` | raíz / `openspec/` |
 | Estado | `build-state.json` (+schema, README) | `.claude/state/` |
-| Agentes | 12 agentes de build | `.claude/agents/build/` |
+| Agentes | 14 agentes de build | `.claude/agents/build/` |
 | Hooks | settings.json + 13 scripts | `.claude/settings.json`, `.claude/hooks/build/` |
 | Skill | `building-a-slice` (+11 refs · `workflows/`) · `releasing-a-version` (`workflows/`) · `building-a-micro-change` (carril ligero de mantenimiento) · `managing-parallel-front` (front paralelo inter-épica) | `.claude/skills/` |
 | Comandos | `/opsx:*` · `/build:onboard` · `/build:reflect` · `/build:slice` · `/build:release` · `/build:work` · `/build:resume` · `/build:front` | `.claude/commands/` |

package/INSTALL.md

@@ -86,10 +86,10 @@ Qué hace `init`:
 
 1. **Verifica requisitos duros** (a menos que uses `--skip-doctor`).
 2. **Siembra los assets** en rutas nativas de Claude Code:
-   - `.claude/agents/build/` — 12 agentes.
-   - `.claude/commands/opsx/` (10 comandos `/opsx:*`) y `.claude/commands/build/` (5 comandos: `/build:onboard`, `/build:reflect`, `/build:slice`, `/build:release`, `/build:work`).
-   - `.claude/skills/` — 13 skills (`building-a-slice`, `building-a-micro-change`, `releasing-a-version`, `openspec-*`).
-   - `.claude/hooks/build/` — 10 hooks bash.
+   - `.claude/agents/build/` — 14 agentes.
+   - `.claude/commands/opsx/` (10 comandos `/opsx:*`) y `.claude/commands/build/` (8 comandos: `/build:onboard`, `/build:reflect`, `/build:architect`, `/build:slice`, `/build:release`, `/build:work`, `/build:resume`, `/build:front`).
+   - `.claude/skills/` — 15 skills (`building-a-slice`, `building-a-micro-change`, `releasing-a-version`, `managing-parallel-front`, `setup-architecture`, `openspec-*`).
+   - `.claude/hooks/build/` — 13 hooks (bash + python).
 3. **Siembra el estado**: `state/build-state.schema.json` y `state/README.md` se versionan;
    `state/build-state.json` se siembra **vacío y nunca se sobrescribe** (va al `.gitignore`).
 4. **Siembra `config/stack-allowlist.json`** (artefacto del consumidor; lo puebla `/build:onboard`).

package/METODOLOGIA.md

@@ -19,11 +19,19 @@
 discovery). El flujo completo de extremo a extremo es:
 
 ```
-DISCOVERY  (@trycore/spec-product-flow)        CONSTRUCCIÓN  (@trycore/spec-build-harness)
-PRD → User Story Map → Backlog → Historias  →  por épica: DoR → change → TDD → smoke → api/data → DoD → PR
-      (AC G/W/T) → Priorización → Flows           por release: Release Gate (seguridad/diseño/UX/coherencia/arquitectura/integración)
+DISCOVERY (@trycore/spec-product-flow)   ARQUITECTURA (capa ADD)      CONSTRUCCIÓN (@trycore/spec-build-harness)
+PRD → User Story Map → Backlog →      →  drivers/ASRs → tácticas →  →  por épica: DoR → change → TDD → smoke → api/data → DoD → PR
+      Historias (AC G/W/T) → Flows        estilos → vistas → ATAM →      por release: Release Gate (seguridad/diseño/UX/coherencia/arquitectura/integración)
+                                          stack (ADRs en docs/adr/)
 ```
 
+La **capa de arquitectura** (`/build:architect`, skill `setup-architecture`) es **opcional pero
+recomendada** y corre **una vez, entre discovery y construcción**: lee `docs/` (solo lectura) y produce
+los ADRs en `docs/adr/` con el método **ADD** (Attribute-Driven Design, Len Bass). Sus decisiones se
+vuelven **criterios exigibles**: pueblan `stack-allowlist.json` (que `stack-guard.sh` hace cumplir) y son
+criterio de DoR (cobertura de ADR para el cimiento fundacional). Es agnóstica: el dominio entra por
+`docs/`. Ver §9.3.
+
 Ambos paquetes **coexisten en el mismo `.claude/` sin colisión**, con namespaces disjuntos:
 
 | Eje | Discovery (`spec-product-flow`) | Construcción (`spec-build-harness`) |
@@ -404,7 +412,10 @@ dor → change → red → green → refactor → smoke → api → data → dod
 
 **Versionado del estado.** `build-state.json` se siembra **vacío** y **nunca se sobreescribe** (está
 en `.gitignore`: es working state). El **schema** y el **README** sí se versionan. El
-`stack-allowlist.json` es artefacto del consumidor (lo siembra el CLI, lo puebla `/build:onboard`).
+`stack-allowlist.json` es artefacto del consumidor con tres escritores en secuencia y **merge aditivo**:
+lo **siembra** el CLI (`init`), lo **puebla** `/build:onboard` (stack mecánico) y, si el proyecto corre
+la capa de arquitectura, `/build:architect` lo **consolida** (añade `allow`/`rationale` con referencia a
+los ADRs; **nunca** borra entradas del consumidor ni pisa `source`, que sigue apuntando al PRD).
 `uninstall` preserva `state/` y `config/`.
 
 ---
@@ -463,9 +474,41 @@ La construcción **consume** los artefactos de discovery y los trata como entrad
 | `docs/02-user-story-map/` (backbone + líneas de release) | Esqueleto que camina (§2); definición de release y default del Release Gate (§4) |
 | PRD §7 / `stack-allowlist.json#source` | Stack permitido; arquitectura auditada en `stack_arch` |
 
-El arnés **no escribe** en `docs/`; cuando una HU no cumple DoR, devuelve el trabajo a discovery
-(`/trycore:*`). El único contacto de escritura cruzada es la **back-reference** del change en la
-épica y las HU al archivar (§6.4).
+El arnés **no escribe** en los artefactos de discovery (`docs/01-prd/` … `docs/04-historias/`); cuando
+una HU no cumple DoR, devuelve el trabajo a discovery (`/trycore:*`). Los contactos de escritura del
+arnés en `docs/` son dos y están acotados: la **back-reference** del change en la épica y las HU al
+archivar (§6.4), y el subárbol **`docs/adr/`** —propiedad de construcción— que produce la capa de
+arquitectura (§9.3). `docs/adr/` **no** es un artefacto de discovery: es la salida de construcción que
+traza *hacia* discovery (HU/PRD) sin modificarla.
+
+### 9.3 Capa de arquitectura (ADD) — entre discovery y construcción
+
+Fase **opcional pero recomendada** que corre **una vez, después de discovery y antes del primer slice**,
+activada por **`/build:architect`** (skill `setup-architecture`). Aplica el método **ADD** (Attribute-Driven
+Design, Len Bass): lee `docs/` de solo lectura, extrae **drivers/ASRs** (objetivos de negocio → casos de
+uso significativos → escenarios de calidad de 6 partes → restricciones → concerns), itera rondas de diseño
+(**tácticas → estilos → vistas → evaluación ATAM-lite**) y decide el **stack**. Produce en `docs/adr/`:
+
+- `0000-drivers-y-asrs.md` — catálogo de drivers (entrada de diseño, documento vivo).
+- `000N-<slug>.md` — un ADR por decisión, plantilla de 7 secciones (= los pasos ADD).
+- `_backlog-arquitectonico.md` — tablero de cobertura driver↔ADR, riesgos abiertos y bitácora (el
+  **estado** de la capa; no toca `build-state.json`).
+
+**UX y HITL.** Autónoma y de propuesta máxima: genera todo de una pasada y se detiene en **una** revisión
+final; solo escala trade-offs de **negocio** (no de arquitectura). **Propone, no publica**: los ADRs nacen
+`proposed`/`living-document` y un humano los promueve a `accepted`. Delega la extracción en `asr-extractor`
+y la evaluación en `architecture-evaluator` (ambos read-only). Re-correr es **incremental** (añade
+iteraciones; no pisa ADRs `accepted`).
+
+**Los ADRs son criterios exigibles** (cierre del lazo con los gates existentes):
+- **`stack-allowlist.json`** — la capa lo puebla; el hook `stack-guard.sh` bloquea deps fuera de lista.
+- **DoR** — `dor-dod-gatekeeper` exige que el cimiento de una épica `layer: foundational` tenga un ADR
+  con estado ≥ `ABORDADO` (duro); en épicas `business` es advertencia. Opt-in: sin `docs/adr/`, N/A.
+- **`stack_arch`** (Release Gate) — `stack-guardian` audita el diff contra las decisiones `accepted` de
+  `docs/adr/`, no solo contra la allowlist.
+
+Forward-compat v0.9: los tipos generados se declaran en `asset-types.json` (protocolo runtime §6); hoy la
+salida es file-based y la propuesta se materializa en git, mañana irá por API sin cambiar la skill.
 
 ---
 

package/README.md

@@ -73,6 +73,7 @@ Gate de release que corre **una sola vez por versión** sobre el conjunto de sli
 |---|---|
 | `/build:onboard` | Onboarding capa 2: lee el PRD, pregunta por PII/IA/determinismo/secretos, resuelve `{{placeholders}}` y escribe la auto-memory. |
 | `/build:reflect` | Reflexión post-slice: tras archivar, propone convenciones aprendidas / errores recurrentes al bloque `trycore-build-learnings` de `CLAUDE.md` (tras tu aprobación) y marca el slice como reflexionado. |
+| `/build:architect` | **Capa de arquitectura (ADD)**, entre discovery y construcción: lee `docs/` de solo lectura y produce los ADRs en `docs/adr/` (drivers/ASRs → tácticas → estilos → vistas → ATAM-lite → stack) con mínimo HITL. Puebla `stack-allowlist.json`; sus decisiones se vuelven criterio de DoR y del gate `stack_arch`. Delega en la skill `setup-architecture`. |
 | `/build:slice` | Entrada del **inner loop**: abre o continúa un slice (épica `EP-XXX`) y conduce el pipeline DoR → change → TDD → smoke → api/data → DoD → PR+archive. Adaptador delgado que delega en la skill `building-a-slice`. |
 | `/build:release` | Entrada del **outer loop**: corre el Release Gate **una sola vez** sobre el diff acumulado (los 5 reviewers pesados en paralelo + integración secuencial). Delega en la skill `releasing-a-version`. |
 | `/build:work` | Router *classify-and-act*: clasifica el trabajo entrante y enruta al carril correcto (`building-a-micro-change` · `building-a-slice` · `releasing-a-version`). Es ruteo, no política: no ejecuta el pipeline ni toca el estado. |
@@ -138,11 +139,11 @@ trycore-spec-build-harness/
 ├── METODOLOGIA.md             ← fuente de verdad metodológica (gana ante cualquier skill)
 ├── GOVERNANCE.md              ← gobernanza del paquete + cadencia de auditoría
 ├── .claude-plugin/            ← manifiesto del plugin nativo (canal de conveniencia)
-├── agents/build/              ← 12 agentes revisores (segunda opinión, contexto limpio)
+├── agents/build/              ← 14 agentes revisores (segunda opinión, contexto limpio)
 ├── commands/
 │   ├── opsx/                  ← 10 comandos /opsx:* (ciclo OpenSpec)
-│   └── build/                 ← 7 comandos /build:* (onboard, reflect, slice, release, work, resume, front)
-├── skills/                    ← 14 skills (building-a-slice, building-a-micro-change, releasing-a-version, managing-parallel-front, 10 openspec-*) + 3 plantillas *.workflow.js (opt-in, read-only)
+│   └── build/                 ← 8 comandos /build:* (onboard, reflect, architect, slice, release, work, resume, front)
+├── skills/                    ← 15 skills (building-a-slice, building-a-micro-change, releasing-a-version, managing-parallel-front, setup-architecture, 10 openspec-*) + 3 plantillas *.workflow.js (opt-in, read-only)
 ├── hooks/build/               ← 13 hooks (gate-check, reflect-nudge, release-gate-nudge, scaffold-guard, gitflow-guard, stack-guard, statusline-bridge, context-monitor, reconcile-build-state, …)
 ├── state/                     ← máquina de estado: build-state.json + schema + README
 ├── config/                    ← build-config.template.json (umbrales de contexto) + stack-allowlist.template.json (artefacto del consumidor)
@@ -151,7 +152,7 @@ trycore-spec-build-harness/
 └── docs/examples/reference/   ← ejemplo de referencia (fuera del core, excluido de check-agnostic)
 ```
 
-Los **12 agentes** en `agents/build/` son: `build-orchestrator`, `dor-dod-gatekeeper`, `security-reviewer`, `simple-design-reviewer`, `ux-krug-reviewer`, `coherence-three-way` (opus), `stack-guardian`, `api-contract-tester`, `data-consistency-checker`, `change-epic-coherence`, `ux-fidelity-reviewer` y `wiring-adversarial-verifier` (opus).
+Los **14 agentes** en `agents/build/` son: `build-orchestrator`, `dor-dod-gatekeeper`, `security-reviewer`, `simple-design-reviewer`, `ux-krug-reviewer`, `coherence-three-way` (opus), `stack-guardian`, `api-contract-tester`, `data-consistency-checker`, `change-epic-coherence`, `ux-fidelity-reviewer`, `wiring-adversarial-verifier` (opus), `asr-extractor` y `architecture-evaluator`.
 
 **Estado.** `state/build-state.json` se siembra **vacío** y nunca se sobreescribe (va al `.gitignore`); el schema y el README sí se versionan. `config/stack-allowlist.json` es artefacto del consumidor: lo siembra el CLI y lo puebla `/build:onboard`. `uninstall` preserva `state/` y `config/`.
 
@@ -181,7 +182,9 @@ El core no menciona ningún dominio de cliente. Toda parametrización entra por
 - ✅ **v0.6.0** — **calidad de cierre contra horizonte largo** (feedback exodocs): handoff fino en disco (`wiring_checklist[]` + `progress_log[]` + `sub_slices[]`), gate `wiring_verified` por nuevo agente **`wiring-adversarial-verifier`** (verificación adversarial independiente, contexto virgen), cimiento pre-construido + tag `layer` y gate de tamaño en el DoR, runner fuera-de-chat `integration-check`, y **fidelidad estricta por verificación visual real** (MCP requerido para UI). Convenciones anti-deriva (producto completo, no MVP) upstreadas al bloque del arnés. Total: **12 agentes**, **9 hooks**.
 - ✅ **v0.7.0** — **orquestación con workflows dinámicos + hardening** (de una evaluación adversarial del propio arnés): **3 plantillas `*.workflow.js`** opt-in y read-only (`explore-fanout`, `wiring-verify`, `release-gate`) que entran **solo donde aportan valor** y nunca en el camino caliente del inner loop; **3 comandos nuevos** `/build:slice` (entrada del inner loop), `/build:release` (outer loop) y `/build:work` (router *classify-and-act*); hook **`release-gate-nudge.sh`** (Stop, determinista: solo sugiere el Release Gate). Rename de los gates de los 5 reviewers pesados → `releases[].gates.{security,smell,ux,coherence,stack_arch}` (`stack`→`stack_arch`; separación `coherence` (release) / `coherence_link` (inner)). Hardening: degradación segura en 8 agentes, escritura atómica del estado, cierre del bypass de specs no-semver, `wiring` exige evidencia ejecutada y `check-agnostic` barre `*.js`. Total: **12 agentes**, **10 hooks**, **5 comandos `/build:*`**.
 - ✅ **v0.8.0** — **motor de contexto + estado anclado a disco + front paralelo inter-épica**: hooks **`statusline-bridge.sh`** (canal CLI) + **`context-monitor.sh`** (umbrales `context.warning_pct`/`context.critical_pct` configurables, 35%/25% por defecto) con **auto-handoff** a `session_continuity` en critical/`PreCompact` y comando **`/build:resume`** para rehidratar desde disco; config **`context.auto_checkpoint`** (opt-in). Reconciliador **`reconcile-build-state.py`** (`SessionStart`): deriva de git + evidencia de tests, degrada `wiring_checklist` sin evidencia, anota *branch drift*, ratchet de gates, fail-open. **Front paralelo** (`parallel_front` en el estado): comando **`/build:front`** + skill **`managing-parallel-front`** + `scripts/lib/front-plan.py` (disjunción por `files_scope`, foundational-first). Schema nuevo: `slice.layer`, `slice.files_scope`, `slice.branch_drift`, `slice.session_continuity`. **Caveat:** `statusLine` es solo canal CLI; en plugin-only el motor de contexto degrada fail-open. Total: **12 agentes**, **13 hooks**, **7 comandos `/build:*`**, **14 skills**.
-- ✅ **v0.8.1 (actual)** — **hotfix del motor de contexto**: `context-monitor.sh` re-inyectaba `additionalContext` en cada evento `Stop`, lo que re-lanzaba el turno en bucle hasta el tope `CLAUDE_CODE_STOP_HOOK_BLOCK_CAP` (9→override). Ahora en `Stop` re-lanza como mucho una vez por sesión (solo la transición a crítico que graba el handoff) y `warning` nunca inyecta en `Stop`. Cubierto por `test-context-monitor.sh`.
+- ✅ **v0.8.1** — **hotfix del motor de contexto**: `context-monitor.sh` re-inyectaba `additionalContext` en cada evento `Stop`, lo que re-lanzaba el turno en bucle hasta el tope `CLAUDE_CODE_STOP_HOOK_BLOCK_CAP` (9→override). Ahora en `Stop` re-lanza como mucho una vez por sesión (solo la transición a crítico que graba el handoff) y `warning` nunca inyecta en `Stop`. Cubierto por `test-context-monitor.sh`.
+- ✅ **v0.8.3 (actual)** — **gates de validación paralelizados (sharding lossless)**: el carril `coherence` del Release Gate se shardea **por HU** (≥ 3 HUs, `args.hus[]`) — de un solo agente opus O(HUs) a un shard por HU en paralelo con consolidación **fail-closed** y cobertura completa; nueva plantilla **`dor-fanout.workflow.js`** para los chequeos per-HU del DoR (frontmatter/G-W-T/INVEST en paralelo; el nivel épica sigue en `dor-dod-gatekeeper`, único emisor del veredicto). `security`/`smell`/`ux`/`stack_arch` quedan monolíticos a propósito (riesgo cross-cutting); `integration` sigue secuencial (regla dura §5).
+- ✅ **v0.8.2** — **capa de arquitectura (ADD)** entre discovery y construcción: comando **`/build:architect`** + skill **`setup-architecture`** que aplica el método **Attribute-Driven Design** (Len Bass) leyendo `docs/` (solo lectura) y produciendo `docs/adr/` (drivers/ASRs → tácticas → estilos → vistas → ATAM-lite → stack), con **mínimo HITL** (autónomo, una revisión final; propone, no publica). Dos agentes nuevos (`asr-extractor`, `architecture-evaluator`), plantillas ADD embebidas en la skill (`skills/setup-architecture/assets/`) y **`asset-types.json`** (forward-compat runtime v0.9: `arch.drivers`/`arch.adr`/`arch.backlog`). Cierre del lazo: los ADRs se vuelven criterios — el **DoR** exige cobertura para el cimiento fundacional (opt-in, retrocompatible) y el gate **`stack_arch`** audita conformidad contra `docs/adr/`. Total: **14 agentes**, **13 hooks**, **8 comandos `/build:*`**, **15 skills**.
 
 ## Licencia
 

package/VERSION

@@ -1 +1 @@
-0.8.1
+0.8.3

package/agents/build/architecture-evaluator.md

@@ -0,0 +1,45 @@
+---
+name: architecture-evaluator
+description: Evalúa en papel un ADR (método ADD, Paso 7) con una pasada adversarial estilo ATAM-lite, antes de programar. Dado un ADR propuesto y el catálogo de drivers (docs/adr/0000-drivers-y-asrs.md), busca refutar que la decisión satisface sus drivers: emite veredicto por driver con evidencia/medida, identifica puntos de sensibilidad y trade-offs, y lista riesgos y drivers no cubiertos. Úsalo en la fase 3 de la skill setup-architecture (/build:architect). Read-only; no decide negocio ni escribe archivos: devuelve el análisis para §5/§6 del ADR y la sección de riesgos del backlog.
+tools: Read, Grep, Glob
+model: sonnet
+---
+
+Eres el **evaluador de arquitectura** del arnés. Read-only. Aplicas una versión ligera de **ATAM**
+(Architecture Tradeoff Analysis Method) sobre un ADR **antes** de que se escriba una línea de código.
+Tu sesgo es **adversarial**: buscas refutar que el ADR cumple sus drivers. Un riesgo en papel es mucho
+más barato que un rediseño en código.
+
+## Entrada (solo lectura)
+- El ADR bajo análisis: `docs/adr/000N-*.md` (§1–§4 completas).
+- El catálogo de drivers: `docs/adr/0000-drivers-y-asrs.md`.
+- Opcional: ADRs previos relacionados (para detectar decisiones supersedidas o en conflicto).
+
+## Qué producir
+1. **Veredicto por driver.** Para cada driver que el ADR dice satisfacer: ✅ / ⚠️ / ❌ con la **evidencia o
+   medida** que lo respalda (o la que falta). Un driver solo es ✅ si hay medida verificable o plan de
+   verificación (k6, prueba de carga, matriz RBAC…). "Parece suficiente" es ⚠️.
+2. **Puntos de sensibilidad.** Decisiones de las que depende críticamente una respuesta de calidad
+   (p.ej. tamaño de pool ↔ rendimiento de lectura).
+3. **Trade-offs.** Puntos donde una decisión mejora un atributo y empeora otro (p.ej. backoff robusto vs
+   P99 de integración externa).
+4. **Riesgos.** Decisiones sin evidencia, supuestos sin validar, drivers no cubiertos. Cada uno con
+   driver, mitigación planificada e iteración → alimentan la sección de riesgos del backlog.
+5. **Drivers no resueltos.** Se devuelven explícitamente al backlog (`PENDIENTE`/`EN DISEÑO`).
+
+## Reglas
+- **Medida, no opinión.** No des ✅ sin sustento verificable.
+- **No decides negocio.** Si un riesgo se resuelve con una decisión de negocio (exponer o no un dato,
+  fijar o aplazar RTO/RPO), márcalo **trade-off de negocio** → sube a la revisión única de la skill; no
+  lo resuelvas tú.
+- **Detecta conflictos** con ADRs previos (una decisión que supersede a otra sin declararlo es un hallazgo).
+
+## Salida
+- Bloque para **§5 (análisis)** y **§6 (consecuencias)** del ADR + filas para la sección de **riesgos** del
+  backlog. Veredicto global del ADR: **COHERENTE** (cubre sus drivers con evidencia) / **CON RIESGOS**
+  (lista los abiertos) / **INCOHERENTE** (no cubre un driver crítico que dice cubrir).
+
+## Degradación segura
+Si no puedes completar el análisis (ADR ilegible, catálogo ausente), **NO devuelvas COHERENTE**: reporta
+**INCONCLUSO** con el motivo y qué falta. Un fallo de herramienta no es N/A. No escribas archivos:
+devuelve el análisis a la skill `setup-architecture`.

package/agents/build/asr-extractor.md

@@ -0,0 +1,43 @@
+---
+name: asr-extractor
+description: Extrae el catálogo de drivers arquitectónicos y ASRs (Architecturally Significant Requirements) leyendo los artefactos de discovery del consumidor (PRD, user story map, docs/03-backlog/epicas.md, docs/04-historias/HU-*.md), de solo lectura. Propone objetivos de negocio (OE), casos de uso significativos (UC), escenarios de atributos de calidad (QA) en formato Bass de 6 partes con medida cuantificable, restricciones (CON), concerns (CRN), matriz de prioridad y plan de iteraciones. Úsalo en la fase 1 de la skill setup-architecture (/build:architect), típicamente con fan-out por área. No decide arquitectura ni escribe archivos: devuelve el catálogo propuesto.
+tools: Read, Grep, Glob
+model: sonnet
+---
+
+Eres el **extractor de drivers/ASRs** del arnés. Read-only. Tu trabajo es leer discovery y **proponer**
+la entrada de diseño del método ADD (Paso 1), no diseñar la solución.
+
+## Entrada (solo lectura)
+- `docs/01-prd/` — objetivos, requisitos funcionales, requisitos técnicos / no funcionales.
+- `docs/02-user-story-map/` — backbone y líneas de release.
+- `docs/03-backlog/epicas.md` — épicas (`EP-XXX`) y su trazabilidad a objetivos.
+- `docs/04-historias/HU-*.md` — historias con AC en Given/When/Then.
+
+## Qué extraer (propuesta)
+1. **OE — objetivos de negocio.** Cada uno con métrica/meta. Si el PRD no da métrica, propón una y márcala
+   *a validar* (no la des por cierta).
+2. **UC — funcionales arquitecturalmente significativos.** SOLO los que moldean la arquitectura
+   (integraciones externas, transaccionalidad, RBAC, asincronía, auditoría, versionado). No es el backlog
+   completo. Cada UC cita las HU/OE de las que sale.
+3. **QA — escenarios de atributos de calidad**, uno por atributo relevante (rendimiento, disponibilidad,
+   seguridad/confidencialidad, integrabilidad, modificabilidad, observabilidad, escalabilidad, integridad
+   transaccional…). **Formato Bass de 6 partes**: Fuente · Estímulo · Artefacto · Entorno · Respuesta ·
+   **Medida de respuesta (cuantificable)**. Sin medida cuantificable no es ASR — propón una razonable
+   marcada *a validar*. Prioridad `(Importancia de negocio, Impacto arquitectónico)` en {A,M,B}.
+4. **CON — restricciones.** Lo no negociable (stack impuesto, prohibiciones de datos, headers, gates CI).
+5. **CRN — concerns.** Preocupaciones que condicionan el diseño (capacidades del equipo, costos, cuotas
+   de terceros, decisiones abiertas de negocio).
+6. **Matriz de prioridad** (negocio × impacto) y **plan de iteraciones** (una ronda por fase PRD / release).
+
+## Salida
+- El catálogo estructurado tal como lo espera la plantilla `0000-drivers-y-asrs.template.md` (en
+  `assets/` de la skill `setup-architecture`, instalada en el consumidor; bloques §1–§7), listo para que
+  la skill lo escriba en `docs/adr/0000-drivers-y-asrs.md`.
+- **Trazabilidad obligatoria**: cada UC/QA cita su origen (HU/OE/§PRD). Un driver sin sustento en `docs/`
+  no se inventa; si es un hueco real (p.ej. el PRD no fija disponibilidad), decláralo como CRN o riesgo.
+
+## Degradación segura
+Si `docs/` no es legible o falta discovery, **NO inventes** el catálogo: reporta qué falta y detente. La
+ausencia de evidencia no es evidencia de ausencia de drivers. No escribas archivos: devuelve la propuesta
+a la skill `setup-architecture`.

package/agents/build/dor-dod-gatekeeper.md

@@ -19,6 +19,14 @@ las fases de código.)
 La unidad es la **épica**. Identifica `EP-XXX` en `docs/03-backlog/epicas.md` y el conjunto de HU
 que la componen (las que tienen `epica: EP-XXX` en `docs/04-historias/`). Pasa SOLO si **todas** se
 cumplen; lista cada una con ✓/✗:
+
+> **Conducción opcional — fan-out per-HU (épicas con ≥ 3 HUs).** Los criterios 3-5 (frontmatter, AC
+> G/W/T, INVEST) son por-HU e independientes: puedes conducirlos con la plantilla
+> `building-a-slice/workflows/dor-fanout.workflow.js` (read-only; `args: {epica, hus[]}`) para validarlos
+> **en paralelo** en vez de HU por HU. La plantilla devuelve el diagnóstico per-HU con consolidación
+> fail-closed (HU fallida o shard ausente = false); tú **combinas** ese diagnóstico con los criterios de
+> nivel épica (1-2 y 6-10, que valides tú en sesión) y sigues siendo el **único** que emite el veredicto
+> DoR y abre `active_slice`. Con < 3 HUs la plantilla se auto-salta: valida secuencial como siempre.
 1. La épica existe en `docs/03-backlog/epicas.md` con su trazabilidad a objetivos del PRD.
 2. Tiene **al menos una HU** asociada y todas se enumeran en `hus[]`.
 3. **Cada HU** de la épica: frontmatter YAML completo (`id, titulo, epica, prioridad, complejidad,
@@ -39,6 +47,18 @@ cumplen; lista cada una con ✓/✗:
 9. **Fuente de diseño (solo slices con UI)**: si la épica toca UI, `design_source.confirmed===true`
    (fuente visual de verdad declarada para el proyecto) y la épica apunta a la(s) pantalla(s)
    equivalente(s) del `DESIGN_SOURCE`. Si no toca UI, este criterio es N/A.
+10. **Cobertura arquitectónica (ADR)** — *opt-in, retrocompatible*: si el proyecto adoptó la capa de
+    arquitectura (existe `docs/adr/_backlog-arquitectonico.md`, generado por `/build:architect`), los
+    drivers **arquitecturalmente significativos** que la épica ejerce deben tener un ADR con estado
+    ≥ `ABORDADO` en el tablero del backlog. **Mecanismo de join** (determinista, no matching libre): los
+    drivers de la épica son las filas del tablero cuya columna **Trazabilidad (EP/HU)** cita `EP-XXX` o
+    alguna de sus HU (`hus[]`); si el tablero no trae esa columna (backlog de versión previa), usa la
+    columna Trazabilidad del `0000-drivers-y-asrs.md`. **Duro para épicas `layer: foundational`** (auth,
+    datos, arquitectura base, design-system): si ninguno de sus drivers trazados tiene ADR ≥ `ABORDADO`,
+    **NO abras el slice** — instruye correr `/build:architect` para decidir esa arquitectura antes. Para
+    épicas `layer: business` es una **advertencia** (no bloquea) si algún driver que tocan sigue
+    `PENDIENTE`. Si **no** existe `docs/adr/` (proyecto sin la capa), este criterio es **N/A** — no
+    bloquees; deja una nota sugiriendo `/build:architect`.
 
 Si DoR pasa: propón abrir `active_slice` con `epica`, `hus` (lista de las HU cubiertas),
 `openspec_change` (kebab del título de la épica), `branch: feature/ep-xxx-<slug>`, `phase: dor`,

package/agents/build/stack-guardian.md

@@ -10,6 +10,9 @@ Eres el **guardián del stack** del arnés de construcción. Read-only. Defiende
 ## Referencias
 - Contrato: la sección de requisitos técnicos del PRD del consumidor (ruta declarada en `stack-allowlist.json#source`).
 - Allowlist operable: `.claude/config/stack-allowlist.json`.
+- **Decisiones de arquitectura**: `docs/adr/` (catálogo de drivers `0000-drivers-y-asrs.md`, ADRs de
+  decisión y `_backlog-arquitectonico.md`), si el proyecto adoptó la capa (`/build:architect`). Los ADRs
+  `accepted` son el contrato de arquitectura del que la allowlist es la operacionalización de stack.
 
 ## Qué verificar (reporta ✓/✗)
 1. **Dependencias.** Si existe un manifiesto de dependencias del proyecto, toda dep declarada debe
@@ -30,6 +33,12 @@ Eres el **guardián del stack** del arnés de construcción. Read-only. Defiende
 3. **Anti-patrones.** Señala: lógica de decisión delegada a un servicio no determinista cuando el PRD
    la exige determinista; llamadas a servicios externos desde el cliente; claves de servicios externos
    (declaradas server-side) expuestas al browser; dependencias que reemplazan a las del stack declarado.
+4. **Conformidad con los ADRs (si existe `docs/adr/`).** El diff acumulado respeta las decisiones
+   `accepted` de `docs/adr/`: el **estilo** elegido (p.ej. si un ADR fijó monolito modular, no aparecen
+   límites de proceso/red que impliquen microservicios sin un ADR que lo supersede), las **tácticas**
+   comprometidas por driver (p.ej. saga+outbox para integridad transaccional; RBAC central para
+   confidencialidad) y las **divergencias de stack** ya registradas. Marca cada decisión de código que
+   **contradiga** un ADR `accepted` sin superseder-lo (deriva de arquitectura), citando el ADR.
 
 ## Salida
 - Veredicto **STACK-OK** / **DESVIACIÓN**, lista ✓/✗ con `archivo:línea` o nombre de dep.

package/asset-types.json

@@ -0,0 +1,75 @@
+{
+  "_comment": "Tipos de asset que este paquete sabe generar (protocolo-cliente-runtime §6). Declaración forward-compatible con v0.9: hoy la skill setup-architecture (/build:architect) los genera como archivos en docs/adr/ desde las plantillas de skills/setup-architecture/assets/ y los PROPONE (nunca publica); cuando exista el Agent Orchestrator Runtime, la misma skill los propondrá vía API (POST /projects/{id}/context/proposals) sin cambiar su salida. Este manifiesto declara EXACTAMENTE los tipos que la skill produce — ni más ni menos; tipos futuros (p.ej. arch.style/arch.patterns/stack.profile como documentos independientes del §6 del protocolo) se añadirán cuando exista una salida que los materialice. Aditivos → auto-publicados en el registro; breaking → propuestos para un ADMIN.",
+  "meta_schema_version": 1,
+  "types": [
+    {
+      "type_key": "arch.drivers",
+      "title": "Catálogo de drivers y ASRs",
+      "category": "Arquitectura",
+      "content_format": "markdown+frontmatter",
+      "frontmatter_schema": {
+        "type": "object",
+        "properties": {
+          "id": {"type": "string"},
+          "status": {"type": "string", "enum": ["living-document"]}
+        },
+        "required": ["id"]
+      },
+      "body_sections": [
+        {"id": "objetivos-negocio", "title": "Objetivos de negocio (OE)", "required": true},
+        {"id": "funcionales", "title": "Requisitos funcionales primarios (UC)", "required": true},
+        {"id": "escenarios-qa", "title": "Escenarios de atributos de calidad (QA)", "required": true},
+        {"id": "restricciones", "title": "Restricciones (CON)", "required": false},
+        {"id": "concerns", "title": "Concerns (CRN)", "required": false},
+        {"id": "plan-iteraciones", "title": "Plan de iteraciones", "required": false},
+        {"id": "matriz-prioridad", "title": "Matriz de priorización", "required": false}
+      ],
+      "cardinality": "single",
+      "generation": {"source": "plugin", "skill": "setup-architecture"},
+      "descriptor_version": 1
+    },
+    {
+      "type_key": "arch.adr",
+      "title": "Decisión de arquitectura (ADR-ADD)",
+      "category": "Arquitectura",
+      "content_format": "markdown+frontmatter",
+      "frontmatter_schema": {
+        "type": "object",
+        "properties": {
+          "id": {"type": "string"},
+          "title": {"type": "string"},
+          "status": {"type": "string", "enum": ["proposed", "accepted", "superseded", "deprecated"]},
+          "add": {"type": "object"}
+        },
+        "required": ["id", "title", "status"]
+      },
+      "body_sections": [
+        {"id": "objetivo-drivers", "title": "Objetivo de la iteración y drivers (Pasos 2-3)", "required": true},
+        {"id": "conceptos", "title": "Conceptos de diseño: tácticas y estilos (Paso 4)", "required": true},
+        {"id": "instanciacion", "title": "Instanciación: responsabilidades e interfaces (Paso 5)", "required": true},
+        {"id": "vistas-decision", "title": "Vistas y registro de la decisión (Paso 6)", "required": true},
+        {"id": "analisis", "title": "Análisis del diseño / ATAM (Paso 7)", "required": true},
+        {"id": "consecuencias", "title": "Consecuencias", "required": false},
+        {"id": "trazabilidad", "title": "Trazabilidad", "required": true}
+      ],
+      "cardinality": "multiple",
+      "generation": {"source": "plugin", "skill": "setup-architecture"},
+      "descriptor_version": 1
+    },
+    {
+      "type_key": "arch.backlog",
+      "title": "Backlog arquitectónico (cobertura driver↔ADR)",
+      "category": "Arquitectura",
+      "content_format": "markdown",
+      "frontmatter_schema": {"type": "object"},
+      "body_sections": [
+        {"id": "tablero-drivers", "title": "Tablero por driver", "required": true},
+        {"id": "riesgos-abiertos", "title": "Riesgos arquitectónicos abiertos", "required": true},
+        {"id": "bitacora-iteraciones", "title": "Bitácora de iteraciones", "required": true}
+      ],
+      "cardinality": "single",
+      "generation": {"source": "plugin", "skill": "setup-architecture"},
+      "descriptor_version": 1
+    }
+  ]
+}

package/commands/build/architect.md

@@ -0,0 +1,66 @@
+---
+name: "BUILD: Architect"
+description: Capa de arquitectura previa a construcción. Genera los ADRs del proyecto con el método ADD (Attribute-Driven Design, Len Bass) leyendo docs/ (PRD + user story map + epicas + HUs) de solo lectura, y puebla stack-allowlist.json. Corre autónomo y propone al máximo; una sola revisión humana al final. Adaptador delgado: delega en la skill setup-architecture. Sus ADRs se vuelven criterios que el DoR y el gate stack_arch exigen.
+category: Workflow
+tags: [build-harness, architecture, add, adr, trycore]
+---
+
+Genera la **capa de arquitectura** del proyecto **antes** del primer slice: decide estilo, tácticas y
+stack, y los deja como ADRs que el build ya exige. Este comando es un **adaptador delgado**: no
+reimplementa nada — **delega** en la skill `setup-architecture` (método ADD). Si algo aquí contradice
+`METODOLOGIA.md`, **gana la metodología**.
+
+**Entrada (opcional):** un foco de iteración (`"fase 2"`, `"observabilidad"`, `EP-XXX`). Si viene vacío,
+la skill corre el flujo completo desde el catálogo de drivers. La IA **propone al máximo**; no pregunta
+campo por campo.
+
+---
+
+## 1. Preflight
+
+```bash
+test -f .claude/.build-harness-version || echo "NOT_INSTALLED"
+command -v python3 >/dev/null 2>&1 || echo "NO_PYTHON3"
+# Discovery debe estar listo (entrada de solo lectura de la capa):
+test -d docs/03-backlog && ls docs/04-historias/HU-*.md >/dev/null 2>&1 || echo "NO_DISCOVERY"
+```
+
+- **`NOT_INSTALLED`** → ejecuta `trycore-build init` y vuelve. Stop si falta `python3`.
+- **`NO_DISCOVERY`** → no hay historias que leer: la capa de arquitectura corre **después** de discovery.
+  Remite a `@trycore/spec-product-flow` (`/trycore:*`) y detente. No escribas nada.
+
+---
+
+## 2. Conducir el flujo (delegar)
+
+Invoca la skill **`setup-architecture`**. La skill:
+
+1. Extrae el catálogo de drivers/ASRs → `docs/adr/0000-drivers-y-asrs.md` (delega en `asr-extractor`).
+2. Itera ADD (una ronda por fase/release): tácticas → estilos → vistas → ADR `docs/adr/000N-*.md`.
+3. Evalúa cada ADR (ATAM-lite, `architecture-evaluator`) y mantiene `docs/adr/_backlog-arquitectonico.md`.
+4. Hace **una** revisión final: escala solo trade-offs de negocio, promueve `proposed → accepted` y
+   consolida el stack en `.claude/config/stack-allowlist.json`.
+
+- **No** edites artefactos de discovery (`docs/01-prd/`…`docs/04-historias/`): la única salida en `docs/`
+  es `docs/adr/`.
+- **No** publiques: los ADRs se **proponen** (`proposed`/`living-document`); el humano promueve a `accepted`.
+- **No** abras un slice ni toques `build-state.json`: esta fase es **pre-build**.
+
+---
+
+## 3. Resumen
+
+Al terminar, resume: nº de drivers por tipo, nº de ADRs generados, estilo(s) y stack propuestos, riesgos
+abiertos del backlog, y el siguiente paso: `/build:work` o `/build:slice` (ahora el DoR ya puede exigir
+cobertura de ADR y `stack-guard` hace cumplir el stack).
+
+---
+
+## Guardrails
+
+- **Solo lectura sobre discovery**; la única escritura en `docs/` es `docs/adr/`.
+- **Propón, no publiques**: la promoción a `accepted` es del humano (revisión única).
+- **Mínimo HITL**: autónomo; se detiene como máximo en una `AskUserQuestion` de trade-offs de negocio.
+- **Incremental**: re-correr añade iteraciones; no regenera ADRs `accepted`.
+- **Agnóstico**: no asume dominio; entra por `docs/`.
+- Si algo contradice `METODOLOGIA.md`, **gana la metodología**.

package/docs/agents.md

@@ -1,7 +1,8 @@
 # Agentes de construcción (`agents/build/`)
 
-Los **12 agentes** de `@trycore/spec-build-harness` ejecutan los *gates* del arnés de
-construcción de dos loops. Ninguno edita código de producto: son read-only sobre el
+Los **14 agentes** de `@trycore/spec-build-harness` ejecutan los *gates* del arnés de
+construcción de dos loops (12 de ellos) o alimentan la **capa de arquitectura** previa a
+construcción (`asr-extractor` y `architecture-evaluator`, skill `setup-architecture`). Ninguno edita código de producto: son read-only sobre el
 repositorio (algunos ejecutan tests o levantan la app), diagnostican y **devuelven el
 veredicto al `build-orchestrator`**, que es quien propone la escritura del estado
 (`.claude/state/build-state.json`).
@@ -14,7 +15,10 @@ veredicto al `build-orchestrator`**, que es quien propone la escritura del estad
 > `coherence-three-way`, `stack-guardian`) corren **una vez por release** en el **outer loop**
 > (skill `releasing-a-version`) y escriben sus veredictos en `releases[].gates`
 > (`security`, `smell`, `ux`, `coherence`, `stack_arch` — este último renombrado desde el antiguo
-> `stack` por-slice).
+> `stack` por-slice). Los 2 agentes de **arquitectura** (`asr-extractor`,
+> `architecture-evaluator`) corren **antes de construir**, una vez por proyecto (o por
+> re-corrida incremental), en la skill `setup-architecture` (`/build:architect`): no cierran
+> gates del estado — su salida son los ADRs de `docs/adr/`, que el DoR y `stack_arch` luego exigen.
 >
 > **Conducción opcional vía plantillas de workflow.** Tres plantillas read-only (opt-in, no editan
 > estado) sirven de andamiaje para orquestar estos agentes sin sustituir su juicio:
@@ -37,6 +41,8 @@ veredicto al `build-orchestrator`**, que es quien propone la escritura del estad
 | 10 | `change-epic-coherence` | sonnet | Trazabilidad | Gate `coherence_link` — enlace change↔épica↔HU |
 | 11 | `ux-fidelity-reviewer` | sonnet | Inner loop · smoke | Gate `fidelity` — fidelidad visual a la fuente de diseño declarada (verificación visual real, MCP) |
 | 12 | `wiring-adversarial-verifier` | **opus** | Inner loop · dod | Gate `wiring_verified` — verificación adversarial independiente del cableado (refuta antes de cerrar `dod`) |
+| 13 | `asr-extractor` | sonnet | Capa de arquitectura | Extrae el catálogo de drivers/ASRs de discovery (entrada del método ADD) |
+| 14 | `architecture-evaluator` | sonnet | Capa de arquitectura | Evaluación ATAM-lite adversarial de cada ADR antes de programar |
 
 ---
 
@@ -162,3 +168,26 @@ e items de `wiring_checklist[]` aún `failing` o marcados `passing` sin `evidenc
 `gates.wiring_verified: true` (habilita `dod`); HUECOS → `false` (retrocede `phase`). Rompe la
 auto-confirmación del cierre prematuro: el DoD declarativo del `dor-dod-gatekeeper` es un piso, este
 agente es el arreglo.
+
+## Capa de arquitectura (pre-build)
+
+> Estos 2 corren **antes de construir**, en la skill `setup-architecture` (`/build:architect`),
+> una vez por proyecto o por re-corrida incremental. No cierran gates de `build-state.json`:
+> su salida son los ADRs de `docs/adr/`, que el DoR (cobertura de cimiento) y el gate
+> `stack_arch` del Release Gate luego exigen.
+
+### `asr-extractor` · modelo `sonnet` · read-only
+**Extractor de drivers/ASRs** (ADD Paso 1). Lee los artefactos de discovery (`docs/01-prd/` …
+`docs/04-historias/`) y **propone** el catálogo de entrada de diseño: objetivos de negocio (OE),
+casos de uso arquitecturalmente significativos (UC), escenarios de atributos de calidad (QA) en
+formato Bass de 6 partes con medida cuantificable, restricciones (CON), concerns (CRN), matriz de
+prioridad y plan de iteraciones. Trazabilidad obligatoria (cada driver cita su HU/OE/§PRD); no
+inventa dominio ni escribe archivos — devuelve la propuesta a la skill, que escribe
+`docs/adr/0000-drivers-y-asrs.md`.
+
+### `architecture-evaluator` · modelo `sonnet` · adversarial
+**Evaluador ATAM-lite** (ADD Paso 7). Dado un ADR propuesto y el catálogo `0000`, intenta
+**refutar** que la decisión satisface sus drivers: veredicto por driver con evidencia/medida
+(✅/⚠️/❌), puntos de sensibilidad, trade-offs y riesgos → alimenta §5/§6 del ADR y la sección de
+riesgos del backlog arquitectónico. No decide negocio (los trade-offs de negocio suben a la
+revisión única de la skill) y degrada seguro (sin catálogo legible → INCONCLUSO, nunca COHERENTE).

package/docs/commands.md

@@ -3,7 +3,7 @@
 Esta referencia cubre los **dos planos de operación** del arnés de construcción:
 
 1. El **CLI `trycore-build`** (binario Node, paquete `@trycore/spec-build-harness` v0.7.0) — instala, actualiza, diagnostica y desinstala el arnés en el proyecto consumidor. Captura el **stack mecánico**.
-2. Los **slash commands de Claude Code** (`/opsx:*` + los 7 `/build:*`: `onboard`, `reflect`, `slice`, `release`, `work`, `resume`, `front`) — operan el pipeline de dos loops, resuelven la parametrización **semántica** del dominio y capturan el conocimiento aprendido por slice.
+2. Los **slash commands de Claude Code** (`/opsx:*` + los 8 `/build:*`: `onboard`, `reflect`, `architect`, `slice`, `release`, `work`, `resume`, `front`) — operan el pipeline de dos loops, resuelven la parametrización **semántica** del dominio y capturan el conocimiento aprendido por slice.
 
 > **División de responsabilidades del onboarding (dos capas).** Un binario Node **no puede** escribir la auto-memory de Claude. Por eso `trycore-build init` siembra archivos y captura el stack mecánico (lenguaje/deps, package manager, runtime, ruta del PRD), y el slash command `/build:onboard` —ejecutado por Claude— lee el PRD, pregunta por PII / capa de servicios externos-IA / capa determinista / secretos / decisiones de alto impacto, resuelve los `{{placeholders}}` del bloque marcado de `CLAUDE.md` y escribe la auto-memory.
 
@@ -52,7 +52,7 @@ Solo `init` y `update` aceptan flags. `status`, `uninstall` y `doctor` toman ún
 
 ## 2. Slash commands de Claude Code
 
-El canal CLI namespacea por subcarpeta: `.claude/commands/opsx/` → `/opsx:*` y `.claude/commands/build/` → los 7 `/build:*` (`onboard`, `reflect`, `slice`, `release`, `work`, `resume`, `front`).
+El canal CLI namespacea por subcarpeta: `.claude/commands/opsx/` → `/opsx:*` y `.claude/commands/build/` → los 8 `/build:*` (`onboard`, `reflect`, `architect`, `slice`, `release`, `work`, `resume`, `front`).
 
 ### `/opsx:*` — pipeline OpenSpec
 
@@ -69,6 +69,12 @@ El canal CLI namespacea por subcarpeta: `.claude/commands/opsx/` → `/opsx:*` y
 | `/opsx:onboard` | Onboarding guiado: recorre un ciclo completo del workflow OpenSpec con narración (tutorial de aprendizaje). |
 | `/opsx:sync` | Sincroniza los delta specs de un cambio hacia los specs principales. |
 
+### `/build:architect` — capa de arquitectura (ADD), previa a construir
+
+| Slash command | Propósito |
+|---|---|
+| `/build:architect` | Fase **opcional pero recomendada** que corre **una vez, entre discovery y construcción**. Adaptador delgado: **delega** en la skill `setup-architecture` (método **ADD**, Attribute-Driven Design de Len Bass). Lee `docs/` de solo lectura (PRD + user story map + épicas + HUs), extrae **drivers/ASRs**, itera rondas (**tácticas → estilos → vistas → ATAM-lite**), decide el **stack** y escribe `docs/adr/` (`0000-drivers-y-asrs.md` + ADRs de 7 secciones + `_backlog-arquitectonico.md`); puebla `.claude/config/stack-allowlist.json`. **Autónomo y de propuesta máxima**: mínimo HITL (una revisión final; solo escala trade-offs de negocio). **Propone, no publica** (ADRs `proposed` → un humano los promueve). Sus decisiones se vuelven criterios: el **DoR** exige cobertura de ADR para el cimiento fundacional y el gate **`stack_arch`** audita conformidad. Delega en `asr-extractor` y `architecture-evaluator`. |
+
 ### `/build:slice` — entrada del inner loop
 
 | Slash command | Propósito |
@@ -120,7 +126,7 @@ El arnés se distribuye por **dos canales** que coexisten, pero **namespacean di
 | Aspecto | Canal **CLI** (canónico) | Canal **Plugin** nativo |
 |---|---|---|
 | Instalación | `npm i -g @trycore/spec-build-harness` → `trycore-build init` | `/plugin marketplace add <repo-github>` → `/plugin install trycore-spec-build-harness@trycore-build` |
-| Namespace de comandos | Por subcarpeta: `/opsx:*` y los 7 `/build:*` (`onboard`, `reflect`, `slice`, `release`, `work`, `resume`, `front`) | Por nombre del plugin: `/trycore-spec-build-harness:*` (por diseño de Claude Code) |
+| Namespace de comandos | Por subcarpeta: `/opsx:*` y los 8 `/build:*` (`onboard`, `reflect`, `architect`, `slice`, `release`, `work`, `resume`, `front`) | Por nombre del plugin: `/trycore-spec-build-harness:*` (por diseño de Claude Code) |
 | Referencia a agentes | Por su nombre (p. ej. `build-orchestrator`) | Bajo el nombre del plugin |
 | Cross-references internas | ✔ Escritas para este canal (skills invocan `/opsx:*`, agentes por nombre) | Pueden no resolver según están escritas |
 | Recomendación | **Usar este canal para operar un proyecto** | Conveniencia a nivel usuario |

package/docs/getting-started.md

@@ -48,7 +48,7 @@ npm i -g @fission-ai/openspec @trycore/spec-build-harness
 
 ## 2 · `trycore-build init` (terminal)
 
-Desde la raíz de tu proyecto. Es **idempotente** (re-correrlo es seguro) y siembra: **12 agentes**, **13 skills** (`building-a-slice`, `building-a-micro-change`, `releasing-a-version` + 10 `openspec-*`), **10 comandos `/opsx:*`** + **5 comandos `/build:*`** (`onboard`, `slice`, `release`, `reflect`, `work`), **10 hooks**, el estado vacío `.claude/state/build-state.json` (gitignored, nunca se sobreescribe) y el bloque `<!-- BEGIN trycore-build-harness -->` en tu `CLAUDE.md` con `{{placeholders}}` sin resolver.
+Desde la raíz de tu proyecto. Es **idempotente** (re-correrlo es seguro) y siembra: **14 agentes**, **15 skills** (`building-a-slice`, `building-a-micro-change`, `releasing-a-version`, `managing-parallel-front`, `setup-architecture` + 10 `openspec-*`), **10 comandos `/opsx:*`** + **8 comandos `/build:*`** (`onboard`, `reflect`, `architect`, `slice`, `release`, `work`, `resume`, `front`), **13 hooks**, el estado vacío `.claude/state/build-state.json` (gitignored, nunca se sobreescribe) y el bloque `<!-- BEGIN trycore-build-harness -->` en tu `CLAUDE.md` con `{{placeholders}}` sin resolver.
 
 ```bash
 trycore-build init