sonance-brand-mcp 1.3.98 → 1.3.99

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

@@ -1342,63 +1342,89 @@ Output format:
 The "search" field must match the file EXACTLY (copy-paste from the code provided).`;
 
 /**
- * DESIGN REASONING PROMPT
- * Forces the LLM through a structured analysis before making design changes.
- * This prevents over-engineering and ensures thoughtful, targeted modifications.
+ * 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 = `
 ═══════════════════════════════════════════════════════════════════════════════
-DESIGN REASONING PROTOCOL (Follow BEFORE generating patches)
+DESIGNER ANALYSIS PROTOCOL
 ═══════════════════════════════════════════════════════════════════════════════
 
-STEP 1 - VISUAL ANALYSIS:
-Before making any changes, analyze the current UI in the screenshot:
-• What type of component is this? (form wizard, modal, card, data table, sidebar, etc.)
-• What is currently working well that should be PRESERVED?
-• What specific visual issues exist? (inconsistent spacing, unclear hierarchy, alignment problems, clutter)
-
-STEP 2 - MINIMAL CHANGE PLAN:
-Identify the MINIMUM changes needed to address the user's request:
-• What 1-3 targeted fixes would solve the issue?
-• What should you explicitly NOT change?
-• Will these changes break existing functionality or visual balance?
-
-STEP 3 - GUARDRAILS CHECK:
-Before implementing, verify you are following these rules:
-• Am I preserving the existing layout structure? (flex stays flex, grid stays grid)
-• Am I keeping the existing color palette unless specifically asked to change it?
-• Am I making incremental improvements, NOT a complete restructure?
-• Am I keeping the same visual hierarchy and element positions?
-
-STEP 4 - IMPLEMENT:
-Only now generate patches for the targeted changes from Step 2.
-Each patch should be small and focused - prefer multiple small patches over one large rewrite.
+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 GUARDRAILS
- * Explicit constraints to prevent the LLM from over-engineering design changes.
+ * DESIGN DECISION RULES
+ * Informed decision rules that allow fixing real problems while preventing unnecessary rewrites.
  */
 const DESIGN_GUARDRAILS = `
 ═══════════════════════════════════════════════════════════════════════════════
-DESIGN GUARDRAILS (MUST FOLLOW)
+DESIGN DECISION RULES
 ═══════════════════════════════════════════════════════════════════════════════
 
-❌ DO NOT:
-• Convert layout systems (do NOT change flex to grid or vice versa)
-• Restructure component hierarchy unless explicitly asked
-• Change color schemes unless specifically requested
-• Move elements to different positions unless asked
-• Rewrite entire sections - make targeted changes only
-• Add new wrapper elements or change semantic structure
-
-✓ DO:
-• Focus on spacing, padding, and margins for "cleaner" requests
-• Improve typography (font size, weight, line-height) for readability
-• Fix alignment issues within the existing structure
-• Adjust visual hierarchy through subtle styling, not restructuring
-• Make the smallest change that addresses the user's request
-• Preserve what is already working well
+✓ 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.
+═══════════════════════════════════════════════════════════════════════════════
 `;
 
 /**

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

@@ -1338,63 +1338,89 @@ Output format:
 The "search" field must match the file EXACTLY (copy-paste from the code provided).`;
 
 /**
- * DESIGN REASONING PROMPT
- * Forces the LLM through a structured analysis before making design changes.
- * This prevents over-engineering and ensures thoughtful, targeted modifications.
+ * 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 = `
 ═══════════════════════════════════════════════════════════════════════════════
-DESIGN REASONING PROTOCOL (Follow BEFORE generating patches)
+DESIGNER ANALYSIS PROTOCOL
 ═══════════════════════════════════════════════════════════════════════════════
 
-STEP 1 - VISUAL ANALYSIS:
-Before making any changes, analyze the current UI in the screenshot:
-• What type of component is this? (form wizard, modal, card, data table, sidebar, etc.)
-• What is currently working well that should be PRESERVED?
-• What specific visual issues exist? (inconsistent spacing, unclear hierarchy, alignment problems, clutter)
-
-STEP 2 - MINIMAL CHANGE PLAN:
-Identify the MINIMUM changes needed to address the user's request:
-• What 1-3 targeted fixes would solve the issue?
-• What should you explicitly NOT change?
-• Will these changes break existing functionality or visual balance?
-
-STEP 3 - GUARDRAILS CHECK:
-Before implementing, verify you are following these rules:
-• Am I preserving the existing layout structure? (flex stays flex, grid stays grid)
-• Am I keeping the existing color palette unless specifically asked to change it?
-• Am I making incremental improvements, NOT a complete restructure?
-• Am I keeping the same visual hierarchy and element positions?
-
-STEP 4 - IMPLEMENT:
-Only now generate patches for the targeted changes from Step 2.
-Each patch should be small and focused - prefer multiple small patches over one large rewrite.
+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 GUARDRAILS
- * Explicit constraints to prevent the LLM from over-engineering design changes.
+ * DESIGN DECISION RULES
+ * Informed decision rules that allow fixing real problems while preventing unnecessary rewrites.
  */
 const DESIGN_GUARDRAILS = `
 ═══════════════════════════════════════════════════════════════════════════════
-DESIGN GUARDRAILS (MUST FOLLOW)
+DESIGN DECISION RULES
 ═══════════════════════════════════════════════════════════════════════════════
 
-❌ DO NOT:
-• Convert layout systems (do NOT change flex to grid or vice versa)
-• Restructure component hierarchy unless explicitly asked
-• Change color schemes unless specifically requested
-• Move elements to different positions unless asked
-• Rewrite entire sections - make targeted changes only
-• Add new wrapper elements or change semantic structure
-
-✓ DO:
-• Focus on spacing, padding, and margins for "cleaner" requests
-• Improve typography (font size, weight, line-height) for readability
-• Fix alignment issues within the existing structure
-• Adjust visual hierarchy through subtle styling, not restructuring
-• Make the smallest change that addresses the user's request
-• Preserve what is already working well
+✓ 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.
+═══════════════════════════════════════════════════════════════════════════════
 `;
 
 /**

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "sonance-brand-mcp",
-  "version": "1.3.98",
+  "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",