@trycore/spec-build-harness 0.5.0 → 0.7.0

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
@@ -39,8 +61,24 @@ if not s:
 else:
     g=s.get("gates",{})
     abiertos=[k for k,v in g.items() if v is False]
-    print(f"   Slice activo: {s.get('hu')} ({s.get('epica')}) · change={s.get('openspec_change')} · fase={s.get('phase')}")
+    hus=", ".join(s.get("hus") or []) or "—"
+    print(f"   Slice activo: {s.get('epica')} [{hus}] · change={s.get('openspec_change')} · fase={s.get('phase')}")
     print(f"   Gates pendientes: {', '.join(abiertos) if abiertos else 'ninguno ✅'}")
+    # Handoff fino en disco (A1): items de cableado aún FAILING + última bitácora.
+    # Una sesión fresca arranca de aquí; mientras queden failing, el cableado NO está hecho.
+    failing=[w for w in (s.get("wiring_checklist") or []) if w.get("status")=="failing"]
+    if failing:
+        muestra="; ".join(f"{w.get('id')}({w.get('kind')})" for w in failing[:8])
+        extra=f" (+{len(failing)-8} más)" if len(failing)>8 else ""
+        print(f"   ⚠️  Cableado pendiente ({len(failing)} item/s failing): {muestra}{extra}")
+        print("       NO declares el slice terminado mientras queden items failing (verifica con prueba real).")
+    pend=[ss for ss in (s.get("sub_slices") or []) if ss.get("status")!="done"]
+    if pend:
+        print(f"   ⚠️  Sub-slices pendientes: {', '.join(ss.get('id') for ss in pend)}")
+    log=s.get("progress_log") or []
+    if log:
+        last=log[-1]
+        print(f"   Última bitácora: [{last.get('by')}] {last.get('note')}")
 PY
 fi
 exit 0

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

@@ -25,7 +25,14 @@ el avance en el estado.
   `.claude/state/README.md`). Lee antes de actuar; escribe una vez por transición.
 - **Secuencial**: un slice activo a la vez. Un gate no se salta.
 - **Divulgación progresiva**: carga el `references/<tema>.md` solo cuando la fase lo necesita.
-- **Delega en subagentes** para revisión pesada (devuelven síntesis, protegen el contexto).
+- **Delega en subagentes** para revisión pesada y para **explorar** (devuelven síntesis condensada,
+  protegen el presupuesto de atención de la sesión principal para **cablear**, no para descubrir).
+- **Refresh de contexto = estado por defecto**: cada iteración nace **headless / contexto virgen** y
+  reconstruye el estado **desde disco** (git + `build-state.json` + logs), no desde la conversación
+  viva. Mantén el **`wiring_checklist[]`** (un item por escenario AC y por punto de integración entre
+  capas): nace `failing`, pasa a `passing` **solo tras prueba real ejecutada**. Deja una nota en
+  `progress_log[]` por hito. **Mientras quede un item `failing`, el slice NO está terminado.** Ver
+  `references/state-protocol.md`.
 
 ## Dos loops
 
@@ -39,6 +46,39 @@ inner loop: **≤ ~20 min por épica** y producto que **camina end-to-end en tod
 > cada paso sea un stub. Cada épica posterior **engorda** un paso de ese esqueleto y mantiene el
 > `journey_smoke` verde. Nunca se construyen capas horizontales aisladas que "se juntan al final".
 
+> **Cimiento antes que negocio (épicas fundacionales).** Las épicas marcadas `layer: foundational`
+> (autenticación, acceso a datos, arquitectura base, design-system/componentes base) se construyen
+> **antes** que las `layer: business`. El DoR **rechaza** abrir una épica de negocio que arrastra
+> cimiento no construido y lo extrae a una épica fundacional previa (ver `dor.md`). Así cada slice de
+> negocio **solo toca lógica aplicable** y no quema contexto creando infra.
+
+> **Descomposición por tamaño (no one-shot).** Una épica que supera el **gate de tamaño**
+> (heurística por defecto: **> 3 HU** ó **≥ 3 capas tocadas**; configurable por proyecto) es
+> demasiado grande para una pasada: el DoR obliga a trocearla en **sub-slices verificables**
+> (`sub_slices[]`) construidos **de a uno**, con `journey_smoke` verde entre cada uno antes de pasar
+> al siguiente. El orquestador trabaja por **fases encadenadas** (mapear → generar → revisar →
+> 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)
 
 Antes de abrir **cualquier** slice, el scaffold runnable del proyecto debe **existir y estar
@@ -78,9 +118,9 @@ Espejo de la Fase 0, para proyectos **con UI**. Antes de abrir el primer slice c
 | 1 · dor | Validar Definition of Ready | `dor-dod-gatekeeper` | `dor` | `dor.md` |
 | 2 · change | `opsx:new` + bloque `## Trazabilidad`; validar enlace (barato) | `opsx:new`, `change-epic-coherence` | `coherence_link` | `link-change-epic.md` |
 | 3 · tdd | red → green → refactor | `superpowers:test-driven-development` | `tdd` | — |
-| 4 · smoke | Recorrer el journey-hasta-aquí end-to-end; **slices con UI:** verificar fidelidad a la fuente de diseño | skill `verify` / `run` (+ MCP chrome-devtools), `ux-fidelity-reviewer` | `journey_smoke`,`fidelity` | `mcp-map.md` |
+| 4 · smoke | Recorrer el journey-hasta-aquí end-to-end con el **runner determinista fuera-de-chat** (`integration-check`: suite+build+reporte) en **sesión/contexto virgen**; **slices con UI:** fidelidad por **verificación visual REAL** (MCP chrome-devtools, screenshot app vs prototipo) | runner `integration-check`, skill `verify`/`run` + MCP chrome-devtools, `ux-fidelity-reviewer` | `journey_smoke`,`fidelity` | `integration-check.md`, `mcp-map.md` |
 | 5 · api/data | contratos + consistencia (si aplican al slice) | `api-contract-tester`, `data-consistency-checker` | `api`,`data` | `newman-tests.md`, `data-consistency.md` |
-| 6 · dod | Definition of Done (por slice, reducido) | `dor-dod-gatekeeper` | `dod` | `dod.md` |
+| 6 · dod | **Primero** verificación adversarial INDEPENDIENTE del cableado (contexto virgen: refuta stubs/rutas sin cablear/AC sin test/items `failing`) → `wiring_verified`; **solo entonces** Definition of Done | `wiring-adversarial-verifier`, `dor-dod-gatekeeper` | `wiring_verified`,`dod` | `dod.md`, `integration-check.md` |
 | 7 · pr | Abrir PR + archivar change en el mismo PR | `opsx:archive`, `opsx:sync` | — | `gitflow.md` |
 | 8 · release? | Preguntar si correr el Release Gate ahora | usuario (default computado) | — | abajo |
 
@@ -88,9 +128,15 @@ Los gates `stack`, `security`, `smell`, `ux` y la coherencia triple completa **y
 aquí**: pertenecen al Release Gate. Las **deps** siguen vigiladas en tiempo real por el hook
 `stack-guard.sh`; lint/tsc/gitflow por sus hooks.
 
-El gate `fidelity` (fidelidad a la fuente de diseño) **sí** es de inner loop: es barato (se computa
-en `smoke`, con la app ya levantada) y vivo por-slice; complementa al `ux-krug-reviewer` (usabilidad),
-que sigue en el Release Gate.
+El gate `fidelity` (fidelidad a la fuente de diseño) **sí** es de inner loop: se computa en `smoke`,
+con la app ya levantada, y es vivo por-slice; complementa al `ux-krug-reviewer` (usabilidad), que
+sigue en el Release Gate. **Estricto para UI:** una UI no mejora su fidelidad por el prompt sino
+porque el agente **carga la página, observa la salida real y lee la consola**. Para slices con UI
+(`design_source.applies===true`), `fidelity` **solo cierra con verificación visual real vía MCP
+chrome-devtools** (screenshot app vs prototipo). Sin MCP, `fidelity` queda `false` (INCONCLUSO ya
+**no** pasa) → el `dod` no cierra: corre el slice donde haya MCP. Mantén **cobertura** (ninguna
+pantalla del prototipo en alcance sin construir; ninguna pantalla de la app sin HU/EP) y el
+**journey-smoke de clic real como tenant no-admin**.
 
 MCP/LSP por gate: ver `references/mcp-map.md`. Protocolo de estado: `references/state-protocol.md`.
 
@@ -126,4 +172,14 @@ El usuario siempre puede sobreescribir el default. Si acepta, invoca la skill
 - El enlace change↔épica va en `## Trazabilidad` del `proposal.md`, **nunca** en frontmatter YAML
   (rompe `openspec validate`). Ver `link-change-epic.md`.
 - Integración solo por **PR** a `main` (el hook `gitflow-guard.sh` bloquea commits/push directos).
+- **`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
+  bloque del arnés en `CLAUDE.md`).
 - Si una regla aquí contradice la metodología Trycore (`METODOLOGIA.md`), **gana la metodología**.

package/skills/building-a-slice/references/dod.md

@@ -12,9 +12,21 @@ pesadas (seguridad, diseño, UX, coherencia triple, arquitectura, integración)
 - [ ] **`data`** — `data-consistency-checker` valida invariantes de datos (salida de servicios externos validada contra esquema antes de alimentar la capa de decisión determinista del dominio) (si el slice toca datos).
 - [ ] **`api`** — `api-contract-tester` (Newman) 100% verde (o `null` si el slice no tiene endpoints).
 - [ ] **`fidelity` (slices con UI)** — `ux-fidelity-reviewer` devuelve **FIEL** (o DESVIACIONES todas
-  justificadas/documentadas) → `gates.fidelity: true`; `null` si el slice no tiene UI. INCONCLUSO
-  (MCP no disponible) se registra, **no bloquea**. Es gate **vivo** de inner loop (no la revisión Krug,
-  que sigue en el Release Gate).
+  justificadas/documentadas) → `gates.fidelity: true`; `null` si el slice no tiene UI. **ESTRICTO para
+  UI** (`design_source.applies===true`): solo `true` con **verificación visual real** vía MCP
+  chrome-devtools (screenshot app vs prototipo). **INCONCLUSO ya NO pasa**: sin MCP queda `false` y el
+  `dod` no cierra (corre el slice donde haya MCP). Mantén **cobertura** (ninguna pantalla del prototipo
+  en alcance sin construir; ninguna pantalla de la app sin HU/EP). Es gate **vivo** de inner loop (no la
+  revisión Krug, que sigue en el Release Gate).
+- [ ] **Sub-slices completos** — si la épica se descompuso (`sub_slices[]` no vacío), **todos** en
+  `status: done` con su `journey_smoke` verde. No se cierra `dod` con sub-slices pendientes.
+- [ ] **`wiring_verified`** — el `wiring-adversarial-verifier` (subagente **independiente**, contexto
+  virgen) intentó **refutar** el slice (stubs, rutas sin cablear, AC sin test, items de
+  `wiring_checklist[]` aún `failing`) y no halló huecos → `gates.wiring_verified: true`. **Prerequisito
+  duro de `dod`**: el DoD declarativo de este checklist es un **piso, no el arreglo** (la auto-confirmación
+  surge de reusar el mismo agente como generador y verificador). Esa verificación puede conducirse,
+  opcionalmente, con la plantilla read-only `../workflows/wiring-verify.workflow.js` (envuelve al verificador;
+  `build-orchestrator` es quien escribe el gate a partir de su veredicto).
 - [ ] **OpenSpec**: todas las tasks `[x]`; el archive del change va **en el mismo PR** (no PR aparte).
 - [ ] **Docs/trazabilidad**: back-ref del change añadida en la épica y en cada HU de `hus[]`.
 - [ ] **Hooks verdes (automáticos, no son gates de agente)**: `lint-typecheck.sh` (lint + chequeo de tipos del stack declarado), `stack-guard.sh` (deps en allowlist según la sección de requisitos técnicos del PRD del consumidor, ruta declarada en `stack-allowlist.json#source`), `gitflow-guard.sh` (rama `feature/*`, sin commits directos a `main`).