@hanzlaa/rcode 4.10.2 → 4.10.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@hanzlaa/rcode",
-  "version": "4.10.2",
+  "version": "4.10.3",
   "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/rcode/workflows/council.md

@@ -602,6 +602,14 @@ node .rcode/bin/rcode-tools.cjs state record-council \
 node .rcode/bin/rcode-tools.cjs state record-session
 ```
 
+**Also record the decision itself (closes #1036-adjacent gap — dashboard "Decisions (ADRs)" reads `state.json`'s `decisions[]`, which `record-council` above does NOT populate; only `state add-decision` does).** Write one concise line per DISTINCT consensus decision the council reached — not the full synthesis prose, not one line per panelist. A council session that reached one architectural consensus gets one `add-decision` call; a session with 2-3 genuinely separate decisions gets that many calls. `add-decision` takes the summary as a plain positional argument (no `--summary-file` flag exists on this subcommand — verified against `rcode-tools.cjs`'s actual implementation, don't invent flags), so keep each summary to one shell-safe line:
+
+```bash
+node .rcode/bin/rcode-tools.cjs state add-decision "{one-line consensus decision, e.g. 'Password reset: opaque crypto token, sha256-hashed on existing user record, 15-30min single-use expiry, console-stub email'}"
+```
+
+If the council reached no real consensus (pure disagreement, or panelists only asked clarifying questions), skip this call — don't manufacture a decision that wasn't made.
+
 > **Note:** If `rcode-tools.cjs` state commands fail (e.g. state.json missing or not yet initialized), continue without error — state tracking is optional, the session artifact saved in Step 5 is mandatory.
 
 ## Success Criteria

package/rcode/workflows/execute-sprint.md

@@ -31,7 +31,11 @@ else
 fi
 ```
 
-Use `$EXEC_AGENT` as the `subagent_type` in every Task spawn below (Pattern A, Pattern B subagent route). No other change to the spawn prompt is needed — the persona file's own conditional clause tells it to load the full executor playbook when it sees `subagent_type` = itself and a SPRINT.md path in the prompt. If `$EXEC_AGENT` is a persona and that persona is not installed (agent file missing), fall back to `rcode-executor` and note the fallback in SUMMARY.md's Deviations section — do not fail the sprint over this.
+Use `$EXEC_AGENT` as the `subagent_type` in every Task spawn below (Pattern A, Pattern B subagent route). No other change to the spawn prompt is needed — the persona file's own conditional clause tells it to load the full executor playbook when it sees `subagent_type` = itself and a SPRINT.md path in the prompt.
+
+**Fall back to `rcode-executor` and note the fallback in SUMMARY.md's Deviations section (do not fail the sprint) when:**
+- `$EXEC_AGENT` is a persona and that persona's agent file is not installed in this project, OR
+- The persona agent **declines/refuses the role** — a persona's own scope-discipline and anti-injection instincts may correctly distrust a spawn prompt that merely *asserts* "you are the sprint executor" without provenance from a real `/rcode-execute` dispatch (confirmed live: this happens; a hand-authored trigger reads exactly like a prompt-injection attempt to the persona, and refusing that is the correct default). Detect this by the spawn returning zero commits / zero file changes with a refusal-shaped response (no tool calls, explanation citing lack of authorization or wrong capability lane) rather than a normal execution report. Retry once with `rcode-executor`; do not retry the same persona a second time.
 </step>
 
 <process>