@hanzlaa/rcode 4.13.0 → 4.15.0

package/rcode/bin/rcode-tools.cjs

@@ -193,7 +193,13 @@ function extractReqIds(requirements) {
   if (!Array.isArray(requirements) || requirements.length === 0) return [];
   const seen = new Set();
   const out = [];
-  const re = /\bREQ-[A-Z0-9][A-Z0-9-]*\b/g;
+  // Two shapes, because real projects rarely use the REQ- prefix:
+  //   REQ-AUTH, REQ-FOO-BAR   — the documented convention
+  //   FOUND-01, RENT-04, AUTHZ-04, OBJ-06, CITY-02 — what projects actually write
+  // Matching only the first shape returned an empty phase_req_ids on every
+  // domain-prefixed project, and plan.md's Requirements Coverage Gate skips
+  // itself when that array is empty. The gate was silently off, not passing.
+  const re = /\bREQ-[A-Z0-9][A-Z0-9-]*\b|\b[A-Z][A-Z0-9]{1,15}-\d+[a-z]?\b/g;
   for (const line of requirements) {
     const matches = String(line).match(re) || [];
     for (const m of matches) {
@@ -1414,6 +1420,26 @@ function cmdState(subArgs) {
   // --- set-phase ---
   if (sub === 'set-phase') {
     const name = subArgs[1];
+    // A flag-looking argument is never a phase name. Without this,
+    // `state set-phase --phase 99 --status complete` created a phase literally
+    // NAMED "--phase", set current_phase to "--phase", and returned ok:true.
+    // Silent state corruption reported from a live project.
+    if (typeof name === 'string' && name.startsWith('--')) {
+      throw new Error(
+        `set-phase takes a phase NAME as a positional argument, not flags. ` +
+        `Got "${name}". Did you mean:\n` +
+        `  state set-phase "Phase name"        (set the current phase pointer)\n` +
+        `  phase complete <N>                  (mark a phase complete)\n` +
+        `  state planned-phase --phase <N>     (record a phase as planned)`
+      );
+    }
+    const strayFlags = subArgs.slice(2).filter(a => typeof a === 'string' && a.startsWith('--'));
+    if (strayFlags.length > 0) {
+      throw new Error(
+        `set-phase does not accept flags (${strayFlags.join(', ')}). It sets the ` +
+        `current-phase pointer only. Use 'phase complete <N>' to change a phase's status.`
+      );
+    }
     if (!name) throw new Error('set-phase requires a phase name argument');
     const state = readState() || defaultState();
     // Fix #854 — mark the previously active phase as completed before switching.
@@ -3256,6 +3282,29 @@ function cmdState(subArgs) {
   // instead. Its stale-executing-phase hygiene warning was ported there.
   // Kept only for backward compatibility with anyone scripting against it
   // directly; do not wire new callers to this — use `phase complete`.
+  // Records what the user actually authorized this session — 'plan', 'build',
+  // 'research', 'audit'. `resume-work` reads it so "resume" restores POSITION
+  // AND SCOPE, not position alone. Without it, a resume after a planning
+  // session reads as "keep going" and starts building work nobody asked for.
+  if (sub === 'set-intent') {
+    const flags = parseFlags(1);
+    const intent = flags.intent || subArgs[1];
+    const ALLOWED = ['plan', 'build', 'research', 'audit', 'review'];
+    if (!intent) throw new Error(`set-intent requires an intent (${ALLOWED.join('|')})`);
+    if (!ALLOWED.includes(intent)) {
+      throw new Error(`unknown intent "${intent}" — expected one of: ${ALLOWED.join(', ')}`);
+    }
+    const state = readState() || defaultState();
+    const previous = state.last_intent ? state.last_intent.intent : null;
+    state.last_intent = {
+      intent,
+      recorded_at: new Date().toISOString(),
+      source: flags.source || 'workflow',
+    };
+    writeState(state);
+    return { ok: true, intent, previous };
+  }
+
   if (sub === 'complete-phase') {
     const flags = parseFlags(1);
     if (!flags.phase) throw new Error('complete-phase requires --phase <N>');
@@ -3582,6 +3631,32 @@ function cmdState(subArgs) {
         }
 
         if (existingIdx >= 0) {
+          // Identity check BEFORE anything is carried over. Sync matched this
+          // entry by NUMBER, but a number is a slot, not an identity. When a
+          // roadmap is replaced, slot 3 can go from "Location Template" to
+          // "Competitor Gap Analysis" — two unrelated pieces of work. Carrying
+          // the old status across told a live project that competitor analysis
+          // was "complete" when it had never been started, and only a manual
+          // disk audit caught it.
+          const priorName = String(state.phases[existingIdx].name || '').trim();
+          const incomingName = String(phaseName || '').trim();
+          const normName = (n) => n.toLowerCase().replace(/[^a-z0-9]+/g, ' ').trim();
+          const identityChanged = priorName && incomingName
+            && normName(priorName) !== normName(incomingName);
+          if (identityChanged) {
+            // Different work in the same slot. Drop the inherited status and
+            // completion, and let the disk-derived pass below decide afresh.
+            state.phases[existingIdx].status = 'planned';
+            delete state.phases[existingIdx].completed;
+            delete state.phases[existingIdx].started;
+            parsed.identity_changed = parsed.identity_changed || [];
+            parsed.identity_changed.push({
+              phase: phaseNum,
+              was: priorName,
+              now: incomingName,
+              carried_status_dropped: true,
+            });
+          }
           // Backfill both id and number so future readers using either schema find it.
           state.phases[existingIdx].number = state.phases[existingIdx].number || phaseNum;
           state.phases[existingIdx].id = state.phases[existingIdx].id || phaseNum;
@@ -4468,6 +4543,70 @@ function cmdPhase(subArgs) {
   // Closes #731. No --names arg required — reads the ROADMAP table directly.
   // Only creates directories; does NOT create .md files inside them.
   // =====================================================================
+  // phase rename-dir <N> — align a phase directory's slug with its ROADMAP name.
+  // Dry-run by default: renaming a directory moves artifacts and, without git mv,
+  // detaches their history. There was no mechanism for this at all, so a roadmap
+  // rewrite left every directory carrying the name of whatever it used to be.
+  if (sub === 'rename-dir') {
+    // cmdPhase has no shared flag parser (parseFlags is local to cmdState), so
+    // read the two flags this needs directly.
+    const argvIdx = subArgs.findIndex((a, i) => i > 0 && !String(a).startsWith('--'));
+    const phaseFlagIdx = subArgs.indexOf('--phase');
+    const target = argvIdx > 0 ? subArgs[argvIdx]
+      : (phaseFlagIdx !== -1 ? subArgs[phaseFlagIdx + 1] : null);
+    if (!target) throw new Error('phase rename-dir requires a phase number');
+    const apply = subArgs.includes('--apply');
+
+    const found = cmdFindPhase([String(target)]);
+    if (!found.exists) throw new Error(`No phase directory on disk for phase ${target}`);
+
+    const roadmapLib = require(path.join(__dirname, 'lib', 'roadmap.cjs'));
+    const rp = roadmapLib.dispatch(PROJECT_ROOT, ['get-phase', String(target)]);
+    if (!rp || !rp.found || !rp.name) {
+      throw new Error(`Phase ${target} not found in ROADMAP.md — nothing to rename toward`);
+    }
+
+    const slugify = (t) => String(t).toLowerCase()
+      .replace(/[^a-z0-9]+/g, '-').replace(/^-|-$/g, '').replace(/-+/g, '-');
+    const newSlug = slugify(rp.name);
+    const phasesDir = path.join(PLANNING_DIR, 'phases');
+    const oldDirName = path.basename(found.dir);
+    const newDirName = `${target}-${newSlug}`;
+
+    if (oldDirName === newDirName) {
+      return { ok: true, renamed: false, reason: 'directory already matches the roadmap name', dir: found.dir };
+    }
+    const newPath = path.join(phasesDir, newDirName);
+    if (fs.existsSync(newPath)) {
+      throw new Error(`Target directory already exists: ${newDirName}. Resolve by hand — two phase dirs for one number is worse than a stale name.`);
+    }
+
+    if (!apply) {
+      return {
+        ok: true,
+        renamed: false,
+        dry_run: true,
+        from: oldDirName,
+        to: newDirName,
+        note: 'Dry run. Re-run with --apply to rename. Check first that the artifacts in this directory belong to the phase the roadmap now describes — if the phase was REPLACED rather than renamed, renaming hides that instead of fixing it.',
+      };
+    }
+
+    // Prefer `git mv` so the artifacts keep their history.
+    const oldPath = path.join(phasesDir, oldDirName);
+    let method = 'fs';
+    const { spawnSync } = require('child_process');
+    const gitMv = spawnSync('git', ['mv', oldPath, newPath], { cwd: PROJECT_ROOT, encoding: 'utf8' });
+    if (gitMv.status === 0) { method = 'git mv'; }
+    else { fs.renameSync(oldPath, newPath); }
+
+    return {
+      ok: true, renamed: true, method,
+      from: oldDirName, to: newDirName,
+      warning: 'Any file referencing the old path (SPRINT frontmatter, SUMMARY links, notes) still points at it. Grep for the old slug.',
+    };
+  }
+
   if (sub === 'scaffold-all') {
     const roadmapPath = path.join(PLANNING_DIR, 'ROADMAP.md');
     const phasesDir   = path.join(PLANNING_DIR, 'phases');
@@ -5801,11 +5940,52 @@ function cmdFindPhase(args) {
     .map((d) => path.relative(PROJECT_ROOT, path.join(phasesDir, d)));
   if (!exact) return { number: target, exists: false, dir: null, slug: null, decimal_children };
   const slugMatch = exact.match(/^\d+(?:\.\d+)?[-](.+)$/);
+  const slug = slugMatch ? slugMatch[1] : '';
+
+  // Name drift: the directory keeps the slug it was created with, but ROADMAP.md
+  // can be rewritten under it. Resolving to the existing directory is correct —
+  // that is where the artifacts and the git history live, and auto-renaming would
+  // orphan both. Staying SILENT about the divergence is not: an agent reading
+  // `slug: foundation-contact-loop` while the roadmap says "Rentable Contact
+  // Layer" has no way to tell whether it is looking at the same work.
+  // Same class as the phase-identity drift in `state sync --from-disk`.
+  let name_drift = null;
+  try {
+    const roadmapPath = path.join(PLANNING_DIR, 'ROADMAP.md');
+    if (slug && fs.existsSync(roadmapPath)) {
+      const roadmapLib = require(path.join(__dirname, 'lib', 'roadmap.cjs'));
+      const rp = roadmapLib.dispatch(PROJECT_ROOT, ['get-phase', String(target)]);
+      const roadmapName = rp && rp.found ? String(rp.name || '') : '';
+      if (roadmapName) {
+        const slugify = (t) => String(t).toLowerCase().replace(/[^a-z0-9]+/g, '-').replace(/^-|-$/g, '');
+        const fromRoadmap = slugify(roadmapName);
+        // Compare on word sets, not exact slugs — a truncated or reordered slug
+        // is normal, a different subject is the signal.
+        const words = (t) => new Set(String(t).split('-').filter(w => w.length > 3));
+        const dirWords = words(slug);
+        const roadWords = words(fromRoadmap);
+        const shared = [...dirWords].filter(w => roadWords.has(w)).length;
+        if (dirWords.size > 0 && roadWords.size > 0 && shared === 0) {
+          name_drift = {
+            dir_slug: slug,
+            roadmap_name: roadmapName,
+            note: 'Directory name and ROADMAP name share no significant words. '
+                + 'The phase may have been replaced under the same number. '
+                + 'The directory is NOT auto-renamed: its artifacts and git history '
+                + 'belong to whatever was built there. Confirm they are the same work '
+                + 'before planning or executing against it.',
+          };
+        }
+      }
+    }
+  } catch { /* drift detection is advisory — never fail a lookup over it */ }
+
   return {
     number: target,
     exists: true,
     dir: path.relative(PROJECT_ROOT, path.join(phasesDir, exact)),
-    slug: slugMatch ? slugMatch[1] : '',
+    slug,
+    name_drift,
     decimal_children,
   };
 }
@@ -6987,6 +7167,16 @@ async function main() {
         if (args[0] === 'list') { result = cmdPhasesList(args.slice(1)); if (result === undefined) return; }
         else { console.error('Unknown phases subcommand. Valid: list'); process.exit(1); }
         break;
+      case 'customize': {
+        const customize = require(path.join(__dirname, 'lib', 'customize.cjs'));
+        result = customize.dispatch(RCODE_DIR, args);
+        break;
+      }
+      case 'memlog': {
+        const memlog = require(path.join(__dirname, 'lib', 'memlog.cjs'));
+        result = memlog.dispatch(PLANNING_DIR, args);
+        break;
+      }
       case 'find-phase':
         result = cmdFindPhase(args);
         break;
@@ -7434,6 +7624,10 @@ async function main() {
         console.log('  phase next-range [count]                     → return next N contiguous free phase numbers (#730)');
         console.log('  phase scaffold-milestone --names "n1|n2|..." → bulk-create phase folders for a milestone (#731)');
         console.log('  phase scaffold-all                           → create missing phase folders for all phases in ROADMAP.md (#731)');
+        console.log('  phase rename-dir <N> [--apply]               → align a phase dir slug with its ROADMAP name (dry-run by default)');
+        console.log('  customize <resolve <name>|list|init <name>>  → per-workflow overrides in .rcode/custom/ that survive an update');
+        console.log('  memlog <init|append|read|open>               → append-only run memory (.planning/MEMLOG.md)');
+        console.log('    memlog append --type <decision|change|override|assumption|event|blocker> --text "..." [--phase N]');
         console.log('  workflow-config-audit                        → find workflows still referencing .planning/config.json (#733)');
         console.log('  commit "<msg>" [--files p1 p2 ...]          → atomic git commit with conventional-commits validation (no AI attribution, no --no-verify, no auto-push)');
         console.log('  commit-to-subrepo --subrepo <p> "<msg>"     → atomic commit inside a git subrepo (same validation as commit)');
@@ -7524,7 +7718,7 @@ async function main() {
         console.log('  state story list [--sprint <NN.S>] [--status <status>]');
         return;
       default: {
-        const stateSubs = ['read','get','init','set-phase','advance-plan','snapshot','update-progress','record-execution','record-council','record-chain','add-decision','decisions-global','add-blocker','resolve-blocker','record-session','set-ids-in-state','migrate-ids','migrate-schema','next-phase-id','next-plan-id','next-task-id','resolve-id','workstream-create','workstream-switch','workstream-list','workstream-status','workstream-complete','workstream-validate','insert-phase','planned-phase','begin-phase','complete-phase','reset'];
+        const stateSubs = ['read','get','init','set-phase','advance-plan','snapshot','update-progress','record-execution','record-council','record-chain','add-decision','decisions-global','add-blocker','resolve-blocker','record-session','set-ids-in-state','migrate-ids','migrate-schema','next-phase-id','next-plan-id','next-task-id','resolve-id','workstream-create','workstream-switch','workstream-list','workstream-status','workstream-complete','workstream-validate','insert-phase','planned-phase','begin-phase','complete-phase','set-intent','reset'];
         // Issue #656 — top-level aliases for intuitive guesses.
         const intuitionAliases = {
           blocker: 'state resolve-blocker',

package/rcode/references/agent-shared-rules.md

@@ -41,6 +41,74 @@ on what it touches, so a high score is corroboration and a zero score is no
 information. When your reading disagrees with the score, your reading wins, and
 you name the file or decision that made you override.
 
+**Apply the project's overrides before you follow a shipped rule.** rcode's
+workflows and references are regenerated by the installer, so anything a project
+edited into them is lost on the next update. Overrides live in `.rcode/custom/`,
+which the installer never writes:
+
+```bash
+node ".rcode/bin/rcode-tools.cjs" customize resolve <workflow-or-reference-name>
+```
+
+Non-empty `block` is appended AFTER the shipped content and wins where they
+conflict. Overrides append rather than replace on purpose: a replacing override
+silently drops whatever the next rcode version adds, which is the same trap as
+editing the installed file, just slower to notice.
+
+**Log it when it happens, not when you remember.** Every decision, change of
+direction, override, and assumption goes into the memlog at the moment it occurs:
+
+```bash
+node ".rcode/bin/rcode-tools.cjs" memlog append \
+  --type <decision|change|override|assumption|event|blocker> \
+  --text "<one line, with the reason>" [--phase N]
+```
+
+Not at the end of the session, not "when there's a natural pause" — those are the
+entries that never get written. **Whatever is not logged is lost on the next
+`/clear` or resume**, and a project whose artifacts nobody can explain is the
+result. The memlog is append-only: a wrong entry is followed by a correcting
+entry, never edited away, so the disagreement stays visible.
+
+This does not replace `state add-decision` — that is the curated record of
+decisions that stuck. The memlog is the raw trail, including the reversals.
+
+**Elicitation is not authoring — hand the pen back.** When gathering what the user
+wants, the moment you catch yourself naming the stack, picking the MVP cut, or
+proposing the phase breakdown, stop and hand it back to them. Infer-and-confirm
+("I'm assuming the maintainer is you, not a client — right?") is fine; presenting
+your conclusion as a finding is not. Every inferred value that reaches an artifact
+carries an inline `[ASSUMPTION]` tag, and every tag gets walked with the user
+before that artifact is final. An untriaged assumption in a finished document is a
+decision nobody made.
+
+**Never decide the stack for the user.** Technology choice — language, framework,
+CMS, database, hosting model — is the user's call, always. Research produces a
+suggestion; only the user turns it into a decision. Present it with the ONE reason
+that actually drove it, in their terms, and offer three ways out: confirm it, name
+their own, or ask for more comparison. Then stop. No default, no auto-selection,
+no "the obvious choice for this domain" — a wrong stack is the single most
+expensive thing in a project to reverse.
+
+**Write the premise into the decision, and re-open it when the premise dies.** "X
+because a non-technical client updates content themselves" stays true only while
+there is a non-technical client. When the project pivots, every decision whose
+stated reason the pivot invalidated goes back to the user. A decision whose reason
+has expired is not locked, it is stale — and treating it as locked is how a
+codebase gets built twice.
+
+**Planning never authorizes building.** If the user asked you to plan, design,
+research, or audit, the deliverable is the plan, the design, the findings — not
+the implementation. Finishing the plan and continuing into code is not
+thoroughness, it is doing work nobody approved, and it costs more to unwind than
+it saved. The same applies to an ambiguous continuation like "resume", "carry
+on", or "next": it restores POSITION, never SCOPE. When the standing instruction
+was to plan, a resume continues planning.
+
+If you believe the next step is obvious and valuable, say so in one line and stop.
+The user typing the next command takes two seconds; undoing an unrequested build
+took a whole session.
+
 ---
 
 ## Redirect protocol

package/rcode/references/planner-playbook.md

@@ -154,6 +154,17 @@ autonomous: true|false
 files_modified: [...]
 requirements: [...]
 must_haves: {truths, artifacts, key_links}
+
+**`truths` are copied from the requirement's Consequences, not invented.** For
+each requirement this plan claims, read its `**Consequences (testable):**` list in
+REQUIREMENTS.md and carry those lines into `must_haves.truths` verbatim. You are
+transcribing a decision someone already made, not making a new one.
+
+Invent a truth only when the requirement has no consequences recorded — and when
+you do, say so in the plan (`[DERIVED]` prefix on that truth) so the verifier
+knows it is checking your reconstruction rather than the requirement's own
+criteria. A phase full of `[DERIVED]` truths is a signal the requirements were
+never finished, not a signal to proceed quietly.
 ---
 
 ## Sprint {phase}.{plan}: {one-line sprint goal, plain English, no jargon}

package/rcode/references/questioning.md

@@ -105,10 +105,108 @@ A well-paced Socratic conversation follows a natural arc:
    ↓ Proceed to planning or revisit if gaps remain
 ```
 
-Each phase should feel **natural, conversational**, not like a checklist. If the user volunteers information, use it; don't force a predetermined sequence.
+Each phase should feel **natural, conversational**, not like a checklist. If the user volunteers information, use it; don't force a predetermined sequence. **This is a rule about TONE, not about coverage** — the decisions in the Mandatory decision set below still all get resolved, in whatever order the conversation makes natural.
 
 ---
 
+## Working mode — offer it, don't read it from config
+
+**Before any planning questions, ask how the user wants to work.** This is a
+per-run choice presented to them, never a config flag read silently:
+
+- **Fast path** — batch the remaining gaps into one or two consolidated
+  questions, then draft the full artifact, marking every inferred value with an
+  `[ASSUMPTION]` tag inline. The user reviews and iterates. Initial quality
+  depends on how much they gave upfront.
+- **Coaching path** — walk the decisions together, section by section.
+
+Why it must be asked: a user who never enabled autonomous mode should never be
+*treated* as if they had. Confirmed live — a user asked for a project to be
+planned, was never offered this choice, got no defined questions, and received a
+plan built on assumptions they never saw. "You didn't turn on yolo" is not a
+defence when nothing ever asked.
+
+Auto/yolo mode picks Fast path automatically. Everything else asks.
+
+## Stakes calibration — one probe, before anything else
+
+Ask once, early: **is this a hobby/solo thing, an internal tool, or a launch?**
+Then scale rigor to the answer. rcode's pipeline is built for the launch case and
+applying it whole to a weekend project is its own kind of failure — the user
+abandons the process rather than the project.
+
+| Stakes | Depth |
+|---|---|
+| Hobby / solo | Minimal artifacts. Reviewer gates run quietly or not at all |
+| Internal tool | Normal pipeline, lighter review |
+| Launch / production | Full pipeline, all gates, nothing skipped |
+
+## Elicitation, not direction — the hand-back rule
+
+Discovery pulls the user's vision out. It does not insert yours.
+
+**When you catch yourself naming the stack, picking the MVP cut, or proposing the
+phase breakdown — stop. You have crossed from asking into authoring. Hand the pen
+back.**
+
+Infer-and-confirm is fine: *"I'm assuming the maintainer is you, not a client —
+right?"* Quizzing the user through a tree of your own options is not, and neither
+is presenting your conclusion as the finding.
+
+This is the rule that would have prevented the most expensive failure in rcode's
+own history: a session picked a stack, phased a roadmap around it, and built on
+it, having never handed the pen back once.
+
+## Mandatory decision set — tone is conversational, coverage is not
+
+The "don't feel like a checklist" rule above governs **tone**. It does not govern
+**coverage**. There is a set of decisions that shape everything downstream, and
+each one must be either answered by the user or recorded as an assumption with
+its reason. Silently deciding one on the user's behalf is not conversational
+skill, it is skipping the question.
+
+Confirmed live: a user asked for a project to be planned, was never asked a
+single defined question, and got a stack, a roadmap, and an implementation built
+on a premise they had never confirmed. When the premise turned out to be wrong
+the whole build was thrown away. Nothing in this file forced the question,
+because this file told the asker to avoid predetermined sequences.
+
+Every one of these must be resolved before PROJECT.md is written:
+
+| Decision | Why it cannot be assumed |
+|---|---|
+| **Who maintains this after launch** | Drives the stack more than any technical factor. "Non-technical client" and "you, the technical owner" give opposite answers |
+| **Stack** | Most expensive thing in the project to reverse. Never decided for the user — see the stack gate |
+| **Who the users are, and whether there are roles** | Auth, permissions, and data model all hang off it |
+| **What is explicitly OUT of scope for v1** | An unstated exclusion reappears later as a gap |
+| **What already exists** | Greenfield vs brownfield changes every phase |
+| **What "done" means for the first milestone** | Without it there is no way to verify anything |
+| **Any hard constraint** — budget, deadline, hosting, compliance, locale | These invalidate otherwise-correct plans |
+
+**How to run it without sounding like a form:** weave them into the conversation
+in whatever order the user's own answers suggest — that part stays conversational.
+But **track them, and before you write PROJECT.md, state which ones the user
+actually answered and which you are assuming, with the assumption spelled out.**
+
+```
+Before I write this up — you answered: maintainer (you), scope (city pages only),
+users (visitors, no login).
+I'm assuming: no deadline, hosting undecided, English only.
+Correct any of those, or say go.
+```
+
+**Tag assumptions in the artifact itself, not just in chat.** Every inferred value
+written into PROJECT.md, REQUIREMENTS.md, or ROADMAP.md carries an inline
+`[ASSUMPTION]` marker. A summary the user scrolled past is not consent; a tag in
+the document survives the conversation and can be triaged later.
+
+Before any artifact is marked final, **walk every `[ASSUMPTION]` tag with the
+user**: confirm it, correct it, or defer it with an owner. An untriaged assumption
+in a finalised document is a decision nobody made.
+
+That block is not optional and auto mode does not remove it. An assumption the
+user never saw is indistinguishable from a decision you made for them.
+
 ## Context Checklist
 
 After Socratic questioning, verify these dimensions were covered:
@@ -122,7 +220,7 @@ After Socratic questioning, verify these dimensions were covered:
 - [ ] **Auth/identity** — SSO, local accounts, guest access, or a specific IdP?
 - [ ] **Locale/i18n** — Which languages/regions must be supported, RTL needed?
 
-If gaps remain after natural conversation, weave questions naturally. Don't suddenly shift to checklist mode.
+If gaps remain after natural conversation, weave questions naturally. Don't suddenly shift to checklist mode — but do NOT let "not a checklist" become "never asked". Anything from the Mandatory decision set still unresolved gets asked outright before you move on, plainly, rather than silently assumed.
 
 ---
 

package/rcode/references/roadmapper-playbook.md

@@ -145,6 +145,28 @@ Read only when the current task needs the detail. Don't preemptively load.
 ## Workflow
 
 1. **Read context** — REQUIREMENTS.md, FEATURES.md, ARCHITECTURE.md, STACK.md, RESEARCH.md (per `<files_to_read>`).
+   **STACK.md is a suggestion until a `state add-decision` entry shows the user
+   confirmed it.** If no such entry exists, do not build the roadmap around that
+   stack — say the stack is unconfirmed and route back to the stack gate. A
+   roadmap phased around an unconfirmed stack is what makes the wrong choice
+   expensive: by the time anyone questions it, every phase depends on it.
+   If the project has pivoted since the stack was chosen, check whether the
+   premise recorded with that decision still holds. If it does not, the decision
+   is stale, not locked.
+   **Read PROJECT.md's Glossary and use its terms verbatim** in phase names and
+   goals. A roadmap that renames the domain's nouns forces every downstream
+   agent to guess which concept a phase is about.
+   **Cut phases vertically.** Every phase must answer: what can someone do after
+   this that they could not do before? A phase whose goal names a layer ("the
+   data model", "the API", "all the repositories") rather than a capability is
+   horizontal, and everything it builds goes unexercised until some later phase
+   reaches for it — which is how a service ships with no caller. Create the
+   schema, services, and endpoints a phase's own capability needs, and no more.
+   A genuine foundation phase is allowed, but it names what it unblocks in the
+   same sentence and is no bigger than that.
+   **Read PROJECT.md's Out of Scope (Non-Goals) before phasing.** A phase whose
+   goal reaches into a declared non-goal is scope creep with a plan attached —
+   flag it rather than quietly phasing it.
 2. **Cluster requirements** — group related requirements into natural delivery units.
 3. **Derive phases** — name each phase by what the user can DO after it, not what was built.
 3b. **Declare the Information Architecture** (UI projects only) — before phases are finalized, explicitly decide the app's eventual final-state IA, not per-phase: enumerate the top-level sections (e.g. Dashboard / Operations / Reports / Admin), pick sidebar vs topbar vs tabs, state max nesting depth (e.g. 2 levels: section > subsection), and group every planned phase's screens under one of those sections. Persist this as an `IA.md` (or a "## Information Architecture" section in ROADMAP.md). A flat list of nav links that grows by one item per phase is not an IA decision — it's the failure mode this step exists to prevent. Later phases must slot new routes under an existing top-level section or explicitly propose adding one, never silently append a new sidebar item.

package/rcode/references/universal-anti-patterns.md

@@ -10,6 +10,32 @@ Phase plan picks up scope adjacent to the actual goal. Symptom: phase descriptio
 ### Implicit prerequisites
 Phase assumes another phase has shipped without declaring the dependency. Symptom: plan refers to a file or table that doesn't exist yet. Fix: surface the dependency in the phase's `Depends on` line in ROADMAP.md.
 
+### Layer-first phasing (horizontal slices)
+
+A phase whose whole job is one technical layer: "Phase 1 — create all the
+database tables", "Phase 2 — build every repository", "Phase 3 — the API".
+Symptom: the phase's goal names a layer or an artifact type rather than
+something a user can do afterwards, and no phase before the last one produces
+anything anybody can use.
+
+Why it costs more than it looks: nothing in a layer-first phase is exercised
+until a much later phase reaches for it, so a table, a service, or an endpoint
+can be built wrong — or built and never wired to anything — and pass every gate
+in between. Confirmed live: a project shipped a cycle-closing service with
+exactly one importer in the whole repo, its own test, because the phase that
+built it was never obliged to connect it to anything a user touches.
+
+Fix: **cut phases vertically.** Each phase delivers one thing end to end, and
+creates only the schema, services, and endpoints that thing needs. Tables get
+created by the first phase that reads or writes them, not by a phase whose
+purpose is tables. If a foundation genuinely must come first (auth, a
+migration framework), name what it unblocks in the same sentence and keep it as
+small as that.
+
+The test: read a phase goal and ask *what can someone do after this that they
+could not do before?* If the honest answer is "nothing yet, but later phases
+need it", the phase is horizontal.
+
 ### Vague acceptance
 Acceptance criterion is "users can do X" with no measurable threshold. Fix: make every acceptance criterion observable from outside the system — a CLI command, an API response, a log line, a UI assertion.
 

package/rcode/references/verifier-playbook.md

@@ -41,6 +41,18 @@ Before verifying, discover project context:
 4. **Verify observable truths** — for each truth, status ✓ VERIFIED / ✗ FAILED / ? UNCERTAIN.
 5. **Verify artifacts (4 levels)** — exists, substantive, wired, data-flows. Use `rcode-tools.cjs verify artifacts`.
 6. **Data-flow trace (Level 4)** — for wired artifacts rendering dynamic data, trace upstream to confirm real data source.
+6e. **Check the requirement's own consequences, not your reconstruction of them.**
+For every requirement this phase claims, read its `**Consequences (testable):**`
+list in REQUIREMENTS.md and verify those. Where a plan's truth carries a
+`[DERIVED]` prefix, the requirement had none recorded and you are checking an
+invented criterion — say so in VERIFICATION.md. A phase that passes only against
+derived criteria has not been verified against what anyone actually asked for.
+
+6d. **Unconfirmed assumptions are verification gaps.** Read PROJECT.md's
+Assumptions Index. Any row still `unconfirmed` that this phase's must-haves
+depend on is a gap, not a formality — the phase was built on something nobody
+agreed to. Name it in VERIFICATION.md rather than passing over it.
+
 6c. **Production reachability (Level 5b) — EVERY phase, including backend-only.**
 For each non-UI module this phase delivered, list its importers and classify them
 production vs test. If every importer is a test file, the phase shipped dead code

package/rcode/workflows/execute.md

@@ -37,6 +37,17 @@ Bypassing it produces a built project with no execution trace, no SUMMARY.md, an
 a dashboard frozen at `planned`. See issue #915.
 
 <pre_flight>
+0a. **Record the authorized scope** — the user ran an execute command, so building
+    is authorized from here:
+    ```bash
+    node ".rcode/bin/rcode-tools.cjs" state set-intent build --source execute.md
+    node ".rcode/bin/rcode-tools.cjs" memlog append --type event --text "Execution started for phase ${PHASE_NUMBER}" --phase "${PHASE_NUMBER}"
+    ```
+
+    Log every deviation, checkpoint decision, and override with
+    `memlog append` as it happens — a deviation nobody recorded is
+    indistinguishable from a plan that was followed.
+
 **Mandatory before execution begins.** Run these checks first and surface
 findings BEFORE any subagents are spawned. If any check fails, stop and
 route back to the user.

package/rcode/workflows/new-project-define-requirements.md

@@ -111,6 +111,41 @@ Create `.planning/REQUIREMENTS.md` with:
 
 **REQ-ID format:** `[CATEGORY]-[NUMBER]` (AUTH-01, CONTENT-02)
 
+**Every requirement carries its testable consequences.** This is the shape:
+
+```markdown
+- [ ] **AUTH-01**: User can log in with email and password and stay logged in
+      across sessions.
+  - **Consequences (testable):**
+    - A valid credential pair returns a session cookie with a 30-day expiry
+    - An invalid password returns 401 and does not reveal whether the email exists
+    - A logged-in user reloading the page stays logged in
+```
+
+**Why the consequences live here and not in the plan.** rcode's verifier derives
+`must_haves` at verification time, long after the requirement was written — so it
+is guessing at what "done" meant for a requirement someone else authored. That
+guess is where verification quietly goes wrong: a phase passes because the
+verifier's invented criterion was met, not the one the requirement intended.
+
+Writing the consequences with the requirement moves that decision to the moment
+the person actually knows the answer. The planner then copies them into
+`must_haves.truths` instead of inventing them, and the verifier checks the
+requirement's own criteria rather than its own reconstruction.
+
+A requirement whose consequences you cannot state is a requirement you have not
+finished writing. "Handle authentication properly" has no consequences because it
+has no meaning — that is the signal to push for specificity, not to move on.
+
+**Scope dial:** hobby/solo — one consequence per requirement is usually enough,
+and it can be a sentence. Internal tool — the happy path plus the one failure
+mode that matters. Launch — every condition a reviewer would ask about, including
+the negative cases.
+
+**Do not change the traceability table's shape.** `requirements mark-complete`
+rewrites the status cell of a `| ID | ... | status |` row; consequences are nested
+under the requirement in the list above, not added as table columns.
+
 **Requirement quality criteria:**
 
 Good requirements are:
@@ -119,6 +154,7 @@ Good requirements are:
 - **User-centric:** "User can X"
 - **Atomic:** One capability per requirement
 - **Independent:** Minimal dependencies on other requirements
+- **Consequential:** you can name what must be true for it to be done
 
 Reject vague requirements. Push for specificity: