@papi-ai/server 0.7.12 → 0.7.14

package/dist/prompts.js

@@ -1,4 +1,18 @@
 // src/prompts.ts
+var AD_REJECTION_RULES = `**AD Minting Guard \u2014 REJECT observations dressed as decisions.**
+
+An Active Decision expresses a *stance* the project is taking \u2014 a choice between alternatives that constrains future work. Reject any candidate AD whose body asserts:
+(a) the existence, identity, or status of a person, user, or external entity (e.g. "User X is building Y", "Customer Z is active");
+(b) a metric or measurement (e.g. "Signups grew 3x last cycle", "Latency dropped to 200ms");
+(c) a fact about the current state of the world that could be confirmed or denied by a query rather than challenged by argument (e.g. "External user feedback is now flowing", "The /admin route exists").
+
+If a candidate AD body could be invalidated by running a SQL query, refreshing a dashboard, or checking a log \u2014 it is an observation, not a decision. Capture it as a build report finding, a dogfood observation, a cycle log note, or a registered doc instead. Do NOT mint it as an AD.
+
+**Positive example (valid AD):** "Pricing tier strategy: free engine + paid intelligence. Decision: keep cycles free, charge for strategy reviews and analytics. Why: telemetry shows engagement clusters around intelligence surfaces, not engine surfaces." \u2014 this is a stance with alternatives.
+
+**Negative example (reject):** "External user feedback is now flowing. Stonebridge Systems is actively building." \u2014 this is a fact about the current state of the world. Capture as dogfood/signal observation; do not mint.
+
+This rule applies to: new ADs proposed during planning (Step 9), strategy review AD updates (section 5), and strategy_change AD updates. If you find an existing AD that violates this rule during housekeeping, propose deleting it (action: "delete") with a one-line rationale.`;
 var PLAN_SYSTEM = `You are the PAPI Cycle Planner \u2014 an autonomous planning engine for software projects.
 You receive project context and produce a planning cycle output with a BUILD HANDOFF.
 
@@ -224,6 +238,9 @@ Standard planning cycle with full board review.
 
 9. **Active Decisions** \u2014 If any AD needs updating: Type A (confidence change), Type B (modification), or Type C (reversal/supersede).
    **AD Quality Bar:** ADs are for product and architecture choices that constrain future work \u2014 technology selections, data model designs, UX principles, strategic positioning. They are NOT for: process preferences (commit style, PR size), configuration choices (linter rules, tab width), or temporary workarounds. If a decision doesn't affect what gets built or how it's architected, it's not an AD. Apply this bar when proposing new ADs and when triaging existing ones.
+
+${AD_REJECTION_RULES}
+
    **\u2192 PERSIST:** EVERY AD you created, updated, or confirmed with changes MUST appear in \`activeDecisions\` array in Part 2. Include the full replacement body with ### heading.
 
 ### Operational Quality Rules
@@ -461,6 +478,9 @@ Standard planning cycle with full board review.
 
 9. **Active Decisions** \u2014 If any AD needs updating: Type A (confidence change), Type B (modification), or Type C (reversal/supersede).
    **AD Quality Bar:** ADs are for product and architecture choices that constrain future work \u2014 technology selections, data model designs, UX principles, strategic positioning. They are NOT for: process preferences (commit style, PR size), configuration choices (linter rules, tab width), or temporary workarounds. If a decision doesn't affect what gets built or how it's architected, it's not an AD. Apply this bar when proposing new ADs and when triaging existing ones.
+
+${AD_REJECTION_RULES}
+
    **\u2192 PERSIST:** EVERY AD you created, updated, or confirmed with changes MUST appear in \`activeDecisions\` array in Part 2. Include the full replacement body with ### heading.
 
 ### Operational Quality Rules
@@ -535,6 +555,9 @@ function buildPlanUserMessage(ctx) {
     }) : PLAN_FULL_INSTRUCTIONS;
     parts.push(instructions);
   }
+  if (ctx.foundationalTasksGuidance) {
+    parts.push("", ctx.foundationalTasksGuidance);
+  }
   if (ctx.skipHandoffs) {
     parts.push(
       "",
@@ -830,6 +853,8 @@ You MUST cover these 5 sections. Each is mandatory.
    - Note any hierarchy/phase issues worth correcting (1-2 bullets max)
    - Delete ADs that are legacy, process-level, or redundant without discussion
 
+${AD_REJECTION_RULES}
+
 **Registered Documents:** If a "### Registered Documents" section is present in context, scan it for: (a) research findings that contradict current ADs or strategy, (b) unactioned research that should influence the next plan. Reference relevant docs by title in your review. If unregistered docs are listed, flag 1-2 that look strategically relevant and suggest registering them.
 
 ## CONDITIONAL SECTIONS (include only when genuinely useful \u2014 most reviews should have 0-2 of these)
@@ -1056,6 +1081,9 @@ function buildReviewUserMessage(ctx) {
   if (ctx.docActionStaleness) {
     parts.push("### Doc Action Staleness", "", ctx.docActionStaleness, "");
   }
+  if (ctx.pendingAgendaTopics) {
+    parts.push("### Queued Agenda Topics", "", "_Topics queued via `strategy_agenda` since the last review. Address each one in this review \u2014 they will be auto-marked as addressed on apply._", "", ctx.pendingAgendaTopics, "");
+  }
   return parts.join("\n");
 }
 function parseReviewStructuredOutput(raw) {
@@ -1136,6 +1164,8 @@ The JSON must be valid. Only include ADs that need changes \u2014 omit unchanged
 For new ADs, use the next available AD number.
 The body field must be the COMPLETE replacement text for the AD block (including the ### heading line).
 
+${AD_REJECTION_RULES}
+
 ## PHASE UPDATES
 
 If the strategic change affects the project's phase structure, include a phaseUpdates array.
@@ -1432,6 +1462,7 @@ ${inputs.codebaseContext}
 Return a JSON array of 3-10 tasks based on gaps, improvements, and next steps visible from the codebase analysis above.`;
 }
 export {
+  AD_REJECTION_RULES,
   AD_SEED_SYSTEM,
   CONVENTIONS_SYSTEM,
   HANDOFF_REGEN_SYSTEM,

package/package.json

@@ -1,7 +1,6 @@
 {
   "name": "@papi-ai/server",
-  "version": "0.7.12",
-  "mcpName": "io.github.cathalos92/papi",
+  "version": "0.7.14",
   "description": "PAPI MCP server — AI-powered sprint planning, build execution, and strategy review for software projects",
   "license": "Elastic-2.0",
   "type": "module",