sonance-brand-mcp 1.3.97 → 1.3.99

package/dist/assets/api/sonance-vision-apply/route.ts

@@ -1341,6 +1341,111 @@ Output format:
 
 The "search" field must match the file EXACTLY (copy-paste from the code provided).`;
 
+/**
+ * DESIGNER ANALYSIS PROTOCOL
+ * Forces the LLM to analyze the UI like a senior designer before making changes.
+ * Identifies specific visual problems, maps them to code, then makes targeted fixes.
+ */
+const DESIGN_REASONING_PROMPT = `
+═══════════════════════════════════════════════════════════════════════════════
+DESIGNER ANALYSIS PROTOCOL
+═══════════════════════════════════════════════════════════════════════════════
+
+You are a senior UI/UX designer reviewing this component. Before generating any code changes, you MUST complete this analysis:
+
+STEP 1 - VISUAL AUDIT (analyze the screenshot)
+Examine the UI and identify specific issues in these categories:
+
+• HIERARCHY: Is there a clear visual focus? Are elements competing for attention?
+  - Look for: competing headings, unclear primary actions, visual clutter
+  
+• SPACING: Are related elements grouped? Is there awkward empty space?
+  - Look for: disconnected labels/values, uneven gaps, cramped or overly spread content
+  
+• ALIGNMENT: Do elements align naturally? Are there visual disconnects?
+  - Look for: misaligned text, floating elements, broken visual flow
+  
+• FEEDBACK: Are progress indicators, states, and actions clear?
+  - Look for: weak progress visualization, unclear states, orphaned status indicators
+  
+• GROUPING: Are related items visually connected? Do containers make sense?
+  - Look for: related content that appears separate, missing visual boundaries
+
+List each problem you find with a specific description.
+
+STEP 2 - CODE MAPPING
+For each problem identified in Step 1, find the EXACT code in the file that causes it:
+
+Example format:
+- Problem: "Badge disconnected from its label"
+- Code: Line 45 shows \`<Badge className="absolute right-0">\` positioned separately from label at Line 42
+- Fix needed: Move Badge inside the same flex container as the label
+
+Do this for EACH problem you identified.
+
+STEP 3 - PRIORITIZED FIXES
+Rank your fixes by visual impact. Address the most impactful issues first.
+Each fix should:
+• Target a specific identified problem from Step 1
+• Reference the exact code location from Step 2
+• Make focused changes that fix THAT specific problem
+
+STEP 4 - GENERATE PATCHES
+Now generate patches that implement your fixes.
+• Each patch should be traceable to a specific problem from Step 1
+• Multiple small patches are better than one large rewrite
+• Every change must have a clear reason tied to your analysis
+`;
+
+/**
+ * DESIGN DECISION RULES
+ * Informed decision rules that allow fixing real problems while preventing unnecessary rewrites.
+ */
+const DESIGN_GUARDRAILS = `
+═══════════════════════════════════════════════════════════════════════════════
+DESIGN DECISION RULES
+═══════════════════════════════════════════════════════════════════════════════
+
+✓ ALLOWED when fixing identified problems:
+• Adjust spacing, padding, margins to fix grouping issues
+• Reposition elements to improve visual hierarchy (move badge next to its label, etc.)
+• Add containers/wrappers to group related content that appears disconnected
+• Change flex direction or alignment to fix layout issues
+• Adjust typography for better hierarchy (size, weight, line-height)
+• Improve progress indicators or status displays for clarity
+
+✗ STILL AVOID:
+• Complete rewrites when targeted fixes would work
+• Changing functionality or interactive behavior
+• Removing content or features the user didn't ask to remove
+• Changing color schemes unless specifically identified as a problem
+• Making changes that aren't traceable to a specific visual problem you identified
+
+═══════════════════════════════════════════════════════════════════════════════
+PRINCIPLE: Every change must trace back to a specific visual problem you identified in Step 1.
+If you can't explain WHY a change fixes a specific problem, don't make that change.
+═══════════════════════════════════════════════════════════════════════════════
+`;
+
+/**
+ * Detect if a user request is design-heavy and needs the reasoning protocol.
+ * Simple requests like "change button color to blue" don't need it.
+ */
+function isDesignHeavyRequest(userPrompt: string): boolean {
+  const designKeywords = [
+    'redesign', 'design', 'layout', 'improve', 'better', 'modernize', 'modern',
+    'cleaner', 'clean', 'messy', 'cluttered', 'update look', 'looks bad',
+    'ugly', 'prettier', 'beautiful', 'professional', 'polish', 'refine',
+    'restructure', 'reorganize', 'rearrange', 'simplify', 'streamline',
+    'compact', 'spacious', 'breathing room', 'visual', 'aesthetic',
+    'ux', 'user experience', 'ui', 'user interface', 'make it look',
+    'looks weird', 'not right', 'fix the look', 'appearance'
+  ];
+  
+  const lowerPrompt = userPrompt.toLowerCase();
+  return designKeywords.some(keyword => lowerPrompt.includes(keyword));
+}
+
 export async function POST(request: Request) {
   // Only allow in development
   if (process.env.NODE_ENV !== "development") {
@@ -1748,6 +1853,23 @@ User Request: "${userPrompt}"
 
 `;
 
+      // ========== DESIGN REASONING PROTOCOL ==========
+      // For design-heavy requests, add structured reasoning and guardrails
+      // This prevents over-engineering and ensures thoughtful changes
+      const isDesignRequest = isDesignHeavyRequest(userPrompt || '');
+      
+      if (isDesignRequest) {
+        debugLog("Design-heavy request detected, adding reasoning protocol", {
+          prompt: userPrompt?.substring(0, 50),
+          triggerKeywords: ['redesign', 'better', 'improve', 'cleaner', 'layout', 'modernize']
+            .filter(k => userPrompt?.toLowerCase().includes(k))
+        });
+        
+        textContent += DESIGN_REASONING_PROMPT;
+        textContent += DESIGN_GUARDRAILS;
+        textContent += '\n';
+      }
+
       // ========== TARGET COMPONENT ONLY (with line numbers) ==========
       // CRITICAL: Only include the TARGET file to avoid overwhelming the LLM with noise
       if (recommendedFileContent) {

package/dist/assets/api/sonance-vision-edit/route.ts

@@ -1337,6 +1337,111 @@ Output format:
 
 The "search" field must match the file EXACTLY (copy-paste from the code provided).`;
 
+/**
+ * DESIGNER ANALYSIS PROTOCOL
+ * Forces the LLM to analyze the UI like a senior designer before making changes.
+ * Identifies specific visual problems, maps them to code, then makes targeted fixes.
+ */
+const DESIGN_REASONING_PROMPT = `
+═══════════════════════════════════════════════════════════════════════════════
+DESIGNER ANALYSIS PROTOCOL
+═══════════════════════════════════════════════════════════════════════════════
+
+You are a senior UI/UX designer reviewing this component. Before generating any code changes, you MUST complete this analysis:
+
+STEP 1 - VISUAL AUDIT (analyze the screenshot)
+Examine the UI and identify specific issues in these categories:
+
+• HIERARCHY: Is there a clear visual focus? Are elements competing for attention?
+  - Look for: competing headings, unclear primary actions, visual clutter
+  
+• SPACING: Are related elements grouped? Is there awkward empty space?
+  - Look for: disconnected labels/values, uneven gaps, cramped or overly spread content
+  
+• ALIGNMENT: Do elements align naturally? Are there visual disconnects?
+  - Look for: misaligned text, floating elements, broken visual flow
+  
+• FEEDBACK: Are progress indicators, states, and actions clear?
+  - Look for: weak progress visualization, unclear states, orphaned status indicators
+  
+• GROUPING: Are related items visually connected? Do containers make sense?
+  - Look for: related content that appears separate, missing visual boundaries
+
+List each problem you find with a specific description.
+
+STEP 2 - CODE MAPPING
+For each problem identified in Step 1, find the EXACT code in the file that causes it:
+
+Example format:
+- Problem: "Badge disconnected from its label"
+- Code: Line 45 shows \`<Badge className="absolute right-0">\` positioned separately from label at Line 42
+- Fix needed: Move Badge inside the same flex container as the label
+
+Do this for EACH problem you identified.
+
+STEP 3 - PRIORITIZED FIXES
+Rank your fixes by visual impact. Address the most impactful issues first.
+Each fix should:
+• Target a specific identified problem from Step 1
+• Reference the exact code location from Step 2
+• Make focused changes that fix THAT specific problem
+
+STEP 4 - GENERATE PATCHES
+Now generate patches that implement your fixes.
+• Each patch should be traceable to a specific problem from Step 1
+• Multiple small patches are better than one large rewrite
+• Every change must have a clear reason tied to your analysis
+`;
+
+/**
+ * DESIGN DECISION RULES
+ * Informed decision rules that allow fixing real problems while preventing unnecessary rewrites.
+ */
+const DESIGN_GUARDRAILS = `
+═══════════════════════════════════════════════════════════════════════════════
+DESIGN DECISION RULES
+═══════════════════════════════════════════════════════════════════════════════
+
+✓ ALLOWED when fixing identified problems:
+• Adjust spacing, padding, margins to fix grouping issues
+• Reposition elements to improve visual hierarchy (move badge next to its label, etc.)
+• Add containers/wrappers to group related content that appears disconnected
+• Change flex direction or alignment to fix layout issues
+• Adjust typography for better hierarchy (size, weight, line-height)
+• Improve progress indicators or status displays for clarity
+
+✗ STILL AVOID:
+• Complete rewrites when targeted fixes would work
+• Changing functionality or interactive behavior
+• Removing content or features the user didn't ask to remove
+• Changing color schemes unless specifically identified as a problem
+• Making changes that aren't traceable to a specific visual problem you identified
+
+═══════════════════════════════════════════════════════════════════════════════
+PRINCIPLE: Every change must trace back to a specific visual problem you identified in Step 1.
+If you can't explain WHY a change fixes a specific problem, don't make that change.
+═══════════════════════════════════════════════════════════════════════════════
+`;
+
+/**
+ * Detect if a user request is design-heavy and needs the reasoning protocol.
+ * Simple requests like "change button color to blue" don't need it.
+ */
+function isDesignHeavyRequest(userPrompt: string): boolean {
+  const designKeywords = [
+    'redesign', 'design', 'layout', 'improve', 'better', 'modernize', 'modern',
+    'cleaner', 'clean', 'messy', 'cluttered', 'update look', 'looks bad',
+    'ugly', 'prettier', 'beautiful', 'professional', 'polish', 'refine',
+    'restructure', 'reorganize', 'rearrange', 'simplify', 'streamline',
+    'compact', 'spacious', 'breathing room', 'visual', 'aesthetic',
+    'ux', 'user experience', 'ui', 'user interface', 'make it look',
+    'looks weird', 'not right', 'fix the look', 'appearance'
+  ];
+  
+  const lowerPrompt = userPrompt.toLowerCase();
+  return designKeywords.some(keyword => lowerPrompt.includes(keyword));
+}
+
 export async function POST(request: Request) {
   // Only allow in development
   if (process.env.NODE_ENV !== "development") {
@@ -1717,6 +1822,23 @@ User Request: "${userPrompt}"
 
 `;
 
+      // ========== DESIGN REASONING PROTOCOL ==========
+      // For design-heavy requests, add structured reasoning and guardrails
+      // This prevents over-engineering and ensures thoughtful changes
+      const isDesignRequest = isDesignHeavyRequest(userPrompt || '');
+      
+      if (isDesignRequest) {
+        debugLog("Design-heavy request detected, adding reasoning protocol", {
+          prompt: userPrompt?.substring(0, 50),
+          triggerKeywords: ['redesign', 'better', 'improve', 'cleaner', 'layout', 'modernize']
+            .filter(k => userPrompt?.toLowerCase().includes(k))
+        });
+        
+        textContent += DESIGN_REASONING_PROMPT;
+        textContent += DESIGN_GUARDRAILS;
+        textContent += '\n';
+      }
+
       // ========== TARGET COMPONENT ONLY (with line numbers) ==========
       // CRITICAL: Only include the TARGET file to avoid overwhelming the LLM with noise
       if (recommendedFileContent) {

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sonance-brand-mcp",
-  "version": "1.3.97",
+  "version": "1.3.99",
   "description": "MCP Server for Sonance Brand Guidelines and Component Library - gives Claude instant access to brand colors, typography, and UI components.",
   "main": "dist/index.js",
   "type": "module",