@gonrocca/zero-pi 0.1.51 → 0.1.53

package/README.md

@@ -56,6 +56,14 @@ The verdict is `pasa` (done), `corregir` (re-run build), or `replantear`
 without a `pasa`, the run stops and is reported as **not verified**.
 `/forge --continue [slug]` resumes an interrupted run.
 
+**Build runs test-first.** By default the build phase follows a strict TDD
+cycle — RED → GREEN → TRIANGULATE → REFACTOR — and records a **TDD Cycle
+Evidence** table; veredicto audits that evidence (tests exist, are really green,
+assertions verify real behavior) and returns `corregir` if the discipline
+slipped. It engages only when a test runner exists and the change touches code,
+so docs/config-only work degrades gracefully. Opt a project out with
+`tdd.mode: "off"` in `.sdd/config.json` (see *Configuration*).
+
 The run speaks **Spanish**, in a bounded, low-noise format — one short summary
 per phase, naming the model that phase runs on, no raw tool output. Or just
 describe the work and say "hacelo con sdd": the `sdd-routing` skill routes it
@@ -65,6 +73,7 @@ into `/forge` for you.
 
 | Feature | What it does |
 | ------- | ------------ |
+| **Strict TDD** | The build phase drives RED → GREEN → TRIANGULATE → REFACTOR with a TDD Cycle Evidence table; veredicto audits it. On by default, runtime-gated on a test runner; `tdd.mode: "off"` disables it. |
 | **`/zero-models`** | Pick the model + provider for each SDD phase — a boxed-window picker, or set one directly. |
 | **Autotune** | Learns which model fits each phase from your run history and re-tunes itself. |
 | **`/zero-sync` / `/zero-archive`** | Folds each run's spec delta into a canonical, project-wide spec store and archives approved runs. |
@@ -160,6 +169,20 @@ zero-pi keeps its state in `~/.pi/zero.json` (per-phase models + autotune mode)
 and `~/.pi/zero-runs.jsonl` (the run-metrics log); per-project artifacts live
 under `.sdd/`. Set `ZERO_RESUME=off` to disable the conversation-resume note.
 
+`.sdd/config.json` carries the per-project git and TDD settings:
+
+```json
+{
+  "git": { "branchPrefix": "sdd/", "numbering": false, "autoCommit": false, "commitStyle": "conventional", "baseBranch": "main" },
+  "tdd": { "mode": "strict", "testCommand": "" }
+}
+```
+
+`tdd.mode` defaults to `"strict"` (the build phase runs test-first; veredicto
+audits the TDD evidence) and accepts `"off"` to disable the discipline.
+`tdd.testCommand` overrides the auto-detected test runner the TDD cycle invokes;
+leave it empty to let the build/veredicto phases detect it from the project.
+
 ## Continuous integration
 
 The `.github/workflows/zero-pi-ci.yml` workflow runs on every push to `main` and

package/extensions/sdd-agents.ts

@@ -11,7 +11,7 @@
 // the per-phase models in `~/.pi/zero.json`. The files are regenerated every
 // load, so they stay in sync with the prompts and with `/zero-models`.
 
-import { mkdirSync, readFileSync, writeFileSync } from "node:fs";
+import { copyFileSync, mkdirSync, readFileSync, writeFileSync } from "node:fs";
 import { homedir } from "node:os";
 import { dirname, join } from "node:path";
 import { fileURLToPath } from "node:url";
@@ -20,6 +20,20 @@ import { fileURLToPath } from "node:url";
 export const PHASES = ["explore", "plan", "build", "veredicto"] as const;
 export type Phase = (typeof PHASES)[number];
 
+/**
+ * The Strict TDD support modules, copied verbatim from `prompts/support/` to a
+ * stable directory beside the generated agents so the `zero-build` /
+ * `zero-veredicto` sub-agents can `read` them at runtime. The sub-agents are
+ * generated with `inheritSkills: false`, so the phase prompt body is the only
+ * channel that can point them at these files — see `supportModulesDir()`.
+ */
+export const SUPPORT_MODULES = ["strict-tdd.md", "strict-tdd-verify.md"] as const;
+
+/** Absolute path of the runtime support dir the phase prompts reference. */
+export function supportModulesDir(): string {
+  return join(homedir(), ".pi", "agent", "agents", "zero", "support");
+}
+
 /**
  * Split a phase prompt into its `description` (from `---` frontmatter) and its
  * body. A prompt with no frontmatter yields an empty description and the whole
@@ -109,6 +123,7 @@ export default function register(_pi?: unknown): void {
   try {
     const here = dirname(fileURLToPath(import.meta.url)); // <pkg>/extensions
     const phasesDir = join(here, "..", "prompts", "phases");
+    const supportSrcDir = join(here, "..", "prompts", "support");
     const agentsDir = join(homedir(), ".pi", "agent", "agents", "zero");
     mkdirSync(agentsDir, { recursive: true });
 
@@ -122,6 +137,23 @@ export default function register(_pi?: unknown): void {
         // A single phase failing must not block the other three.
       }
     }
+
+    // Stage the Strict TDD support modules next to the agents so `zero-build`
+    // and `zero-veredicto` can read them at runtime. A copy failure is
+    // non-fatal: the build/veredicto prompts carry an inline fallback contract.
+    try {
+      const supportDir = supportModulesDir();
+      mkdirSync(supportDir, { recursive: true });
+      for (const mod of SUPPORT_MODULES) {
+        try {
+          copyFileSync(join(supportSrcDir, mod), join(supportDir, mod));
+        } catch {
+          // One module failing must not block the other.
+        }
+      }
+    } catch {
+      // Support staging is best-effort; the inline fallback covers absence.
+    }
   } catch {
     // Sub-agent provisioning must never break a pi session.
   }

package/extensions/sdd-config.ts

@@ -9,10 +9,30 @@ export interface SddConfig {
     commitStyle: "conventional" | "plain";
     baseBranch: string;
   };
+  /**
+   * Strict TDD discipline for the build/veredicto phases.
+   *
+   * `mode`:
+   * - `"strict"` (default) — the build phase follows RED → GREEN →
+   *   TRIANGULATE → REFACTOR and emits a TDD Cycle Evidence table; veredicto
+   *   audits it. The discipline is **runtime-gated**: the phase prompts only
+   *   engage it when a test runner is actually available and the change touches
+   *   code — a docs/config-only change or a project with no test runner
+   *   degrades gracefully instead of failing.
+   * - `"off"` — no TDD ceremony; the build phase tests where practical only.
+   *
+   * `testCommand` is an optional explicit override of the test runner the TDD
+   * cycle invokes; empty means the phase auto-detects it from the project.
+   */
+  tdd: {
+    mode: "strict" | "off";
+    testCommand: string;
+  };
 }
 
 export const DEFAULT_SDD_CONFIG: SddConfig = {
   git: { branchPrefix: "sdd/", numbering: false, autoCommit: false, commitStyle: "conventional", baseBranch: "main" },
+  tdd: { mode: "strict", testCommand: "" },
 };
 
 function asObject(value: unknown): Record<string, unknown> {
@@ -26,6 +46,7 @@ export function loadSddConfig(root = process.cwd()): SddConfig {
   try { parsed = asObject(JSON.parse(readFileSync(path, "utf8"))); }
   catch (err) { throw new Error(`invalid .sdd/config.json: ${err instanceof Error ? err.message : String(err)}`); }
   const git = asObject(parsed.git);
+  const tdd = asObject(parsed.tdd);
   return {
     git: {
       branchPrefix: typeof git.branchPrefix === "string" ? git.branchPrefix : DEFAULT_SDD_CONFIG.git.branchPrefix,
@@ -34,5 +55,9 @@ export function loadSddConfig(root = process.cwd()): SddConfig {
       commitStyle: git.commitStyle === "plain" ? "plain" : DEFAULT_SDD_CONFIG.git.commitStyle,
       baseBranch: typeof git.baseBranch === "string" ? git.baseBranch : DEFAULT_SDD_CONFIG.git.baseBranch,
     },
+    tdd: {
+      mode: tdd.mode === "off" ? "off" : DEFAULT_SDD_CONFIG.tdd.mode,
+      testCommand: typeof tdd.testCommand === "string" ? tdd.testCommand : DEFAULT_SDD_CONFIG.tdd.testCommand,
+    },
   };
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@gonrocca/zero-pi",
-  "version": "0.1.51",
+  "version": "0.1.53",
   "description": "zero-pi — an installable layer for pi (pi.dev): the zero spec-driven development workflow (explore → plan → build → veredicto) with per-phase model autotune and token-efficient batched builds. Adds capability to pi without modifying pi.",
   "type": "module",
   "keywords": [

package/prompts/forge.md

@@ -11,8 +11,22 @@ report the result as not verified. Ask the user for interactive or automatic
 mode up front; in interactive mode pause after each phase for approval. Never
 claim success unless veredicto returned `pasa`.
 
-If the request begins with `--continue [slug]`, resume that unfinished run from
-its `.sdd/<slug>/` artifacts instead of starting fresh.
+**Parse the arguments first.** If the request begins with `--continue`, this is
+a **resume** run, not a fresh one:
+
+- `--continue` with no slug → resume mode: hand control to the orchestrator's
+  `## Resuming a run` section, which scans `.sdd/*/` for an unfinished run.
+- `--continue <slug>` → resume mode targeting `.sdd/<slug>/` directly. If that
+  directory does not exist, report "no such run: <slug>" and stop — do **not**
+  start a fresh run under that slug.
+- Anything else (a feature request, or no arguments) → a fresh run: the
+  arguments are the feature request below.
+
+**Strict TDD by default.** Follow the orchestrator's `## Strict TDD forwarding`:
+build runs test-first (RED → GREEN → TRIANGULATE → REFACTOR) and emits a TDD
+Cycle Evidence table whenever a test runner exists and the work touches code;
+veredicto audits that evidence and returns `corregir` if it fails. Set
+`tdd.mode: "off"` in `.sdd/config.json` to opt a project out.
 
 **Output and language.** Follow the orchestrator's `## Language Boundary` and
 `## Output Contract`: user-facing chat in Spanish (natural Rioplatense voseo),

package/prompts/orchestrator.md

@@ -152,6 +152,29 @@ phase (re-batching whatever tasks its defects reopened) as the next round.
 **Resume is unaffected.** Each batch marks its tasks `[x]` as they land, so an
 interrupted batched build resumes from the first `[ ]` task with no new state.
 
+## Strict TDD forwarding
+
+zero runs build test-first by default. Before the **build** and **veredicto**
+phases, resolve the run's TDD mode once and forward it explicitly — never rely
+on the sub-agent to discover it alone.
+
+- Read `.sdd/config.json` at run start. `tdd.mode` is `"strict"` by default
+  (absent file or field = strict); `"off"` disables the discipline.
+- Strict TDD only *engages* when a test runner exists (`tdd.testCommand`, or one
+  the phase detects from the project) and the work touches code — the phase
+  prompts gate on this and degrade gracefully for docs/config-only changes or
+  projects with no runner. You do not need to pre-check the runner; just forward
+  the mode.
+- When mode is strict, add one line to the `zero-build` and `zero-veredicto`
+  briefs: `Strict TDD mode: strict (test command: <cmd or "auto-detect">).
+  Follow RED → GREEN → TRIANGULATE → REFACTOR and record the TDD Cycle Evidence
+  table.` When mode is `off`, forward `Strict TDD mode: off`.
+- The build writes its evidence to `.sdd/<slug>/tdd-evidence.md`; veredicto
+  audits it. Reference that artifact by path in the briefs — never paste it.
+- A veredicto that fails the TDD audit (missing evidence, a reported-green test
+  that now fails, or a CRITICAL assertion violation) returns `corregir`, which
+  re-runs build as the next round exactly like any other defect list.
+
 ## Model configuration
 
 The per-phase model assignments live in `~/.pi/zero.json`: `models` maps each

package/prompts/phases/build.md

@@ -26,6 +26,36 @@ then proceed — never fall back to scanning the whole tree.
 Implement the planned tasks in order, test-first where practical. Keep every
 change within the plan's scope — do not expand it on your own initiative.
 
+## Strict TDD gate
+
+Before writing code, resolve whether **Strict TDD Mode** is active for this run.
+It is active when **all three** hold:
+
+1. **Mode is on.** Read `.sdd/config.json`; treat `tdd.mode` as `"strict"` when
+   the file is absent or the field is missing (strict is the default). If
+   `tdd.mode` is `"off"`, Strict TDD is disabled — skip to *Standard mode* below.
+2. **A test runner exists.** Use `tdd.testCommand` from `.sdd/config.json` when
+   set; otherwise detect one from the project (`package.json` scripts,
+   `pyproject.toml`, `go.mod`, a Makefile target, etc.). If no test runner can
+   be found, Strict TDD cannot run — note it as a risk and use *Standard mode*.
+3. **The batch touches code.** A docs-, copy-, or config-only batch has nothing
+   to drive with tests — note it and use *Standard mode* for that batch.
+
+When all three hold, **Strict TDD Mode is active**. Read the support module
+`~/.pi/agent/agents/zero/support/strict-tdd.md` and follow it for every task in
+your batch: RED → GREEN → TRIANGULATE → REFACTOR, never production code before a
+failing test, run the focused test on every GREEN, and emit the **TDD Cycle
+Evidence** table to `.sdd/<slug>/tdd-evidence.md` and in your return envelope. If
+that support file is missing, do not silently drop the discipline: follow the
+RED → GREEN → TRIANGULATE → REFACTOR contract and the TDD Cycle Evidence table
+from memory, and report the missing module as a risk.
+
+## Standard mode
+
+When Strict TDD is disabled, unavailable, or the batch is code-free, implement
+the assigned tasks test-first where practical, update the task checkboxes, and
+record the verification evidence — no TDD Cycle Evidence table is required.
+
 **Scope to your batch.** When the brief names a batch — a set or contiguous
 range of task numbers — implement exactly those tasks, mark each `[x]`, and
 **return**; do not continue into later unchecked tasks (the orchestrator drives

package/prompts/phases/plan.md

@@ -84,6 +84,29 @@ Rules:
 - `evidence:` is mandatory and names a concrete verification command or artifact.
 - Keep `## Review Workload` present and synchronized with the task list.
 
+## TDD-shaped tasks
+
+Unless the project sets `tdd.mode: "off"` in `.sdd/config.json`, the build phase
+runs under **Strict TDD** whenever a test runner exists and the task touches
+code. Shape the tasks so that discipline is natural rather than bolted on:
+
+- For every code task, list its **test file alongside the production file** in
+  `files:` (mark a brand-new test `(new)`), so RED → GREEN has a home from the
+  start. A task that changes behavior with no test file in its `files:` list is
+  under-specified — add one.
+- Make `evidence:` name the **focused test command** that proves the task
+  (`npm test -- <file>`, `pytest <file>`, `go test ./pkg -run <Name>`), not a
+  vague "works" — the build runs exactly that during the cycle and veredicto
+  re-runs it.
+- Keep each task small enough that one RED → GREEN → TRIANGULATE → REFACTOR
+  cycle covers it; if a task needs several unrelated tests, split it.
+- Pure-structural tasks (a constant, a type export, a config value) need no
+  test — say so in the task `detail:` so the build phase can note
+  "Triangulation skipped" without guessing.
+
+This is guidance for the task shape only; the build phase owns the actual RED →
+GREEN cycle and the TDD Cycle Evidence table.
+
 ## Constitution / Steering check
 
 Before finalizing tasks, check project steering/constitution files when present (`.sdd/constitution.md`, `.sdd/steering.md`, `.kiro/steering/*`, or project equivalents). If absent, mark `n/a`; absence is not a blocker. Include this table in `design.md` or `tasks.md`:

package/prompts/phases/veredicto.md

@@ -39,6 +39,29 @@ Review the build adversarially, with a fresh perspective. Check it against the
 plan's requirements, run the tests yourself, and look for gaps, regressions,
 and unmet acceptance criteria.
 
+## Strict TDD audit
+
+Resolve whether **Strict TDD Mode** governed this run, by the same gate the
+build phase used: `tdd.mode` in `.sdd/config.json` is `"strict"` (the default
+when the file or field is absent) **and** a test runner exists
+(`tdd.testCommand` or one detected from the project) **and** the change touches
+code. A `.sdd/<slug>/tdd-evidence.md` file or a TDD Cycle Evidence table in the
+build result also signals it was active.
+
+When Strict TDD governed the run, read the support module
+`~/.pi/agent/agents/zero/support/strict-tdd-verify.md` and apply it: confirm the
+TDD Cycle Evidence table exists, cross-reference every reported test file
+against the codebase, run the listed tests yourself to confirm GREEN still
+holds, and audit assertion quality (no tautologies, ghost loops, lone type-only
+assertions, smoke-only tests, or implementation-detail/CSS assertions). A
+missing evidence table, a reported-green test that now fails, or a CRITICAL
+assertion violation is grounds for **`corregir`**, not `pasa`. If that support
+file is missing, perform the same checks from memory and note the missing module
+as a risk — do not skip the TDD audit.
+
+When Strict TDD did not govern the run (mode `off`, no test runner, or a
+code-free change), skip the TDD audit and review on the standard criteria below.
+
 ## Constitution / Steering gate
 
 Re-check the plan's Constitution/Steering table before choosing a verdict. If a

package/prompts/support/strict-tdd-verify.md

@@ -0,0 +1,193 @@
+# Strict TDD Module — Veredicto Phase
+
+> **This module governs the veredicto phase ONLY when Strict TDD Mode is active
+> AND a test runner is available.** The veredicto prompt already resolved both
+> conditions before pointing you here. If you are reading this, follow every
+> instruction.
+
+## TDD Verification Philosophy
+
+When Strict TDD Mode is active, the review goes beyond "does the code work?" to
+"was the code built correctly?" — meaning: was TDD actually followed? The build
+phase reports TDD evidence; your job is to validate that evidence against
+reality. A failed TDD audit is a **`corregir`** verdict, not `pasa`.
+
+## Step A — TDD Compliance Check
+
+Read the build's **TDD Cycle Evidence** table — from
+`.sdd/<slug>/tdd-evidence.md` and/or the build's return envelope — and verify
+TDD was actually followed:
+
+```
+FOR EACH task row in the TDD Cycle Evidence table:
+├── RED column:
+│   ├── Must say "✅ Written"
+│   ├── Verify: the named test file EXISTS in the codebase
+│   └── Flag: CRITICAL if the test file does not exist
+│
+├── GREEN column:
+│   ├── Must say "✅ Passed"
+│   ├── Cross-reference with your own test run (Step C):
+│   │   └── The listed test file must PASS when YOU run it
+│   └── Flag: CRITICAL if the test fails now (was it really green?)
+│
+├── TRIANGULATE column:
+│   ├── "✅ N cases" → verify N test cases exist in the file
+│   ├── "➖ Single" → verify the spec truly has only one scenario
+│   └── Flag: WARNING if the spec has multiple scenarios but only 1 test case
+│
+├── SAFETY NET column:
+│   ├── "✅ N/N" → existing tests were run before modification (good)
+│   ├── "N/A (new)" → verify the file was actually NEW, not modified
+│   └── Flag: WARNING if a modified file shows "N/A"
+│
+└── REFACTOR column:
+    └── Not strictly verifiable (subjective) — trust the report
+
+If NO "TDD Cycle Evidence" table is found:
+└── Flag: CRITICAL — the build did not report TDD evidence while Strict TDD was
+    active. This alone is grounds for a `corregir` verdict.
+
+Summary: "{N}/{total} tasks have complete TDD evidence".
+```
+
+## Step B — Test Layer Validation
+
+Classify every test file related to this change by its testing layer:
+
+```
+├── Unit test: a single function/class in isolation
+│   └── Indicators: no render(), no page., no HTTP calls, mocked deps
+├── Integration test: component interaction or user behavior
+│   └── Indicators: render(), screen., userEvent., testing-library imports
+├── E2E test: full system through a real browser/HTTP
+│   └── Indicators: page.goto(), playwright/cypress imports, browser context
+└── Unknown: cannot classify → report as-is
+
+Report the distribution (Unit / Integration / E2E counts) and, for each spec
+scenario, note which layer covers it. Flag as SUGGESTION (not blocking) if
+critical business logic only has unit tests while higher-layer tools exist.
+```
+
+## Step C — Run the Tests Yourself
+
+Run the relevant focused tests AND the full suite when available, exactly as
+reported, and confirm GREEN is still true. Report the commands you ran and any
+failures verbatim. A test that the build reported as ✅ but fails when you run
+it is a CRITICAL discrepancy.
+
+## Step D — Changed File Coverage (if a coverage tool is available)
+
+```
+IF a coverage tool is available:
+├── Run the coverage command
+├── Filter to ONLY files created/modified in this change
+├── Report per file: line %, branch %, uncovered line ranges
+│   ├── ≥ 95% → ✅ Excellent
+│   ├── ≥ 80% → ⚠️ Acceptable
+│   └── < 80% → ⚠️ Low (list the uncovered lines)
+└── Flag: WARNING (never CRITICAL) if a changed file is < 80%
+
+IF NOT available:
+└── "Coverage analysis skipped — no coverage tool detected" (not a failure).
+```
+
+## Step E — Assertion Quality Audit (MANDATORY)
+
+Scan ALL test files created or modified by this change for trivial/meaningless
+assertions:
+
+```
+FOR EACH test file related to the change:
+├── Scan for BANNED patterns:
+│   ├── Tautologies: expect(true).toBe(true), assert True, expect(1).toBe(1)
+│   │   └── CRITICAL — the test proves NOTHING
+│   ├── Orphan empty checks: expect(result).toEqual([]) / assert len(result) == 0
+│   │   └── WARNING unless a companion test with the same setup asserts NON-EMPTY
+│   ├── Type-only assertions used alone: toBeDefined(), not.toBeNull(), typeof
+│   │   └── WARNING — OK only when COMBINED with a value assertion
+│   ├── Assertions that never call production code (no call, no render, no request)
+│   │   └── CRITICAL — the test exercises nothing
+│   ├── Ghost loops: assertions inside for/forEach over queryAll/filter results
+│   │   └── CRITICAL if the collection could be empty — the loop never runs
+│   ├── Incomplete TDD cycle: passes because preconditions stop the code running
+│   │   └── CRITICAL — the code path was never exercised
+│   ├── Smoke-only: render() + toBeInTheDocument() with no behavioral assertion
+│   │   └── WARNING — does not count toward TDD coverage
+│   ├── Implementation-detail coupling: CSS classes, internal state, mock call counts
+│   │   └── WARNING — tests must assert behavior, not implementation
+│   └── Mock/assertion ratio: vi.mock()/jest.mock() count vs expect() count
+│       └── WARNING if mocks > 2× assertions — wrong test layer
+│
+├── For each violation: record file, line, the assertion, and why it's trivial.
+│
+└── Triangulation quality:
+    ├── If a behavior with multiple spec scenarios has only 1 test case → WARNING
+    └── If all cases assert the SAME trivial value (all empty arrays) → WARNING
+
+Summary: "{N} trivial assertions found across {N} files".
+```
+
+## Step F — Quality Metrics (if tools available)
+
+```
+IF a linter is available  → run on changed files; report errors/warnings.
+IF a type checker is available → run; filter to changed files; report type errors.
+IF neither → "Quality metrics skipped — no tools detected" (not a failure).
+```
+
+## Verdict Mapping
+
+Fold the TDD audit into the standard verdict:
+
+- A missing TDD Cycle Evidence table, a CRITICAL assertion violation
+  (tautology, no-production-call, ghost loop, incomplete cycle), or a test that
+  fails when you run it → **`corregir`** with the specific defects named.
+- WARNING-level findings (low coverage, smoke tests, mock-heavy, impl-detail
+  coupling, thin triangulation) do not by themselves force `corregir`, but list
+  them in the verdict reasoning so the next build round can address them.
+- Coverage/quality-tool absence is never a failure — note it and move on.
+- `pasa` requires: all evidence present, every reported GREEN actually green
+  when you run it, and no CRITICAL assertion violations.
+
+## Report Section (include in the verdict reasoning)
+
+```markdown
+### TDD Compliance
+| Check | Result | Details |
+|-------|--------|---------|
+| TDD Evidence reported | ✅ / ❌ | Found in tdd-evidence.md / Missing |
+| All tasks have tests | ✅ / ❌ | {N}/{total} tasks have test files |
+| RED confirmed (tests exist) | ✅ / ⚠️ | {N}/{total} test files verified |
+| GREEN confirmed (tests pass) | ✅ / ❌ | {N}/{total} pass on execution |
+| Triangulation adequate | ✅ / ⚠️ / ➖ | {N} triangulated / {N} single-case |
+| Safety Net for modified files | ✅ / ⚠️ | {N}/{total} had a safety net |
+
+**TDD Compliance**: {N}/{total} checks passed
+
+### Test Layer Distribution
+| Layer | Tests | Files | Tools |
+|-------|-------|-------|-------|
+| Unit | {N} | {N} | {tool} |
+| Integration | {N} | {N} | {tool or "not installed"} |
+| E2E | {N} | {N} | {tool or "not installed"} |
+
+### Assertion Quality
+| File | Line | Assertion | Issue | Severity |
+|------|------|-----------|-------|----------|
+| ... | ... | ... | ... | ... |
+
+**Assertion quality**: {N} CRITICAL, {N} WARNING
+(or "✅ All assertions verify real behavior")
+```
+
+## Rules (Strict TDD Verify specific)
+
+- ALWAYS check the TDD Cycle Evidence table — it is the primary artifact.
+- ALWAYS cross-reference the reported test files against an actual run — never trust the report blindly.
+- ALWAYS run the Assertion Quality Audit (Step E) — trivial tests are WORSE than missing tests.
+- If no TDD evidence table exists while Strict TDD is active → CRITICAL → `corregir`.
+- If a tautology assertion is found → CRITICAL → it MUST be rewritten → `corregir`.
+- Coverage and quality metrics are informational — WARNING at most, never the sole cause of `corregir`.
+- DO NOT fix issues — only report and choose the verdict. The build phase fixes on the `corregir` re-run.
+- If coverage/quality tools are absent, say so cleanly and move on — never flag a missing tool as a failure.

package/prompts/support/strict-tdd.md

@@ -0,0 +1,333 @@
+# Strict TDD Module — Build Phase
+
+> **This module governs the build phase ONLY when Strict TDD Mode is active AND
+> a test runner is available.** The build prompt already resolved both
+> conditions before pointing you here. If you are reading this, follow every
+> instruction.
+
+## TDD Philosophy
+
+TDD is not testing. TDD is **software design driven by tests**. You write a test
+that describes what the code SHOULD do, then write the minimum code to make it
+real. The tests design the API, the contracts, the behavior. Code is a side
+effect of tests.
+
+### The Three Laws
+
+1. **Do NOT write production code** until you have a failing test.
+2. **Do NOT write more test** than is necessary to fail.
+3. **Do NOT write more code** than is necessary to pass the test.
+
+## TDD Implementation Cycle
+
+For EVERY task assigned to your batch, follow this cycle strictly:
+
+```
+FOR EACH TASK:
+├── 0. SAFETY NET (only if modifying existing files)
+│   ├── Run existing tests for the files being modified
+│   ├── Capture baseline: "{N} tests passing"
+│   ├── If any FAIL → STOP, report as "pre-existing failure"
+│   │   (do NOT fix pre-existing failures — report them in the return envelope)
+│   └── This baseline proves you did not break what already worked
+│
+├── 1. UNDERSTAND
+│   ├── Read the task description and its `files:` / `evidence:` bullets
+│   ├── Read the relevant spec.md scenarios (these ARE your acceptance criteria)
+│   ├── Read the design.md decisions (these CONSTRAIN your approach)
+│   ├── Read existing code and test patterns (match the style)
+│   └── Determine the test layer (see "Choosing Test Layer" below)
+│
+├── 2. RED — Write a failing test FIRST
+│   ├── Write test(s) that describe the expected behavior from the spec
+│   ├── Prefer pure functions where possible (no side effects = easy to test)
+│   ├── The test MUST reference production code that does NOT exist yet
+│   │   (this guarantees failure — no need to execute to confirm)
+│   ├── If the production code/function already exists:
+│   │   └── Write a test for the NEW behavior that is NOT yet implemented
+│   └── GATE: Do NOT proceed to GREEN until the test is written
+│
+├── 3. GREEN — Write the MINIMUM code to pass
+│   ├── Implement ONLY what the failing test needs
+│   ├── "Fake It" is VALID here (hardcoded return values are OK)
+│   ├── EXECUTE the focused test → must PASS
+│   │   ├── ✅ Passed → proceed to TRIANGULATE or REFACTOR
+│   │   └── ❌ Failed → fix the implementation, NOT the test
+│   └── GATE: Do NOT proceed until GREEN is confirmed by execution
+│
+├── 4. TRIANGULATE (MANDATORY for most tasks)
+│   ├── DEFAULT: triangulation is REQUIRED. You need a compelling reason to skip it.
+│   ├── Add a second test case with DIFFERENT inputs/expected outputs
+│   ├── EXECUTE tests → if "Fake It" breaks (the hardcode no longer works):
+│   │   └── Generalize to real logic (this is the whole point)
+│   ├── Repeat until ALL spec scenarios for this task are covered
+│   ├── MINIMUM: at least 2 test cases per behavior (happy path + one edge case)
+│   │   ├── One test with data that produces a NON-EMPTY/NON-TRIVIAL result
+│   │   └── One test that exercises a DIFFERENT code path
+│   ├── WATCH OUT for a GREEN that passes trivially:
+│   │   ├── Passes because the component/element isn't rendered → NOT a real GREEN
+│   │   ├── Passes because a loop iterates 0 times → NOT a real GREEN
+│   │   ├── Passes because the setup never triggers the code path → NOT a real GREEN
+│   │   └── A real GREEN means: production code RAN and produced the expected output
+│   ├── Skip triangulation ONLY when ALL of these are true:
+│   │   ├── The task is purely structural (config file, constant, type export)
+│   │   ├── There is literally ONE possible output (no branching, no logic)
+│   │   └── You note "Triangulation skipped: {reason}" in the evidence table
+│   └── GATE: All spec scenarios for this task have tests before REFACTOR
+│
+├── 5. REFACTOR — Improve without changing behavior
+│   ├── Extract constants (eliminate magic numbers)
+│   ├── Extract functions (reduce cyclomatic complexity)
+│   ├── Improve naming, remove duplication, push toward pure functions
+│   ├── Apply the Boy Scout Rule: leave code cleaner than you found it
+│   ├── EXECUTE tests after EACH refactoring step → must STILL PASS
+│   │   ├── ✅ Still passing → the refactoring is safe, continue
+│   │   └── ❌ Failed → REVERT that step, try a smaller one
+│   └── GATE: Tests green after EVERY refactoring change
+│
+├── 6. Mark the task `[x]` in tasks.md
+└── 7. Note any deviations or issues discovered
+```
+
+## Choosing Test Layer
+
+```
+Determine the test layer by WHAT the task does:
+├── Pure logic, utility, calculation, data transformation
+│   └── Unit test (always available when a test runner exists)
+│
+├── Component rendering, user interaction, state changes
+│   ├── IF integration tools available → Integration test
+│   └── IF NOT → Unit test with mocks (degrade gracefully)
+│
+├── Multi-component flow, API interaction, context/provider behavior
+│   ├── IF integration tools available → Integration test
+│   └── IF NOT → Unit test with mocks
+│
+├── Critical business flow, full user journey, cross-page navigation
+│   ├── IF E2E tools available → E2E test
+│   ├── IF NOT but integration available → Integration test
+│   └── IF neither → Unit test (degrade gracefully)
+│
+└── Default: Unit test (always the fallback)
+```
+
+**Key rule**: use the HIGHEST available layer that fits the task, but NEVER skip
+a task because a layer is unavailable — degrade to the next available layer.
+
+## Test Execution
+
+Detect the test runner, in order:
+
+```
+├── `.sdd/config.json` → tdd.testCommand (explicit override, fastest)
+└── Fallback: detect from package.json / pyproject.toml / go.mod / etc.
+
+When executing tests during the cycle, run ONLY the relevant test file:
+├── JS/TS: {runner} {test-file}   (e.g. npm test -- src/utils/tax.test.ts)
+├── Python: pytest {test-file}
+├── Go: go test ./{package}/... -run {TestName}
+└── Adapt to the runner's CLI
+
+Run a focused file, not the whole suite — it keeps the cycle FAST. The full
+suite runs once at the end of the build phase (and again in veredicto).
+```
+
+## Pure Function Preference
+
+When writing production code in GREEN/TRIANGULATE, prefer pure functions:
+
+```
+✅ PREFER (pure — easy to test):
+function calculateDiscount(price: number, quantity: number): number {
+  return quantity >= 5 ? price * quantity * 0.1 : 0
+}
+
+❌ AVOID (impure — hard to test):
+function calculateDiscount(item: Item) {
+  globalState.lastDiscount = item.price * 0.1  // side effect
+  updateDOM()                                   // side effect
+  return globalState.lastDiscount
+}
+```
+
+Pure functions are deterministic (same input → same output), have no side
+effects, and are trivially testable. TDD naturally pushes you toward them —
+embrace it, but don't force it where it doesn't fit (e.g. stateful components).
+
+## Approval Testing (for refactoring existing code)
+
+When a task REFACTORS existing code (not writing new behavior):
+
+```
+BEFORE touching production code:
+├── 1. Identify the existing behavior to preserve
+├── 2. Write "approval tests" that capture the current behavior:
+│   ├── Call the function with known inputs
+│   ├── Assert the CURRENT outputs (even if ugly)
+│   └── These tests document what the code does NOW
+├── 3. Run approval tests → must PASS (they describe current reality)
+├── 4. NOW refactor the production code
+├── 5. Run approval tests again → must STILL PASS
+│   ├── ✅ Passing → refactoring preserved behavior
+│   └── ❌ Failing → refactoring broke something, revert
+└── 6. If the spec says behavior should CHANGE:
+    ├── Update the approval test to the NEW expected behavior
+    ├── Run → test FAILS (RED — new behavior not implemented yet)
+    └── Implement the new behavior → GREEN
+```
+
+## TDD Cycle Evidence (MANDATORY output)
+
+When Strict TDD Mode is active, the build phase MUST produce a **TDD Cycle
+Evidence** table. Write it to `.sdd/<slug>/tdd-evidence.md` (create the file on
+the first batch; append rows on later batches — never overwrite prior batches'
+rows) AND include it in your return envelope so the veredicto phase can audit it.
+
+```markdown
+### TDD Cycle Evidence
+| Task | Test File | Layer | Safety Net | RED | GREEN | TRIANGULATE | REFACTOR |
+|------|-----------|-------|------------|-----|-------|-------------|----------|
+| T001 | `path/test.ext` | Unit | ✅ 5/5 | ✅ Written | ✅ Passed | ✅ 3 cases | ✅ Clean |
+| T002 | `path/test.ext` | Integration | N/A (new) | ✅ Written | ✅ Passed | ➖ Single | ✅ Clean |
+| T003 | `path/test.ext` | Unit | ✅ 2/2 | ✅ Written | ✅ Passed | ✅ 2 cases | ➖ None needed |
+
+### Test Summary
+- **Total tests written**: {N}
+- **Total tests passing**: {N}
+- **Layers used**: Unit ({N}), Integration ({N}), E2E ({N})
+- **Approval tests** (refactoring): {N} or "None — no refactoring tasks"
+- **Pure functions created**: {N}
+```
+
+**Column definitions**:
+- **Safety Net**: pre-existing tests run before modifying files. "N/A (new)" for new files.
+- **RED**: test written first, referencing code that doesn't exist yet. Always "✅ Written".
+- **GREEN**: tests executed and passing after minimal implementation. Must reflect an execution.
+- **TRIANGULATE**: extra cases added to force real logic. "➖ Single" if the spec has one scenario.
+- **REFACTOR**: code improved with tests still green. "➖ None needed" if already clean.
+
+A build that omits this table when Strict TDD is active will be sent back as
+`corregir` by veredicto — the table is the contract.
+
+## Assertion Quality Rules (MANDATORY)
+
+**Every assertion must verify REAL behavior.** A test that passes without
+exercising production logic is worse than no test — it gives false confidence.
+
+### Banned Assertion Patterns (NEVER write these)
+
+```
+# TRIVIAL ASSERTIONS — the test proves nothing
+expect(true).toBe(true)              # ❌ Tautology
+expect(1).toBe(1)                    # ❌ Tautology — no production code involved
+assert True                          # ❌ Always passes
+
+# EMPTY COLLECTION ASSERTIONS without setup context
+expect(result).toEqual([])           # ❌ ONLY valid if you set up conditions for empty
+expect(result).toHaveLength(0)       # ❌ Why is it empty? Did production code run?
+assert result == []                  # ❌ Prove the emptiness comes from real logic
+
+# TYPE-ONLY ASSERTIONS — proves existence, not behavior
+expect(result).toBeDefined()         # ❌ Alone is useless — WHAT is the value?
+expect(result).not.toBeNull()        # ❌ Alone is useless — assert the actual value
+assert result is not None            # ❌ Alone — assert what result actually IS
+
+# GHOST LOOP — assertion inside a loop that iterates 0 times
+const items = screen.queryAllByTestId("item");   // returns []
+for (const item of items) {
+  expect(item).toHaveTextContent("value");        # ❌ NEVER EXECUTES — dead code
+}
+# FIX: assert the collection is non-empty FIRST, or set up data so it IS non-empty:
+expect(items).toHaveLength(3);                    # ✅ Proves items exist
+for (const item of items) { ... }                 # ✅ Now the loop actually runs
+```
+
+### What Makes a REAL Assertion
+
+Every assertion must satisfy ALL of these:
+1. **Calls production code** — invokes a function, method, or component from the implementation.
+2. **Asserts a specific output** — compares against a concrete value derived from the spec.
+3. **Would FAIL if the production code were wrong** — change the logic and THIS test breaks.
+
+```
+# ✅ REAL assertions — production code determines the result
+expect(calculateDiscount(100, 10)).toBe(10)
+expect(screen.getByText('Welcome, John')).toBeInTheDocument()
+assert response.status_code == 403
+expect(result).toHaveLength(3)                     # AND you set up exactly 3 items
+```
+
+### Empty Collection Rule
+
+`expect(result).toEqual([])` / `assert len(result) == 0` is ONLY valid when:
+1. You set up a precondition that SHOULD produce an empty result.
+2. The production code actually ran and filtered/processed data to arrive at empty.
+3. A companion test with different setup produces a NON-EMPTY result (triangulation).
+
+If you cannot explain WHY the result is empty from the setup → the assertion is trivial.
+
+### Smoke Test Rule
+
+```
+# ❌ SMOKE TEST ONLY — proves nothing about behavior
+render(<MyComponent data={mockData} />);
+expect(screen.getByTestId("wrapper")).toBeInTheDocument();
+
+# ✅ BEHAVIORAL TEST — proves what the component DOES with the data
+render(<MyComponent data={mockData} />);
+expect(screen.getByText("Expected Title")).toBeInTheDocument();
+expect(screen.getByRole("button")).toHaveTextContent("Submit");
+```
+
+"Renders without crash" is a smoke test. It does NOT count toward TDD coverage;
+if you need one, it must be accompanied by real behavioral assertions.
+
+### Mock Hygiene Rules
+
+**If you need more mocks than assertions, you are testing at the WRONG level.**
+
+```
+├── ≤ 3 mocks for a test file → ✅ Healthy — focused test
+├── 4–6 mocks → ⚠️ Consider extracting logic to a pure function
+└── 7+ mocks → ❌ STOP — wrong layer
+    ├── Extract the logic to a PURE FUNCTION and test it without mocks, OR
+    └── Move the test to the integration/E2E layer where real deps exist
+```
+
+**Extract-Before-Mock Rule**: if the behavior is a data transformation,
+mapping, filtering, or conditional logic, EXTRACT it to a pure function FIRST,
+then test the pure function directly — no mocks needed.
+
+### Implementation Detail Coupling Rule
+
+Tests must assert **behavior visible to the user**, not internal details:
+
+```
+# ❌ COUPLED — breaks on any style/internal refactor
+expect(element.className).toContain("text-xs");
+expect(mockService.mock.calls.length).toBe(3);
+expect(component.state.isLoading).toBe(true);
+
+# ✅ BEHAVIORAL — survives refactors, tests what users see
+expect(screen.getByText("Error: Payment failed")).toBeInTheDocument();
+expect(screen.getByRole("alert")).toHaveTextContent("Risk:");
+expect(screen.getByRole("button")).toBeDisabled();
+```
+
+**CSS class assertions are NEVER valid test assertions.** Verify the semantic
+outcome (role, visible text, disabled state) or use a visual-regression/E2E
+screenshot — never assert Tailwind/CSS class names.
+
+## Rules (Strict TDD specific)
+
+- NEVER write production code before its test — this is the ONE rule that cannot be broken.
+- NEVER skip the GREEN execution gate — you MUST run the test and confirm it passes.
+- NEVER skip triangulation when the spec defines multiple scenarios.
+- NEVER write trivial assertions (see Banned Patterns) — they are WORSE than no test.
+- ALWAYS verify every assertion CALLS production code and asserts a SPECIFIC value.
+- ALWAYS run the Safety Net before modifying existing files.
+- ALWAYS write the TDD Cycle Evidence table — veredicto checks it.
+- If a test-runner execution fails for infrastructure reasons (not a test failure), report it as "Blocked" and continue to the next task.
+- For refactoring tasks, ALWAYS write approval tests before touching code.
+- Run ONLY the relevant test file during the cycle, not the full suite.