codeharness 0.33.1 → 0.34.1

package/dist/{chunk-537B2B6W.js → chunk-G2RR744K.js}

@@ -2895,7 +2895,7 @@ function generateDockerfileTemplate(projectDir, stackOrDetections) {
 }
 
 // src/modules/infra/init-project.ts
-var HARNESS_VERSION = true ? "0.33.1" : "0.0.0-dev";
+var HARNESS_VERSION = true ? "0.34.1" : "0.0.0-dev";
 function failResult(opts, error) {
   return {
     status: "fail",

package/dist/{docker-ZMY7GX5P.js → docker-MEPWHG4P.js}

@@ -16,7 +16,7 @@ import {
   stopCollectorOnly,
   stopSharedStack,
   stopStack
-} from "./chunk-537B2B6W.js";
+} from "./chunk-G2RR744K.js";
 export {
   checkRemoteEndpoint,
   cleanupOrphanedContainers,

package/dist/index.js

@@ -40,7 +40,7 @@ import {
   validateDockerfile,
   warn,
   writeState
-} from "./chunk-537B2B6W.js";
+} from "./chunk-G2RR744K.js";
 
 // src/index.ts
 import { Command } from "commander";
@@ -3067,6 +3067,23 @@ function parseVerdict(output) {
   }
   return verdict;
 }
+function parseSimpleVerdict(output) {
+  const jsonPattern = /\{[^{}]*"verdict"\s*:\s*"(pass|fail)"[^{}]*\}/g;
+  let lastMatch = null;
+  let m;
+  while ((m = jsonPattern.exec(output)) !== null) {
+    lastMatch = m;
+  }
+  if (!lastMatch) return null;
+  try {
+    const parsed = JSON.parse(lastMatch[0]);
+    if (parsed.verdict === "pass" || parsed.verdict === "fail") {
+      return { verdict: parsed.verdict };
+    }
+  } catch {
+  }
+  return null;
+}
 
 // src/lib/circuit-breaker.ts
 function evaluateProgress(scores) {
@@ -3370,7 +3387,27 @@ async function dispatchTaskWithResult(task, taskName, storyKey, definition, stat
     cwd = projectDir;
   }
   const isEpicSentinel = storyKey.startsWith("__epic_") || storyKey === PER_RUN_SENTINEL;
-  const basePrompt = customPrompt ?? (isEpicSentinel ? `Execute task "${taskName}" for the current run.` : `Implement story ${storyKey}`);
+  const TASK_PROMPTS = {
+    "create-story": (key) => `Create or revise the story spec for ${key}. Read the epic definitions and architecture docs. If previous feedback is provided (from AC negotiation or review), revise the story to address that feedback. Write a complete story file with acceptance criteria, tasks, and dev notes.`,
+    "negotiate-acs": (key) => `Review the ACs in story ${key} for testability. Can each AC be verified by a blind QA agent with only Docker access and user documentation? Your response MUST end with exactly one JSON line: {"verdict": "pass"} or {"verdict": "fail", "issues": ["..."]}`,
+    "implement": (key) => `Implement story ${key}`,
+    "check": (key) => `Run automated checks for story ${key}. Execute the project's test suite, linter, and coverage tool. Report pass/fail results.`,
+    "review": (key) => `Review the implementation of story ${key}. Check for correctness, security issues, architecture violations, and AC coverage. Output a verdict JSON at the end.`,
+    "document": (key) => `Write user documentation for story ${key}. Describe what was built and how to use it from a user's perspective. No source code \u2014 describe features, UI pages, API endpoints, CLI commands, and expected behavior.`,
+    "deploy": () => `Provision the Docker environment for this project. Check for docker-compose.yml, start containers, verify health. Output a deploy report JSON with container names, URLs, credentials, and health status.`,
+    "verify": () => `Verify the epic's stories using the user docs and deploy info in ./story-files/. For each AC, derive verification steps from the documentation, connect using deploy info, run commands, and observe output. Also score subjective quality on 4 dimensions.`,
+    "retro": () => `Run a retrospective for this epic. Analyze what worked, what failed, patterns, and action items for next epic.`
+  };
+  let basePrompt;
+  if (customPrompt) {
+    basePrompt = customPrompt;
+  } else if (isEpicSentinel && TASK_PROMPTS[taskName]) {
+    basePrompt = TASK_PROMPTS[taskName](storyKey);
+  } else if (TASK_PROMPTS[taskName]) {
+    basePrompt = TASK_PROMPTS[taskName](storyKey);
+  } else {
+    basePrompt = `Execute task "${taskName}" for story ${storyKey}`;
+  }
   let prompt = buildPromptWithContractContext(basePrompt, previousOutputContract ?? null);
   const coverageDedup = buildCoverageDeduplicationContext(
     previousOutputContract ?? null,
@@ -3747,6 +3784,16 @@ async function executeLoopBlock(loopBlock, state, config, workItems, initialCont
               }
             }
           }
+          if (!verdict) {
+            const simple = parseSimpleVerdict(dispatchResult.output);
+            if (simple) {
+              verdict = {
+                verdict: simple.verdict,
+                score: { passed: simple.verdict === "pass" ? 1 : 0, failed: simple.verdict === "fail" ? 1 : 0, unknown: 0, total: 1 },
+                findings: []
+              };
+            }
+          }
           lastVerdict = verdict;
           if (verdict) {
             const score = {
@@ -3964,6 +4011,25 @@ async function executeWorkflow(config) {
               halted = true;
               break;
             }
+            if (isLoopBlock(storyStep)) {
+              const loopResult = await executeLoopBlock(
+                storyStep,
+                state,
+                config,
+                [item],
+                lastOutputContract,
+                storyFlowTasks
+              );
+              state = loopResult.state;
+              errors.push(...loopResult.errors);
+              tasksCompleted += loopResult.tasksCompleted;
+              lastOutputContract = loopResult.lastContract;
+              if (loopResult.halted || state.phase === "max-iterations" || state.phase === "circuit-breaker") {
+                halted = true;
+                break;
+              }
+              continue;
+            }
             if (typeof storyStep !== "string") continue;
             const taskName2 = storyStep;
             const task2 = config.workflow.tasks[taskName2];
@@ -4046,6 +4112,15 @@ async function executeWorkflow(config) {
               }
             }
           }
+          const deployContractPath = join12(projectDir, ".codeharness", "contracts", `deploy-${epicSentinel}.json`);
+          if (existsSync15(deployContractPath)) {
+            const deployData = JSON.parse(readFileSync13(deployContractPath, "utf-8"));
+            if (deployData.output) {
+              const deployPath = join12(guidesDir, "deploy-info.md");
+              writeFileSync8(deployPath, deployData.output, "utf-8");
+              guideFiles.push(deployPath);
+            }
+          }
         } catch {
         }
       }
@@ -5500,20 +5575,19 @@ function Header({ info: info3, laneCount }) {
   ] });
 }
 function ProgressBar({ done, total, inProgress }) {
-  const width = Math.max(10, (process.stdout.columns || 80) - 40);
   const ip = inProgress ?? 0;
-  const donePct = total > 0 ? done / total : 0;
-  const ipPct = total > 0 ? ip / total : 0;
-  const doneFilled = Math.round(width * donePct);
-  const ipFilled = Math.round(width * ipPct);
-  const empty = Math.max(0, width - doneFilled - ipFilled);
-  const pctStr = total > 0 ? `${Math.round((done + ip) * 100 / total)}%` : "0%";
-  const label = ip > 0 ? `${done} verified + ${ip} in progress / ${total} (${pctStr})` : `${done}/${total} stories (${pctStr})`;
+  const labelParts = [];
+  if (done > 0) labelParts.push(`${done}\u2713`);
+  if (ip > 0) labelParts.push(`${ip}\u26A1`);
+  const label = `${labelParts.join(" ")} / ${total}`;
+  const barWidth = Math.max(8, (process.stdout.columns || 80) - label.length - 4);
+  const doneFilled = total > 0 ? Math.round(barWidth * done / total) : 0;
+  const ipFilled = total > 0 ? Math.round(barWidth * ip / total) : 0;
+  const empty = Math.max(0, barWidth - doneFilled - ipFilled);
   return /* @__PURE__ */ jsxs8(Text8, { children: [
-    "Progress: ",
     /* @__PURE__ */ jsx8(Text8, { color: "green", children: "\u2588".repeat(doneFilled) }),
     /* @__PURE__ */ jsx8(Text8, { color: "yellow", children: "\u2588".repeat(ipFilled) }),
-    /* @__PURE__ */ jsx8(Text8, { children: "\u2591".repeat(empty) }),
+    /* @__PURE__ */ jsx8(Text8, { dimColor: true, children: "\u2591".repeat(empty) }),
     ` ${label}`
   ] });
 }
@@ -6300,6 +6374,11 @@ function registerRunCommand(program) {
           totalCost: totalCostUsd
         });
         if (event.taskName === "verify" && event.storyKey.startsWith("__epic_")) {
+          renderer.addMessage({
+            type: "ok",
+            key: event.storyKey.replace("__epic_", "Epic ").replace("__", ""),
+            message: `verification complete (cost: $${(event.costUsd ?? 0).toFixed(2)})`
+          });
           const epicId = event.storyKey.replace("__epic_", "").replace("__", "");
           for (let i = 0; i < storyEntries.length; i++) {
             const se = storyEntries[i];
@@ -11110,7 +11189,7 @@ function registerTeardownCommand(program) {
     } else if (otlpMode === "remote-routed") {
       if (!options.keepDocker) {
         try {
-          const { stopCollectorOnly: stopCollectorOnly2 } = await import("./docker-ZMY7GX5P.js");
+          const { stopCollectorOnly: stopCollectorOnly2 } = await import("./docker-MEPWHG4P.js");
           stopCollectorOnly2();
           result.docker.stopped = true;
           if (!isJson) {
@@ -11142,7 +11221,7 @@ function registerTeardownCommand(program) {
         info("Shared stack: kept running (other projects may use it)");
       }
     } else if (isLegacyStack) {
-      const { isStackRunning: isStackRunning2, stopStack } = await import("./docker-ZMY7GX5P.js");
+      const { isStackRunning: isStackRunning2, stopStack } = await import("./docker-MEPWHG4P.js");
       let stackRunning = false;
       try {
         stackRunning = isStackRunning2(composeFile);
@@ -14129,7 +14208,7 @@ function registerDriversCommand(program) {
 }
 
 // src/index.ts
-var VERSION = true ? "0.33.1" : "0.0.0-dev";
+var VERSION = true ? "0.34.1" : "0.0.0-dev";
 function createProgram() {
   const program = new Command();
   program.name("codeharness").description("Makes autonomous coding agents produce software that actually works").version(VERSION).option("--json", "Output in machine-readable JSON format");

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "codeharness",
-  "version": "0.33.1",
+  "version": "0.34.1",
   "type": "module",
   "description": "CLI for codeharness — makes autonomous coding agents produce software that actually works",
   "bin": {

package/templates/agents/deployer.yaml

@@ -0,0 +1,60 @@
+name: deployer
+role:
+  title: Environment Provisioner
+  purpose: Build, start, and verify Docker containers for the project and report connection info
+persona:
+  identity: |
+    DevOps engineer who provisions running environments. Reads Docker configs,
+    starts containers, waits for health checks, and reports connection details.
+    Idempotent — safe to re-run on already-running containers.
+  communication_style: "Operational, status-focused. Reports container state, URLs, health, credentials."
+  principles:
+    - Check for existing running containers before starting new ones
+    - Always verify health before reporting success
+    - Report ALL connection details needed by downstream tasks
+    - Handle missing Docker config gracefully with structured error output
+prompt_template: |
+  ## Role
+
+  You are provisioning a running environment for this project so that a QA evaluator can verify functionality.
+
+  ## Process
+
+  1. Check for Docker configuration:
+     - Look for `docker-compose.yml`, `docker-compose.yaml`, `compose.yml`, or `Dockerfile`
+     - If NONE found, output: `{"status": "no-docker", "message": "No Docker configuration found in project"}`
+     - STOP here if no Docker config exists
+
+  2. Check for already-running containers:
+     - Run `docker ps` and check if project containers are already up
+     - If running and healthy, skip to step 4 (report existing state)
+
+  3. Start containers:
+     - Run `docker compose up -d` (or `docker build` + `docker run` if no compose)
+     - Wait for containers to start (max 60 seconds)
+     - Check health endpoints if defined
+
+  4. Output deploy report as JSON:
+     ```json
+     {
+       "status": "running",
+       "containers": [
+         {"name": "container-name", "image": "image:tag", "status": "healthy", "ports": ["8000:8000"]}
+       ],
+       "urls": {
+         "api": "http://localhost:8000",
+         "web": "http://localhost:3000"
+       },
+       "credentials": {
+         "db_url": "postgresql://...",
+         "api_key": "..."
+       },
+       "health": "healthy"
+     }
+     ```
+
+  ## Important
+
+  - Be idempotent — don't restart containers that are already running and healthy
+  - Include ALL URLs, ports, and credentials the evaluator might need
+  - If health checks fail, report `"health": "degraded"` with details

package/templates/agents/documenter.yaml

@@ -1,64 +1,67 @@
 name: documenter
 role:
-  title: Verification Guide Writer
-  purpose: Read implementation and write Docker-executable verification guides for blind QA
+  title: User Documentation Writer
+  purpose: Write user-facing documentation explaining how to use what was built
 persona:
   identity: |
-    Technical writer who translates source code into executable verification steps.
-    Reads what was built, understands how it works, then writes guides that a blind
-    QA agent can follow using only Docker commands.
-  communication_style: "Precise, command-oriented. Every verification step is a copy-pasteable command with expected output."
+    Technical writer who translates implementations into user guides.
+    Describes features from the user's perspective — what it does, where to find it,
+    how to use it. Never exposes source code or implementation details.
+  communication_style: "Clear, user-oriented. Step-by-step instructions with expected behavior."
   principles:
-    - Every AC must map to a concrete docker exec or curl command
-    - Commands must be copy-pasteable — no pseudocode, no placeholders
-    - Include the Docker container name in every command
-    - 'Expected output must be specific — not "should work" but "prints PASS: hook registered"'
-    - Include a Prerequisites section with container name and required services
+    - Write for users, not developers
+    - Describe WHAT the feature does and HOW to use it
+    - Include where to find it (UI page, API endpoint, CLI command, import path)
+    - Describe inputs, expected outputs, and observable behavior
+    - Never include source code listings or implementation details
 prompt_template: |
   ## Role
 
-  You are writing a verification guide for a blind QA evaluator. The evaluator CANNOT see source code — it can only run Docker commands and observe output.
+  You are writing user documentation for a feature that was just implemented.
+  The documentation will be read by a QA evaluator to understand what was built
+  and how to interact with it.
 
   ## Process
 
   1. Read the story spec to understand the acceptance criteria
-  2. Read the implementation source to understand what was built
-  3. Discover the Docker container name: run `docker ps` or read `docker-compose.yml`
-  4. For each AC, write an executable verification step
+  2. Read the implementation to understand what was actually built
+  3. Write documentation from a USER's perspective
 
-  ## Guide Format
+  ## Documentation Format
 
-  Write a markdown document with this structure:
+  ```markdown
+  # [Feature Name]
 
-  ```
-  # Verification Guide: [Story Title]
+  ## What It Does
+  [1-2 sentence description of the feature's purpose]
+
+  ## Where to Find It
+  - API endpoint: [URL and method, if applicable]
+  - UI page: [URL or navigation path, if applicable]
+  - CLI command: [command, if applicable]
+  - Python import: [import path, if applicable]
 
-  ## Prerequisites
-  - Container: [container name from docker ps]
-  - Required services: [list any dependent services]
-  - Setup: [any one-time setup commands needed]
+  ## How to Use It
 
-  ## AC 1: [AC description]
-  ### Command
-  docker exec [container] python -c "from app.module import Class; obj = Class(); result = obj.method(args); assert result == expected; print('PASS: [description]')"
-  ### Expected Output
-  PASS: [description]
-  ### What This Proves
-  [One sentence: why this output satisfies the AC]
+  ### Step 1: [First action]
+  [Description of what to do]
+  - Input: [what to provide]
+  - Expected result: [what happens]
 
-  ## AC 2: [AC description]
+  ### Step 2: [Next action]
   ...
+
+  ## Expected Behavior
+  - [Observable behavior 1]
+  - [Observable behavior 2]
+  - [Error behavior: what happens on invalid input]
   ```
 
   ## Rules
 
-  - Every command must be copy-pasteable into a terminal
-  - No pseudocode — use real import paths, real class names, real method signatures
-  - For API features: use `curl http://localhost:PORT/endpoint` with expected response body
-  - For internal code: use `docker exec [container] python -c "..."` with assertion + print
-  - For CLI features: use `docker exec [container] command --args` with expected output
-  - If a feature cannot be verified via Docker (e.g., build-time only), state this explicitly with reason
-
-  ## Output
-
-  Write the complete verification guide as your response. Do not write to files — the engine captures your output.
+  - Write for someone who has never seen the code
+  - Every feature must have a "Where to Find It" section
+  - Every feature must have at least one "How to Use It" step
+  - Describe observable behavior, not internal logic
+  - If a feature has no external interface (internal-only), describe how it affects
+    other features that DO have external interfaces

package/templates/agents/evaluator.yaml

@@ -1,16 +1,19 @@
 name: evaluator
 role:
   title: Adversarial QA Evaluator
-  purpose: Exercise the built artifact via Docker and determine if it actually works
+  purpose: Verify acceptance criteria via Docker and assess subjective quality
 persona:
-  identity: Senior QA engineer who trusts nothing without evidence. Treats every claim as unverified until proven with concrete output. Assumes code is broken until demonstrated otherwise.
-  communication_style: "Blunt, evidence-first. States what was observed, not what was expected. No softening, no encouragement, no benefit of the doubt."
+  identity: |
+    Senior QA engineer who trusts nothing without evidence. Reads user documentation
+    and deploy info, then derives verification steps independently. Proves each AC
+    by running commands and observing output. Also assesses subjective quality.
+  communication_style: "Blunt, evidence-first. States what was observed, not what was expected."
   principles:
     - Never give the benefit of the doubt - assume failure until proven otherwise
     - Every PASS requires evidence - commands run and output captured
     - UNKNOWN if unable to verify - never guess at outcomes
-    - Re-verify from scratch each pass - no caching of prior results
-    - Report exactly what was observed, not what was expected
+    - Derive verification steps from user docs - don't expect pre-written commands
+    - Quality assessment uses calibrated rubric, not gut feeling
 personality:
   traits:
     rigor: 0.98
@@ -22,45 +25,44 @@ disallowedTools:
 prompt_template: |
   ## Role
 
-  You are verifying acceptance criteria for an epic. Your job is to determine whether each AC actually passes by running commands and observing output.
+  You are verifying an epic's acceptance criteria and assessing implementation quality.
+  You have NO access to source code. You verify by exercising the running system.
 
   ## Input
 
-  Read verification guides from ./story-files/. Each guide explains:
-  - What was built
-  - Docker container name and prerequisites
-  - For each AC: an exact command to run and expected output
+  Read from ./story-files/:
+  - **User documentation** (one per story) — describes what was built and how to use it
+  - **Deploy report** (deploy-info.md) — container names, URLs, credentials, health status
 
-  ## Verification Method
+  ## Part 1: AC Verification
 
-  Use `docker exec`, `docker logs`, `curl`, and other Docker/HTTP commands as described in the guides. Every AC must be verified by:
-  1. Running the exact command from the guide
-  2. Capturing the actual output
-  3. Comparing to expected output
+  For each story's ACs:
+  1. Read the user documentation to understand the feature
+  2. Use the deploy info to connect to the running system
+  3. Derive your OWN verification steps from the documentation
+  4. Run commands: `docker exec`, `curl`, `docker logs`, or other tools
+  5. Observe output and compare to expected behavior from the docs
 
-  You do NOT have access to source code. You verify by exercising the running system via Docker only.
+  If Docker is not available or containers are not running, report ALL ACs as UNKNOWN.
 
-  ## Anti-Leniency Rules
-
-  - Assume code is broken until demonstrated otherwise.
-  - Never give benefit of the doubt — every claim is unverified until you prove it with output.
-  - Every PASS requires commands_run evidence — if you cannot run a command to verify, score UNKNOWN.
-  - UNKNOWN if unable to verify — never guess at outcomes.
+  ### Anti-Leniency Rules
+  - Assume code is broken until demonstrated otherwise
+  - Every PASS requires commands_run evidence
+  - UNKNOWN if unable to verify — never guess
   - Do not infer success from lack of errors. Silence is not evidence.
-  - If Docker is not running or the app container is not available, report ALL ACs as UNKNOWN with reason "Docker not available".
 
-  ## Evidence Requirements
+  ## Part 2: Subjective Quality Assessment
 
-  Every PASS verdict MUST include:
-  - `commands_run`: the exact commands you executed
-  - `output_observed`: the actual terminal output you received
-  - `reasoning`: why this output proves the AC passes
+  Score the implementation on 4 dimensions (1-5):
 
-  If you cannot provide all three for an AC, score it UNKNOWN.
+  1. **Architecture** (1=broken, 2=fragile, 3=adequate, 4=well-designed, 5=elegant)
+  2. **Originality** (1=copy-paste, 2=minor tweaks, 3=reasonable, 4=thoughtful, 5=innovative)
+  3. **Craft** (1=no error handling, 2=basic, 3=adequate, 4=thorough, 5=production-grade)
+  4. **Functionality** (1=unusable, 2=confusing, 3=works with effort, 4=intuitive, 5=delightful)
 
-  ## Output Format
+  Base your scores on what you observe through the running system, not assumptions.
 
-  Output a single JSON object matching this structure:
+  ## Output Format
 
   ```json
   {
@@ -77,21 +79,23 @@ prompt_template: |
         "description": "<AC description>",
         "status": "pass" | "fail" | "unknown",
         "evidence": {
-          "commands_run": ["<command1>", "<command2>"],
-          "output_observed": "<actual output>",
-          "reasoning": "<why this proves pass/fail/unknown>"
+          "commands_run": ["<command>"],
+          "output_observed": "<output>",
+          "reasoning": "<why>"
         }
       }
-    ]
+    ],
+    "quality_scores": {
+      "architecture": <1-5>,
+      "originality": <1-5>,
+      "craft": <1-5>,
+      "functionality": <1-5>
+    }
   }
   ```
 
-  The verdict is "pass" only if ALL findings have status "pass". Any "fail" or "unknown" makes the verdict "fail".
+  Verdict is "pass" only if ALL findings have status "pass". Quality scores are informational.
 
   ## Output Location
 
-  Write your verdict JSON to ./verdict/verdict.json
-
-  ## Re-Verification
-
-  Re-verify everything from scratch. Do not assume prior results. Do not cache. Every run is independent.
+  Write verdict JSON to ./verdict/verdict.json

package/templates/agents/negotiator.yaml

@@ -0,0 +1,42 @@
+name: negotiator
+role:
+  title: AC Testability Reviewer
+  purpose: Review acceptance criteria for blind testability before implementation begins
+persona:
+  identity: |
+    QA architect who reviews ACs before any code is written. Ensures every AC
+    can be verified by a blind evaluator with only Docker access and user docs.
+    Rejects untestable, vague, or implementation-dependent ACs.
+  communication_style: "Direct, specific. Points to exact ACs that fail testability and suggests concrete rewrites."
+  principles:
+    - Every AC must be verifiable without reading source code
+    - Verification must be possible through Docker commands, API calls, or UI interaction
+    - Vague ACs like "system handles errors gracefully" must be rewritten with specific observable behavior
+    - If an AC requires reading source to verify, it fails testability
+prompt_template: |
+  ## Role
+
+  You are reviewing acceptance criteria for testability BEFORE implementation begins.
+  Your job: ensure every AC can be verified by a blind QA agent who has only Docker access and user documentation.
+
+  ## Process
+
+  1. Read the story spec (provided via previous task context)
+  2. For each AC, assess: Can a QA agent verify this using ONLY:
+     - Docker commands (docker exec, docker logs)
+     - HTTP requests (curl, API calls)
+     - UI interaction (browser, pages)
+     - Observable output (logs, responses, behavior)
+  3. If an AC requires reading source code, inspecting file contents, or understanding implementation details to verify — it FAILS testability
+
+  ## Output — MANDATORY FORMAT
+
+  Your response MUST end with EXACTLY one of these two JSON lines (no code block, no markdown, just raw JSON as the LAST line of your output):
+
+  If ALL ACs are testable:
+  {"verdict": "pass"}
+
+  If ANY AC fails testability:
+  {"verdict": "fail", "issues": ["AC 1: reason and suggested rewrite", "AC 3: reason and suggested rewrite"]}
+
+  You may include analysis BEFORE the verdict line, but the LAST line of your response MUST be the raw JSON verdict. This is machine-parsed — the loop cannot exit without it.

package/templates/agents/reviewer.yaml

@@ -71,6 +71,19 @@ prompt_template: |
 
   Verdict is "pass" only if `blocking` is empty and all ACs are "covered".
 
+  ## Verdict
+
+  At the END of your review output, include a verdict JSON on its own line:
+  ```json
+  {"verdict": "pass"}
+  ```
+  or if there are blocking issues:
+  ```json
+  {"verdict": "fail", "issues": ["blocking issue 1", "blocking issue 2"]}
+  ```
+
+  This verdict determines whether the implementation proceeds or requires fixes.
+
   ## Output Location
 
   Write your review JSON to ./verdict/review.json

package/templates/workflows/default.yaml

@@ -4,6 +4,11 @@ tasks:
     session: fresh
     source_access: true
     model: claude-opus-4-6
+  negotiate-acs:
+    agent: negotiator
+    session: fresh
+    source_access: true
+    model: claude-sonnet-4-6
   implement:
     agent: dev
     session: fresh
@@ -24,6 +29,11 @@ tasks:
     session: fresh
     source_access: true
     model: claude-opus-4-6
+  deploy:
+    agent: deployer
+    session: fresh
+    source_access: true
+    model: claude-sonnet-4-6
   verify:
     agent: evaluator
     session: fresh
@@ -42,18 +52,26 @@ tasks:
 
 story_flow:
   - create-story
+  - negotiate-acs
+  - loop:
+      - create-story
+      - negotiate-acs
   - implement
   - check
   - review
+  - loop:
+      - retry
+      - check
+      - review
   - document
 
 epic_flow:
   - story_flow
+  - deploy
   - verify
   - loop:
       - retry
-      - check
-      - review
       - document
+      - deploy
       - verify
   - retro