@trycore/spec-build-harness

Arnés agéntico de construcción de Trycore para Claude Code: el compañero de @trycore/spec-product-flow. Donde la vertical de producto cierra el discovery (PRD → backlog priorizado), este arnés toma ese backlog y lo lleva a código mergeado con calidad gobernada. La narrativa completa es Discovery → Construcción:

Discovery (@trycore/spec-product-flow)      Construcción (este arnés)
PRD → User Story Map → Backlog        →      slice por épica (TDD + gates) → release gate

Ambos paquetes coexisten en el mismo .claude/ sin colisión: namespaces disjuntos (trycore/ vs build/ + opsx/), archivos de versión separados (.trycore-version vs .build-harness-version) y bloques distintos en CLAUDE.md (<!-- BEGIN trycore-vertical --> vs <!-- BEGIN trycore-build-harness -->). El núcleo es 100% agnóstico al proyecto.

Cómo se usa (rápido)

Guía paso a paso: docs/getting-started.md — Quickstart de 0 a tu primer slice.

# 0) Requisito: OpenSpec (lo usan los comandos /opsx:* y las skills openspec-*)
npm install -g @fission-ai/openspec

# 1) Instalar el CLI global (una vez por máquina)
npm install -g @trycore/spec-build-harness

# 2) Instalar el arnés en un proyecto cliente (idempotente; siembra estado y allowlist)
cd /ruta/al/proyecto-cliente
trycore-build init

# 3) Abrir Claude Code y parametrizar (lee el PRD, resuelve los {{placeholders}})
/build:onboard

trycore-build init captura el stack mecánico (lenguaje/deps, package manager, runtime, ruta del PRD) por flags o por prompt TTY, y siembra los archivos. Luego /build:onboard —ejecutado por Claude— lee el PRD, pregunta por PII / capa-IA / capa-determinista / secretos / decisiones de alto impacto vía AskUserQuestion, resuelve los {{placeholders}} del bloque CLAUDE.md y escribe la auto-memory. Es un onboarding en dos capas porque un binario Node no puede escribir la auto-memory de Claude.

Alternativa: instalar como plugin nativo de Claude Code (sin npm)

/plugin marketplace add trycore-co/trycore-spec-build-harness
/plugin install trycore-spec-build-harness@trycore-build

Caveat de canales. Para operar dentro de un proyecto, usa el canal CLI (canónico): comandos namespaceados por subcarpeta (/opsx:*, /build:*) y agentes por nombre. El plugin los namespacea bajo su propio nombre (/trycore-spec-build-harness:*) y las cross-references internas asumen el canal CLI. Los hooks son idénticos en ambos canales (se deduplican si coexisten). Detalle → INSTALL.md.

Comandos del CLI trycore-build

| Comando | Para qué | |---|---| | trycore-build init | Instala el arnés en el proyecto (idempotente). Siembra estado, schema, allowlist y bloque CLAUDE.md. | | trycore-build update | Refresca assets y schema tras npm update -g. No pisa estado ni allowlist. | | trycore-build status | Muestra el estado de la instalación y la fase activa del arnés. | | trycore-build uninstall | Quita el arnés. Preserva .claude/state/ y .claude/config/. | | trycore-build doctor | Verifica requisitos externos (openspec/python3/git), hooks ejecutables y canales; reporta slices sin reflexionar y sugiere LSP en stacks tipados. |

Flags de init: --copy (copiar en vez de symlinkear), --yes (no interactivo), --skip-doctor, --force-init, --stack <deps>, --pkg-manager <pm>, --runtime <semver>, --prd-path <path>.

Los dos loops

El arnés modela la construcción como dos ciclos anidados, cada uno con su skill maestra:

Inner loop — building-a-slice (una vez por épica EP-XXX)

DoR → OpenSpec change → TDD → journey-smoke → api/data → DoD → PR + archive

Por cada épica del backlog: se valida el Definition of Ready, se abre un change en OpenSpec, se desarrolla con TDD, se corre el smoke del journey, se verifican contratos de API y consistencia de datos, se valida el Definition of Done y se cierra con PR + archivado del change. Tras archivar, /build:reflect puede capturar las convenciones aprendidas del slice (ciclo autocorrectivo, opcional; lo sugiere el hook reflect-nudge.sh).

Outer loop — releasing-a-version (una vez por release)

Gate de release que corre una sola vez por versión sobre el conjunto de slices acumulados: seguridad, diseño, UX, coherencia triple (spec ↔ código ↔ tests), arquitectura e integración.

Slash commands

| Command | Propósito | |---|---| | /build:onboard | Onboarding capa 2: lee el PRD, pregunta por PII/IA/determinismo/secretos, resuelve {{placeholders}} y escribe la auto-memory. Desde 0.18.0 declara además las fronteras externas (Fase 2d) y siembra config/build-config.json#boundaries[], la memoria que usan los items BND-* del checklist de cableado. | | /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. Sin señal, el carril no escala; señal de forma → slice, señal de requisito → discovery. | | /build:bugfix | Entrada directa al modo bugfix de building-a-micro-change: ancla al AC (HU-XXX/AC citable), reproduce ejecutando, arregla, re-ejecuta y valida el test de regresión por reversión. PR de cuatro líneas. | | /build:microwork | Entrada directa al modo microwork (mantenimiento sin bug): cambio → verificar → test solo si cambia comportamiento especificado → PR. | | /build:resume | Rehidrata el slice activo desde disco (no desde la conversación) tras un reinicio de contexto: reconcilia el estado, lee session_continuity/wiring_checklist/parallel_front y determina la siguiente acción por prioridad. | | /build:front | Abre y coordina un front paralelo de épicas no fundacionales y disjuntas en archivos (parallel_front), cada una en su worktree/rama/PR. Delega en la skill managing-parallel-front. | | /build:epic | Propone una épica incremental al hub (modo runtime): el agente redacta y propone, el hub asigna el EP-XXX al aprobar y un humano aprueba; después epicas.md se escribe como proyección del grafo. En legacy/dual no aplica. | | /build:graph-sync | Propone el re-sync del grafo del hub desde los docs de discovery (modo runtime): el hub calcula el delta y un humano lo aprueba — nada se aplica sin esa aprobación. Con --check lee el veredicto. Sin esto, el grafo del hub se quedaba en la foto del import inicial y los eventos de las épicas posteriores rebotaban. | | /opsx:* (10) | Ciclo OpenSpec: explore · new · continue · apply · verify · archive · bulk-archive · ff · onboard · sync. Detalle → docs/commands.md. |

Gestión de contexto

Las sesiones largas (una épica multicapa, un slice que se alarga) pueden agotar la ventana de contexto antes de terminar el cableado. El arnés lo mitiga con un motor de contexto que corre solo, sin que el humano lo invoque:

• Aviso por umbrales. El hook context-monitor.sh lee el contexto restante en cada PostToolUse/PreCompact/Stop y lo compara contra dos umbrales configurables (context.warning_pct: 35, context.critical_pct: 25 en build-config.json): por debajo del umbral de aviso, inyecta un recordatorio de acercarse a un punto de corte natural; por debajo del crítico (o en PreCompact), dispara un auto-handoff —una sola vez por sesión— que escribe en active_slice.session_continuity un resume_hint derivado de los items wiring_checklist aún failing, sin esperar a que el humano lo pida.
• /build:resume. Para retomar sin pérdida: reconcilia el estado contra disco y determina la siguiente acción por prioridad (resume_hint → primer item failing → siguiente sub_slice → fase del pipeline). Reconstruye el contexto desde el estado, nunca desde la conversación viva.
• config context.auto_checkpoint (opt-in, default false): si se activa, el handoff marca auto_continue: true para que la siguiente sesión retome automáticamente el resume_hint sin preguntar. Apagado por defecto porque el checkpoint automático es una decisión que el equipo debe optar explícitamente a tomar.
• Caveat de canal. El aviso proactivo depende de statusLine, un ajuste de settings.json que solo existe en el canal CLI (trycore-build init/update). En una instalación plugin-only no hay puente de contexto que leer y el motor degrada fail-open: no rompe nada, simplemente no avisa; /build:resume y el reconciliador de disco (ver abajo) siguen funcionando igual porque no dependen del puente.

El estado sigue anclado a disco entre sesiones: reconcile-build-state.py corre en cada SessionStart (y en /build:resume) y deriva la verdad desde git y la evidencia de tests —degrada a failing cualquier item wiring_checklist marcado passing sin evidence, anota branch drift si la rama real difiere de la del slice, y nunca revierte un gate booleano por sí mismo (ratchet)—. Fail-open siempre: un estado ilegible o git ausente no bloquean la sesión.

Front paralelo

Cuando hay ≥ 2 épicas de negocio (layer: business) listas (DoR pasado) y disjuntas en archivos, el comando /build:front (skill managing-parallel-front) las construye en paralelo, cada una en su propio git worktree/rama/PR — el inner loop no cambia: cada worktree mantiene su active_slice singular y su propio build-state.json. Tres compuertas gobiernan el front (más una compuerta cero, de identidad, cuando se corre contra el hub):

0. Un agente por worktree, un token por agente (modo runtime). Cada árbol se da de alta con slice-ops.sh register y un token que el ADMIN emitió para él: el hub deriva el agent_key del token, así que dos worktrees con el mismo token son un solo agente. Un árbol sin dar de alta hereda las credenciales del clon principal y lo suplantaría — por eso toda escritura desde él aborta con rc 9.
1. Foundational-first. Ninguna épica layer: foundational entra jamás al front; si una aparece mientras el front está activo, el front pasa a status: "draining" (termina lo que ya empezó, no admite épicas nuevas) hasta vaciarse.
2. Disjunción por files_scope y por el grafo. scripts/lib/front-plan.py calcula, por conjuntos de globs declarados en cada épica, qué candidatas son mutuamente disjuntas (selected) y cuáles deben esperar (serialized) por solaparse. Sin files_scope declarado una épica no es candidata (se serializa), y dos épicas unidas por un camino en el DAG de depends_on tampoco van juntas aunque sus ficheros sean disjuntos.
3. Merge en orden + re-smoke. El merge de los worktrees sigue un merge_order determinista; tras cada merge se re-corre el journey_smoke completo en el árbol principal. Un conflicto no detectado por la disjunción declarada lo caza el re-smoke: la épica perdedora se serializa (rebase + re-correr sus gates) en vez de abortar el front.

Arquitectura

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/              ← 14 agentes revisores (segunda opinión, contexto limpio)
├── commands/
│   ├── opsx/                  ← 10 comandos /opsx:* (ciclo OpenSpec)
│   └── build/                 ← 16 comandos /build:* (onboard, reflect, architect, prototype, slice, release, work, bugfix, microwork, resume, front, claim, status, escalate, epic, graph-sync)
├── skills/                    ← 16 skills (building-a-slice, building-a-micro-change, releasing-a-version, managing-parallel-front, setup-architecture, prototyping-screens, 10 openspec-*) + 3 plantillas *.workflow.js (opt-in, read-only)
├── hooks/build/               ← 19 hooks (gate-check, reflect-nudge, release-gate-nudge, scaffold-guard, gitflow-guard, stack-guard, statusline-bridge, context-monitor, reconcile-build-state, …) + 6 opt-in del cliente runtime (session-start, event-emitter, context-sync, heartbeat, dual-compare, session-stop — ver docs/hooks.md)
├── state/                     ← máquina de estado legacy: build-state.json + schema + README
├── config/                    ← build-config.template.json (umbrales de contexto + runtime.mode) + stack-allowlist.template.json (artefacto del consumidor)
├── src/ + dist/               ← CLI trycore-build (init/update/status/uninstall/doctor/migrate)
├── scripts/                   ← installer + guardias (check-version-sync/agnostic/state-clean)
└── docs/examples/reference/   ← ejemplo de referencia (fuera del core, excluido de check-agnostic)

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/.

Modo runtime (beta, opcional)

El arnés puede correr el mismo pipeline contra un Agent Orchestrator Runtime remoto en vez de (o además de) build-state.json — útil para flotas de varios agentes sobre un mismo proyecto. Es opt-in: legacy (el fichero local) sigue siendo el default y el único camino con soporte completo. Activarlo: trycore-build init --runtime-url <url> --runtime-token <token> (el token lo emite un ADMIN en la consola del hub). Guía paso a paso → docs/runtime/guia-modo-dual-y-migracion.md.

Requisitos

init y doctor fallan si falta cualquiera de estos:

| Requisito | Por qué | Instalación | |---|---|---| | openspec | Lo usan los comandos /opsx:* y las skills openspec-*. | npm i -g @fission-ai/openspec | | python3 | Los hooks parsean JSON con python3. | Según el sistema operativo | | git | Flujo de ramas / PRs / archivado de changes. | Según el sistema operativo |

Runtime Node >=18.0.0.

Agnóstico al proyecto

El core no menciona ningún dominio de cliente. Toda parametrización entra por el bloque CLAUDE.md (<!-- BEGIN trycore-build-harness -->), la auto-memory que escribe /build:onboard y las preguntas en runtime. El ejemplo de referencia vive en docs/examples/reference/ —fuera del core y excluido de check-agnostic— para que nunca contamine los assets distribuibles. Las guardias de prepublishOnly lo blindan: check-version-sync + check-agnostic + check-state-clean.

Roadmap

• ✅ v0.18.0 (actual) — frontera verificada antes de construir (#78) — un slice cerraba tdd con suites verdes, mutación al 100 % y journey end-to-end, y aun así contenía código que no podía funcionar: toda la evidencia se había producido contra dobles escritos por el mismo agente, y el contrato del proveedor externo estaba inventado (caso de campo: primera llamada real → 422). La mutación prueba que los tests son sensibles, no que la premisa sea cierta. Ahora las fronteras externas (servicio de terceros, motor de datos, cola, SDK, documento a interpretar) se declaran una vez en config/build-config.json#boundaries[] (/build:onboard, Fase 2d, derivadas del PRD técnico y confirmadas en bloque), y cada slice que las toca —por join determinista paths ∩ files_scope ∪ HU que las citan, cero preguntas por slice— siembra un item BND-<frontera>-<forma> en wiring_checklist[] por cada forma de mensaje aún no verificada: tdd no cierra con uno en failing, la evidencia es un resumen hasheado del intercambio real (el doble no cuenta; lo caza el wiring-adversarial-verifier) y la forma verificada queda en boundaries[].verified[] como memoria por proyecto: una interacción por forma nueva, una vez, sin caducidad por sha. na solo por catálogo cerrado, custodiado por datos en el gate integration. Sin gate ni fase nuevos, sin cambio de schema, sin cambios en el hub. Consumidores ya onboardeados: ausente ≠ vacío (STOP determinista hasta declarar boundaries o []).
• ✅ v0.17.0 — fast-track de bugfix (#79) — un bug de tres líneas recorría los nueve gates del slice porque el límite duro «cambia lógica de dominio» se tragaba casi cualquier bug y el router escalaba «ante la duda». El límite 3 pasa a «cambia el comportamiento especificado»: corregir código para que cumpla un AC que ya existe no es cambiar el dominio, es cumplirlo. Dos entradas propias al carril ligero, sin router: /build:bugfix (anclar al HU-XXX / AC n que el comportamiento viola → reproducir ejecutando lo más barato que evidencie el fallo → arreglar → re-ejecutar → test de regresión escrito después y validado revirtiendo el fix → PR de cuatro líneas) y /build:microwork (mantenimiento). Escalada por señales, no por duda, con dos destinos: forma (dependencia, API, migración) → slice; requisito (un AC cambia o falta, HU nunca cableada) → discovery. Sin presupuesto de tiempo. Con un slice activo, build-gate-check, context-monitor y load-build-state distinguen la rama de mantenimiento fix/*|chore/*, y el aviso legacy de build-gate-check.sh vuelve a verse tras versiones mudo por un 2>/dev/null.
• ✅ v0.16.0 — identidad por árbol de trabajo (#74) — construir dos épicas en paralelo en la misma máquina, una por git worktree, ya es una operación segura. El reparto nunca fue el problema del hub —ya entrega dos épicas a dos agentes sin objeción—: el bloqueo estaba en el cliente. El estado del arnés está en .gitignore y no viaja a un worktree, así que el árbol nuevo heredaba en silencio las credenciales del clon principal y lo suplantaba: reclamaba con su agent_key, reportaba los sha del árbol equivocado (cegando la detección de drift justo en el escenario paralelo) y compartía su heartbeat. Ahora toda escritura desde un árbol sin dar de alta aborta con rc 9 antes de abrir un socket (las lecturas siguen, y status avisa con identidad: ⚠ HEREDADA), y el alta es explícita: slice-ops.sh register, con el token por stdin —nunca por argumento—, siembra local antes de tocar la red, verificación de que el agent_key difiera del principal y rollback total ante cualquier fallo. Dato que corrige la documentación anterior: POST /agents/register no crea identidad —el agent_key es el agent_id grabado en el token por el ADMIN—, así que es un token por agente, no uno por proyecto. Además, front-plan.py cierra tres fallos silenciosos: layer normalizado (el bundle del grafo emite FOUNDATIONAL y la exclusión foundational-first podía no disparar), fail-closed sin files_scope declarado, y serialización de los pares con camino en el DAG de depends_on.
• ✅ v0.15.0 — el arnés propone el re-sync de su grafo (EP-OR-17) — el grafo del hub se sembraba una vez, con el import de admin de /build:onboard, y ahí se quedaba: las épicas que discovery escribía después no tenían por dónde entrar y todos los eventos de un slice cuya épica falta rebotan. Comando /build:graph-sync (+ --check) y subcomandos graph-sync/ graph-sync-status: el arnés construye el bundle desde los docs, el hub calcula el delta y un humano aprueba en la consola — nada se aplica sin esa aprobación; tras ella, las historias nuevas entran solas al reparto del claim. client_event_id determinista para que el reintento deduplique en vez de dejar dos propuestas del mismo grafo esperando. En el camino, dos defectos vivos desde antes: el 409 se leía en la raíz y con un nombre que no existe en el backend (el claim no reintentaba ante grafo rancio ni ante drift), y el espejo del modo dual era un 422 el 100 % de las veces (mandaba un cuerpo que el contrato no tiene). Total: 14 comandos /build:*.
• ✅ v0.14.0 — contexto vivo, épicas propuestas y versión de grafo (#61, #62, #63) — tres capacidades del cliente del runtime que componen entre sí. (1) El daemon de heartbeat refresca GET /agent/context con cadencia propia (runtime.context_refresh_s, default 45 s, 0 la desactiva): antes la caché se hidrataba al arrancar la sesión y en cada claim —y el claim ocurre una vez por slice—, así que una terminal abierta podía trabajar horas contra una foto vieja; un refresco fallido conserva la caché anterior y la marca stale, porque quedarse sin proyección dejaría al agente huérfano. (2) En modo runtime la épica se propone al hub en vez de escribirse en el backlog: comando nuevo /build:epic, subcomandos propose-epic/epic-status/epic-writeback y un carril directo en la cola offline que sobrevive a quedarse sin red; el hub asigna el EP-XXX al aprobar y docs/03-backlog/epicas.md pasa a ser proyección del grafo, nunca una fuente paralela —el agente pierde la potestad de inventar identidades, que es lo que hacía colisionar las historias de dos épicas creadas el mismo día—. (3) claim y la propuesta mandan la versión de grafo conocida, estampada al despachar y no al encolar; un 409 por grafo rancio provoca refresco y un reintento en vez de un fallo. legacy sigue siendo el default y no cambia. Las mitades de servidor de (2) y (3) ya existen en el hub, en el carril del agente (/projects/{id}/agent/epic-proposals), y la v0.14.2 alineó al cliente con ese contrato: hasta entonces pegaba contra la ruta de consola y la propuesta moría con 405/422 (#70). Contra un hub que no lo exponga, el cliente degrada a «instancia sin soporte». Total: 14 agentes, 19 hooks, 13 comandos /build:*, 16 skills.
• ✅ v0.13.0 — el grafo llega al hub con aristas — las dependencias entre épicas viven como prosa en epicas.md (**Depende de**: EP-001) y su lectura estaba delegada al modelo, con un ejemplo en /build:onboard que mostraba "depends_on": []: las 41 épicas del piloto entraron sin una sola arista y nadie lo detectó, porque un grafo vacío no falla, solo empobrece (#56). graph-bundle.py gana un extractor determinista (--from-docs / --print-deps) que relee el campo, con avisos de cobertura y traza de la fuente en depends_on_source. Además, unmapped[].original viaja siempre como dict (#55): el hub valida el bundle entero con pydantic, así que un escalar lo rechazaba completo antes de persistir nada.
• ✅ v0.12.0 — la fase del slice llega al hub (#52) — el hub modela la fase con eventos phase_advanced de orden estricto y exige phase == pr para archivar, pero el cliente no emitía ninguna: los slices quedaban «en construcción» con su PR ya mergeado. Subcomando slice-ops.sh phase <to>, que emite la cadena que falte (idempotente, sin saltos), y catch-up automático al archivar. Además, outbox/rejected/ deja de ser invisible: la razón del rechazo se persiste en el propio fichero y la muestran slice-ops.sh status y trycore-build status/doctor.
• ✅ v0.11.1 — auto-cierre de releases en verde — el cierre manual de una release con 6/6 gates PASS era control-teatro: el hub la cierra solo (closed_by: AUTO_6_OF_6_PASS) y los casos degradados siguen siendo decisión humana. Arreglado también que release-ops.sh verdict devolvía 422 en todo reporte (faltaba el campo verdict en mayúsculas junto a status).
• ✅ v0.11.0 — drift cliente↔hub del primer piloto real (#36–#44) — la primera migración contra el hub en producción reveló un desajuste sistemático entre lo que el cliente emite y lo que el hub valida: claim devolvía 422 en todo intento, la cola offline nunca drenaba, fact emitía tipos fuera del catálogo, claim --epic se ignoraba en silencio y repartía otra épica, y el import rechazaba 36 de 41 entradas del bundle histórico. Cada fix verificado contra el código real del hub, con regresión anti-drift nueva que valida todo tipo encolable contra una réplica literal de su catálogo.
• ✅ v0.10.0 — convergencia del inner loop — ataque a los seis multiplicadores de latencia de la verificación adversarial (iniciativa #31, issues #25–#30) sin bajar el rigor: re-verificación incremental con verified_at_sha por item de wiring_checklist[] (las pasadas 2+ re-ejecutan O(items tocados), no O(items totales)); condición de parada del bucle adversarial (máx. 2 pasadas completas por slice; lo diferido se declara en el PR y lo custodia el Release Gate; excepción única: hallazgo ALTA en código preexistente → pasada extra acotada); carril micro blindado (building-a-micro-change exento de mutación obligatoria/evidencia anclada/regresión con worktree — 1 test de regresión + suite del módulo en verde); presupuesto de mutación (obligatoria solo para tests que sostienen items del checklist); evidencia en dos clases (determinista → HEAD; viva → último commit del módulo medido, anchored_at.sha/head_at_run); y baseline de regresión cacheado por sha (assets/baseline-verdict.sh: capture/compare contra origin/<destino> con guard contra refs locales). Nuevos references evidence-budget.md y regression-baseline.md; superficies sincronizadas en METODOLOGIA §1-bis/§3.2/§10.
• ✅ v0.9.0 — beta/opt-in, EP-OR-08 — cliente del Agent Orchestrator Runtime, opt-in, sin cambiar el default: el mismo pipeline de dos loops puede correr contra un servidor remoto en vez de (o además de) build-state.json. 6 hooks nuevos (session-start, event-emitter, context-sync, heartbeat, dual-compare, session-stop), slice-ops.sh/ release-ops.sh (13 subcomandos que conducen las skills), 3 comandos nuevos (/build:claim, /build:status, /build:escalate), CLI extendido (init --runtime-url/--runtime-token, doctor/status con sección Runtime, migrate). Esta versión NO es "el corte": el paso a runtime como único camino y el retiro del legacy esperan a un piloto real sin discrepancias (release posterior) — ver docs/runtime/guia-modo-dual-y-migracion.md. Total: 19 hooks, 12 comandos /build:*.
• ✅ v0.1.0 — arnés de dos loops (building-a-slice + releasing-a-version), 10 agentes, comandos /opsx:* + /build:onboard, 12 skills, 6 hooks, máquina de estado build-state.json, allowlist de stack, CLI trycore-build (init/update/status/uninstall/doctor) y plugin nativo. Compañero de @trycore/spec-product-flow.
• ✅ v0.2.0 — scaffold como "Paso 1 fundamental": gate de proyecto scaffold.confirmed (confirmación explícita, no auto), Fase 0 en building-a-slice, criterio duro de DoR y hook scaffold-guard.sh. El arnés exige el scaffold pero no lo genera.
• ✅ v0.3.0 — ciclo autocorrectivo (hook reflect-nudge.sh + comando /build:reflect: propone convenciones aprendidas al bloque trycore-build-learnings de CLAUDE.md tras tu aprobación; campos reflected/reflected_at) y LSP opt-in (docs/customization/lsp-extensions.md + sugerencia en doctor para stacks tipados). Total: 8 hooks; comandos /opsx:* + /build:onboard + /build:reflect.
• ✅ v0.4.0 — carril building-a-micro-change (mantenimiento ligero sin slice) + DoR proporcional a la complejidad.
• ✅ v0.5.0 — seguro de fuente de diseño (design_source + design-source-guard.sh) + agente ux-fidelity-reviewer (gate fidelity, inner loop). Total: 11 agentes, 9 hooks.
• ✅ 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 — 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.5 — generador de prototipos HTML de referencia: comando /build:prototype + skill prototyping-screens que producen la fuente de diseño (DESIGN_SOURCE) en docs/05-prototipo/ (DESIGN.md + tokens.css + manifest.json pantalla↔épica/HU + un HTML autocontenido por pantalla). Dos modos: greenfield (inventario desde PRD/mapa/historias → dirección estética con 2-3 variantes a elección humana → generación por lotes) y feature (pantallas de una épica nueva con extracción viva obligatoria del UI implementado: CSS computado + screenshots en 3 viewports vía MCP; sin degradación estática). Auto-verificación visual (render real, máx. 3 iteraciones, sin pixel-diff) y aprobación humana de cada pantalla (borrador→aprobada); ux-fidelity-reviewer resuelve pantallas vía manifest.json (solo aprobada). La regla "el arnés no genera el prototipo" evoluciona a "puede generarlo; design_source.confirmed sigue siendo humano". 4º carve-out de escritura en docs/ (§9.2). Total: 14 agentes, 13 hooks, 9 comandos /build:*, 16 skills.
• ✅ v0.8.4 — épica caparazón obligatoria en greenfield: nuevo campo project_kind con detección automática conservadora en trycore-build init (brownfield seguro = manifiesto + código + historial git con commits de código; ambigüedad → una sola pregunta en /build:onboard; en brownfield el mecanismo es N/A total, sin preguntar) y gate de proyecto foundation: contrato del caparazón (navegación/menús · layout/panel central · homepage · login/authN · redirecciones/guards) como checklist podable con evidencia de ejecución por ítem (patrón wiring_checklist, contrato en skills/building-a-slice/references/foundation-contract.md). /build:onboard Fase 2c poda el contrato y redacta el borrador híbrido de la épica (solo se escribe en epicas.md con aprobación humana explícita — carve-out §9.2). DoR 7-bis proactivo: en greenfield ninguna épica business abre slice hasta que la caparazón esté archivada con checklist evidenciada (foundation.completed_at); las fundacionales y el carril micro-change nunca se bloquean. Línea Caparazón en status/doctor. Retrocompatible: campos opcionales del schema.
• ✅ v0.8.3 — 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

Uso interno de Trycore.