@papi-ai/server 0.7.15 → 0.7.16

package/dist/prompts.js

@@ -286,11 +286,11 @@ ${AD_REJECTION_RULES}
 
    **UI/visual task detection:** Apply these additions ONLY to tasks whose PRIMARY scope is frontend visual work \u2014 the task's main deliverable must be a UI change, new component, visual design, or page. Do NOT apply to backend tasks, DB migrations, or prompt/config changes that merely mention a dashboard or page in passing. Signal: the task would fail if no .tsx/.css files were changed. If uncertain, skip the UI additions.
    When a task IS a UI task (primary scope is visual/frontend):
-   - Add to SCOPE: "Read \`.impeccable.md\` for brand palette, design principles, and audience context before writing any code. Use the \`frontend-design\` skill for implementation."
+   - Add to SCOPE: "Read \`.impeccable.md\` for component patterns, anti-patterns, and dev-loop design rules. Read \`docs/branding/brand-book.html\` for brand identity (positioning, voice, palette as final canon). Use the \`frontend-design\` skill for implementation."
    - For M/L UI tasks, add to SCOPE: "Use the full UI toolchain: Playground (design preview) \u2192 Frontend-design (build) \u2192 Playwright (verify). The playground is the quality bar. Expect 2-3 iterations."
    - Add to ACCEPTANCE CRITERIA: "[ ] Visually verify rendered output in browser \u2014 provide localhost URL or screenshot to user for review." and "[ ] No raw IDs, abbreviations, or jargon visible without human-readable labels or tooltips."
-   - If the task involves image selection, add to SCOPE: "Include brand/theme direction constraints for image selection."
-   The planner's job is scoping, not design direction. Design decisions happen at build time via \`.impeccable.md\` and the frontend-design skill \u2014 don't try to write design specs in the handoff.
+   - If the task involves image selection, add to SCOPE: "Include brand/theme direction constraints for image selection \u2014 pull from \`docs/branding/brand-book.html\` for canonical brand identity."
+   The planner's job is scoping, not design direction. Design decisions happen at build time via \`.impeccable.md\` (dev patterns) + \`docs/branding/brand-book.html\` (brand identity) and the frontend-design skill \u2014 don't try to write design specs in the handoff.
 
 11. **New Tasks (max 3 per cycle)** \u2014 Actively mine the Recent Build Reports for task candidates. For each report, check:
    - **Discovered Issues:** If a build report lists a discovered issue and no existing board task covers it, propose a new task.
@@ -358,7 +358,7 @@ var PLAN_FRAGMENT_SPIKE = `
 var PLAN_FRAGMENT_DESIGN_BRIEF = `
    **Design brief task detection:** When a task's task type is "design-brief", generate a DESIGN BRIEF handoff. Replace the standard SCOPE (DO THIS) section with these type-specific sections:
    - AUDIENCE: Who this design is for \u2014 persona and context of use (e.g. "non-technical Owner, first dashboard visit")
-   - BRAND CONSTRAINTS: Palette, typography, tone \u2014 pull from \`.impeccable.md\` and \`docs/design/brand-system.md\` if present. If neither exists, state "No brand doc \u2014 Owner should define constraints before starting."
+   - BRAND CONSTRAINTS: Palette, typography, tone \u2014 pull from \`.impeccable.md\` (dev patterns, anti-patterns, component rules) AND \`docs/branding/brand-book.html\` (brand identity, positioning, voice canon) if present. If neither exists, state "No brand doc \u2014 Owner should define constraints before starting."
    - DELIVERABLE FORMAT: What the output looks like \u2014 Claude Design handoff package / annotated mockup / style spec. Be specific so the person doing the work knows what "done" means.
    - REVIEW POINTS: What the Owner must approve before the design is considered done (e.g. layout, copy, colour, imagery).
    Keep SCOPE BOUNDARY, ACCEPTANCE CRITERIA, SECURITY CONSIDERATIONS, and PRE-BUILD VERIFICATION sections as normal.
@@ -390,11 +390,11 @@ var PLAN_FRAGMENT_OPS_BRIEF = `
 var PLAN_FRAGMENT_UI = `
    **UI/visual task detection:** Apply these additions ONLY to tasks whose PRIMARY scope is frontend visual work \u2014 the task's main deliverable must be a UI change, new component, visual design, or page. Do NOT apply to backend tasks, DB migrations, or prompt/config changes that merely mention a dashboard or page in passing. Signal: the task would fail if no .tsx/.css files were changed. If uncertain, skip the UI additions.
    When a task IS a UI task (primary scope is visual/frontend):
-   - Add to SCOPE: "Read \`.impeccable.md\` for brand palette, design principles, and audience context before writing any code. Use the \`frontend-design\` skill for implementation."
+   - Add to SCOPE: "Read \`.impeccable.md\` for component patterns, anti-patterns, and dev-loop design rules. Read \`docs/branding/brand-book.html\` for brand identity (positioning, voice, palette as final canon). Use the \`frontend-design\` skill for implementation."
    - For M/L UI tasks, add to SCOPE: "Use the full UI toolchain: Playground (design preview) \u2192 Frontend-design (build) \u2192 Playwright (verify). The playground is the quality bar. Expect 2-3 iterations."
    - Add to ACCEPTANCE CRITERIA: "[ ] Visually verify rendered output in browser \u2014 provide localhost URL or screenshot to user for review." and "[ ] No raw IDs, abbreviations, or jargon visible without human-readable labels or tooltips."
-   - If the task involves image selection, add to SCOPE: "Include brand/theme direction constraints for image selection."
-   The planner's job is scoping, not design direction. Design decisions happen at build time via \`.impeccable.md\` and the frontend-design skill \u2014 don't try to write design specs in the handoff.`;
+   - If the task involves image selection, add to SCOPE: "Include brand/theme direction constraints for image selection \u2014 pull from \`docs/branding/brand-book.html\` for canonical brand identity."
+   The planner's job is scoping, not design direction. Design decisions happen at build time via \`.impeccable.md\` (dev patterns) + \`docs/branding/brand-book.html\` (brand identity) and the frontend-design skill \u2014 don't try to write design specs in the handoff.`;
 var PLAN_FRAGMENT_PRODUCT_BRIEF = `
 12. **Product Brief** \u2014 Check whether the product brief still reflects reality. Update the brief when ANY of these apply:
    - A new AD was created or an existing AD was superseded that changes product scope, target user, or positioning
@@ -984,7 +984,7 @@ After your natural language output, include this EXACT format on its own line:
       "content": "string \u2014 specific observation from using PAPI on this project (e.g. 'deprioritise clears handoffs unnecessarily, wasting planner tokens')"
     }
   ],
-  "northStar": "string or null \u2014 the current North Star statement. Include if you assessed it in section 4 and it is still accurate (copy the current statement verbatim). Include the updated version if you revised it. Use null ONLY if no North Star has ever been set for this project."
+  "northStar": "string or null \u2014 the current North Star statement. Include if you assessed it in section 4 and it is still accurate (copy the current statement verbatim). Include the updated version if you revised it. Use null ONLY if no North Star has ever been set for this project. PLAIN TEXT ONLY \u2014 no markdown formatting, no **bold**, no _italic_, no ##headings, no quote marks around the whole statement. Just the statement itself."
 }
 \`\`\`
 
@@ -1292,12 +1292,16 @@ This is an existing project being adopted into PAPI. Use the codebase analysis b
 
 ${inputs.codebaseContext}
 ` : "";
+  const description = inputs.description?.trim() ? `**Description:** ${inputs.description}
+` : `**Description:** (not provided \u2014 derive from the codebase analysis below)
+`;
+  const targetUsers = inputs.targetUsers?.trim() ? `**Target users:** ${inputs.targetUsers}
+` : `**Target users:** (not provided \u2014 derive from the codebase analysis below)
+`;
   return `Generate a Product Brief for this project.
 
 **Project name:** ${inputs.projectName}
-**Description:** ${inputs.description}
-**Target users:** ${inputs.targetUsers}
-**Key problems it solves:** ${inputs.problems}${codebaseSection}
+${description}${targetUsers}**Key problems it solves:** ${inputs.problems}${codebaseSection}
 
 Return the Product Brief using this exact markdown structure (fill in each section with specific, concrete content \u2014 no placeholder text):
 
@@ -1385,8 +1389,8 @@ function buildAdSeedPrompt(ctx) {
     "",
     `**Project:** ${ctx.projectName}`,
     `**Type:** ${ctx.projectType}`,
-    `**Description:** ${ctx.description}`,
-    `**Target users:** ${ctx.targetUsers}`,
+    `**Description:** ${ctx.description?.trim() || "(not provided \u2014 derive from project type and problems)"}`,
+    `**Target users:** ${ctx.targetUsers?.trim() || "(not provided \u2014 infer reasonable defaults from project type)"}`,
     `**Problems solved:** ${ctx.problems}`
   ];
   parts.push(`**Team size:** ${ctx.teamSize}`);
@@ -1431,8 +1435,8 @@ function buildConventionsPrompt(ctx) {
     "",
     `**Project:** ${ctx.projectName}`,
     `**Type:** ${ctx.projectType}`,
-    `**Description:** ${ctx.description}`,
-    `**Target users:** ${ctx.targetUsers}`,
+    `**Description:** ${ctx.description?.trim() || "(not provided \u2014 infer from project type)"}`,
+    `**Target users:** ${ctx.targetUsers?.trim() || "(not provided \u2014 infer reasonable defaults from project type)"}`,
     `**Problems solved:** ${ctx.problems}`,
     `**Team size:** ${ctx.teamSize}`,
     `**Deployment:** ${ctx.deploymentTarget}`
@@ -1470,12 +1474,16 @@ Return a JSON array of 3-10 tasks. Each task must have:
 - Tasks should be specific enough to execute without further investigation
 - Maximum 10 tasks \u2014 fewer is better if the codebase is well-maintained`;
 function buildInitialTasksPrompt(inputs) {
+  const description = inputs.description?.trim() ? `**Description:** ${inputs.description}
+` : `**Description:** (not provided \u2014 derive from the codebase analysis below)
+`;
+  const targetUsers = inputs.targetUsers?.trim() ? `**Target users:** ${inputs.targetUsers}
+` : `**Target users:** (not provided \u2014 derive from the codebase analysis below)
+`;
   return `Analyse this existing codebase and generate initial backlog tasks.
 
 **Project:** ${inputs.projectName}
-**Description:** ${inputs.description}
-**Target users:** ${inputs.targetUsers}
-
+${description}${targetUsers}
 ${inputs.codebaseContext}
 
 Return a JSON array of 3-10 tasks based on gaps, improvements, and next steps visible from the codebase analysis above.`;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@papi-ai/server",
-  "version": "0.7.15",
+  "version": "0.7.16",
   "description": "PAPI MCP server — AI-powered sprint planning, build execution, and strategy review for software projects",
   "license": "Elastic-2.0",
   "type": "module",
@@ -23,6 +23,7 @@
     "start": "node dist/index.js",
     "test": "vitest run",
     "test:watch": "vitest",
+    "lint": "eslint src",
     "prepack": "rm -rf dist && npm run build"
   },
   "keywords": [