ralphctl 0.2.3 → 0.2.5

package/dist/{chunk-V4ZUDZCG.mjs → chunk-DUU5346E.mjs}

@@ -2,7 +2,7 @@
 import {
   createSprint,
   setCurrentSprint
-} from "./chunk-ITRZMBLJ.mjs";
+} from "./chunk-JRFOUFD3.mjs";
 import {
   emoji,
   field,

package/dist/{chunk-7TBO6GOT.mjs → chunk-EUNAUHC3.mjs}

@@ -7,7 +7,7 @@ import {
   readValidatedJson,
   validateProjectPath,
   writeValidatedJson
-} from "./chunk-GLDPHKEW.mjs";
+} from "./chunk-IB6OCKZW.mjs";
 import {
   ParseError,
   ProjectExistsError,

package/dist/{chunk-GLDPHKEW.mjs → chunk-IB6OCKZW.mjs}

@@ -53,6 +53,13 @@ function getTasksFilePath(sprintId) {
 function getProgressFilePath(sprintId) {
   return join(getSprintDir(sprintId), "progress.md");
 }
+function getEvaluationsDir(sprintId) {
+  return join(getSprintDir(sprintId), "evaluations");
+}
+function getEvaluationFilePath(sprintId, taskId) {
+  assertSafeSegment(taskId, "task ID");
+  return join(getEvaluationsDir(sprintId), `${taskId}.md`);
+}
 function assertSafeSegment(segment, label) {
   if (!segment || segment.includes("/") || segment.includes("\\") || segment.includes("..") || segment.includes("\0")) {
     throw new Error(`Path traversal detected in ${label}: ${segment}`);
@@ -203,6 +210,7 @@ import { z } from "zod";
 var SprintStatusSchema = z.enum(["draft", "active", "closed"]);
 var TaskStatusSchema = z.enum(["todo", "in_progress", "done"]);
 var RequirementStatusSchema = z.enum(["pending", "approved"]);
+var EvaluationStatusSchema = z.enum(["passed", "failed", "malformed"]);
 var RepositorySchema = z.object({
   name: z.string().min(1),
   // Auto-derived from basename(path)
@@ -254,8 +262,12 @@ var TaskSchema = z.object({
   // Output from verification run
   evaluated: z.boolean().default(false),
   // Whether evaluation passed
-  evaluationOutput: z.string().optional()
-  // Output from evaluation run
+  evaluationOutput: z.string().optional(),
+  // Truncated output from evaluation run (full critique lives in evaluationFile)
+  evaluationStatus: EvaluationStatusSchema.optional(),
+  // Discriminator: 'passed' | 'failed' | 'malformed'
+  evaluationFile: z.string().optional()
+  // Sidecar file path containing the full untruncated critique
 });
 var TasksSchema = z.array(TaskSchema);
 var ImportTaskSchema = z.object({
@@ -309,6 +321,7 @@ export {
   getSprintFilePath,
   getTasksFilePath,
   getProgressFilePath,
+  getEvaluationFilePath,
   getRefinementDir,
   getPlanningDir,
   getIdeateDir,

package/dist/{chunk-ITRZMBLJ.mjs → chunk-JRFOUFD3.mjs}

@@ -21,7 +21,7 @@ import {
   readValidatedJson,
   removeDir,
   writeValidatedJson
-} from "./chunk-GLDPHKEW.mjs";
+} from "./chunk-IB6OCKZW.mjs";
 import {
   LockError,
   NoCurrentSprintError,

package/dist/{chunk-LAERLCL5.mjs → chunk-UBPZHHCD.mjs}

@@ -8,7 +8,7 @@ import {
 } from "./chunk-7TG3EAQ2.mjs";
 import {
   createProject
-} from "./chunk-7TBO6GOT.mjs";
+} from "./chunk-EUNAUHC3.mjs";
 import {
   ensureError,
   wrapAsync
@@ -16,7 +16,7 @@ import {
 import {
   expandTilde,
   validateProjectPath
-} from "./chunk-GLDPHKEW.mjs";
+} from "./chunk-IB6OCKZW.mjs";
 import {
   IOError,
   ProjectExistsError

package/dist/cli.mjs

@@ -2,7 +2,7 @@
 import {
   addCheckScriptToRepository,
   projectAddCommand
-} from "./chunk-LAERLCL5.mjs";
+} from "./chunk-UBPZHHCD.mjs";
 import {
   addTask,
   areAllTasksDone,
@@ -10,6 +10,7 @@ import {
   buildHeadlessAiRequest,
   buildIdeateAutoPrompt,
   buildIdeatePrompt,
+  buildProjectToolingSection,
   buildTicketRefinePrompt,
   exportRequirementsToMarkdown,
   extractJsonArray,
@@ -52,13 +53,13 @@ import {
   sprintStartCommand,
   updateTaskStatus,
   validateImportTasks
-} from "./chunk-ORVGM6EV.mjs";
+} from "./chunk-CSICORGV.mjs";
 import {
   escapableSelect
 } from "./chunk-7LZ6GOGN.mjs";
 import {
   sprintCreateCommand
-} from "./chunk-V4ZUDZCG.mjs";
+} from "./chunk-DUU5346E.mjs";
 import {
   addTicket,
   allRequirementsApproved,
@@ -73,7 +74,7 @@ import {
   removeTicket,
   ticketAddCommand,
   updateTicket
-} from "./chunk-QYF7QIZJ.mjs";
+} from "./chunk-742XQ7FL.mjs";
 import {
   EXIT_ERROR,
   exitWithCode
@@ -84,7 +85,7 @@ import {
   listProjects,
   removeProject,
   removeProjectRepo
-} from "./chunk-7TBO6GOT.mjs";
+} from "./chunk-EUNAUHC3.mjs";
 import {
   DEFAULT_EVALUATION_ITERATIONS,
   assertSprintStatus,
@@ -107,7 +108,7 @@ import {
   setEditor,
   setEvaluationIterations,
   withFileLock
-} from "./chunk-ITRZMBLJ.mjs";
+} from "./chunk-JRFOUFD3.mjs";
 import {
   ensureError,
   wrapAsync
@@ -134,7 +135,7 @@ import {
   getTasksFilePath,
   readValidatedJson,
   validateProjectPath
-} from "./chunk-GLDPHKEW.mjs";
+} from "./chunk-IB6OCKZW.mjs";
 import {
   DomainError,
   NoCurrentSprintError,
@@ -1338,8 +1339,16 @@ async function sprintIdeateCommand(args) {
   const schema = await getTaskImportSchema();
   const ideateDir = getIdeateDir(id, ticket.id);
   await mkdir(ideateDir, { recursive: true });
+  const projectToolingSection = buildProjectToolingSection(selectedPaths);
   if (options.auto) {
-    const prompt = buildIdeateAutoPrompt(ideaTitle, ideaDescription, projectName, repositoriesText, schema);
+    const prompt = buildIdeateAutoPrompt(
+      ideaTitle,
+      ideaDescription,
+      projectName,
+      repositoriesText,
+      schema,
+      projectToolingSection
+    );
     const spinner = createSpinner(`${providerName} is refining idea and planning tasks...`);
     spinner.start();
     const outputR = await wrapAsync(() => invokeAiAuto(prompt, selectedPaths, ideateDir), ensureError);
@@ -1419,7 +1428,15 @@ async function sprintIdeateCommand(args) {
     log.newline();
   } else {
     const outputFile = join(ideateDir, "output.json");
-    const prompt = buildIdeatePrompt(ideaTitle, ideaDescription, projectName, repositoriesText, outputFile, schema);
+    const prompt = buildIdeatePrompt(
+      ideaTitle,
+      ideaDescription,
+      projectName,
+      repositoriesText,
+      outputFile,
+      schema,
+      projectToolingSection
+    );
     showInfo(`Starting interactive ${providerName} session...`);
     console.log(muted(`  Exploring: ${selectedPaths.join(", ")}`));
     console.log(muted(`
@@ -3764,7 +3781,7 @@ async function interactiveMode() {
       continue;
     }
     if (command === "wizard") {
-      const { runWizard } = await import("./wizard-RCQ4QQOL.mjs");
+      const { runWizard } = await import("./wizard-XZ7OGBCJ.mjs");
       await runWizard();
       continue;
     }
@@ -4323,7 +4340,7 @@ Checks performed:
 // package.json
 var package_default = {
   name: "ralphctl",
-  version: "0.2.3",
+  version: "0.2.5",
   description: "Agent harness for long-running AI coding tasks \u2014 orchestrates Claude Code & GitHub Copilot across repositories",
   homepage: "https://github.com/lukas-grigis/ralphctl",
   type: "module",
@@ -4445,7 +4462,7 @@ registerCompletionCommands(program);
 registerDoctorCommands(program);
 async function main() {
   if (process.env["COMP_CWORD"] && process.env["COMP_POINT"] && process.env["COMP_LINE"]) {
-    const { handleCompletionRequest } = await import("./handle-2BACSJLR.mjs");
+    const { handleCompletionRequest } = await import("./handle-TA4MYNQJ.mjs");
     if (await handleCompletionRequest(program)) return;
   }
   if (process.argv.length <= 2 || process.argv[2] === "interactive") {

package/dist/{create-5MILNF7E.mjs → create-MYGOWO2F.mjs}

@@ -1,10 +1,10 @@
 #!/usr/bin/env node
 import {
   sprintCreateCommand
-} from "./chunk-V4ZUDZCG.mjs";
-import "./chunk-ITRZMBLJ.mjs";
+} from "./chunk-DUU5346E.mjs";
+import "./chunk-JRFOUFD3.mjs";
 import "./chunk-OEUJDSHY.mjs";
-import "./chunk-GLDPHKEW.mjs";
+import "./chunk-IB6OCKZW.mjs";
 import "./chunk-EDJX7TT6.mjs";
 import "./chunk-QBXHAXHI.mjs";
 export {

package/dist/{handle-2BACSJLR.mjs → handle-TA4MYNQJ.mjs}

@@ -7,7 +7,7 @@ async function handleCompletionRequest(program) {
     return false;
   }
   const tabtab = (await import("tabtab")).default;
-  const { resolveCompletions } = await import("./resolver-CFY6DIOP.mjs");
+  const { resolveCompletions } = await import("./resolver-RXEY6EJE.mjs");
   const tabEnv = tabtab.parseEnv(env);
   const completions = await resolveCompletions(program, {
     line: tabEnv.line,

package/dist/{project-XC7AXA4B.mjs → project-YONEJICR.mjs}

@@ -9,8 +9,8 @@ import {
   removeProject,
   removeProjectRepo,
   updateProject
-} from "./chunk-7TBO6GOT.mjs";
-import "./chunk-GLDPHKEW.mjs";
+} from "./chunk-EUNAUHC3.mjs";
+import "./chunk-IB6OCKZW.mjs";
 import {
   ProjectExistsError,
   ProjectNotFoundError

package/dist/prompts/harness-context.md

@@ -0,0 +1,5 @@
+<harness-context>
+Your context window will be automatically compacted as it approaches its limit, allowing you to continue working
+indefinitely. Do not stop early or rush completion due to token budget concerns — the harness manages session
+lifecycle. Focus on doing the work correctly within your designated role.
+</harness-context>

package/dist/prompts/ideate-auto.md

@@ -4,6 +4,10 @@ You are a combined requirements analyst and task planner working autonomously. T
 requirements and a dependency-ordered set of implementation tasks. Make all decisions based on the idea description and
 codebase analysis — there is no user to interact with.
 
+{{HARNESS_CONTEXT}}
+
+When finished, emit a signal from the `<signals>` block below.
+
 ## Two-Phase Protocol
 
 ### Phase 1: Refine Requirements (WHAT)
@@ -50,13 +54,34 @@ Analyze the idea and produce complete, implementation-agnostic requirements:
 
 ### Phase 2: Plan Implementation (HOW)
 
-Explore the selected repositories and produce implementation tasks:
+Phase 2 begins with reconnaissance — orient yourself in the codebase before generating tasks. Skip exploration and your
+plan will be guesswork.
+
+#### Step 0: Explore the Project
+
+Explore efficiently — read what matters, skip what does not:
+
+1. **Read project instructions first** — start with `CLAUDE.md` if it exists, and also check provider-specific files
+   such as `.github/copilot-instructions.md` and `AGENTS.md` when present. Follow any links to other documentation.
+   Check the `.claude/` directory for agents, rules, and memory (see "Project Resources" in the Planning Common
+   Context below).
+2. **Read manifest files** — `package.json`, `pyproject.toml`, `Cargo.toml`, `go.mod`, `pom.xml`, etc. for dependencies
+   and scripts
+3. **Read README** — project overview, setup, and architecture
+4. **Scan directory structure** — understand the layout before diving into files
+5. **Find similar implementations** — look for existing features similar to what the requirements call for; follow
+   their patterns
+6. **Extract verification commands** — find the exact build, test, lint, and typecheck commands from the repository
+   instruction files or project config
 
-1. **Explore codebase** — Read the repository instruction files (`CLAUDE.md`, `.github/copilot-instructions.md`, etc.)
-   when present, understand project structure, find patterns
-2. **Map requirements to implementation** — Determine which parts map to which repository
-3. **Create tasks** — Following the Planning Common Context guidelines below
-4. **Validate** — Ensure tasks are non-overlapping, properly ordered, and completable
+Read project instruction files and README first, then only the specific files needed to understand patterns and plan
+tasks — broad exploration wastes context budget without improving task quality.
+
+#### Step 1: Generate the Plan
+
+1. **Map requirements to implementation** — Determine which parts of the approved requirements map to which repository
+2. **Create tasks** — Following the Planning Common Context guidelines below
+3. **Validate** — Ensure tasks are non-overlapping, properly ordered, and completable
 
 ### Blocker Handling
 
@@ -84,17 +109,7 @@ You have access to these repositories:
 
 {{COMMON}}
 
-## Pre-Output Validation
-
-Before outputting JSON, verify:
-
-1. **Requirements complete** — Problem statement, acceptance criteria, and scope boundaries are all present
-2. **No file overlap** — No two tasks modify the same files (or overlap is delineated in steps)
-3. **Correct order** — Foundations before dependents, all `blockedBy` references point to earlier tasks
-4. **Maximized parallelism** — Independent tasks do NOT block each other unnecessarily
-5. **Precise steps** — Every task has 3+ specific, actionable steps with file references
-6. **Verification steps** — Every task ends with project-appropriate verification commands
-7. **projectPath assigned** — Every task uses a path from the Selected Repositories
+{{VALIDATION}}
 
 ## Output Format
 
@@ -149,6 +164,8 @@ If you cannot produce a valid plan, output `<planning-blocked>reason</planning-b
 }
 ```
 
+{{SIGNALS}}
+
 ---
 
 Proceed autonomously: refine the idea into clear requirements, explore the codebase, then generate tasks. Output only

package/dist/prompts/ideate.md

@@ -3,6 +3,10 @@
 You are a combined requirements analyst and task planner. Your goal is to quickly turn a rough idea into refined
 requirements and a dependency-ordered set of implementation tasks in a single session.
 
+{{HARNESS_CONTEXT}}
+
+When finished, emit a signal from the `<signals>` block below.
+
 ## Two-Phase Protocol
 
 ### Phase 1: Refine Requirements (WHAT)
@@ -27,8 +31,16 @@ Focus: Clarify WHAT needs to be built (implementation-agnostic)
    - What are the acceptance criteria? (Given/When/Then format)
    - What edge cases and error states need handling?
    - What are the business constraints? (performance, compatibility, etc.)
-3. **Stop when ready** — Stop asking questions when the problem statement is clear, requirements have acceptance
-   criteria, scope boundaries are explicit, and major edge cases are addressed
+3. **Stop when ready** — Stop asking questions when ALL of these are true:
+   - The problem statement is clear and agreed upon
+   - Every functional requirement has at least one acceptance criterion
+   - Scope boundaries (in/out) are explicitly defined
+   - Major edge cases and error states are addressed
+   - No remaining ambiguity about what the feature should do — two developers reading these requirements would build
+     the same observable behavior
+
+   If the idea description already answers all of these, skip directly to Step 4.
+
 4. **Present requirements** — Show the complete refined requirements in readable markdown, then ask for approval using
    AskUserQuestion:
    ```
@@ -103,6 +115,8 @@ Focus: Determine HOW to implement the approved requirements
    - Ask: "Does this task breakdown look correct? Any changes needed?"
 7. **Wait for confirmation** — write the JSON to the output file after the user confirms
 
+{{VALIDATION}}
+
 ## Idea to Refine and Plan
 
 **Title:** {{IDEA_TITLE}}
@@ -176,6 +190,8 @@ Use this exact JSON Schema:
 - Tasks can reference each other via `id` and `blockedBy`
 - Only write after BOTH requirements AND task breakdown are approved
 
+{{SIGNALS}}
+
 ---
 
 Start with Phase 1: Read the idea above, identify what's clear vs ambiguous, then ask your first clarifying question.

package/dist/prompts/plan-auto.md

@@ -4,6 +4,10 @@ You are a task planning specialist. Your goal is to produce a dependency-ordered
 self-contained mini-spec that an AI agent can pick up cold and complete in a single session. Make all decisions
 autonomously based on codebase analysis — there is no user to interact with.
 
+{{HARNESS_CONTEXT}}
+
+When finished, emit a signal from the `<signals>` block below.
+
 ## Protocol
 
 ### Step 1: Explore the Project
@@ -65,18 +69,7 @@ If you cannot produce a valid task breakdown, signal the issue instead of output
 
 ### Step 6: Pre-Output Validation
 
-Before outputting JSON, verify EVERY item on this checklist:
-
-1. **No file overlap** — No two tasks modify the same files (or overlap is explicitly delineated in steps)
-2. **Correct order** — Foundations before dependents
-3. **Valid dependencies** — All `blockedBy` references point to earlier tasks with real code dependencies
-4. **Maximized parallelism** — Independent tasks do NOT block each other unnecessarily
-5. **Precise steps** — Every task has 3+ specific, actionable steps with file references
-6. **Verification steps** — Every task ends with project-appropriate verification commands from the repository
-   instructions
-7. **projectPath assigned** — Every task has a `projectPath` from the project's repository paths
-8. **Verification criteria** — Every task has 2-4 verificationCriteria that are testable and unambiguous
-9. **Valid JSON** — The output parses as valid JSON matching the schema
+{{VALIDATION}}
 
 ## Output
 
@@ -142,3 +135,5 @@ JSON Schema:
   }
 ]
 ```
+
+{{SIGNALS}}

package/dist/prompts/plan-common.md

@@ -78,7 +78,7 @@ Aim for 2-4 criteria per task. Include at least one criterion that is computatio
 lint clean). For **UI/frontend tasks**, if the project has Playwright configured, add a browser-verifiable criterion —
 the evaluator will attempt visual verification using Playwright or browser tools when the project supports it.
 
-### Rules
+### Guidelines
 
 1. **Outcome-oriented** — Each task delivers a testable result
 2. **Merge create+use** — Never separate "create X" from "use X" — that is one task
@@ -108,7 +108,7 @@ the evaluator will attempt visual verification using Playwright or browser tools
 
 Tasks execute in dependency order — foundations before dependents.
 
-### Rules
+### Guidelines
 
 1. **Foundation first** — Shared utilities, types, schemas before anything that uses them
 2. **Declare all dependencies** — Use `blockedBy` to enforce order. Do not rely on array position alone.
@@ -205,3 +205,19 @@ commands.
 
 Start with an action verb (Add, Create, Update, Fix, Refactor, Remove, Migrate). Include the feature/concept, not files.
 Keep under 60 characters. Avoid vague verbs (Improve, Enhance, Handle).
+
+## Delegation to Available Tooling
+
+The "Project Tooling" section below (when present) lists subagents, skills, and MCP servers detected in the target
+repositories. Use these in your task planning:
+
+- **Surface tool delegation in task steps.** When a step's nature matches an available tool's specialization, write
+  the step so the executor knows to delegate. For example, if the tooling section lists a subagent specialized in
+  security review, security-sensitive task steps should explicitly recommend invoking it via the Task tool. Generic
+  pseudo-step: _"Delegate the final review of authentication changes to the `<name>` subagent via the Task tool."_
+- **Pull verification criteria from available tools.** UI tasks should add browser-verifiable criteria when a
+  Playwright or similar MCP is listed. Database tasks should reference DB-inspection MCPs when present.
+- **Do not invent tools.** Only reference tools that actually appear in the Project Tooling section. If the section is
+  empty or absent, omit delegation recommendations entirely — do not fabricate subagent names.
+
+{{PROJECT_TOOLING}}

package/dist/prompts/plan-interactive.md

@@ -4,6 +4,10 @@ You are a task planning specialist collaborating with the user. Your goal is to
 implementation tasks — each one a self-contained mini-spec that an AI agent can pick up cold and complete in a single
 session.
 
+{{HARNESS_CONTEXT}}
+
+When finished, emit a signal from the `<signals>` block below.
+
 ## Protocol
 
 ### Step 1: Explore the Project
@@ -47,7 +51,7 @@ selection.
 
 Using the confirmed repositories and your codebase exploration, create tasks. Use the tools available to you:
 
-Use available tools to search, explore, and read the codebase. When you need implementation decisions from the user, use AskUserQuestion:
+Use available tools to search, explore, and read the codebase. When you need implementation decisions from the user, use AskUserQuestion with:
 
 - **Recommended option first** with "(Recommended)" in the label
 - **2-4 options** with descriptions explaining trade-offs
@@ -109,18 +113,7 @@ If you encounter issues that prevent planning, communicate clearly:
 
 ### Step 7: Pre-Output Checklist
 
-Before writing the final JSON, verify every item:
-
-- [ ] Each task modifies 1-3 primary files (up to 5-7 total including tests)
-- [ ] No two tasks modify the same files without clear delineation in their steps
-- [ ] Tasks are ordered so foundations come before dependents
-- [ ] Every `blockedBy` reference points to an earlier task that produces code this task needs
-- [ ] Independent tasks do NOT block each other (parallelism maximized)
-- [ ] Every task has 3+ specific, actionable steps with file references
-- [ ] Steps reference concrete files and functions from the actual codebase
-- [ ] Each task includes verification using commands from the repository instruction files (if available)
-- [ ] Every task has 2-4 verificationCriteria that are testable and unambiguous
-- [ ] Every task has a `projectPath` from the project's repository paths
+{{VALIDATION}}
 
 ## Sprint Context
 
@@ -185,6 +178,8 @@ Use this exact JSON Schema:
 }
 ```
 
+{{SIGNALS}}
+
 ---
 
 Start by reading the repository instruction files and exploring the codebase, then discuss the approach with the user.

package/dist/prompts/signals-evaluation.md

@@ -0,0 +1,6 @@
+<signals>
+
+- `<evaluation-passed>` — All four dimensions pass; implementation accepted
+- `<evaluation-failed>critique</evaluation-failed>` — One or more dimensions fail; critique describes specific issues to fix
+
+</signals>

package/dist/prompts/signals-planning.md

@@ -0,0 +1,5 @@
+<signals>
+
+- `<planning-blocked>reason</planning-blocked>` — Cannot produce a valid plan; describe the blocker
+
+</signals>

package/dist/prompts/signals-task.md

@@ -0,0 +1,7 @@
+<signals>
+
+- `<task-verified>output</task-verified>` — Records verification results (required before completion)
+- `<task-complete>` — Marks task as done (ONLY after verified)
+- `<task-blocked>reason</task-blocked>` — Marks task as blocked (cannot proceed)
+
+</signals>

package/dist/prompts/task-evaluation-resume.md

@@ -0,0 +1,34 @@
+# Evaluator Feedback — Fix and Re-verify
+
+You are a task implementer responding to a code review. The independent reviewer's findings are
+authoritative — fix each issue precisely, re-verify, and signal completion.
+
+{{HARNESS_CONTEXT}}
+
+When finished, emit a signal from the `<signals>` block below.
+
+<constraints>
+
+- **Stay within scope** — fix only what the critique flags; do not expand the task or refactor neighboring code
+- **Fix, don't rewrite** — make minimal targeted changes; preserve the existing implementation structure where possible
+- **Don't argue with the critique** — treat reviewer findings as authoritative; if a finding is genuinely wrong, signal `<task-blocked>` instead of ignoring it
+
+</constraints>
+
+## Critique
+
+{{CRITIQUE}}
+
+## Fix Protocol
+
+1. **Address each issue** — Reference the file:line locations the reviewer cited. If a citation is
+   wrong, find the actually-affected location and fix that.
+2. **Re-run verification** — Run the project's check script (or the equivalent verification
+   commands) and confirm they pass.{{COMMIT_INSTRUCTION}}
+3. **Output verification results** — Wrap output in `<task-verified>...</task-verified>`.
+4. **Signal completion** — Output `<task-complete>` ONLY after all steps above pass.
+
+If an issue is unfixable (contradicts the spec, or requires changes outside your scope), signal
+`<task-blocked>reason</task-blocked>` instead of completing.
+
+{{SIGNALS}}

package/dist/prompts/task-evaluation.md

@@ -3,6 +3,10 @@
 You are an independent code reviewer evaluating whether an implementation satisfies its specification. Assume problems
 exist until you prove otherwise through investigation.
 
+{{HARNESS_CONTEXT}}
+
+When finished, emit a signal from the `<signals>` block below.
+
 <task-specification>
 
 These verification criteria are the pre-agreed definition of "done" — your primary grading rubric.
@@ -22,6 +26,8 @@ You are working in this project directory:
 {{PROJECT_PATH}}
 ```
 
+{{PROJECT_TOOLING}}
+
 ### Phase 1: Computational Verification (run before reasoning)
 
 Run deterministic checks first — these are cheap, fast, and authoritative.
@@ -178,3 +184,5 @@ Each issue must reference which dimension it violates.]
 >    query: `WHERE name LIKE $1` with `%${query}%` as parameter.
 
 Be direct and specific — point to files, lines, and concrete problems.
+
+{{SIGNALS}}

package/dist/prompts/task-execution.md

@@ -6,13 +6,11 @@ completion. Do not expand scope beyond what the declared steps specify.
 Implement the task described in {{CONTEXT_FILE}}. The task directive and implementation steps are at the top of that
 file.
 
-<harness-context>
-Your context window will be automatically compacted as it approaches its limit, allowing you to continue working
-indefinitely. Do not stop tasks early or rush completion due to token budget concerns. The harness manages session
-lifecycle — focus on doing the work correctly.
-</harness-context>
+{{HARNESS_CONTEXT}}
 
-<rules>
+When finished, emit a signal from the `<signals>` block below.
+
+<constraints>
 
 - **One task only** — complete this task, then stop. The harness manages task sequencing; continuing to the next task
   would conflict with parallel execution.
@@ -29,7 +27,7 @@ lifecycle — focus on doing the work correctly.
 - **Leave task definitions unchanged** — the task name, description, steps, and other task files are immutable.
   {{COMMIT_CONSTRAINT}}
 
-</rules>
+</constraints>
 
 ## Phase 1: Reconnaissance (feedforward — understand before acting)
 
@@ -77,9 +75,9 @@ Proceed to Phase 2 once all reconnaissance steps pass.
    - If a step is unclear, attempt reasonable interpretation before marking blocked
    - If steps seem incomplete relative to ticket requirements, signal `<task-blocked>` rather than improvising —
      the planner may have intentionally scoped them this way to avoid conflicts
-3. **Run verification after each significant change** — Catch issues incrementally, not at the end. Run the check script
-   or relevant test commands after each meaningful code change. This is cheaper than debugging a pile of errors at the
-   end.
+3. **Smoke-test as you go** — Run relevant test or typecheck commands after each meaningful code change to catch issues
+   early. This is incremental sanity-checking, not the final gate. **The authoritative gate is Phase 3 step 2 below:
+   the full check script runs there and must pass.**
 
 ## Phase 3: Completion
 
@@ -88,8 +86,7 @@ Complete these steps IN ORDER:
 1. **Confirm all steps done** — Every task step has been completed
 2. **Run ALL verification commands** — Execute every verification command (see Check Script section in the context file
    or project instructions). Fix any failures before proceeding. The harness runs the check script as a post-task
-   gate — your task is not marked done unless it passes.
-   {{COMMIT_STEP}}
+   gate — your task is not marked done unless it passes.{{COMMIT_STEP}}
 3. **Update progress file** — Append to {{PROGRESS_FILE}} using this format:
 
    ```markdown
@@ -175,10 +172,4 @@ Signal `<task-blocked>Missing dependency: [what and which task]</task-blocked>`.
 Follow project patterns over steps if they conflict. If steps seem incomplete relative to requirements:
 `<task-blocked>Steps incomplete: [what appears missing]</task-blocked>`.
 
-<signals>
-
-- `<task-verified>output</task-verified>` — Records verification results (required before completion)
-- `<task-complete>` — Marks task as done (ONLY after verified)
-- `<task-blocked>reason</task-blocked>` — Marks task as blocked (cannot proceed)
-
-</signals>
+{{SIGNALS}}