openplanr 1.2.1 → 1.2.2

package/dist/ai/prompts/prompt-builder.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"prompt-builder.d.ts","sourceRoot":"","sources":["../../../src/ai/prompts/prompt-builder.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAEH,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,aAAa,CAAC;AAgB7C,wBAAgB,eAAe,CAAC,KAAK,EAAE,MAAM,EAAE,aAAa,GAAE,MAAM,EAAO,GAAG,SAAS,EAAE,CAkBxF;AAED,wBAAgB,mBAAmB,CACjC,WAAW,EAAE,MAAM,EACnB,gBAAgB,GAAE,MAAM,EAAO,EAC/B,YAAY,CAAC,EAAE,MAAM,GACpB,SAAS,EAAE,CAeb;AAED,wBAAgB,kBAAkB,CAChC,cAAc,EAAE,MAAM,EACtB,WAAW,EAAE,MAAM,EACnB,eAAe,GAAE,MAAM,EAAO,GAC7B,SAAS,EAAE,CAYb;AAED,MAAM,WAAW,gBAAgB;IAC/B,OAAO,EAAE,KAAK,CAAC;QAAE,EAAE,EAAE,MAAM,CAAC;QAAC,GAAG,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;IAC5C,gBAAgB,CAAC,EAAE,KAAK,CAAC;QAAE,OAAO,EAAE,MAAM,CAAC;QAAC,OAAO,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;IAC/D,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,IAAI,CAAC,EAAE,KAAK,CAAC;QAAE,EAAE,EAAE,MAAM,CAAC;QAAC,OAAO,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;IAC9C,eAAe,CAAC,EAAE,MAAM,CAAC;IACzB,gFAAgF;IAChF,KAAK,CAAC,EAAE;QAAE,IAAI,EAAE,SAAS,CAAC;QAAC,EAAE,EAAE,MAAM,CAAA;KAAE,GAAG;QAAE,IAAI,EAAE,OAAO,CAAC;QAAC,EAAE,EAAE,MAAM,CAAA;KAAE,CAAC;CACzE;AAED,wBAAgB,gBAAgB,CAAC,GAAG,EAAE,gBAAgB,GAAG,SAAS,EAAE,CAqDnE;AAED,wBAAgB,qBAAqB,CAAC,WAAW,EAAE,MAAM,EAAE,eAAe,CAAC,EAAE,MAAM,GAAG,SAAS,EAAE,CAkBhG;AAED,wBAAgB,mBAAmB,CACjC,eAAe,EAAE,MAAM,EACvB,YAAY,EAAE,MAAM,EACpB,eAAe,CAAC,EAAE,MAAM,GACvB,SAAS,EAAE,CAWb;AAED,wBAAgB,4BAA4B,CAC1C,KAAK,EAAE,KAAK,CAAC;IACX,EAAE,EAAE,MAAM,CAAC;IACX,KAAK,EAAE,MAAM,CAAC;IACd,QAAQ,EAAE,MAAM,CAAC;IACjB,IAAI,EAAE,MAAM,EAAE,CAAC;IACf,WAAW,EAAE,MAAM,CAAC;CACrB,CAAC,EACF,eAAe,CAAC,EAAE,MAAM,GACvB,SAAS,EAAE,CAkBb;AAED,wBAAgB,2BAA2B,CACzC,cAAc,EAAE,KAAK,CAAC;IAAE,EAAE,EAAE,MAAM,CAAC;IAAC,KAAK,EAAE,MAAM,CAAC;IAAC,MAAM,CAAC,EAAE,MAAM,CAAA;CAAE,CAAC,EACrE,QAAQ,EAAE,MAAM,EAChB,eAAe,CAAC,EAAE,MAAM,GACvB,SAAS,EAAE,CAeb;AAED,wBAAgB,iBAAiB,CAC/B,eAAe,EAAE,MAAM,EACvB,YAAY,EAAE,MAAM,EACpB,aAAa,CAAC,EAAE;IAAE,IAAI,EAAE,MAAM,CAAC;IAAC,OAAO,EAAE,MAAM,CAAA;CAAE,GAChD,SAAS,EAAE,CAYb"}
+{"version":3,"file":"prompt-builder.d.ts","sourceRoot":"","sources":["../../../src/ai/prompts/prompt-builder.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAEH,OAAO,KAAK,EAAE,SAAS,EAAE,MAAM,aAAa,CAAC;AAgB7C,wBAAgB,eAAe,CAAC,KAAK,EAAE,MAAM,EAAE,aAAa,GAAE,MAAM,EAAO,GAAG,SAAS,EAAE,CAkBxF;AAED,wBAAgB,mBAAmB,CACjC,WAAW,EAAE,MAAM,EACnB,gBAAgB,GAAE,MAAM,EAAO,EAC/B,YAAY,CAAC,EAAE,MAAM,GACpB,SAAS,EAAE,CAeb;AAED,wBAAgB,kBAAkB,CAChC,cAAc,EAAE,MAAM,EACtB,WAAW,EAAE,MAAM,EACnB,eAAe,GAAE,MAAM,EAAO,GAC7B,SAAS,EAAE,CAYb;AAED,MAAM,WAAW,gBAAgB;IAC/B,OAAO,EAAE,KAAK,CAAC;QAAE,EAAE,EAAE,MAAM,CAAC;QAAC,GAAG,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;IAC5C,gBAAgB,CAAC,EAAE,KAAK,CAAC;QAAE,OAAO,EAAE,MAAM,CAAC;QAAC,OAAO,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;IAC/D,UAAU,CAAC,EAAE,MAAM,CAAC;IACpB,OAAO,CAAC,EAAE,MAAM,CAAC;IACjB,IAAI,CAAC,EAAE,KAAK,CAAC;QAAE,EAAE,EAAE,MAAM,CAAC;QAAC,OAAO,EAAE,MAAM,CAAA;KAAE,CAAC,CAAC;IAC9C,eAAe,CAAC,EAAE,MAAM,CAAC;IACzB,gFAAgF;IAChF,KAAK,CAAC,EAAE;QAAE,IAAI,EAAE,SAAS,CAAC;QAAC,EAAE,EAAE,MAAM,CAAA;KAAE,GAAG;QAAE,IAAI,EAAE,OAAO,CAAC;QAAC,EAAE,EAAE,MAAM,CAAA;KAAE,CAAC;CACzE;AAED,wBAAgB,gBAAgB,CAAC,GAAG,EAAE,gBAAgB,GAAG,SAAS,EAAE,CAqDnE;AAED,wBAAgB,qBAAqB,CAAC,WAAW,EAAE,MAAM,EAAE,eAAe,CAAC,EAAE,MAAM,GAAG,SAAS,EAAE,CA6BhG;AAED,wBAAgB,mBAAmB,CACjC,eAAe,EAAE,MAAM,EACvB,YAAY,EAAE,MAAM,EACpB,eAAe,CAAC,EAAE,MAAM,GACvB,SAAS,EAAE,CAWb;AAED,wBAAgB,4BAA4B,CAC1C,KAAK,EAAE,KAAK,CAAC;IACX,EAAE,EAAE,MAAM,CAAC;IACX,KAAK,EAAE,MAAM,CAAC;IACd,QAAQ,EAAE,MAAM,CAAC;IACjB,IAAI,EAAE,MAAM,EAAE,CAAC;IACf,WAAW,EAAE,MAAM,CAAC;CACrB,CAAC,EACF,eAAe,CAAC,EAAE,MAAM,GACvB,SAAS,EAAE,CAkBb;AAED,wBAAgB,2BAA2B,CACzC,cAAc,EAAE,KAAK,CAAC;IAAE,EAAE,EAAE,MAAM,CAAC;IAAC,KAAK,EAAE,MAAM,CAAC;IAAC,MAAM,CAAC,EAAE,MAAM,CAAA;CAAE,CAAC,EACrE,QAAQ,EAAE,MAAM,EAChB,eAAe,CAAC,EAAE,MAAM,GACvB,SAAS,EAAE,CAeb;AAED,wBAAgB,iBAAiB,CAC/B,eAAe,EAAE,MAAM,EACvB,YAAY,EAAE,MAAM,EACpB,aAAa,CAAC,EAAE;IAAE,IAAI,EAAE,MAAM,CAAC;IAAC,OAAO,EAAE,MAAM,CAAA;CAAE,GAChD,SAAS,EAAE,CAYb"}

package/dist/ai/prompts/prompt-builder.js

@@ -99,7 +99,18 @@ export function buildQuickTasksPrompt(description, codebaseContext) {
     const isDetailed = description.split('\n').length > DETAILED_INPUT_LINE_THRESHOLD;
     let userContent;
     if (isDetailed) {
-        userContent = `Generate an implementation task list from this detailed requirements document. Extract ALL commands, data models, constraints, and features into concrete implementation tasks:\n\n${description}`;
+        userContent = `Generate a comprehensive implementation task list from this requirements document.
+
+CRITICAL — Completeness rules:
+1. Walk through EVERY numbered section of the document. Do NOT skip or summarize sections.
+2. For each API endpoint, data model, integration point, and workflow described, there MUST be a corresponding task or subtask.
+3. Open questions and undecided items in the document should become investigation/spike subtasks.
+4. If the document describes retry logic, error handling, auth flows, webhooks, or queue mechanisms — each needs its own subtask, not a bullet inside another task.
+5. After generating tasks, mentally re-read the document and verify no section was left uncovered.
+
+Requirements document:
+
+${description}`;
     }
     else {
         userContent = `Generate an implementation task list for the following:\n\n"${description}"`;

package/dist/ai/prompts/prompt-builder.js.map

@@ -1 +1 @@
-{"version":3,"file":"prompt-builder.js","sourceRoot":"","sources":["../../../src/ai/prompts/prompt-builder.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAGH,OAAO,EACL,gCAAgC,EAChC,kBAAkB,EAClB,sBAAsB,EACtB,sBAAsB,EACtB,yBAAyB,EACzB,oBAAoB,EACpB,gCAAgC,EAChC,qBAAqB,EACrB,mBAAmB,GACpB,MAAM,qBAAqB,CAAC;AAE7B,2FAA2F;AAC3F,MAAM,6BAA6B,GAAG,CAAC,CAAC;AAExC,MAAM,UAAU,eAAe,CAAC,KAAa,EAAE,gBAA0B,EAAE;IACzE,MAAM,UAAU,GAAG,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,MAAM,GAAG,6BAA6B,CAAC;IAE5E,IAAI,WAAmB,CAAC;IACxB,IAAI,UAAU,EAAE,CAAC;QACf,WAAW,GAAG,oJAAoJ,KAAK,EAAE,CAAC;IAC5K,CAAC;SAAM,CAAC;QACN,WAAW,GAAG,uCAAuC,KAAK,GAAG,CAAC;IAChE,CAAC;IAED,IAAI,aAAa,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;QAC7B,WAAW,IAAI,2DAA2D,aAAa,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,KAAK,CAAC,EAAE,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CAAC;IAC5H,CAAC;IAED,OAAO;QACL,EAAE,IAAI,EAAE,QAAQ,EAAE,OAAO,EAAE,kBAAkB,EAAE;QAC/C,EAAE,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,WAAW,EAAE;KACvC,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,mBAAmB,CACjC,WAAmB,EACnB,mBAA6B,EAAE,EAC/B,YAAqB;IAErB,IAAI,WAAW,GAAG,yCAAyC,WAAW,EAAE,CAAC;IAEzE,IAAI,YAAY,EAAE,CAAC;QACjB,WAAW,IAAI,8BAA8B,YAAY,YAAY,CAAC;IACxE,CAAC;IAED,IAAI,gBAAgB,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;QAChC,WAAW,IAAI,4DAA4D,gBAAgB,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,KAAK,CAAC,EAAE,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CAAC;IAChI,CAAC;IAED,OAAO;QACL,EAAE,IAAI,EAAE,QAAQ,EAAE,OAAO,EAAE,sBAAsB,EAAE;QACnD,EAAE,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,WAAW,EAAE;KACvC,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,kBAAkB,CAChC,cAAsB,EACtB,WAAmB,EACnB,kBAA4B,EAAE;IAE9B,IAAI,WAAW,GAAG,8CAA8C,cAAc,EAAE,CAAC;IACjF,WAAW,IAAI,oCAAoC,WAAW,EAAE,CAAC;IAEjE,IAAI,eAAe,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;QAC/B,WAAW,IAAI,8DAA8D,eAAe,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,KAAK,CAAC,EAAE,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CAAC;IACjI,CAAC;IAED,OAAO;QACL,EAAE,IAAI,EAAE,QAAQ,EAAE,OAAO,EAAE,qBAAqB,EAAE;QAClD,EAAE,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,WAAW,EAAE;KACvC,CAAC;AACJ,CAAC;AAaD,MAAM,UAAU,gBAAgB,CAAC,GAAqB;IACpD,MAAM,QAAQ,GAAa,EAAE,CAAC;IAE9B,eAAe;IACf,QAAQ,CAAC,IAAI,CAAC,sBAAsB,CAAC,CAAC;IACtC,KAAK,MAAM,KAAK,IAAI,GAAG,CAAC,OAAO,EAAE,CAAC;QAChC,QAAQ,CAAC,IAAI,CAAC,MAAM,KAAK,CAAC,EAAE,MAAM,KAAK,CAAC,GAAG,EAAE,CAAC,CAAC;IACjD,CAAC;IAED,8BAA8B;IAC9B,IAAI,GAAG,CAAC,gBAAgB,IAAI,GAAG,CAAC,gBAAgB,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;QAC5D,QAAQ,CAAC,IAAI,CAAC,uCAAuC,CAAC,CAAC;QACvD,KAAK,MAAM,CAAC,IAAI,GAAG,CAAC,gBAAgB,EAAE,CAAC;YACrC,QAAQ,CAAC,IAAI,CAAC,kBAAkB,CAAC,CAAC,OAAO,MAAM,CAAC,CAAC,OAAO,EAAE,CAAC,CAAC;QAC9D,CAAC;IACH,CAAC;IAED,yBAAyB;IACzB,IAAI,GAAG,CAAC,UAAU,EAAE,CAAC;QACnB,QAAQ,CAAC,IAAI,CAAC,qCAAqC,GAAG,CAAC,UAAU,EAAE,CAAC,CAAC;IACvE,CAAC;IAED,sBAAsB;IACtB,IAAI,GAAG,CAAC,OAAO,EAAE,CAAC;QAChB,QAAQ,CAAC,IAAI,CAAC,kCAAkC,GAAG,CAAC,OAAO,EAAE,CAAC,CAAC;IACjE,CAAC;IAED,gCAAgC;IAChC,IAAI,GAAG,CAAC,IAAI,IAAI,GAAG,CAAC,IAAI,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;QACpC,QAAQ,CAAC,IAAI,CAAC,yCAAyC,CAAC,CAAC;QACzD,KAAK,MAAM,GAAG,IAAI,GAAG,CAAC,IAAI,EAAE,CAAC;YAC3B,QAAQ,CAAC,IAAI,CAAC,MAAM,GAAG,CAAC,EAAE,MAAM,GAAG,CAAC,OAAO,EAAE,CAAC,CAAC;QACjD,CAAC;IACH,CAAC;IAED,mBAAmB;IACnB,IAAI,GAAG,CAAC,eAAe,EAAE,CAAC;QACxB,QAAQ,CAAC,IAAI,CAAC,+BAA+B,GAAG,CAAC,eAAe,EAAE,CAAC,CAAC;IACtE,CAAC;IAED,0DAA0D;IAC1D,IAAI,GAAG,CAAC,KAAK,EAAE,CAAC;QACd,QAAQ,CAAC,IAAI,CACX,yDAAyD,GAAG,CAAC,KAAK,CAAC,IAAI,cAAc,GAAG,CAAC,KAAK,CAAC,EAAE,uCAAuC,GAAG,CAAC,KAAK,CAAC,EAAE,wBAAwB,CAC7K,CAAC;IACJ,CAAC;IAED,MAAM,WAAW,GAAG,wEAAwE,QAAQ,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CAAC;IAElH,OAAO;QACL,EAAE,IAAI,EAAE,QAAQ,EAAE,OAAO,EAAE,mBAAmB,EAAE;QAChD,EAAE,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,WAAW,EAAE;KACvC,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,qBAAqB,CAAC,WAAmB,EAAE,eAAwB;IACjF,MAAM,UAAU,GAAG,WAAW,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,MAAM,GAAG,6BAA6B,CAAC;IAClF,IAAI,WAAmB,CAAC;IAExB,IAAI,UAAU,EAAE,CAAC;QACf,WAAW,GAAG,sLAAsL,WAAW,EAAE,CAAC;IACpN,CAAC;SAAM,CAAC;QACN,WAAW,GAAG,+DAA+D,WAAW,GAAG,CAAC;IAC9F,CAAC;IAED,IAAI,eAAe,EAAE,CAAC;QACpB,WAAW,IAAI,iCAAiC,eAAe,EAAE,CAAC;IACpE,CAAC;IAED,OAAO;QACL,EAAE,IAAI,EAAE,QAAQ,EAAE,OAAO,EAAE,yBAAyB,EAAE;QACtD,EAAE,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,WAAW,EAAE;KACvC,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,mBAAmB,CACjC,eAAuB,EACvB,YAAoB,EACpB,eAAwB;IAExB,IAAI,WAAW,GAAG,gCAAgC,YAAY,iBAAiB,eAAe,EAAE,CAAC;IAEjG,IAAI,eAAe,EAAE,CAAC;QACpB,WAAW,IAAI,iCAAiC,eAAe,EAAE,CAAC;IACpE,CAAC;IAED,OAAO;QACL,EAAE,IAAI,EAAE,QAAQ,EAAE,OAAO,EAAE,sBAAsB,EAAE;QACnD,EAAE,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,WAAW,EAAE;KACvC,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,4BAA4B,CAC1C,KAME,EACF,eAAwB;IAExB,MAAM,SAAS,GAAG,KAAK;SACpB,GAAG,CACF,CAAC,IAAI,EAAE,EAAE,CACP,KAAK,IAAI,CAAC,EAAE,MAAM,IAAI,CAAC,KAAK,eAAe,IAAI,CAAC,QAAQ,WAAW,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,IAAI,MAAM,GAAG,CACvG;SACA,IAAI,CAAC,IAAI,CAAC,CAAC;IAEd,IAAI,WAAW,GAAG,yEAAyE,SAAS,EAAE,CAAC;IAEvG,IAAI,eAAe,EAAE,CAAC;QACpB,WAAW,IAAI,iCAAiC,eAAe,EAAE,CAAC;IACpE,CAAC;IAED,OAAO;QACL,EAAE,IAAI,EAAE,QAAQ,EAAE,OAAO,EAAE,gCAAgC,EAAE;QAC7D,EAAE,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,WAAW,EAAE;KACvC,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,2BAA2B,CACzC,cAAqE,EACrE,QAAgB,EAChB,eAAwB;IAExB,MAAM,QAAQ,GAAG,cAAc;SAC5B,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,KAAK,CAAC,CAAC,EAAE,MAAM,CAAC,CAAC,KAAK,IAAI,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,KAAK,CAAC,CAAC,MAAM,OAAO,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC;SAC5E,IAAI,CAAC,IAAI,CAAC,CAAC;IAEd,IAAI,WAAW,GAAG,yDAAyD,QAAQ,sCAAsC,QAAQ,EAAE,CAAC;IAEpI,IAAI,eAAe,EAAE,CAAC;QACpB,WAAW,IAAI,iCAAiC,eAAe,EAAE,CAAC;IACpE,CAAC;IAED,OAAO;QACL,EAAE,IAAI,EAAE,QAAQ,EAAE,OAAO,EAAE,gCAAgC,EAAE;QAC7D,EAAE,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,WAAW,EAAE;KACvC,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,iBAAiB,CAC/B,eAAuB,EACvB,YAAoB,EACpB,aAAiD;IAEjD,IAAI,WAAW,GAAG,2BAA2B,YAAY,+IAA+I,eAAe,EAAE,CAAC;IAE1N,IAAI,aAAa,EAAE,CAAC;QAClB,WAAW,IAAI,0BAA0B,aAAa,CAAC,IAAI,2BAA2B,aAAa,CAAC,OAAO,EAAE,CAAC;QAC9G,WAAW,IAAI,6BAA6B,aAAa,CAAC,IAAI,wCAAwC,YAAY,kHAAkH,CAAC;IACvO,CAAC;IAED,OAAO;QACL,EAAE,IAAI,EAAE,QAAQ,EAAE,OAAO,EAAE,oBAAoB,EAAE;QACjD,EAAE,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,WAAW,EAAE;KACvC,CAAC;AACJ,CAAC"}
+{"version":3,"file":"prompt-builder.js","sourceRoot":"","sources":["../../../src/ai/prompts/prompt-builder.ts"],"names":[],"mappings":"AAAA;;;;;;;;;GASG;AAGH,OAAO,EACL,gCAAgC,EAChC,kBAAkB,EAClB,sBAAsB,EACtB,sBAAsB,EACtB,yBAAyB,EACzB,oBAAoB,EACpB,gCAAgC,EAChC,qBAAqB,EACrB,mBAAmB,GACpB,MAAM,qBAAqB,CAAC;AAE7B,2FAA2F;AAC3F,MAAM,6BAA6B,GAAG,CAAC,CAAC;AAExC,MAAM,UAAU,eAAe,CAAC,KAAa,EAAE,gBAA0B,EAAE;IACzE,MAAM,UAAU,GAAG,KAAK,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,MAAM,GAAG,6BAA6B,CAAC;IAE5E,IAAI,WAAmB,CAAC;IACxB,IAAI,UAAU,EAAE,CAAC;QACf,WAAW,GAAG,oJAAoJ,KAAK,EAAE,CAAC;IAC5K,CAAC;SAAM,CAAC;QACN,WAAW,GAAG,uCAAuC,KAAK,GAAG,CAAC;IAChE,CAAC;IAED,IAAI,aAAa,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;QAC7B,WAAW,IAAI,2DAA2D,aAAa,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,KAAK,CAAC,EAAE,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CAAC;IAC5H,CAAC;IAED,OAAO;QACL,EAAE,IAAI,EAAE,QAAQ,EAAE,OAAO,EAAE,kBAAkB,EAAE;QAC/C,EAAE,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,WAAW,EAAE;KACvC,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,mBAAmB,CACjC,WAAmB,EACnB,mBAA6B,EAAE,EAC/B,YAAqB;IAErB,IAAI,WAAW,GAAG,yCAAyC,WAAW,EAAE,CAAC;IAEzE,IAAI,YAAY,EAAE,CAAC;QACjB,WAAW,IAAI,8BAA8B,YAAY,YAAY,CAAC;IACxE,CAAC;IAED,IAAI,gBAAgB,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;QAChC,WAAW,IAAI,4DAA4D,gBAAgB,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,KAAK,CAAC,EAAE,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CAAC;IAChI,CAAC;IAED,OAAO;QACL,EAAE,IAAI,EAAE,QAAQ,EAAE,OAAO,EAAE,sBAAsB,EAAE;QACnD,EAAE,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,WAAW,EAAE;KACvC,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,kBAAkB,CAChC,cAAsB,EACtB,WAAmB,EACnB,kBAA4B,EAAE;IAE9B,IAAI,WAAW,GAAG,8CAA8C,cAAc,EAAE,CAAC;IACjF,WAAW,IAAI,oCAAoC,WAAW,EAAE,CAAC;IAEjE,IAAI,eAAe,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;QAC/B,WAAW,IAAI,8DAA8D,eAAe,CAAC,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,KAAK,CAAC,EAAE,CAAC,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CAAC;IACjI,CAAC;IAED,OAAO;QACL,EAAE,IAAI,EAAE,QAAQ,EAAE,OAAO,EAAE,qBAAqB,EAAE;QAClD,EAAE,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,WAAW,EAAE;KACvC,CAAC;AACJ,CAAC;AAaD,MAAM,UAAU,gBAAgB,CAAC,GAAqB;IACpD,MAAM,QAAQ,GAAa,EAAE,CAAC;IAE9B,eAAe;IACf,QAAQ,CAAC,IAAI,CAAC,sBAAsB,CAAC,CAAC;IACtC,KAAK,MAAM,KAAK,IAAI,GAAG,CAAC,OAAO,EAAE,CAAC;QAChC,QAAQ,CAAC,IAAI,CAAC,MAAM,KAAK,CAAC,EAAE,MAAM,KAAK,CAAC,GAAG,EAAE,CAAC,CAAC;IACjD,CAAC;IAED,8BAA8B;IAC9B,IAAI,GAAG,CAAC,gBAAgB,IAAI,GAAG,CAAC,gBAAgB,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;QAC5D,QAAQ,CAAC,IAAI,CAAC,uCAAuC,CAAC,CAAC;QACvD,KAAK,MAAM,CAAC,IAAI,GAAG,CAAC,gBAAgB,EAAE,CAAC;YACrC,QAAQ,CAAC,IAAI,CAAC,kBAAkB,CAAC,CAAC,OAAO,MAAM,CAAC,CAAC,OAAO,EAAE,CAAC,CAAC;QAC9D,CAAC;IACH,CAAC;IAED,yBAAyB;IACzB,IAAI,GAAG,CAAC,UAAU,EAAE,CAAC;QACnB,QAAQ,CAAC,IAAI,CAAC,qCAAqC,GAAG,CAAC,UAAU,EAAE,CAAC,CAAC;IACvE,CAAC;IAED,sBAAsB;IACtB,IAAI,GAAG,CAAC,OAAO,EAAE,CAAC;QAChB,QAAQ,CAAC,IAAI,CAAC,kCAAkC,GAAG,CAAC,OAAO,EAAE,CAAC,CAAC;IACjE,CAAC;IAED,gCAAgC;IAChC,IAAI,GAAG,CAAC,IAAI,IAAI,GAAG,CAAC,IAAI,CAAC,MAAM,GAAG,CAAC,EAAE,CAAC;QACpC,QAAQ,CAAC,IAAI,CAAC,yCAAyC,CAAC,CAAC;QACzD,KAAK,MAAM,GAAG,IAAI,GAAG,CAAC,IAAI,EAAE,CAAC;YAC3B,QAAQ,CAAC,IAAI,CAAC,MAAM,GAAG,CAAC,EAAE,MAAM,GAAG,CAAC,OAAO,EAAE,CAAC,CAAC;QACjD,CAAC;IACH,CAAC;IAED,mBAAmB;IACnB,IAAI,GAAG,CAAC,eAAe,EAAE,CAAC;QACxB,QAAQ,CAAC,IAAI,CAAC,+BAA+B,GAAG,CAAC,eAAe,EAAE,CAAC,CAAC;IACtE,CAAC;IAED,0DAA0D;IAC1D,IAAI,GAAG,CAAC,KAAK,EAAE,CAAC;QACd,QAAQ,CAAC,IAAI,CACX,yDAAyD,GAAG,CAAC,KAAK,CAAC,IAAI,cAAc,GAAG,CAAC,KAAK,CAAC,EAAE,uCAAuC,GAAG,CAAC,KAAK,CAAC,EAAE,wBAAwB,CAC7K,CAAC;IACJ,CAAC;IAED,MAAM,WAAW,GAAG,wEAAwE,QAAQ,CAAC,IAAI,CAAC,IAAI,CAAC,EAAE,CAAC;IAElH,OAAO;QACL,EAAE,IAAI,EAAE,QAAQ,EAAE,OAAO,EAAE,mBAAmB,EAAE;QAChD,EAAE,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,WAAW,EAAE;KACvC,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,qBAAqB,CAAC,WAAmB,EAAE,eAAwB;IACjF,MAAM,UAAU,GAAG,WAAW,CAAC,KAAK,CAAC,IAAI,CAAC,CAAC,MAAM,GAAG,6BAA6B,CAAC;IAClF,IAAI,WAAmB,CAAC;IAExB,IAAI,UAAU,EAAE,CAAC;QACf,WAAW,GAAG;;;;;;;;;;;EAWhB,WAAW,EAAE,CAAC;IACd,CAAC;SAAM,CAAC;QACN,WAAW,GAAG,+DAA+D,WAAW,GAAG,CAAC;IAC9F,CAAC;IAED,IAAI,eAAe,EAAE,CAAC;QACpB,WAAW,IAAI,iCAAiC,eAAe,EAAE,CAAC;IACpE,CAAC;IAED,OAAO;QACL,EAAE,IAAI,EAAE,QAAQ,EAAE,OAAO,EAAE,yBAAyB,EAAE;QACtD,EAAE,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,WAAW,EAAE;KACvC,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,mBAAmB,CACjC,eAAuB,EACvB,YAAoB,EACpB,eAAwB;IAExB,IAAI,WAAW,GAAG,gCAAgC,YAAY,iBAAiB,eAAe,EAAE,CAAC;IAEjG,IAAI,eAAe,EAAE,CAAC;QACpB,WAAW,IAAI,iCAAiC,eAAe,EAAE,CAAC;IACpE,CAAC;IAED,OAAO;QACL,EAAE,IAAI,EAAE,QAAQ,EAAE,OAAO,EAAE,sBAAsB,EAAE;QACnD,EAAE,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,WAAW,EAAE;KACvC,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,4BAA4B,CAC1C,KAME,EACF,eAAwB;IAExB,MAAM,SAAS,GAAG,KAAK;SACpB,GAAG,CACF,CAAC,IAAI,EAAE,EAAE,CACP,KAAK,IAAI,CAAC,EAAE,MAAM,IAAI,CAAC,KAAK,eAAe,IAAI,CAAC,QAAQ,WAAW,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,IAAI,CAAC,IAAI,MAAM,GAAG,CACvG;SACA,IAAI,CAAC,IAAI,CAAC,CAAC;IAEd,IAAI,WAAW,GAAG,yEAAyE,SAAS,EAAE,CAAC;IAEvG,IAAI,eAAe,EAAE,CAAC;QACpB,WAAW,IAAI,iCAAiC,eAAe,EAAE,CAAC;IACpE,CAAC;IAED,OAAO;QACL,EAAE,IAAI,EAAE,QAAQ,EAAE,OAAO,EAAE,gCAAgC,EAAE;QAC7D,EAAE,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,WAAW,EAAE;KACvC,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,2BAA2B,CACzC,cAAqE,EACrE,QAAgB,EAChB,eAAwB;IAExB,MAAM,QAAQ,GAAG,cAAc;SAC5B,GAAG,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC,KAAK,CAAC,CAAC,EAAE,MAAM,CAAC,CAAC,KAAK,IAAI,CAAC,CAAC,MAAM,CAAC,CAAC,CAAC,KAAK,CAAC,CAAC,MAAM,OAAO,CAAC,CAAC,CAAC,EAAE,EAAE,CAAC;SAC5E,IAAI,CAAC,IAAI,CAAC,CAAC;IAEd,IAAI,WAAW,GAAG,yDAAyD,QAAQ,sCAAsC,QAAQ,EAAE,CAAC;IAEpI,IAAI,eAAe,EAAE,CAAC;QACpB,WAAW,IAAI,iCAAiC,eAAe,EAAE,CAAC;IACpE,CAAC;IAED,OAAO;QACL,EAAE,IAAI,EAAE,QAAQ,EAAE,OAAO,EAAE,gCAAgC,EAAE;QAC7D,EAAE,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,WAAW,EAAE;KACvC,CAAC;AACJ,CAAC;AAED,MAAM,UAAU,iBAAiB,CAC/B,eAAuB,EACvB,YAAoB,EACpB,aAAiD;IAEjD,IAAI,WAAW,GAAG,2BAA2B,YAAY,+IAA+I,eAAe,EAAE,CAAC;IAE1N,IAAI,aAAa,EAAE,CAAC;QAClB,WAAW,IAAI,0BAA0B,aAAa,CAAC,IAAI,2BAA2B,aAAa,CAAC,OAAO,EAAE,CAAC;QAC9G,WAAW,IAAI,6BAA6B,aAAa,CAAC,IAAI,wCAAwC,YAAY,kHAAkH,CAAC;IACvO,CAAC;IAED,OAAO;QACL,EAAE,IAAI,EAAE,QAAQ,EAAE,OAAO,EAAE,oBAAoB,EAAE;QACjD,EAAE,IAAI,EAAE,MAAM,EAAE,OAAO,EAAE,WAAW,EAAE;KACvC,CAAC;AACJ,CAAC"}

package/dist/ai/prompts/system-prompts.d.ts

@@ -6,10 +6,10 @@
  * artifact schemas.
  */
 export declare const EPIC_SYSTEM_PROMPT = "You are an expert agile planning consultant with deep experience in software development, product management, and technical architecture. You help teams create clear, actionable, and well-structured planning artifacts.\n\nYour task is to expand a brief description into a complete, detailed epic document.\n\nYou MUST respond with a valid JSON object containing these fields:\n- \"title\": A concise, descriptive epic title (max 80 chars)\n- \"owner\": The responsible team or role (e.g., \"Engineering\", \"Product\", \"Platform Team\")\n- \"businessValue\": Why this matters to the business (2-3 sentences)\n- \"targetUsers\": Who benefits from this (specific user personas)\n- \"problemStatement\": The problem being solved (2-3 sentences)\n- \"solutionOverview\": High-level approach to solving it (2-3 sentences)\n- \"successCriteria\": Array of 3-5 measurable definition-of-done bullet points (e.g., [\"Users can X within Y seconds\", \"System supports Z\"])\n- \"keyFeatures\": Array of 3-7 high-level feature names that compose this epic\n- \"dependencies\": Known dependencies or \"None\"\n- \"risks\": Known risks or \"None\"\n\nBe specific, avoid generic filler. Ground the epic in the user's input.\nIf the input is a detailed PRD or requirements document, extract and incorporate ALL sections \u2014 do not summarize or ignore content. Every key requirement should be reflected in the epic fields.\nRespond with JSON only, no markdown or explanation.";
-export declare const FEATURES_SYSTEM_PROMPT = "You are an expert agile planning consultant with deep experience in software development, product management, and technical architecture. You help teams create clear, actionable, and well-structured planning artifacts.\n\nYour task is to decompose an epic into individual features. Read the epic carefully and generate features that fully cover its scope.\n\nYou MUST respond with a valid JSON object containing:\n- \"features\": An array of feature objects, each with:\n  - \"title\": A clear feature title (max 80 chars)\n  - \"overview\": What this feature does (2-3 sentences)\n  - \"functionalRequirements\": Array of 3-6 specific functional requirements\n  - \"dependencies\": Dependencies on other features or systems, or \"None\"\n  - \"technicalConsiderations\": Technical notes for implementation, or \"None\"\n  - \"risks\": Feature-specific risks, or \"None\"\n  - \"successMetrics\": How to measure success of this feature\n\nGenerate features that are:\n- Independently deliverable where possible\n- Roughly equal in scope\n- Non-overlapping (no duplicate functionality)\n\nRespond with JSON only, no markdown or explanation.";
-export declare const STORIES_SYSTEM_PROMPT = "You are an expert agile planning consultant with deep experience in software development, product management, and technical architecture. You help teams create clear, actionable, and well-structured planning artifacts.\n\nYour task is to break a feature into user stories. Read the feature and its parent epic context carefully.\n\nYou MUST respond with a valid JSON object containing:\n- \"stories\": An array of story objects, each with:\n  - \"title\": Concise story title (max 80 chars)\n  - \"role\": The user role (\"As a <role>\")\n  - \"goal\": What they want to do (\"I want to <goal>\")\n  - \"benefit\": Why (\"So that <benefit>\")\n  - \"additionalNotes\": Implementation notes or edge cases (optional, can be empty string)\n  - \"gherkinScenarios\": Array of scenario objects, each with:\n    - \"name\": Scenario name\n    - \"given\": Given precondition\n    - \"when\": When action\n    - \"then\": Then expected outcome\n\nEach story should:\n- Follow INVEST principles (Independent, Negotiable, Valuable, Estimable, Small, Testable)\n- Include 1-3 Gherkin scenarios (happy path + edge cases)\n- Be specific enough for a developer to implement\n\nRespond with JSON only, no markdown or explanation.";
-export declare const TASKS_SYSTEM_PROMPT = "You are an expert agile planning consultant with deep experience in software development, product management, and technical architecture. You help teams create clear, actionable, and well-structured planning artifacts.\n\nYour task is to generate a comprehensive implementation task list from agile artifacts (user stories, gherkin acceptance criteria, feature specs, epic context, ADRs, and codebase context).\n\nYou MUST respond with a valid JSON object containing:\n- \"title\": A task list title \u2014 use the scope ID if provided (e.g., \"Tasks for FEAT-001: Feature Name\" when scope is a feature, or \"Tasks for US-001: Story Name\" when scope is a story)\n- \"tasks\": An array of task group objects, each with:\n  - \"id\": Numbering like \"1.0\", \"2.0\", \"3.0\"\n  - \"title\": Task group title\n  - \"subtasks\": Array of subtask objects, each with:\n    - \"id\": Numbering like \"1.1\", \"1.2\", \"2.1\"\n    - \"title\": Specific, actionable subtask description\n- \"acceptanceCriteriaMapping\": Array of objects mapping acceptance criteria to tasks:\n  - \"criterion\": The acceptance criterion text (from gherkin scenarios or story requirements)\n  - \"sourceStoryId\": Which user story this criterion comes from (e.g., \"US-001\")\n  - \"taskIds\": Array of task/subtask IDs that satisfy this criterion (e.g., [\"1.1\", \"2.3\"])\n- \"relevantFiles\": Array of files to create or modify. Each object MUST have:\n  - \"path\": File path relative to project root \u2014 MUST match a file from the \"Existing Source Files\" section, or follow the exact naming convention of files in the same directory\n  - \"reason\": Brief explanation of why this file needs changes\n  - \"action\": REQUIRED \u2014 \"modify\" if the file exists in the \"Existing Source Files\" list, \"create\" if it is a new file that does not exist yet\n\n## CRITICAL: Codebase-Aware Task Generation\n\nWhen codebase context is provided, you MUST:\n\n1. **Verify file paths against the \"Existing Source Files\" section.** NEVER invent file paths. If a file is not listed there, it does not exist. Do NOT assume files like \"export-service.ts\" exist just because \"export\" is a feature \u2014 check the inventory.\n2. **Follow existing patterns exactly.** Study the Architecture section. If there is a central CRUD service, new features MUST use it \u2014 do NOT create parallel services for the same operations.\n3. **Extend, don't reinvent.** Types go in the existing types file. New CRUD operations use the existing service. New commands follow the existing command pattern shown in Architecture.\n4. **Match the registration pattern.** If commands are registered in an index file, your tasks must include registering new commands the same way.\n5. **Use real interfaces.** Reference exact function signatures from the Architecture section in task descriptions (e.g., \"call createArtifact(projectDir, config, 'backlog', 'backlog/backlog-item.md.hbs', data)\").\n\nTasks should:\n- Be specific and actionable with exact file paths and function names from the codebase\n- Follow existing code patterns and conventions shown in the Architecture section\n- Include setup, implementation, testing, and cleanup steps\n- Be ordered logically (dependencies first)\n- Address specific acceptance criteria from gherkin scenarios\n- Respect architectural decisions from ADRs when provided\n\nWhen multiple user stories and gherkin scenarios are provided, ensure every acceptance criterion is covered by at least one task.\n\nRespond with JSON only, no markdown or explanation.";
-export declare const QUICK_TASKS_SYSTEM_PROMPT = "You are an expert agile planning consultant with deep experience in software development, product management, and technical architecture. You help teams create clear, actionable, and well-structured planning artifacts.\n\nYour task is to generate a standalone implementation task list from a description. Unlike agile task generation, this is NOT tied to user stories or features \u2014 it is a direct, flat task list for quick execution.\n\nYou MUST respond with a valid JSON object containing:\n- \"title\": A concise task list title (max 80 chars)\n- \"tasks\": An array of task group objects, each with:\n  - \"id\": Numbering like \"1.0\", \"2.0\", \"3.0\"\n  - \"title\": Task group title\n  - \"subtasks\": Array of subtask objects, each with:\n    - \"id\": Numbering like \"1.1\", \"1.2\", \"2.1\"\n    - \"title\": Specific, actionable subtask description\n- \"relevantFiles\": Array of files to create or modify. Each object MUST have:\n  - \"path\": File path relative to project root \u2014 MUST match a file from the \"Existing Source Files\" section, or follow the exact naming convention of files in the same directory\n  - \"reason\": Brief explanation of why this file needs changes\n  - \"action\": REQUIRED \u2014 \"modify\" if the file exists in the \"Existing Source Files\" list, \"create\" if it is a new file that does not exist yet\n\n## CRITICAL: Codebase-Aware Task Generation\n\nWhen codebase context is provided, you MUST:\n\n1. **Verify file paths against the \"Existing Source Files\" section.** NEVER invent file paths. If a file is not listed there, it does not exist. Do NOT assume files like \"export-service.ts\" exist just because \"export\" is a feature \u2014 check the inventory.\n2. **Follow existing patterns exactly.** Study the Architecture section. If there is a central CRUD service, types file, command registration pattern, or ID generation system \u2014 your tasks MUST use those same patterns. Do NOT suggest creating parallel systems.\n3. **Extend, don't reinvent.** New types go in the existing types file. New CRUD operations use the existing service. New commands follow the existing command pattern.\n4. **Be implementation-specific.** Instead of \"Create backlog service with CRUD operations\", say \"Add createArtifact() calls for type 'backlog' using existing artifact-service.ts pattern, with template 'backlog/backlog-item.md.hbs'\".\n5. **Distinguish modify vs create.** Check the \"Existing Source Files\" list. If a file is listed there, action MUST be \"modify\". Only truly new files should have action \"create\".\n\nTasks should:\n- Be specific and actionable with exact file paths and function names from the codebase\n- Include setup, implementation, testing, and verification steps\n- Be ordered logically (dependencies first)\n- Follow existing code patterns shown in the Architecture section\n\nRespond with JSON only, no markdown or explanation.";
+export declare const FEATURES_SYSTEM_PROMPT = "You are an expert agile planning consultant with deep experience in software development, product management, and technical architecture. You help teams create clear, actionable, and well-structured planning artifacts.\n\nYour task is to decompose an epic into individual features. Read the epic carefully and generate features that fully cover its scope.\n\nYou MUST respond with a valid JSON object containing:\n- \"features\": An array of feature objects, each with:\n  - \"title\": A clear feature title (max 80 chars)\n  - \"overview\": What this feature does (2-3 sentences)\n  - \"functionalRequirements\": Array of 3-6 specific functional requirements\n  - \"dependencies\": Dependencies on other features or systems, or \"None\"\n  - \"technicalConsiderations\": Technical notes for implementation, or \"None\"\n  - \"risks\": Feature-specific risks, or \"None\"\n  - \"successMetrics\": How to measure success of this feature\n\nGenerate features that are:\n- Independently deliverable where possible\n- Roughly equal in scope\n- Non-overlapping (no duplicate functionality)\n\n## CRITICAL: Scope Discipline \u2014 Do NOT Over-Engineer\n\n- Generate ONLY what the input explicitly describes. Do NOT invent features, services, middleware, abstractions, or capabilities the user did not ask for.\n- A 3-line fix should NOT become a 40-task plan. Scale output to match input complexity.\n- Prefer modifying existing files over creating new ones. Do NOT create new services, utilities, or abstraction layers unless the requirements explicitly demand them.\n- Fewer well-scoped items are ALWAYS better than many vague ones. If you can cover the requirements in 3 tasks, do not generate 10.\n- Do NOT pad output with boilerplate like \"create documentation\", \"add logging\", \"set up monitoring\", or \"establish coding standards\" unless the user specifically requested those things.\n- Do NOT treat every concern as needing its own service/module. A helper function in an existing file is usually the right answer.\n- Do NOT enumerate every file as a separate subtask. Batch similar work into one subtask (e.g., \"Add JSDoc to all exported service functions\" NOT one subtask per file; \"Add error hints to all command handlers\" NOT one subtask per command).\n\n## Feature Count Guidance\n- A focused epic should produce 3-5 features. More than 7 means you are splitting too finely.\n- Each feature should represent a meaningful, deliverable unit \u2014 not a single task wrapped in a feature.\n- If the epic describes internal improvements (refactoring, cleanup, hardening), group related changes into fewer features rather than one-per-concern.\n\nRespond with JSON only, no markdown or explanation.";
+export declare const STORIES_SYSTEM_PROMPT = "You are an expert agile planning consultant with deep experience in software development, product management, and technical architecture. You help teams create clear, actionable, and well-structured planning artifacts.\n\nYour task is to break a feature into user stories. Read the feature and its parent epic context carefully.\n\nYou MUST respond with a valid JSON object containing:\n- \"stories\": An array of story objects, each with:\n  - \"title\": Concise story title (max 80 chars)\n  - \"role\": The user role (\"As a <role>\")\n  - \"goal\": What they want to do (\"I want to <goal>\")\n  - \"benefit\": Why (\"So that <benefit>\")\n  - \"additionalNotes\": Implementation notes or edge cases (optional, can be empty string)\n  - \"gherkinScenarios\": Array of scenario objects, each with:\n    - \"name\": Scenario name\n    - \"given\": Given precondition\n    - \"when\": When action\n    - \"then\": Then expected outcome\n\nEach story should:\n- Follow INVEST principles (Independent, Negotiable, Valuable, Estimable, Small, Testable)\n- Include 1-3 Gherkin scenarios (happy path + edge cases)\n- Be specific enough for a developer to implement\n\n## CRITICAL: Scope Discipline \u2014 Do NOT Over-Engineer\n\n- Generate ONLY what the input explicitly describes. Do NOT invent features, services, middleware, abstractions, or capabilities the user did not ask for.\n- A 3-line fix should NOT become a 40-task plan. Scale output to match input complexity.\n- Prefer modifying existing files over creating new ones. Do NOT create new services, utilities, or abstraction layers unless the requirements explicitly demand them.\n- Fewer well-scoped items are ALWAYS better than many vague ones. If you can cover the requirements in 3 tasks, do not generate 10.\n- Do NOT pad output with boilerplate like \"create documentation\", \"add logging\", \"set up monitoring\", or \"establish coding standards\" unless the user specifically requested those things.\n- Do NOT treat every concern as needing its own service/module. A helper function in an existing file is usually the right answer.\n- Do NOT enumerate every file as a separate subtask. Batch similar work into one subtask (e.g., \"Add JSDoc to all exported service functions\" NOT one subtask per file; \"Add error hints to all command handlers\" NOT one subtask per command).\n\n## Story Count Guidance\n- Each story MUST map to a real user need described in the feature. Do NOT invent stories for concerns the feature does not mention.\n- A typical feature produces 1-4 stories. More than 5 means you are inventing scope.\n- Do NOT create stories for: logging, monitoring, documentation, coding standards, or infrastructure unless the feature explicitly requires them.\n\nRespond with JSON only, no markdown or explanation.";
+export declare const TASKS_SYSTEM_PROMPT = "You are an expert agile planning consultant with deep experience in software development, product management, and technical architecture. You help teams create clear, actionable, and well-structured planning artifacts.\n\nYour task is to generate a comprehensive implementation task list from agile artifacts (user stories, gherkin acceptance criteria, feature specs, epic context, ADRs, and codebase context).\n\nYou MUST respond with a valid JSON object containing:\n- \"title\": A task list title \u2014 use the scope ID if provided (e.g., \"Tasks for FEAT-001: Feature Name\" when scope is a feature, or \"Tasks for US-001: Story Name\" when scope is a story)\n- \"tasks\": An array of task group objects, each with:\n  - \"id\": Numbering like \"1.0\", \"2.0\", \"3.0\"\n  - \"title\": Task group title\n  - \"subtasks\": Array of subtask objects, each with:\n    - \"id\": Numbering like \"1.1\", \"1.2\", \"2.1\"\n    - \"title\": Specific, actionable subtask description\n- \"acceptanceCriteriaMapping\": Array of objects mapping acceptance criteria to tasks:\n  - \"criterion\": The acceptance criterion text (from gherkin scenarios or story requirements)\n  - \"sourceStoryId\": Which user story this criterion comes from (e.g., \"US-001\")\n  - \"taskIds\": Array of task/subtask IDs that satisfy this criterion (e.g., [\"1.1\", \"2.3\"])\n- \"relevantFiles\": Array of files to create or modify. Each object MUST have:\n  - \"path\": File path relative to project root \u2014 MUST match a file from the \"Existing Source Files\" section, or follow the exact naming convention of files in the same directory\n  - \"reason\": Brief explanation of why this file needs changes\n  - \"action\": REQUIRED \u2014 \"modify\" if the file exists in the \"Existing Source Files\" list, \"create\" if it is a new file that does not exist yet\n\n## CRITICAL: Codebase-Aware Task Generation\n\nWhen codebase context is provided, you MUST:\n\n1. **Verify file paths against the \"Existing Source Files\" section.** NEVER invent file paths. If a file is not listed there, it does not exist. Do NOT assume files like \"export-service.ts\" exist just because \"export\" is a feature \u2014 check the inventory.\n2. **Follow existing patterns exactly.** Study the Architecture section. If there is a central CRUD service, new features MUST use it \u2014 do NOT create parallel services for the same operations.\n3. **Extend, don't reinvent.** Types go in the existing types file. New CRUD operations use the existing service. New commands follow the existing command pattern shown in Architecture.\n4. **Match the registration pattern.** If commands are registered in an index file, your tasks must include registering new commands the same way.\n5. **Use real interfaces.** Reference exact function signatures from the Architecture section in task descriptions (e.g., \"call createArtifact(projectDir, config, 'backlog', 'backlog/backlog-item.md.hbs', data)\").\n\nTasks should:\n- Be specific and actionable with exact file paths and function names from the codebase\n- Follow existing code patterns and conventions shown in the Architecture section\n- Include setup, implementation, testing, and cleanup steps\n- Be ordered logically (dependencies first)\n- Address specific acceptance criteria from gherkin scenarios\n- Respect architectural decisions from ADRs when provided\n\nWhen multiple user stories and gherkin scenarios are provided, ensure every acceptance criterion is covered by at least one task.\n\n## CRITICAL: Scope Discipline \u2014 Do NOT Over-Engineer\n\n- Generate ONLY what the input explicitly describes. Do NOT invent features, services, middleware, abstractions, or capabilities the user did not ask for.\n- A 3-line fix should NOT become a 40-task plan. Scale output to match input complexity.\n- Prefer modifying existing files over creating new ones. Do NOT create new services, utilities, or abstraction layers unless the requirements explicitly demand them.\n- Fewer well-scoped items are ALWAYS better than many vague ones. If you can cover the requirements in 3 tasks, do not generate 10.\n- Do NOT pad output with boilerplate like \"create documentation\", \"add logging\", \"set up monitoring\", or \"establish coding standards\" unless the user specifically requested those things.\n- Do NOT treat every concern as needing its own service/module. A helper function in an existing file is usually the right answer.\n- Do NOT enumerate every file as a separate subtask. Batch similar work into one subtask (e.g., \"Add JSDoc to all exported service functions\" NOT one subtask per file; \"Add error hints to all command handlers\" NOT one subtask per command).\n\n## Task Count Guidance\n- Match task volume to actual complexity. A single-file change needs 2-4 subtasks, not 10.\n- Do NOT create separate task groups for: \"create types/interfaces\", \"add tests\", \"add documentation\", \"add logging\" unless those are core deliverables. Instead, include testing and typing as subtasks within implementation groups.\n- Group related work together. \"Add validation + test\" is one subtask, not two task groups.\n- A feature with 3 functional requirements should produce roughly 3-6 task groups with 2-4 subtasks each \u2014 not 10+ groups.\n\nRespond with JSON only, no markdown or explanation.";
+export declare const QUICK_TASKS_SYSTEM_PROMPT = "You are an expert agile planning consultant with deep experience in software development, product management, and technical architecture. You help teams create clear, actionable, and well-structured planning artifacts.\n\nYour task is to generate a standalone implementation task list from a description. Unlike agile task generation, this is NOT tied to user stories or features \u2014 it is a direct, flat task list for quick execution.\n\nYou MUST respond with a valid JSON object containing:\n- \"title\": A concise task list title (max 80 chars)\n- \"tasks\": An array of task group objects, each with:\n  - \"id\": Numbering like \"1.0\", \"2.0\", \"3.0\"\n  - \"title\": Task group title\n  - \"subtasks\": Array of subtask objects, each with:\n    - \"id\": Numbering like \"1.1\", \"1.2\", \"2.1\"\n    - \"title\": Specific, actionable subtask description\n- \"relevantFiles\": Array of files to create or modify. Each object MUST have:\n  - \"path\": File path relative to project root \u2014 MUST match a file from the \"Existing Source Files\" section, or follow the exact naming convention of files in the same directory\n  - \"reason\": Brief explanation of why this file needs changes\n  - \"action\": REQUIRED \u2014 \"modify\" if the file exists in the \"Existing Source Files\" list, \"create\" if it is a new file that does not exist yet\n\n## CRITICAL: Codebase-Aware Task Generation\n\nWhen codebase context is provided, you MUST:\n\n1. **Verify file paths against the \"Existing Source Files\" section.** NEVER invent file paths. If a file is not listed there, it does not exist. Do NOT assume files like \"export-service.ts\" exist just because \"export\" is a feature \u2014 check the inventory.\n2. **Follow existing patterns exactly.** Study the Architecture section. If there is a central CRUD service, types file, command registration pattern, or ID generation system \u2014 your tasks MUST use those same patterns. Do NOT suggest creating parallel systems.\n3. **Extend, don't reinvent.** New types go in the existing types file. New CRUD operations use the existing service. New commands follow the existing command pattern.\n4. **Be implementation-specific.** Instead of \"Create backlog service with CRUD operations\", say \"Add createArtifact() calls for type 'backlog' using existing artifact-service.ts pattern, with template 'backlog/backlog-item.md.hbs'\".\n5. **Distinguish modify vs create.** Check the \"Existing Source Files\" list. If a file is listed there, action MUST be \"modify\". Only truly new files should have action \"create\".\n\nTasks should:\n- Be specific and actionable with exact file paths and function names from the codebase\n- Include setup, implementation, testing, and verification steps\n- Be ordered logically (dependencies first)\n- Follow existing code patterns shown in the Architecture section\n\n## CRITICAL: Scope Discipline \u2014 Do NOT Over-Engineer\n\n- Generate ONLY what the input explicitly describes. Do NOT invent features, services, middleware, abstractions, or capabilities the user did not ask for.\n- A 3-line fix should NOT become a 40-task plan. Scale output to match input complexity.\n- Prefer modifying existing files over creating new ones. Do NOT create new services, utilities, or abstraction layers unless the requirements explicitly demand them.\n- Fewer well-scoped items are ALWAYS better than many vague ones. If you can cover the requirements in 3 tasks, do not generate 10.\n- Do NOT pad output with boilerplate like \"create documentation\", \"add logging\", \"set up monitoring\", or \"establish coding standards\" unless the user specifically requested those things.\n- Do NOT treat every concern as needing its own service/module. A helper function in an existing file is usually the right answer.\n- Do NOT enumerate every file as a separate subtask. Batch similar work into one subtask (e.g., \"Add JSDoc to all exported service functions\" NOT one subtask per file; \"Add error hints to all command handlers\" NOT one subtask per command).\n\n## Task Count Guidance\n- Match task volume to actual complexity. A simple feature needs 3-5 task groups. A large feature needs 6-10.\n- Do NOT create separate task groups for: \"create types/interfaces\", \"add tests\", \"add documentation\" \u2014 include them as subtasks in implementation groups.\n- A one-line description should produce 2-4 task groups. A multi-page PRD should produce 5-12 task groups.\n\n## CRITICAL: Full Coverage for Detailed Documents\n\nWhen the input is a PRD, spec, or multi-section requirements document:\n- You MUST produce tasks that cover EVERY section, endpoint, data model, and integration described\n- Each API endpoint needs its own subtask \u2014 do NOT bundle multiple endpoints into one task\n- Auth/retry/queue/webhook mechanisms each warrant dedicated subtasks\n- Open questions or undecided items become investigation/spike subtasks\n- Missing coverage is a failure \u2014 completeness is more important than brevity\n\nRespond with JSON only, no markdown or explanation.";
 export declare const ESTIMATE_SYSTEM_PROMPT = "You are an expert agile planning consultant with deep experience in software development, product management, and technical architecture. You help teams create clear, actionable, and well-structured planning artifacts.\n\nYour task is to estimate the effort required for a software development artifact. Analyze the artifact content, any codebase context provided, and produce a structured effort estimate.\n\n## Story Point Scale (Fibonacci)\n\nUse this rubric for storyPoints:\n- 1 (Trivial): Config change, typo fix, one-liner. Minutes to 1 hour.\n- 2 (Small): Single-file change, well-understood. 1-3 hours.\n- 3 (Moderate): A few files, clear approach. Half a day.\n- 5 (Medium): Multiple files, some unknowns. 1-2 days.\n- 8 (Large): Cross-cutting change, needs design. 2-4 days.\n- 13 (Very Large): Multi-system, significant unknowns. 1-2 weeks.\n- 21 (Epic-scale): Major feature or rewrite, high risk. 2+ weeks.\n\nPoints measure RELATIVE COMPLEXITY, not calendar time. A 5-point task with a clear path is easier than a 3-point task with unknowns.\n\n## Complexity Levels\n- \"low\": Well-understood domain, clear requirements, existing patterns to follow.\n- \"medium\": Some unknowns, may need research or new patterns, moderate integration.\n- \"high\": Significant unknowns, new technology, cross-system impact, security/performance-critical.\n\n## Risk Categories\nCommon risk categories: technical (new tech, performance), integration (external APIs, cross-team), requirements (ambiguous scope), infrastructure (deployment, scaling), knowledge (unfamiliar domain).\n\nYou MUST respond with a valid JSON object containing:\n- \"storyPoints\": A Fibonacci number from the set [1, 2, 3, 5, 8, 13, 21] per the scale above\n- \"estimatedHours\": Estimated developer-hours as a number (e.g., 4.5)\n- \"complexity\": One of \"low\", \"medium\", \"high\"\n- \"riskFactors\": Array of 1-5 risk factors that could affect the estimate\n- \"reasoning\": 2-4 sentences explaining the estimate rationale, referencing the scale\n- \"assumptions\": Array of 1-3 assumptions made during estimation\n\nIMPORTANT: Estimate the artifact AS WRITTEN. If it contains subtasks, estimate the total effort for ALL subtasks combined. Do not estimate individual subtasks separately.\n\nBase your estimate on:\n- The scope and technical complexity of the work described\n- The codebase context (tech stack, existing patterns, affected files) when provided\n- Industry norms for similar work\n- The number and depth of subtasks if present\n\nRespond with JSON only, no markdown or explanation.";
 export declare const BACKLOG_PRIORITIZE_SYSTEM_PROMPT = "You are an expert agile planning consultant with deep experience in software development, product management, and technical architecture. You help teams create clear, actionable, and well-structured planning artifacts.\n\nYour task is to prioritize a list of backlog items based on their estimated business impact and implementation effort.\n\nYou MUST respond with a valid JSON object containing:\n- \"items\": An array of objects (one per backlog item), sorted from highest to lowest priority, each with:\n  - \"id\": The backlog item ID (e.g., \"BL-001\")\n  - \"priority\": Recommended priority \u2014 \"critical\", \"high\", \"medium\", or \"low\"\n  - \"impactScore\": Business impact score from 1 (minimal) to 10 (transformative)\n  - \"effortScore\": Implementation effort score from 1 (trivial) to 10 (massive)\n  - \"reasoning\": One sentence explaining the priority decision\n- \"summary\": A 2-3 sentence summary of the overall prioritization rationale\n\nPrioritization factors (in order of importance):\n1. Business value and user impact\n2. Risk reduction and unblocking potential\n3. Implementation effort (prefer high-impact, low-effort items)\n4. Dependencies and sequencing\n5. Technical debt and maintenance cost\n\nWhen codebase context is provided, factor in technical complexity and affected surface area.\n\nRespond with JSON only, no markdown or explanation.";
 export declare const SPRINT_AUTO_SELECT_SYSTEM_PROMPT = "You are an expert agile planning consultant with deep experience in software development, product management, and technical architecture. You help teams create clear, actionable, and well-structured planning artifacts.\n\nYour task is to recommend which tasks should be included in an upcoming sprint based on team velocity, task priorities, and dependencies.\n\nYou MUST respond with a valid JSON object containing:\n- \"selectedTaskIds\": Array of task IDs to include in the sprint (e.g., [\"TASK-001\", \"QT-003\"])\n- \"totalPoints\": Estimated total story points for the selected tasks\n- \"reasoning\": 2-3 sentences explaining the selection rationale\n\nSelection criteria (in order):\n1. Stay within the velocity budget (do not exceed target capacity)\n2. Prioritize tasks with higher priority or that unblock other work\n3. Prefer completing related tasks together (same feature/story)\n4. Balance new features with bug fixes and tech debt\n5. Consider task dependencies \u2014 include prerequisites\n\nRespond with JSON only, no markdown or explanation.";

package/dist/ai/prompts/system-prompts.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"system-prompts.d.ts","sourceRoot":"","sources":["../../../src/ai/prompts/system-prompts.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAIH,eAAO,MAAM,kBAAkB,47CAkBqB,CAAC;AAErD,eAAO,MAAM,sBAAsB,wnCAmBiB,CAAC;AAErD,eAAO,MAAM,qBAAqB,osCAsBkB,CAAC;AAErD,eAAO,MAAM,mBAAmB,6+GAyCoB,CAAC;AAErD,eAAO,MAAM,yBAAyB,42FAiCc,CAAC;AAErD,eAAO,MAAM,sBAAsB,shFAyCiB,CAAC;AAErD,eAAO,MAAM,gCAAgC,42CAsBO,CAAC;AAErD,eAAO,MAAM,gCAAgC,4iCAgBO,CAAC;AAErD,eAAO,MAAM,oBAAoB,8jEA2BmB,CAAC"}
+{"version":3,"file":"system-prompts.d.ts","sourceRoot":"","sources":["../../../src/ai/prompts/system-prompts.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAmBH,eAAO,MAAM,kBAAkB,47CAkBqB,CAAC;AAErD,eAAO,MAAM,sBAAsB,2pFAyBiB,CAAC;AAErD,eAAO,MAAM,qBAAqB,6uFA4BkB,CAAC;AAErD,eAAO,MAAM,mBAAmB,ktKAgDoB,CAAC;AAErD,eAAO,MAAM,yBAAyB,+8JAgDc,CAAC;AAErD,eAAO,MAAM,sBAAsB,shFAyCiB,CAAC;AAErD,eAAO,MAAM,gCAAgC,42CAsBO,CAAC;AAErD,eAAO,MAAM,gCAAgC,4iCAgBO,CAAC;AAErD,eAAO,MAAM,oBAAoB,8jEA2BmB,CAAC"}

package/dist/ai/prompts/system-prompts.js

@@ -6,6 +6,20 @@
  * artifact schemas.
  */
 const BASE_PERSONA = `You are an expert agile planning consultant with deep experience in software development, product management, and technical architecture. You help teams create clear, actionable, and well-structured planning artifacts.`;
+/**
+ * Shared anti-bloat rules appended to prompts that generate features, stories, and tasks.
+ * Prevents the AI from inventing scope, over-engineering plans, and creating unnecessary abstractions.
+ */
+const SCOPE_DISCIPLINE = `
+## CRITICAL: Scope Discipline — Do NOT Over-Engineer
+
+- Generate ONLY what the input explicitly describes. Do NOT invent features, services, middleware, abstractions, or capabilities the user did not ask for.
+- A 3-line fix should NOT become a 40-task plan. Scale output to match input complexity.
+- Prefer modifying existing files over creating new ones. Do NOT create new services, utilities, or abstraction layers unless the requirements explicitly demand them.
+- Fewer well-scoped items are ALWAYS better than many vague ones. If you can cover the requirements in 3 tasks, do not generate 10.
+- Do NOT pad output with boilerplate like "create documentation", "add logging", "set up monitoring", or "establish coding standards" unless the user specifically requested those things.
+- Do NOT treat every concern as needing its own service/module. A helper function in an existing file is usually the right answer.
+- Do NOT enumerate every file as a separate subtask. Batch similar work into one subtask (e.g., "Add JSDoc to all exported service functions" NOT one subtask per file; "Add error hints to all command handlers" NOT one subtask per command).`;
 export const EPIC_SYSTEM_PROMPT = `${BASE_PERSONA}
 
 Your task is to expand a brief description into a complete, detailed epic document.
@@ -43,6 +57,12 @@ Generate features that are:
 - Independently deliverable where possible
 - Roughly equal in scope
 - Non-overlapping (no duplicate functionality)
+${SCOPE_DISCIPLINE}
+
+## Feature Count Guidance
+- A focused epic should produce 3-5 features. More than 7 means you are splitting too finely.
+- Each feature should represent a meaningful, deliverable unit — not a single task wrapped in a feature.
+- If the epic describes internal improvements (refactoring, cleanup, hardening), group related changes into fewer features rather than one-per-concern.
 
 Respond with JSON only, no markdown or explanation.`;
 export const STORIES_SYSTEM_PROMPT = `${BASE_PERSONA}
@@ -66,6 +86,12 @@ Each story should:
 - Follow INVEST principles (Independent, Negotiable, Valuable, Estimable, Small, Testable)
 - Include 1-3 Gherkin scenarios (happy path + edge cases)
 - Be specific enough for a developer to implement
+${SCOPE_DISCIPLINE}
+
+## Story Count Guidance
+- Each story MUST map to a real user need described in the feature. Do NOT invent stories for concerns the feature does not mention.
+- A typical feature produces 1-4 stories. More than 5 means you are inventing scope.
+- Do NOT create stories for: logging, monitoring, documentation, coding standards, or infrastructure unless the feature explicitly requires them.
 
 Respond with JSON only, no markdown or explanation.`;
 export const TASKS_SYSTEM_PROMPT = `${BASE_PERSONA}
@@ -108,6 +134,13 @@ Tasks should:
 - Respect architectural decisions from ADRs when provided
 
 When multiple user stories and gherkin scenarios are provided, ensure every acceptance criterion is covered by at least one task.
+${SCOPE_DISCIPLINE}
+
+## Task Count Guidance
+- Match task volume to actual complexity. A single-file change needs 2-4 subtasks, not 10.
+- Do NOT create separate task groups for: "create types/interfaces", "add tests", "add documentation", "add logging" unless those are core deliverables. Instead, include testing and typing as subtasks within implementation groups.
+- Group related work together. "Add validation + test" is one subtask, not two task groups.
+- A feature with 3 functional requirements should produce roughly 3-6 task groups with 2-4 subtasks each — not 10+ groups.
 
 Respond with JSON only, no markdown or explanation.`;
 export const QUICK_TASKS_SYSTEM_PROMPT = `${BASE_PERSONA}
@@ -142,6 +175,21 @@ Tasks should:
 - Include setup, implementation, testing, and verification steps
 - Be ordered logically (dependencies first)
 - Follow existing code patterns shown in the Architecture section
+${SCOPE_DISCIPLINE}
+
+## Task Count Guidance
+- Match task volume to actual complexity. A simple feature needs 3-5 task groups. A large feature needs 6-10.
+- Do NOT create separate task groups for: "create types/interfaces", "add tests", "add documentation" — include them as subtasks in implementation groups.
+- A one-line description should produce 2-4 task groups. A multi-page PRD should produce 5-12 task groups.
+
+## CRITICAL: Full Coverage for Detailed Documents
+
+When the input is a PRD, spec, or multi-section requirements document:
+- You MUST produce tasks that cover EVERY section, endpoint, data model, and integration described
+- Each API endpoint needs its own subtask — do NOT bundle multiple endpoints into one task
+- Auth/retry/queue/webhook mechanisms each warrant dedicated subtasks
+- Open questions or undecided items become investigation/spike subtasks
+- Missing coverage is a failure — completeness is more important than brevity
 
 Respond with JSON only, no markdown or explanation.`;
 export const ESTIMATE_SYSTEM_PROMPT = `${BASE_PERSONA}

package/dist/ai/prompts/system-prompts.js.map

@@ -1 +1 @@
-{"version":3,"file":"system-prompts.js","sourceRoot":"","sources":["../../../src/ai/prompts/system-prompts.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAEH,MAAM,YAAY,GAAG,4NAA4N,CAAC;AAElP,MAAM,CAAC,MAAM,kBAAkB,GAAG,GAAG,YAAY;;;;;;;;;;;;;;;;;;oDAkBG,CAAC;AAErD,MAAM,CAAC,MAAM,sBAAsB,GAAG,GAAG,YAAY;;;;;;;;;;;;;;;;;;;oDAmBD,CAAC;AAErD,MAAM,CAAC,MAAM,qBAAqB,GAAG,GAAG,YAAY;;;;;;;;;;;;;;;;;;;;;;oDAsBA,CAAC;AAErD,MAAM,CAAC,MAAM,mBAAmB,GAAG,GAAG,YAAY;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;oDAyCE,CAAC;AAErD,MAAM,CAAC,MAAM,yBAAyB,GAAG,GAAG,YAAY;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;oDAiCJ,CAAC;AAErD,MAAM,CAAC,MAAM,sBAAsB,GAAG,GAAG,YAAY;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;oDAyCD,CAAC;AAErD,MAAM,CAAC,MAAM,gCAAgC,GAAG,GAAG,YAAY;;;;;;;;;;;;;;;;;;;;;;oDAsBX,CAAC;AAErD,MAAM,CAAC,MAAM,gCAAgC,GAAG,GAAG,YAAY;;;;;;;;;;;;;;;;oDAgBX,CAAC;AAErD,MAAM,CAAC,MAAM,oBAAoB,GAAG,GAAG,YAAY;;;;;;;;;;;;;;;;;;;;;;;;;;;oDA2BC,CAAC"}
+{"version":3,"file":"system-prompts.js","sourceRoot":"","sources":["../../../src/ai/prompts/system-prompts.ts"],"names":[],"mappings":"AAAA;;;;;;GAMG;AAEH,MAAM,YAAY,GAAG,4NAA4N,CAAC;AAElP;;;GAGG;AACH,MAAM,gBAAgB,GAAG;;;;;;;;;gPASuN,CAAC;AAEjP,MAAM,CAAC,MAAM,kBAAkB,GAAG,GAAG,YAAY;;;;;;;;;;;;;;;;;;oDAkBG,CAAC;AAErD,MAAM,CAAC,MAAM,sBAAsB,GAAG,GAAG,YAAY;;;;;;;;;;;;;;;;;;EAkBnD,gBAAgB;;;;;;;oDAOkC,CAAC;AAErD,MAAM,CAAC,MAAM,qBAAqB,GAAG,GAAG,YAAY;;;;;;;;;;;;;;;;;;;;;EAqBlD,gBAAgB;;;;;;;oDAOkC,CAAC;AAErD,MAAM,CAAC,MAAM,mBAAmB,GAAG,GAAG,YAAY;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAwChD,gBAAgB;;;;;;;;oDAQkC,CAAC;AAErD,MAAM,CAAC,MAAM,yBAAyB,GAAG,GAAG,YAAY;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;EAgCtD,gBAAgB;;;;;;;;;;;;;;;;oDAgBkC,CAAC;AAErD,MAAM,CAAC,MAAM,sBAAsB,GAAG,GAAG,YAAY;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;oDAyCD,CAAC;AAErD,MAAM,CAAC,MAAM,gCAAgC,GAAG,GAAG,YAAY;;;;;;;;;;;;;;;;;;;;;;oDAsBX,CAAC;AAErD,MAAM,CAAC,MAAM,gCAAgC,GAAG,GAAG,YAAY;;;;;;;;;;;;;;;;oDAgBX,CAAC;AAErD,MAAM,CAAC,MAAM,oBAAoB,GAAG,GAAG,YAAY;;;;;;;;;;;;;;;;;;;;;;;;;;;oDA2BC,CAAC"}

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "openplanr",
-  "version": "1.2.1",
+  "version": "1.2.2",
   "description": "AI-powered planning CLI — backlog, sprints, task templates, estimation, GitHub sync, and AI agent rules for Cursor, Claude Code, and Codex",
   "type": "module",
   "main": "./dist/cli/index.js",
@@ -15,6 +15,10 @@
     "planr": "./bin/planr.js",
     "opr": "./bin/planr.js"
   },
+  "publishConfig": {
+    "access": "public",
+    "provenance": true
+  },
   "files": [
     "dist/",
     "bin/",