@rayburst/cc 3.2.6 → 3.4.0

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "rayburst",
-  "version": "3.2.6",
+  "version": "3.3.0",
   "description": "Always-on product context for Claude Code. Automatically injects feature atlas and acceptance criteria into every coding session — no slash commands needed.",
   "author": {
     "name": "Rayburst",

package/hooks/sessionstart.mjs

@@ -167,7 +167,7 @@ function buildProductContextBlock(features, cards) {
   return `<rayburst_product_context>
   <rules>
     <rule>You have access to a Rayburst feature atlas \u2014 a knowledge graph of product features with Gherkin acceptance criteria. Use it to understand what you're building.</rule>
-    <rule>MANDATORY PRE-IMPLEMENTATION STEP: Before writing ANY code \u2014 regardless of task size, type, or complexity (including visual changes, icon swaps, layout tweaks, styling, refactoring) \u2014 you MUST: (1) call rb_list_features to search for a matching feature, (2) call rb_get_feature to load its criteria, (3) work against those criteria. There are NO exceptions. If no feature exists, create one with rb_create_feature before proceeding.</rule>
+    <rule>MANDATORY PRE-IMPLEMENTATION STEP: Before writing ANY code \u2014 regardless of task size, type, or complexity \u2014 you MUST: (1) call rb_list_features to search for a matching feature, (2) call rb_get_feature to load its criteria, (3) work against those criteria. There are NO exceptions. If no feature exists, create one with rb_create_feature before proceeding. Note: visual appearance (colors, spacing, layout) belongs in Designs, not criteria \u2014 use /rb:capture-design instead.</rule>
     <rule>PREFER EXISTING FEATURES: When adding criteria, ALWAYS search for an existing feature first via rb_list_features. Add criteria to the best-matching existing feature rather than creating a new one. Only create a new feature when no existing feature covers the UI area or capability.</rule>
     <rule>FEATURE NAMING: Feature titles MUST be short, user-friendly UI area names like "Header", "Poster Slider", "Settings Page", "Login Screen", "Featured Row". NEVER use requirement descriptions as titles (e.g. NOT "Implement dark mode toggle on settings page").</rule>
     <rule>CRITERION TITLES: Every criterion MUST have a short, user-friendly title that summarizes the behavior (e.g. "Persists dark mode on refresh", "Shows error on invalid email", "Filters by favorites on tap"). This applies when creating, updating, and reviewing criteria. Never leave the title empty or use the Gherkin description as the title.</rule>
@@ -178,7 +178,8 @@ Then the favorites filter is applied</rule>
     <rule>TAGS: Every feature MUST have at least one tag assigned. Use rb_list_tags to see available tags, or rb_create_tag if needed. Assign tags via the feature's tagIds when creating or updating.</rule>
     <rule>If your changes may affect behaviors described in OTHER features' criteria, flag this to the user before proceeding.</rule>
     <rule>NEVER create, update, or delete features or criteria in the atlas without explicitly asking the user for confirmation first. Show them what you want to change and wait for approval.</rule>
-    <rule>MANDATORY POST-IMPLEMENTATION STEP: After every implementation \u2014 in the same response as the code changes \u2014 you MUST update Rayburst without being asked: (1) update affected feature descriptions if behavior changed via rb_update_feature, (2) add new acceptance criteria for every new behavior introduced via rb_add_criterion (Gherkin format, Given/When/Then on separate lines), (3) update criterion status where applicable via rb_update_criterion. Do NOT wait for the user to ask. A post-write hook will verify compliance.</rule>
+    <rule>MANDATORY POST-IMPLEMENTATION STEP: After every implementation \u2014 in the same response as the code changes \u2014 you MUST update Rayburst without being asked: (1) update affected feature descriptions if behavior changed via rb_update_feature, (2) add new acceptance criteria for every new BEHAVIOR introduced via rb_add_criterion (Gherkin format, Given/When/Then on separate lines) \u2014 do NOT add criteria for visual appearance (colors, spacing, typography, borders, shadows, animations, layout), (3) update criterion status where applicable via rb_update_criterion. Do NOT wait for the user to ask. A post-write hook will verify compliance.</rule>
+    <rule>DESIGNS vs CRITERIA: Acceptance criteria capture BEHAVIOR (what the feature does). Designs capture APPEARANCE (how it looks). Do NOT write criteria for colors, spacing, typography, borders, shadows, animations, or layout. Instead, use rb_create_design to save a TOON-encoded snapshot of the component. Run /rb:capture-design to create one.</rule>
     <rule>Use mcp__plugin_rayburst_rayburst__rb_* MCP tools to interact with the atlas. Use rb_get_feature to load full criteria for a specific feature.</rule>
   </rules>
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rayburst/cc",
-  "version": "3.2.6",
+  "version": "3.4.0",
   "type": "module",
   "description": "Always-on product context for Claude Code. Automatically injects feature atlas and acceptance criteria into every coding session.",
   "author": {