fifony 0.1.42 → 0.1.43

package/dist/chunk-ESWHDHH6.js

@@ -0,0 +1,102 @@
+// src/agents/prompting.ts
+import { TemplateEngine } from "recker";
+
+// src/agents/generated/prompts.ts
+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',
+  // 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',
+  // 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',
+  // 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
+  "integrations-impeccable": '# Impeccable integration idea\n\nUse impeccable-oriented skills as a frontend review layer around fifony issues.\n\nSuggested pattern:\n\n1. Use `agency-senior-developer` or `codex` as executor.\n2. Route UI-heavy issues to a reviewer prompt that explicitly asks for impeccable-style critique.\n3. Expose the resulting review through the fifony MCP prompts or as a follow-up review issue.\n\nSuggested labels:\n- frontend\n- ui\n- design-system\n\nSuggested reviewer prompt seed:\n"Review this implementation using impeccable standards for frontend quality, polish, hierarchy, spacing, responsiveness, and interaction clarity."\n',
+  // src/agents/prompts/integrations-impeccable.stub.md
+  "mcp-code-review": "# Code Review for Issue {{issueId}}\n\n## Issue Context\n- **Title**: {{title}}\n- **Description**: {{description}}\n- **State**: {{state}}\n\n## Change Summary\n- **Files Changed**: {{filesChanged}}\n- **Total Additions**: +{{totalAdditions}}\n- **Total Deletions**: -{{totalDeletions}}\n\n### Files\n| Path | Status | Additions | Deletions |\n|------|--------|-----------|-----------|\n{{#each files}}\n| {{path}} | {{status}} | +{{additions}} | -{{deletions}} |\n{{/each}}\n\n## Diff\n```diff\n{{diff}}\n```\n\n## Review Checklist\nPlease review the changes and evaluate:\n1. **Correctness**: Do the changes correctly implement what the issue describes?\n2. **Code Quality**: Is the code clean, readable, and follows project conventions?\n3. **Error Handling**: Are edge cases and errors properly handled?\n4. **Security**: Are there any security concerns (hardcoded secrets, SQL injection, XSS)?\n5. **Performance**: Are there any performance concerns or inefficiencies?\n6. **Tests**: Are changes adequately covered by tests?\n7. **Breaking Changes**: Do any changes break backward compatibility?\n",
+  // src/agents/prompts/mcp-code-review.stub.md
+  "mcp-code-review-empty": "# Code Review for {{issueId}}\n\nNo code changes found for this issue. The workspace may not have been created yet or no modifications were made.\n",
+  // src/agents/prompts/mcp-code-review-empty.stub.md
+  "mcp-diagnose-blocked": '# Diagnostic Report for Issue {{issueId}}\n\n## Issue Details\n- **Title**: {{title}}\n- **State**: {{state}}\n- **Attempts**: {{attempts}} / {{maxAttempts}}\n- **Last Error**: {{lastError}}\n- **Updated At**: {{updatedAt}}\n\n## Plan\n{{#if hasPlan}}\n- **Summary**: {{planSummary}}\n{{#if hasPlanSteps}}\n- **Steps**: {{planStepsCount}} step(s)\n{{/if}}\n{{#if planComplexity}}\n- **Estimated Complexity**: {{planComplexity}}\n{{/if}}\n{{else}}\nNo plan generated.\n{{/if}}\n\n## History\n{{#if history.length}}\n{{#each history}}\n- {{this}}\n{{/each}}\n{{else}}\nNo history entries.\n{{/if}}\n\n## Recent Events\n{{#if recentEvents.length}}\n{{#each recentEvents}}\n- [{{kind}}] {{at}}: {{message}}\n{{/each}}\n{{else}}\nNo events found.\n{{/if}}\n\n## Diagnostic Questions\nBased on the information above, please analyze:\n1. What is the root cause of the issue being in "{{state}}" state?\n2. Is the error recoverable? If so, what steps should be taken?\n3. Does the plan need modification before retrying?\n4. Are there any dependency or configuration issues that need resolution?\n5. What is the recommended next action?\n',
+  // src/agents/prompts/mcp-diagnose-blocked.stub.md
+  "mcp-integrate-client": "Integrate {{client}} with the local fifony MCP server.\n\nGoal: {{goal}}\n\n{{integrationGuide}}\n\nUse the available fifony resources and tools instead of inventing your own persistence model.\n",
+  // src/agents/prompts/mcp-integrate-client.stub.md
+  "mcp-integration-guide": '# fifony MCP integration\n\nWorkspace root: `{{workspaceRoot}}`\nPersistence root: `{{persistenceRoot}}`\nState root: `{{stateRoot}}`\n\nRecommended MCP client command:\n\n```json\n{\n  "mcpServers": {\n    "fifony": {\n      "command": "npx",\n      "args": ["fifony", "mcp", "--workspace", "{{workspaceRoot}}", "--persistence", "{{persistenceRoot}}"]\n    }\n  }\n}\n```\n\nExpected workflow:\n\n1. Read `fifony://guide/overview` and `fifony://state/summary`.\n2. Use `fifony.list_issues` or read `fifony://issues`.\n3. Create work with `fifony.create_issue`.\n4. Update workflow state with `fifony.update_issue_state`.\n5. Use the prompts exposed by this MCP server to structure planning or execution.\n\nThe MCP server is read-write against the same `s3db` filesystem store used by the fifony runtime.\n',
+  // src/agents/prompts/mcp-integration-guide.stub.md
+  "mcp-issue": 'You are integrating with fifony as the {{role}} using {{provider}}.\n\nIssue ID: {{id}}\nTitle: {{title}}\nState: {{state}}\n{{#if paths.length}}\nPaths: {{paths | join ", "}}\n{{/if}}\nDescription:\n{{description}}\n\nUse fifony as the source of truth:\n- Persist transitions through the fifony tools instead of inventing local state.\n- Keep outputs actionable and aligned with the tracked issue lifecycle.\n',
+  // src/agents/prompts/mcp-issue.stub.md
+  "mcp-refine-plan": "# Plan Refinement for Issue {{issueId}}\n\n## Issue\n- **Title**: {{title}}\n- **Description**: {{description}}\n\n## Current Plan\n{{#if hasPlan}}\n- **Summary**: {{planSummary}}\n{{#if planComplexity}}\n- **Complexity**: {{planComplexity}}\n{{/if}}\n{{else}}\nNo plan exists yet.\n{{/if}}\n\n### Steps\n{{#if steps.length}}\n{{#each steps}}\n{{index}}. **{{title}}**\n   {{description}}\n{{/each}}\n{{else}}\nNo steps defined.\n{{/if}}\n\n{{#if concern}}\n## Specific Concern\n{{concern}}\n{{/if}}\n\n## Refinement Guidance\nPlease review the current plan and provide specific, actionable feedback:\n1. Are the steps correctly ordered and complete?\n2. Are there missing edge cases or error handling steps?\n3. Is the complexity estimate accurate?\n4. Are the file paths and affected areas correct?\n5. Should any steps be split, merged, or removed?\n\nProvide your feedback, and it will be used to refine the plan via `fifony.refine`.\n",
+  // src/agents/prompts/mcp-refine-plan.stub.md
+  "mcp-review-workflow": "Review the pipeline configuration for this fifony workspace as {{provider}}.\n\nWorkspace: {{workspaceRoot}}\n\nFocus on:\n- provider orchestration quality (plan/execute/review stages)\n- hooks safety (beforeRun, afterRun, afterCreate, beforeRemove)\n- prompt clarity\n- issue lifecycle correctness\n- what an MCP client needs in order to integrate cleanly\n",
+  // src/agents/prompts/mcp-review-workflow.stub.md
+  "mcp-weekly-summary": "# Fifony Weekly Progress Summary\n\n## Issue Statistics\n| Status | Count |\n|--------|-------|\n| Total Issues | {{totalIssues}} |\n| Completed (Done) | {{completed}} |\n| In Progress | {{inProgress}} |\n| Planned | {{planned}} |\n| Planning | {{planning}} |\n| Blocked/Failed | {{blocked}} |\n| Cancelled | {{cancelled}} |\n\n## Token Usage\n- **Total Tokens**: {{totalTokensFormatted}}\n- **Input Tokens**: {{inputTokensFormatted}}\n- **Output Tokens**: {{outputTokensFormatted}}\n- **Estimated Cost**: ${{estimatedCostFormatted}}\n\n## Analysis Request\nBased on these metrics, please provide:\n1. A brief summary of overall progress this week\n2. Identification of any bottlenecks (blocked/failed issues)\n3. Token usage efficiency assessment\n4. Recommendations for improving throughput\n5. Priority items for next week\n",
+  // 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',
+  // 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',
+  // 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
+  "project-analysis": `You are analyzing a software project to help configure an AI-powered development assistant.
+
+Look at the project structure, source code, configuration files, and any documentation you can find. Pay special attention to:
+- README, CLAUDE.md, AGENTS.md, or any project documentation
+- Build files: package.json, Cargo.toml, pyproject.toml, build.gradle, Gemfile, go.mod, Makefile, CMakeLists.txt, pom.xml, etc.
+- Source code directories and their contents
+- Configuration files (.env, docker-compose, terraform, etc.)
+- CI/CD pipelines (.github/workflows, .gitlab-ci, Jenkinsfile, etc.)
+
+Return a JSON object with exactly these fields:
+
+{
+  "description": "A concise 2-3 sentence description of what this project does, its purpose, and who it's for.",
+  "language": "The primary programming language (e.g. typescript, python, rust, java, kotlin, ruby, go, swift, c++)",
+  "domains": ["Array of relevant domain tags that apply to this project"],
+  "stack": ["Array of key technologies, frameworks, and tools used"],
+  "suggestedAgents": ["Array of specialist agent names that would help develop this project"]
+}
+
+For "domains", choose from: frontend, backend, mobile, devops, database, ai-ml, security, testing, games, ecommerce, fintech, healthcare, education, saas, design, product, marketing, embedded, blockchain, spatial-computing, data-engineering.
+
+For "suggestedAgents", choose from: frontend-developer, backend-architect, database-optimizer, security-engineer, devops-automator, mobile-app-builder, ai-engineer, ui-designer, ux-architect, code-reviewer, technical-writer, sre, data-engineer, software-architect, game-designer.
+
+Return ONLY the JSON object. No markdown fences, no explanation, no extra text.
+`,
+  // src/agents/prompts/project-analysis.stub.md
+  "workflow-default": "You are working on {{issue.identifier}}.\n\nTitle: {{issue.title}}\nDescription:\n{{issue.description}}\n",
+  // src/agents/prompts/workflow-default.stub.md
+  "workflow-plan-section": '## Execution Plan\n\nComplexity: {{estimatedComplexity}}\nSummary: {{summary}}\n\nSteps:\n{{#each steps}}\n{{step}}. {{action}}{{#if files.length}} (files: {{files | join ", "}}){{/if}}{{#if details}} - {{details}}{{/if}}\n{{/each}}\n\nFollow this plan. Complete each step in order.\n'
+  // src/agents/prompts/workflow-plan-section.stub.md
+};
+
+// src/agents/prompting.ts
+var engine = new TemplateEngine({
+  cache: true,
+  format: "raw",
+  strict: false
+});
+function normalizePrompt(text) {
+  return text.replace(/\r\n/g, "\n").replace(/\n{3,}/g, "\n\n").trim();
+}
+async function renderPrompt(name, context = {}) {
+  return renderPromptString(PROMPT_TEMPLATES[name], context);
+}
+async function renderPromptString(template, context = {}) {
+  const rendered = await engine.render(template, context);
+  return normalizePrompt(rendered);
+}
+
+export {
+  renderPrompt
+};
+//# sourceMappingURL=chunk-ESWHDHH6.js.map