@hanzlaa/rcode 3.6.5 → 3.6.7

package/cli/generate-command-skills.cjs

@@ -231,7 +231,29 @@ function main(packageRoot, targetSkillsDir, version, options = {}) {
     generated++;
   }
 
-  return { generated, skipped };
+  // Cleanup stale stubs: generated stubs whose command was removed from
+  // SIDEBAR_COMMANDS still block the corresponding ~/.claude/commands/ file
+  // in Claude Code 2.x (skill with user-invocable:false overrides the command).
+  // Delete any generated stub for a command no longer in the curated set.
+  let cleaned = 0;
+  try {
+    for (const entry of fs.readdirSync(targetSkillsDir)) {
+      if (!entry.startsWith('rihal-')) continue;
+      const cmdName = entry.replace(/^rihal-/, '');
+      if (SIDEBAR_COMMANDS.has(cmdName)) continue; // still wanted — leave it
+      if (realSkills.has(entry)) continue;          // real skill — never touch
+      const skillFile = path.join(targetSkillsDir, entry, 'SKILL.md');
+      if (!fs.existsSync(skillFile)) continue;
+      const text = fs.readFileSync(skillFile, 'utf8');
+      // Only remove stubs that were auto-generated from a command file.
+      if (!/^generated:\s*true/m.test(text)) continue;
+      if (!/^source:\s*rihal\/commands\//m.test(text)) continue;
+      fs.rmSync(path.join(targetSkillsDir, entry), { recursive: true, force: true });
+      cleaned++;
+    }
+  } catch { /* non-fatal */ }
+
+  return { generated, skipped, cleaned };
 }
 
 if (require.main === module) {
@@ -240,8 +262,8 @@ if (require.main === module) {
     console.error('Usage: generate-command-skills.cjs <package-root> <target-skills-dir> [version]');
     process.exit(2);
   }
-  const { generated, skipped } = main(packageRoot, targetSkillsDir, version);
-  console.log(`✓ ${generated} sidebar skill stub${generated === 1 ? '' : 's'} generated, ${skipped} skipped (already real skills or out of curated set)`);
+  const { generated, skipped, cleaned } = main(packageRoot, targetSkillsDir, version);
+  console.log(`✓ ${generated} sidebar skill stub${generated === 1 ? '' : 's'} generated, ${skipped} skipped, ${cleaned} stale stubs cleaned`);
 }
 
 module.exports = { main, SIDEBAR_COMMANDS };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hanzlaa/rcode",
-  "version": "3.6.5",
+  "version": "3.6.7",
   "description": "rcode — the AI team that never forgets. Persistent memory, specialist agents, and slash commands for AI IDEs. Works in Claude Code, Cursor, Gemini, VS Code, and Antigravity.",
   "main": "cli/index.js",
   "bin": {

package/rihal/skills/actions/4-implementation/rihal-dev-story/SKILL.md

@@ -32,15 +32,39 @@ Follow the instructions in ./workflow.md.
 - Reads story file first; executes tasks in order
 - Marks tasks [x] only when implementation AND tests pass
 - Updates story's File List and Dev Agent Record sections
-- Reports: "Story complete. N tasks done. Tests: PASS (X). Files: [list]."
+- Runs two-stage automated review before marking complete: spec compliance → code quality
+- Reports: "Story complete. N tasks done. Tests: PASS (X). Files: [list]. Reviews: SPEC ✅ QUALITY ✅"
 - Do NOT invent scope beyond the story
 - Do NOT commit with red tests
 
+## Review Protocol
+
+After all tasks complete, dispatches two fresh reviewer subagents before handing off to human review:
+
+**Stage 1 — Spec Compliance:** Confirms every AC is implemented, nothing extra was built. Repeats until COMPLIANT.
+
+**Stage 2 — Code Quality:** Reviews naming, error handling, test depth, security, maintainability. Fixes High-severity issues; logs Medium issues for human reviewer. Repeats until APPROVED/APPROVED_WITH_NOTES.
+
+## Model Selection
+
+When dispatching reviewer subagents or sub-tasks:
+- Mechanical tasks (isolated, clear spec, 1-2 files) → cheapest/fastest model
+- Integration tasks (multi-file, pattern matching) → standard model  
+- Architecture, design, or review tasks → most capable model
+
+## Implementer Status Protocol
+
+When running as a subagent implementer, report one of:
+- **DONE** — all requirements met, tests pass
+- **DONE_WITH_CONCERNS** — complete but flagging doubts about correctness or scope
+- **NEEDS_CONTEXT** — cannot proceed without specific missing information
+- **BLOCKED** — cannot complete; caller must restructure or escalate
+
 ## Examples
 
 ### Happy Path
 **Input:** "dev this story: .rihal/phases/phase-02/stories/story-005.md"
-**Expected behavior:** Read story, execute tasks in order, write tests, run suite after each task, mark checkboxes, update File List.
+**Expected behavior:** Read story, execute tasks in order, write tests, run suite after each task, mark checkboxes, update File List. After all tasks: dispatch spec compliance reviewer, dispatch code quality reviewer, mark as "review".
 
 ### Edge Case: Missing Story
 **Input:** "dev the login story" (story file doesn't exist)
@@ -49,3 +73,7 @@ Follow the instructions in ./workflow.md.
 ### Edge Case: Red Tests Mid-Execution
 **Input:** (task 2 breaks a test from task 1)
 **Expected behavior:** STOP. Report regression. Fix before continuing.
+
+### Edge Case: Spec Compliance Fails Review
+**Input:** Implementation complete but reviewer finds missing AC
+**Expected behavior:** Fix the gap, re-run tests, re-dispatch spec compliance reviewer. Do not proceed to code quality review until spec compliance passes.

package/rihal/skills/actions/4-implementation/rihal-dev-story/workflow.md

@@ -263,6 +263,21 @@ Load config from `{project-root}/.rihal/config.json` and resolve:
   <step n="5" goal="Implement task following red-green-refactor cycle">
     <critical>FOLLOW THE STORY FILE TASKS/SUBTASKS SEQUENCE EXACTLY AS WRITTEN - NO DEVIATION</critical>
 
+    <!-- Model selection guidance — applies when dispatching sub-tasks to subagents -->
+    <model_selection>
+      Mechanical tasks (isolated function, clear spec, 1-2 files) → use cheapest/fastest model
+      Integration tasks (multi-file coordination, pattern matching) → use standard model
+      Architecture, design, or review tasks → use most capable model
+    </model_selection>
+
+    <!-- Implementer status protocol — use when completing tasks as a subagent -->
+    <status_protocol>
+      DONE: All requirements met, tests pass, committed.
+      DONE_WITH_CONCERNS: Complete but flagging doubts — describe the concern. Caller decides before review.
+      NEEDS_CONTEXT: Cannot proceed without missing information — specify exactly what is needed.
+      BLOCKED: Cannot complete despite context — describe the blocker. Caller must restructure or escalate.
+    </status_protocol>
+
     <action>Review the current task/subtask from the story file - this is your authoritative implementation guide</action>
     <action>Plan implementation following red-green-refactor cycle</action>
 
@@ -410,6 +425,65 @@ Load config from `{project-root}/.rihal/config.json` and resolve:
     <action if="definition-of-done validation fails">HALT - Address DoD failures before completing</action>
   </step>
 
+  <step n="9.5" goal="Two-stage automated review: spec compliance then code quality">
+    <critical>Both stages must pass before the story is marked complete. Never skip either stage. Spec compliance must pass before starting code quality review.</critical>
+
+    <output>🔍 **Two-Stage Review** — verifying before handing off to human review</output>
+
+    <!-- STAGE 1: Spec Compliance -->
+    <output>
+    ━━━ Stage 1: Spec Compliance Review ━━━
+    </output>
+    <action>Spawn a fresh spec-compliance reviewer subagent. Provide it:
+      - Full story file contents (especially Acceptance Criteria and Tasks sections)
+      - List of all modified files from the File List section
+      - Brief: "Review that every AC is satisfied in the code. Flag anything built outside spec. Flag any AC with no corresponding implementation."
+    </action>
+
+    <action>Reviewer reports one of: COMPLIANT | NON_COMPLIANT (with specific gaps listed)</action>
+
+    <check if="spec compliance reviewer reports NON_COMPLIANT">
+      <action>Fix each gap: implement missing ACs, remove any out-of-spec additions</action>
+      <action>Re-run tests to confirm fixes pass</action>
+      <action>Re-dispatch spec compliance reviewer with the same prompt</action>
+      <action>Repeat until COMPLIANT</action>
+    </check>
+
+    <output>✅ Stage 1 passed — implementation is spec-compliant</output>
+
+    <!-- STAGE 2: Code Quality Review -->
+    <output>
+    ━━━ Stage 2: Code Quality Review ━━━
+    </output>
+    <action>Spawn a fresh code quality reviewer subagent. Provide it:
+      - All modified files (from File List)
+      - Story title and ACs (context for what was being built)
+      - Project coding standards (contents of CLAUDE.md or project-context.md if available)
+      - Brief: "Review code quality: naming conventions, error handling, test coverage depth, security, performance, maintainability. Severity: High (must fix) | Medium (should fix) | Low (note only)."
+    </action>
+
+    <action>Reviewer reports one of: APPROVED | APPROVED_WITH_NOTES | CHANGES_REQUIRED (severity breakdown)</action>
+
+    <check if="code quality reviewer reports CHANGES_REQUIRED (High severity issues)">
+      <action>Fix all High-severity issues</action>
+      <action>Re-run tests to confirm fixes pass</action>
+      <action>Re-dispatch code quality reviewer with the same prompt</action>
+      <action>Repeat until APPROVED or APPROVED_WITH_NOTES</action>
+    </check>
+
+    <check if="Medium-severity issues exist">
+      <action>Fix Medium-severity issues when the fix is straightforward and low-risk</action>
+      <action>Log unfixed Medium issues in Dev Agent Record → Completion Notes for human reviewer awareness</action>
+    </check>
+
+    <output>✅ Stage 2 passed — code quality verified</output>
+
+    <output>
+    ✅ **Two-stage review complete** — story is spec-compliant and quality-approved.
+       Ready for human review.
+    </output>
+  </step>
+
   <step n="10" goal="Completion communication and user support">
     <action>Execute the enhanced definition-of-done checklist using the validation framework</action>
     <action>Prepare a concise summary in Dev Agent Record → Completion Notes</action>

package/rihal/workflows/plan-spawn-planner.md

@@ -114,6 +114,37 @@ Output consumed by /rihal-execute. Plans need:
 </downstream_consumer>
 
 <deep_work_rules>
+## File Structure Map (REQUIRED — before task decomposition)
+
+Before writing any task, produce a file structure map listing every file this plan will create or modify:
+
+```
+FILES_TO_CREATE:
+  - exact/path/to/new/file.ts  — responsibility: [one sentence]
+FILES_TO_MODIFY:
+  - exact/path/to/existing.ts  — what changes: [one sentence]
+FILES_FOR_TESTS:
+  - tests/exact/path/test.ts   — tests for: [one sentence]
+```
+
+Rules:
+- Each file has one clear responsibility — if you can't describe it in one sentence, split the file
+- Files that change together should live together (split by responsibility, not layer)
+- This map is what informs task decomposition — each task should produce self-contained changes
+- In existing codebases: follow established patterns; only restructure files if a file is genuinely unwieldy and the split is included as its own task
+
+## No-Placeholders Rule (HARD BLOCKER)
+
+Every step must contain the actual content the executor needs. These are **plan failures** — never write them:
+- "TBD", "TODO", "implement later", "fill in details"
+- "Add appropriate error handling" / "add validation" / "handle edge cases" (without code)
+- "Write tests for the above" (without actual test code)
+- "Similar to Task N" — copy the code; executor may read tasks out of order
+- Steps that describe what to do without showing how (code blocks required for code steps)
+- References to types, functions, or methods not yet defined in any task in this plan
+
+If a step would require TBD content, either: (a) do the research now and fill it in, or (b) split into a research task that outputs a decision, followed by an implementation task that consumes it.
+
 ## Anti-Shallow Execution Rules (MANDATORY)
 
 Every task MUST include these fields — they are NOT optional:
@@ -185,6 +216,8 @@ Every task MUST include these fields — they are NOT optional:
 </deep_work_rules>
 
 <quality_gate>
+- [ ] File structure map written before first task (files_to_create / files_to_modify / files_for_tests)
+- [ ] No placeholder patterns: no TBD/TODO/implement-later, no "similar to Task N", no code steps without code
 - [ ] SPRINT.md files created in phase directory
 - [ ] Each plan has valid frontmatter including `files_modified:` array aggregating all `<files>` paths across tasks (consumed by execute.md intra-wave overlap checker)
 - [ ] Tasks are specific and actionable
@@ -195,10 +228,21 @@ Every task MUST include these fields — they are NOT optional:
 - [ ] Every task has `<done>` with a single observable acceptance sentence (Dimension 2 requirement)
 - [ ] Every `<action>` contains concrete values (no "align X with Y" without specifying what)
 - [ ] Tasks extending existing code have `<interfaces>` with relevant signatures
+- [ ] Type/name consistency: function names, types, and method signatures match across all tasks (no rename drift)
 - [ ] Dependencies correctly identified
 - [ ] Waves assigned for parallel execution
 - [ ] must_haves derived from phase goal
 </quality_gate>
+
+<self_review>
+After writing the complete plan, review the spec with fresh eyes before handing off:
+
+1. **Spec coverage** — skim each requirement in the phase goal / CONTEXT.md decisions. Can you point to a task that implements it? List any gaps; add tasks if needed.
+2. **Placeholder scan** — search the plan for the no-placeholder patterns listed above. Fix any found inline.
+3. **Type consistency** — check that function names, types, and method signatures used in later tasks match what earlier tasks define. A method called `clearLayers()` in Task 3 but `clearFullLayers()` in Task 7 is a bug.
+
+Fix issues inline. No sub-agent needed — this is a quick self-check before the sprint-checker runs.
+</self_review>
 ```
 
 ```

package/server/dashboard.js

@@ -205,7 +205,7 @@ function spawnOrchestrator() {
   try {
     _orchProc = spawn(process.execPath, [ORCH_BIN], {
       cwd: path.join(__dirname, '..'),
-      env: { ...process.env, ORCH_TOKEN },
+      env: { ...process.env, ORCH_TOKEN, RIHAL_DIR, PROJECT_ROOT },
       stdio: 'pipe',
     });
     _orchProc.stdout.on('data', chunk => {

package/server/orchestrator.js

@@ -40,8 +40,14 @@ try { pty = require('@lydell/node-pty'); } catch { /* handled in handleRun */ }
 let WebSocketServer = null;
 try { ({ WebSocketServer } = require('ws')); } catch { /* handled at boot */ }
 
-const PORT         = parseInt(process.env.ORCH_PORT || '7718', 10);
-const PROJECT_ROOT = path.resolve(__dirname, '..');
+const PORT = parseInt(process.env.ORCH_PORT || '7718', 10);
+// Use the project root passed by the dashboard (RIHAL_DIR → parent, or explicit
+// PROJECT_ROOT env var). Fall back to cwd so standalone orchestrator runs work.
+// NEVER use __dirname-relative path — that resolves to the npm package dir when
+// rcode is installed globally, not the user's actual project.
+const PROJECT_ROOT = process.env.PROJECT_ROOT
+  || (process.env.RIHAL_DIR ? path.dirname(process.env.RIHAL_DIR) : null)
+  || process.cwd();
 const CLAUDE_BIN   = process.env.CLAUDE_BIN || 'claude';
 
 // Per-session auth token — see authed(). The dashboard passes ORCH_TOKEN in