@hanzlaa/rcode 2.6.4 → 2.6.5

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hanzlaa/rcode",
-  "version": "2.6.4",
+  "version": "2.6.5",
   "description": "Rihal Code (rcode) — installable context-brain for Rihalians. 43 agents, 99 slash commands, 56 skills, pullable Rihal standards. Unified install for Claude Code, Cursor, and Gemini.",
   "main": "cli/index.js",
   "bin": {

package/rihal/workflows/do.md

@@ -4,6 +4,7 @@ Analyze freeform text from the user and route to the most appropriate Rihal comm
 
 <required_reading>
 @.rihal/references/output-format.md
+@.rihal/references/verb-dictionary.md
 Read all files referenced by the invoking prompt's execution_context before starting.
 </required_reading>
 
@@ -149,25 +150,23 @@ When the user uses a literal create/make/start verb paired with a scope-noun (mi
 
 This was a real bug: `/rihal:do "milestone bnao aur ... list down karo"` triggered an ambiguity prompt offering new-milestone vs add-phase vs create-epics-and-stories — even though the user literally said "milestone bnao" (= "create a milestone" in Roman Urdu). That second-guessing wasted the user's time and broke trust.
 
-**Verb dictionary — match if `$QUESTION` contains any of these (case-insensitive):**
+**Verb + scope detection — sourced from `@.rihal/references/verb-dictionary.md`.**
 
-- English: `create`, `make`, `start`, `add`, `new`, `set up`, `setup`, `kick off`, `spin up`
-- Roman Urdu / Hindi: `bnao`, `banao`, `bana do`, `bnado`, `banaa`, `banade`, `shuru karo`, `start karo`, `create karo`, `naya banao`, `add karo`, `daal do`
-- Arabic transliteration: `ansha'`, `inshaa`
+Match if `$QUESTION` contains any verb from §Create or §Add (English + Roman Urdu/Hindi + Arabic transliteration — full list lives in the dictionary file, do not duplicate here). Pair with a scope noun to determine the route.
 
-**Scope-noun → command map:**
+The full mapping is in the dictionary's "Scope nouns" table. Pre-conditions enforced by this workflow:
 
-| Scope noun in input | Direct route | Pre-condition |
+| Scope noun | Direct route | Pre-condition (this workflow only) |
 |---|---|---|
-| `milestone`, `milestones` | `/rihal:new-milestone` | none — methodology chain assumed when greenfield_guard cleared |
-| `phase`, `phases` (singular intent — "add a phase") | `/rihal:add-phase` | HAS_PHASES OR HAS_PRD true |
-| `story`, `stories`, `user story` | `/rihal:create-story` | HAS_EPICS true |
-| `epic`, `epics`, `epics and stories` | `/rihal:create-epics-and-stories` | HAS_PRD true |
-| `sprint` | `/rihal:sprint-planning` | HAS_EPICS true |
-| `PRD`, `requirements doc`, `product requirements` | `/rihal:create-prd` | none |
-| `roadmap` | `/rihal:create-milestone` | HAS_PRD true |
-| `council`, `majlis` | `/rihal:council` | none |
-| `plan` (verb — "plan phase N") | `/rihal:plan` | HAS_PHASES true |
+| milestone | `/rihal:new-milestone` | none — methodology chain assumed when greenfield_guard cleared |
+| phase | `/rihal:add-phase` | HAS_PHASES OR HAS_PRD true |
+| story | `/rihal:create-story` | HAS_EPICS true |
+| epic | `/rihal:create-epics-and-stories` | HAS_PRD true |
+| sprint | `/rihal:sprint-planning` | HAS_EPICS true |
+| PRD | `/rihal:create-prd` | none |
+| roadmap | `/rihal:create-milestone` | HAS_PRD true |
+| council | `/rihal:council` | none |
+| plan (verb) | `/rihal:plan` | HAS_PHASES true |
 
 **Behavior:**
 1. If both a verb AND a scope-noun match, fire this step.

package/rihal/workflows/quick.md

@@ -95,6 +95,62 @@ Do the work directly:
 **No SPRINT.md. No subagents. Just do it.**
 </step>
 
+<step name="blocker_handling">
+**When investigation reveals a blocker, do NOT present a multi-option menu.** Pick ONE response per the rules below.
+
+Common blocker types:
+- Need a screenshot / browser-rendered state to confirm
+- Need the dev server running
+- Need a decision the user hasn't given yet
+- Need access to an external system (production logs, Sentry, etc.)
+
+**Rules:**
+
+1. **If the original input was a LIST of tasks** (bulk_detection-eligible OR the user passed multiple tasks): silently SKIP the blocked task, log the blocker in the running tracker, and PIVOT to the next clearly-runnable task in the list. Do not stop. Do not ask. Do not present 5 options.
+
+   Example log line (appended to `.planning/BUG-TRACKER-YYYY-MM-DD.md` if it exists, or stdout otherwise):
+
+   ```
+   ⏸  #36 (Extraction wizard CSS) — skipped: needs runtime screenshot to confirm cascade-layer hypothesis. Will resume when dev server is available.
+   ```
+
+   Then continue with #19 / #17 / whichever is the next-most-runnable in the list. State the pivot in one line:
+
+   ```
+   ▶ Pivoting to next runnable: #19 (Breadcrumb UUID→name) — clear scope, no runtime needed.
+   ```
+
+2. **If the input was a SINGLE task and there's nothing to pivot to**: stop with ONE line stating the single specific blocker and how to unblock it. No menu. No options. The user pastes back the resolved info and re-runs.
+
+   ```
+   ⏸  Blocked on: a screenshot of the broken Extraction wizard. Paste the screenshot or run `pnpm dev` and share what you see — I'll resume from where I left off.
+   ```
+
+3. **If the user passed `--force-inline` AND the input was single-task AND blocked**: attempt the highest-confidence speculative fix, COMMIT it with a clear "speculative — needs runtime verification" prefix in the commit message, and proceed. The user explicitly chose this path.
+
+**Never present a 4+ option menu in blocker_handling.** Multi-option menus during execution are decision-fatigue. Pick one response, do it, move on.
+</step>
+
+<step name="next_task_loop">
+**If the original input was a list and there are remaining tasks after this one** (whether the current task succeeded, failed, or was skipped due to blocker), automatically continue to the next task without asking. State the pivot in one line and re-enter execute_inline.
+
+**Stop the loop only when:**
+- All tasks in the list are processed (done / skipped / blocked)
+- A task touches `> 5` files (escalate the rest of the list to /rihal:add-phase)
+- The user types stop / cancel / pause
+
+At the end of the loop, summarise:
+
+```
+✅ Loop complete: {N} done · {M} skipped · {K} blocked
+   Done:    {bullet list with commit hashes}
+   Skipped: {bullet list with reasons}
+   Blocked: {bullet list with what info is needed}
+
+Resume blocked tasks: {one-line guidance on what to provide and re-run}
+```
+</step>
+
 <step name="commit">
 Commit atomically with conventional commit format (`fix:`, `feat:`, `docs:`, `chore:`, `refactor:`):