@hanzlaa/rcode 2.6.4 → 2.6.6

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hanzlaa/rcode",
-  "version": "2.6.4",
+  "version": "2.6.6",
   "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/add-phase.md

@@ -41,11 +41,43 @@ Run /rihal:new-project to initialize.
 Exit.
 </step>
 
+<step name="detect_task_list">
+**Detect bulk-task input** — when /rihal:quick or /rihal:do auto-routes a multi-task input here, the entire bug list arrives as `${description}`. Don't put it all in the phase title; extract structure.
+
+Match if `${description}` contains ANY of:
+- 5+ numbered list items (`/^\s*\d+\.\s/m` ≥ 5)
+- 5+ bullet items (`/^\s*[-*]\s/m` ≥ 5)
+- 3+ "Bug Report:" / "Issue:" / "Severity:" headers
+- Multiple newlines (> 5 lines total)
+
+If matched:
+
+1. **Phase name** = first line of `${description}` (or first 80 chars if no newline). If the first line is itself a heading like `# Phase 09 — UI Bug Cleanup`, strip the leading `#` characters.
+2. **Phase body** = the rest of the input.
+3. After the phase directory is created (next step), write the body to `.planning/phases/{NN}-{slug}/TASKS.md` with header:
+
+   ```markdown
+   # Phase {N} — {phase name} — Tasks
+
+   *Auto-extracted from /rihal:quick or /rihal:do bulk auto-route on {ISO date}.*
+
+   {original body, preserved verbatim}
+   ```
+
+4. Note in the completion message: "TASKS.md written with N tasks". The downstream /rihal:plan workflow consumes TASKS.md as the input to SPRINT.md generation — no manual re-paste needed.
+
+If NOT matched (single task), proceed normally — `${description}` is the phase name as-is.
+
+Set `BULK_MODE=true|false` for the next step.
+</step>
+
 <step name="add_phase">
 **Delegate the phase addition to rihal-tools:**
 
 ```bash
-RESULT=$(node ".rihal/bin/rihal-tools.cjs" phase add "${description}")
+# In bulk mode, pass only the extracted phase name (not the entire body)
+PHASE_NAME=$( [ "$BULK_MODE" = "true" ] && echo "$EXTRACTED_FIRST_LINE" || echo "$description" )
+RESULT=$(node ".rihal/bin/rihal-tools.cjs" phase add "${PHASE_NAME}")
 ```
 
 The CLI handles:
@@ -56,6 +88,8 @@ The CLI handles:
 - Inserting the phase entry into ROADMAP.md with Goal, Depends on, and Plans sections
 
 Extract from result: `phase_number`, `padded`, `name`, `slug`, `directory`.
+
+**If `BULK_MODE=true`:** after the CLI returns, write the bulk body to `${directory}/TASKS.md` per the structure defined in `detect_task_list`. This step is non-destructive — it only ADDs a TASKS.md file inside the new phase directory.
 </step>
 
 <step name="update_project_state">

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:`):