@wizdear/atlas-code 0.2.4 → 0.2.6

package/dist/planner.js

@@ -1,6 +1,6 @@
 import { createRoleAgent, runAgent } from "./agent-factory.js";
 import { getSystemPromptForRole } from "./roles/index.js";
-import { extractArtifactContent } from "./step-executor.js";
+import { aggregateUsage, extractArtifactContent } from "./step-executor.js";
 // ─── Planner Runner ──────────────────────────────────────────────────────────
 /**
  * Runs the Planner Agent to generate plan.json and spec.md for each feature
@@ -27,8 +27,12 @@ export async function runPlanner(options) {
     if (await store.hasGlobalArtifact("impact-report.md")) {
         impactReport = await store.readGlobalArtifact("impact-report.md");
     }
+    let systemDesign;
+    if (await store.hasSystemDesign()) {
+        systemDesign = await store.readSystemDesign();
+    }
     // 2. Combine context
-    const featureContext = buildPlannerContext(requirements, projectContext, impactReport);
+    const featureContext = buildPlannerContext(requirements, impactReport, systemDesign);
     // 3. Create Agent
     const systemPrompt = getSystemPromptForRole("planner");
     const agent = await createRoleAgent({
@@ -39,7 +43,6 @@ export async function runPlanner(options) {
         model,
         featureContext: featureContext || undefined,
         getApiKey,
-        availableSkills: options.availableSkills,
     });
     // Notify external code that the agent has been created (for abort wiring)
     options.onAgentCreated?.(agent);
@@ -56,18 +59,19 @@ export async function runPlanner(options) {
             prompt = buildPlannerPrompt(requirements, projectContext, impactReport);
         }
         const response = await runAgent(agent, prompt, onAgentEvent ? { onEvent: onAgentEvent } : undefined);
+        const usage = aggregateUsage(agent.state.messages);
         onMessage?.(response);
         // 5. Extract and save plan.json
         const planContent = extractArtifactContent(response, "plan.json", false);
         if (!planContent) {
-            return { completed: false, featureCount: 0 };
+            return { completed: false, featureCount: 0, usage };
         }
         let plan;
         try {
             plan = JSON.parse(planContent);
         }
         catch {
-            return { completed: false, featureCount: 0 };
+            return { completed: false, featureCount: 0, usage };
         }
         await store.savePlan(plan);
         // 6. Extract and save each feature's spec.md
@@ -77,7 +81,7 @@ export async function runPlanner(options) {
                 await store.writeArtifact(feature.featureId, "spec.md", specContent);
             }
         }
-        return { completed: true, featureCount: plan.features.length };
+        return { completed: true, featureCount: plan.features.length, usage };
     }
     catch (error) {
         // Interruption by agent.abort(): "Request was aborted" error
@@ -92,20 +96,20 @@ export async function runPlanner(options) {
     }
 }
 // ─── Context & Prompt Builders ───────────────────────────────────────────────
-function buildPlannerContext(requirements, projectContext, impactReport) {
+function buildPlannerContext(requirements, impactReport, systemDesign) {
     const parts = [];
     if (requirements) {
         parts.push("## Requirements\n");
         parts.push(requirements);
     }
-    if (projectContext) {
-        parts.push("## Project Context\n");
-        parts.push(projectContext);
-    }
     if (impactReport) {
         parts.push("## Impact Report\n");
         parts.push(impactReport);
     }
+    if (systemDesign) {
+        parts.push("## System Architecture\n");
+        parts.push(systemDesign);
+    }
     return parts.join("\n\n");
 }
 function buildPlannerPrompt(requirements, projectContext, impactReport) {

package/dist/planner.js.map

@@ -1 +1 @@
-{"version":3,"file":"planner.js","sourceRoot":"","sources":["../src/planner.ts"],"names":[],"mappings":"AAGA,OAAO,EAAE,eAAe,EAAE,QAAQ,EAAE,MAAM,oBAAoB,CAAC;AAC/D,OAAO,EAAE,sBAAsB,EAAE,MAAM,kBAAkB,CAAC;AAC1D,OAAO,EAAE,sBAAsB,EAAE,MAAM,oBAAoB,CAAC;AAoC5D,0MAAgF;AAEhF;;;;;;;;;GASG;AACH,MAAM,CAAC,KAAK,UAAU,UAAU,CAAC,OAAuB,EAA0B;IACjF,MAAM,EAAE,KAAK,EAAE,MAAM,EAAE,WAAW,EAAE,SAAS,EAAE,KAAK,EAAE,YAAY,EAAE,SAAS,EAAE,QAAQ,EAAE,GAAG,OAAO,CAAC;IAEpG,iBAAiB;IACjB,IAAI,YAAgC,CAAC;IACrC,IAAI,MAAM,KAAK,CAAC,eAAe,EAAE,EAAE,CAAC;QACnC,YAAY,GAAG,MAAM,KAAK,CAAC,gBAAgB,EAAE,CAAC;IAC/C,CAAC;IAED,IAAI,cAAkC,CAAC;IACvC,IAAI,MAAM,KAAK,CAAC,iBAAiB,EAAE,EAAE,CAAC;QACrC,cAAc,GAAG,MAAM,KAAK,CAAC,kBAAkB,EAAE,CAAC;IACnD,CAAC;IAED,IAAI,YAAgC,CAAC;IACrC,IAAI,MAAM,KAAK,CAAC,iBAAiB,CAAC,kBAAkB,CAAC,EAAE,CAAC;QACvD,YAAY,GAAG,MAAM,KAAK,CAAC,kBAAkB,CAAC,kBAAkB,CAAC,CAAC;IACnE,CAAC;IAED,qBAAqB;IACrB,MAAM,cAAc,GAAG,mBAAmB,CAAC,YAAY,EAAE,cAAc,EAAE,YAAY,CAAC,CAAC;IAEvF,kBAAkB;IAClB,MAAM,YAAY,GAAG,sBAAsB,CAAC,SAAS,CAAC,CAAC;IACvD,MAAM,KAAK,GAAG,MAAM,eAAe,CAAC;QACnC,IAAI,EAAE,SAAS;QACf,YAAY;QACZ,MAAM;QACN,WAAW;QACX,KAAK;QACL,cAAc,EAAE,cAAc,IAAI,SAAS;QAC3C,SAAS;QACT,eAAe,EAAE,OAAO,CAAC,eAAe;KACxC,CAAC,CAAC;IAEH,0EAA0E;IAC1E,OAAO,CAAC,cAAc,EAAE,CAAC,KAAK,CAAC,CAAC;IAEhC,8BAA8B;IAC9B,IAAI,CAAC;QACJ,IAAI,MAAc,CAAC;QACnB,IAAI,QAAQ,EAAE,CAAC;YACd,MAAM;gBACL,kEAAkE,QAAQ,MAAM;oBAChF,oDAAoD;oBACpD,kBAAkB,CAAC,YAAY,EAAE,cAAc,EAAE,YAAY,CAAC,CAAC;QACjE,CAAC;aAAM,CAAC;YACP,MAAM,GAAG,kBAAkB,CAAC,YAAY,EAAE,cAAc,EAAE,YAAY,CAAC,CAAC;QACzE,CAAC;QACD,MAAM,QAAQ,GAAG,MAAM,QAAQ,CAAC,KAAK,EAAE,MAAM,EAAE,YAAY,CAAC,CAAC,CAAC,EAAE,OAAO,EAAE,YAAY,EAAE,CAAC,CAAC,CAAC,SAAS,CAAC,CAAC;QACrG,SAAS,EAAE,CAAC,QAAQ,CAAC,CAAC;QAEtB,gCAAgC;QAChC,MAAM,WAAW,GAAG,sBAAsB,CAAC,QAAQ,EAAE,WAAW,EAAE,KAAK,CAAC,CAAC;QACzE,IAAI,CAAC,WAAW,EAAE,CAAC;YAClB,OAAO,EAAE,SAAS,EAAE,KAAK,EAAE,YAAY,EAAE,CAAC,EAAE,CAAC;QAC9C,CAAC;QAED,IAAI,IAAc,CAAC;QACnB,IAAI,CAAC;YACJ,IAAI,GAAG,IAAI,CAAC,KAAK,CAAC,WAAW,CAAa,CAAC;QAC5C,CAAC;QAAC,MAAM,CAAC;YACR,OAAO,EAAE,SAAS,EAAE,KAAK,EAAE,YAAY,EAAE,CAAC,EAAE,CAAC;QAC9C,CAAC;QAED,MAAM,KAAK,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC;QAE3B,6CAA6C;QAC7C,KAAK,MAAM,OAAO,IAAI,IAAI,CAAC,QAAQ,EAAE,CAAC;YACrC,MAAM,WAAW,GAAG,sBAAsB,CAAC,QAAQ,EAAE,GAAG,OAAO,CAAC,SAAS,UAAU,EAAE,KAAK,CAAC,CAAC;YAC5F,IAAI,WAAW,EAAE,CAAC;gBACjB,MAAM,KAAK,CAAC,aAAa,CAAC,OAAO,CAAC,SAAS,EAAE,SAAS,EAAE,WAAW,CAAC,CAAC;YACtE,CAAC;QACF,CAAC;QAED,OAAO,EAAE,SAAS,EAAE,IAAI,EAAE,YAAY,EAAE,IAAI,CAAC,QAAQ,CAAC,MAAM,EAAE,CAAC;IAChE,CAAC;IAAC,OAAO,KAAK,EAAE,CAAC;QAChB,6DAA6D;QAC7D,MAAM,GAAG,GAAG,KAAK,YAAY,KAAK,CAAC,CAAC,CAAC,KAAK,CAAC,OAAO,CAAC,CAAC,CAAC,MAAM,CAAC,KAAK,CAAC,CAAC;QACnE,IAAI,GAAG,CAAC,QAAQ,CAAC,SAAS,CAAC,EAAE,CAAC;YAC7B,OAAO,EAAE,SAAS,EAAE,KAAK,EAAE,YAAY,EAAE,CAAC,EAAE,CAAC;QAC9C,CAAC;QACD,MAAM,KAAK,CAAC;IACb,CAAC;YAAS,CAAC;QACV,OAAO,CAAC,eAAe,EAAE,EAAE,CAAC;IAC7B,CAAC;AAAA,CACD;AAED,oLAAgF;AAEhF,SAAS,mBAAmB,CAAC,YAAqB,EAAE,cAAuB,EAAE,YAAqB,EAAU;IAC3G,MAAM,KAAK,GAAa,EAAE,CAAC;IAE3B,IAAI,YAAY,EAAE,CAAC;QAClB,KAAK,CAAC,IAAI,CAAC,mBAAmB,CAAC,CAAC;QAChC,KAAK,CAAC,IAAI,CAAC,YAAY,CAAC,CAAC;IAC1B,CAAC;IAED,IAAI,cAAc,EAAE,CAAC;QACpB,KAAK,CAAC,IAAI,CAAC,sBAAsB,CAAC,CAAC;QACnC,KAAK,CAAC,IAAI,CAAC,cAAc,CAAC,CAAC;IAC5B,CAAC;IAED,IAAI,YAAY,EAAE,CAAC;QAClB,KAAK,CAAC,IAAI,CAAC,oBAAoB,CAAC,CAAC;QACjC,KAAK,CAAC,IAAI,CAAC,YAAY,CAAC,CAAC;IAC1B,CAAC;IAED,OAAO,KAAK,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC;AAAA,CAC1B;AAED,SAAS,kBAAkB,CAAC,YAAqB,EAAE,cAAuB,EAAE,YAAqB,EAAU;IAC1G,MAAM,KAAK,GAAa,EAAE,CAAC;IAE3B,KAAK,CAAC,IAAI,CAAC,4EAA4E,CAAC,CAAC;IACzF,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;IAEf,IAAI,YAAY,EAAE,CAAC;QAClB,KAAK,CAAC,IAAI,CAAC,0BAA0B,CAAC,CAAC;QACvC,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;QACf,KAAK,CAAC,IAAI,CAAC,YAAY,CAAC,CAAC;QACzB,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;IAChB,CAAC;SAAM,CAAC;QACP,KAAK,CAAC,IAAI,CAAC,sFAAsF,CAAC,CAAC;QACnG,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;IAChB,CAAC;IAED,IAAI,cAAc,EAAE,CAAC;QACpB,KAAK,CAAC,IAAI,CAAC,oBAAoB,CAAC,CAAC;QACjC,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;QACf,KAAK,CAAC,IAAI,CAAC,cAAc,CAAC,CAAC;QAC3B,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;IAChB,CAAC;IAED,IAAI,YAAY,EAAE,CAAC;QAClB,KAAK,CAAC,IAAI,CAAC,kBAAkB,CAAC,CAAC;QAC/B,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;QACf,KAAK,CAAC,IAAI,CACT,yJAAyJ,CACzJ,CAAC;QACF,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;QACf,KAAK,CAAC,IAAI,CAAC,YAAY,CAAC,CAAC;QACzB,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;IAChB,CAAC;IAED,KAAK,CAAC,IAAI,CAAC,iBAAiB,CAAC,CAAC;IAC9B,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;IACf,KAAK,CAAC,IAAI,CAAC,mEAAmE,CAAC,CAAC;IAChF,KAAK,CAAC,IAAI,CAAC,sEAAsE,CAAC,CAAC;IACnF,KAAK,CAAC,IAAI,CAAC,2DAA2D,CAAC,CAAC;IACxE,KAAK,CAAC,IAAI,CAAC,6DAA6D,CAAC,CAAC;IAC1E,KAAK,CAAC,IAAI,CAAC,kDAAkD,CAAC,CAAC;IAC/D,KAAK,CAAC,IAAI,CAAC,yEAAyE,CAAC,CAAC;IAEtF,OAAO,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAAA,CACxB","sourcesContent":["import type { Agent, AgentEvent } from \"@mariozechner/pi-agent-core\";\nimport type { Model } from \"@mariozechner/pi-ai\";\nimport type { GetApiKeyFn } from \"./agent-factory.js\";\nimport { createRoleAgent, runAgent } from \"./agent-factory.js\";\nimport { getSystemPromptForRole } from \"./roles/index.js\";\nimport { extractArtifactContent } from \"./step-executor.js\";\nimport type { VibeStore } from \"./store.js\";\nimport type { PlanData, VibeConfig } from \"./types.js\";\n\n// ─── Types ───────────────────────────────────────────────────────────────────\n\n/** Planner execution options */\nexport interface PlannerOptions {\n\tstore: VibeStore;\n\tconfig: VibeConfig;\n\tprojectRoot: string;\n\tgetApiKey?: GetApiKeyFn;\n\t/** Model to use. Uses the Agent's default model if not specified. */\n\tmodel?: Model<any>;\n\t/** Agent event callback. Used for progress display, etc. */\n\tonAgentEvent?: (event: AgentEvent) => void;\n\t/** Callback to relay agent messages externally */\n\tonMessage?: (message: string) => void;\n\t/** User feedback on rejection. Regenerates the existing plan with feedback applied. */\n\tfeedback?: string;\n\t/** Lightweight skill index. Included in the agent system prompt. */\n\tavailableSkills?: string;\n\t/** Callback invoked when the agent is created. Used for abort wiring, etc. */\n\tonAgentCreated?: (agent: Agent) => void;\n\t/** Callback invoked when the agent finishes execution. */\n\tonAgentFinished?: () => void;\n}\n\n/** Planner execution result */\nexport interface PlannerResult {\n\t/** Whether plan.json was generated */\n\tcompleted: boolean;\n\t/** Number of decomposed features */\n\tfeatureCount: number;\n}\n\n// ─── Planner Runner ──────────────────────────────────────────────────────────\n\n/**\n * Runs the Planner Agent to generate plan.json and spec.md for each feature\n * based on requirements.md and project-context.md.\n *\n * 1. Load requirements.md and project-context.md from the store\n * 2. Create Planner Agent (readonly — extracts artifacts from response)\n * 3. Run the agent\n * 4. Extract plan.json from the response → save to store\n * 5. Extract each feature's spec.md → save to store\n */\nexport async function runPlanner(options: PlannerOptions): Promise<PlannerResult> {\n\tconst { store, config, projectRoot, getApiKey, model, onAgentEvent, onMessage, feedback } = options;\n\n\t// 1. Load inputs\n\tlet requirements: string | undefined;\n\tif (await store.hasRequirements()) {\n\t\trequirements = await store.readRequirements();\n\t}\n\n\tlet projectContext: string | undefined;\n\tif (await store.hasProjectContext()) {\n\t\tprojectContext = await store.readProjectContext();\n\t}\n\n\tlet impactReport: string | undefined;\n\tif (await store.hasGlobalArtifact(\"impact-report.md\")) {\n\t\timpactReport = await store.readGlobalArtifact(\"impact-report.md\");\n\t}\n\n\t// 2. Combine context\n\tconst featureContext = buildPlannerContext(requirements, projectContext, impactReport);\n\n\t// 3. Create Agent\n\tconst systemPrompt = getSystemPromptForRole(\"planner\");\n\tconst agent = await createRoleAgent({\n\t\trole: \"planner\",\n\t\tsystemPrompt,\n\t\tconfig,\n\t\tprojectRoot,\n\t\tmodel,\n\t\tfeatureContext: featureContext || undefined,\n\t\tgetApiKey,\n\t\tavailableSkills: options.availableSkills,\n\t});\n\n\t// Notify external code that the agent has been created (for abort wiring)\n\toptions.onAgentCreated?.(agent);\n\n\t// 4. Build prompt and execute\n\ttry {\n\t\tlet prompt: string;\n\t\tif (feedback) {\n\t\t\tprompt =\n\t\t\t\t`The previous plan was rejected with the following feedback:\\n\\n${feedback}\\n\\n` +\n\t\t\t\t\"Please revise the plan based on this feedback.\\n\\n\" +\n\t\t\t\tbuildPlannerPrompt(requirements, projectContext, impactReport);\n\t\t} else {\n\t\t\tprompt = buildPlannerPrompt(requirements, projectContext, impactReport);\n\t\t}\n\t\tconst response = await runAgent(agent, prompt, onAgentEvent ? { onEvent: onAgentEvent } : undefined);\n\t\tonMessage?.(response);\n\n\t\t// 5. Extract and save plan.json\n\t\tconst planContent = extractArtifactContent(response, \"plan.json\", false);\n\t\tif (!planContent) {\n\t\t\treturn { completed: false, featureCount: 0 };\n\t\t}\n\n\t\tlet plan: PlanData;\n\t\ttry {\n\t\t\tplan = JSON.parse(planContent) as PlanData;\n\t\t} catch {\n\t\t\treturn { completed: false, featureCount: 0 };\n\t\t}\n\n\t\tawait store.savePlan(plan);\n\n\t\t// 6. Extract and save each feature's spec.md\n\t\tfor (const feature of plan.features) {\n\t\t\tconst specContent = extractArtifactContent(response, `${feature.featureId}/spec.md`, false);\n\t\t\tif (specContent) {\n\t\t\t\tawait store.writeArtifact(feature.featureId, \"spec.md\", specContent);\n\t\t\t}\n\t\t}\n\n\t\treturn { completed: true, featureCount: plan.features.length };\n\t} catch (error) {\n\t\t// Interruption by agent.abort(): \"Request was aborted\" error\n\t\tconst msg = error instanceof Error ? error.message : String(error);\n\t\tif (msg.includes(\"aborted\")) {\n\t\t\treturn { completed: false, featureCount: 0 };\n\t\t}\n\t\tthrow error;\n\t} finally {\n\t\toptions.onAgentFinished?.();\n\t}\n}\n\n// ─── Context & Prompt Builders ───────────────────────────────────────────────\n\nfunction buildPlannerContext(requirements?: string, projectContext?: string, impactReport?: string): string {\n\tconst parts: string[] = [];\n\n\tif (requirements) {\n\t\tparts.push(\"## Requirements\\n\");\n\t\tparts.push(requirements);\n\t}\n\n\tif (projectContext) {\n\t\tparts.push(\"## Project Context\\n\");\n\t\tparts.push(projectContext);\n\t}\n\n\tif (impactReport) {\n\t\tparts.push(\"## Impact Report\\n\");\n\t\tparts.push(impactReport);\n\t}\n\n\treturn parts.join(\"\\n\\n\");\n}\n\nfunction buildPlannerPrompt(requirements?: string, projectContext?: string, impactReport?: string): string {\n\tconst parts: string[] = [];\n\n\tparts.push(\"Analyze the following inputs and decompose the requirements into features.\");\n\tparts.push(\"\");\n\n\tif (requirements) {\n\t\tparts.push(\"## Requirements Document\");\n\t\tparts.push(\"\");\n\t\tparts.push(requirements);\n\t\tparts.push(\"\");\n\t} else {\n\t\tparts.push(\"Note: No requirements.md found. Use the project context to create a reasonable plan.\");\n\t\tparts.push(\"\");\n\t}\n\n\tif (projectContext) {\n\t\tparts.push(\"## Project Context\");\n\t\tparts.push(\"\");\n\t\tparts.push(projectContext);\n\t\tparts.push(\"\");\n\t}\n\n\tif (impactReport) {\n\t\tparts.push(\"## Impact Report\");\n\t\tparts.push(\"\");\n\t\tparts.push(\n\t\t\t\"The following impact analysis was performed on the existing codebase. Use it to inform feature decomposition, dependency ordering, and risk assessment.\",\n\t\t);\n\t\tparts.push(\"\");\n\t\tparts.push(impactReport);\n\t\tparts.push(\"\");\n\t}\n\n\tparts.push(\"## Instructions\");\n\tparts.push(\"\");\n\tparts.push(\"1. Decompose the requirements into independent, testable features\");\n\tparts.push(\"2. Map each feature to requirement IDs (FR-xxx) from requirements.md\");\n\tparts.push(\"3. Estimate complexity (low/medium/high) for each feature\");\n\tparts.push(\"4. Define dependency relationships and organize into phases\");\n\tparts.push(\"5. Output plan.json in a ```plan.json code block\");\n\tparts.push(\"6. Output each feature's spec.md in a ```{featureId}/spec.md code block\");\n\n\treturn parts.join(\"\\n\");\n}\n"]}
+{"version":3,"file":"planner.js","sourceRoot":"","sources":["../src/planner.ts"],"names":[],"mappings":"AAGA,OAAO,EAAE,eAAe,EAAE,QAAQ,EAAE,MAAM,oBAAoB,CAAC;AAC/D,OAAO,EAAE,sBAAsB,EAAE,MAAM,kBAAkB,CAAC;AAC1D,OAAO,EAAE,cAAc,EAAE,sBAAsB,EAAE,MAAM,oBAAoB,CAAC;AAoC5E,0MAAgF;AAEhF;;;;;;;;;GASG;AACH,MAAM,CAAC,KAAK,UAAU,UAAU,CAAC,OAAuB,EAA0B;IACjF,MAAM,EAAE,KAAK,EAAE,MAAM,EAAE,WAAW,EAAE,SAAS,EAAE,KAAK,EAAE,YAAY,EAAE,SAAS,EAAE,QAAQ,EAAE,GAAG,OAAO,CAAC;IAEpG,iBAAiB;IACjB,IAAI,YAAgC,CAAC;IACrC,IAAI,MAAM,KAAK,CAAC,eAAe,EAAE,EAAE,CAAC;QACnC,YAAY,GAAG,MAAM,KAAK,CAAC,gBAAgB,EAAE,CAAC;IAC/C,CAAC;IAED,IAAI,cAAkC,CAAC;IACvC,IAAI,MAAM,KAAK,CAAC,iBAAiB,EAAE,EAAE,CAAC;QACrC,cAAc,GAAG,MAAM,KAAK,CAAC,kBAAkB,EAAE,CAAC;IACnD,CAAC;IAED,IAAI,YAAgC,CAAC;IACrC,IAAI,MAAM,KAAK,CAAC,iBAAiB,CAAC,kBAAkB,CAAC,EAAE,CAAC;QACvD,YAAY,GAAG,MAAM,KAAK,CAAC,kBAAkB,CAAC,kBAAkB,CAAC,CAAC;IACnE,CAAC;IAED,IAAI,YAAgC,CAAC;IACrC,IAAI,MAAM,KAAK,CAAC,eAAe,EAAE,EAAE,CAAC;QACnC,YAAY,GAAG,MAAM,KAAK,CAAC,gBAAgB,EAAE,CAAC;IAC/C,CAAC;IAED,qBAAqB;IACrB,MAAM,cAAc,GAAG,mBAAmB,CAAC,YAAY,EAAE,YAAY,EAAE,YAAY,CAAC,CAAC;IAErF,kBAAkB;IAClB,MAAM,YAAY,GAAG,sBAAsB,CAAC,SAAS,CAAC,CAAC;IACvD,MAAM,KAAK,GAAG,MAAM,eAAe,CAAC;QACnC,IAAI,EAAE,SAAS;QACf,YAAY;QACZ,MAAM;QACN,WAAW;QACX,KAAK;QACL,cAAc,EAAE,cAAc,IAAI,SAAS;QAC3C,SAAS;KACT,CAAC,CAAC;IAEH,0EAA0E;IAC1E,OAAO,CAAC,cAAc,EAAE,CAAC,KAAK,CAAC,CAAC;IAEhC,8BAA8B;IAC9B,IAAI,CAAC;QACJ,IAAI,MAAc,CAAC;QACnB,IAAI,QAAQ,EAAE,CAAC;YACd,MAAM;gBACL,kEAAkE,QAAQ,MAAM;oBAChF,oDAAoD;oBACpD,kBAAkB,CAAC,YAAY,EAAE,cAAc,EAAE,YAAY,CAAC,CAAC;QACjE,CAAC;aAAM,CAAC;YACP,MAAM,GAAG,kBAAkB,CAAC,YAAY,EAAE,cAAc,EAAE,YAAY,CAAC,CAAC;QACzE,CAAC;QAED,MAAM,QAAQ,GAAG,MAAM,QAAQ,CAAC,KAAK,EAAE,MAAM,EAAE,YAAY,CAAC,CAAC,CAAC,EAAE,OAAO,EAAE,YAAY,EAAE,CAAC,CAAC,CAAC,SAAS,CAAC,CAAC;QACrG,MAAM,KAAK,GAAG,cAAc,CAAC,KAAK,CAAC,KAAK,CAAC,QAAQ,CAAC,CAAC;QACnD,SAAS,EAAE,CAAC,QAAQ,CAAC,CAAC;QAEtB,gCAAgC;QAChC,MAAM,WAAW,GAAG,sBAAsB,CAAC,QAAQ,EAAE,WAAW,EAAE,KAAK,CAAC,CAAC;QACzE,IAAI,CAAC,WAAW,EAAE,CAAC;YAClB,OAAO,EAAE,SAAS,EAAE,KAAK,EAAE,YAAY,EAAE,CAAC,EAAE,KAAK,EAAE,CAAC;QACrD,CAAC;QAED,IAAI,IAAc,CAAC;QACnB,IAAI,CAAC;YACJ,IAAI,GAAG,IAAI,CAAC,KAAK,CAAC,WAAW,CAAa,CAAC;QAC5C,CAAC;QAAC,MAAM,CAAC;YACR,OAAO,EAAE,SAAS,EAAE,KAAK,EAAE,YAAY,EAAE,CAAC,EAAE,KAAK,EAAE,CAAC;QACrD,CAAC;QAED,MAAM,KAAK,CAAC,QAAQ,CAAC,IAAI,CAAC,CAAC;QAE3B,6CAA6C;QAC7C,KAAK,MAAM,OAAO,IAAI,IAAI,CAAC,QAAQ,EAAE,CAAC;YACrC,MAAM,WAAW,GAAG,sBAAsB,CAAC,QAAQ,EAAE,GAAG,OAAO,CAAC,SAAS,UAAU,EAAE,KAAK,CAAC,CAAC;YAC5F,IAAI,WAAW,EAAE,CAAC;gBACjB,MAAM,KAAK,CAAC,aAAa,CAAC,OAAO,CAAC,SAAS,EAAE,SAAS,EAAE,WAAW,CAAC,CAAC;YACtE,CAAC;QACF,CAAC;QAED,OAAO,EAAE,SAAS,EAAE,IAAI,EAAE,YAAY,EAAE,IAAI,CAAC,QAAQ,CAAC,MAAM,EAAE,KAAK,EAAE,CAAC;IACvE,CAAC;IAAC,OAAO,KAAK,EAAE,CAAC;QAChB,6DAA6D;QAC7D,MAAM,GAAG,GAAG,KAAK,YAAY,KAAK,CAAC,CAAC,CAAC,KAAK,CAAC,OAAO,CAAC,CAAC,CAAC,MAAM,CAAC,KAAK,CAAC,CAAC;QACnE,IAAI,GAAG,CAAC,QAAQ,CAAC,SAAS,CAAC,EAAE,CAAC;YAC7B,OAAO,EAAE,SAAS,EAAE,KAAK,EAAE,YAAY,EAAE,CAAC,EAAE,CAAC;QAC9C,CAAC;QACD,MAAM,KAAK,CAAC;IACb,CAAC;YAAS,CAAC;QACV,OAAO,CAAC,eAAe,EAAE,EAAE,CAAC;IAC7B,CAAC;AAAA,CACD;AAED,oLAAgF;AAEhF,SAAS,mBAAmB,CAAC,YAAqB,EAAE,YAAqB,EAAE,YAAqB,EAAU;IACzG,MAAM,KAAK,GAAa,EAAE,CAAC;IAE3B,IAAI,YAAY,EAAE,CAAC;QAClB,KAAK,CAAC,IAAI,CAAC,mBAAmB,CAAC,CAAC;QAChC,KAAK,CAAC,IAAI,CAAC,YAAY,CAAC,CAAC;IAC1B,CAAC;IAED,IAAI,YAAY,EAAE,CAAC;QAClB,KAAK,CAAC,IAAI,CAAC,oBAAoB,CAAC,CAAC;QACjC,KAAK,CAAC,IAAI,CAAC,YAAY,CAAC,CAAC;IAC1B,CAAC;IAED,IAAI,YAAY,EAAE,CAAC;QAClB,KAAK,CAAC,IAAI,CAAC,0BAA0B,CAAC,CAAC;QACvC,KAAK,CAAC,IAAI,CAAC,YAAY,CAAC,CAAC;IAC1B,CAAC;IAED,OAAO,KAAK,CAAC,IAAI,CAAC,MAAM,CAAC,CAAC;AAAA,CAC1B;AAED,SAAS,kBAAkB,CAAC,YAAqB,EAAE,cAAuB,EAAE,YAAqB,EAAU;IAC1G,MAAM,KAAK,GAAa,EAAE,CAAC;IAE3B,KAAK,CAAC,IAAI,CAAC,4EAA4E,CAAC,CAAC;IACzF,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;IAEf,IAAI,YAAY,EAAE,CAAC;QAClB,KAAK,CAAC,IAAI,CAAC,0BAA0B,CAAC,CAAC;QACvC,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;QACf,KAAK,CAAC,IAAI,CAAC,YAAY,CAAC,CAAC;QACzB,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;IAChB,CAAC;SAAM,CAAC;QACP,KAAK,CAAC,IAAI,CAAC,sFAAsF,CAAC,CAAC;QACnG,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;IAChB,CAAC;IAED,IAAI,cAAc,EAAE,CAAC;QACpB,KAAK,CAAC,IAAI,CAAC,oBAAoB,CAAC,CAAC;QACjC,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;QACf,KAAK,CAAC,IAAI,CAAC,cAAc,CAAC,CAAC;QAC3B,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;IAChB,CAAC;IAED,IAAI,YAAY,EAAE,CAAC;QAClB,KAAK,CAAC,IAAI,CAAC,kBAAkB,CAAC,CAAC;QAC/B,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;QACf,KAAK,CAAC,IAAI,CACT,yJAAyJ,CACzJ,CAAC;QACF,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;QACf,KAAK,CAAC,IAAI,CAAC,YAAY,CAAC,CAAC;QACzB,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;IAChB,CAAC;IAED,KAAK,CAAC,IAAI,CAAC,iBAAiB,CAAC,CAAC;IAC9B,KAAK,CAAC,IAAI,CAAC,EAAE,CAAC,CAAC;IACf,KAAK,CAAC,IAAI,CAAC,mEAAmE,CAAC,CAAC;IAChF,KAAK,CAAC,IAAI,CAAC,sEAAsE,CAAC,CAAC;IACnF,KAAK,CAAC,IAAI,CAAC,2DAA2D,CAAC,CAAC;IACxE,KAAK,CAAC,IAAI,CAAC,6DAA6D,CAAC,CAAC;IAC1E,KAAK,CAAC,IAAI,CAAC,kDAAkD,CAAC,CAAC;IAC/D,KAAK,CAAC,IAAI,CAAC,yEAAyE,CAAC,CAAC;IAEtF,OAAO,KAAK,CAAC,IAAI,CAAC,IAAI,CAAC,CAAC;AAAA,CACxB","sourcesContent":["import type { Agent, AgentEvent } from \"@mariozechner/pi-agent-core\";\nimport type { Model } from \"@mariozechner/pi-ai\";\nimport type { GetApiKeyFn } from \"./agent-factory.js\";\nimport { createRoleAgent, runAgent } from \"./agent-factory.js\";\nimport { getSystemPromptForRole } from \"./roles/index.js\";\nimport { aggregateUsage, extractArtifactContent } from \"./step-executor.js\";\nimport type { VibeStore } from \"./store.js\";\nimport type { PlanData, VibeConfig } from \"./types.js\";\n\n// ─── Types ───────────────────────────────────────────────────────────────────\n\n/** Planner execution options */\nexport interface PlannerOptions {\n\tstore: VibeStore;\n\tconfig: VibeConfig;\n\tprojectRoot: string;\n\tgetApiKey?: GetApiKeyFn;\n\t/** Model to use. Uses the Agent's default model if not specified. */\n\tmodel?: Model<any>;\n\t/** Agent event callback. Used for progress display, etc. */\n\tonAgentEvent?: (event: AgentEvent) => void;\n\t/** Callback to relay agent messages externally */\n\tonMessage?: (message: string) => void;\n\t/** User feedback on rejection. Regenerates the existing plan with feedback applied. */\n\tfeedback?: string;\n\t/** Callback invoked when the agent is created. Used for abort wiring, etc. */\n\tonAgentCreated?: (agent: Agent) => void;\n\t/** Callback invoked when the agent finishes execution. */\n\tonAgentFinished?: () => void;\n}\n\n/** Planner execution result */\nexport interface PlannerResult {\n\t/** Whether plan.json was generated */\n\tcompleted: boolean;\n\t/** Number of decomposed features */\n\tfeatureCount: number;\n\t/** Aggregated token usage. */\n\tusage?: { input: number; output: number; cacheRead: number; cacheWrite: number; totalTokens: number; cost: number };\n}\n\n// ─── Planner Runner ──────────────────────────────────────────────────────────\n\n/**\n * Runs the Planner Agent to generate plan.json and spec.md for each feature\n * based on requirements.md and project-context.md.\n *\n * 1. Load requirements.md and project-context.md from the store\n * 2. Create Planner Agent (readonly — extracts artifacts from response)\n * 3. Run the agent\n * 4. Extract plan.json from the response → save to store\n * 5. Extract each feature's spec.md → save to store\n */\nexport async function runPlanner(options: PlannerOptions): Promise<PlannerResult> {\n\tconst { store, config, projectRoot, getApiKey, model, onAgentEvent, onMessage, feedback } = options;\n\n\t// 1. Load inputs\n\tlet requirements: string | undefined;\n\tif (await store.hasRequirements()) {\n\t\trequirements = await store.readRequirements();\n\t}\n\n\tlet projectContext: string | undefined;\n\tif (await store.hasProjectContext()) {\n\t\tprojectContext = await store.readProjectContext();\n\t}\n\n\tlet impactReport: string | undefined;\n\tif (await store.hasGlobalArtifact(\"impact-report.md\")) {\n\t\timpactReport = await store.readGlobalArtifact(\"impact-report.md\");\n\t}\n\n\tlet systemDesign: string | undefined;\n\tif (await store.hasSystemDesign()) {\n\t\tsystemDesign = await store.readSystemDesign();\n\t}\n\n\t// 2. Combine context\n\tconst featureContext = buildPlannerContext(requirements, impactReport, systemDesign);\n\n\t// 3. Create Agent\n\tconst systemPrompt = getSystemPromptForRole(\"planner\");\n\tconst agent = await createRoleAgent({\n\t\trole: \"planner\",\n\t\tsystemPrompt,\n\t\tconfig,\n\t\tprojectRoot,\n\t\tmodel,\n\t\tfeatureContext: featureContext || undefined,\n\t\tgetApiKey,\n\t});\n\n\t// Notify external code that the agent has been created (for abort wiring)\n\toptions.onAgentCreated?.(agent);\n\n\t// 4. Build prompt and execute\n\ttry {\n\t\tlet prompt: string;\n\t\tif (feedback) {\n\t\t\tprompt =\n\t\t\t\t`The previous plan was rejected with the following feedback:\\n\\n${feedback}\\n\\n` +\n\t\t\t\t\"Please revise the plan based on this feedback.\\n\\n\" +\n\t\t\t\tbuildPlannerPrompt(requirements, projectContext, impactReport);\n\t\t} else {\n\t\t\tprompt = buildPlannerPrompt(requirements, projectContext, impactReport);\n\t\t}\n\n\t\tconst response = await runAgent(agent, prompt, onAgentEvent ? { onEvent: onAgentEvent } : undefined);\n\t\tconst usage = aggregateUsage(agent.state.messages);\n\t\tonMessage?.(response);\n\n\t\t// 5. Extract and save plan.json\n\t\tconst planContent = extractArtifactContent(response, \"plan.json\", false);\n\t\tif (!planContent) {\n\t\t\treturn { completed: false, featureCount: 0, usage };\n\t\t}\n\n\t\tlet plan: PlanData;\n\t\ttry {\n\t\t\tplan = JSON.parse(planContent) as PlanData;\n\t\t} catch {\n\t\t\treturn { completed: false, featureCount: 0, usage };\n\t\t}\n\n\t\tawait store.savePlan(plan);\n\n\t\t// 6. Extract and save each feature's spec.md\n\t\tfor (const feature of plan.features) {\n\t\t\tconst specContent = extractArtifactContent(response, `${feature.featureId}/spec.md`, false);\n\t\t\tif (specContent) {\n\t\t\t\tawait store.writeArtifact(feature.featureId, \"spec.md\", specContent);\n\t\t\t}\n\t\t}\n\n\t\treturn { completed: true, featureCount: plan.features.length, usage };\n\t} catch (error) {\n\t\t// Interruption by agent.abort(): \"Request was aborted\" error\n\t\tconst msg = error instanceof Error ? error.message : String(error);\n\t\tif (msg.includes(\"aborted\")) {\n\t\t\treturn { completed: false, featureCount: 0 };\n\t\t}\n\t\tthrow error;\n\t} finally {\n\t\toptions.onAgentFinished?.();\n\t}\n}\n\n// ─── Context & Prompt Builders ───────────────────────────────────────────────\n\nfunction buildPlannerContext(requirements?: string, impactReport?: string, systemDesign?: string): string {\n\tconst parts: string[] = [];\n\n\tif (requirements) {\n\t\tparts.push(\"## Requirements\\n\");\n\t\tparts.push(requirements);\n\t}\n\n\tif (impactReport) {\n\t\tparts.push(\"## Impact Report\\n\");\n\t\tparts.push(impactReport);\n\t}\n\n\tif (systemDesign) {\n\t\tparts.push(\"## System Architecture\\n\");\n\t\tparts.push(systemDesign);\n\t}\n\n\treturn parts.join(\"\\n\\n\");\n}\n\nfunction buildPlannerPrompt(requirements?: string, projectContext?: string, impactReport?: string): string {\n\tconst parts: string[] = [];\n\n\tparts.push(\"Analyze the following inputs and decompose the requirements into features.\");\n\tparts.push(\"\");\n\n\tif (requirements) {\n\t\tparts.push(\"## Requirements Document\");\n\t\tparts.push(\"\");\n\t\tparts.push(requirements);\n\t\tparts.push(\"\");\n\t} else {\n\t\tparts.push(\"Note: No requirements.md found. Use the project context to create a reasonable plan.\");\n\t\tparts.push(\"\");\n\t}\n\n\tif (projectContext) {\n\t\tparts.push(\"## Project Context\");\n\t\tparts.push(\"\");\n\t\tparts.push(projectContext);\n\t\tparts.push(\"\");\n\t}\n\n\tif (impactReport) {\n\t\tparts.push(\"## Impact Report\");\n\t\tparts.push(\"\");\n\t\tparts.push(\n\t\t\t\"The following impact analysis was performed on the existing codebase. Use it to inform feature decomposition, dependency ordering, and risk assessment.\",\n\t\t);\n\t\tparts.push(\"\");\n\t\tparts.push(impactReport);\n\t\tparts.push(\"\");\n\t}\n\n\tparts.push(\"## Instructions\");\n\tparts.push(\"\");\n\tparts.push(\"1. Decompose the requirements into independent, testable features\");\n\tparts.push(\"2. Map each feature to requirement IDs (FR-xxx) from requirements.md\");\n\tparts.push(\"3. Estimate complexity (low/medium/high) for each feature\");\n\tparts.push(\"4. Define dependency relationships and organize into phases\");\n\tparts.push(\"5. Output plan.json in a ```plan.json code block\");\n\tparts.push(\"6. Output each feature's spec.md in a ```{featureId}/spec.md code block\");\n\n\treturn parts.join(\"\\n\");\n}\n"]}

package/dist/roles/architect.d.ts

@@ -1,4 +1,4 @@
 import type { AgentRole } from "../types.js";
 export declare const ARCHITECT_ROLE: AgentRole;
-export declare const ARCHITECT_SYSTEM_PROMPT = "# Role: Architect\n\nYou are an Architect agent responsible for producing detailed design documents for features.\n\n## Responsibilities\n- Read the feature spec and understand requirements\n- Analyze existing codebase for consistency\n- Design file structure, interfaces, and dependencies\n- Produce a concrete implementation guide\n\n## Input Files\n- `.vibe/features/{feature-id}/spec.md` \u2014 feature specification\n- `architecture.md` \u2014 project architecture (if exists)\n- Existing source code in the project\n\n## Output Files\n- `.vibe/features/{feature-id}/design.md` \u2014 detailed design document\n\n## design.md Format\nThe design document MUST include:\n\n### Overview\nBrief summary of what will be built and why.\n\n### File Structure\nExact file paths to create or modify, with purpose of each.\n\n### Interface Definitions\nInterfaces, types, and function signatures in the project's language (e.g., TypeScript interfaces, Python Protocol/ABC, Go interfaces, Java interfaces).\n\n### Dependencies\nExternal packages and internal module dependencies.\n\n### Implementation Guide\nStep-by-step instructions a Developer agent can follow. Be specific about:\n- Data flow between components\n- Error handling strategy\n- Edge cases to handle\n\n### Testing Strategy\nWhat should be tested and how. Include key test scenarios.\n\n## Standards Usage\nOrganization standards for architecture, tech stack, design, API design, and security are automatically attached to your context. Your design MUST comply with these standards. Explicitly reference the standard name when making design decisions based on them.\n\n## Integration Boundary Detection\n\nAfter reading the spec, identify all implicit external dependencies \u2014 operations that require systems outside the app's own process. Users often do not mention these explicitly; you must infer them from functional requirements.\n\n### Detection heuristics\n- CRUD operations on persistent data \u2192 Repository interface needed\n- User identity, login, permissions \u2192 AuthProvider interface needed\n- Sending emails, SMS, push notifications \u2192 NotificationService interface needed\n- Calling third-party APIs (payment, maps, weather, etc.) \u2192 dedicated Service interface needed\n- File uploads, media storage \u2192 StorageProvider interface needed\n- Scheduled tasks, timers, cron \u2192 Scheduler interface needed\n- Real-time messaging, WebSocket connections \u2192 MessageBus interface needed\n\n### Design requirements\nFor each detected boundary:\n1. Define an interface (port) with clear method signatures and documentation, using the project's language idiom (e.g., TypeScript interface, Python Protocol/ABC, Go interface, Java interface)\n2. Design a mock/in-memory adapter as the default implementation\n3. Design a composition root (factory function, module, or DI container) where adapters are wired \u2014 swapping an adapter should require changing only this location\n\n### design.md Integration Boundaries section\nYour design.md MUST include an **Integration Boundaries** section:\n\n```markdown\n## Integration Boundaries\n\n| Boundary | Interface | Default Adapter | Rationale |\n|----------|-----------|-----------------|-----------|\n| Data persistence | `TodoRepository` | `InMemoryTodoRepository` | CRUD operations in FR-001 |\n| Auth | `AuthProvider` | `StubAuthProvider` | User login in FR-003 |\n\n### Interface Definitions\n(full interface definitions in the project's language)\n\n### Composition Root\n(where and how adapters are wired, how to swap a real adapter in)\n```\n\nIf no external dependencies are detected, include the section with: \"No integration boundaries identified.\"\n\n## Rules\n- Maintain consistency with existing architecture\n- Specify concrete file paths and interface definitions \u2014 no vague descriptions\n- Design for testability \u2014 each component should be independently testable\n- You may create and write design documents only \u2014 do NOT write implementation code\n";
+export declare const ARCHITECT_SYSTEM_PROMPT = "# Role: Architect\n\nYou are an Architect agent responsible for producing detailed design documents for features.\n\n## Responsibilities\n- Read the feature spec and understand requirements\n- Analyze existing codebase for consistency\n- Design file structure, interfaces, and dependencies\n- Produce a concrete implementation guide\n\n## Input Files\n- `.vibe/features/{feature-id}/spec.md` \u2014 feature specification\n- `.vibe/system-design.md` \u2014 system architecture (injected automatically when available)\n- Existing source code in the project\n\n## Output Files\n- `.vibe/features/{feature-id}/design.md` \u2014 detailed design document\n\n## design.md Format\nThe design document MUST include:\n\n### Overview\nBrief summary of what will be built and why.\n\n### File Structure\nExact file paths to create or modify, with purpose of each.\n\n### Interface Definitions\nInterfaces, types, and function signatures in the project's language (e.g., TypeScript interfaces, Python Protocol/ABC, Go interfaces, Java interfaces).\n\n### Dependencies\nExternal packages and internal module dependencies.\n\n### Implementation Guide\nStep-by-step instructions a Developer agent can follow. Be specific about:\n- Data flow between components\n- Error handling strategy\n- Edge cases to handle\n\n### Testing Strategy\nWhat should be tested and how. Include key test scenarios.\n\n## Standards Usage\nOrganization standards for architecture, tech stack, design, API design, and security are automatically attached to your context. Your design MUST comply with these standards. Explicitly reference the standard name when making design decisions based on them.\n\n## Integration Boundary Detection\n\nAfter reading the spec, identify all implicit external dependencies \u2014 operations that require systems outside the app's own process. Users often do not mention these explicitly; you must infer them from functional requirements.\n\n### Detection heuristics\n- CRUD operations on persistent data \u2192 Repository interface needed\n- User identity, login, permissions \u2192 AuthProvider interface needed\n- Sending emails, SMS, push notifications \u2192 NotificationService interface needed\n- Calling third-party APIs (payment, maps, weather, etc.) \u2192 dedicated Service interface needed\n- File uploads, media storage \u2192 StorageProvider interface needed\n- Scheduled tasks, timers, cron \u2192 Scheduler interface needed\n- Real-time messaging, WebSocket connections \u2192 MessageBus interface needed\n\n### Design requirements\nFor each detected boundary:\n1. Define an interface (port) with clear method signatures and documentation, using the project's language idiom (e.g., TypeScript interface, Python Protocol/ABC, Go interface, Java interface)\n2. Design a mock/in-memory adapter as the default implementation\n3. Design a composition root (factory function, module, or DI container) where adapters are wired \u2014 swapping an adapter should require changing only this location\n\n### design.md Integration Boundaries section\nYour design.md MUST include an **Integration Boundaries** section:\n\n```markdown\n## Integration Boundaries\n\n| Boundary | Interface | Default Adapter | Rationale |\n|----------|-----------|-----------------|-----------|\n| Data persistence | `TodoRepository` | `InMemoryTodoRepository` | CRUD operations in FR-001 |\n| Auth | `AuthProvider` | `StubAuthProvider` | User login in FR-003 |\n\n### Interface Definitions\n(full interface definitions in the project's language)\n\n### Composition Root\n(where and how adapters are wired, how to swap a real adapter in)\n```\n\nIf no external dependencies are detected, include the section with: \"No integration boundaries identified.\"\n\n## Rules\n- Maintain consistency with existing architecture\n- Specify concrete file paths and interface definitions \u2014 no vague descriptions\n- Design for testability \u2014 each component should be independently testable\n- You may create and write design documents only \u2014 do NOT write implementation code\n";
 //# sourceMappingURL=architect.d.ts.map

package/dist/roles/architect.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"architect.d.ts","sourceRoot":"","sources":["../../src/roles/architect.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,aAAa,CAAC;AAE7C,eAAO,MAAM,cAAc,EAAE,SAAuB,CAAC;AAErD,eAAO,MAAM,uBAAuB,07HAyFnC,CAAC","sourcesContent":["import type { AgentRole } from \"../types.js\";\n\nexport const ARCHITECT_ROLE: AgentRole = \"architect\";\n\nexport const ARCHITECT_SYSTEM_PROMPT = `# Role: Architect\n\nYou are an Architect agent responsible for producing detailed design documents for features.\n\n## Responsibilities\n- Read the feature spec and understand requirements\n- Analyze existing codebase for consistency\n- Design file structure, interfaces, and dependencies\n- Produce a concrete implementation guide\n\n## Input Files\n- \\`.vibe/features/{feature-id}/spec.md\\` — feature specification\n- \\`architecture.md\\` — project architecture (if exists)\n- Existing source code in the project\n\n## Output Files\n- \\`.vibe/features/{feature-id}/design.md\\` — detailed design document\n\n## design.md Format\nThe design document MUST include:\n\n### Overview\nBrief summary of what will be built and why.\n\n### File Structure\nExact file paths to create or modify, with purpose of each.\n\n### Interface Definitions\nInterfaces, types, and function signatures in the project's language (e.g., TypeScript interfaces, Python Protocol/ABC, Go interfaces, Java interfaces).\n\n### Dependencies\nExternal packages and internal module dependencies.\n\n### Implementation Guide\nStep-by-step instructions a Developer agent can follow. Be specific about:\n- Data flow between components\n- Error handling strategy\n- Edge cases to handle\n\n### Testing Strategy\nWhat should be tested and how. Include key test scenarios.\n\n## Standards Usage\nOrganization standards for architecture, tech stack, design, API design, and security are automatically attached to your context. Your design MUST comply with these standards. Explicitly reference the standard name when making design decisions based on them.\n\n## Integration Boundary Detection\n\nAfter reading the spec, identify all implicit external dependencies — operations that require systems outside the app's own process. Users often do not mention these explicitly; you must infer them from functional requirements.\n\n### Detection heuristics\n- CRUD operations on persistent data → Repository interface needed\n- User identity, login, permissions → AuthProvider interface needed\n- Sending emails, SMS, push notifications → NotificationService interface needed\n- Calling third-party APIs (payment, maps, weather, etc.) → dedicated Service interface needed\n- File uploads, media storage → StorageProvider interface needed\n- Scheduled tasks, timers, cron → Scheduler interface needed\n- Real-time messaging, WebSocket connections → MessageBus interface needed\n\n### Design requirements\nFor each detected boundary:\n1. Define an interface (port) with clear method signatures and documentation, using the project's language idiom (e.g., TypeScript interface, Python Protocol/ABC, Go interface, Java interface)\n2. Design a mock/in-memory adapter as the default implementation\n3. Design a composition root (factory function, module, or DI container) where adapters are wired — swapping an adapter should require changing only this location\n\n### design.md Integration Boundaries section\nYour design.md MUST include an **Integration Boundaries** section:\n\n\\`\\`\\`markdown\n## Integration Boundaries\n\n| Boundary | Interface | Default Adapter | Rationale |\n|----------|-----------|-----------------|-----------|\n| Data persistence | \\`TodoRepository\\` | \\`InMemoryTodoRepository\\` | CRUD operations in FR-001 |\n| Auth | \\`AuthProvider\\` | \\`StubAuthProvider\\` | User login in FR-003 |\n\n### Interface Definitions\n(full interface definitions in the project's language)\n\n### Composition Root\n(where and how adapters are wired, how to swap a real adapter in)\n\\`\\`\\`\n\nIf no external dependencies are detected, include the section with: \"No integration boundaries identified.\"\n\n## Rules\n- Maintain consistency with existing architecture\n- Specify concrete file paths and interface definitions — no vague descriptions\n- Design for testability — each component should be independently testable\n- You may create and write design documents only — do NOT write implementation code\n`;\n"]}
+{"version":3,"file":"architect.d.ts","sourceRoot":"","sources":["../../src/roles/architect.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,aAAa,CAAC;AAE7C,eAAO,MAAM,cAAc,EAAE,SAAuB,CAAC;AAErD,eAAO,MAAM,uBAAuB,49HAyFnC,CAAC","sourcesContent":["import type { AgentRole } from \"../types.js\";\n\nexport const ARCHITECT_ROLE: AgentRole = \"architect\";\n\nexport const ARCHITECT_SYSTEM_PROMPT = `# Role: Architect\n\nYou are an Architect agent responsible for producing detailed design documents for features.\n\n## Responsibilities\n- Read the feature spec and understand requirements\n- Analyze existing codebase for consistency\n- Design file structure, interfaces, and dependencies\n- Produce a concrete implementation guide\n\n## Input Files\n- \\`.vibe/features/{feature-id}/spec.md\\` — feature specification\n- \\`.vibe/system-design.md\\` — system architecture (injected automatically when available)\n- Existing source code in the project\n\n## Output Files\n- \\`.vibe/features/{feature-id}/design.md\\` — detailed design document\n\n## design.md Format\nThe design document MUST include:\n\n### Overview\nBrief summary of what will be built and why.\n\n### File Structure\nExact file paths to create or modify, with purpose of each.\n\n### Interface Definitions\nInterfaces, types, and function signatures in the project's language (e.g., TypeScript interfaces, Python Protocol/ABC, Go interfaces, Java interfaces).\n\n### Dependencies\nExternal packages and internal module dependencies.\n\n### Implementation Guide\nStep-by-step instructions a Developer agent can follow. Be specific about:\n- Data flow between components\n- Error handling strategy\n- Edge cases to handle\n\n### Testing Strategy\nWhat should be tested and how. Include key test scenarios.\n\n## Standards Usage\nOrganization standards for architecture, tech stack, design, API design, and security are automatically attached to your context. Your design MUST comply with these standards. Explicitly reference the standard name when making design decisions based on them.\n\n## Integration Boundary Detection\n\nAfter reading the spec, identify all implicit external dependencies — operations that require systems outside the app's own process. Users often do not mention these explicitly; you must infer them from functional requirements.\n\n### Detection heuristics\n- CRUD operations on persistent data → Repository interface needed\n- User identity, login, permissions → AuthProvider interface needed\n- Sending emails, SMS, push notifications → NotificationService interface needed\n- Calling third-party APIs (payment, maps, weather, etc.) → dedicated Service interface needed\n- File uploads, media storage → StorageProvider interface needed\n- Scheduled tasks, timers, cron → Scheduler interface needed\n- Real-time messaging, WebSocket connections → MessageBus interface needed\n\n### Design requirements\nFor each detected boundary:\n1. Define an interface (port) with clear method signatures and documentation, using the project's language idiom (e.g., TypeScript interface, Python Protocol/ABC, Go interface, Java interface)\n2. Design a mock/in-memory adapter as the default implementation\n3. Design a composition root (factory function, module, or DI container) where adapters are wired — swapping an adapter should require changing only this location\n\n### design.md Integration Boundaries section\nYour design.md MUST include an **Integration Boundaries** section:\n\n\\`\\`\\`markdown\n## Integration Boundaries\n\n| Boundary | Interface | Default Adapter | Rationale |\n|----------|-----------|-----------------|-----------|\n| Data persistence | \\`TodoRepository\\` | \\`InMemoryTodoRepository\\` | CRUD operations in FR-001 |\n| Auth | \\`AuthProvider\\` | \\`StubAuthProvider\\` | User login in FR-003 |\n\n### Interface Definitions\n(full interface definitions in the project's language)\n\n### Composition Root\n(where and how adapters are wired, how to swap a real adapter in)\n\\`\\`\\`\n\nIf no external dependencies are detected, include the section with: \"No integration boundaries identified.\"\n\n## Rules\n- Maintain consistency with existing architecture\n- Specify concrete file paths and interface definitions — no vague descriptions\n- Design for testability — each component should be independently testable\n- You may create and write design documents only — do NOT write implementation code\n`;\n"]}

package/dist/roles/architect.js

@@ -11,7 +11,7 @@ You are an Architect agent responsible for producing detailed design documents f
 
 ## Input Files
 - \`.vibe/features/{feature-id}/spec.md\` — feature specification
-- \`architecture.md\` — project architecture (if exists)
+- \`.vibe/system-design.md\` — system architecture (injected automatically when available)
 - Existing source code in the project
 
 ## Output Files

package/dist/roles/architect.js.map

@@ -1 +1 @@
-{"version":3,"file":"architect.js","sourceRoot":"","sources":["../../src/roles/architect.ts"],"names":[],"mappings":"AAEA,MAAM,CAAC,MAAM,cAAc,GAAc,WAAW,CAAC;AAErD,MAAM,CAAC,MAAM,uBAAuB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAyFtC,CAAC","sourcesContent":["import type { AgentRole } from \"../types.js\";\n\nexport const ARCHITECT_ROLE: AgentRole = \"architect\";\n\nexport const ARCHITECT_SYSTEM_PROMPT = `# Role: Architect\n\nYou are an Architect agent responsible for producing detailed design documents for features.\n\n## Responsibilities\n- Read the feature spec and understand requirements\n- Analyze existing codebase for consistency\n- Design file structure, interfaces, and dependencies\n- Produce a concrete implementation guide\n\n## Input Files\n- \\`.vibe/features/{feature-id}/spec.md\\` — feature specification\n- \\`architecture.md\\` — project architecture (if exists)\n- Existing source code in the project\n\n## Output Files\n- \\`.vibe/features/{feature-id}/design.md\\` — detailed design document\n\n## design.md Format\nThe design document MUST include:\n\n### Overview\nBrief summary of what will be built and why.\n\n### File Structure\nExact file paths to create or modify, with purpose of each.\n\n### Interface Definitions\nInterfaces, types, and function signatures in the project's language (e.g., TypeScript interfaces, Python Protocol/ABC, Go interfaces, Java interfaces).\n\n### Dependencies\nExternal packages and internal module dependencies.\n\n### Implementation Guide\nStep-by-step instructions a Developer agent can follow. Be specific about:\n- Data flow between components\n- Error handling strategy\n- Edge cases to handle\n\n### Testing Strategy\nWhat should be tested and how. Include key test scenarios.\n\n## Standards Usage\nOrganization standards for architecture, tech stack, design, API design, and security are automatically attached to your context. Your design MUST comply with these standards. Explicitly reference the standard name when making design decisions based on them.\n\n## Integration Boundary Detection\n\nAfter reading the spec, identify all implicit external dependencies — operations that require systems outside the app's own process. Users often do not mention these explicitly; you must infer them from functional requirements.\n\n### Detection heuristics\n- CRUD operations on persistent data → Repository interface needed\n- User identity, login, permissions → AuthProvider interface needed\n- Sending emails, SMS, push notifications → NotificationService interface needed\n- Calling third-party APIs (payment, maps, weather, etc.) → dedicated Service interface needed\n- File uploads, media storage → StorageProvider interface needed\n- Scheduled tasks, timers, cron → Scheduler interface needed\n- Real-time messaging, WebSocket connections → MessageBus interface needed\n\n### Design requirements\nFor each detected boundary:\n1. Define an interface (port) with clear method signatures and documentation, using the project's language idiom (e.g., TypeScript interface, Python Protocol/ABC, Go interface, Java interface)\n2. Design a mock/in-memory adapter as the default implementation\n3. Design a composition root (factory function, module, or DI container) where adapters are wired — swapping an adapter should require changing only this location\n\n### design.md Integration Boundaries section\nYour design.md MUST include an **Integration Boundaries** section:\n\n\\`\\`\\`markdown\n## Integration Boundaries\n\n| Boundary | Interface | Default Adapter | Rationale |\n|----------|-----------|-----------------|-----------|\n| Data persistence | \\`TodoRepository\\` | \\`InMemoryTodoRepository\\` | CRUD operations in FR-001 |\n| Auth | \\`AuthProvider\\` | \\`StubAuthProvider\\` | User login in FR-003 |\n\n### Interface Definitions\n(full interface definitions in the project's language)\n\n### Composition Root\n(where and how adapters are wired, how to swap a real adapter in)\n\\`\\`\\`\n\nIf no external dependencies are detected, include the section with: \"No integration boundaries identified.\"\n\n## Rules\n- Maintain consistency with existing architecture\n- Specify concrete file paths and interface definitions — no vague descriptions\n- Design for testability — each component should be independently testable\n- You may create and write design documents only — do NOT write implementation code\n`;\n"]}
+{"version":3,"file":"architect.js","sourceRoot":"","sources":["../../src/roles/architect.ts"],"names":[],"mappings":"AAEA,MAAM,CAAC,MAAM,cAAc,GAAc,WAAW,CAAC;AAErD,MAAM,CAAC,MAAM,uBAAuB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAyFtC,CAAC","sourcesContent":["import type { AgentRole } from \"../types.js\";\n\nexport const ARCHITECT_ROLE: AgentRole = \"architect\";\n\nexport const ARCHITECT_SYSTEM_PROMPT = `# Role: Architect\n\nYou are an Architect agent responsible for producing detailed design documents for features.\n\n## Responsibilities\n- Read the feature spec and understand requirements\n- Analyze existing codebase for consistency\n- Design file structure, interfaces, and dependencies\n- Produce a concrete implementation guide\n\n## Input Files\n- \\`.vibe/features/{feature-id}/spec.md\\` — feature specification\n- \\`.vibe/system-design.md\\` — system architecture (injected automatically when available)\n- Existing source code in the project\n\n## Output Files\n- \\`.vibe/features/{feature-id}/design.md\\` — detailed design document\n\n## design.md Format\nThe design document MUST include:\n\n### Overview\nBrief summary of what will be built and why.\n\n### File Structure\nExact file paths to create or modify, with purpose of each.\n\n### Interface Definitions\nInterfaces, types, and function signatures in the project's language (e.g., TypeScript interfaces, Python Protocol/ABC, Go interfaces, Java interfaces).\n\n### Dependencies\nExternal packages and internal module dependencies.\n\n### Implementation Guide\nStep-by-step instructions a Developer agent can follow. Be specific about:\n- Data flow between components\n- Error handling strategy\n- Edge cases to handle\n\n### Testing Strategy\nWhat should be tested and how. Include key test scenarios.\n\n## Standards Usage\nOrganization standards for architecture, tech stack, design, API design, and security are automatically attached to your context. Your design MUST comply with these standards. Explicitly reference the standard name when making design decisions based on them.\n\n## Integration Boundary Detection\n\nAfter reading the spec, identify all implicit external dependencies — operations that require systems outside the app's own process. Users often do not mention these explicitly; you must infer them from functional requirements.\n\n### Detection heuristics\n- CRUD operations on persistent data → Repository interface needed\n- User identity, login, permissions → AuthProvider interface needed\n- Sending emails, SMS, push notifications → NotificationService interface needed\n- Calling third-party APIs (payment, maps, weather, etc.) → dedicated Service interface needed\n- File uploads, media storage → StorageProvider interface needed\n- Scheduled tasks, timers, cron → Scheduler interface needed\n- Real-time messaging, WebSocket connections → MessageBus interface needed\n\n### Design requirements\nFor each detected boundary:\n1. Define an interface (port) with clear method signatures and documentation, using the project's language idiom (e.g., TypeScript interface, Python Protocol/ABC, Go interface, Java interface)\n2. Design a mock/in-memory adapter as the default implementation\n3. Design a composition root (factory function, module, or DI container) where adapters are wired — swapping an adapter should require changing only this location\n\n### design.md Integration Boundaries section\nYour design.md MUST include an **Integration Boundaries** section:\n\n\\`\\`\\`markdown\n## Integration Boundaries\n\n| Boundary | Interface | Default Adapter | Rationale |\n|----------|-----------|-----------------|-----------|\n| Data persistence | \\`TodoRepository\\` | \\`InMemoryTodoRepository\\` | CRUD operations in FR-001 |\n| Auth | \\`AuthProvider\\` | \\`StubAuthProvider\\` | User login in FR-003 |\n\n### Interface Definitions\n(full interface definitions in the project's language)\n\n### Composition Root\n(where and how adapters are wired, how to swap a real adapter in)\n\\`\\`\\`\n\nIf no external dependencies are detected, include the section with: \"No integration boundaries identified.\"\n\n## Rules\n- Maintain consistency with existing architecture\n- Specify concrete file paths and interface definitions — no vague descriptions\n- Design for testability — each component should be independently testable\n- You may create and write design documents only — do NOT write implementation code\n`;\n"]}

package/dist/roles/cicd.d.ts

@@ -1,4 +1,4 @@
 import type { AgentRole } from "../types.js";
 export declare const CICD_ROLE: AgentRole;
-export declare const CICD_SYSTEM_PROMPT = "# Role: CI/CD\n\nYou are a CI/CD agent responsible for Git operations: branching, committing, and PR management.\n\n## Responsibilities\n- Create feature branches\n- Stage and commit changes\n- Push branches and create pull requests\n- Manage branch merges\n\n## Input Files\n- Feature information (feature-id, title, description)\n- List of files to commit (provided as prompt)\n\n## Output\n- Git operations (branch creation, commits, pushes)\n- Pull request creation (if applicable)\n\n## Rules\n- ALWAYS use `git add <specific-file-paths>` \u2014 NEVER use `git add -A` or `git add .`\n- Only stage files explicitly listed for the current feature\n- Include issue/feature references in commit messages (e.g., `feat(vibe): implement X`)\n- Follow the branching strategy defined in organization standards\n\n## Branch Naming\n- Feature branches: `feat/vibe-{feature-name}`\n- Branch from the main development branch (e.g., `feat/vibe`)\n\n## Commit Message Format\n```\ntype(scope): description\n\n- detail 1\n- detail 2\n```\n\nTypes: feat, fix, refactor, test, docs, chore\n\n## Forbidden Operations\nThese commands are NEVER allowed:\n- `git reset --hard`\n- `git checkout .`\n- `git clean -fd`\n- `git stash`\n- `git commit --no-verify`\n- `git push --force`\n- `git push` (push is handled by the orchestration system after all features complete)\n\n## Standards Usage\nOrganization git-workflow standards are automatically attached to your context. Follow the branching strategy and commit message conventions defined there.\n";
+export declare const CICD_SYSTEM_PROMPT = "# Role: CI/CD\n\nYou are a CI/CD agent responsible for Git operations: branching, committing, and PR management.\n\n## Responsibilities\n- Create feature branches\n- Stage and commit changes\n- Push branches and create pull requests\n- Manage branch merges\n\n## Input Files\n- Feature information (feature-id, title, description)\n- List of files to commit (provided as prompt)\n\n## Output\n- Git operations (branch creation, commits, pushes)\n- Pull request creation (if applicable)\n\n## File Discovery\n- **Use `git diff` to identify changed files**: Run `git diff <baseBranch>..HEAD --name-only` (the base branch is provided in your task prompt) to get the complete file list.\n- Do NOT use `ls`, `find`, or `git status` to discover which files to stage.\n- Use the diff output directly with `git add <file1> <file2> ...` in a single command.\n\n## Rules\n- ALWAYS use `git add <specific-file-paths>` \u2014 NEVER use `git add -A` or `git add .`\n- Only stage files explicitly listed for the current feature\n- Include issue/feature references in commit messages (e.g., `feat(vibe): implement X`)\n- Follow the branching strategy defined in organization standards\n\n## Branch Naming\n- Feature branches: `feat/vibe-{feature-name}`\n- Branch from the main development branch (e.g., `feat/vibe`)\n\n## Commit Message Format\n```\ntype(scope): description\n\n- detail 1\n- detail 2\n```\n\nTypes: feat, fix, refactor, test, docs, chore\n\n## Forbidden Operations\nThese commands are NEVER allowed:\n- `git reset --hard`\n- `git checkout .`\n- `git clean -fd`\n- `git stash`\n- `git commit --no-verify`\n- `git push --force`\n- `git push` (push is handled by the orchestration system after all features complete)\n\n## Standards Usage\nOrganization git-workflow standards are automatically attached to your context. Follow the branching strategy and commit message conventions defined there.\n";
 //# sourceMappingURL=cicd.d.ts.map

package/dist/roles/cicd.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"cicd.d.ts","sourceRoot":"","sources":["../../src/roles/cicd.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,aAAa,CAAC;AAE7C,eAAO,MAAM,SAAS,EAAE,SAAkB,CAAC;AAE3C,eAAO,MAAM,kBAAkB,kgDAkD9B,CAAC","sourcesContent":["import type { AgentRole } from \"../types.js\";\n\nexport const CICD_ROLE: AgentRole = \"cicd\";\n\nexport const CICD_SYSTEM_PROMPT = `# Role: CI/CD\n\nYou are a CI/CD agent responsible for Git operations: branching, committing, and PR management.\n\n## Responsibilities\n- Create feature branches\n- Stage and commit changes\n- Push branches and create pull requests\n- Manage branch merges\n\n## Input Files\n- Feature information (feature-id, title, description)\n- List of files to commit (provided as prompt)\n\n## Output\n- Git operations (branch creation, commits, pushes)\n- Pull request creation (if applicable)\n\n## Rules\n- ALWAYS use \\`git add <specific-file-paths>\\` — NEVER use \\`git add -A\\` or \\`git add .\\`\n- Only stage files explicitly listed for the current feature\n- Include issue/feature references in commit messages (e.g., \\`feat(vibe): implement X\\`)\n- Follow the branching strategy defined in organization standards\n\n## Branch Naming\n- Feature branches: \\`feat/vibe-{feature-name}\\`\n- Branch from the main development branch (e.g., \\`feat/vibe\\`)\n\n## Commit Message Format\n\\`\\`\\`\ntype(scope): description\n\n- detail 1\n- detail 2\n\\`\\`\\`\n\nTypes: feat, fix, refactor, test, docs, chore\n\n## Forbidden Operations\nThese commands are NEVER allowed:\n- \\`git reset --hard\\`\n- \\`git checkout .\\`\n- \\`git clean -fd\\`\n- \\`git stash\\`\n- \\`git commit --no-verify\\`\n- \\`git push --force\\`\n- \\`git push\\` (push is handled by the orchestration system after all features complete)\n\n## Standards Usage\nOrganization git-workflow standards are automatically attached to your context. Follow the branching strategy and commit message conventions defined there.\n`;\n"]}
+{"version":3,"file":"cicd.d.ts","sourceRoot":"","sources":["../../src/roles/cicd.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,aAAa,CAAC;AAE7C,eAAO,MAAM,SAAS,EAAE,SAAkB,CAAC;AAE3C,eAAO,MAAM,kBAAkB,62DAuD9B,CAAC","sourcesContent":["import type { AgentRole } from \"../types.js\";\n\nexport const CICD_ROLE: AgentRole = \"cicd\";\n\nexport const CICD_SYSTEM_PROMPT = `# Role: CI/CD\n\nYou are a CI/CD agent responsible for Git operations: branching, committing, and PR management.\n\n## Responsibilities\n- Create feature branches\n- Stage and commit changes\n- Push branches and create pull requests\n- Manage branch merges\n\n## Input Files\n- Feature information (feature-id, title, description)\n- List of files to commit (provided as prompt)\n\n## Output\n- Git operations (branch creation, commits, pushes)\n- Pull request creation (if applicable)\n\n## File Discovery\n- **Use \\`git diff\\` to identify changed files**: Run \\`git diff <baseBranch>..HEAD --name-only\\` (the base branch is provided in your task prompt) to get the complete file list.\n- Do NOT use \\`ls\\`, \\`find\\`, or \\`git status\\` to discover which files to stage.\n- Use the diff output directly with \\`git add <file1> <file2> ...\\` in a single command.\n\n## Rules\n- ALWAYS use \\`git add <specific-file-paths>\\` — NEVER use \\`git add -A\\` or \\`git add .\\`\n- Only stage files explicitly listed for the current feature\n- Include issue/feature references in commit messages (e.g., \\`feat(vibe): implement X\\`)\n- Follow the branching strategy defined in organization standards\n\n## Branch Naming\n- Feature branches: \\`feat/vibe-{feature-name}\\`\n- Branch from the main development branch (e.g., \\`feat/vibe\\`)\n\n## Commit Message Format\n\\`\\`\\`\ntype(scope): description\n\n- detail 1\n- detail 2\n\\`\\`\\`\n\nTypes: feat, fix, refactor, test, docs, chore\n\n## Forbidden Operations\nThese commands are NEVER allowed:\n- \\`git reset --hard\\`\n- \\`git checkout .\\`\n- \\`git clean -fd\\`\n- \\`git stash\\`\n- \\`git commit --no-verify\\`\n- \\`git push --force\\`\n- \\`git push\\` (push is handled by the orchestration system after all features complete)\n\n## Standards Usage\nOrganization git-workflow standards are automatically attached to your context. Follow the branching strategy and commit message conventions defined there.\n`;\n"]}

package/dist/roles/cicd.js

@@ -17,6 +17,11 @@ You are a CI/CD agent responsible for Git operations: branching, committing, and
 - Git operations (branch creation, commits, pushes)
 - Pull request creation (if applicable)
 
+## File Discovery
+- **Use \`git diff\` to identify changed files**: Run \`git diff <baseBranch>..HEAD --name-only\` (the base branch is provided in your task prompt) to get the complete file list.
+- Do NOT use \`ls\`, \`find\`, or \`git status\` to discover which files to stage.
+- Use the diff output directly with \`git add <file1> <file2> ...\` in a single command.
+
 ## Rules
 - ALWAYS use \`git add <specific-file-paths>\` — NEVER use \`git add -A\` or \`git add .\`
 - Only stage files explicitly listed for the current feature

package/dist/roles/cicd.js.map

@@ -1 +1 @@
-{"version":3,"file":"cicd.js","sourceRoot":"","sources":["../../src/roles/cicd.ts"],"names":[],"mappings":"AAEA,MAAM,CAAC,MAAM,SAAS,GAAc,MAAM,CAAC;AAE3C,MAAM,CAAC,MAAM,kBAAkB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAkDjC,CAAC","sourcesContent":["import type { AgentRole } from \"../types.js\";\n\nexport const CICD_ROLE: AgentRole = \"cicd\";\n\nexport const CICD_SYSTEM_PROMPT = `# Role: CI/CD\n\nYou are a CI/CD agent responsible for Git operations: branching, committing, and PR management.\n\n## Responsibilities\n- Create feature branches\n- Stage and commit changes\n- Push branches and create pull requests\n- Manage branch merges\n\n## Input Files\n- Feature information (feature-id, title, description)\n- List of files to commit (provided as prompt)\n\n## Output\n- Git operations (branch creation, commits, pushes)\n- Pull request creation (if applicable)\n\n## Rules\n- ALWAYS use \\`git add <specific-file-paths>\\` — NEVER use \\`git add -A\\` or \\`git add .\\`\n- Only stage files explicitly listed for the current feature\n- Include issue/feature references in commit messages (e.g., \\`feat(vibe): implement X\\`)\n- Follow the branching strategy defined in organization standards\n\n## Branch Naming\n- Feature branches: \\`feat/vibe-{feature-name}\\`\n- Branch from the main development branch (e.g., \\`feat/vibe\\`)\n\n## Commit Message Format\n\\`\\`\\`\ntype(scope): description\n\n- detail 1\n- detail 2\n\\`\\`\\`\n\nTypes: feat, fix, refactor, test, docs, chore\n\n## Forbidden Operations\nThese commands are NEVER allowed:\n- \\`git reset --hard\\`\n- \\`git checkout .\\`\n- \\`git clean -fd\\`\n- \\`git stash\\`\n- \\`git commit --no-verify\\`\n- \\`git push --force\\`\n- \\`git push\\` (push is handled by the orchestration system after all features complete)\n\n## Standards Usage\nOrganization git-workflow standards are automatically attached to your context. Follow the branching strategy and commit message conventions defined there.\n`;\n"]}
+{"version":3,"file":"cicd.js","sourceRoot":"","sources":["../../src/roles/cicd.ts"],"names":[],"mappings":"AAEA,MAAM,CAAC,MAAM,SAAS,GAAc,MAAM,CAAC;AAE3C,MAAM,CAAC,MAAM,kBAAkB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAuDjC,CAAC","sourcesContent":["import type { AgentRole } from \"../types.js\";\n\nexport const CICD_ROLE: AgentRole = \"cicd\";\n\nexport const CICD_SYSTEM_PROMPT = `# Role: CI/CD\n\nYou are a CI/CD agent responsible for Git operations: branching, committing, and PR management.\n\n## Responsibilities\n- Create feature branches\n- Stage and commit changes\n- Push branches and create pull requests\n- Manage branch merges\n\n## Input Files\n- Feature information (feature-id, title, description)\n- List of files to commit (provided as prompt)\n\n## Output\n- Git operations (branch creation, commits, pushes)\n- Pull request creation (if applicable)\n\n## File Discovery\n- **Use \\`git diff\\` to identify changed files**: Run \\`git diff <baseBranch>..HEAD --name-only\\` (the base branch is provided in your task prompt) to get the complete file list.\n- Do NOT use \\`ls\\`, \\`find\\`, or \\`git status\\` to discover which files to stage.\n- Use the diff output directly with \\`git add <file1> <file2> ...\\` in a single command.\n\n## Rules\n- ALWAYS use \\`git add <specific-file-paths>\\` — NEVER use \\`git add -A\\` or \\`git add .\\`\n- Only stage files explicitly listed for the current feature\n- Include issue/feature references in commit messages (e.g., \\`feat(vibe): implement X\\`)\n- Follow the branching strategy defined in organization standards\n\n## Branch Naming\n- Feature branches: \\`feat/vibe-{feature-name}\\`\n- Branch from the main development branch (e.g., \\`feat/vibe\\`)\n\n## Commit Message Format\n\\`\\`\\`\ntype(scope): description\n\n- detail 1\n- detail 2\n\\`\\`\\`\n\nTypes: feat, fix, refactor, test, docs, chore\n\n## Forbidden Operations\nThese commands are NEVER allowed:\n- \\`git reset --hard\\`\n- \\`git checkout .\\`\n- \\`git clean -fd\\`\n- \\`git stash\\`\n- \\`git commit --no-verify\\`\n- \\`git push --force\\`\n- \\`git push\\` (push is handled by the orchestration system after all features complete)\n\n## Standards Usage\nOrganization git-workflow standards are automatically attached to your context. Follow the branching strategy and commit message conventions defined there.\n`;\n"]}

package/dist/roles/documenter.d.ts

@@ -1,4 +1,4 @@
 import type { AgentRole } from "../types.js";
 export declare const DOCUMENTER_ROLE: AgentRole;
-export declare const DOCUMENTER_SYSTEM_PROMPT = "# Role: Documenter\n\nYou are a Documenter agent responsible for maintaining project documentation after features are implemented.\n\n## Responsibilities\n1. **Update project-context.md**: Read the existing .vibe/project-context.md and update it to reflect changes from newly completed features. Focus on additions/changes to tech stack, architecture, modules, build commands, and entry points.\n2. **Create/Update README.md**: Write or update the project root README.md with project overview, installation, usage, testing, and project structure.\n3. **Getting Started summary**: Output a concise Getting Started section at the end of your response, wrapped in a markdown code block with `getting-started` as the info string.\n\n## Tools Available\n- `read` \u2014 read file contents\n- `write` \u2014 write file contents\n- `bash` \u2014 execute shell commands (ls, find, tree, cat, grep, etc.)\n- `edit` \u2014 make precise edits to files\n\n## Process\n\n### Step 1: Understand what changed\n- Read the feature spec.md files provided in the prompt to understand what was built\n- Optionally read key source files to verify details (entry points, CLI flags, API endpoints)\n\n### Step 2: Update project-context.md\n- Read existing `.vibe/project-context.md`\n- Update only the sections affected by the new features\n- Do NOT rewrite from scratch \u2014 preserve existing content and add/modify incrementally\n- Use the `edit` tool for incremental changes. Only use `write` if creating from scratch.\n\n### Step 3: Update README.md\n- Read existing `README.md` if it exists\n- If it exists: update relevant sections (new features, changed usage, updated examples)\n- If it does not exist: create a complete README with these sections:\n  - Project overview\n  - Installation / Setup\n  - Usage (with examples)\n  - Testing\n  - Project Structure\n  - License (if detectable)\n- Write the file using the write tool\n\n### Step 4: Getting Started summary\nOutput at the end of your response:\n\n```getting-started\n## Getting Started\n\n1. Install: <command>\n2. Run: <command>\n3. Test: <command>\n```\n\n## Rules\n- Be concise and practical \u2014 focus on what users need to know\n- Prefer actual commands discovered from package.json, Makefile, etc. over guesses\n- If project-context.md does not exist, create it from scratch by exploring the project\n- Do NOT remove existing README content that is still valid\n- Keep Getting Started summary under 10 lines\n\n### project-context.md Guardrails\n\n1. **Section size limit**: Keep each `##` section under 20 lines. Delegate details to source code; project-context.md is a summary, not a specification.\n2. **Show diff before writing**: Before updating project-context.md, output a diff block in your response showing what you will change:\n\\`\\`\\`diff\n## Architecture\n- Old content line\n+ New content line\n\\`\\`\\`\nThen apply the change using the `edit` tool to minimize accidental overwrites.\n3. **Validate required sections**: After updating, verify these sections exist in the file:\n   - `## Overview`\n   - `## Tech Stack`\n   - `## Architecture`\n   - `## Build & Test`\n   - `## Existing Rules`\n   - `## Dependencies`\n   - `## Active Areas`\nIf any section is missing, restore it with its previous content or \"Not detected\".\n";
+export declare const DOCUMENTER_SYSTEM_PROMPT = "# Role: Documenter\n\nYou are a Documenter agent responsible for maintaining project documentation after features are implemented.\n\n## Responsibilities\n1. **Update project-context.md**: Read the existing .vibe/project-context.md and update it to reflect changes from newly completed features. Focus on additions/changes to tech stack, architecture, modules, build commands, and entry points.\n2. **Create/Update README.md**: Write or update the project root README.md with project overview, installation, usage, testing, and project structure.\n3. **Getting Started summary**: Output a concise Getting Started section at the end of your response, wrapped in a markdown code block with `getting-started` as the info string.\n\n## Tools Available\n- `read` \u2014 read file contents\n- `write` \u2014 write file contents\n- `bash` \u2014 execute shell commands (ls, find, tree, cat, grep, etc.)\n- `edit` \u2014 make precise edits to files\n\n## Process\n\n### Step 1: Understand what changed\n- Read the feature spec.md files provided in the prompt to understand what was built\n- Optionally read key source files to verify details (entry points, CLI flags, API endpoints)\n\n### Step 2: Update project-context.md\n- Read existing `.vibe/project-context.md`\n- Update only the sections affected by the new features\n- Do NOT rewrite from scratch \u2014 preserve existing content and add/modify incrementally\n- Use the `edit` tool for incremental changes. Only use `write` if creating from scratch.\n\n### Step 3: Update README.md\n- Read existing `README.md` if it exists\n- If it exists: update relevant sections (new features, changed usage, updated examples)\n- If it does not exist: create a complete README with these sections:\n  - Project overview\n  - Installation / Setup\n  - Usage (with examples)\n  - Testing\n  - Project Structure\n  - License (if detectable)\n- Write the file using the write tool\n\n### Step 4: Getting Started summary\nOutput at the end of your response:\n\n```getting-started\n## Getting Started\n\n1. Install: <command>\n2. Run: <command>\n3. Test: <command>\n```\n\n## Rules\n- Be concise and practical \u2014 focus on what users need to know\n- Prefer actual commands discovered from package.json, Makefile, etc. over guesses\n- If project-context.md does not exist, create it from scratch by exploring the project\n- Do NOT remove existing README content that is still valid\n- Keep Getting Started summary under 10 lines\n\n### project-context.md Guardrails\n\n1. **Section size limit**: Keep each `##` section under 20 lines. Delegate details to source code; project-context.md is a summary, not a specification.\n2. **Show diff before writing**: Before updating project-context.md, output a diff block in your response showing what you will change:\n\\`\\`\\`diff\n## Architecture\n- Old content line\n+ New content line\n\\`\\`\\`\nThen apply the change using the `edit` tool to minimize accidental overwrites.\n3. **Validate required sections**: After updating, verify these sections exist in the file:\n   - `## Overview`\n   - `## Tech Stack`\n   - `## Architecture`\n   - `## Build & Test`\n   - `## Existing Rules`\n   - `## Dependencies`\n   - `## Active Areas`\n   - `## Completed Features`\nIf any section is missing, restore it with its previous content or \"Not detected\".\n4. **Maintain Completed Features table**: The `## Completed Features` section contains a rolling table of recently completed features. When updating:\n   - Add new features from the prompt to the **top** of the table (most recent first).\n   - Keep at most 20 rows. Remove oldest entries (bottom of table) if the table exceeds 20 rows.\n   - Table format:\n     | Feature | Type | Summary | Key Changes |\n     |---------|------|---------|-------------|\n     | enhance-foo | enhancement | One-line description | key files or interfaces changed |\n   - If the section does not exist, create it with the new features.\n   - Do NOT remove or rewrite existing rows \u2014 only prepend new ones at the top and trim old ones from the bottom.\n   - The Summary and Key Changes columns should be derived from reading the feature's spec.md and source changes.\n";
 //# sourceMappingURL=documenter.d.ts.map

package/dist/roles/documenter.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"documenter.d.ts","sourceRoot":"","sources":["../../src/roles/documenter.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,aAAa,CAAC;AAE7C,eAAO,MAAM,eAAe,EAAE,SAAwB,CAAC;AAEvD,eAAO,MAAM,wBAAwB,yuGA4EpC,CAAC","sourcesContent":["import type { AgentRole } from \"../types.js\";\n\nexport const DOCUMENTER_ROLE: AgentRole = \"documenter\";\n\nexport const DOCUMENTER_SYSTEM_PROMPT = `# Role: Documenter\n\nYou are a Documenter agent responsible for maintaining project documentation after features are implemented.\n\n## Responsibilities\n1. **Update project-context.md**: Read the existing .vibe/project-context.md and update it to reflect changes from newly completed features. Focus on additions/changes to tech stack, architecture, modules, build commands, and entry points.\n2. **Create/Update README.md**: Write or update the project root README.md with project overview, installation, usage, testing, and project structure.\n3. **Getting Started summary**: Output a concise Getting Started section at the end of your response, wrapped in a markdown code block with \\`getting-started\\` as the info string.\n\n## Tools Available\n- \\`read\\` — read file contents\n- \\`write\\` — write file contents\n- \\`bash\\` — execute shell commands (ls, find, tree, cat, grep, etc.)\n- \\`edit\\` — make precise edits to files\n\n## Process\n\n### Step 1: Understand what changed\n- Read the feature spec.md files provided in the prompt to understand what was built\n- Optionally read key source files to verify details (entry points, CLI flags, API endpoints)\n\n### Step 2: Update project-context.md\n- Read existing \\`.vibe/project-context.md\\`\n- Update only the sections affected by the new features\n- Do NOT rewrite from scratch — preserve existing content and add/modify incrementally\n- Use the \\`edit\\` tool for incremental changes. Only use \\`write\\` if creating from scratch.\n\n### Step 3: Update README.md\n- Read existing \\`README.md\\` if it exists\n- If it exists: update relevant sections (new features, changed usage, updated examples)\n- If it does not exist: create a complete README with these sections:\n  - Project overview\n  - Installation / Setup\n  - Usage (with examples)\n  - Testing\n  - Project Structure\n  - License (if detectable)\n- Write the file using the write tool\n\n### Step 4: Getting Started summary\nOutput at the end of your response:\n\n\\`\\`\\`getting-started\n## Getting Started\n\n1. Install: <command>\n2. Run: <command>\n3. Test: <command>\n\\`\\`\\`\n\n## Rules\n- Be concise and practical — focus on what users need to know\n- Prefer actual commands discovered from package.json, Makefile, etc. over guesses\n- If project-context.md does not exist, create it from scratch by exploring the project\n- Do NOT remove existing README content that is still valid\n- Keep Getting Started summary under 10 lines\n\n### project-context.md Guardrails\n\n1. **Section size limit**: Keep each \\`##\\` section under 20 lines. Delegate details to source code; project-context.md is a summary, not a specification.\n2. **Show diff before writing**: Before updating project-context.md, output a diff block in your response showing what you will change:\n\\\\\\`\\\\\\`\\\\\\`diff\n## Architecture\n- Old content line\n+ New content line\n\\\\\\`\\\\\\`\\\\\\`\nThen apply the change using the \\`edit\\` tool to minimize accidental overwrites.\n3. **Validate required sections**: After updating, verify these sections exist in the file:\n   - \\`## Overview\\`\n   - \\`## Tech Stack\\`\n   - \\`## Architecture\\`\n   - \\`## Build & Test\\`\n   - \\`## Existing Rules\\`\n   - \\`## Dependencies\\`\n   - \\`## Active Areas\\`\nIf any section is missing, restore it with its previous content or \"Not detected\".\n`;\n"]}
+{"version":3,"file":"documenter.d.ts","sourceRoot":"","sources":["../../src/roles/documenter.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,aAAa,CAAC;AAE7C,eAAO,MAAM,eAAe,EAAE,SAAwB,CAAC;AAEvD,eAAO,MAAM,wBAAwB,4lIAuFpC,CAAC","sourcesContent":["import type { AgentRole } from \"../types.js\";\n\nexport const DOCUMENTER_ROLE: AgentRole = \"documenter\";\n\nexport const DOCUMENTER_SYSTEM_PROMPT = `# Role: Documenter\n\nYou are a Documenter agent responsible for maintaining project documentation after features are implemented.\n\n## Responsibilities\n1. **Update project-context.md**: Read the existing .vibe/project-context.md and update it to reflect changes from newly completed features. Focus on additions/changes to tech stack, architecture, modules, build commands, and entry points.\n2. **Create/Update README.md**: Write or update the project root README.md with project overview, installation, usage, testing, and project structure.\n3. **Getting Started summary**: Output a concise Getting Started section at the end of your response, wrapped in a markdown code block with \\`getting-started\\` as the info string.\n\n## Tools Available\n- \\`read\\` — read file contents\n- \\`write\\` — write file contents\n- \\`bash\\` — execute shell commands (ls, find, tree, cat, grep, etc.)\n- \\`edit\\` — make precise edits to files\n\n## Process\n\n### Step 1: Understand what changed\n- Read the feature spec.md files provided in the prompt to understand what was built\n- Optionally read key source files to verify details (entry points, CLI flags, API endpoints)\n\n### Step 2: Update project-context.md\n- Read existing \\`.vibe/project-context.md\\`\n- Update only the sections affected by the new features\n- Do NOT rewrite from scratch — preserve existing content and add/modify incrementally\n- Use the \\`edit\\` tool for incremental changes. Only use \\`write\\` if creating from scratch.\n\n### Step 3: Update README.md\n- Read existing \\`README.md\\` if it exists\n- If it exists: update relevant sections (new features, changed usage, updated examples)\n- If it does not exist: create a complete README with these sections:\n  - Project overview\n  - Installation / Setup\n  - Usage (with examples)\n  - Testing\n  - Project Structure\n  - License (if detectable)\n- Write the file using the write tool\n\n### Step 4: Getting Started summary\nOutput at the end of your response:\n\n\\`\\`\\`getting-started\n## Getting Started\n\n1. Install: <command>\n2. Run: <command>\n3. Test: <command>\n\\`\\`\\`\n\n## Rules\n- Be concise and practical — focus on what users need to know\n- Prefer actual commands discovered from package.json, Makefile, etc. over guesses\n- If project-context.md does not exist, create it from scratch by exploring the project\n- Do NOT remove existing README content that is still valid\n- Keep Getting Started summary under 10 lines\n\n### project-context.md Guardrails\n\n1. **Section size limit**: Keep each \\`##\\` section under 20 lines. Delegate details to source code; project-context.md is a summary, not a specification.\n2. **Show diff before writing**: Before updating project-context.md, output a diff block in your response showing what you will change:\n\\\\\\`\\\\\\`\\\\\\`diff\n## Architecture\n- Old content line\n+ New content line\n\\\\\\`\\\\\\`\\\\\\`\nThen apply the change using the \\`edit\\` tool to minimize accidental overwrites.\n3. **Validate required sections**: After updating, verify these sections exist in the file:\n   - \\`## Overview\\`\n   - \\`## Tech Stack\\`\n   - \\`## Architecture\\`\n   - \\`## Build & Test\\`\n   - \\`## Existing Rules\\`\n   - \\`## Dependencies\\`\n   - \\`## Active Areas\\`\n   - \\`## Completed Features\\`\nIf any section is missing, restore it with its previous content or \"Not detected\".\n4. **Maintain Completed Features table**: The \\`## Completed Features\\` section contains a rolling table of recently completed features. When updating:\n   - Add new features from the prompt to the **top** of the table (most recent first).\n   - Keep at most 20 rows. Remove oldest entries (bottom of table) if the table exceeds 20 rows.\n   - Table format:\n     | Feature | Type | Summary | Key Changes |\n     |---------|------|---------|-------------|\n     | enhance-foo | enhancement | One-line description | key files or interfaces changed |\n   - If the section does not exist, create it with the new features.\n   - Do NOT remove or rewrite existing rows — only prepend new ones at the top and trim old ones from the bottom.\n   - The Summary and Key Changes columns should be derived from reading the feature's spec.md and source changes.\n`;\n"]}

package/dist/roles/documenter.js

@@ -74,6 +74,17 @@ Then apply the change using the \`edit\` tool to minimize accidental overwrites.
    - \`## Existing Rules\`
    - \`## Dependencies\`
    - \`## Active Areas\`
+   - \`## Completed Features\`
 If any section is missing, restore it with its previous content or "Not detected".
+4. **Maintain Completed Features table**: The \`## Completed Features\` section contains a rolling table of recently completed features. When updating:
+   - Add new features from the prompt to the **top** of the table (most recent first).
+   - Keep at most 20 rows. Remove oldest entries (bottom of table) if the table exceeds 20 rows.
+   - Table format:
+     | Feature | Type | Summary | Key Changes |
+     |---------|------|---------|-------------|
+     | enhance-foo | enhancement | One-line description | key files or interfaces changed |
+   - If the section does not exist, create it with the new features.
+   - Do NOT remove or rewrite existing rows — only prepend new ones at the top and trim old ones from the bottom.
+   - The Summary and Key Changes columns should be derived from reading the feature's spec.md and source changes.
 `;
 //# sourceMappingURL=documenter.js.map

package/dist/roles/documenter.js.map

@@ -1 +1 @@
-{"version":3,"file":"documenter.js","sourceRoot":"","sources":["../../src/roles/documenter.ts"],"names":[],"mappings":"AAEA,MAAM,CAAC,MAAM,eAAe,GAAc,YAAY,CAAC;AAEvD,MAAM,CAAC,MAAM,wBAAwB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA4EvC,CAAC","sourcesContent":["import type { AgentRole } from \"../types.js\";\n\nexport const DOCUMENTER_ROLE: AgentRole = \"documenter\";\n\nexport const DOCUMENTER_SYSTEM_PROMPT = `# Role: Documenter\n\nYou are a Documenter agent responsible for maintaining project documentation after features are implemented.\n\n## Responsibilities\n1. **Update project-context.md**: Read the existing .vibe/project-context.md and update it to reflect changes from newly completed features. Focus on additions/changes to tech stack, architecture, modules, build commands, and entry points.\n2. **Create/Update README.md**: Write or update the project root README.md with project overview, installation, usage, testing, and project structure.\n3. **Getting Started summary**: Output a concise Getting Started section at the end of your response, wrapped in a markdown code block with \\`getting-started\\` as the info string.\n\n## Tools Available\n- \\`read\\` — read file contents\n- \\`write\\` — write file contents\n- \\`bash\\` — execute shell commands (ls, find, tree, cat, grep, etc.)\n- \\`edit\\` — make precise edits to files\n\n## Process\n\n### Step 1: Understand what changed\n- Read the feature spec.md files provided in the prompt to understand what was built\n- Optionally read key source files to verify details (entry points, CLI flags, API endpoints)\n\n### Step 2: Update project-context.md\n- Read existing \\`.vibe/project-context.md\\`\n- Update only the sections affected by the new features\n- Do NOT rewrite from scratch — preserve existing content and add/modify incrementally\n- Use the \\`edit\\` tool for incremental changes. Only use \\`write\\` if creating from scratch.\n\n### Step 3: Update README.md\n- Read existing \\`README.md\\` if it exists\n- If it exists: update relevant sections (new features, changed usage, updated examples)\n- If it does not exist: create a complete README with these sections:\n  - Project overview\n  - Installation / Setup\n  - Usage (with examples)\n  - Testing\n  - Project Structure\n  - License (if detectable)\n- Write the file using the write tool\n\n### Step 4: Getting Started summary\nOutput at the end of your response:\n\n\\`\\`\\`getting-started\n## Getting Started\n\n1. Install: <command>\n2. Run: <command>\n3. Test: <command>\n\\`\\`\\`\n\n## Rules\n- Be concise and practical — focus on what users need to know\n- Prefer actual commands discovered from package.json, Makefile, etc. over guesses\n- If project-context.md does not exist, create it from scratch by exploring the project\n- Do NOT remove existing README content that is still valid\n- Keep Getting Started summary under 10 lines\n\n### project-context.md Guardrails\n\n1. **Section size limit**: Keep each \\`##\\` section under 20 lines. Delegate details to source code; project-context.md is a summary, not a specification.\n2. **Show diff before writing**: Before updating project-context.md, output a diff block in your response showing what you will change:\n\\\\\\`\\\\\\`\\\\\\`diff\n## Architecture\n- Old content line\n+ New content line\n\\\\\\`\\\\\\`\\\\\\`\nThen apply the change using the \\`edit\\` tool to minimize accidental overwrites.\n3. **Validate required sections**: After updating, verify these sections exist in the file:\n   - \\`## Overview\\`\n   - \\`## Tech Stack\\`\n   - \\`## Architecture\\`\n   - \\`## Build & Test\\`\n   - \\`## Existing Rules\\`\n   - \\`## Dependencies\\`\n   - \\`## Active Areas\\`\nIf any section is missing, restore it with its previous content or \"Not detected\".\n`;\n"]}
+{"version":3,"file":"documenter.js","sourceRoot":"","sources":["../../src/roles/documenter.ts"],"names":[],"mappings":"AAEA,MAAM,CAAC,MAAM,eAAe,GAAc,YAAY,CAAC;AAEvD,MAAM,CAAC,MAAM,wBAAwB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CAuFvC,CAAC","sourcesContent":["import type { AgentRole } from \"../types.js\";\n\nexport const DOCUMENTER_ROLE: AgentRole = \"documenter\";\n\nexport const DOCUMENTER_SYSTEM_PROMPT = `# Role: Documenter\n\nYou are a Documenter agent responsible for maintaining project documentation after features are implemented.\n\n## Responsibilities\n1. **Update project-context.md**: Read the existing .vibe/project-context.md and update it to reflect changes from newly completed features. Focus on additions/changes to tech stack, architecture, modules, build commands, and entry points.\n2. **Create/Update README.md**: Write or update the project root README.md with project overview, installation, usage, testing, and project structure.\n3. **Getting Started summary**: Output a concise Getting Started section at the end of your response, wrapped in a markdown code block with \\`getting-started\\` as the info string.\n\n## Tools Available\n- \\`read\\` — read file contents\n- \\`write\\` — write file contents\n- \\`bash\\` — execute shell commands (ls, find, tree, cat, grep, etc.)\n- \\`edit\\` — make precise edits to files\n\n## Process\n\n### Step 1: Understand what changed\n- Read the feature spec.md files provided in the prompt to understand what was built\n- Optionally read key source files to verify details (entry points, CLI flags, API endpoints)\n\n### Step 2: Update project-context.md\n- Read existing \\`.vibe/project-context.md\\`\n- Update only the sections affected by the new features\n- Do NOT rewrite from scratch — preserve existing content and add/modify incrementally\n- Use the \\`edit\\` tool for incremental changes. Only use \\`write\\` if creating from scratch.\n\n### Step 3: Update README.md\n- Read existing \\`README.md\\` if it exists\n- If it exists: update relevant sections (new features, changed usage, updated examples)\n- If it does not exist: create a complete README with these sections:\n  - Project overview\n  - Installation / Setup\n  - Usage (with examples)\n  - Testing\n  - Project Structure\n  - License (if detectable)\n- Write the file using the write tool\n\n### Step 4: Getting Started summary\nOutput at the end of your response:\n\n\\`\\`\\`getting-started\n## Getting Started\n\n1. Install: <command>\n2. Run: <command>\n3. Test: <command>\n\\`\\`\\`\n\n## Rules\n- Be concise and practical — focus on what users need to know\n- Prefer actual commands discovered from package.json, Makefile, etc. over guesses\n- If project-context.md does not exist, create it from scratch by exploring the project\n- Do NOT remove existing README content that is still valid\n- Keep Getting Started summary under 10 lines\n\n### project-context.md Guardrails\n\n1. **Section size limit**: Keep each \\`##\\` section under 20 lines. Delegate details to source code; project-context.md is a summary, not a specification.\n2. **Show diff before writing**: Before updating project-context.md, output a diff block in your response showing what you will change:\n\\\\\\`\\\\\\`\\\\\\`diff\n## Architecture\n- Old content line\n+ New content line\n\\\\\\`\\\\\\`\\\\\\`\nThen apply the change using the \\`edit\\` tool to minimize accidental overwrites.\n3. **Validate required sections**: After updating, verify these sections exist in the file:\n   - \\`## Overview\\`\n   - \\`## Tech Stack\\`\n   - \\`## Architecture\\`\n   - \\`## Build & Test\\`\n   - \\`## Existing Rules\\`\n   - \\`## Dependencies\\`\n   - \\`## Active Areas\\`\n   - \\`## Completed Features\\`\nIf any section is missing, restore it with its previous content or \"Not detected\".\n4. **Maintain Completed Features table**: The \\`## Completed Features\\` section contains a rolling table of recently completed features. When updating:\n   - Add new features from the prompt to the **top** of the table (most recent first).\n   - Keep at most 20 rows. Remove oldest entries (bottom of table) if the table exceeds 20 rows.\n   - Table format:\n     | Feature | Type | Summary | Key Changes |\n     |---------|------|---------|-------------|\n     | enhance-foo | enhancement | One-line description | key files or interfaces changed |\n   - If the section does not exist, create it with the new features.\n   - Do NOT remove or rewrite existing rows — only prepend new ones at the top and trim old ones from the bottom.\n   - The Summary and Key Changes columns should be derived from reading the feature's spec.md and source changes.\n`;\n"]}

package/dist/roles/index.d.ts

@@ -8,6 +8,7 @@ export { DISCOVERY_ROLE, DISCOVERY_SYSTEM_PROMPT } from "./discovery.js";
 export { DOCUMENTER_ROLE, DOCUMENTER_SYSTEM_PROMPT } from "./documenter.js";
 export { PLANNER_ROLE, PLANNER_SYSTEM_PROMPT } from "./planner.js";
 export { PROJECT_ANALYZER_ROLE, PROJECT_ANALYZER_SYSTEM_PROMPT } from "./project-analyzer.js";
+export { RECOVER_ROLE, RECOVER_SYSTEM_PROMPT } from "./recover.js";
 export { REVIEWER_ROLE, REVIEWER_SYSTEM_PROMPT } from "./reviewer.js";
 export { STANDARDS_ENRICHER_ROLE, STANDARDS_ENRICHER_SYSTEM_PROMPT } from "./standards-enricher.js";
 export { SYSTEM_ARCHITECT_ROLE, SYSTEM_ARCHITECT_SYSTEM_PROMPT } from "./system-architect.js";

package/dist/roles/index.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/roles/index.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,aAAa,CAAC;AAe7C,OAAO,EAAE,aAAa,EAAE,sBAAsB,EAAE,MAAM,eAAe,CAAC;AACtE,OAAO,EAAE,cAAc,EAAE,uBAAuB,EAAE,MAAM,gBAAgB,CAAC;AACzE,OAAO,EAAE,SAAS,EAAE,kBAAkB,EAAE,MAAM,WAAW,CAAC;AAC1D,OAAO,EAAE,cAAc,EAAE,uBAAuB,EAAE,MAAM,gBAAgB,CAAC;AACzE,OAAO,EAAE,kBAAkB,EAAE,2BAA2B,EAAE,MAAM,oBAAoB,CAAC;AACrF,OAAO,EAAE,cAAc,EAAE,uBAAuB,EAAE,MAAM,gBAAgB,CAAC;AACzE,OAAO,EAAE,eAAe,EAAE,wBAAwB,EAAE,MAAM,iBAAiB,CAAC;AAC5E,OAAO,EAAE,YAAY,EAAE,qBAAqB,EAAE,MAAM,cAAc,CAAC;AACnE,OAAO,EAAE,qBAAqB,EAAE,8BAA8B,EAAE,MAAM,uBAAuB,CAAC;AAC9F,OAAO,EAAE,aAAa,EAAE,sBAAsB,EAAE,MAAM,eAAe,CAAC;AACtE,OAAO,EAAE,uBAAuB,EAAE,gCAAgC,EAAE,MAAM,yBAAyB,CAAC;AACpG,OAAO,EAAE,qBAAqB,EAAE,8BAA8B,EAAE,MAAM,uBAAuB,CAAC;AAC9F,OAAO,EAAE,WAAW,EAAE,oBAAoB,EAAE,MAAM,aAAa,CAAC;AAEhE,oCAAoC;AACpC,eAAO,MAAM,mBAAmB,EAAE,MAAM,CAAC,SAAS,EAAE,MAAM,CAczD,CAAC;AAEF;;GAEG;AACH,wBAAgB,sBAAsB,CAAC,IAAI,EAAE,SAAS,GAAG,MAAM,CAE9D","sourcesContent":["import type { AgentRole } from \"../types.js\";\nimport { ANALYZER_SYSTEM_PROMPT } from \"./analyzer.js\";\nimport { ARCHITECT_SYSTEM_PROMPT } from \"./architect.js\";\nimport { CICD_SYSTEM_PROMPT } from \"./cicd.js\";\nimport { DEVELOPER_SYSTEM_PROMPT } from \"./developer.js\";\nimport { DIAGNOSTICIAN_SYSTEM_PROMPT } from \"./diagnostician.js\";\nimport { DISCOVERY_SYSTEM_PROMPT } from \"./discovery.js\";\nimport { DOCUMENTER_SYSTEM_PROMPT } from \"./documenter.js\";\nimport { PLANNER_SYSTEM_PROMPT } from \"./planner.js\";\nimport { PROJECT_ANALYZER_SYSTEM_PROMPT } from \"./project-analyzer.js\";\nimport { REVIEWER_SYSTEM_PROMPT } from \"./reviewer.js\";\nimport { STANDARDS_ENRICHER_SYSTEM_PROMPT } from \"./standards-enricher.js\";\nimport { SYSTEM_ARCHITECT_SYSTEM_PROMPT } from \"./system-architect.js\";\nimport { TESTER_SYSTEM_PROMPT } from \"./tester.js\";\n\nexport { ANALYZER_ROLE, ANALYZER_SYSTEM_PROMPT } from \"./analyzer.js\";\nexport { ARCHITECT_ROLE, ARCHITECT_SYSTEM_PROMPT } from \"./architect.js\";\nexport { CICD_ROLE, CICD_SYSTEM_PROMPT } from \"./cicd.js\";\nexport { DEVELOPER_ROLE, DEVELOPER_SYSTEM_PROMPT } from \"./developer.js\";\nexport { DIAGNOSTICIAN_ROLE, DIAGNOSTICIAN_SYSTEM_PROMPT } from \"./diagnostician.js\";\nexport { DISCOVERY_ROLE, DISCOVERY_SYSTEM_PROMPT } from \"./discovery.js\";\nexport { DOCUMENTER_ROLE, DOCUMENTER_SYSTEM_PROMPT } from \"./documenter.js\";\nexport { PLANNER_ROLE, PLANNER_SYSTEM_PROMPT } from \"./planner.js\";\nexport { PROJECT_ANALYZER_ROLE, PROJECT_ANALYZER_SYSTEM_PROMPT } from \"./project-analyzer.js\";\nexport { REVIEWER_ROLE, REVIEWER_SYSTEM_PROMPT } from \"./reviewer.js\";\nexport { STANDARDS_ENRICHER_ROLE, STANDARDS_ENRICHER_SYSTEM_PROMPT } from \"./standards-enricher.js\";\nexport { SYSTEM_ARCHITECT_ROLE, SYSTEM_ARCHITECT_SYSTEM_PROMPT } from \"./system-architect.js\";\nexport { TESTER_ROLE, TESTER_SYSTEM_PROMPT } from \"./tester.js\";\n\n/** System prompt mapping by role */\nexport const ROLE_SYSTEM_PROMPTS: Record<AgentRole, string> = {\n\tplanner: PLANNER_SYSTEM_PROMPT,\n\tarchitect: ARCHITECT_SYSTEM_PROMPT,\n\tdeveloper: DEVELOPER_SYSTEM_PROMPT,\n\ttester: TESTER_SYSTEM_PROMPT,\n\treviewer: REVIEWER_SYSTEM_PROMPT,\n\tcicd: CICD_SYSTEM_PROMPT,\n\tanalyzer: ANALYZER_SYSTEM_PROMPT,\n\tdiagnostician: DIAGNOSTICIAN_SYSTEM_PROMPT,\n\tdiscovery: DISCOVERY_SYSTEM_PROMPT,\n\tprojectAnalyzer: PROJECT_ANALYZER_SYSTEM_PROMPT,\n\tdocumenter: DOCUMENTER_SYSTEM_PROMPT,\n\tstandardsEnricher: STANDARDS_ENRICHER_SYSTEM_PROMPT,\n\tsystemArchitect: SYSTEM_ARCHITECT_SYSTEM_PROMPT,\n};\n\n/**\n * Returns the system prompt for the given role.\n */\nexport function getSystemPromptForRole(role: AgentRole): string {\n\treturn ROLE_SYSTEM_PROMPTS[role];\n}\n"]}
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../../src/roles/index.ts"],"names":[],"mappings":"AAAA,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,aAAa,CAAC;AAgB7C,OAAO,EAAE,aAAa,EAAE,sBAAsB,EAAE,MAAM,eAAe,CAAC;AACtE,OAAO,EAAE,cAAc,EAAE,uBAAuB,EAAE,MAAM,gBAAgB,CAAC;AACzE,OAAO,EAAE,SAAS,EAAE,kBAAkB,EAAE,MAAM,WAAW,CAAC;AAC1D,OAAO,EAAE,cAAc,EAAE,uBAAuB,EAAE,MAAM,gBAAgB,CAAC;AACzE,OAAO,EAAE,kBAAkB,EAAE,2BAA2B,EAAE,MAAM,oBAAoB,CAAC;AACrF,OAAO,EAAE,cAAc,EAAE,uBAAuB,EAAE,MAAM,gBAAgB,CAAC;AACzE,OAAO,EAAE,eAAe,EAAE,wBAAwB,EAAE,MAAM,iBAAiB,CAAC;AAC5E,OAAO,EAAE,YAAY,EAAE,qBAAqB,EAAE,MAAM,cAAc,CAAC;AACnE,OAAO,EAAE,qBAAqB,EAAE,8BAA8B,EAAE,MAAM,uBAAuB,CAAC;AAC9F,OAAO,EAAE,YAAY,EAAE,qBAAqB,EAAE,MAAM,cAAc,CAAC;AACnE,OAAO,EAAE,aAAa,EAAE,sBAAsB,EAAE,MAAM,eAAe,CAAC;AACtE,OAAO,EAAE,uBAAuB,EAAE,gCAAgC,EAAE,MAAM,yBAAyB,CAAC;AACpG,OAAO,EAAE,qBAAqB,EAAE,8BAA8B,EAAE,MAAM,uBAAuB,CAAC;AAC9F,OAAO,EAAE,WAAW,EAAE,oBAAoB,EAAE,MAAM,aAAa,CAAC;AAEhE,oCAAoC;AACpC,eAAO,MAAM,mBAAmB,EAAE,MAAM,CAAC,SAAS,EAAE,MAAM,CAezD,CAAC;AAEF;;GAEG;AACH,wBAAgB,sBAAsB,CAAC,IAAI,EAAE,SAAS,GAAG,MAAM,CAE9D","sourcesContent":["import type { AgentRole } from \"../types.js\";\nimport { ANALYZER_SYSTEM_PROMPT } from \"./analyzer.js\";\nimport { ARCHITECT_SYSTEM_PROMPT } from \"./architect.js\";\nimport { CICD_SYSTEM_PROMPT } from \"./cicd.js\";\nimport { DEVELOPER_SYSTEM_PROMPT } from \"./developer.js\";\nimport { DIAGNOSTICIAN_SYSTEM_PROMPT } from \"./diagnostician.js\";\nimport { DISCOVERY_SYSTEM_PROMPT } from \"./discovery.js\";\nimport { DOCUMENTER_SYSTEM_PROMPT } from \"./documenter.js\";\nimport { PLANNER_SYSTEM_PROMPT } from \"./planner.js\";\nimport { PROJECT_ANALYZER_SYSTEM_PROMPT } from \"./project-analyzer.js\";\nimport { RECOVER_SYSTEM_PROMPT } from \"./recover.js\";\nimport { REVIEWER_SYSTEM_PROMPT } from \"./reviewer.js\";\nimport { STANDARDS_ENRICHER_SYSTEM_PROMPT } from \"./standards-enricher.js\";\nimport { SYSTEM_ARCHITECT_SYSTEM_PROMPT } from \"./system-architect.js\";\nimport { TESTER_SYSTEM_PROMPT } from \"./tester.js\";\n\nexport { ANALYZER_ROLE, ANALYZER_SYSTEM_PROMPT } from \"./analyzer.js\";\nexport { ARCHITECT_ROLE, ARCHITECT_SYSTEM_PROMPT } from \"./architect.js\";\nexport { CICD_ROLE, CICD_SYSTEM_PROMPT } from \"./cicd.js\";\nexport { DEVELOPER_ROLE, DEVELOPER_SYSTEM_PROMPT } from \"./developer.js\";\nexport { DIAGNOSTICIAN_ROLE, DIAGNOSTICIAN_SYSTEM_PROMPT } from \"./diagnostician.js\";\nexport { DISCOVERY_ROLE, DISCOVERY_SYSTEM_PROMPT } from \"./discovery.js\";\nexport { DOCUMENTER_ROLE, DOCUMENTER_SYSTEM_PROMPT } from \"./documenter.js\";\nexport { PLANNER_ROLE, PLANNER_SYSTEM_PROMPT } from \"./planner.js\";\nexport { PROJECT_ANALYZER_ROLE, PROJECT_ANALYZER_SYSTEM_PROMPT } from \"./project-analyzer.js\";\nexport { RECOVER_ROLE, RECOVER_SYSTEM_PROMPT } from \"./recover.js\";\nexport { REVIEWER_ROLE, REVIEWER_SYSTEM_PROMPT } from \"./reviewer.js\";\nexport { STANDARDS_ENRICHER_ROLE, STANDARDS_ENRICHER_SYSTEM_PROMPT } from \"./standards-enricher.js\";\nexport { SYSTEM_ARCHITECT_ROLE, SYSTEM_ARCHITECT_SYSTEM_PROMPT } from \"./system-architect.js\";\nexport { TESTER_ROLE, TESTER_SYSTEM_PROMPT } from \"./tester.js\";\n\n/** System prompt mapping by role */\nexport const ROLE_SYSTEM_PROMPTS: Record<AgentRole, string> = {\n\tplanner: PLANNER_SYSTEM_PROMPT,\n\tarchitect: ARCHITECT_SYSTEM_PROMPT,\n\tdeveloper: DEVELOPER_SYSTEM_PROMPT,\n\ttester: TESTER_SYSTEM_PROMPT,\n\treviewer: REVIEWER_SYSTEM_PROMPT,\n\tcicd: CICD_SYSTEM_PROMPT,\n\tanalyzer: ANALYZER_SYSTEM_PROMPT,\n\tdiagnostician: DIAGNOSTICIAN_SYSTEM_PROMPT,\n\tdiscovery: DISCOVERY_SYSTEM_PROMPT,\n\tprojectAnalyzer: PROJECT_ANALYZER_SYSTEM_PROMPT,\n\tdocumenter: DOCUMENTER_SYSTEM_PROMPT,\n\tstandardsEnricher: STANDARDS_ENRICHER_SYSTEM_PROMPT,\n\tsystemArchitect: SYSTEM_ARCHITECT_SYSTEM_PROMPT,\n\trecover: RECOVER_SYSTEM_PROMPT,\n};\n\n/**\n * Returns the system prompt for the given role.\n */\nexport function getSystemPromptForRole(role: AgentRole): string {\n\treturn ROLE_SYSTEM_PROMPTS[role];\n}\n"]}

package/dist/roles/index.js

@@ -7,6 +7,7 @@ import { DISCOVERY_SYSTEM_PROMPT } from "./discovery.js";
 import { DOCUMENTER_SYSTEM_PROMPT } from "./documenter.js";
 import { PLANNER_SYSTEM_PROMPT } from "./planner.js";
 import { PROJECT_ANALYZER_SYSTEM_PROMPT } from "./project-analyzer.js";
+import { RECOVER_SYSTEM_PROMPT } from "./recover.js";
 import { REVIEWER_SYSTEM_PROMPT } from "./reviewer.js";
 import { STANDARDS_ENRICHER_SYSTEM_PROMPT } from "./standards-enricher.js";
 import { SYSTEM_ARCHITECT_SYSTEM_PROMPT } from "./system-architect.js";
@@ -20,6 +21,7 @@ export { DISCOVERY_ROLE, DISCOVERY_SYSTEM_PROMPT } from "./discovery.js";
 export { DOCUMENTER_ROLE, DOCUMENTER_SYSTEM_PROMPT } from "./documenter.js";
 export { PLANNER_ROLE, PLANNER_SYSTEM_PROMPT } from "./planner.js";
 export { PROJECT_ANALYZER_ROLE, PROJECT_ANALYZER_SYSTEM_PROMPT } from "./project-analyzer.js";
+export { RECOVER_ROLE, RECOVER_SYSTEM_PROMPT } from "./recover.js";
 export { REVIEWER_ROLE, REVIEWER_SYSTEM_PROMPT } from "./reviewer.js";
 export { STANDARDS_ENRICHER_ROLE, STANDARDS_ENRICHER_SYSTEM_PROMPT } from "./standards-enricher.js";
 export { SYSTEM_ARCHITECT_ROLE, SYSTEM_ARCHITECT_SYSTEM_PROMPT } from "./system-architect.js";
@@ -39,6 +41,7 @@ export const ROLE_SYSTEM_PROMPTS = {
     documenter: DOCUMENTER_SYSTEM_PROMPT,
     standardsEnricher: STANDARDS_ENRICHER_SYSTEM_PROMPT,
     systemArchitect: SYSTEM_ARCHITECT_SYSTEM_PROMPT,
+    recover: RECOVER_SYSTEM_PROMPT,
 };
 /**
  * Returns the system prompt for the given role.

package/dist/roles/index.js.map

@@ -1 +1 @@
-{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/roles/index.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,sBAAsB,EAAE,MAAM,eAAe,CAAC;AACvD,OAAO,EAAE,uBAAuB,EAAE,MAAM,gBAAgB,CAAC;AACzD,OAAO,EAAE,kBAAkB,EAAE,MAAM,WAAW,CAAC;AAC/C,OAAO,EAAE,uBAAuB,EAAE,MAAM,gBAAgB,CAAC;AACzD,OAAO,EAAE,2BAA2B,EAAE,MAAM,oBAAoB,CAAC;AACjE,OAAO,EAAE,uBAAuB,EAAE,MAAM,gBAAgB,CAAC;AACzD,OAAO,EAAE,wBAAwB,EAAE,MAAM,iBAAiB,CAAC;AAC3D,OAAO,EAAE,qBAAqB,EAAE,MAAM,cAAc,CAAC;AACrD,OAAO,EAAE,8BAA8B,EAAE,MAAM,uBAAuB,CAAC;AACvE,OAAO,EAAE,sBAAsB,EAAE,MAAM,eAAe,CAAC;AACvD,OAAO,EAAE,gCAAgC,EAAE,MAAM,yBAAyB,CAAC;AAC3E,OAAO,EAAE,8BAA8B,EAAE,MAAM,uBAAuB,CAAC;AACvE,OAAO,EAAE,oBAAoB,EAAE,MAAM,aAAa,CAAC;AAEnD,OAAO,EAAE,aAAa,EAAE,sBAAsB,EAAE,MAAM,eAAe,CAAC;AACtE,OAAO,EAAE,cAAc,EAAE,uBAAuB,EAAE,MAAM,gBAAgB,CAAC;AACzE,OAAO,EAAE,SAAS,EAAE,kBAAkB,EAAE,MAAM,WAAW,CAAC;AAC1D,OAAO,EAAE,cAAc,EAAE,uBAAuB,EAAE,MAAM,gBAAgB,CAAC;AACzE,OAAO,EAAE,kBAAkB,EAAE,2BAA2B,EAAE,MAAM,oBAAoB,CAAC;AACrF,OAAO,EAAE,cAAc,EAAE,uBAAuB,EAAE,MAAM,gBAAgB,CAAC;AACzE,OAAO,EAAE,eAAe,EAAE,wBAAwB,EAAE,MAAM,iBAAiB,CAAC;AAC5E,OAAO,EAAE,YAAY,EAAE,qBAAqB,EAAE,MAAM,cAAc,CAAC;AACnE,OAAO,EAAE,qBAAqB,EAAE,8BAA8B,EAAE,MAAM,uBAAuB,CAAC;AAC9F,OAAO,EAAE,aAAa,EAAE,sBAAsB,EAAE,MAAM,eAAe,CAAC;AACtE,OAAO,EAAE,uBAAuB,EAAE,gCAAgC,EAAE,MAAM,yBAAyB,CAAC;AACpG,OAAO,EAAE,qBAAqB,EAAE,8BAA8B,EAAE,MAAM,uBAAuB,CAAC;AAC9F,OAAO,EAAE,WAAW,EAAE,oBAAoB,EAAE,MAAM,aAAa,CAAC;AAEhE,oCAAoC;AACpC,MAAM,CAAC,MAAM,mBAAmB,GAA8B;IAC7D,OAAO,EAAE,qBAAqB;IAC9B,SAAS,EAAE,uBAAuB;IAClC,SAAS,EAAE,uBAAuB;IAClC,MAAM,EAAE,oBAAoB;IAC5B,QAAQ,EAAE,sBAAsB;IAChC,IAAI,EAAE,kBAAkB;IACxB,QAAQ,EAAE,sBAAsB;IAChC,aAAa,EAAE,2BAA2B;IAC1C,SAAS,EAAE,uBAAuB;IAClC,eAAe,EAAE,8BAA8B;IAC/C,UAAU,EAAE,wBAAwB;IACpC,iBAAiB,EAAE,gCAAgC;IACnD,eAAe,EAAE,8BAA8B;CAC/C,CAAC;AAEF;;GAEG;AACH,MAAM,UAAU,sBAAsB,CAAC,IAAe,EAAU;IAC/D,OAAO,mBAAmB,CAAC,IAAI,CAAC,CAAC;AAAA,CACjC","sourcesContent":["import type { AgentRole } from \"../types.js\";\nimport { ANALYZER_SYSTEM_PROMPT } from \"./analyzer.js\";\nimport { ARCHITECT_SYSTEM_PROMPT } from \"./architect.js\";\nimport { CICD_SYSTEM_PROMPT } from \"./cicd.js\";\nimport { DEVELOPER_SYSTEM_PROMPT } from \"./developer.js\";\nimport { DIAGNOSTICIAN_SYSTEM_PROMPT } from \"./diagnostician.js\";\nimport { DISCOVERY_SYSTEM_PROMPT } from \"./discovery.js\";\nimport { DOCUMENTER_SYSTEM_PROMPT } from \"./documenter.js\";\nimport { PLANNER_SYSTEM_PROMPT } from \"./planner.js\";\nimport { PROJECT_ANALYZER_SYSTEM_PROMPT } from \"./project-analyzer.js\";\nimport { REVIEWER_SYSTEM_PROMPT } from \"./reviewer.js\";\nimport { STANDARDS_ENRICHER_SYSTEM_PROMPT } from \"./standards-enricher.js\";\nimport { SYSTEM_ARCHITECT_SYSTEM_PROMPT } from \"./system-architect.js\";\nimport { TESTER_SYSTEM_PROMPT } from \"./tester.js\";\n\nexport { ANALYZER_ROLE, ANALYZER_SYSTEM_PROMPT } from \"./analyzer.js\";\nexport { ARCHITECT_ROLE, ARCHITECT_SYSTEM_PROMPT } from \"./architect.js\";\nexport { CICD_ROLE, CICD_SYSTEM_PROMPT } from \"./cicd.js\";\nexport { DEVELOPER_ROLE, DEVELOPER_SYSTEM_PROMPT } from \"./developer.js\";\nexport { DIAGNOSTICIAN_ROLE, DIAGNOSTICIAN_SYSTEM_PROMPT } from \"./diagnostician.js\";\nexport { DISCOVERY_ROLE, DISCOVERY_SYSTEM_PROMPT } from \"./discovery.js\";\nexport { DOCUMENTER_ROLE, DOCUMENTER_SYSTEM_PROMPT } from \"./documenter.js\";\nexport { PLANNER_ROLE, PLANNER_SYSTEM_PROMPT } from \"./planner.js\";\nexport { PROJECT_ANALYZER_ROLE, PROJECT_ANALYZER_SYSTEM_PROMPT } from \"./project-analyzer.js\";\nexport { REVIEWER_ROLE, REVIEWER_SYSTEM_PROMPT } from \"./reviewer.js\";\nexport { STANDARDS_ENRICHER_ROLE, STANDARDS_ENRICHER_SYSTEM_PROMPT } from \"./standards-enricher.js\";\nexport { SYSTEM_ARCHITECT_ROLE, SYSTEM_ARCHITECT_SYSTEM_PROMPT } from \"./system-architect.js\";\nexport { TESTER_ROLE, TESTER_SYSTEM_PROMPT } from \"./tester.js\";\n\n/** System prompt mapping by role */\nexport const ROLE_SYSTEM_PROMPTS: Record<AgentRole, string> = {\n\tplanner: PLANNER_SYSTEM_PROMPT,\n\tarchitect: ARCHITECT_SYSTEM_PROMPT,\n\tdeveloper: DEVELOPER_SYSTEM_PROMPT,\n\ttester: TESTER_SYSTEM_PROMPT,\n\treviewer: REVIEWER_SYSTEM_PROMPT,\n\tcicd: CICD_SYSTEM_PROMPT,\n\tanalyzer: ANALYZER_SYSTEM_PROMPT,\n\tdiagnostician: DIAGNOSTICIAN_SYSTEM_PROMPT,\n\tdiscovery: DISCOVERY_SYSTEM_PROMPT,\n\tprojectAnalyzer: PROJECT_ANALYZER_SYSTEM_PROMPT,\n\tdocumenter: DOCUMENTER_SYSTEM_PROMPT,\n\tstandardsEnricher: STANDARDS_ENRICHER_SYSTEM_PROMPT,\n\tsystemArchitect: SYSTEM_ARCHITECT_SYSTEM_PROMPT,\n};\n\n/**\n * Returns the system prompt for the given role.\n */\nexport function getSystemPromptForRole(role: AgentRole): string {\n\treturn ROLE_SYSTEM_PROMPTS[role];\n}\n"]}
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../../src/roles/index.ts"],"names":[],"mappings":"AACA,OAAO,EAAE,sBAAsB,EAAE,MAAM,eAAe,CAAC;AACvD,OAAO,EAAE,uBAAuB,EAAE,MAAM,gBAAgB,CAAC;AACzD,OAAO,EAAE,kBAAkB,EAAE,MAAM,WAAW,CAAC;AAC/C,OAAO,EAAE,uBAAuB,EAAE,MAAM,gBAAgB,CAAC;AACzD,OAAO,EAAE,2BAA2B,EAAE,MAAM,oBAAoB,CAAC;AACjE,OAAO,EAAE,uBAAuB,EAAE,MAAM,gBAAgB,CAAC;AACzD,OAAO,EAAE,wBAAwB,EAAE,MAAM,iBAAiB,CAAC;AAC3D,OAAO,EAAE,qBAAqB,EAAE,MAAM,cAAc,CAAC;AACrD,OAAO,EAAE,8BAA8B,EAAE,MAAM,uBAAuB,CAAC;AACvE,OAAO,EAAE,qBAAqB,EAAE,MAAM,cAAc,CAAC;AACrD,OAAO,EAAE,sBAAsB,EAAE,MAAM,eAAe,CAAC;AACvD,OAAO,EAAE,gCAAgC,EAAE,MAAM,yBAAyB,CAAC;AAC3E,OAAO,EAAE,8BAA8B,EAAE,MAAM,uBAAuB,CAAC;AACvE,OAAO,EAAE,oBAAoB,EAAE,MAAM,aAAa,CAAC;AAEnD,OAAO,EAAE,aAAa,EAAE,sBAAsB,EAAE,MAAM,eAAe,CAAC;AACtE,OAAO,EAAE,cAAc,EAAE,uBAAuB,EAAE,MAAM,gBAAgB,CAAC;AACzE,OAAO,EAAE,SAAS,EAAE,kBAAkB,EAAE,MAAM,WAAW,CAAC;AAC1D,OAAO,EAAE,cAAc,EAAE,uBAAuB,EAAE,MAAM,gBAAgB,CAAC;AACzE,OAAO,EAAE,kBAAkB,EAAE,2BAA2B,EAAE,MAAM,oBAAoB,CAAC;AACrF,OAAO,EAAE,cAAc,EAAE,uBAAuB,EAAE,MAAM,gBAAgB,CAAC;AACzE,OAAO,EAAE,eAAe,EAAE,wBAAwB,EAAE,MAAM,iBAAiB,CAAC;AAC5E,OAAO,EAAE,YAAY,EAAE,qBAAqB,EAAE,MAAM,cAAc,CAAC;AACnE,OAAO,EAAE,qBAAqB,EAAE,8BAA8B,EAAE,MAAM,uBAAuB,CAAC;AAC9F,OAAO,EAAE,YAAY,EAAE,qBAAqB,EAAE,MAAM,cAAc,CAAC;AACnE,OAAO,EAAE,aAAa,EAAE,sBAAsB,EAAE,MAAM,eAAe,CAAC;AACtE,OAAO,EAAE,uBAAuB,EAAE,gCAAgC,EAAE,MAAM,yBAAyB,CAAC;AACpG,OAAO,EAAE,qBAAqB,EAAE,8BAA8B,EAAE,MAAM,uBAAuB,CAAC;AAC9F,OAAO,EAAE,WAAW,EAAE,oBAAoB,EAAE,MAAM,aAAa,CAAC;AAEhE,oCAAoC;AACpC,MAAM,CAAC,MAAM,mBAAmB,GAA8B;IAC7D,OAAO,EAAE,qBAAqB;IAC9B,SAAS,EAAE,uBAAuB;IAClC,SAAS,EAAE,uBAAuB;IAClC,MAAM,EAAE,oBAAoB;IAC5B,QAAQ,EAAE,sBAAsB;IAChC,IAAI,EAAE,kBAAkB;IACxB,QAAQ,EAAE,sBAAsB;IAChC,aAAa,EAAE,2BAA2B;IAC1C,SAAS,EAAE,uBAAuB;IAClC,eAAe,EAAE,8BAA8B;IAC/C,UAAU,EAAE,wBAAwB;IACpC,iBAAiB,EAAE,gCAAgC;IACnD,eAAe,EAAE,8BAA8B;IAC/C,OAAO,EAAE,qBAAqB;CAC9B,CAAC;AAEF;;GAEG;AACH,MAAM,UAAU,sBAAsB,CAAC,IAAe,EAAU;IAC/D,OAAO,mBAAmB,CAAC,IAAI,CAAC,CAAC;AAAA,CACjC","sourcesContent":["import type { AgentRole } from \"../types.js\";\nimport { ANALYZER_SYSTEM_PROMPT } from \"./analyzer.js\";\nimport { ARCHITECT_SYSTEM_PROMPT } from \"./architect.js\";\nimport { CICD_SYSTEM_PROMPT } from \"./cicd.js\";\nimport { DEVELOPER_SYSTEM_PROMPT } from \"./developer.js\";\nimport { DIAGNOSTICIAN_SYSTEM_PROMPT } from \"./diagnostician.js\";\nimport { DISCOVERY_SYSTEM_PROMPT } from \"./discovery.js\";\nimport { DOCUMENTER_SYSTEM_PROMPT } from \"./documenter.js\";\nimport { PLANNER_SYSTEM_PROMPT } from \"./planner.js\";\nimport { PROJECT_ANALYZER_SYSTEM_PROMPT } from \"./project-analyzer.js\";\nimport { RECOVER_SYSTEM_PROMPT } from \"./recover.js\";\nimport { REVIEWER_SYSTEM_PROMPT } from \"./reviewer.js\";\nimport { STANDARDS_ENRICHER_SYSTEM_PROMPT } from \"./standards-enricher.js\";\nimport { SYSTEM_ARCHITECT_SYSTEM_PROMPT } from \"./system-architect.js\";\nimport { TESTER_SYSTEM_PROMPT } from \"./tester.js\";\n\nexport { ANALYZER_ROLE, ANALYZER_SYSTEM_PROMPT } from \"./analyzer.js\";\nexport { ARCHITECT_ROLE, ARCHITECT_SYSTEM_PROMPT } from \"./architect.js\";\nexport { CICD_ROLE, CICD_SYSTEM_PROMPT } from \"./cicd.js\";\nexport { DEVELOPER_ROLE, DEVELOPER_SYSTEM_PROMPT } from \"./developer.js\";\nexport { DIAGNOSTICIAN_ROLE, DIAGNOSTICIAN_SYSTEM_PROMPT } from \"./diagnostician.js\";\nexport { DISCOVERY_ROLE, DISCOVERY_SYSTEM_PROMPT } from \"./discovery.js\";\nexport { DOCUMENTER_ROLE, DOCUMENTER_SYSTEM_PROMPT } from \"./documenter.js\";\nexport { PLANNER_ROLE, PLANNER_SYSTEM_PROMPT } from \"./planner.js\";\nexport { PROJECT_ANALYZER_ROLE, PROJECT_ANALYZER_SYSTEM_PROMPT } from \"./project-analyzer.js\";\nexport { RECOVER_ROLE, RECOVER_SYSTEM_PROMPT } from \"./recover.js\";\nexport { REVIEWER_ROLE, REVIEWER_SYSTEM_PROMPT } from \"./reviewer.js\";\nexport { STANDARDS_ENRICHER_ROLE, STANDARDS_ENRICHER_SYSTEM_PROMPT } from \"./standards-enricher.js\";\nexport { SYSTEM_ARCHITECT_ROLE, SYSTEM_ARCHITECT_SYSTEM_PROMPT } from \"./system-architect.js\";\nexport { TESTER_ROLE, TESTER_SYSTEM_PROMPT } from \"./tester.js\";\n\n/** System prompt mapping by role */\nexport const ROLE_SYSTEM_PROMPTS: Record<AgentRole, string> = {\n\tplanner: PLANNER_SYSTEM_PROMPT,\n\tarchitect: ARCHITECT_SYSTEM_PROMPT,\n\tdeveloper: DEVELOPER_SYSTEM_PROMPT,\n\ttester: TESTER_SYSTEM_PROMPT,\n\treviewer: REVIEWER_SYSTEM_PROMPT,\n\tcicd: CICD_SYSTEM_PROMPT,\n\tanalyzer: ANALYZER_SYSTEM_PROMPT,\n\tdiagnostician: DIAGNOSTICIAN_SYSTEM_PROMPT,\n\tdiscovery: DISCOVERY_SYSTEM_PROMPT,\n\tprojectAnalyzer: PROJECT_ANALYZER_SYSTEM_PROMPT,\n\tdocumenter: DOCUMENTER_SYSTEM_PROMPT,\n\tstandardsEnricher: STANDARDS_ENRICHER_SYSTEM_PROMPT,\n\tsystemArchitect: SYSTEM_ARCHITECT_SYSTEM_PROMPT,\n\trecover: RECOVER_SYSTEM_PROMPT,\n};\n\n/**\n * Returns the system prompt for the given role.\n */\nexport function getSystemPromptForRole(role: AgentRole): string {\n\treturn ROLE_SYSTEM_PROMPTS[role];\n}\n"]}

package/dist/roles/recover.d.ts

@@ -0,0 +1,5 @@
+/** Role identifier for the recovery agent. */
+export declare const RECOVER_ROLE: "recover";
+/** System prompt for the recovery agent. */
+export declare const RECOVER_SYSTEM_PROMPT = "# Recovery Agent\n\nYou are a recovery specialist for the Vibe orchestration system. Your task is to reconstruct a lost `orchestration-state.json` by analyzing surviving artifacts in the `.vibe/` directory.\n\n## OrchestrationState Structure\n\n```typescript\ninterface OrchestrationState {\n  workflowType: \"new_feature\" | \"enhancement\" | \"bugfix\" | \"refactor\" | \"mixed\";\n  phase: \"discovery\" | \"requirements_gate\" | \"system_architecture\" | \"system_design_gate\" | \"analyze\" | \"planning\" | \"plan_gate\" | \"orchestrating\" | \"single_pipeline\" | \"done\";\n  completedFeatures: string[];\n  failedFeatures: string[];\n  skippedFeatures: string[];\n  requirement: string;\n  options?: { parentFeatureId?: string; issueRef?: string };\n  singleFeatureId?: string;\n  baseBranch?: string;\n  updatedAt: string;\n}\n```\n\n## Your Investigation Process\n\n1. **Read plan.json** to understand the workflow type and feature list.\n2. **Check each feature directory** (`.vibe/features/{featureId}/`) for artifacts:\n   - `spec.md` \u2014 feature was planned\n   - `design.md` \u2014 design phase completed\n   - `test-report.md` \u2014 testing was done\n   - `review.md` \u2014 review was done (read it to check if verdict is APPROVED)\n   - `pipeline.json` \u2014 feature was in progress (check `currentStep` and `status`)\n   - `status.json` \u2014 may contain status information\n3. **Check git state** using `execute_command`:\n   - `git branch --list 'feat/vibe-*'` or similar patterns to see feature branches\n   - `git log --oneline -20` to see recent merge commits\n   - `git branch --show-current` for the current branch\n4. **Read config.json** for `baseBranch`.\n5. **Read requirements.md** first few lines for the `requirement` field.\n\n## Feature Completion Criteria\n\nA feature is **completed** when:\n- `review.md` exists AND contains \"APPROVED\" verdict\n- AND the feature branch was merged (visible in git log or branch is gone)\n\nA feature is **in-progress** when:\n- `pipeline.json` exists, OR\n- Some artifacts exist (design.md, test-report.md) but review.md is missing or not approved\n\nA feature is **planned** when:\n- Only `spec.md` exists (or no artifacts at all)\n\nWhen in doubt, classify as **planned** rather than **completed**. This ensures the feature runs again on resume rather than being skipped.\n\n## Output\n\nAfter investigation, output your proposed state as a single JSON code block:\n\n```json\n{\n  \"workflowType\": \"...\",\n  \"phase\": \"orchestrating\",\n  \"completedFeatures\": [...],\n  \"failedFeatures\": [],\n  \"skippedFeatures\": [],\n  \"requirement\": \"...\",\n  \"baseBranch\": \"...\",\n  \"updatedAt\": \"<current ISO timestamp>\"\n}\n```\n\n## Rules\n\n- `phase` should almost always be `\"orchestrating\"` \u2014 recovery puts us back into feature execution.\n- `failedFeatures` should be empty unless you find clear evidence of failure (e.g., status.json with `\"failed\"`).\n- `skippedFeatures` should be empty unless you find clear evidence of skipping.\n- Only include features in `completedFeatures` if you are confident they are fully done.\n- Include a brief explanation before the JSON block explaining your reasoning for each feature's classification.\n";
+//# sourceMappingURL=recover.d.ts.map

package/dist/roles/recover.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"recover.d.ts","sourceRoot":"","sources":["../../src/roles/recover.ts"],"names":[],"mappings":"AAAA,8CAA8C;AAC9C,eAAO,MAAM,YAAY,WAAqB,CAAC;AAE/C,4CAA4C;AAC5C,eAAO,MAAM,qBAAqB,qrGA6EjC,CAAC","sourcesContent":["/** Role identifier for the recovery agent. */\nexport const RECOVER_ROLE = \"recover\" as const;\n\n/** System prompt for the recovery agent. */\nexport const RECOVER_SYSTEM_PROMPT = `# Recovery Agent\n\nYou are a recovery specialist for the Vibe orchestration system. Your task is to reconstruct a lost \\`orchestration-state.json\\` by analyzing surviving artifacts in the \\`.vibe/\\` directory.\n\n## OrchestrationState Structure\n\n\\`\\`\\`typescript\ninterface OrchestrationState {\n  workflowType: \"new_feature\" | \"enhancement\" | \"bugfix\" | \"refactor\" | \"mixed\";\n  phase: \"discovery\" | \"requirements_gate\" | \"system_architecture\" | \"system_design_gate\" | \"analyze\" | \"planning\" | \"plan_gate\" | \"orchestrating\" | \"single_pipeline\" | \"done\";\n  completedFeatures: string[];\n  failedFeatures: string[];\n  skippedFeatures: string[];\n  requirement: string;\n  options?: { parentFeatureId?: string; issueRef?: string };\n  singleFeatureId?: string;\n  baseBranch?: string;\n  updatedAt: string;\n}\n\\`\\`\\`\n\n## Your Investigation Process\n\n1. **Read plan.json** to understand the workflow type and feature list.\n2. **Check each feature directory** (\\`.vibe/features/{featureId}/\\`) for artifacts:\n   - \\`spec.md\\` — feature was planned\n   - \\`design.md\\` — design phase completed\n   - \\`test-report.md\\` — testing was done\n   - \\`review.md\\` — review was done (read it to check if verdict is APPROVED)\n   - \\`pipeline.json\\` — feature was in progress (check \\`currentStep\\` and \\`status\\`)\n   - \\`status.json\\` — may contain status information\n3. **Check git state** using \\`execute_command\\`:\n   - \\`git branch --list 'feat/vibe-*'\\` or similar patterns to see feature branches\n   - \\`git log --oneline -20\\` to see recent merge commits\n   - \\`git branch --show-current\\` for the current branch\n4. **Read config.json** for \\`baseBranch\\`.\n5. **Read requirements.md** first few lines for the \\`requirement\\` field.\n\n## Feature Completion Criteria\n\nA feature is **completed** when:\n- \\`review.md\\` exists AND contains \"APPROVED\" verdict\n- AND the feature branch was merged (visible in git log or branch is gone)\n\nA feature is **in-progress** when:\n- \\`pipeline.json\\` exists, OR\n- Some artifacts exist (design.md, test-report.md) but review.md is missing or not approved\n\nA feature is **planned** when:\n- Only \\`spec.md\\` exists (or no artifacts at all)\n\nWhen in doubt, classify as **planned** rather than **completed**. This ensures the feature runs again on resume rather than being skipped.\n\n## Output\n\nAfter investigation, output your proposed state as a single JSON code block:\n\n\\`\\`\\`json\n{\n  \"workflowType\": \"...\",\n  \"phase\": \"orchestrating\",\n  \"completedFeatures\": [...],\n  \"failedFeatures\": [],\n  \"skippedFeatures\": [],\n  \"requirement\": \"...\",\n  \"baseBranch\": \"...\",\n  \"updatedAt\": \"<current ISO timestamp>\"\n}\n\\`\\`\\`\n\n## Rules\n\n- \\`phase\\` should almost always be \\`\"orchestrating\"\\` — recovery puts us back into feature execution.\n- \\`failedFeatures\\` should be empty unless you find clear evidence of failure (e.g., status.json with \\`\"failed\"\\`).\n- \\`skippedFeatures\\` should be empty unless you find clear evidence of skipping.\n- Only include features in \\`completedFeatures\\` if you are confident they are fully done.\n- Include a brief explanation before the JSON block explaining your reasoning for each feature's classification.\n`;\n"]}

package/dist/roles/recover.js

@@ -0,0 +1,82 @@
+/** Role identifier for the recovery agent. */
+export const RECOVER_ROLE = "recover";
+/** System prompt for the recovery agent. */
+export const RECOVER_SYSTEM_PROMPT = `# Recovery Agent
+
+You are a recovery specialist for the Vibe orchestration system. Your task is to reconstruct a lost \`orchestration-state.json\` by analyzing surviving artifacts in the \`.vibe/\` directory.
+
+## OrchestrationState Structure
+
+\`\`\`typescript
+interface OrchestrationState {
+  workflowType: "new_feature" | "enhancement" | "bugfix" | "refactor" | "mixed";
+  phase: "discovery" | "requirements_gate" | "system_architecture" | "system_design_gate" | "analyze" | "planning" | "plan_gate" | "orchestrating" | "single_pipeline" | "done";
+  completedFeatures: string[];
+  failedFeatures: string[];
+  skippedFeatures: string[];
+  requirement: string;
+  options?: { parentFeatureId?: string; issueRef?: string };
+  singleFeatureId?: string;
+  baseBranch?: string;
+  updatedAt: string;
+}
+\`\`\`
+
+## Your Investigation Process
+
+1. **Read plan.json** to understand the workflow type and feature list.
+2. **Check each feature directory** (\`.vibe/features/{featureId}/\`) for artifacts:
+   - \`spec.md\` — feature was planned
+   - \`design.md\` — design phase completed
+   - \`test-report.md\` — testing was done
+   - \`review.md\` — review was done (read it to check if verdict is APPROVED)
+   - \`pipeline.json\` — feature was in progress (check \`currentStep\` and \`status\`)
+   - \`status.json\` — may contain status information
+3. **Check git state** using \`execute_command\`:
+   - \`git branch --list 'feat/vibe-*'\` or similar patterns to see feature branches
+   - \`git log --oneline -20\` to see recent merge commits
+   - \`git branch --show-current\` for the current branch
+4. **Read config.json** for \`baseBranch\`.
+5. **Read requirements.md** first few lines for the \`requirement\` field.
+
+## Feature Completion Criteria
+
+A feature is **completed** when:
+- \`review.md\` exists AND contains "APPROVED" verdict
+- AND the feature branch was merged (visible in git log or branch is gone)
+
+A feature is **in-progress** when:
+- \`pipeline.json\` exists, OR
+- Some artifacts exist (design.md, test-report.md) but review.md is missing or not approved
+
+A feature is **planned** when:
+- Only \`spec.md\` exists (or no artifacts at all)
+
+When in doubt, classify as **planned** rather than **completed**. This ensures the feature runs again on resume rather than being skipped.
+
+## Output
+
+After investigation, output your proposed state as a single JSON code block:
+
+\`\`\`json
+{
+  "workflowType": "...",
+  "phase": "orchestrating",
+  "completedFeatures": [...],
+  "failedFeatures": [],
+  "skippedFeatures": [],
+  "requirement": "...",
+  "baseBranch": "...",
+  "updatedAt": "<current ISO timestamp>"
+}
+\`\`\`
+
+## Rules
+
+- \`phase\` should almost always be \`"orchestrating"\` — recovery puts us back into feature execution.
+- \`failedFeatures\` should be empty unless you find clear evidence of failure (e.g., status.json with \`"failed"\`).
+- \`skippedFeatures\` should be empty unless you find clear evidence of skipping.
+- Only include features in \`completedFeatures\` if you are confident they are fully done.
+- Include a brief explanation before the JSON block explaining your reasoning for each feature's classification.
+`;
+//# sourceMappingURL=recover.js.map

package/dist/roles/recover.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"recover.js","sourceRoot":"","sources":["../../src/roles/recover.ts"],"names":[],"mappings":"AAAA,8CAA8C;AAC9C,MAAM,CAAC,MAAM,YAAY,GAAG,SAAkB,CAAC;AAE/C,4CAA4C;AAC5C,MAAM,CAAC,MAAM,qBAAqB,GAAG;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;CA6EpC,CAAC","sourcesContent":["/** Role identifier for the recovery agent. */\nexport const RECOVER_ROLE = \"recover\" as const;\n\n/** System prompt for the recovery agent. */\nexport const RECOVER_SYSTEM_PROMPT = `# Recovery Agent\n\nYou are a recovery specialist for the Vibe orchestration system. Your task is to reconstruct a lost \\`orchestration-state.json\\` by analyzing surviving artifacts in the \\`.vibe/\\` directory.\n\n## OrchestrationState Structure\n\n\\`\\`\\`typescript\ninterface OrchestrationState {\n  workflowType: \"new_feature\" | \"enhancement\" | \"bugfix\" | \"refactor\" | \"mixed\";\n  phase: \"discovery\" | \"requirements_gate\" | \"system_architecture\" | \"system_design_gate\" | \"analyze\" | \"planning\" | \"plan_gate\" | \"orchestrating\" | \"single_pipeline\" | \"done\";\n  completedFeatures: string[];\n  failedFeatures: string[];\n  skippedFeatures: string[];\n  requirement: string;\n  options?: { parentFeatureId?: string; issueRef?: string };\n  singleFeatureId?: string;\n  baseBranch?: string;\n  updatedAt: string;\n}\n\\`\\`\\`\n\n## Your Investigation Process\n\n1. **Read plan.json** to understand the workflow type and feature list.\n2. **Check each feature directory** (\\`.vibe/features/{featureId}/\\`) for artifacts:\n   - \\`spec.md\\` — feature was planned\n   - \\`design.md\\` — design phase completed\n   - \\`test-report.md\\` — testing was done\n   - \\`review.md\\` — review was done (read it to check if verdict is APPROVED)\n   - \\`pipeline.json\\` — feature was in progress (check \\`currentStep\\` and \\`status\\`)\n   - \\`status.json\\` — may contain status information\n3. **Check git state** using \\`execute_command\\`:\n   - \\`git branch --list 'feat/vibe-*'\\` or similar patterns to see feature branches\n   - \\`git log --oneline -20\\` to see recent merge commits\n   - \\`git branch --show-current\\` for the current branch\n4. **Read config.json** for \\`baseBranch\\`.\n5. **Read requirements.md** first few lines for the \\`requirement\\` field.\n\n## Feature Completion Criteria\n\nA feature is **completed** when:\n- \\`review.md\\` exists AND contains \"APPROVED\" verdict\n- AND the feature branch was merged (visible in git log or branch is gone)\n\nA feature is **in-progress** when:\n- \\`pipeline.json\\` exists, OR\n- Some artifacts exist (design.md, test-report.md) but review.md is missing or not approved\n\nA feature is **planned** when:\n- Only \\`spec.md\\` exists (or no artifacts at all)\n\nWhen in doubt, classify as **planned** rather than **completed**. This ensures the feature runs again on resume rather than being skipped.\n\n## Output\n\nAfter investigation, output your proposed state as a single JSON code block:\n\n\\`\\`\\`json\n{\n  \"workflowType\": \"...\",\n  \"phase\": \"orchestrating\",\n  \"completedFeatures\": [...],\n  \"failedFeatures\": [],\n  \"skippedFeatures\": [],\n  \"requirement\": \"...\",\n  \"baseBranch\": \"...\",\n  \"updatedAt\": \"<current ISO timestamp>\"\n}\n\\`\\`\\`\n\n## Rules\n\n- \\`phase\\` should almost always be \\`\"orchestrating\"\\` — recovery puts us back into feature execution.\n- \\`failedFeatures\\` should be empty unless you find clear evidence of failure (e.g., status.json with \\`\"failed\"\\`).\n- \\`skippedFeatures\\` should be empty unless you find clear evidence of skipping.\n- Only include features in \\`completedFeatures\\` if you are confident they are fully done.\n- Include a brief explanation before the JSON block explaining your reasoning for each feature's classification.\n`;\n"]}