fifony 0.1.43 → 0.1.47

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

@@ -13,7 +13,7 @@ var PROMPT_TEMPLATES = {
   // 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',
   // 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# 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\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# 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 acceptanceCriteria.length}}\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\n{{/if}}\n\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\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# 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\n# Review Instructions\n\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\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',
+  "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',
   // 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 +39,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- Keep it concise but include meaningful acceptance criteria tailored to the issue type.\n- For "bug": focus on problem description, expected behavior, and steps to reproduce.\n- For "feature": focus on goal, acceptance criteria, and any relevant notes.\n- For "refactor": describe current state, desired state, and scope.\n- For "docs": describe what to document and target audience.\n- For "chore": describe the task and why it\'s needed now.\n- Use markdown formatting appropriate for the type (## headings, bullet points).\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.\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',
   // 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',
   // 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\nQuality rules:\n- Be concrete, not generic. No vague phrases like \'implement\' or \'improve\' without detail.\n- Break work into actionable steps (2-8 steps). Each step describes WHAT, not HOW.\n- Each step must have a clear \'doneWhen\' acceptance criterion.\n- Choose a `harnessMode` deliberately:\n  `solo` for trivial, low-risk work;\n  `standard` for normal multi-file work;\n  `contractual` for high-risk, UI-critical, workflow/FSM, integration, or high-complexity work.\n- Produce structured `acceptanceCriteria`. Every criterion must include category, verificationMethod, evidenceExpected, blocking, and weight.\n- Produce an `executionContract` that fixes deliverables, required checks, required evidence, focus areas, and checkpoint policy before execution begins.\n- Identify assumptions, constraints, unknowns, and risks.\n- For unknowns, specify what question needs answering and how to resolve it.\n- Suggest file paths that are likely relevant to the changes.\n\nComplexity estimation:\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- Set per-role if different: planner, executor, reviewer\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{{/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',
   // 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 +99,4 @@ async function renderPromptString(template, context = {}) {
 export {
   renderPrompt
 };
-//# sourceMappingURL=chunk-ESWHDHH6.js.map
+//# sourceMappingURL=chunk-AAZKYWOY.js.map