@papi-ai/server 0.7.17 → 0.7.19

package/dist/prompts.js

@@ -122,7 +122,7 @@ Everything in Part 1 (natural language) is **display-only**. Part 2 (structured
 
 **If you analysed it in Part 1, it MUST appear in Part 2 to persist. Empty arrays = nothing saved.**
 
-- Created or triaged tasks in Part 1? \u2192 Put them in \`newTasks\` array (with all fields: title, status, priority, complexity, module, epic, phase, owner, notes). **Notes are truncated to 300 chars in plan context \u2014 front-load the most important context.**
+- Created or triaged tasks in Part 1? \u2192 Put them in \`newTasks\` array (with all fields: title, status, priority, complexity, module, epic, phase, owner, notes). **Notes are truncated to 300 chars in plan context \u2014 front-load the most important context.** **PHASE RULE: assign the phase that describes what the task IS (e.g. "Core MCP Server", "Dashboard Intelligence", "Quality & Reliability") \u2014 NOT the current active phase from the Forward Horizon section. The Forward Horizon is a scheduling signal, not a label.**
 - Updated or created Active Decisions in Part 1? \u2192 Put them in \`activeDecisions\` array (with id and full body including ### heading)
 - Found board corrections (wrong priority, missing fields, stale status) in Part 1? \u2192 Put them in \`boardCorrections\` array
 - Generated BUILD HANDOFFs in Part 1? \u2192 Put them in \`cycleHandoffs\` array
@@ -172,6 +172,15 @@ In the JSON block, you MUST include:
 - "boardHealth": summary of created tasks
 - "strategicDirection": one sentence from the North Star
 
+### Delivery Shape Check (Bootstrap Only)
+
+Before generating cycle tasks, answer: **is this a service or a platform?**
+
+- **Service** (manual delivery, human-in-the-loop): scope tasks toward workflow tooling, output quality, and delivery repeatability.
+- **Platform** (self-serve product): scope tasks toward onboarding, self-service UX, and scale.
+
+If unanswered, default to Platform \u2014 which is often wrong for early-stage projects. If the answer is clear from the brief, mint it as AD-1 and shape tasks accordingly.
+
 **CRITICAL: Bootstrap MUST populate newTasks, productBrief, and activeDecisions (if any ADs were created). These are the only way data gets written to files.**`;
 var PLAN_FULL_INSTRUCTIONS = `## FULL MODE
 
@@ -239,6 +248,7 @@ 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.
+   **Reversal Trigger (required for new ADs):** Every new AD body must include a \`### Reversal Trigger\` section. Wording: "Under what conditions would this stance reverse? Specify: the signal (concrete event or metric threshold); the action (mint new AD, modify, supersede, or abandon); and why writing this now reduces sunk-cost drift later." Example: "Signal: 3+ external users report >10-min setup time. Action: supersede with a streamlined onboarding AD. Why: measuring it now means we act before it becomes a retention problem." Existing ADs without this section remain valid \u2014 do not retroactively add triggers. Only include when creating a new AD or substantially modifying an existing one.
 
 ${AD_REJECTION_RULES}
 
@@ -252,6 +262,7 @@ ${AD_REJECTION_RULES}
 10. **BUILD HANDOFFs** \u2014 Generate a full BUILD HANDOFF block for every task selected for this cycle. Include each handoff in the \`cycleHandoffs\` array in the structured output. The handoffs are written to each task on the board for durability.
    **SKIP existing handoffs:** Tasks marked with "Has BUILD HANDOFF: yes" or "\u2713 handoff" on the board already have a valid handoff from a previous plan. Do NOT regenerate handoffs for these tasks \u2014 omit them from the \`cycleHandoffs\` array entirely. Only generate handoffs for tasks that do NOT have one yet. Exception: if a task's dependencies have been completed since its handoff was written, or a relevant Active Decision has changed, you MAY regenerate its handoff \u2014 but note this explicitly in the cycle log.
    **Scope pre-check:** Before writing the SCOPE section of each handoff, cross-reference the task against the "Recently Shipped Capabilities" section in the context below (if present). For each candidate task: (1) check if the task's title or scope overlaps with any recently shipped task, (2) check if the FILES LIKELY TOUCHED overlap with files already modified in recent builds, (3) check the architecture notes from recent builds for patterns that already cover this task's scope. If >80% of a task's scope appears in recently shipped capabilities, recommend cancellation via \`boardCorrections\` or reduce the handoff scope to only the missing pieces \u2014 explicitly note what already exists. C126 task-728 was over-scoped because the planner assumed Blocked status needed creating from scratch \u2014 it already existed in types, DB, orient, and build_list. Over-scoped handoffs waste builder time on verification and cause estimation mismatches.
+   **Reality check (task-1755):** Before scoping a handoff for a candidate task, evaluate whether the implicit assumptions a builder would make actually hold. For each task ask: (a) **Replacement assets** \u2014 does the task assume a copy/image/visual/dataset/fixture that doesn't yet exist? (e.g. "swap the hero illustration" assumes a new illustration is ready); (b) **Required user decisions** \u2014 does it assume an answer to an unresolved question (positioning, copy direction, model choice, pricing) that the user has not yet made?; (c) **Infrastructure dependencies** \u2014 does it assume a service/credential/migration/feature flag that isn't yet provisioned? If ANY assumption is unmet: do NOT generate a handoff for that task. Instead include the task in a **Pre-conditions Missing** paragraph in \`cycleLogNotes\` listing the task ID, the missing dependency, and the suggested unblock (e.g. "task-1234: needs new hero illustration \u2014 file separate asset-creation task or surface as a decision"). Drop it from the cycle entirely; the user can re-add it once the dependency is satisfied. ellies-birthday C5 hit two mid-cycle defers in one cycle from this exact gap (handoffs assumed assets that didn't exist) \u2014 reality check catches that before scope is written, not after work starts.
    **Simplest Viable Path rule:** Before writing each BUILD HANDOFF, identify the simplest approach that satisfies the task's goal \u2014 the minimum change, fewest new abstractions, and smallest blast radius. Write the SCOPE (DO THIS) section for that simplest path FIRST. If you believe a more complex approach is warranted (new abstractions, multi-file refactors, framework changes), you MUST include a "WHY NOT SIMPLER" line in the handoff explaining why the simple path is insufficient. If you cannot articulate a concrete reason, use the simpler path. Pay special attention to tasks involving auth, data access, multi-user features, and infrastructure \u2014 these are the most common over-engineering targets.
    **Maturity gate applies here:** Do NOT generate BUILD HANDOFFs for tasks that failed the maturity gate in step 6 (phase prerequisites not met, dependency chain incomplete). Raw tasks that the planner has scoped and upgraded to "investigated" in step 6 ARE eligible for handoffs.
    **Intra-cycle dependency detection:** After selecting cycle tasks, check every pair for build-order dependencies. Two tasks A and B have an intra-cycle dependency when A must be built before B because B consumes an artifact A creates \u2014 e.g. A adds a new adapter method that B calls, A creates a DB migration B depends on, A introduces a new shared type B imports, A refactors a utility B modifies. Signals: same module + adjacent scope (one is "add X", another is "use X"), or notes explicitly reference the other task. For each dependency detected:
@@ -480,6 +491,7 @@ 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.
+   **Reversal Trigger (required for new ADs):** Every new AD body must include a \`### Reversal Trigger\` section. Wording: "Under what conditions would this stance reverse? Specify: the signal (concrete event or metric threshold); the action (mint new AD, modify, supersede, or abandon); and why writing this now reduces sunk-cost drift later." Example: "Signal: 3+ external users report >10-min setup time. Action: supersede with a streamlined onboarding AD. Why: measuring it now means we act before it becomes a retention problem." Existing ADs without this section remain valid \u2014 do not retroactively add triggers. Only include when creating a new AD or substantially modifying an existing one.
 
 ${AD_REJECTION_RULES}
 
@@ -493,6 +505,7 @@ ${AD_REJECTION_RULES}
 10. **BUILD HANDOFFs** \u2014 Generate a full BUILD HANDOFF block for every task selected for this cycle. Include each handoff in the \`cycleHandoffs\` array in the structured output. The handoffs are written to each task on the board for durability.
    **SKIP existing handoffs:** Tasks marked with "Has BUILD HANDOFF: yes" or "\u2713 handoff" on the board already have a valid handoff from a previous plan. Do NOT regenerate handoffs for these tasks \u2014 omit them from the \`cycleHandoffs\` array entirely. Only generate handoffs for tasks that do NOT have one yet. Exception: if a task's dependencies have been completed since its handoff was written, or a relevant Active Decision has changed, you MAY regenerate its handoff \u2014 but note this explicitly in the cycle log.
    **Scope pre-check:** Before writing the SCOPE section of each handoff, cross-reference the task against the "Recently Shipped Capabilities" section in the context below (if present). For each candidate task: (1) check if the task's title or scope overlaps with any recently shipped task, (2) check if the FILES LIKELY TOUCHED overlap with files already modified in recent builds, (3) check the architecture notes from recent builds for patterns that already cover this task's scope. If >80% of a task's scope appears in recently shipped capabilities, recommend cancellation via \`boardCorrections\` or reduce the handoff scope to only the missing pieces \u2014 explicitly note what already exists. C126 task-728 was over-scoped because the planner assumed Blocked status needed creating from scratch \u2014 it already existed in types, DB, orient, and build_list. Over-scoped handoffs waste builder time on verification and cause estimation mismatches.
+   **Reality check (task-1755):** Before scoping a handoff for a candidate task, evaluate whether the implicit assumptions a builder would make actually hold. For each task ask: (a) **Replacement assets** \u2014 does the task assume a copy/image/visual/dataset/fixture that doesn't yet exist? (e.g. "swap the hero illustration" assumes a new illustration is ready); (b) **Required user decisions** \u2014 does it assume an answer to an unresolved question (positioning, copy direction, model choice, pricing) that the user has not yet made?; (c) **Infrastructure dependencies** \u2014 does it assume a service/credential/migration/feature flag that isn't yet provisioned? If ANY assumption is unmet: do NOT generate a handoff for that task. Instead include the task in a **Pre-conditions Missing** paragraph in \`cycleLogNotes\` listing the task ID, the missing dependency, and the suggested unblock (e.g. "task-1234: needs new hero illustration \u2014 file separate asset-creation task or surface as a decision"). Drop it from the cycle entirely; the user can re-add it once the dependency is satisfied. ellies-birthday C5 hit two mid-cycle defers in one cycle from this exact gap (handoffs assumed assets that didn't exist) \u2014 reality check catches that before scope is written, not after work starts.
    **Simplest Viable Path rule:** Before writing each BUILD HANDOFF, identify the simplest approach that satisfies the task's goal \u2014 the minimum change, fewest new abstractions, and smallest blast radius. Write the SCOPE (DO THIS) section for that simplest path FIRST. If you believe a more complex approach is warranted (new abstractions, multi-file refactors, framework changes), you MUST include a "WHY NOT SIMPLER" line in the handoff explaining why the simple path is insufficient. If you cannot articulate a concrete reason, use the simpler path. Pay special attention to tasks involving auth, data access, multi-user features, and infrastructure \u2014 these are the most common over-engineering targets.
    **Maturity gate applies here:** Do NOT generate BUILD HANDOFFs for tasks that failed the maturity gate in step 6 (phase prerequisites not met, dependency chain incomplete). Raw tasks that the planner has scoped and upgraded to "investigated" in step 6 ARE eligible for handoffs.
    **Security section guidance:** Each handoff includes a SECURITY CONSIDERATIONS section. Populate it when the task involves: data exposure risks (PII, secrets in logs/storage), secrets or credentials handling (API keys, tokens, env vars), auth/access control changes, or dependency security risks (new packages, version changes). For pure refactoring, documentation, prompt-text, or UI-only tasks, write "None \u2014 no security-relevant changes".
@@ -1182,6 +1195,7 @@ After your natural language output, include this EXACT format on its own line:
 The JSON must be valid. Only include ADs that need changes \u2014 omit unchanged ADs.
 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).
+**Reversal Trigger (required for new ADs):** When creating a new AD, include a \`### Reversal Trigger\` section in the body. Specify: the signal that would invalidate this stance; the action to take (modify, supersede, or abandon); and why writing it now prevents sunk-cost drift later.
 
 ${AD_REJECTION_RULES}
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@papi-ai/server",
-  "version": "0.7.17",
+  "version": "0.7.19",
   "description": "PAPI MCP server — AI-powered sprint planning, build execution, and strategy review for software projects",
   "license": "Elastic-2.0",
   "type": "module",