@rayburst/cc 3.2.5 → 3.4.0

package/.claude-plugin/marketplace.json

@@ -6,14 +6,14 @@
   },
   "metadata": {
     "description": "Always-on product context for Claude Code — features, acceptance criteria, and board cards injected automatically.",
-    "version": "3.2.5"
+    "version": "3.2.6"
   },
   "plugins": [
     {
       "name": "rayburst",
       "source": "./",
       "description": "Always-on product context for Claude Code. Automatically injects your Rayburst Product Requirement Registry (features, Gherkin acceptance criteria, board cards) into every coding session.",
-      "version": "3.2.5",
+      "version": "3.2.6",
       "author": {
         "name": "Rayburst"
       },

package/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "rayburst",
-  "version": "3.2.5",
+  "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/posttooluse.mjs

@@ -55,7 +55,7 @@ if (activeFeature) {
   contextBlock = `<rayburst_post_implementation_reminder>
   <action_required>You just modified ${escapeXml(filePath)}. Before continuing to the next task or responding to the user, you MUST update the Rayburst feature atlas NOW:
     1. Search for an existing feature that covers this area via rb_list_features \u2014 add criteria there instead of creating a new feature
-    2. Call rb_add_criterion for new behaviors (Gherkin format: Given/When/Then on separate lines)
+    2. Call rb_add_criterion for new behaviors \u2014 include a short user-friendly title AND a Gherkin description (Given/When/Then on separate lines)
     3. Call rb_update_criterion to mark criteria as passing/failing
     4. Call rb_update_feature if the feature description needs updating
   Do NOT proceed without completing this step. This is a mandatory workflow requirement.</action_required>
@@ -66,7 +66,7 @@ if (activeFeature) {
   <action_required>You just modified ${escapeXml(filePath)} but NO active feature was matched for this task. This likely means you skipped the mandatory feature lookup step. You MUST now:
     1. Call rb_list_features to find an existing feature that covers this area \u2014 prefer adding criteria to existing features over creating new ones
     2. Call rb_get_feature on the best match to load its criteria
-    3. Call rb_add_criterion to reflect what you built (Gherkin format: Given/When/Then on separate lines)
+    3. Call rb_add_criterion to reflect what you built \u2014 include a short user-friendly title AND a Gherkin description (Given/When/Then on separate lines)
     4. Call rb_update_feature if the feature description needs updating
   ALL changes \u2014 including visual, layout, and icon changes \u2014 require feature atlas updates. Do NOT skip this.</action_required>
 </rayburst_post_implementation_reminder>`;

package/hooks/sessionstart.mjs

@@ -167,9 +167,10 @@ 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>
     <rule>GHERKIN FORMAT: All criteria descriptions MUST use Gherkin syntax with Given, When, Then each on a NEW LINE. Example:
 Given the user is on the home screen
 When they tap the favorites button
@@ -177,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.5",
+  "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": {