fifony 0.1.47 → 0.1.48

package/dist/chunk-AFP36N23.js

@@ -0,0 +1,134 @@
+import {
+  init_helpers,
+  now
+} from "./chunk-DLSPRIQL.js";
+import {
+  __esm,
+  __export
+} from "./chunk-Z6ZWNWWR.js";
+
+// src/agents/template-variants.ts
+var template_variants_exports = {};
+__export(template_variants_exports, {
+  getActiveVariants: () => getActiveVariants,
+  getVariant: () => getVariant,
+  listVariants: () => listVariants,
+  loadVariantsFromSettings: () => loadVariantsFromSettings,
+  registerVariant: () => registerVariant,
+  selectVariant: () => selectVariant,
+  unregisterVariant: () => unregisterVariant
+});
+function registerVariant(variant) {
+  registry.set(variant.id, variant);
+}
+function unregisterVariant(id) {
+  if (id === "baseline" || id === "full-trace-inline") return false;
+  return registry.delete(id);
+}
+function getActiveVariants() {
+  return [...registry.values()].filter((v) => v.active);
+}
+function getVariant(id) {
+  return registry.get(id) ?? null;
+}
+function listVariants() {
+  return [...registry.values()];
+}
+function selectVariant(method = "default") {
+  const active = getActiveVariants();
+  if (active.length === 0) {
+    return { variantId: "full-trace-inline", selectedAt: now(), selectionMethod: method };
+  }
+  let selected;
+  if (method === "weighted-random") {
+    const totalWeight = active.reduce((sum, v) => sum + v.weight, 0);
+    let random = Math.random() * totalWeight;
+    selected = active[active.length - 1];
+    for (const variant of active) {
+      random -= variant.weight;
+      if (random <= 0) {
+        selected = variant;
+        break;
+      }
+    }
+  } else {
+    selected = registry.get("full-trace-inline") ?? active[0];
+  }
+  return {
+    variantId: selected.id,
+    selectedAt: now(),
+    selectionMethod: method
+  };
+}
+function loadVariantsFromSettings(variants) {
+  if (!Array.isArray(variants)) return;
+  for (const raw of variants) {
+    if (!raw || typeof raw !== "object") continue;
+    const v = raw;
+    if (typeof v.id !== "string" || !v.id) continue;
+    if (v.id === "baseline" || v.id === "full-trace-inline") {
+      const existing = registry.get(v.id);
+      if (typeof v.weight === "number") existing.weight = v.weight;
+      if (typeof v.active === "boolean") existing.active = v.active;
+      continue;
+    }
+    registerVariant({
+      id: v.id,
+      description: typeof v.description === "string" ? v.description : "",
+      weight: typeof v.weight === "number" ? v.weight : 1,
+      active: typeof v.active === "boolean" ? v.active : true,
+      parameters: {
+        budgetMultiplier: typeof v.parameters?.budgetMultiplier === "number" ? v.parameters.budgetMultiplier : 1,
+        inlineTraceContent: Boolean(v.parameters?.inlineTraceContent),
+        hypothesisGeneration: Boolean(v.parameters?.hypothesisGeneration),
+        lessonExtraction: Boolean(v.parameters?.lessonExtraction)
+      }
+    });
+  }
+}
+var registry, BASELINE_VARIANT, FULL_TRACE_VARIANT;
+var init_template_variants = __esm({
+  "src/agents/template-variants.ts"() {
+    init_helpers();
+    registry = /* @__PURE__ */ new Map();
+    BASELINE_VARIANT = {
+      id: "baseline",
+      description: "Default retry context behavior \u2014 summary-based with file references",
+      weight: 1,
+      active: true,
+      parameters: {
+        budgetMultiplier: 1,
+        inlineTraceContent: false,
+        hypothesisGeneration: false,
+        lessonExtraction: false
+      }
+    };
+    FULL_TRACE_VARIANT = {
+      id: "full-trace-inline",
+      description: "Inline trace content, causal hypotheses, cross-issue lessons",
+      weight: 1,
+      active: true,
+      parameters: {
+        budgetMultiplier: 1,
+        inlineTraceContent: true,
+        hypothesisGeneration: true,
+        lessonExtraction: true
+      }
+    };
+    registry.set(BASELINE_VARIANT.id, BASELINE_VARIANT);
+    registry.set(FULL_TRACE_VARIANT.id, FULL_TRACE_VARIANT);
+  }
+});
+
+export {
+  registerVariant,
+  unregisterVariant,
+  getActiveVariants,
+  getVariant,
+  listVariants,
+  selectVariant,
+  loadVariantsFromSettings,
+  template_variants_exports,
+  init_template_variants
+};
+//# sourceMappingURL=chunk-AFP36N23.js.map

package/dist/{chunk-AAZKYWOY.js → chunk-AFYKGVSP.js}

@@ -5,15 +5,110 @@ import { TemplateEngine } from "recker";
 var PROMPT_TEMPLATES = {
   "agent-provider-base": '{{#if isPlanner}}\nRole: planner.\nAnalyze the issue and prepare an execution plan for the implementation agents.\nDo not claim the issue is complete unless the plan itself is the deliverable.\n{{else}}\n{{#if isReviewer}}\nRole: reviewer.\nInspect the workspace and review the current implementation critically.\nIf rework is required, emit `FIFONY_STATUS=continue` and provide actionable `nextPrompt` feedback.\nEmit `FIFONY_STATUS=done` only when the work is acceptable.\n{{else}}\nRole: executor.\nImplement the required changes in the workspace.\nUse any planner guidance or prior reviewer feedback already persisted in the workspace.\n{{/if}}\n{{/if}}\n\n{{#if hasImpeccableOverlay}}\nImpeccable overlay is active.\nRaise the bar on UI polish, clarity, responsiveness, visual hierarchy, and interaction quality.\n{{#if isReviewer}}\nReview with a stricter frontend and product-quality standard than a normal correctness-only pass.\n{{else}}\nWhen touching frontend work, do not settle for baseline implementation quality.\n{{/if}}\n{{/if}}\n\n{{#if hasFrontendDesignOverlay}}\nFrontend-design overlay is active.\nPrefer stronger hierarchy, spacing, and readability decisions over generic implementation choices.\n{{/if}}\n\n{{#if selectionReason}}\nSelection reason: {{selectionReason}}\n{{/if}}\n{{#if overlays.length}}\nActive overlays:\n{{#each overlays}}\n- {{this}}\n{{/each}}\n{{/if}}\n\n{{#if profileInstructions}}\n## Agent Profile\n{{profileInstructions}}\n{{/if}}\n\n{{#if capabilitiesManifest}}\n{{capabilitiesManifest}}\n{{/if}}\n\n{{#if skillContext}}\n{{skillContext}}\n{{/if}}\n\n{{#if targetPaths.length}}\nTarget paths: {{targetPaths | join ", "}}\n{{/if}}\n\nWorkspace: {{workspacePath}}\n\n{{basePrompt}}\n',
   // src/agents/prompts/agent-provider-base.stub.md
-  "agent-turn": 'Continue working on {{issueIdentifier}}.\nTurn {{turnIndex}} of {{maxTurns}}.\n\n{{#if isFinalTurns}}\n\u26A0\uFE0F **Turn budget warning: {{turnsRemaining}} turn(s) remaining.**\nThis is one of your last turns. Prioritize delivering working, testable code over perfection.\nIf the issue cannot be completed in {{turnsRemaining}} turn(s), write a `fifony-result.json` with `"status": "blocked"` and a clear summary of what remains.\n{{/if}}\n{{#if isContextPressure}}\n\u26A0\uFE0F **Context pressure: ~{{contextWindowPct}}% of context window used.**\nAvoid loading large files unnecessarily. Prefer targeted edits over full rewrites. If helpful, write a checkpoint file summarizing progress so far.\n{{/if}}\n\nBase objective:\n{{basePrompt}}\n\nContinuation guidance:\n{{continuation}}\n\nPrevious command output tail:\n```text\n{{outputTail}}\n```\n\nBefore exiting successfully, emit one of the following control markers:\n- `FIFONY_STATUS=continue` if more turns are required.\n- `FIFONY_STATUS=done` if the issue is complete.\n- `FIFONY_STATUS=blocked` if manual intervention is required.\nYou may also write `fifony-result.json` with `{ "status": "...", "summary": "...", "nextPrompt": "..." }`.\n',
+  "agent-turn": 'Continue working on {{issueIdentifier}}.\nTurn {{turnIndex}} of {{maxTurns}}.\n\n{{#if isFinalTurns}}\n\u26A0\uFE0F **Turn budget warning: {{turnsRemaining}} turn(s) remaining.**\nThis is one of your last turns. Prioritize delivering working, testable code over perfection.\nIf the issue cannot be completed in {{turnsRemaining}} turn(s), write a `fifony-result.json` with `"status": "blocked"` and a clear summary of what remains.\n{{/if}}\n{{#if isContextPressure}}\n\u26A0\uFE0F **Context pressure: ~{{contextWindowPct}}% of context window used.**\nAvoid loading large files unnecessarily. Prefer targeted edits over full rewrites. If helpful, write a checkpoint file summarizing progress so far.\n{{/if}}\n\n## Turn Guidance\n\n- Go straight to the point. Try the simplest approach first.\n- If your previous approach failed, diagnose WHY before trying again \u2014 don\'t retry the identical action.\n- If you made partial progress, build on it. If you\'re stuck on the same error, try a fundamentally different strategy.\n- Keep output concise. Lead with what you did and what happened, not reasoning or preamble.\n- Before marking done, verify your changes work: run tests, check the build, inspect output. Report outcomes faithfully.\n\nBase objective:\n{{basePrompt}}\n\nContinuation guidance:\n{{continuation}}\n\nPrevious command output tail:\n```text\n{{outputTail}}\n```\n\nBefore exiting successfully, emit one of the following control markers:\n- `FIFONY_STATUS=continue` if more turns are required.\n- `FIFONY_STATUS=done` if the issue is complete.\n- `FIFONY_STATUS=blocked` if manual intervention is required.\nYou may also write `fifony-result.json` with `{ "status": "...", "summary": "...", "nextPrompt": "..." }`.\n',
   // src/agents/prompts/agent-turn.stub.md
   "compile-contract-negotiation": 'Negotiate the pre-execution contract for {{issueIdentifier}} before any code is written.\n\nTitle: {{title}}\nDescription: {{description}}\nWorkspace: {{workspacePath}}\n\n# Your Role: Adversarial Contract Negotiator\n\nYou are reviewing the execution contract before implementation begins.\nYour job is to make sure the planner and the executor cannot move the goalposts later.\n\nYou are NOT reviewing code. You are reviewing whether the planned work is concrete, testable, scoped correctly, and hard enough for the later execution/review loop to enforce.\n\nRound {{round}} of {{maxRounds}}.\n\n# Reviewer Routing\n\nProvider: {{reviewerProvider}}{{#if reviewerModel}} / {{reviewerModel}}{{/if}}{{#if reviewerEffort}} / effort {{reviewerEffort}}{{/if}}\n{{#if reviewerSelectionReason}}\nSelection reason: {{reviewerSelectionReason}}\n{{/if}}\n{{#if reviewerOverlays.length}}\nReviewer overlays:\n{{#each reviewerOverlays}}\n- {{value}}\n{{/each}}\n{{/if}}\n\n{{#if reviewProfile}}\n# Review Profile\n\nPrimary profile: **{{reviewProfile.primary}}**\nSeverity bias: {{reviewProfile.severityBias}}\n{{#if reviewProfileSecondary.length}}\nSecondary profiles:\n{{#each reviewProfileSecondary}}\n- {{value}}\n{{/each}}\n{{/if}}\n{{#if reviewProfileRationale.length}}\nWhy this profile was selected:\n{{#each reviewProfileRationale}}\n- {{value}}\n{{/each}}\n{{/if}}\nFocus areas:\n{{#each reviewProfileFocusAreas}}\n- {{value}}\n{{/each}}\nFailure modes to probe aggressively:\n{{#each reviewProfileFailureModes}}\n- {{value}}\n{{/each}}\nEvidence priorities:\n{{#each reviewProfileEvidencePriorities}}\n- {{value}}\n{{/each}}\n{{/if}}\n\n{{#if planPrompt}}\n# Current Plan\n\n{{planPrompt}}\n{{/if}}\n\n{{#if acceptanceCriteria.length}}\n# Acceptance Criteria\n\nReview these as a contract, not as execution results:\n{{#each acceptanceCriteria}}\n- **{{id}}** [{{category}}]{{#if blocking}} blocking{{else}} advisory{{/if}}, weight {{weight}}: {{description}}\n  Verify via: {{verificationMethod}}\n  Evidence expected: {{evidenceExpected}}\n{{/each}}\n{{/if}}\n\n{{#if executionContract}}\n# Execution Contract\n\nSummary: {{executionContract.summary}}\nCheckpoint policy: {{executionContract.checkpointPolicy}}\n{{#if deliverables.length}}\nDeliverables:\n{{#each deliverables}}\n- {{value}}\n{{/each}}\n{{/if}}\n{{#if requiredChecks.length}}\nRequired checks:\n{{#each requiredChecks}}\n- {{value}}\n{{/each}}\n{{/if}}\n{{#if requiredEvidence.length}}\nRequired evidence:\n{{#each requiredEvidence}}\n- {{value}}\n{{/each}}\n{{/if}}\n{{#if executionContract.focusAreas.length}}\nFocus areas:\n{{#each executionContract.focusAreas}}\n- {{this}}\n{{/each}}\n{{/if}}\n{{/if}}\n\n{{#if currentNegotiationStatus}}\n# Negotiation History\n\nCurrent negotiation status: {{currentNegotiationStatus}}\n{{#if priorNegotiationSummary}}\nPrevious negotiation feedback:\n{{priorNegotiationSummary}}\n{{/if}}\n{{/if}}\n\n# What to critique\n\nLook for:\n- vague or untestable acceptance criteria\n- missing blocking criteria for risky behavior\n- missing validation commands or required evidence\n- focus areas that are too broad or too weak\n- harness mode that is too weak for the risk level\n- execution steps that do not actually line up with the contract\n- contracts that are easy for the executor to game with superficial implementation\n\n# Output decision\n\nUse `approved` only when the contract is specific enough that:\n- an executor can build against it without ambiguity\n- a reviewer can fail it with concrete evidence\n- the harness mode and checkpoint policy match the real risk\n\nUse `revise` whenever any blocking concern remains.\n\nAt the end of your response, you MUST emit a JSON block tagged `contract_decision` in exactly this format:\n\n```json contract_decision\n{\n  "status": "approved",\n  "summary": "Short summary of the contract quality.",\n  "rationale": "Why the contract is or is not execution-ready.",\n  "concerns": [\n    {\n      "id": "NC-1",\n      "severity": "blocking",\n      "area": "acceptance_criteria",\n      "problem": "The current criteria do not prove that the API contract is preserved.",\n      "requiredChange": "Add a blocking criterion that requires probing the route and checking status codes and payload shape."\n    }\n  ]\n}\n```\n\nRules:\n- `status` must be `approved` or `revise`.\n- If any concern has severity `blocking`, `status` MUST be `revise`.\n- `concerns` must be empty when `status` is `approved`.\n- `area` must be one of: `harness_mode`, `steps`, `acceptance_criteria`, `execution_contract`, `validation`, `suggested_paths`.\n- Keep concerns concrete and directly actionable by the planner.\n\nAfter the `contract_decision` block:\n- If `status` is `approved`, emit `FIFONY_STATUS=done`\n- If `status` is `revise`, emit `FIFONY_STATUS=continue` and put the most important contract fixes in `nextPrompt`\n',
   // src/agents/prompts/compile-contract-negotiation.stub.md
-  "compile-execution-claude": '{{#if isPlanner}}\nRole: planner. Analyze the issue and prepare an execution plan.\n{{else}}\n{{#if isReviewer}}\nRole: reviewer. Inspect and review the implementation critically.\n{{else}}\nRole: executor. Implement the required changes.\n{{/if}}\n{{/if}}\n\n{{#if profileInstructions}}\n## Agent Profile\n{{profileInstructions}}\n{{/if}}\n\n{{#if capabilitiesManifest}}\n{{capabilitiesManifest}}\n{{/if}}\n\n{{#if skillContext}}\n{{skillContext}}\n{{/if}}\n\n{{planPrompt}}\n\n{{#if suggestedAgents.length}}\n## Delegation\nFifony may decompose this work into specialist subtasks:\n{{#each suggestedAgents}}\n- **{{this}}**\n{{/each}}\n\n{{#if hasNativeSubagents}}\nYour current runtime supports native subagents. Use them for independent subtasks to maximize parallelism.\n{{else}}\nYour current runtime may not expose native subagents. Preserve the same delegation semantics by keeping subtask boundaries explicit and using a single integration owner for the final result.\n{{/if}}\n{{/if}}\n\n{{#if suggestedSkills.length}}\n## Skills\nInvoke these skills during execution:\n{{#each suggestedSkills}}\n- Run **/{{this}}** for specialized quality checks and procedures.\n{{/each}}\n{{/if}}\n\n{{#if suggestedPaths.length}}\nTarget paths: {{suggestedPaths | join ", "}}\n{{/if}}\n\nWorkspace: {{workspacePath}}\n\nIssue: {{issueIdentifier}}\nTitle: {{title}}\nDescription: {{description}}\n\n## Structured Input\nThe file `execution-payload.json` in the workspace contains the canonical structured data for this task.\nUse it as the source of truth for constraints, success criteria, execution intent, and plan details.\nIf there is any conflict between this prompt and the structured fields in the payload, prioritize the payload.\n\n{{#if validationItems.length}}\n## Pre-completion enforcement\nBefore reporting done, verify:\n{{#each validationItems}}\n- {{value}}\n{{/each}}\n{{/if}}\n',
+  "compile-execution-claude": `{{#if isPlanner}}
+Role: planner. Analyze the issue and prepare an execution plan.
+{{else}}
+{{#if isReviewer}}
+Role: reviewer. Inspect and review the implementation critically.
+{{else}}
+Role: executor. Implement the required changes.
+
+## Execution Principles
+
+Do NOT over-engineer. The goal is the SMALLEST correct change, nothing more:
+- A bug fix = fix the bug. Don't clean up surrounding code or add unrelated improvements.
+- A feature = add that one feature. Don't add extra configurability or future-proofing.
+- Don't create helpers, utilities, or abstractions for one-time operations. Three similar lines of code is better than a premature abstraction.
+- Don't add error handling, fallbacks, or validation for scenarios that can't happen. Trust internal code and framework guarantees. Only validate at system boundaries.
+- Don't add docstrings, comments, or type annotations to code you didn't change. Only add comments where the WHY is non-obvious.
+
+If an approach fails, diagnose WHY before switching tactics \u2014 read the error, check your assumptions, try a focused fix. Don't retry the identical action blindly, but don't abandon a viable approach after a single failure either.
+
+Before reporting done, VERIFY your work actually works: run the tests, check the build, inspect the output. If you can't verify (no test exists, can't run the code), say so explicitly rather than claiming success. Never claim "all tests pass" when output shows failures, and never suppress failing checks to manufacture a green result.
+{{/if}}
+{{/if}}
+
+{{#if profileInstructions}}
+## Agent Profile
+{{profileInstructions}}
+{{/if}}
+
+{{#if capabilitiesManifest}}
+{{capabilitiesManifest}}
+{{/if}}
+
+{{#if skillContext}}
+{{skillContext}}
+{{/if}}
+
+{{planPrompt}}
+
+{{#if suggestedAgents.length}}
+## Delegation
+Specialist agents available for this work:
+{{#each suggestedAgents}}
+- **{{this}}**
+{{/each}}
+
+{{#if hasNativeSubagents}}
+Your runtime supports native subagents. **Parallelism is your superpower.** Use subagents for independent subtasks:
+- **Research tasks** (reading files, searching code, checking tests) \u2014 run in parallel freely.
+- **Write tasks on different file sets** \u2014 run in parallel (no shared files).
+- **Write tasks on the same files** \u2014 run serially (one at a time).
+- Launch multiple subagents in a single turn when they're independent.
+- After subagents complete, synthesize their findings before continuing. Never delegate understanding \u2014 you must understand results before acting on them.
+{{else}}
+Your runtime doesn't expose native subagents. Keep subtask boundaries explicit and execute serially. Focus on one step at a time.
+{{/if}}
+{{/if}}
+
+{{#if suggestedSkills.length}}
+## Skills
+Invoke these skills during execution:
+{{#each suggestedSkills}}
+- Run **/{{this}}** for specialized quality checks and procedures.
+{{/each}}
+{{/if}}
+
+{{#if suggestedPaths.length}}
+Target paths: {{suggestedPaths | join ", "}}
+{{/if}}
+
+{{#if outputStyleVerbose}}
+## Output Style: Verbose
+Explain your reasoning as you work. Describe what you're investigating, what you found, and why you chose each approach. This is useful for debugging and auditing.
+{{else}}
+## Output Style: Concise
+Keep your output brief and direct. Lead with what you did and what happened. Skip preamble, filler words, and unnecessary transitions. Don't narrate each step \u2014 focus on decisions, results, and blockers.
+{{/if}}
+
+Workspace: {{workspacePath}}
+
+Issue: {{issueIdentifier}}
+Title: {{title}}
+Description: {{description}}
+
+## Structured Input
+The file \`execution-payload.json\` in the workspace contains the canonical structured data for this task.
+Use it as the source of truth for constraints, success criteria, execution intent, and plan details.
+If there is any conflict between this prompt and the structured fields in the payload, prioritize the payload.
+
+{{#if validationItems.length}}
+## Pre-completion enforcement
+Before reporting done, verify:
+{{#each validationItems}}
+- {{value}}
+{{/each}}
+{{/if}}
+`,
   // src/agents/prompts/compile-execution-claude.stub.md
-  "compile-execution-codex": '{{#if isReviewer}}\nRole: reviewer. Inspect and review the implementation critically.\n{{else}}\n{{#if isPlanner}}\nRole: planner. Analyze and prepare an execution plan.\n{{else}}\nRole: executor. Implement the required changes in the workspace.\n{{/if}}\n{{/if}}\n\n{{#if profileInstructions}}\n## Agent Profile\n{{profileInstructions}}\n{{/if}}\n\n{{#if capabilitiesManifest}}\n{{capabilitiesManifest}}\n{{/if}}\n\n{{#if skillContext}}\n{{skillContext}}\n{{/if}}\n\nIssue: {{issueIdentifier}}\nTitle: {{title}}\nDescription: {{description}}\nWorkspace: {{workspacePath}}\n\n{{planPrompt}}\n\n{{#if phases.length}}\n## Checkpoint Execution (Codex mode)\nExecute in strict phases. After each phase, verify outputs before proceeding.\n{{#each phases}}\n- **{{phaseName}}**: {{goal}}\n{{#if outputs.length}}  Checkpoint: verify {{outputs | join ", "}} before next phase.{{/if}}\n{{/each}}\n{{else}}\n## Execution Order\nExecute steps in order. Verify each step\'s `doneWhen` criterion before proceeding.\n{{/if}}\n\n{{#if suggestedPaths.length}}\nTarget paths: {{suggestedPaths | join ", "}}\nFocus changes on these paths. Do not make unnecessary changes elsewhere.\n{{/if}}\n\n{{#if suggestedSkills.length}}\n## Skills\nInvoke these skills during execution:\n{{#each suggestedSkills}}\n- Run **/{{this}}** for specialized quality checks and procedures.\n{{/each}}\n{{/if}}\n\n{{#if suggestedAgents.length}}\n## Delegation\nFifony may decompose this work into specialist subtasks:\n{{#each suggestedAgents}}\n- **{{this}}**\n{{/each}}\n\n{{#if hasNativeSubagents}}\nYour current runtime supports native subagents. Use them for independent subtasks when that improves throughput.\n{{else}}\nYour current runtime may not expose native subagents. Preserve the same delegation semantics by keeping subtask boundaries explicit and maintaining a single integration owner for the final result.\n{{/if}}\n{{/if}}\n\n{{#if validationItems.length}}\n## Pre-completion checks\nBefore reporting done, run:\n{{#each validationItems}}\n- {{value}}\n{{/each}}\n{{/if}}\n\n## Structured Input\nThe file `execution-payload.json` in the workspace contains the canonical structured data for this task.\nUse it as the source of truth for constraints, success criteria, execution intent, and plan details.\nIf there is any conflict between this prompt and the structured fields in the payload, prioritize the payload.\n\n## Output Format\n\n{{outputContract}}\n',
+  "compile-execution-codex": "{{#if isReviewer}}\nRole: reviewer. Inspect and review the implementation critically.\n{{else}}\n{{#if isPlanner}}\nRole: planner. Analyze and prepare an execution plan.\n{{else}}\nRole: executor. Implement the required changes in the workspace.\n\nDo NOT over-engineer. Implement the SMALLEST correct change:\n- A bug fix = fix the bug. Don't refactor surrounding code.\n- Don't create abstractions for one-time operations. Three similar lines beat a premature abstraction.\n- Don't add error handling for impossible scenarios.\n- If an approach fails, diagnose why before retrying. Don't repeat the same mistake.\n- Before reporting done, verify your work: run tests, check the build. Never claim success without evidence.\n{{/if}}\n{{/if}}\n\n{{#if profileInstructions}}\n## Agent Profile\n{{profileInstructions}}\n{{/if}}\n\n{{#if capabilitiesManifest}}\n{{capabilitiesManifest}}\n{{/if}}\n\n{{#if skillContext}}\n{{skillContext}}\n{{/if}}\n\n{{#if outputStyleVerbose}}\n## Output Style: Verbose\nExplain your reasoning as you work. Describe what you're investigating and why.\n{{else}}\n## Output Style: Concise\nKeep output brief. Lead with what you did and what happened. Skip filler.\n{{/if}}\n\nIssue: {{issueIdentifier}}\nTitle: {{title}}\nDescription: {{description}}\nWorkspace: {{workspacePath}}\n\n{{planPrompt}}\n\n{{#if phases.length}}\n## Checkpoint Execution (Codex mode)\nExecute in strict phases. After each phase, verify outputs before proceeding.\n{{#each phases}}\n- **{{phaseName}}**: {{goal}}\n{{#if outputs.length}}  Checkpoint: verify {{outputs | join \", \"}} before next phase.{{/if}}\n{{/each}}\n{{else}}\n## Execution Order\nExecute steps in order. Verify each step's `doneWhen` criterion before proceeding.\n{{/if}}\n\n{{#if suggestedPaths.length}}\nTarget paths: {{suggestedPaths | join \", \"}}\nFocus changes on these paths. Do not make unnecessary changes elsewhere.\n{{/if}}\n\n{{#if suggestedSkills.length}}\n## Skills\nInvoke these skills during execution:\n{{#each suggestedSkills}}\n- Run **/{{this}}** for specialized quality checks and procedures.\n{{/each}}\n{{/if}}\n\n{{#if suggestedAgents.length}}\n## Delegation\nSpecialist agents available:\n{{#each suggestedAgents}}\n- **{{this}}**\n{{/each}}\n\n{{#if hasNativeSubagents}}\nYour runtime supports subagents. Use them for independent subtasks:\n- Research (reading, searching) \u2014 parallel freely.\n- Writes on different files \u2014 parallel.\n- Writes on same files \u2014 serial.\n{{else}}\nNo native subagents. Execute steps serially, keeping subtask boundaries clear.\n{{/if}}\n{{/if}}\n\n{{#if validationItems.length}}\n## Pre-completion checks\nBefore reporting done, run:\n{{#each validationItems}}\n- {{value}}\n{{/each}}\n{{/if}}\n\n## Structured Input\nThe file `execution-payload.json` in the workspace contains the canonical structured data for this task.\nUse it as the source of truth for constraints, success criteria, execution intent, and plan details.\nIf there is any conflict between this prompt and the structured fields in the payload, prioritize the payload.\n\n## Output Format\n\n{{outputContract}}\n",
   // src/agents/prompts/compile-execution-codex.stub.md
-  "compile-review": 'Review the work done for {{issueIdentifier}}.\n\nTitle: {{title}}\nDescription: {{description}}\nWorkspace: {{workspacePath}}\n{{#if images.length}}\n\n## Visual Evidence (screenshots attached to this issue)\n{{#each images}}\n- {{this}}\n{{/each}}\nCompare the implementation against these screenshots if they show expected behavior or bugs.\n{{/if}}\n\n{{#if planPrompt}}\n# Original Execution Plan\n\n{{planPrompt}}\n{{/if}}\n\n{{#if lightReview}}\n# Your Role: Quick Sanity Check\n\nThis is a low-complexity task. Do a quick verification \u2014 don\'t over-analyze.\nCheck that the change matches what was requested and doesn\'t break anything obvious.\nKeep your review brief and focused.\n{{else}}\n# Your Role: Adversarial Quality Gate\n\nYou are NOT a collaborator \u2014 you are a skeptical evaluator. Your job is to find reasons to FAIL this work, not to be encouraging. Assume the implementation is incomplete until proven otherwise. The executor is incentivised to ship; you are incentivised to catch what they missed.\n{{/if}}\n\n# Review Scope\n\nCurrent review scope: **{{reviewScopeLabel}}** (`{{reviewScope}}`)\nGoal: {{reviewScopeGoal}}\nVerdict rule: {{reviewScopeVerdictRule}}\n{{#if reviewScopeInstructions.length}}\nScope instructions:\n{{#each reviewScopeInstructions}}\n- {{value}}\n{{/each}}\n{{/if}}\n\n{{#unless lightReview}}\n# Reviewer Routing\n\nProvider: {{reviewerProvider}}{{#if reviewerModel}} / {{reviewerModel}}{{/if}}{{#if reviewerEffort}} / effort {{reviewerEffort}}{{/if}}\n{{#if reviewerSelectionReason}}\nSelection reason: {{reviewerSelectionReason}}\n{{/if}}\n{{#if reviewerOverlays.length}}\nReviewer overlays:\n{{#each reviewerOverlays}}\n- {{value}}\n{{/each}}\n{{/if}}\n\n{{#if reviewProfile}}\n# Review Profile\n\nPrimary profile: **{{reviewProfile.primary}}**\nSeverity bias: {{reviewProfile.severityBias}}\n{{#if reviewProfileSecondary.length}}\nSecondary profiles:\n{{#each reviewProfileSecondary}}\n- {{value}}\n{{/each}}\n{{/if}}\n{{#if reviewProfileRationale.length}}\nWhy this profile was selected:\n{{#each reviewProfileRationale}}\n- {{value}}\n{{/each}}\n{{/if}}\nFocus areas:\n{{#each reviewProfileFocusAreas}}\n- {{value}}\n{{/each}}\nFailure modes to probe aggressively:\n{{#each reviewProfileFailureModes}}\n- {{value}}\n{{/each}}\nEvidence priorities:\n{{#each reviewProfileEvidencePriorities}}\n- {{value}}\n{{/each}}\n{{/if}}\n{{/unless}}\n\n{{#if acceptanceCriteria.length}}\n{{#if lightReview}}\n# Acceptance Criteria (quick check)\n\n{{#each acceptanceCriteria}}\n- **{{id}}**{{#if blocking}} blocking{{/if}}: {{description}}\n{{/each}}\n\nBriefly confirm each criterion is met. No need for exhaustive evidence on low-complexity work.\n{{else}}\n# Acceptance Criteria (grade EACH one)\n\nYou MUST evaluate every criterion below. Do not skip any.\n\n{{#each acceptanceCriteria}}\n- **{{id}}** [{{category}}]{{#if blocking}} blocking{{else}} advisory{{/if}}, weight {{weight}}: {{description}}\n  Verify via: {{verificationMethod}}\n  Evidence expected: {{evidenceExpected}}\n{{/each}}\n\nFor each criterion, provide **concrete evidence** of what you observed:\n- For UI changes: navigate to the affected page, describe what you see\n- For API changes: read the route handler and trace the logic, or call the endpoint if possible\n- For logic changes: trace the code path step by step and explain why it is correct or incorrect\n- For tests: run them if a test command is available, or verify test assertions manually\n{{/if}}\n\n{{/if}}\n\n{{#unless lightReview}}\n{{#if deliverables.length}}\n# Expected Deliverables\n{{#each deliverables}}\n- [ ] {{value}}\n{{/each}}\n{{/if}}\n\n{{#if executionContract}}\n# Execution Contract\nSummary: {{executionContract.summary}}\nCheckpoint policy: {{executionContract.checkpointPolicy}}\n{{#if executionContract.focusAreas.length}}\nFocus areas: {{executionContract.focusAreas | join ", "}}\n{{/if}}\n{{#if requiredChecks.length}}\nRequired checks:\n{{#each requiredChecks}}\n- {{value}}\n{{/each}}\n{{/if}}\n{{#if requiredEvidence.length}}\nRequired evidence:\n{{#each requiredEvidence}}\n- {{value}}\n{{/each}}\n{{/if}}\n{{/if}}\n{{/unless}}\n\n{{#if preReviewValidation}}\n# Pre-Review Validation Gate\n\nThe harness ran `{{preReviewValidation.command}}` immediately after execution completed.\n\n**Result: {{#if preReviewValidation.passed}}\u2713 PASS{{else}}\u2717 FAIL{{/if}}**\n\n```\n{{preReviewValidation.output}}\n```\n{{#unless preReviewValidation.passed}}\n> This indicates a test or build failure. Factor this into your verdict \u2014 it likely maps to one or more acceptance criteria above.\n{{/unless}}\n{{/if}}\n\n{{#if diffSummary}}\n# Changes Made (diff summary)\n```\n{{diffSummary}}\n```\n{{/if}}\n\n{{#if hasFrontendChanges}}\n# Browser Verification (Playwright MCP available)\n\nYou have access to browser automation tools via Playwright MCP. Use them to verify UI changes:\n1. Navigate to the running app: use `mcp__playwright__navigate` with `http://localhost:5173`\n2. Take a screenshot to confirm rendering: `mcp__playwright__screenshot`\n3. Click affected elements and verify interactions work correctly\n4. Check for JS errors: `mcp__playwright__evaluate` with `() => window.__playwright_errors ?? []`\n\nUse these tools for any criterion that involves visible UI output or user interactions.\n{{/if}}\n\n{{#unless lightReview}}\n# Structured Context\nIf `execution-payload.json` exists in the workspace, read it for the canonical structured task data.\nUse `acceptanceCriteria` and `executionContract` as the canonical evaluation checklist.\n{{/unless}}\n\n# Review Instructions\n\n{{#if lightReview}}\n1. Read the diff to understand what changed.\n2. Confirm the change matches the plan.\n3. Check for obvious regressions or mistakes.\n{{else}}\n1. Read the diff summary to understand what changed.\n2. Inspect the actual files in the workspace \u2014 do not trust the diff alone.\n3. Grade each acceptance criterion with concrete evidence.\n4. Check for correctness, security issues, and unintended regressions.\n5. Verify validation checks pass (run commands if specified in the plan).\n{{/if}}\n\n{{#if lightReview}}\n# Required Output Format\n\nAfter your review, emit a simple `grading_report` JSON block:\n\n```json grading_report\n{\n  "scope": "{{reviewScope}}",\n  "overallVerdict": "PASS",\n  "blockingVerdict": "PASS",\n  "criteria": [\n    {\n      "id": "AC-1",\n      "description": "...",\n      "category": "functionality",\n      "blocking": true,\n      "weight": 1,\n      "result": "PASS",\n      "evidence": "Brief confirmation"\n    }\n  ]\n}\n```\n\n- Keep evidence brief \u2014 one sentence per criterion is fine for low-complexity work.\n- If `blockingVerdict` is PASS: emit FIFONY_STATUS=done\n- If `blockingVerdict` is FAIL: emit FIFONY_STATUS=continue and provide actionable feedback in nextPrompt\n{{else}}\n{{#if acceptanceCriteria.length}}\n# Required Output Format\n\nAfter your analysis, you MUST end your response with a JSON block tagged `grading_report`. This block is machine-parsed \u2014 format it exactly as shown:\n\n```json grading_report\n{\n  "scope": "{{reviewScope}}",\n  "overallVerdict": "FAIL",\n  "blockingVerdict": "FAIL",\n  "criteria": [\n    {\n      "id": "AC-1",\n      "description": "...",\n      "category": "functionality",\n      "verificationMethod": "ui_walkthrough",\n      "evidenceExpected": "Expected concrete evidence",\n      "blocking": true,\n      "weight": 3,\n      "result": "FAIL",\n      "evidence": "I read src/foo.ts and verified that..."\n    }\n  ]\n}\n```\n\nRules:\n- `scope` must be `"{{reviewScope}}"`.\n- `overallVerdict` must be `"PASS"` or `"FAIL"`. If ANY criterion is `"FAIL"`, `overallVerdict` MUST be `"FAIL"`.\n- `blockingVerdict` must be `"PASS"` or `"FAIL"`. If ANY blocking criterion is `"FAIL"`, `blockingVerdict` MUST be `"FAIL"`.\n- `result` per criterion: `"PASS"`, `"FAIL"`, or `"SKIP"` (only if truly untestable).\n- `evidence` must describe what you actually observed, not what you expected to see.\n- Copy the criterion metadata exactly as defined above.\n- Do NOT invent criteria not in the list above.\n\nAfter outputting the `grading_report` block, also emit the appropriate status signal:\n- If `blockingVerdict` is PASS: emit FIFONY_STATUS=done\n- If `blockingVerdict` is FAIL: emit FIFONY_STATUS=continue and provide actionable feedback in nextPrompt\n{{else}}\nIf the work is acceptable, emit FIFONY_STATUS=done.\nIf rework is needed, emit FIFONY_STATUS=continue and provide actionable feedback in nextPrompt.\nIf the work is fundamentally broken, emit FIFONY_STATUS=blocked.\n{{/if}}\n{{/if}}\n',
+  "compile-review": 'Review the work done for {{issueIdentifier}}.\n\nTitle: {{title}}\nDescription: {{description}}\nWorkspace: {{workspacePath}}\n{{#if images.length}}\n\n## Visual Evidence (screenshots attached to this issue)\n{{#each images}}\n- {{this}}\n{{/each}}\nCompare the implementation against these screenshots if they show expected behavior or bugs.\n{{/if}}\n\n{{#if planPrompt}}\n# Original Execution Plan\n\n{{planPrompt}}\n{{/if}}\n\n{{#if lightReview}}\n# Your Role: Quick Sanity Check\n\nThis is a low-complexity task. Do a quick verification \u2014 don\'t over-analyze.\nCheck that the change matches what was requested and doesn\'t break anything obvious.\nKeep your review brief and focused.\n{{else}}\n# Your Role: Adversarial Quality Gate\n\nYou are NOT a collaborator \u2014 you are a skeptical evaluator. Your job is to find reasons to FAIL this work, not to be encouraging. Assume the implementation is incomplete until proven otherwise. The executor is incentivised to ship; you are incentivised to catch what they missed.\n\nVerification means PROVING the code works, not confirming it exists. A reviewer that rubber-stamps weak work undermines everything:\n- Run tests with the feature enabled \u2014 not just "tests pass".\n- Run typechecks and investigate errors \u2014 don\'t dismiss as "unrelated".\n- If something looks off, dig in. Read the actual file, trace the code path.\n- Test independently \u2014 prove the change works, don\'t trust the executor\'s claim.\n- Never claim a criterion PASS without concrete evidence of what you observed.\n{{/if}}\n\n# Review Scope\n\nCurrent review scope: **{{reviewScopeLabel}}** (`{{reviewScope}}`)\nGoal: {{reviewScopeGoal}}\nVerdict rule: {{reviewScopeVerdictRule}}\n{{#if reviewScopeInstructions.length}}\nScope instructions:\n{{#each reviewScopeInstructions}}\n- {{value}}\n{{/each}}\n{{/if}}\n\n{{#unless lightReview}}\n# Reviewer Routing\n\nProvider: {{reviewerProvider}}{{#if reviewerModel}} / {{reviewerModel}}{{/if}}{{#if reviewerEffort}} / effort {{reviewerEffort}}{{/if}}\n{{#if reviewerSelectionReason}}\nSelection reason: {{reviewerSelectionReason}}\n{{/if}}\n{{#if reviewerOverlays.length}}\nReviewer overlays:\n{{#each reviewerOverlays}}\n- {{value}}\n{{/each}}\n{{/if}}\n\n{{#if reviewProfile}}\n# Review Profile\n\nPrimary profile: **{{reviewProfile.primary}}**\nSeverity bias: {{reviewProfile.severityBias}}\n{{#if reviewProfileSecondary.length}}\nSecondary profiles:\n{{#each reviewProfileSecondary}}\n- {{value}}\n{{/each}}\n{{/if}}\n{{#if reviewProfileRationale.length}}\nWhy this profile was selected:\n{{#each reviewProfileRationale}}\n- {{value}}\n{{/each}}\n{{/if}}\nFocus areas:\n{{#each reviewProfileFocusAreas}}\n- {{value}}\n{{/each}}\nFailure modes to probe aggressively:\n{{#each reviewProfileFailureModes}}\n- {{value}}\n{{/each}}\nEvidence priorities:\n{{#each reviewProfileEvidencePriorities}}\n- {{value}}\n{{/each}}\n{{/if}}\n{{/unless}}\n\n{{#if acceptanceCriteria.length}}\n{{#if lightReview}}\n# Acceptance Criteria (quick check)\n\n{{#each acceptanceCriteria}}\n- **{{id}}**{{#if blocking}} blocking{{/if}}: {{description}}\n{{/each}}\n\nBriefly confirm each criterion is met. No need for exhaustive evidence on low-complexity work.\n{{else}}\n# Acceptance Criteria (grade EACH one)\n\nYou MUST evaluate every criterion below. Do not skip any.\n\n{{#each acceptanceCriteria}}\n- **{{id}}** [{{category}}]{{#if blocking}} blocking{{else}} advisory{{/if}}, weight {{weight}}: {{description}}\n  Verify via: {{verificationMethod}}\n  Evidence expected: {{evidenceExpected}}\n{{/each}}\n\nFor each criterion, provide **concrete evidence** of what you observed:\n- For UI changes: navigate to the affected page, describe what you see\n- For API changes: read the route handler and trace the logic, or call the endpoint if possible\n- For logic changes: trace the code path step by step and explain why it is correct or incorrect\n- For tests: run them if a test command is available, or verify test assertions manually\n{{/if}}\n\n{{/if}}\n\n{{#unless lightReview}}\n{{#if deliverables.length}}\n# Expected Deliverables\n{{#each deliverables}}\n- [ ] {{value}}\n{{/each}}\n{{/if}}\n\n{{#if executionContract}}\n# Execution Contract\nSummary: {{executionContract.summary}}\nCheckpoint policy: {{executionContract.checkpointPolicy}}\n{{#if executionContract.focusAreas.length}}\nFocus areas: {{executionContract.focusAreas | join ", "}}\n{{/if}}\n{{#if requiredChecks.length}}\nRequired checks:\n{{#each requiredChecks}}\n- {{value}}\n{{/each}}\n{{/if}}\n{{#if requiredEvidence.length}}\nRequired evidence:\n{{#each requiredEvidence}}\n- {{value}}\n{{/each}}\n{{/if}}\n{{/if}}\n{{/unless}}\n\n{{#if preReviewValidation}}\n# Pre-Review Validation Gate\n\nThe harness ran `{{preReviewValidation.command}}` immediately after execution completed.\n\n**Result: {{#if preReviewValidation.passed}}\u2713 PASS{{else}}\u2717 FAIL{{/if}}**\n\n```\n{{preReviewValidation.output}}\n```\n{{#unless preReviewValidation.passed}}\n> This indicates a test or build failure. Factor this into your verdict \u2014 it likely maps to one or more acceptance criteria above.\n{{/unless}}\n{{/if}}\n\n{{#if diffSummary}}\n# Changes Made (diff summary)\n```\n{{diffSummary}}\n```\n{{/if}}\n\n{{#unless lightReview}}\n# Structured Context\nIf `execution-payload.json` exists in the workspace, read it for the canonical structured task data.\nUse `acceptanceCriteria` and `executionContract` as the canonical evaluation checklist.\n{{/unless}}\n\n# Review Instructions\n\n{{#if lightReview}}\n1. Read the diff to understand what changed.\n2. Confirm the change matches the plan.\n3. Check for obvious regressions or mistakes.\n{{else}}\n1. Read the diff summary to understand what changed.\n2. Inspect the actual files in the workspace \u2014 do not trust the diff alone.\n3. Grade each acceptance criterion with concrete evidence.\n4. Check for correctness, security issues, and unintended regressions.\n5. Verify validation checks pass (run commands if specified in the plan).\n{{/if}}\n\n{{#if lightReview}}\n# Required Output Format\n\nAfter your review, emit a simple `grading_report` JSON block:\n\n```json grading_report\n{\n  "scope": "{{reviewScope}}",\n  "overallVerdict": "PASS",\n  "blockingVerdict": "PASS",\n  "criteria": [\n    {\n      "id": "AC-1",\n      "description": "...",\n      "category": "functionality",\n      "blocking": true,\n      "weight": 1,\n      "result": "PASS",\n      "evidence": "Brief confirmation"\n    }\n  ]\n}\n```\n\n- Keep evidence brief \u2014 one sentence per criterion is fine for low-complexity work.\n- If `blockingVerdict` is PASS: emit FIFONY_STATUS=done\n- If `blockingVerdict` is FAIL: emit FIFONY_STATUS=continue and provide actionable feedback in nextPrompt\n{{else}}\n{{#if acceptanceCriteria.length}}\n# Required Output Format\n\nAfter your analysis, you MUST end your response with a JSON block tagged `grading_report`. This block is machine-parsed \u2014 format it exactly as shown:\n\n```json grading_report\n{\n  "scope": "{{reviewScope}}",\n  "overallVerdict": "FAIL",\n  "blockingVerdict": "FAIL",\n  "criteria": [\n    {\n      "id": "AC-1",\n      "description": "...",\n      "category": "functionality",\n      "verificationMethod": "ui_walkthrough",\n      "evidenceExpected": "Expected concrete evidence",\n      "blocking": true,\n      "weight": 3,\n      "result": "FAIL",\n      "evidence": "I read src/foo.ts and verified that..."\n    }\n  ]\n}\n```\n\nRules:\n- `scope` must be `"{{reviewScope}}"`.\n- `overallVerdict` must be `"PASS"` or `"FAIL"`. If ANY criterion is `"FAIL"`, `overallVerdict` MUST be `"FAIL"`.\n- `blockingVerdict` must be `"PASS"` or `"FAIL"`. If ANY blocking criterion is `"FAIL"`, `blockingVerdict` MUST be `"FAIL"`.\n- `result` per criterion: `"PASS"`, `"FAIL"`, or `"SKIP"` (only if truly untestable).\n- `evidence` must describe what you actually observed, not what you expected to see.\n- Copy the criterion metadata exactly as defined above.\n- Do NOT invent criteria not in the list above.\n\nAfter outputting the `grading_report` block, also emit the appropriate status signal:\n- If `blockingVerdict` is PASS: emit FIFONY_STATUS=done\n- If `blockingVerdict` is FAIL: emit FIFONY_STATUS=continue and provide actionable feedback in nextPrompt\n{{else}}\nIf the work is acceptable, emit FIFONY_STATUS=done.\nIf rework is needed, emit FIFONY_STATUS=continue and provide actionable feedback in nextPrompt.\nIf the work is fundamentally broken, emit FIFONY_STATUS=blocked.\n{{/if}}\n{{/if}}\n',
   // src/agents/prompts/compile-review.stub.md
   "integrations-agency-agents": '---\nagent:\n  providers:\n    - provider: claude\n      role: planner\n      profile: agency-senior-project-manager\n    - provider: codex\n      role: executor\n      profile: agency-senior-developer\n    - provider: claude\n      role: reviewer\n      profile: agency-code-reviewer\ncodex:\n  command: "codex"\nclaude:\n  command: "claude"\n---\n\nUse local agency agent profiles discovered from workspace or home directories.\nWorkspace: {{workspaceRoot}}\n',
   // src/agents/prompts/integrations-agency-agents.stub.md
@@ -39,11 +134,11 @@ var PROMPT_TEMPLATES = {
   // src/agents/prompts/mcp-weekly-summary.stub.md
   "merge-conflict-resolver": 'You are resolving git merge conflicts in a software project.\n\n## Context\n\nIssue: {{issueIdentifier}} \u2014 {{title}}\n{{#if description}}\nDescription: {{description}}\n{{/if}}\nMerging branch `{{featureBranch}}` into `{{baseBranch}}`.\n\n## Conflicting Files\n\nThe following files have conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`) that you must resolve:\n\n{{#each conflictFiles}}\n- {{this}}\n{{/each}}\n\n## Instructions\n\n1. Read each conflicting file and understand the intent of BOTH sides.\n2. Resolve ALL conflict markers (`<<<<<<<`, `=======`, `>>>>>>>`) by choosing the correct combination of changes. Prefer keeping both sides\' intent when possible.\n3. CRITICAL: Before staging, run `grep -n "^<<<<<<<" <file>` on EACH file to verify zero conflict markers remain. If any markers remain, fix them first.\n4. After verifying each file is clean, stage with `git add <file>`.\n5. Do NOT commit \u2014 the merge commit will be created automatically after you finish.\n6. Do NOT modify files that are not in the conflict list.\n7. Do NOT use `git add .` or `git add -A` \u2014 stage only the conflicting files listed above.\n',
   // src/agents/prompts/merge-conflict-resolver.stub.md
-  "planning-issue-enhancer-description": 'You are helping improve issue metadata for a software execution queue.\nRewrite the description to be clearer, complete, and directly actionable.\n\nIssue type: {{issueType}}\nCurrent title: {{title}}\nCurrent description: {{description}}\n{{#if images}}\nVisual evidence (attached screenshots for context):\n{{#each images}}\n- {{this}}\n{{/each}}\n{{/if}}\n\nRules:\n- SIMPLICITY FIRST: describe the smallest change that solves the problem. Do NOT suggest refactoring, re-architecting, or expanding scope beyond what was asked.\n- Keep it short \u2014 3-8 lines max. No walls of text. No essays.\n- For "bug": what\'s broken, what\'s expected. That\'s it.\n- For "feature": what to add, where. No elaboration on alternatives or future work.\n- For "refactor": current state \u2192 desired state. Minimal scope.\n- For "docs": what to document.\n- For "chore": what to do and why.\n- Do NOT add acceptance criteria, test plans, or implementation details \u2014 the planner handles that.\n- Use bullet points. No ## headings unless truly needed.\n- The value should be in Portuguese if the input is in Portuguese; otherwise in English.\n\nAfter your analysis, return a single JSON code block as the LAST thing in your output:\n```json\n{ "field": "description", "value": "<REPLACE_WITH_ACTUAL_DESCRIPTION>" }\n```\n',
+  "planning-issue-enhancer-description": 'You are helping improve issue metadata for a software execution queue.\nRewrite the description to be clearer, complete, and directly actionable.\n\nIssue type: {{issueType}}\nCurrent title: {{title}}\nCurrent description: {{description}}\n{{#if images}}\nVisual evidence (attached screenshots for context):\n{{#each images}}\n- {{this}}\n{{/each}}\n{{/if}}\n\nRules:\n- SIMPLICITY FIRST: describe the smallest change that solves the problem. Do NOT suggest refactoring, re-architecting, or expanding scope beyond what was asked.\n- Keep it short \u2014 3-8 lines max. No walls of text. No essays. A 1-line input should produce a 2-4 line output, not a specification document.\n- For "bug": what\'s broken, what\'s expected. That\'s it.\n- For "feature": what to add, where. No elaboration on alternatives or future work.\n- For "refactor": current state \u2192 desired state. Minimal scope.\n- For "docs": what to document.\n- For "chore": what to do and why.\n- Do NOT add acceptance criteria, test plans, or implementation details \u2014 the planner handles that.\n- Do NOT inflate a simple request into a complex one. If the user said "fix the typo in header", the description is about fixing a typo \u2014 not about "comprehensive text review".\n- Use bullet points. No ## headings unless truly needed.\n- Match the language of the input.\n\nAfter your analysis, return a single JSON code block as the LAST thing in your output:\n```json\n{ "field": "description", "value": "<REPLACE_WITH_ACTUAL_DESCRIPTION>" }\n```\n',
   // src/agents/prompts/planning-issue-enhancer-description.stub.md
-  "planning-issue-enhancer-title": 'You are helping improve issue metadata for a software execution queue.\nRewrite the title for clarity, actionability, and specificity.\n\nIssue type: {{issueType}}\nCurrent title: {{title}}\nDescription context: {{description}}\n{{#if images}}\nVisual evidence (attached screenshots for context):\n{{#each images}}\n- {{this}}\n{{/each}}\n{{/if}}\n\nRules:\n- Keep it concise and suitable as a task title.\n- Use imperative language when possible.\n- If the issue type is "bug", start with "fix: ". If "feature", start with "feat: ". If "refactor", start with "refactor: ". If "docs", start with "docs: ". If "chore", start with "chore: ". For "blank", use no prefix.\n- Do not include markdown, quotes, or extra explanation.\n- The value should be in Portuguese if the input is in Portuguese; otherwise in English.\n\nReturn a single JSON code block as the LAST thing in your output:\n```json\n{ "field": "title", "value": "<REPLACE_WITH_ACTUAL_TITLE>" }\n```\n',
+  "planning-issue-enhancer-title": 'You are helping improve issue metadata for a software execution queue.\nRewrite the title for clarity, actionability, and specificity.\n\nIssue type: {{issueType}}\nCurrent title: {{title}}\nDescription context: {{description}}\n{{#if images}}\nVisual evidence (attached screenshots for context):\n{{#each images}}\n- {{this}}\n{{/each}}\n{{/if}}\n\nRules:\n- Keep it concise (< 72 characters) and suitable as a task title.\n- Use imperative language when possible.\n- If the issue type is "bug", start with "fix: ". If "feature", start with "feat: ". If "refactor", start with "refactor: ". If "docs", start with "docs: ". If "chore", start with "chore: ". For "blank", use no prefix.\n- Do NOT expand scope. If the user said "fix the button", don\'t rewrite it as "refactor the entire form component". Preserve the original intent and scope.\n- Do not include markdown, quotes, or extra explanation.\n- Match the language of the input.\n\nReturn a single JSON code block as the LAST thing in your output:\n```json\n{ "field": "title", "value": "<REPLACE_WITH_ACTUAL_TITLE>" }\n```\n',
   // src/agents/prompts/planning-issue-enhancer-title.stub.md
-  "planning-issue-planner": 'You are a senior technical execution planner.\nProduce the best possible plan for the issue below, filling the JSON schema precisely.\n{{#if fast}}\n\nFAST MODE: Be brief and direct. Minimize reasoning depth.\n- 2-4 steps maximum. Skip optional fields (unknowns, risks, alternatives).\n- Focus only on: summary, steps, estimatedComplexity, suggestedPaths.\n{{/if}}\n\n{{#if availableCapabilities}}\n## Installed Capabilities (recommend from these lists)\n\n{{#if availableSkills.length}}\n### Skills\n{{#each availableSkills}}\n- **{{name}}**{{#if description}} \u2014 {{description}}{{/if}}{{#if whenToUse}} (Use when: {{whenToUse}}){{/if}}\n{{/each}}\n{{/if}}\n{{#if availableAgents.length}}\n### Agents\n{{#each availableAgents}}\n- **{{name}}**{{#if description}} \u2014 {{description}}{{/if}}{{#if whenToUse}} (Use when: {{whenToUse}}){{/if}}{{#if avoidIf}} (Avoid if: {{avoidIf}}){{/if}}\n{{/each}}\n{{/if}}\n{{#if availableCommands.length}}\n### Commands\n{{#each availableCommands}}\n- /{{name}}\n{{/each}}\n{{/if}}\n\nRecommend skills and agents ONLY from these lists. Do not invent names.\nOnly recommend when there is a concrete benefit \u2014 not everything needs skills or agents.\n{{/if}}\n\nIssue title: {{title}}\nIssue description: {{description}}\n{{#if images}}\nVisual evidence (attached screenshots for context):\n{{#each images}}\n- {{this}}\n{{/each}}\n{{/if}}\n{{#if failureContext}}\n{{{failureContext}}}\n\n{{/if}}\n{{#unless fast}}\n\nCRITICAL \u2014 SIMPLICITY PRINCIPLE:\n- Plan the SMALLEST change that solves the issue. Nothing more.\n- Do NOT refactor surrounding code, add abstractions, or expand scope.\n- A bug fix = fix the bug. A feature = add that one feature. A chore = do the chore.\n- Prefer 1-3 steps. Only go up to 5-8 for genuinely complex work.\n- Default to `solo` or `standard` harnessMode. Only use `contractual` for truly high-risk work (security, data loss, FSM changes). A missing link, a config change, or a UI tweak is NEVER contractual.\n- If the fix is obvious (add a line, change a value, restore deleted code), say so directly. Don\'t dress it up with architectural analysis.\n\nQuality rules:\n- Be concrete, not generic. Each step describes WHAT to change and WHERE.\n- Each step must have a clear \'doneWhen\' \u2014 one sentence.\n- Keep `acceptanceCriteria` minimal: 1-3 criteria for trivial/low tasks, 3-5 for medium, up to 8 for high.\n- Keep `executionContract` proportional to complexity. A trivial fix needs a trivial contract.\n- Only list `unknowns` and `risks` that are REAL \u2014 not hypothetical. Empty arrays are fine.\n- Suggest file paths that are likely relevant to the changes.\n\nComplexity estimation (be honest \u2014 most issues are trivial or low):\n- trivial: < 5 min, single-file cosmetic change\n- low: 5-15 min, small focused change\n- medium: 15-60 min, multi-file change with testing\n- high: > 1 hour, architectural change or new feature\n\nEffort suggestion:\n- low: simple fixes, no deep reasoning needed\n- medium: standard development work\n- high: complex architecture, security, or cross-cutting changes\n{{/unless}}\n\n## Instructions\n\nYou are encouraged to explore the codebase \u2014 read files, search for patterns, inspect structure \u2014 to produce an informed plan. Use any tools available to you.\n\nAfter your analysis, you MUST output the final plan as a single JSON code block (```json ... ```).\nThe JSON block must be the LAST thing in your output. Any analysis or reasoning should come BEFORE it.\n\nIMPORTANT: Replace ALL placeholder values with real content specific to the issue above. Do NOT copy the example values literally \u2014 every field must contain actual plan content derived from the issue.\n\nUse these exact field names:\n\n```json\n{\n  "summary": "<YOUR one-line summary here>",\n  "estimatedComplexity": "trivial|low|medium|high",\n  "harnessMode": "solo|standard|contractual",\n  "steps": [\n    {\n      "step": 1,\n      "action": "<YOUR concrete action here>",\n      "files": ["<real/path/to/file.ts>"],\n      "details": "<YOUR additional context>",\n      "doneWhen": "<YOUR acceptance criterion>"\n    }\n  ],\n  "assumptions": ["<YOUR assumptions>"],\n  "constraints": ["<YOUR constraints>"],\n  "unknowns": [\n    { "question": "<YOUR question>", "whyItMatters": "<YOUR reason>", "howToResolve": "<YOUR approach>" }\n  ],\n  "acceptanceCriteria": [\n    {\n      "id": "AC-1",\n      "description": "<criterion>",\n      "category": "functionality|correctness|regression|design|code_quality|performance|security|validation|integration",\n      "verificationMethod": "<ui_walkthrough|api_probe|run_command|code_inspection|integration_check>",\n      "evidenceExpected": "<what concrete evidence the reviewer should gather>",\n      "blocking": true,\n      "weight": 3\n    }\n  ],\n  "executionContract": {\n    "summary": "<definition of done summary>",\n    "deliverables": ["<artifact or behavior required at the end>"],\n    "requiredChecks": ["<command or verification step>"],\n    "requiredEvidence": ["<evidence the reviewer must collect>"],\n    "focusAreas": ["<path or subsystem to scrutinize>"],\n    "checkpointPolicy": "final_only|checkpointed"\n  },\n  "risks": [\n    { "risk": "<YOUR risk>", "impact": "<YOUR impact>", "mitigation": "<YOUR mitigation>" }\n  ],\n  "suggestedPaths": ["<real/path/to/relevant/file.ts>"],\n  "suggestedSkills": ["<skill-name-from-list-above>"],\n  "suggestedAgents": ["<agent-name-from-list-above>"],\n  "suggestedEffort": { "default": "medium", "planner": "low", "executor": "medium", "reviewer": "medium" }\n}\n```\n',
+  "planning-issue-planner": 'You are a senior technical execution planner.\nProduce the best possible plan for the issue below, filling the JSON schema precisely.\n{{#if fast}}\n\nFAST MODE: Be brief and direct. Minimize reasoning depth.\n- 2-4 steps maximum. Skip optional fields (unknowns, risks, alternatives).\n- Focus only on: summary, steps, estimatedComplexity, suggestedPaths.\n{{/if}}\n\n{{#if availableCapabilities}}\n## Installed Capabilities (recommend from these lists)\n\n{{#if availableSkills.length}}\n### Skills\n{{#each availableSkills}}\n- **{{name}}**{{#if description}} \u2014 {{description}}{{/if}}{{#if whenToUse}} (Use when: {{whenToUse}}){{/if}}\n{{/each}}\n{{/if}}\n{{#if availableAgents.length}}\n### Agents\n{{#each availableAgents}}\n- **{{name}}**{{#if description}} \u2014 {{description}}{{/if}}{{#if whenToUse}} (Use when: {{whenToUse}}){{/if}}{{#if avoidIf}} (Avoid if: {{avoidIf}}){{/if}}\n{{/each}}\n{{/if}}\n{{#if availableCommands.length}}\n### Commands\n{{#each availableCommands}}\n- /{{name}}\n{{/each}}\n{{/if}}\n\nRecommend skills and agents ONLY from these lists. Do not invent names.\nOnly recommend when there is a concrete benefit \u2014 not everything needs skills or agents.\n{{/if}}\n\nIssue title: {{title}}\nIssue description: {{description}}\n{{#if images}}\nVisual evidence (attached screenshots for context):\n{{#each images}}\n- {{this}}\n{{/each}}\n{{/if}}\n{{#if failureContext}}\n{{{failureContext}}}\n\n{{/if}}\n{{#unless fast}}\n\nCRITICAL \u2014 SIMPLICITY PRINCIPLE:\n- Plan the SMALLEST change that solves the issue. Nothing more.\n- Do NOT refactor surrounding code, add abstractions, or expand scope.\n- A bug fix = fix the bug. A feature = add that one feature. A chore = do the chore.\n- Prefer 1-3 steps. Only go up to 5-8 for genuinely complex work.\n- Default to `solo` or `standard` harnessMode. Only use `contractual` for truly high-risk work (security, data loss, FSM changes). A missing link, a config change, or a UI tweak is NEVER contractual.\n- If the fix is obvious (add a line, change a value, restore deleted code), say so directly. Don\'t dress it up with architectural analysis.\n\nQuality rules:\n- Be concrete, not generic. Each step describes WHAT to change and WHERE.\n- Each step must have a clear \'doneWhen\' \u2014 one sentence.\n- Keep `acceptanceCriteria` minimal: 1-3 criteria for trivial/low tasks, 3-5 for medium, up to 8 for high.\n- Keep `executionContract` proportional to complexity. A trivial fix needs a trivial contract.\n- Only list `unknowns` and `risks` that are REAL \u2014 not hypothetical. Empty arrays are fine.\n- Suggest file paths that are likely relevant to the changes.\n\nComplexity estimation (be honest \u2014 most issues are trivial or low):\n- trivial: < 5 min, single-file cosmetic change\n- low: 5-15 min, small focused change\n- medium: 15-60 min, multi-file change with testing\n- high: > 1 hour, architectural change or new feature\n\nEffort suggestion:\n- low: simple fixes, no deep reasoning needed\n- medium: standard development work\n- high: complex architecture, security, or cross-cutting changes\n\nParallel execution (optional \u2014 only for medium/high complexity with 4+ steps):\n- If steps can be grouped into 2-3 independent sets that touch DIFFERENT files, add `parallelSubTasks` to the `executionContract`.\n- Each subtask is `{ "id": "sub-1", "label": "short description", "steps": [1, 2] }` where `steps` are indices into the plan steps array (0-based).\n- ONLY parallelize when subtasks have NO file overlap and NO shared state. Two steps editing the same file MUST be in the same subtask.\n- Don\'t force parallelism \u2014 serial is fine for most issues. Only parallelize when there\'s a genuine speedup opportunity.\n- Maximum 3 subtasks. Most issues need 0 (serial) or 2 subtasks.\n{{/unless}}\n\n## Instructions\n\nBEFORE planning, you MUST explore the codebase. Read the relevant files, search for patterns, understand the current code. Do NOT plan from assumptions \u2014 plan from evidence. A plan based on guesses about file structure or API shape will fail at execution time.\n\nExploration checklist:\n1. Find the files that will be changed \u2014 confirm they exist and understand their current state.\n2. Identify patterns and conventions in the codebase \u2014 your plan must follow them.\n3. Check for existing tests, build commands, or CI config that constrain the solution.\n4. If the issue references specific behavior, trace the code path to understand it.\n\nAnti-patterns in plans:\n- Don\'t plan architectural refactors when a targeted fix will do.\n- Don\'t suggest adding new abstractions, layers, or files unless the issue specifically requires them.\n- Don\'t include "nice to have" steps that aren\'t required to solve the issue.\n- Don\'t pad the plan with analysis steps \u2014 the plan should describe WHAT TO CHANGE, not how to investigate.\n\nAfter your analysis, you MUST output the final plan as a single JSON code block (```json ... ```).\nThe JSON block must be the LAST thing in your output. Any analysis or reasoning should come BEFORE it.\n\nIMPORTANT: Replace ALL placeholder values with real content specific to the issue above. Do NOT copy the example values literally \u2014 every field must contain actual plan content derived from the issue.\n\nUse these exact field names:\n\n```json\n{\n  "summary": "<YOUR one-line summary here>",\n  "estimatedComplexity": "trivial|low|medium|high",\n  "harnessMode": "solo|standard|contractual",\n  "steps": [\n    {\n      "step": 1,\n      "action": "<YOUR concrete action here>",\n      "files": ["<real/path/to/file.ts>"],\n      "details": "<YOUR additional context>",\n      "doneWhen": "<YOUR acceptance criterion>"\n    }\n  ],\n  "assumptions": ["<YOUR assumptions>"],\n  "constraints": ["<YOUR constraints>"],\n  "unknowns": [\n    { "question": "<YOUR question>", "whyItMatters": "<YOUR reason>", "howToResolve": "<YOUR approach>" }\n  ],\n  "acceptanceCriteria": [\n    {\n      "id": "AC-1",\n      "description": "<criterion>",\n      "category": "functionality|correctness|regression|design|code_quality|performance|security|validation|integration",\n      "verificationMethod": "<ui_walkthrough|api_probe|run_command|code_inspection|integration_check>",\n      "evidenceExpected": "<what concrete evidence the reviewer should gather>",\n      "blocking": true,\n      "weight": 3\n    }\n  ],\n  "executionContract": {\n    "summary": "<definition of done summary>",\n    "deliverables": ["<artifact or behavior required at the end>"],\n    "requiredChecks": ["<command or verification step>"],\n    "requiredEvidence": ["<evidence the reviewer must collect>"],\n    "focusAreas": ["<path or subsystem to scrutinize>"],\n    "checkpointPolicy": "final_only|checkpointed",\n    "parallelSubTasks": []\n  },\n  "risks": [\n    { "risk": "<YOUR risk>", "impact": "<YOUR impact>", "mitigation": "<YOUR mitigation>" }\n  ],\n  "suggestedPaths": ["<real/path/to/relevant/file.ts>"],\n  "suggestedSkills": ["<skill-name-from-list-above>"],\n  "suggestedAgents": ["<agent-name-from-list-above>"],\n  "suggestedEffort": { "default": "medium", "planner": "low", "executor": "medium", "reviewer": "medium" }\n}\n```\n',
   // src/agents/prompts/planning-issue-planner.stub.md
   "planning-issue-planner-refine": "You are a senior technical execution planner refining an existing plan based on user feedback.\n\n## Original Issue\nTitle: {{title}}\nDescription: {{description}}\n{{#if images}}\n\n## Visual Evidence\n{{#each images}}\n- {{this}}\n{{/each}}\n{{/if}}\n\n## Current Plan (JSON)\n```json\n{{currentPlan}}\n```\n\n## User Feedback\n{{feedback}}\n\n## Instructions\n\nRevise the plan above to address the user's feedback precisely.\n\nRules:\n- Keep all parts of the plan that are NOT affected by the feedback unchanged.\n- Only modify, add, or remove elements that the feedback specifically requests.\n- Preserve the same JSON schema structure as the current plan.\n- Maintain step numbering consistency after changes.\n- If feedback asks to add steps, insert them in the logical position and renumber.\n- If feedback asks to remove steps, renumber remaining steps sequentially.\n- Update the summary if the overall direction changed.\n- Re-evaluate estimatedComplexity if the scope changed significantly.\n- Update suggestedPaths, suggestedSkills, and suggestedAgents if affected by the changes.\n\nYou may explore the codebase to inform your revisions. After your analysis, return the revised plan as a single JSON code block (```json ... ```) as the LAST thing in your output.\n",
   // src/agents/prompts/planning-issue-planner-refine.stub.md
@@ -99,4 +194,4 @@ async function renderPromptString(template, context = {}) {
 export {
   renderPrompt
 };
-//# sourceMappingURL=chunk-AAZKYWOY.js.map
+//# sourceMappingURL=chunk-AFYKGVSP.js.map