@trycore/spec-build-harness 0.6.0 → 0.7.0

package/commands/build/slice.md

@@ -0,0 +1,93 @@
+---
+name: "BUILD: Slice"
+description: Punto de 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 delegando en la skill building-a-slice (o el agente build-orchestrator para épicas multicapa). Respeta el orden estricto de gates y el scaffold como precondición.
+category: Workflow
+tags: [build-harness, inner-loop, slice, trycore]
+---
+
+Lanza el **inner loop** de construcción sobre una épica. Este comando es un **adaptador delgado**: no
+reimplementa el pipeline — **delega** en la skill `building-a-slice` (motor del inner loop) y en `opsx:*`
+(motor de changes). Si algo aquí contradice `METODOLOGIA.md`, **gana la metodología**.
+
+**Entrada:** `EP-XXX` o una descripción de la épica. Si viene vacío, usa **AskUserQuestion** para elegir la
+épica desde `docs/03-backlog/epicas.md`.
+
+---
+
+## 1. Preflight
+
+```bash
+test -f .claude/.build-harness-version || echo "NOT_INSTALLED"
+command -v python3 >/dev/null 2>&1 || echo "NO_PYTHON3"
+```
+
+**Si `NOT_INSTALLED`:** este proyecto no tiene el arnés instalado → ejecuta `trycore-build init` y vuelve.
+Stop si no está instalado o falta `python3`.
+
+---
+
+## 2. Leer el estado y decidir punto de entrada
+
+```bash
+python3 - <<'PY'
+import json, os, sys
+p = ".claude/state/build-state.json"
+if not os.path.exists(p): print("NO_STATE"); sys.exit(0)
+try: d = json.load(open(p))
+except Exception as e: print("CORRUPT_STATE", e); sys.exit(0)
+s = d.get("active_slice")
+if not s:
+    print("START dor")
+else:
+    g = s.get("gates", {})
+    abierto = next((k for k, v in g.items() if v is False), None)
+    print(f"RESUME {s.get('epica')} fase={s.get('phase')} primer_gate_abierto={abierto}")
+PY
+```
+
+- `NO_STATE`/`CORRUPT_STATE` → reporta y detente (no escribas).
+- `START dor` → no hay slice activo: arranca en **dor** con la épica objetivo.
+- `RESUME …` → ya hay un slice activo: **reanuda en su primer gate abierto** (no abras otro: el modelo es
+  secuencial, un solo slice activo).
+
+---
+
+## 3. Precondición de scaffold (y fuente de diseño si hay UI)
+
+Antes de escribir código de slice, verifica los gates de proyecto:
+
+- `scaffold.confirmed` debe ser `true`. Si es `false` → **STOP**: delega en la **Fase 0** de `building-a-slice`
+  (pregunta explícita; el arnés **no genera** el scaffold). No abras el slice.
+- Si el proyecto tiene UI, `design_source.confirmed` debe ser `true` (Fase 0-bis). Si no → **STOP** igual.
+
+El hook `scaffold-guard.sh` respalda esto en tiempo real.
+
+---
+
+## 4. Conducir el pipeline (delegar)
+
+Invoca la skill **`building-a-slice`** para conducir el inner loop. Para una épica **multicapa / grande**
+(superó el gate de tamaño → `sub_slices[]`), invoca el agente **`build-orchestrator`** (trabaja por fases
+encadenadas y, opcionalmente, conduce la exploración solo-lectura con `workflows/explore-fanout.workflow.js`).
+
+- **No** ejecutes `opsx:apply` directamente ni saltes gates: el orden es estricto
+  (`dor → change → tdd → smoke → api/data → dod → pr`).
+- **No** dispares reviewers pesados aquí (`security`, `smell`, `ux`, `coherence`, `stack_arch`): pertenecen
+  al **Release Gate** (`/build:release`). Hacerlo por slice rompería el modelo de dos loops.
+
+---
+
+## 5. Resumen
+
+Al terminar el paso, resume: fase actual, gates cerrados/abiertos y el siguiente gate. Si la épica quedó
+archivada, recuerda el default del Release Gate (ver `/build:release`).
+
+---
+
+## Guardrails
+
+- **Un solo slice activo** (secuencial). No abras un segundo mientras haya `active_slice`.
+- **Orden estricto de gates**; un gate no se salta. `dod` exige `wiring_verified: true`.
+- **Sin scaffold confirmado, no hay slice** (el arnés lo exige pero no lo genera).
+- **Agnóstico**: este comando no asume dominio; lo específico entra por `/build:onboard` y `stack-allowlist.json`.
+- Si algo contradice `METODOLOGIA.md`, **gana la metodología**.

package/commands/build/work.md

@@ -0,0 +1,68 @@
+---
+name: "BUILD: Work"
+description: Router de entrada (classify-and-act) del arnés. Clasifica el trabajo entrante y enruta a la skill correcta — building-a-micro-change (mantenimiento), building-a-slice (épica/producto nuevo) o releasing-a-version (Release Gate) — codificando los límites duros del micro-change y el default del Release Gate. Es RUTEO, no política: no ejecuta el pipeline, no toca el estado ni crea ramas.
+category: Workflow
+tags: [build-harness, router, classify-and-act, trycore]
+---
+
+**Router puro.** Decide *qué carril* aplica y **delega** en la skill correspondiente. NO ejecuta el pipeline,
+NO escribe `build-state.json`, NO crea ramas. Codifica como **ruteo** (no política nueva) el *decision gate*
+del micro-change y el default del Release Gate de `METODOLOGIA.md` (§2, §4). Si algo contradice la metodología,
+**gana la metodología**.
+
+**Entrada:** una descripción del trabajo a hacer.
+
+---
+
+## 1. Preflight
+
+```bash
+test -f .claude/.build-harness-version || echo "NOT_INSTALLED"
+```
+
+Si `NOT_INSTALLED` → ejecuta `trycore-build init` y vuelve.
+
+---
+
+## 2. Clasificar (decision gate)
+
+Aplica las reglas en orden:
+
+1. **¿Mantenimiento sin capacidad nueva?** — typo, ajuste de copy/config/docs, bump de dependencia **ya
+   permitida**, o fix de **pocas líneas** sin nueva capacidad **Y** sin ninguno de los límites duros del
+   paso 3 → carril **`building-a-micro-change`** (`fix/*`|`chore/*` → PR, **sin** abrir `active_slice`).
+2. **¿Producto nuevo / una épica?** — capacidad nueva, o cualquier límite duro cruzado → carril
+   **`building-a-slice`** (una épica `EP-XXX` = un slice = un change = una rama = un PR). Si no hay épica aún,
+   el trabajo vuelve a discovery para crearla.
+3. **¿Toca correr el Release Gate?** — la épica recién archivada **cierra una línea de release** del Story Map,
+   o hay **≥ 2 épicas archivadas** desde el último entry de `releases[]` → sugiere el carril
+   **`releasing-a-version`** (outer loop). (El destino es la skill existente; este router no depende de
+   `/build:release`.)
+
+---
+
+## 3. Límites duros del micro-change (escalan a épica)
+
+Si el cambio **añade una dependencia nueva**, **crea un endpoint/API nuevo**, o **toca lógica de dominio o el
+modelo/invariantes de datos** → **deja de ser micro-change** y se enruta a **`building-a-slice`** (épica).
+**Ante la duda, SIEMPRE épica.**
+
+---
+
+## 4. Actuar (delegar) — con degradación headless
+
+- **Con TTY**: confirma la clasificación con **una sola** `AskUserQuestion` (ofrece el carril propuesto como
+  primera opción "(Recomendado)") y luego invoca la skill elegida.
+- **Sin TTY / headless / entrada ausente**: **no bloquees**. Clasifica determinísticamente y emite por stdout
+  `{clasificación, skill recomendada, criterio que disparó la rama}`. Si es **ambiguo**, aplica el **default
+  duro**: escalar a épica → `building-a-slice`, declarándolo explícitamente.
+
+---
+
+## Guardrails
+
+- **Solo ruteo.** No corres el pipeline, no tocas el estado, no creas ramas: eso es de las skills destino.
+- **Ante la duda, épica.** Nunca degrades un cambio con límite duro a micro-change.
+- **No dupliques gates** ni saltes el orden: las skills destino los gobiernan.
+- **Agnóstico**: vocabulario genérico del arnés; lo específico del dominio entra por `/build:onboard`.
+- Si algo contradice `METODOLOGIA.md`, **gana la metodología**.

package/docs/super-power-workflows.md

@@ -0,0 +1,281 @@
+![](https://cdn.prod.website-files.com/68a44d4040f98a4adf2207b6/6903d22e13864f88ea55c2d8_b5c98d26c46edc43193e7f7e28a00633a538bb9c-1000x1000.svg)
+
+# 
+
+A
+
+harness
+
+for
+
+every
+
+task:
+
+dynamic
+
+workflows
+
+in
+
+Claude
+
+Code
+
+Claude Code can now write and orchestrate its own multi-agent harness on the fly. Here's how dynamic workflows work, and the patterns that get the most out of them.
+
+‍
+
+[](#)
+
+[](#)
+
+Get Claude Code
+
+curl -fsSL https://claude.ai/install.sh | bash
+
+Copy command to clipboard
+
+irm https://claude.ai/install.ps1 | iex
+
+Copy command to clipboard
+
+Or read the [documentation](https://code.claude.com/docs/en/overview)
+
+Try Claude Code
+
+[Try Claude Code](https://claude.ai/redirect/claudedotcom.v1.e9ed21ea-4023-46bb-ad88-1ac576336b09/code)Try Claude Code
+
+Developer docs
+
+[Developer docs](https://code.claude.com/docs/en/overview)Developer docs
+
+*   Category
+    
+    [Claude Code](https://claude.com/blog/category/claude-code)
+    
+*   Product
+    
+    No items found.
+    
+*   Date
+    
+    June 2, 2026
+    
+*   Reading time
+    
+    5
+    
+    min
+    
+*   Share
+    
+    [Copy link](#)
+    
+
+Last week, we released [dynamic workflows](https://code.claude.com/docs/en/workflows) in Claude Code. Claude can now write its own  [harness](https://code.claude.com/docs/en/glossary#agentic-harness) on the fly, custom-built for the task at hand.
+
+While the default Claude Code harness is built for coding, it is also useful for many other types of tasks because, as it turns out, many tasks resemble coding tasks. But there are certain classes of tasks where we have had to build custom harnesses on top of Claude Code to achieve peak performance such as [Research](https://support.claude.com/en/articles/11088861-using-research-on-claude), [security analysis](https://support.claude.com/en/articles/11932705-automated-security-reviews-in-claude-code), [agent teams](https://code.claude.com/docs/en/agent-teams), or [Code Review](https://code.claude.com/docs/en/code-review).
+
+Workflows allow you to dynamically create harnesses built on top of Claude Code that enable Claude to solve all of those problems more natively. You can also share and reuse these workflows with others.
+
+In this article, I’ll cover my initial workflows experiences and learnings so you can best take full advantage. Keep in mind, best practices are still developing: dynamic workflows often use more tokens and are best suited for complex, high value tasks.
+
+## Example prompts
+
+Before diving into the technical details, I’d like to start with several example prompts to get you thinking about the possibilities with workflows:
+
+"This test fails maybe 1 in 50 runs. Set up a workflow to reproduce it. Form competing theories about the race, and don't stop until one theory survives the evidence." 
+
+"Using a workflow, go through my last 50 sessions and mine them for corrections I keep making and turn the recurring ones into `CLAUDE.md` rules"
+
+“Use a workflow to dig through #incidents in Slack for the past six months and find recurring root causes where nobody has filed a ticket." 
+
+"Take my business plan and run a workflow where different agents tear it apart from an investor's, a customer's, and a competitor's perspective." 
+
+"Here's a folder of 80 resumes, use a workflow to rank them for the backend role and double-check the top ten. Interview me using the AskUserQuestion tool for a rubric."
+
+"I need a name for this CLI tool. Use a workflow to brainstorm a bunch of options and run a tournament to pick the top 3." 
+
+"Use a workflow to rename our User model to Account everywhere." 
+
+“Go through my blog post draft and verify every technical claim against the codebase using a workflow, I don't want to ship anything wrong."
+
+## How dynamic workflows work
+
+Dynamic workflows execute a javascript file with a few special functions that help spawn and coordinate [subagents](https://code.claude.com/docs/en/sub-agents):
+
+![](https://cdn.prod.website-files.com/68a44d4040f98a4adf2207b6/6a1f1684f559cc83ff4b465b_image1.png)
+
+Dynamic workflows also include standard JavaScript functions like JSON, Math, and Array, to help process data.
+
+It’s particularly useful to know that dynamic workflows can decide which models an agent uses and whether subagents are run in their own worktree, allowing Claude to choose the intelligence level and isolation needed.
+
+If a workflow is interrupted, for example by user action or quitting the terminal, resuming the session will allow the workflow to pick up where it left off.
+
+## Why dynamic workflows 
+
+When you ask the default Claude Code harness to do a task, it needs to both plan and execute in the same context window. For many coding tasks, this is highly effective, but it can break down over long-running, massively parallel, highly structured and/or adversarial tasks.
+
+This is because the longer Claude works on a complex task in a single context window, the more it becomes susceptible to a few specific failure modes:
+
+*   **Agentic laziness** refers to when Claude stops before finishing a particularly complex, multi-part task and declares the job done after partial progress, for example addressing 35 of the 50 items in a security review.
+*   **Self-preferential bias** refers to Claude’s tendency to prefer its own results or findings, especially when asked to verify or judge them against a rubric. 
+*   **Goal drift** refers to the gradual loss of fidelity to the original objective across many turns, especially after compaction. Each summarization step is lossy, and details like edge-case requirements or "don't do X" constraints can get lost.
+
+Creating a workflow helps combat these by orchestrating separate Claude subagents with their own context windows and focused, isolated goals.
+
+## Dynamic vs static workflows
+
+You may have previously created a static workflow using the Claude Agent SDK or `claude -p` to coordinate multiple instances of Claude Code together. 
+
+But because static workflows need to work for all edge cases, they are usually more generic. With [Claude Opus 4.8](https://www.anthropic.com/news/claude-opus-4-8) and dynamic workflows, Claude is now intelligent enough to write a custom harness tailor-made for your use case.
+
+![](https://cdn.prod.website-files.com/68a44d4040f98a4adf2207b6/6a1f3a0e17e2844bed86f22a_image9.png)
+
+## Helpful patterns when using dynamic workflows
+
+You can start using dynamic workflows just by asking Claude to make one, or by using the trigger word “`ultracode`” to ensure that Claude Code creates a workflow. 
+
+But building a mental model for how dynamic workflows work will help you understand when to use them and how you might nudge Claude via prompts.
+
+There are a few common patterns that Claude might use and compose together when building workflows:
+
+![](https://cdn.prod.website-files.com/68a44d4040f98a4adf2207b6/6a1f16d86247e586b929a407_image10.png)
+
+### Classify-and-act
+
+Use a classifier agent to decide on the type of task, and then route to different agents or behavior based on the task. Or, use a classifier at the end to determine output.
+
+### Fan-out-and-synthesize
+
+Split up a task into many smaller steps, run an agent on each step and then synthesize those results. This is particularly useful for when there are a large number of smaller steps, or when each step benefits from its own clean context window so they don't interfere or cross-contaminate. The synthesize step is a barrier—it waits for all the fan-out agents, then merges their structured outputs into one result.
+
+### Adversarial verification
+
+For each spawned agent, run a separate spawned agent to adversarially verify its output against a rubric or criteria. 
+
+### Generate-and-filter
+
+Generate a number of ideas on a topic and then filter them by a rubric or by verification, dedupe duplicates and return only the highest quality, tested ideas.
+
+### Tournament
+
+Instead of dividing the work, have agents compete on it. Spawn N agents that each attempt the same task using different approaches. Prompts or models then judge the results in a pairwise fashion using a judging agent until you have a winner.
+
+### Loop until done
+
+For tasks with an unknown amount of work, loop spawning agents until a stop condition is met (no new findings, or no more errors in the logs) instead of a fixed number of passes.
+
+## Use cases
+
+Think creatively of when and how to ask Claude Code to make dynamic workflows. I’ve found that workflows are sometimes even more useful for non-technical work.
+
+### Migrations and refactors 
+
+[Bun](https://bun.com/) was rewritten from Zig to Rust using workflows. You can read more about how that was done in [Jarred’s X thread](https://x.com/jarredsumner/status/2060050578026189172). 
+
+The key is to break down the task into a series of steps that need to be operated on for example callsites, failing tests, modules, etc. Spin off a subagent for every fix in a worktree to make the fix, then have another agent adversarially review, and merge them. Consider telling the agent not to use resource intensive commands so that you can maximally parallelize without running out of resources on your machine.
+
+### Deep research
+
+We published a deep research skill (`/deep-research`) inside Claude Code that uses dynamic workflows. Specifically, it fans-out web searches, fetches sources, adversarially verifies their claims, and synthesizes a cited report.
+
+But you may do this sort of research for more than just web searches. For example, asking Claude to compile a status report from context in Slack or to research how a feature works by exploring a codebase in-depth.
+
+### Deep verification
+
+![](https://cdn.prod.website-files.com/68a44d4040f98a4adf2207b6/6a1f1721824a27cf13da87f4_image2.png)
+
+On the other hand, if you have a report where you want to check and source every factual claim that it references you may want to generate a workflow which has one agent identify all of the factual claims and then spin off a subagent to check each one in-detail. You could also have a verification agent check the source subagent to make sure its source is high quality. 
+
+### Sorting
+
+![](https://cdn.prod.website-files.com/68a44d4040f98a4adf2207b6/6a1f173ce727a972001584cc_image3.png)
+
+You may have a list of items that you want to sort by some qualitative measurement that you believe that Claude Code is good at evaluating, for example: support tickets sorted by severity of the bug. But if you try to sort 1000+ rows in one prompt, quality degrades and it won't fit in context. Instead run a tournament, a pipeline of pairwise-comparison agents (comparative judgment is more reliable than absolute scoring), or bucket-rank in parallel then merge. Each comparison is its own agent, so the deterministic loop holds the bracket and only the running order stays in context.
+
+### Memory and rule adherence
+
+![](https://cdn.prod.website-files.com/68a44d4040f98a4adf2207b6/6a1f17517076bb59050d90bb_image8.png)
+
+If you have a particular set of rules that you find Claude misses or struggles with, even when put into the `CLAUDE.mds`, create a workflow with a list of rules that must be checked by verifier agents—one verifier per rule. Creating a skeptic persona subagent to review the rules to make sure they are in line will help avoid too many false positives.
+
+The reverse direction works too: mine your recent sessions and code review comments for corrections you keep making, cluster them with parallel agents, adversarially verify each candidate (would this rule have prevented a real mistake?), and then distill the survivors back into a `CLAUDE.md`.
+
+### Root-cause investigation 
+
+Debugging works best when you come up with several independent hypotheses and test them, but if you’re only using one context window, Claude can run into self-preferential bias
+
+A workflow can structurally prevent this by spinning up agents to generate hypotheses from disjoint evidence. For example, separate agents for logs, files, and data. Each hypothesis can then face a panel of verifiers and refuters.
+
+This isn't just for code. Workflows can be used for sales (why did sales drop in March?), data engineering (why did this pipeline fail?), or any post-mortem exercise.
+
+### Triaging at scale
+
+![](https://cdn.prod.website-files.com/68a44d4040f98a4adf2207b6/6a1f1778dc00d34cca70819d_image6.png)
+
+Every team has a support queue, bug reports, or some other backlog that cannot be fully processed by humans. 
+
+A triage workflow classifies each item, dedupes against what's already tracked, and takes action. This could mean attempting the fix or escalating to a human user.
+
+A useful pattern for triage workflows is quarantine. This involves barring the agents that read untrusted public content from taking high-privilege actions, which are instead done by the agents in charge of acting on the information.
+
+Pair triage workflows with /loop to have Claude do this continuously.
+
+### Exploration and taste
+
+Workflows can be useful when exploring different approaches to a solution, especially when it is taste based, like design or naming, and would benefit from a rubric.
+
+Try asking Claude to explore a bunch of solutions, and give a review agent  a rubric for what a good solution looks like. The task is complete when the review agent feels like it has met the criteria. Solutions can also be ordered or selected via a tournament based on the rubric.
+
+### Evals
+
+You can run lightweight evals for particular tasks by spinning off separate agents in a worktree and then spinning off comparison agents to compare and grade the specific outputs against a rubric. For example, evaluating and then refining a skill you’ve created against a particular criteria.
+
+### Model and intelligence routing
+
+Create a classifier agent tuned to your tasks that decides which model to use. This can be helpful when your task will involve many tool calls and conducting research prior to execution can identify the best model for the job. 
+
+For example, the best model for the task “explain how the auth module works” depends on how many files in the auth module there are and the shape of the codebase. A classifier agent can do this research and then route to Sonnet or Opus based on the expected complexity of the task.
+
+## When not to use dynamic workflows
+
+Workflows are new. While there are many use cases where it will create outsized results, they are not needed for every task and may end up using significantly more tokens.
+
+It’s best to use workflows creatively to push Claude Code in ways that you haven’t previously. For regular coding tasks, try and ask yourself: does it really need more compute? For example, most traditional coding tasks do not need a panel of 5 reviewers.
+
+## Tips for building dynamic workflows
+
+### Prompting
+
+Detailed prompting, using the specific techniques we described above, for dynamic workflows creates the best results.
+
+Workflows are not just for large tasks. You can prompt the model to use a “quick workflow.” For example, you can create a quick adversarial review of an assumption.
+
+### Combine with `/goal` and `/loop`
+
+When using workflows that can be repeated, for example triage, research, or verification, pair them with `/loop` to be run at regular intervals, and /goal to set a hard completion requirement.
+
+### Token usage budgets
+
+You can set explicit token usage budgets for dynamic workflows to limit how many tokens a task uses. You can prompt it with a budget like: “use 10k tokens,” which will set the cap.
+
+### Saving and sharing dynamic workflows
+
+You can save workflows by pressing “s” in the workflow menu. You can check these into `~/.claude/workflows` or distribute them via a skill. 
+
+![](https://cdn.prod.website-files.com/68a44d4040f98a4adf2207b6/6a1f17b1ca20533e666c867c_image4.png)
+
+To share them via a skill, put your JavaScript workflow files in the skill and folder and reference them in the [SKILL.MD](http://skill.md). To allow for more flexibility, you may want to prompt Claude to think of the workflows in the skill as a template instead of a script that needs to be run verbatim.
+
+![](https://cdn.prod.website-files.com/68a44d4040f98a4adf2207b6/6a1f17cb835cf4f9fd5da921_image7.png)
+
+## A new starting point for discovery 
+
+Workflows are a helpful new way to extend Claude Code. I encourage you to think of them as a starting point to explore new ways to use Claude to help accomplish your tasks. There is still much to discover in how to use them best. Let me know what you find. 
+
+‍
+
+*This article was written by Thariq Shihipar and Sid Bidasaria, members of technical staff at Anthropic working on Claude Code.*
+

package/hooks/build/build-gate-check.sh

@@ -18,7 +18,9 @@ if not s: sys.exit(0)
 g=s.get("gates",{})
 abiertos=[k for k,v in g.items() if v is False]
 if abiertos:
-    print(f"build-gate-check: slice {s.get('hu')} en fase '{s.get('phase')}' con gates abiertos: {', '.join(abiertos)}.", file=sys.stderr)
+    epica=s.get('epica') or '?'
+    hus=', '.join(s.get('hus') or []) or '—'
+    print(f"build-gate-check: slice {epica} [{hus}] en fase '{s.get('phase')}' con gates abiertos: {', '.join(abiertos)}.", file=sys.stderr)
     print("   No archives ni abras PR hasta cerrarlos (ver building-a-slice / dod.md).", file=sys.stderr)
 PY
 exit 0

package/hooks/build/load-build-state.sh

@@ -12,15 +12,37 @@ BRANCH="$(git -C "$ROOT" rev-parse --abbrev-ref HEAD 2>/dev/null || echo 'descon
 if [ -f "$ROOT/package.json" ]; then PHASE="active"; else PHASE="authoring"; fi
 
 # Sincroniza harness_phase en el estado (si python3 disponible y el archivo existe).
+# Escritura ATÓMICA + validada: este hook corre en CADA SessionStart (alta frecuencia,
+# headless incluido); una escritura no atómica que se interrumpa truncaría la ÚNICA
+# fuente de verdad. Solo escribe si harness_phase cambia; si algo falla, deja el original
+# intacto (fail-open) y nunca rompe el SessionStart.
 if [ -f "$STATE" ] && command -v python3 >/dev/null 2>&1; then
   python3 - "$STATE" "$PHASE" <<'PY' 2>/dev/null || true
-import json,sys
+import json,sys,os,tempfile
 path,phase=sys.argv[1],sys.argv[2]
 try:
-    d=json.load(open(path))
-    if d.get("harness_phase")!=phase:
-        d["harness_phase"]=phase
-        json.dump(d,open(path,"w"),indent=2,ensure_ascii=False)
+    with open(path) as fh:
+        d=json.load(fh)
+    # No escribir si no hay cambio.
+    if d.get("harness_phase")==phase:
+        sys.exit(0)
+    # Validación mínima de forma antes de tocar disco (no relajamos el schema completo,
+    # solo evitamos persistir algo que claramente no es un build-state).
+    if not isinstance(d,dict) or not all(k in d for k in ("version","harness_phase","active_slice","history","releases")):
+        sys.exit(0)
+    d["harness_phase"]=phase
+    dirn=os.path.dirname(path) or "."
+    fd,tmp=tempfile.mkstemp(dir=dirn,prefix=".build-state.",suffix=".tmp")
+    try:
+        with os.fdopen(fd,"w") as out:
+            json.dump(d,out,indent=2,ensure_ascii=False)
+            out.flush()
+            os.fsync(out.fileno())
+        os.replace(tmp,path)  # sustitución atómica
+    except Exception:
+        try: os.unlink(tmp)
+        except OSError: pass
+        raise
 except Exception:
     pass
 PY

package/hooks/build/release-gate-nudge.sh

@@ -0,0 +1,40 @@
+#!/usr/bin/env bash
+# release-gate-nudge.sh — Stop
+# Sugiere correr el Release Gate (releasing-a-version) cuando hay ≥2 épicas archivadas sin
+# auditar desde el último release. NUNCA bloquea el cierre, NUNCA ejecuta trabajo pesado,
+# NUNCA llama al modelo ni escribe estado. Determinista y barato: aritmética de conjuntos
+# sobre epicas[] (archivadas − cubiertas), independiente de timestamps.
+# El criterio "cierra una línea de release" vive en docs/02-user-story-map/ y NO se intenta aquí
+# (lo computa la skill building-a-slice en la fase 8).
+set -uo pipefail
+
+ROOT="$(git rev-parse --show-toplevel 2>/dev/null || echo "${CLAUDE_PROJECT_DIR:-$(pwd)}")"
+STATE="$ROOT/.claude/state/build-state.json"
+[ -f "$STATE" ] || exit 0
+command -v python3 >/dev/null 2>&1 || exit 0   # fail-open: jamás impide cerrar sesión
+
+# Mensaje a STDOUT (no stderr): un Stop hook con exit 0 no bloquea el cierre; el 2>/dev/null
+# suprime SOLO trazas de python, nunca el nudge.
+python3 - "$STATE" <<'PY' 2>/dev/null || true
+import json, sys
+try:
+    d = json.load(open(sys.argv[1]))
+except Exception:
+    sys.exit(0)
+hist = d.get("history") or []
+rels = d.get("releases") or []
+# Épicas ya archivadas (slices cerrados).
+archived = {h.get("epica") for h in hist if isinstance(h, dict) and isinstance(h.get("epica"), str)}
+# Épicas ya cubiertas por ALGÚN release (pending/passed/failed por igual).
+covered = set()
+for r in rels:
+    if isinstance(r, dict):
+        for e in (r.get("epicas") or []):
+            if isinstance(e, str):
+                covered.add(e)
+pend = sorted(archived - covered)
+if len(pend) >= 2:
+    print(f"💡 Release Gate sugerido: {len(pend)} épicas archivadas sin auditar desde el último release ({', '.join(pend)}).")
+    print("   Ejecuta /build:release (o la skill releasing-a-version): corre los gates pesados UNA vez sobre el diff acumulado.")
+PY
+exit 0

package/hooks/build/stack-guard.sh

@@ -33,20 +33,42 @@ ti=data.get("tool_input",{})
 fp=ti.get("file_path") or ti.get("path") or ""
 if not fp.endswith("package.json"):
     sys.exit(0)
-content=ti.get("content") or ti.get("new_string") or ""
-if not content.strip():
+content=ti.get("content")
+new=ti.get("new_string")
+old=ti.get("old_string")
+# Nada que verificar si la edición no aporta texto.
+if not (content and content.strip()) and not (new and new.strip()):
     sys.exit(0)
 allow=json.load(open(os.environ["ALLOW"])).get("allow",[])
 def ok(name):
     return any(fnmatch.fnmatch(name, pat) for pat in allow)
-# Extrae nombres de deps tanto de JSON completo como de fragmentos de edición.
-deps=set()
-try:
-    pkg=json.loads(content)
+def extract(pkg):
+    deps=set()
     for sec in ("dependencies","devDependencies","peerDependencies","optionalDependencies"):
         deps.update((pkg.get(sec) or {}).keys())
-except Exception:
-    for m in re.finditer(r'"((?:@[\w.-]+/)?[\w.-]+)"\s*:\s*"[\^~>=<*\d][^"]*"', content):
+    return deps
+# Extracción por clave (version-agnóstica) en tres ramas de prioridad decreciente.
+# Las ramas 1 y 2 parsean el documento COMPLETO, así que capturan specs no-semver
+# (github:, file:, git+https:, npm:alias) que la regex de la rama 3 dejaba pasar.
+deps=set(); extracted=False
+# (1) Write con package.json completo en `content`.
+if content and content.strip():
+    try:
+        deps=extract(json.loads(content)); extracted=True
+    except Exception:
+        pass
+# (2) Edit: reconstruir el documento POST-edición leyendo el package.json de disco.
+if not extracted and new is not None:
+    try:
+        with open(fp) as fh: disk=fh.read()
+        post = disk.replace(old, new) if old else (new + disk)
+        deps=extract(json.loads(post)); extracted=True
+    except Exception:
+        pass
+# (3) Fallback (solo si 1 y 2 fallan): regex semver ACTUAL, sin ampliar.
+if not extracted:
+    frag = content or new or ""
+    for m in re.finditer(r'"((?:@[\w.-]+/)?[\w.-]+)"\s*:\s*"[\^~>=<*\d][^"]*"', frag):
         deps.add(m.group(1))
 bad=sorted(d for d in deps if d and not ok(d))
 if bad:

package/hooks/build-harness.json

@@ -65,6 +65,10 @@
           {
             "type": "command",
             "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/reflect-nudge.sh\""
+          },
+          {
+            "type": "command",
+            "command": "\"${CLAUDE_PLUGIN_ROOT:-$CLAUDE_PROJECT_DIR/.claude}/hooks/build/release-gate-nudge.sh\""
           }
         ]
       }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@trycore/spec-build-harness",
-  "version": "0.6.0",
+  "version": "0.7.0",
   "description": "Arnés agéntico de construcción de Trycore para Claude Code: pipeline de dos loops (slice por épica + release gate) con gates de calidad, estado compartido y OpenSpec. Compañero de @trycore/spec-product-flow. Agnóstico al proyecto.",
   "type": "module",
   "bin": {

package/scripts/check-agnostic.sh

@@ -59,7 +59,7 @@ TARGETS=(
 for target in "${TARGETS[@]}"; do
   [[ -e "$target" ]] || continue
   hits=$(grep -riEn -- "$PATTERN" "$target" 2>/dev/null \
-    --include='*.md' --include='*.json' --include='*.sh' \
+    --include='*.md' --include='*.json' --include='*.sh' --include='*.js' --include='*.mjs' \
     --exclude-dir='node_modules' || true)
   if [[ -n "$hits" ]]; then
     VIOLATIONS+=("$hits")

package/skills/building-a-slice/SKILL.md

@@ -60,6 +60,24 @@ inner loop: **≤ ~20 min por épica** y producto que **camina end-to-end en tod
 > fix-loop → optimizar) y reparte la exploración **"ancho antes que profundo"** con subagentes
 > **solo-lectura por área** (frontend/backend/datos); el **cableado** lo hace la sesión, no
 > subagentes que escriben en paralelo. Trocear acota además el tamaño del `wiring_checklist[]`.
+> Para épicas troceadas, esa exploración solo-lectura **puede** conducirse con la plantilla (opcional)
+> `workflows/explore-fanout.workflow.js` — contrato en `references/exploration-fanout.md`. **No** se usa en
+> épicas atómicas (inflaría el inner loop barato); es read-only (no escribe estado) y el cableado sigue
+> siendo de la sesión.
+
+## Workflows (plantillas, no scripts)
+
+Los archivos `*.workflow.js` bajo `workflows/` son **plantillas de referencia** que esta skill **conduce**,
+no scripts a correr verbatim (si contradicen `METODOLOGIA.md`, gana la metodología). Reglas duras:
+- **Opt-in y solo para épicas grandes.** Los workflows del inner loop solo aplican a épicas troceadas por el
+  gate de tamaño (`sub_slices[]` no vacío); **nunca** en el camino caliente ≤ ~20 min de una épica atómica.
+- **Read-only sobre el estado.** Ningún workflow escribe `build-state.json`: devuelven un diagnóstico y
+  `build-orchestrator` (o el agente dueño del gate) aplica el mapeo respetando el protocolo (una transición =
+  una escritura; gates monótonos; **validar contra el schema tras escribir**).
+- **Subagentes de exploración = solo-lectura** (Read/Grep/Glob); el cableado lo hace la sesión.
+
+Ver `workflows/README.md`. Hoy: `workflows/explore-fanout.workflow.js` (exploración fan-out) y
+`workflows/wiring-verify.workflow.js` (conducción del verificador adversarial del gate `wiring_verified`).
 
 ## Fase 0 · Scaffold (Paso 1 fundamental — precondición restrictiva)
 
@@ -157,6 +175,9 @@ El usuario siempre puede sobreescribir el default. Si acepta, invoca la skill
 - **`dod` exige `wiring_verified: true`** (verificación adversarial independiente, contexto virgen).
   El DoD declarativo del gatekeeper es un **piso, no el arreglo**: reusar el mismo agente como
   generador y verificador produce auto-confirmación. La generación y la verificación van separadas.
+  Opcionalmente, esa verificación se **conduce** con la plantilla read-only
+  `workflows/wiring-verify.workflow.js` (envuelve al `wiring-adversarial-verifier`); `build-orchestrator`
+  sigue siendo quien **escribe** `gates.wiring_verified` a partir del veredicto que la plantilla devuelve.
 - **Producto completo, no MVP.** El alcance acordado se construye entero. **Recortar o diferir es
   bloqueante explícito** que requiere acuerdo del equipo — nunca una decisión del modelo. No derives
   en lo complejo. La verificación es **ejecutada, no por inspección** (ver `METODOLOGIA.md` y el