rafcode 2.5.1 → 3.2.1

package/.claude/settings.local.json

@@ -33,7 +33,8 @@
       "Bash(bash:*)",
       "Bash(git add:*)",
       "WebFetch(domain:support.claude.com)",
-      "WebFetch(domain:www.anthropic.com)"
+      "WebFetch(domain:www.anthropic.com)",
+      "Bash(ls:*)"
     ]
   }
 }

package/CLAUDE.md

@@ -1,349 +1,11 @@
-# RAF - Claude Code Instructions
+# RAF
 
-## Project Overview
+Node.js CLI tool that orchestrates task planning and execution via Claude Code CLI.
 
-RAF (Ralph's Automation Framework) is a Node.js CLI tool that orchestrates task planning and execution using Claude Code CLI.
+- New features should be configurable — add keys to `DEFAULT_CONFIG` in `src/types/config.ts`
 
-## Architecture
+## When Changing Code
 
-- **Runtime**: Node.js 20+ with ESM modules
-- **Language**: TypeScript (strict mode)
-- **CLI Framework**: Commander.js
-- **TTY Emulation**: node-pty for interactive Claude sessions
-- **Testing**: Jest with ts-jest ESM preset
-
-## Directory Structure
-
-```
-src/
-├── index.ts                 # CLI entry point
-├── commands/                # CLI commands (plan, do, status, config)
-├── core/                    # Core business logic
-├── prompts/                 # System prompts for Claude
-│   └── config-docs.md       # Full config reference (used by raf config)
-├── parsers/                 # Output parsing utilities
-├── utils/                   # Utility functions
-└── types/                   # TypeScript type definitions
-```
-
-## RAF Project Structure
-
-Each RAF project follows this structure:
-```
-RAF/
-└── abcdef-project-name/    # 6-char epoch-based base26 ID (a-z only)
-    ├── input.md             # User requirements
-    ├── decisions.md         # Q&A from planning interviews
-    ├── plans/               # Task breakdowns
-    │   ├── 01-task-name.md  # 2-char base36 task ID
-    │   └── 02-another-task.md
-    └── outcomes/            # Completed task results
-        ├── 01-task-name.md
-        └── 02-another-task.md
-```
-
-### Plan File Structure
-
-Each plan file MUST have Obsidian-style frontmatter at the top, before the `# Task:` heading:
-```markdown
----
-effort: medium
----
-# Task: [Task Name]
-
-## Objective
-[Clear, one-sentence description]
-
-## Context
-[Why this task is needed]
-
-## Dependencies
-[Optional - comma-separated task IDs, e.g., "01, 02"]
-[If a dependency fails, this task is blocked]
-
-## Requirements
-- Requirement 1
-- Requirement 2
-
-## Implementation Steps
-1. Step 1
-2. Step 2
-
-## Acceptance Criteria
-- [ ] Criterion 1
-- [ ] Criterion 2
-
-## Notes
-[Additional context]
-```
-
-**Frontmatter**:
-- Uses standard Obsidian/YAML format: opening `---`, `key: value` lines, closing `---`
-- `effort` is REQUIRED: `low`, `medium`, or `high` — determines execution model via `effortMapping`
-- `model` is OPTIONAL: explicit model override (subject to ceiling)
-- Frontmatter is parsed by `src/utils/frontmatter.ts`
-- Parser also supports legacy format (no opening `---`) for backward compatibility
-
-**Dependencies Section**:
-- Optional - omit if task has no dependencies
-- Uses task IDs only (e.g., `01, 02`)
-- If a dependency fails, dependent tasks are automatically blocked
-
-## Development Commands
-
-```bash
-npm run build      # Compile TypeScript
-npm run dev        # Watch mode compilation
-npm test           # Run tests
-npm run lint       # Type check without emit
-```
-
-## Code Style Guidelines
-
-1. **ESM Modules**: Always use `.js` extension in imports (TypeScript will resolve `.ts` files)
-2. **Strict TypeScript**: All code must pass strict type checking
-3. **Error Handling**: Use typed errors and handle edge cases explicitly
-4. **Async/Await**: Prefer async/await over raw promises
-5. **No Default Exports**: Use named exports for better refactoring support
-
-## Testing Requirements
-
-- Unit tests for all core modules
-- Integration tests for command flows
-- Mock external dependencies (Claude CLI, file system where appropriate)
-- Follow TDD approach - write tests first
-
-## Key Implementation Details
-
-### node-pty Usage
-- Required for real TTY interaction with Claude's AskUserQuestionTool
-- Use `setRawMode(true)` for interactive planning mode
-- Graceful cleanup on process termination
-
-### Output Parsing
-- Look for `<promise>COMPLETE</promise>` or `<promise>FAILED</promise>` markers
-- Detect context overflow patterns
-- Parse task completion status
-
-## Architectural Decisions (from completed projects)
-
-### State Derivation Over Persistence
-- Task status determined by outcome file existence and content
-- Outcome files must end with `<promise>COMPLETE</promise>` or `<promise>FAILED</promise>` marker
-- Use `state-derivation.ts` module: `deriveProjectState()`, `getNextPendingTask()`, `isProjectComplete()`
-
-### Outcome File Flow
-- Claude writes outcome files during task execution (not RAF)
-- RAF validates outcome by checking for completion marker
-- If no marker found, RAF generates minimal fallback outcome
-- Metadata (attempts, elapsed time, timestamp) appended to outcome
-
-### Failure Analysis
-- On task failure, RAF analyzes the failure using Claude Haiku
-- Programmatic failures (API errors, timeouts, context overflow) handled without API call
-- Failure reports include: Failure Reason, Analysis, Suggested Fix, Relevant Output
-- All failure outcomes end with `<promise>FAILED</promise>` marker
-
-### Configurable by Default
-- If a feature or setting can be configurable, it should be configurable through the config system
-- Built-in defaults in `DEFAULT_CONFIG` (`src/types/config.ts`) provide sensible out-of-the-box behavior
-- Global config at `~/.raf/raf.config.json` overrides defaults
-- CLI flags override config values
-- Three-tier precedence: **CLI flag > global config > built-in defaults**
-- When adding new features, add corresponding config keys to the schema
-
-### Configuration System
-- **Config file**: `~/.raf/raf.config.json` (optional — missing file uses all defaults)
-- **Schema** (defined in `src/types/config.ts`):
-  - `models.*` — Claude model per scenario (`execute`, `plan`, `nameGeneration`, `failureAnalysis`, `prGeneration`, `config`)
-  - `effortMapping.*` — maps task effort labels (`low`, `medium`, `high`) to models
-  - `timeout` — task timeout in seconds
-  - `maxRetries` — max retry attempts per task
-  - `autoCommit` — whether Claude auto-commits on task completion
-  - `worktree` — default worktree mode for plan/do commands
-  - `syncMainBranch` — sync main branch with remote before worktree/PR operations (default: true)
-  - `commitFormat.*` — commit message templates (`task`, `plan`, `amend`, `prefix`)
-- **Validation**: strict — unknown keys rejected at every nesting level (`src/utils/config.ts`)
-- **Deep-merge**: partial overrides merge with defaults (only specify keys you want to change)
-- **Helper accessors**: `getModel()`, `getEffortMapping()`, `resolveEffortToModel()`, `getModelTier()`, `applyModelCeiling()`, `getCommitFormat()`, `getCommitPrefix()`, `getTimeout()`, `getMaxRetries()`, `getAutoCommit()`, `getWorktreeDefault()`, `getSyncMainBranch()` (all in `src/utils/config.ts`)
-- **Full reference**: `src/prompts/config-docs.md` (also serves as system prompt for `raf config`)
-
-### Per-Task Model Resolution
-- Plan files contain `effort` frontmatter that determines which model executes the task
-- `effortMapping` config maps effort labels to models: `{ low: "sonnet", medium: "opus", high: "opus" }`
-- `models.execute` acts as a ceiling — tasks can't exceed this model tier
-- On retry, tasks escalate to the ceiling model for a better chance of success
-- If a plan has no effort frontmatter, `models.execute` is used as a fallback (with a warning)
-
-### `raf config` Command
-- `raf config` — launches interactive Claude session for viewing/editing config
-- `raf config "use haiku for name generation"` — session with initial prompt
-- `raf config --reset` — deletes config file after confirmation prompt
-- Session uses config documentation as system prompt and shows current config state
-- Post-session validation checks the config file for errors and warns on issues
-- Implementation: `src/commands/config.ts`
-
-### Project Naming Convention
-- Format: `XXXXXX-project-name` where `XXXXXX` is a 6-character base26 ID (a-z only)
-- ID is generated from `(current_unix_seconds - RAF_EPOCH)` encoded as base26, left-padded with 'a' to 6 characters
-- Base26 encoding: a=0, b=1, ..., z=25 (lowercase letters only, no digits)
-- RAF_EPOCH is 2026-01-01T00:00:00Z (Unix timestamp 1767225600)
-- Project name is kebab-case derived from core feature
-- IDs are unique by timestamp and sort chronologically
-- Project IDs are visually distinct from task IDs (which use base36 with digits)
-
-### Task ID Format
-- Task IDs are 2-character base36 strings, zero-padded (e.g., `01`, `0a`, `1z`, `zz`)
-- Base36 charset: 0-9, a-z (lowercase)
-- Supports up to 1296 tasks per project (00-zz)
-- Task numbering starts at `01` (not `00`)
-- Sort order: 00, 01, ..., 09, 0a, 0b, ..., 0z, 10, 11, ..., zz
-- Utilities in `src/utils/paths.ts`: `encodeTaskId()`, `decodeTaskId()`, `TASK_ID_PATTERN`
-- File naming: `01-task-name.md`, `0a-task-name.md`, etc.
-
-### Project Identifier Resolution
-Support multiple identifier formats in commands:
-1. Base26 ID: `abcdef` (6-character epoch-based ID, a-z only)
-2. Project name: `fix-stuff` (case-insensitive, partial match)
-3. Full folder name: `abcdef-fix-stuff` (exact match)
-
-Use `resolveProjectIdentifierWithDetails()` from `src/utils/paths.ts`
-
-### Token Usage Tracking
-- After each task, RAF displays a per-task token summary (input/output tokens, cache tokens, cost)
-- After all tasks complete, RAF displays a grand total summary block
-- Token data and costs come from Claude's `--output-format stream-json --verbose` result events
-- Claude CLI provides exact costs via `total_cost_usd` and per-model `costUSD` fields
-- `TokenTracker` class (`src/utils/token-tracker.ts`) accumulates usage and costs across tasks
-- Formatting utilities in `src/utils/terminal-symbols.ts`: `formatTaskTokenSummary()`, `formatTokenTotalSummary()`, `formatNumber()`, `formatCost()`
-- Failed tasks with partial usage data are still tracked in totals
-- Tasks with no usage data (timeout, crash) are silently skipped
-
-### Git Commit Schema
-
-All git commits are made by Claude during task execution. RAF does not create any automated commits.
-
-**Commit format** is configurable via `commitFormat.*` config keys. The default templates use `{placeholder}` syntax:
-- `commitFormat.task`: `"{prefix}[{projectId}:{taskId}] {description}"` — task completion commits
-- `commitFormat.plan`: `"{prefix}[{projectId}] Plan: {projectName}"` — plan commits
-- `commitFormat.amend`: `"{prefix}[{projectId}] Amend: {projectName}"` — amendment commits
-- `commitFormat.prefix`: `"RAF"` — prefix token used in all templates
-
-Default output example:
-```
-RAF[abcdef:01] Add validation for user input fields
-RAF[abcdef:02] Fix null pointer in auth handler
-```
-
-- Claude commits code changes and outcome file together in one commit per task
-- No commits on failure (changes are stashed instead)
-- Handle "not in git repo" gracefully (warning, no crash)
-- Template rendering: `renderCommitMessage()` in `src/utils/config.ts`
-
-### Amendment Mode
-- `raf plan --amend <identifier>` adds tasks to existing projects
-- Existing tasks shown with status: `[COMPLETED]`, `[PENDING]`, `[FAILED]`
-- New tasks numbered sequentially after last task
-- No modification of existing plan files
-
-### Worktree Mode
-- `raf plan --worktree` and `raf do --worktree` run in an isolated git worktree
-- Worktree path: `~/.raf/worktrees/<repo-basename>/<project-id>` (e.g., `~/.raf/worktrees/myapp/abcdef-my-feature`)
-- Branch name matches the project folder name (e.g., `abcdef-my-feature`)
-- `--worktree` flag is required on `plan`; on `do` it is auto-detected when a worktree project is selected from the picker
-- `raf do` without arguments auto-discovers pending worktree projects and merges them into the project picker
-  - Worktree projects are labeled with `[worktree]` suffix in the picker
-  - Selecting a worktree project automatically enables worktree mode (post-action picker, worktree cwd)
-  - Projects are deduplicated: when a folder exists in both local and worktree, the worktree version is shown
-  - Mixed local and worktree projects are sorted chronologically
-- `raf status` automatically discovers and displays worktree projects (no flag needed)
-  - List mode: worktree projects that differ from main repo shown under `Worktrees:` header
-  - Single project mode: shows both main and worktree state when they differ
-  - Identical worktree projects are hidden; worktree-only projects always shown
-- Lifecycle: create worktree -> plan in worktree -> pick post-action -> execute in worktree -> auto-run chosen action
-- **Post-execution picker**: Before task execution, an interactive picker asks what to do after tasks complete:
-  1. **Merge** — merge branch into original branch (fast-forward preferred, merge-commit fallback)
-  2. **Create PR** — push branch and create a GitHub PR (uses `createPullRequest()` from `pull-request.ts`)
-  3. **Leave branch** — do nothing, keep the branch as-is
-- PR option runs preflight checks immediately; falls back to "leave" if `gh` CLI is missing or unauthenticated
-- On task failure, the chosen post-action is skipped with a message
-- Worktree cleanup: all post-actions (merge, PR, leave) clean up the worktree directory (branch preserved in git)
-- On failure, worktree is kept for inspection
-- `raf plan --amend --worktree` auto-recreates the worktree when it was cleaned up:
-  - If the branch exists (common after cleanup): recreates worktree from the existing branch
-  - If no branch exists: creates a fresh worktree and copies project files from the main repo
-- On plan failure with no plan files created, the worktree is cleaned up automatically
-- Core utilities in `src/core/worktree.ts`: `createWorktree()`, `createWorktreeFromBranch()`, `branchExists()`, `validateWorktree()`, `mergeWorktreeBranch()`, `removeWorktree()`, `listWorktreeProjects()`
-- Post-execution picker: `pickPostExecutionAction()` and `PostExecutionAction` type exported from `src/commands/do.ts`
-
-### PR Creation from Worktree
-- `src/core/pull-request.ts` provides `createPullRequest()` to create GitHub PRs from worktree branches
-- Requires `gh` CLI installed and authenticated (`gh auth login`)
-- Auto-detects base branch (from `refs/remotes/origin/HEAD`, falling back to `main`/`master`)
-- PR title derived from project name (kebab-case to human-readable)
-- PR body generated by Claude Haiku summarizing input.md, decisions.md, and outcomes
-- Falls back to simple body if Claude is unavailable
-- Auto-pushes branch to origin if not already pushed
-- Preflight checks: `prPreflight()` validates gh CLI, authentication, GitHub remote
-- Key functions: `createPullRequest()`, `prPreflight()`, `generatePrBody()`, `generatePrTitle()`, `detectBaseBranch()`
-
-
-## PR Review
-
-When reviewing a PR or addressing PR comments, use `gh` CLI to read PR details:
-
-```bash
-# View PR description and metadata
-gh pr view <number>
-
-# View PR diff
-gh pr diff <number>
-
-# View review comments (inline code comments)
-gh api repos/{owner}/{repo}/pulls/<number>/comments
-
-# View PR review summaries
-gh api repos/{owner}/{repo}/pulls/<number>/reviews
-
-# View general PR conversation comments (non-inline)
-gh api repos/{owner}/{repo}/issues/<number>/comments
-
-# List PR files changed
-gh pr diff <number> --name-only
-
-# View PR checks/CI status
-gh pr checks <number>
-```
-
-### Checking Out PR Branches
-
-PR branches are often checked out in git worktrees. Before creating a new checkout, check for existing worktrees:
-
-```bash
-# List existing worktrees
-git worktree list
-
-# Find the branch name from the PR
-gh pr view <number> --json headRefName -q .headRefName
-
-# If gh is rate-limited, list remote branches to find it
-git ls-remote --heads origin
-
-# Check if branch is already in a worktree (look for the path in worktree list output)
-# If it is, work directly in that worktree path (e.g., /Users/eremeev/.raf/worktrees/Paperi/<branch>)
-# If not, checkout normally:
-git fetch origin <branch> && git checkout <branch>
-```
-
-When working in a worktree, use absolute paths to the worktree directory for all file operations and builds.
-
-## Important Reminders
-
-1. **Keep README.md updated** — Update the user-facing README when:
-   - A new CLI command is added (add usage section + Command Reference entry)
-   - Existing command flags or behavior change
-   - Important features are added (e.g., worktrees, config, token tracking)
-   - The Features list needs a new bullet point
-2. **Keep CLAUDE.md updated** — Update internal docs when architectural decisions, config keys, or conventions change
-3. Cover changes with tests - use TDD approach
-4. Use Clean Architecture principles (SOLID)
+- Keep README.md updated when adding/changing CLI commands, flags, or features
+- This app has no users. Make whatever changes you want. This project is super greenfield. It's ok if you change the schema entirely.
+- The role of this file is to describe common mistakes and confusion points that agents might encounter as they work in this project. If you ever encounter something in the project that surprises you, please alert the developer working with you and indicate that this is the case in the AgentMD file to help prevent future agents from having the same issue.

package/RAF/{aaaabn-dependencies-watchdog/plans/02-update-planning-prompts.md → 13-dependencies-watchdog/plans/2-update-planning-prompts.md}

@@ -7,7 +7,7 @@ Modify the planning system prompt so Claude automatically infers and records tas
 When Claude breaks down a project into tasks, it should analyze relationships between tasks and specify dependencies. This enables the execution engine to properly handle task failures by blocking dependent tasks.
 
 ## Dependencies
-001
+1
 
 ## Requirements
 - Claude should automatically infer dependencies from task relationships (not ask user)

package/RAF/{aaaabn-dependencies-watchdog/plans/03-parse-dependencies-update-state.md → 13-dependencies-watchdog/plans/3-parse-dependencies-update-state.md}

@@ -7,7 +7,7 @@ Add dependency parsing to plan file reading and extend state derivation to inclu
 Plan files now contain an optional Dependencies section. The state derivation system needs to parse these dependencies and determine when tasks are blocked (when any dependency has failed).
 
 ## Dependencies
-001
+1
 
 ## Requirements
 - Parse `## Dependencies` section from plan files

package/RAF/{aaaabn-dependencies-watchdog/plans/04-implement-dependency-checking-in-do.md → 13-dependencies-watchdog/plans/4-implement-dependency-checking-in-do.md}

@@ -7,7 +7,7 @@ Update the `raf do` command to detect blocked tasks and automatically create blo
 When executing a project, if a task fails, any tasks that depend on it should be automatically marked as blocked. This prevents wasting time attempting tasks that cannot succeed because their prerequisites failed.
 
 ## Dependencies
-003
+3
 
 ## Requirements
 - Before executing a task, check if it's blocked (has failed/blocked dependencies)

package/RAF/{aaaabn-dependencies-watchdog/plans/05-update-execution-prompts.md → 13-dependencies-watchdog/plans/5-update-execution-prompts.md}

@@ -7,7 +7,7 @@ Modify the execution system prompt to include outcome summaries of completed dep
 When a task depends on other tasks, Claude should know what those tasks accomplished. This helps Claude understand the current state of the codebase and build upon previous work effectively.
 
 ## Dependencies
-003, 004
+3, 4
 
 ## Requirements
 - Execution prompt should include dependency task outcomes when relevant

package/RAF/{aaaabn-dependencies-watchdog/plans/06-add-tests.md → 13-dependencies-watchdog/plans/6-add-tests.md}

@@ -7,7 +7,7 @@ Create comprehensive tests for all dependency-related functionality to ensure re
 The dependency watchdog feature introduces several new behaviors that need test coverage: parsing, state derivation, blocking logic, and prompt generation.
 
 ## Dependencies
-001, 002, 003, 004, 005
+1, 2, 3, 4, 5
 
 ## Requirements
 - Unit tests for dependency parsing

package/RAF/{aaaabr-decision-vault/plans/02-integrate-commit-into-plan.md → 17-decision-vault/plans/2-integrate-commit-into-plan.md}

@@ -7,7 +7,7 @@ Call the git commit utility after planning completes successfully in both regula
 The commit utility from task 001 needs to be integrated into the plan command. The commit should happen automatically after Claude finishes planning and plan files have been created.
 
 ## Dependencies
-001
+1
 
 ## Requirements
 - Commit happens automatically (no flag needed)

package/RAF/{aaaabr-decision-vault/plans/03-add-tests-for-planning-commit.md → 17-decision-vault/plans/3-add-tests-for-planning-commit.md}

@@ -7,7 +7,7 @@ Write unit tests for the git commit utility to ensure correct behavior in variou
 The new git commit functionality needs test coverage to verify it works correctly and handles edge cases properly.
 
 ## Dependencies
-001
+1
 
 ## Requirements
 - Test the `commitPlanningArtifacts` function

package/RAF/{aaaabt-verbose-chronicle/plans/04-commit-verification-before-halt.md → 19-verbose-chronicle/plans/4-commit-verification-before-halt.md}

@@ -9,7 +9,7 @@ The current halt mechanism in `claude-runner.ts` detects completion markers (`<p
 See previous halt work: commit `4d3868c3ef4c607c59829e94462ffd0490d82a98`
 
 ## Dependencies
-003
+3
 
 ## Requirements
 - Record the HEAD commit hash before task execution begins

package/RAF/{aaaacu-worktree-weaver/plans/02-worktree-plan-command.md → 20-worktree-weaver/plans/2-worktree-plan-command.md}

@@ -7,7 +7,7 @@ Add `--worktree` flag to `raf plan` that creates a git worktree and runs the ent
 When a user runs `raf plan --worktree` (with or without a project name), RAF should create a git worktree under `~/.raf/worktrees/<repo-basename>/`, then create the project folder inside the worktree and run the interactive planning session there. The project name is optional — the normal name picker/auto-generation works since the editor uses a temp file and the worktree is only created after the name is known. When combined with `--amend`, RAF should find the existing worktree, switch into it, and run the amendment flow there.
 
 ## Dependencies
-001
+1
 
 ## Requirements
 

package/RAF/{aaaacu-worktree-weaver/plans/03-worktree-do-command.md → 20-worktree-weaver/plans/3-worktree-do-command.md}

@@ -9,7 +9,7 @@ After planning with `--worktree`, the user runs `raf do <project> --worktree` to
 Additionally, `raf do --worktree` (without a project identifier) should auto-discover uncompleted worktree projects by scanning the worktrees directory and filtering to projects that come after the latest completed project in the main tree.
 
 ## Dependencies
-001
+1
 
 ## Requirements
 - Add `--worktree` boolean flag to the do command in Commander.js

package/RAF/{aaaacu-worktree-weaver/plans/04-auto-merge-and-cleanup.md → 20-worktree-weaver/plans/4-auto-merge-and-cleanup.md}

@@ -7,7 +7,7 @@ When `--merge` flag is present on `raf do --worktree`, automatically merge the p
 After worktree execution completes, the user may want to merge the project branch back into the branch from which `raf` was originally called. This is controlled by the `--merge` flag (only valid with `--worktree`). The worktree itself is NOT cleaned up or removed after merge — it stays in place.
 
 ## Dependencies
-003
+3
 
 ## Requirements
 - Add `--merge` boolean flag to the do command in Commander.js

package/RAF/{aaaacu-worktree-weaver/plans/05-worktree-tests.md → 20-worktree-weaver/plans/5-worktree-tests.md}

@@ -7,7 +7,7 @@ Add comprehensive tests covering the worktree utilities and the integration of `
 RAF uses Jest with ts-jest ESM preset. Existing tests are in `__tests__/` directories. The worktree functionality involves git operations that need careful testing with real temporary git repos.
 
 ## Dependencies
-001, 002, 003, 004
+1, 2, 3, 4
 
 ## Requirements
 - Unit tests for all worktree utility functions in `src/core/worktree.ts`:

package/RAF/{aaaacu-worktree-weaver/plans/06-update-documentation.md → 20-worktree-weaver/plans/6-update-documentation.md}

@@ -7,7 +7,7 @@ Document the `--worktree` and `--merge` flags and worktree workflow in both CLAU
 The worktree feature adds a new workflow to RAF. Users need to know how to use it, and developers maintaining RAF need to understand the architecture. Both docs files need updates.
 
 ## Dependencies
-002, 003, 004
+2, 3, 4
 
 ## Requirements
 

package/RAF/{aaaacv-trim-the-fat/plans/03-commit-artifacts-on-amend.md → 21-trim-the-fat/plans/3-commit-artifacts-on-amend.md}

@@ -4,7 +4,7 @@
 Ensure that `raf plan --amend` commits input.md, decisions.md, AND plan files — not just input and decisions — using a distinct "Amend" commit message.
 
 ## Dependencies
-002
+2
 
 ## Context
 Currently `commitPlanningArtifacts()` in `src/core/git.ts` only stages and commits `input.md` and `decisions.md`. For new plans (`raf plan`), this is fine because Claude commits plan files during execution. But for amendments, the new/updated plan files created during the amend session are never committed by RAF. Additionally, the commit message should distinguish amendments from new plans.

package/RAF/{aaaacv-trim-the-fat/plans/04-worktree-aware-exit-messages.md → 21-trim-the-fat/plans/4-worktree-aware-exit-messages.md}

@@ -7,7 +7,7 @@ When planning or amending in worktree mode, the exit message shown to the user s
 Currently the planning prompt (`src/prompts/planning.ts`) shows `raf do <project>` as the exit message, and the amend prompt (`src/prompts/amend.ts`) shows a generic "Press Ctrl-C twice to exit" with no `raf do` hint. Neither is aware of worktree mode. When the user planned with `--worktree`, the follow-up `raf do` command also needs `--worktree`, so the exit message should reflect that.
 
 ## Dependencies
-002
+2
 
 ## Requirements
 - Add a `worktreeMode` (boolean) parameter to both `PlanningPromptParams` and `AmendPromptParams` interfaces

package/RAF/{aaaacw-prune-cycle/plans/02-cleanup-worktree-on-success.md → 22-prune-cycle/plans/2-cleanup-worktree-on-success.md}

@@ -7,7 +7,7 @@ Add automatic worktree cleanup to `raf do --worktree` when all tasks complete su
 Currently worktrees persist indefinitely after execution. Since the git branch contains all committed work, the worktree directory is redundant after successful completion. Cleaning it up reduces clutter in `~/.raf/worktrees/`. The branch is intentionally kept so `raf plan --amend --worktree` can recreate the worktree later.
 
 ## Dependencies
-001
+1
 
 ## Requirements
 - After `executeSingleProject()` returns successfully in worktree mode, remove the worktree using `removeWorktree()`

package/RAF/{aaaacw-prune-cycle/plans/03-amend-recreate-worktree.md → 22-prune-cycle/plans/3-amend-recreate-worktree.md}

@@ -9,7 +9,7 @@ After task 002, worktrees are cleaned up on successful execution but branches ar
 2. Neither branch nor worktree exists → create a fresh worktree with a new branch and copy the project files from the main repo
 
 ## Dependencies
-001, 002
+1, 2
 
 ## Requirements
 - In `runAmendCommand()` when `worktreeMode` is true, after the existing worktree search fails to find the project:

package/RAF/{aaaacx-epoch-shift/plans/02-update-pattern-matching.md → 23-epoch-shift/plans/2-update-pattern-matching.md}

@@ -7,7 +7,7 @@ Update every regex pattern, folder matching function, and identifier resolution
 After task 001 changes the ID generation, the rest of the codebase still has regex patterns like `/^(\d{2,3})-/` and `/^([a-z][0-9a-z]{2})-/` that match the old format. These must all be updated to match the new 6-char alphanumeric format (e.g., `00j3k1-project-name`). This is a clean break, so old patterns should be removed entirely.
 
 ## Dependencies
-001
+1
 
 ## Requirements
 - New project folder pattern: `/^([0-9a-z]{6})-(.+)$/` (6 lowercase alphanumeric chars, hyphen, name)

package/RAF/{aaaacx-epoch-shift/plans/03-update-tests.md → 23-epoch-shift/plans/3-update-tests.md}

@@ -7,7 +7,7 @@ Rewrite all unit tests affected by the project ID format change to test the new
 The test suite in `tests/unit/paths.test.ts` (~741 lines) extensively tests the old sequential numbering and base36 encoding. After tasks 001 and 002 change the production code, these tests will all fail. Other test files (`status-command.test.ts`, `plan-command.test.ts`, `do-command.test.ts`) may also have hardcoded project folder names in old format.
 
 ## Dependencies
-001, 002
+1, 2
 
 ## Requirements
 - Rewrite `tests/unit/paths.test.ts` to cover:

package/RAF/{aaaacx-epoch-shift/plans/04-update-documentation.md → 23-epoch-shift/plans/4-update-documentation.md}

@@ -7,7 +7,7 @@ Update CLAUDE.md and README.md to reflect the new epoch-based project ID format.
 After the code changes, the documentation still references the old sequential numbering system (001-999 numeric, a00-zzz base36). All references need to be updated to describe the new 6-character base36 epoch-based IDs.
 
 ## Dependencies
-001, 002
+1, 2
 
 ## Requirements
 - Update `CLAUDE.md`:

package/RAF/{ahmpro-merge-guardian/plans/003-worktree-pr-creation.md → 24-merge-guardian/plans/3-worktree-pr-creation.md}

@@ -4,7 +4,7 @@
 Add the ability to create a GitHub Pull Request from a worktree branch using the `gh` CLI tool.
 
 ## Dependencies
-002
+2
 
 ## Context
 Currently, after completing tasks in a worktree, the only automated option is merging the branch back. This task adds PR creation as an alternative workflow. The PR body should be a Claude-generated summary combining the project's input.md, key decisions, and task outcomes.

package/RAF/{ahmpro-merge-guardian/plans/004-post-execution-picker.md → 24-merge-guardian/plans/4-post-execution-picker.md}

@@ -4,7 +4,7 @@
 Replace the `--merge` flag with an interactive picker shown before task execution that lets users choose what to do with the worktree branch after tasks complete: merge, create PR, or leave the branch.
 
 ## Dependencies
-001, 003
+1, 3
 
 ## Context
 Currently `raf do --worktree --merge` is the only way to handle the branch after execution. This task replaces that with a better UX: an interactive picker shown before execution starts, so the user declares intent upfront. After all tasks succeed, the chosen action is performed automatically. On failure, the action is skipped.

package/RAF/{ahnbcu-letterjam/plans/02-update-tests.md → 25-letterjam/plans/2-update-tests.md}

@@ -7,7 +7,7 @@ Update all unit and integration tests to reflect the base36-to-base26 encoding c
 After task 01 changes the core encoding functions, all existing tests that reference base36 project IDs will fail. Test fixtures, expected values, and regex patterns need updating. Task ID tests should remain unchanged.
 
 ## Dependencies
-01
+1
 
 ## Requirements
 - All test cases for encode/decode functions updated with base26 expected values

package/RAF/{ahnbcu-letterjam/plans/03-migrate-command.md → 25-letterjam/plans/3-migrate-command.md}

@@ -7,7 +7,7 @@ Add a CLI command that renames existing project folders from old ID formats (3-c
 After switching to base26 encoding, existing projects on disk still have old-format IDs. The migrate command provides a clean one-time transition. It must handle two legacy formats: the original 3-char base36 sequential IDs (e.g., "007-project") and the intermediate 6-char base36 epoch IDs (e.g., "021h44-project").
 
 ## Dependencies
-01
+1
 
 ## Requirements
 - New CLI command: `raf migrate-project-ids-base26`

package/RAF/{ahnbcu-letterjam/plans/04-update-documentation.md → 25-letterjam/plans/4-update-documentation.md}

@@ -7,7 +7,7 @@ Update CLAUDE.md and README.md to document the new base26 project ID encoding sc
 After tasks 01-03, the codebase uses base26 for project IDs, but documentation still references base36. All developer-facing docs need updating.
 
 ## Dependencies
-01, 03
+1, 3
 
 ## Requirements
 - Update CLAUDE.md sections that reference base36 project IDs:

package/RAF/{ahnwrk-worktree-weaver/plans/04-fix-pr-description.md → 26-worktree-weaver/plans/4-fix-pr-description.md}

@@ -22,7 +22,7 @@ PR descriptions currently have multiple issues:
 - Clean up the temp file after PR creation
 
 ## Dependencies
-01
+1
 
 ## Implementation Steps
 1. In `createPullRequest()`, write the generated PR body to a temp file and use `--body-file <path>` flag instead of `--body "<escaped>"`. Clean up the temp file after the `gh` command completes

package/RAF/{ahrren-turbo-finder/plans/02-medium-effort-do.md → 27-turbo-finder/plans/2-medium-effort-do.md}

@@ -4,7 +4,7 @@
 Configure `raf do` to spawn Claude CLI processes with `CLAUDE_CODE_EFFORT_LEVEL=medium` to reduce reasoning overhead during task execution.
 
 ## Dependencies
-01
+1
 
 ## Context
 By default, Claude Opus uses "high" effort level which allocates more thinking tokens. For automated task execution via `raf do`, medium effort provides a good balance of speed, cost, and capability. The `CLAUDE_CODE_EFFORT_LEVEL` environment variable is the supported mechanism for controlling this in the Claude Code CLI.