@hanzlaa/rcode 3.6.16 → 4.1.0

package/rihal/workflows/add-todo.md

@@ -1,187 +0,0 @@
-<purpose>
-Capture an idea, task, or issue that surfaces during a Rihal session as a structured note for later work. Enables "thought → capture → continue" flow without losing context.
-</purpose>
-
-
-## Step 0 — Usage check
-
-If `$ARGUMENTS` is empty or contains only `--help` or `-h`:
-
-```
-/rihal-add-todo <argument-here>
-```
-
-**Examples:**
-```
-/rihal-add-todo example 1
-/rihal-add-todo example 2
-```
-
-STOP — do not proceed.
-
-<required_reading>
-Read all files referenced by the invoking prompt's execution_context before starting.
-</required_reading>
-
-<process>
-
-<step name="init_context">
-Load todo context:
-
-```bash
-[ -d .rihal/todos ] || mkdir -p .rihal/todos/pending .rihal/todos/done
-```
-
-Ensure directories exist for organized todo capture.
-</step>
-
-<step name="extract_content">
-**With arguments:** Use as the title/focus.
-- `/rihal-add-todo Add auth token refresh` → title = "Add auth token refresh"
-
-**Without arguments:** Analyze recent conversation to extract:
-- The specific problem, idea, or task discussed
-- Relevant file paths mentioned
-- Technical details (error messages, line numbers, constraints)
-
-Formulate:
-- `title`: 3-10 word descriptive title (action verb preferred)
-- `problem`: What's wrong or why this is needed
-- `solution`: Approach hints or "TBD" if just an idea
-- `files`: Relevant paths with line numbers from conversation
-</step>
-
-<step name="infer_area">
-Infer area from file paths:
-
-| Path pattern | Area |
-|--------------|------|
-| `src/api/*`, `api/*` | `api` |
-| `src/components/*`, `src/ui/*` | `ui` |
-| `src/auth/*`, `auth/*` | `auth` |
-| `src/db/*`, `database/*` | `database` |
-| `tests/*`, `__tests__/*` | `testing` |
-| `docs/*` | `docs` |
-| `.rihal/*` | `planning` |
-| `scripts/*`, `bin/*` | `tooling` |
-| No files or unclear | `general` |
-
-Use existing area if similar match exists.
-</step>
-
-<step name="check_duplicates">
-```bash
-# Search for key words from title in existing todos
-grep -l -i "[key words from title]" .rihal/todos/pending/*.md 2>/dev/null || true
-```
-
-If potential duplicate found:
-1. Read the existing todo
-2. Compare scope
-
-If overlapping, ask user:
-- "Similar todo exists: [title]. What would you like to do?"
-- Options:
-  - "Skip" — keep existing todo
-  - "Replace" — update existing with new context
-  - "Add anyway" — create as separate todo
-</step>
-
-<step name="create_file">
-Generate slug for the title and write to `.rihal/todos/pending/{date}-{slug}.md`:
-
-```bash
-slug=$(echo "$title" | tr ' ' '-' | tr '[:upper:]' '[:lower:]')
-date=$(date +%Y-%m-%d)
-```
-
-Write file with:
-
-```markdown
----
-created: [ISO timestamp]
-title: [title]
-area: [area]
-files:
-  - [file:lines]
----
-
-## Problem
-
-[problem description - enough context for future agent to understand weeks later]
-
-## Solution
-
-[approach hints or "TBD"]
-```
-</step>
-
-<step name="update_state">
-If `.rihal/STATE.md` exists:
-
-1. Count pending todos in .rihal/todos/pending/
-2. Update "## Pending Todos" section (if exists)
-</step>
-
-<step name="git_commit">
-Commit the todo and any updated state:
-
-```bash
-git add .rihal/todos/pending/ .rihal/STATE.md 2>/dev/null || true
-git commit -m "docs: capture todo - $title" 2>/dev/null || true
-```
-
-Confirm: "Committed: docs: capture todo - [title]"
-</step>
-
-<step name="confirm">
-```
-Todo saved: .rihal/todos/pending/[filename]
-
-  [title]
-  Area: [area]
-  Files: [count] referenced
-
----
-
-Would you like to:
-
-1. Continue with current work
-2. Add another todo
-3. View all todos (/rihal-add-todo --list)
-```
-</step>
-
-</process>
-
-<success_criteria>
-- [ ] Directory structure exists
-- [ ] Todo file created with valid frontmatter
-- [ ] Problem section has enough context for future agent
-- [ ] No duplicates (checked and resolved)
-- [ ] Area consistent with existing todos
-- [ ] STATE.md updated if exists
-- [ ] Todo committed to git
-</success_criteria>
-</process>
-
-## Success Criteria
-
-- [ ] Task completed as requested
-- [ ] Output saved or reported
-- [ ] State updated if necessary
-- [ ] No errors encountered
-
-## On Error
-
-If arguments are invalid, missing files, or subagent fails:
-- Validate inputs match expected format
-- Check that required files exist
-- Retry with clearer arguments or report the specific error to the user
-
-
-## On Completion
-
-/rihal-check-todos — review all open todos
-/rihal-next — get suggested next action
-/rihal-progress — see overall roadmap status

package/rihal/workflows/analyze-dependencies.md

@@ -1,144 +0,0 @@
-# Workflow: rihal-analyze-dependencies
-
-<purpose>
-Analyze ROADMAP.md phases for dependency relationships before execution. Detect file overlap between phases, semantic API/data-flow dependencies, and suggest `Depends on` entries to prevent merge conflicts during parallel execution.
-</purpose>
-
-
-## Step 0 — Usage check
-
-If `$ARGUMENTS` is empty or contains only `--help` or `-h`:
-
-```
-/rihal-analyze-dependencies <argument-here>
-```
-
-**Examples:**
-```
-/rihal-analyze-dependencies example 1
-/rihal-analyze-dependencies example 2
-```
-
-STOP — do not proceed.
-
-## Step 0 — Load ROADMAP.md
-
-**Action:** Read `.planning/ROADMAP.md` and extract all phases.
-
-```bash
-test -f .planning/ROADMAP.md || echo "No ROADMAP.md found — run /rihal-new-project first."
-```
-
-For each phase, capture:
-- Phase number and name
-- Scope/Goal description
-- Files listed in `Files` or `files_modified` fields (if present)
-- Existing `Depends on` field value
-
-If file missing: exit with instructions to create project.
-
-## Step 1 — Infer likely file modifications
-
-**Action:** For each phase without explicit `files_modified`, analyze scope/goal and infer file domains.
-
-Use heuristics to classify phases:
-- **Database/schema phases** → migration files, schema definitions, model files
-- **API/backend phases** → route files, controller files, service files, handler files
-- **Frontend/UI phases** → component files, page files, style files
-- **Auth phases** → middleware files, auth route files, session/token files
-- **Config/infra phases** → config files, environment files, CI/CD files
-- **Test phases** → test files, spec files, fixture files
-- **Shared utility phases** → lib/utils files, shared type definitions
-
-Group phases by inferred file domain (database, API, frontend, auth, config, shared).
-
-## Step 2 — Detect dependency relationships
-
-**Action:** For each pair of phases (A, B), check for three types of dependencies.
-
-### File Overlap Detection
-If phases A and B both modify files in same domain or same specific file, one must run before the other. The foundational phase runs first.
-
-### Semantic Dependency Detection
-Read each phase's scope/goal for patterns:
-- Phase B mentions consuming/using something Phase A creates/implements
-- Phase B references "API", "schema", "model", "endpoint", "interface" that Phase A builds
-- Phase B says "after X complete", "once X built", "using the X from Phase N"
-- Phase B extends code that Phase A establishes
-
-### Data Flow Detection
-- Phase A creates data structures/schemas → Phase B consumes/transforms them
-- Phase A seeds/migrates database → Phase B reads from it
-- Phase A exposes API contract → Phase B implements client for it
-
-## Step 3 — Build dependency table
-
-**Action:** Output dependency suggestions for each phase.
-
-For each phase, print:
-
-```
-Phase N: <name>
-  Scope: <brief scope>
-  Likely touches: <inferred file domains>
-
-  Suggested dependencies:
-  → Depends on: <Phase M> — reason: <overlap/semantic/data-flow explanation>
-
-  Current "Depends on": <existing value or "(none)">
-```
-
-For phase pairs with no detected dependency: "No dependency detected between Phase X and Phase Y."
-
-## Step 4 — Summarize suggested changes
-
-**Action:** Show consolidated diff of proposed ROADMAP.md `Depends on` changes.
-
-```
-Suggested ROADMAP.md updates:
-  Phase 3: add "Depends on: 1, 2"   (file overlap: database schema)
-  Phase 5: add "Depends on: 3"      (semantic: uses auth API from Phase 3)
-  Phase 4: no change needed         (independent scope)
-```
-
-## Step 5 — Confirm and apply changes
-
-**Action:** Ask user for confirmation and apply changes if approved.
-
-```
-Apply these Depends on suggestions to ROADMAP.md? (yes / no / edit)
-```
-
-Handle responses:
-- **yes** — Write all suggested entries to ROADMAP.md. Confirm each write.
-- **no** — Print suggestions as text only. User updates manually.
-- **edit** — Present each suggestion individually with yes/no/skip per suggestion.
-
-When writing:
-- Locate phase entry and add or update `Depends on:` field
-- Preserve all other phase content unchanged
-- Do not reorder phases
-
-After applying: "ROADMAP.md updated. Run `/rihal-execute-milestone` to execute phases in the correct order."
-
-## Success Criteria
-
-- [ ] All phases analyzed for dependencies
-- [ ] File overlap detected correctly
-- [ ] Semantic dependencies identified
-- [ ] Data flow dependencies recognized
-- [ ] Suggestions clear and justified
-- [ ] User approval obtained before changes
-- [ ] ROADMAP.md updated atomically
-
-## On Error
-
-- **ROADMAP.md missing:** Print error and suggest creating project first
-- **Phase parsing fails:** Print which phase and why parsing failed
-- **File write fails:** Print error and suggest manual update
-
-## ▶ Next Up
-
-- **Circular deps found:** Fix dependency cycle, then re-run analysis
-- /rihal-execute {phase}
-- /rihal-progress

package/rihal/workflows/audit-fix.md

@@ -1,204 +0,0 @@
-<purpose>
-Autonomous audit-to-fix pipeline. Runs an audit, parses findings, classifies each as
-auto-fixable vs manual-only, spawns executor agents for fixable issues, runs tests
-after each fix, and commits atomically with finding IDs for traceability.
-</purpose>
-
-@.rihal/references/karpathy-guidelines.md
-
-<available_agent_types>
-- rihal-executor — executes a specific, scoped code change
-</available_agent_types>
-
-## Step 0 — Usage check
-
-If `$ARGUMENTS` is empty or contains only `--help` or `-h`:
-- Print the usage block below
-- STOP — do not proceed
-
-**Usage:**
-```
-/rihal-audit-fix [--max N] [--severity high|medium|all] [--dry-run] [--source audit]
-```
-
-**Examples:**
-```
-/rihal-audit-fix
-/rihal-audit-fix --max 10 --severity high
-/rihal-audit-fix --dry-run
-```
-
-<process>
-
-<step name="parse-arguments">
-Extract flags from the user's invocation:
-
-- `--max N` — maximum findings to fix (default: **5**)
-- `--severity high|medium|all` — minimum severity to process (default: **medium**)
-- `--dry-run` — classify findings without fixing (shows classification table only)
-- `--source <audit>` — which audit to run (default: **audit-uat**)
-
-Validate `--source` is a supported audit. Currently supported:
-- `audit-uat`
-
-If `--source` is not supported, stop with an error:
-```
-Error: Unsupported audit source "{source}". Supported sources: audit-uat
-```
-</step>
-
-<step name="run-audit">
-Invoke the source audit command and capture output.
-
-For `audit-uat` source:
-```bash
-INIT=$(node ".rihal/bin/rihal-tools.cjs" init audit-uat 2>/dev/null || echo "{}")
-if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi
-```
-
-Read existing UAT and verification files to extract findings:
-- Glob: `.planning/phases/*/*-UAT.md`
-- Glob: `.planning/phases/*/*-VERIFICATION.md`
-
-Parse each finding into a structured record:
-- **ID** — sequential identifier (F-01, F-02, ...)
-- **description** — concise summary of the issue
-- **severity** — high, medium, or low
-- **file_refs** — specific file paths referenced in the finding
-</step>
-
-<step name="classify-findings">
-For each finding, classify as one of:
-
-- **auto-fixable** — clear code change, specific file referenced, testable fix
-- **manual-only** — requires design decisions, ambiguous scope, architectural changes, user input needed
-- **skip** — severity below the `--severity` threshold
-
-**Classification heuristics** (err on manual-only when uncertain):
-
-Auto-fixable signals:
-- References a specific file path + line number
-- Describes a missing test or assertion
-- Missing export, wrong import path, typo in identifier
-- Clear single-file change with obvious expected behavior
-
-Manual-only signals:
-- Uses words like "consider", "evaluate", "design", "rethink"
-- Requires new architecture or API changes
-- Ambiguous scope or multiple valid approaches
-- Requires user input or design decisions
-- Cross-cutting concerns affecting multiple subsystems
-- Performance or scalability issues without clear fix
-
-**When uncertain, always classify as manual-only.**
-</step>
-
-<step name="present-classification">
-Display the classification table:
-
-```
-## Audit-Fix Classification
-
-| # | Finding | Severity | Classification | Reason |
-|---|---------|----------|---------------|--------|
-| F-01 | Missing export in index.ts | high | auto-fixable | Specific file, clear fix |
-| F-02 | No error handling in payment flow | high | manual-only | Requires design decisions |
-| F-03 | Test stub with 0 assertions | medium | auto-fixable | Clear test gap |
-```
-
-If `--dry-run` was specified, **stop here and exit**. The classification table is the
-final output — do not proceed to fixing.
-</step>
-
-<step name="fix-loop">
-For each **auto-fixable** finding (up to `--max`, ordered by severity desc):
-
-**a. Spawn executor agent:**
-```
-Task(
-  prompt="Fix finding {ID}: {description}. Files: {file_refs}. Make the minimal change to resolve this specific finding. Do not refactor surrounding code.",
-  subagent_type="rihal-executor"
-)
-```
-
-**b. Run tests:**
-```bash
-npm test 2>&1 | tail -20
-```
-
-**c. If tests pass** — commit atomically:
-```bash
-git add {changed_files}
-git commit -m "fix({scope}): resolve {ID} — {description}"
-```
-The commit message **must** include the finding ID (e.g., F-01) for traceability.
-
-**d. If tests fail** — revert changes, mark finding as `fix-failed`, and **stop the pipeline**:
-```bash
-git checkout -- {changed_files} 2>/dev/null
-```
-Log the failure reason and stop processing — do not continue to the next finding.
-A test failure indicates the codebase may be in an unexpected state, so the pipeline
-must halt to avoid cascading issues. Remaining auto-fixable findings will appear in the
-report as `not-attempted`.
-</step>
-
-<step name="report">
-Present the final summary:
-
-```
-## Audit-Fix Complete
-
-**Source:** {audit_command}
-**Findings:** {total} total, {auto} auto-fixable, {manual} manual-only
-**Fixed:** {fixed_count}/{auto} auto-fixable findings
-**Failed:** {failed_count} (reverted)
-
-| # | Finding | Status | Commit |
-|---|---------|--------|--------|
-| F-01 | Missing export | Fixed | abc1234 |
-| F-03 | Test stub | Fix failed | (reverted) |
-
-### Manual-only findings (require developer attention):
-- F-02: No error handling in payment flow — requires design decisions
-```
-</step>
-
-</process>
-
-<success_criteria>
-- Auto-fixable findings processed sequentially until --max reached or a test failure stops the pipeline
-- Tests pass after each committed fix (no broken commits)
-- Failed fixes are reverted cleanly (no partial changes left)
-- Pipeline stops after the first test failure (no cascading fixes)
-- Every commit message contains the finding ID
-- Manual-only findings are surfaced for developer attention
-- --dry-run produces a useful standalone classification table
-</success_criteria>
-
-## Success Criteria
-
-- [ ] Task completed as requested
-- [ ] Output saved or reported
-- [ ] State updated if necessary
-- [ ] No errors encountered
-
-## On Error
-
-If arguments are invalid, missing files, or subagent fails:
-- Validate inputs match expected format
-- Check that required files exist
-- Retry with clearer arguments or report the specific error to the user
-
-
-## On Completion
-
-/rihal-audit — re-run audit to verify fixes applied correctly
-/rihal-code-review — review the auto-applied changes
-/rihal-progress — see overall project state
-
-## ▶ Next Up
-
-- /rihal-verify-phase {phase}
-- /rihal-audit {phase}
-- /rihal-progress