@rayburst/cc 1.0.30 → 1.0.32

package/commands/rb/discover.md

@@ -202,10 +202,10 @@ Initialize:
 
 3. From the accessibility tree, record:
    - **Page name** — derive from `<title>` tag or the main heading visible (e.g. "Board View", "Settings > Integrations", "Card Detail")
-   - **Behaviors** — list of interactive elements (buttons, forms, modals, sidebars) and their apparent purpose, expressed as user-facing actions:
-     - "User can create a new card using the + button"
-     - "User can filter cards by label"
-     - "User can drag cards between columns"
+   - **Behaviors** — list of interactive elements (buttons, forms, modals, sidebars) and their apparent purpose, expressed as Gherkin scenarios:
+     - "Given the user is on the board page\nWhen the user clicks the + button\nThen a new card creation form appears"
+     - "Given cards exist on the board\nWhen the user selects a label filter\nThen only cards with that label are visible"
+     - "Given a card is in one column\nWhen the user drags the card to another column\nThen the card moves to the target column"
    - **Links** — all `<a href>` values and navigation elements pointing to internal pages
 
 4. For any clearly interactive element that opens a modal or panel (e.g. "+ New Card", "Settings", "Detail view"):
@@ -256,17 +256,25 @@ For each `new_candidate`, create a feature:
 })
 ```
 
-Immediately after `create_feature`, add 4–8 acceptance criteria in batches of 4–5. Each criterion must describe a **testable, user-facing behavior**:
+Immediately after `create_feature`, add 4–8 acceptance criteria in batches of 4–5. Each criterion must be written in **Gherkin syntax** (Given/When/Then) to describe a testable, user-facing behavior:
 
 ```
 <MCP_PREFIX>add_criterion({
   featureId: "<new feature ID>",
-  description: "<testable behavior — e.g. 'User can remove a dependency by clicking the × icon'>",
+  description: "<Gherkin scenario — e.g. 'Given a card exists in a column\\nWhen the user clicks the × icon on a dependency\\nThen the dependency is removed from the card'>",
   status: "pass",
   tagIds: ["<tag IDs from Step 2 cache or newly created tags>"]
 })
 ```
 
+**Gherkin format rules:**
+- Always use `Given / When / Then` structure, with optional `And` for additional steps
+- `Given` — the precondition or starting state (e.g. "Given the user is on the board page")
+- `When` — the user action or system event (e.g. "When the user clicks + New Card")
+- `Then` — the observable outcome (e.g. "Then a new card appears in the first column")
+- Keep each scenario focused on one behavior — one Given/When/Then block per criterion
+- Use `\n` to separate Given/When/Then lines within the description string
+
 **After creating a feature's criteria**, search for related already-tracked features (both from the existing atlas loaded in Step 2 and from features created earlier in this same discovery run) and link them:
 
 ```
@@ -326,7 +334,7 @@ For each `existing_feature` with observed behaviors not yet tracked as criteria:
 ```
 <MCP_PREFIX>add_criterion({
   featureId: "<existing feature ID>",
-  description: "<newly observed behavior not yet in criteria>",
+  description: "<Gherkin scenario — Given [precondition]\\nWhen [action]\\nThen [outcome]>",
   status: "pass",
   tagIds: ["<relevant tag IDs>"]
 })
@@ -334,6 +342,26 @@ For each `existing_feature` with observed behaviors not yet tracked as criteria:
 
 Limit enrichment to 3 new criteria per existing feature to avoid over-loading features with redundant data.
 
+**After enriching each existing feature**, check its current links and add any missing relationships that were evident from the discovery run:
+
+```
+<MCP_PREFIX>list_feature_links({ featureId: "<existing feature ID>" })
+```
+
+For each clear relationship not yet present (limit: at most 3 new links per feature):
+
+```
+<MCP_PREFIX>link_feature_to_feature({
+  sourceFeatureId: "<existing feature ID>",
+  targetFeatureId: "<related feature ID>",
+  linkType: "<depends_on | implements | extends | related_to>"
+})
+```
+
+Apply the same relationship type guide as Step 7. Only link if the relationship is semantically clear from what you observed in the browser. Track the total count for the Step 9 report.
+
+**Also apply this linking check to existing features that were matched but had NO new criteria to add** — if you observed a clear relationship that isn't yet linked, create the link even if no criteria enrichment was needed.
+
 ---
 
 ### Step 9: Summary Report
@@ -379,6 +407,6 @@ New tags:
 5. **Batch MCP calls** in groups of 4–5 to stay within the 60 req/min rate limit.
 6. **Do not create tags for every page** — reuse existing tags aggressively; create new ones only for genuinely new UI contexts.
 7. **Feature titles = Noun Phrases** (e.g. "Card Label Management", "GitHub OAuth Integration", "Swimlane Board View") — not verb phrases or sentences.
-8. **Criteria = user-facing behaviors** — write in the form "User can…" or "System displays…". Avoid implementation details.
+8. **Criteria = Gherkin scenarios** — write in `Given / When / Then` format. Each criterion must have exactly one Given (precondition), one When (action), and one Then (observable outcome). Use `And` for additional steps. Avoid implementation details — focus on observable user-facing behavior.
 9. **Login only once** — after Step 4, reuse the authenticated browser session for all navigation in Step 5.
 10. **Depth limit = 30 pages** — prioritize pages reachable from the main navigation over deeply nested sub-pages.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rayburst/cc",
-  "version": "1.0.30",
+  "version": "1.0.32",
   "description": "Rayburst slash commands for Claude Code — /rb:init, /rb:plan, /rb:sync, /rb:status, /rb:validate-feature, /rb:validate-card, /rb:implement, /rb:discover",
   "bin": {
     "rayburst-cc": "bin/install.js"