rafcode 1.0.0

package/RAF/003-multi-project-execution/outcomes/006-multi-project-execution.md

@@ -0,0 +1,42 @@
+# Task 006 - Completed
+
+## Summary
+## Task 006 Complete
+### Summary
+Implemented multi-project execution support for the `raf do` command, allowing users to execute multiple projects in a single command.
+### Changes Made
+1. **Updated `src/utils/paths.ts`**:
+   - Added `resolveProjectIdentifier(rafDir, identifier)` function
+   - Supports numeric identifiers (e.g., "003", "3") - looks up by project number
+   - Supports name identifiers (e.g., "my-project") - looks up by project name
+   - Returns project path or null if not found
+2. **Updated `src/commands/do.ts`**:
+   - Changed argument from `<projectName>` to variadic `<projects...>`
+   - Resolves all project identifiers at start, removing duplicates
+   - Reports resolution errors but continues with valid projects
+   - Executes projects sequentially in specified order
+   - Wraps each project in try-catch for continue-on-failure behavior
+   - Shows project header: `=== Project 1/3: project-name ===`
+   - Displays multi-project summary after all complete:
+   - Exit code 1 if any project fails, 0 if all succeed
+3. **Added `tests/unit/do-multiproject.test.ts`** (12 tests):
+   - Project resolution tests (by number, by name, mixed)
+   - Duplicate detection tests (same project, number+name, different formats)
+   - Edge cases (empty list, all invalid, single project, similar names)
+   - Order preservation tests
+4. **Updated `tests/unit/paths.test.ts`** (11 new tests):
+   - Tests for `resolveProjectIdentifier` function
+### Acceptance Criteria Met
+- ✅ `raf do project1 project2` executes both projects
+- ✅ `raf do 003 004` resolves numbers to project names
+- ✅ Projects execute sequentially
+- ✅ Failure in one project doesn't stop others
+- ✅ Summary shows results for all projects
+- ✅ Tests cover multi-project scenarios (23 new tests, 219 total passing)
+<promise>COMPLETE</promise>
+
+## Details
+- Attempts: 1
+- Elapsed time: 3m 51s
+- Completed at: 2026-01-30T18:20:12.500Z
+

package/RAF/003-multi-project-execution/outcomes/007-verify-timeout.md

@@ -0,0 +1,54 @@
+# Task 007 - Completed
+
+## Summary
+## Task 007 Complete
+### Summary
+Verified that the 60-minute timeout is correctly applied per task (not per project or per retry) and added comprehensive tests to ensure this behavior.
+### Changes Made
+1. **Code Review and Verification**:
+   - Reviewed `src/core/claude-runner.ts` timeout handling
+   - Confirmed that `setTimeout` is set up independently for each call to `run()` or `runVerbose()`
+   - Verified that each retry attempt in `do.ts` gets a fresh timeout (new call to run methods)
+   - Timeout is at lines 143-148 (`run()`) and 235-240 (`runVerbose()`)
+2. **Added Documentation to `src/core/claude-runner.ts`**:
+   - Added detailed JSDoc comments to `ClaudeRunnerOptions.timeout` explaining:
+     - Timeout is per individual call (not shared)
+     - Retries get fresh timeout (elapsed time NOT accumulated)
+     - Default is 60 minutes
+   - Added TIMEOUT BEHAVIOR comments to `run()` and `runVerbose()` methods
+3. **Added Timeout Validation**:
+   - Added validation for edge cases where timeout is 0, negative, or NaN
+   - Falls back to 60 minutes default in these cases
+4. **Created `tests/unit/claude-runner.test.ts`** with 16 tests covering:
+   - **Timeout handling tests** (10 tests):
+     - Timeout set up for each run() call
+     - Timeout set up for each runVerbose() call
+     - Default timeout of 60 minutes when not specified
+     - Timeout cleared when process completes normally
+     - Fresh timeout for consecutive calls
+     - timedOut flag set correctly on timeout
+     - timedOut flag not set when completed before timeout
+     - Default timeout used when timeout is 0
+     - Default timeout used when timeout is negative
+     - Default timeout used when timeout is NaN
+   - **Context overflow detection tests** (2 tests)
+   - **Output collection tests** (2 tests)
+   - **Retry isolation tests** (2 tests):
+     - Fresh timeout for each retry attempt
+     - Elapsed time NOT shared between attempts
+### Acceptance Criteria Met
+- ✅ Code review confirms timeout is per-task execution
+- ✅ Code review confirms retries get fresh timeout
+- ✅ Unit tests verify timeout behavior (16 tests)
+- ✅ Integration tests verify multi-task timeout independence (retry isolation tests)
+- ✅ Documentation updated with timeout behavior (JSDoc comments)
+- ✅ Edge cases handled appropriately (0, negative, NaN → fallback to 60 min)
+### Test Results
+All 235 tests pass (16 new tests for claude-runner.test.ts).
+<promise>COMPLETE</promise>
+
+## Details
+- Attempts: 1
+- Elapsed time: 4m 30s
+- Completed at: 2026-01-30T18:24:42.738Z
+

package/RAF/003-multi-project-execution/outcomes/008-move-decisions-file.md

@@ -0,0 +1,38 @@
+# Task 008 - Completed
+
+## Summary
+## Task 008 Complete
+### Summary
+Simplified project structure by moving the decisions file from `decisions/DECISIONS.md` to `decisions.md` at the project root.
+### Changes Made
+1. **Updated `src/utils/paths.ts`**:
+   - Renamed `getDecisionsDir()` to `getDecisionsPath()`
+   - Returns `path.join(projectPath, 'decisions.md')` instead of `path.join(projectPath, 'decisions')`
+2. **Updated `src/core/project-manager.ts`**:
+   - Removed `decisions/` folder creation
+   - Creates `decisions.md` file directly at project root with initial content `# Project Decisions\n`
+   - Updated import from `getDecisionsDir` to `getDecisionsPath`
+3. **Updated `src/prompts/planning.ts`**:
+   - Changed path reference from `${projectPath}/decisions/DECISIONS.md` to `${projectPath}/decisions.md`
+4. **Updated `README.md`**:
+   - Updated project structure to show `decisions.md` at project root
+   - Removed outdated `.raf/` folder reference (which was removed in earlier tasks)
+5. **Updated tests**:
+   - `tests/unit/project-manager.test.ts`: Changed test to verify `decisions.md` file instead of `decisions` directory
+   - `tests/unit/paths.test.ts`: Added test for `getDecisionsPath()` function
+### Acceptance Criteria Met
+- ✅ New projects create `decisions.md` at project root
+- ✅ `decisions/` folder is not created for new projects
+- ✅ Planning prompt references correct path
+- ✅ Path utilities return correct location
+- ✅ Documentation updated
+- ✅ Tests updated (236 tests pass)
+### Test Results
+All 236 tests pass.
+<promise>COMPLETE</promise>
+
+## Details
+- Attempts: 1
+- Elapsed time: 2m 43s
+- Completed at: 2026-01-30T18:27:26.044Z
+

package/RAF/003-multi-project-execution/outcomes/SUMMARY.md

@@ -0,0 +1,79 @@
+# Project Summary: multi-project-execution
+
+**Status:** executing
+**Created:** 2026-01-30T17:35:55.018Z
+**Updated:** 2026-01-30T18:27:26.044Z
+
+## Statistics
+
+- Completed: 8
+- Failed: 0
+- Skipped: 0
+- Pending: 0
+
+## Tasks
+
+### [x] Task 001
+
+- **Plan:** plans/001-remove-state-json.md
+- **Status:** completed
+- **Attempts:** 1
+- **Started:** 2026-01-30T17:55:55.719Z
+- **Completed:** 2026-01-30T18:03:28.628Z
+
+### [x] Task 002
+
+- **Plan:** plans/002-update-raf-status.md
+- **Status:** completed
+- **Attempts:** 1
+- **Started:** 2026-01-30T18:03:28.656Z
+- **Completed:** 2026-01-30T18:07:19.042Z
+
+### [x] Task 003
+
+- **Plan:** plans/003-simplify-git-logic.md
+- **Status:** completed
+- **Attempts:** 1
+- **Started:** 2026-01-30T18:07:19.064Z
+- **Completed:** 2026-01-30T18:10:57.209Z
+
+### [x] Task 004
+
+- **Plan:** plans/004-auto-commit-planning.md
+- **Status:** completed
+- **Attempts:** 1
+- **Started:** 2026-01-30T18:10:57.232Z
+- **Completed:** 2026-01-30T18:13:18.833Z
+
+### [x] Task 005
+
+- **Plan:** plans/005-rerun-failed-tasks.md
+- **Status:** completed
+- **Attempts:** 1
+- **Started:** 2026-01-30T18:13:18.857Z
+- **Completed:** 2026-01-30T18:16:20.525Z
+
+### [x] Task 006
+
+- **Plan:** plans/006-multi-project-execution.md
+- **Status:** completed
+- **Attempts:** 1
+- **Started:** 2026-01-30T18:16:20.547Z
+- **Completed:** 2026-01-30T18:20:12.503Z
+
+### [x] Task 007
+
+- **Plan:** plans/007-verify-timeout.md
+- **Status:** completed
+- **Attempts:** 1
+- **Started:** 2026-01-30T18:20:12.530Z
+- **Completed:** 2026-01-30T18:24:42.738Z
+
+### [x] Task 008
+
+- **Plan:** plans/008-move-decisions-file.md
+- **Status:** completed
+- **Attempts:** 1
+- **Started:** 2026-01-30T18:24:42.761Z
+- **Completed:** 2026-01-30T18:27:26.044Z
+

package/RAF/003-multi-project-execution/plans/001-remove-state-json.md

@@ -0,0 +1,71 @@
+# Task: Remove .raf Folder and State-Based Logic
+
+## Objective
+Remove the `.raf` folder and `state.json` entirely, deriving all state from the RAF project folder structure and outcome files.
+
+## Context
+Currently, RAF maintains state in `.raf/state.json` which tracks project status, task states, and execution metadata. This creates a dependency on a technical artifact that can become out of sync with actual project state. By deriving state from the folder structure and outcome files, we make the system more resilient and transparent.
+
+## Requirements
+- Remove all usage of `.raf/state.json`
+- Remove the `.raf` folder entirely (including logs directory - logs will be console-only)
+- State must be derived from:
+  - Project existence: `RAF/NNN-project-name/` folder exists
+  - Task status: determined by outcome file existence and content
+- Outcome file format must include status marker: `## Status: SUCCESS` or `## Status: FAILED` at the top
+- No execution logs will be persisted - console output only
+
+## Implementation Steps
+
+1. **Update outcome file format** (`src/core/outcomes.ts` or similar)
+   - Modify outcome generation to include `## Status: SUCCESS` or `## Status: FAILED` as first line
+   - Create a parser function to read outcome files and extract status
+
+2. **Create state derivation module** (`src/core/state-derivation.ts`)
+   - Function `deriveProjectState(projectPath)` that:
+     - Scans `plans/` directory for plan files
+     - Scans `outcomes/` directory for outcome files
+     - Matches plan files to outcome files by task ID (NNN prefix)
+     - Parses outcome files for SUCCESS/FAILED status
+     - Returns derived state object with task statuses
+
+3. **Remove StateManager class** (`src/core/state-manager.ts`)
+   - Delete the entire StateManager class
+   - Remove all imports and usages throughout codebase
+
+4. **Update `raf do` command** (`src/commands/do.ts`)
+   - Replace StateManager usage with state derivation
+   - Get pending/failed tasks from derived state
+   - Remove state saving logic
+
+5. **Update `raf plan` command** (`src/commands/plan.ts`)
+   - Remove StateManager initialization
+   - Remove state saving after planning
+
+6. **Update `raf status` command** (`src/commands/status.ts`)
+   - Will be updated in subsequent task (002)
+
+7. **Remove .raf path utilities** (`src/utils/paths.ts`)
+   - Remove functions related to `.raf` directory
+   - Remove state file path constants
+
+8. **Clean up imports and dependencies**
+   - Remove state-manager from all imports
+   - Update any type definitions that reference state types
+
+9. **Add migration note**
+   - Document that `.raf` folder can be safely deleted from existing projects
+
+## Acceptance Criteria
+- [ ] `.raf` folder is not created or used by any command
+- [ ] `state.json` is not created or read
+- [ ] Project state can be derived from `RAF/project/` folder structure
+- [ ] Outcome files contain `## Status: SUCCESS` or `## Status: FAILED` marker
+- [ ] All existing tests updated or removed as appropriate
+- [ ] New tests for state derivation logic
+- [ ] Code compiles without errors
+
+## Notes
+- This is a breaking change - existing `.raf` folders will be ignored
+- The `raf status` command will be updated in task 002 to work with derived state
+- Consider backward compatibility: old outcome files without status markers should be treated as incomplete

package/RAF/003-multi-project-execution/plans/002-update-raf-status.md

@@ -0,0 +1,65 @@
+# Task: Update raf status Command for Stateless Operation
+
+## Objective
+Update the `raf status` command to work without `state.json`, deriving all status information from the RAF folder structure and outcome files.
+
+## Context
+With the removal of `state.json` in task 001, the `raf status` command needs to scan the `RAF/` directory and derive project and task statuses from the folder structure and outcome file contents.
+
+## Requirements
+- Scan `RAF/` folder to discover all projects
+- Derive project status from task outcomes:
+  - `planning`: has `input.md` but no `plans/` folder or empty plans
+  - `ready`: has plan files but no outcome files
+  - `executing`: has some outcome files but not all (or has failed outcomes without SUCCESS)
+  - `completed`: all plan files have corresponding SUCCESS outcomes
+  - `failed`: has FAILED outcome files
+- Derive task status from outcome files:
+  - `pending`: no outcome file exists
+  - `completed`: outcome file exists with `## Status: SUCCESS`
+  - `failed`: outcome file exists with `## Status: FAILED`
+- Display same user-friendly output as before (badges, stats)
+- Support `--json` flag for machine-readable output
+
+## Implementation Steps
+
+1. **Create project scanner** (in `src/core/state-derivation.ts` or new file)
+   - Function `discoverProjects(rafPath)` that:
+     - Lists all directories in `RAF/` matching pattern `NNN-project-name`
+     - Returns array of project info objects
+
+2. **Update `deriveProjectState`** function
+   - Accept project path
+   - Scan plans directory
+   - Scan outcomes directory
+   - Match and determine task statuses
+   - Calculate overall project status
+
+3. **Update status command** (`src/commands/status.ts`)
+   - Remove StateManager dependency
+   - Use `discoverProjects()` for listing all projects
+   - Use `deriveProjectState()` for individual project details
+   - Maintain existing output format and badges
+
+4. **Update stats calculation**
+   - Calculate completed/failed/pending/skipped counts from derived state
+   - No changes to display logic needed
+
+5. **Handle edge cases**
+   - Project folder exists but is empty
+   - Plans folder exists but is empty
+   - Outcome file exists but has no status marker (treat as incomplete)
+   - Malformed outcome files
+
+## Acceptance Criteria
+- [ ] `raf status` lists all projects from RAF folder
+- [ ] `raf status <project>` shows detailed task status derived from files
+- [ ] Status badges display correctly: `[ ]` pending, `[x]` completed, `[!]` failed
+- [ ] `--json` flag outputs valid JSON with derived state
+- [ ] No dependency on StateManager or state.json
+- [ ] Tests cover status derivation scenarios
+
+## Notes
+- Depends on task 001 (state derivation logic)
+- Skipped tasks (`[-]` badge) may not be supported without state - consider removing or deriving differently
+- Performance: scanning files should be fast enough for typical project sizes (< 20 tasks)

package/RAF/003-multi-project-execution/plans/003-simplify-git-logic.md

@@ -0,0 +1,74 @@
+# Task: Simplify Git Logic - Claude Commits Changes
+
+## Objective
+Simplify git operations by instructing Claude to commit its own changes during task execution, removing the smart commit logic from RAF.
+
+## Context
+Currently, RAF captures a "baseline" of changed files before each task, then commits only the delta after task completion. This adds complexity and can miss files or include unrelated changes. By instructing Claude to commit after making changes, we simplify the codebase and give Claude more control over what gets committed.
+
+## Requirements
+- Claude must be instructed to commit changes after completing task work
+- Commit message format: `[project-name] task description` (no task numbers)
+- Outcome file should be included in Claude's commit
+- Remove smart commit logic (baseline tracking, delta filtering)
+- Remove `commitTaskChanges`, `setTaskBaseline`, `getTaskBaseline` functions
+- RAF should NOT commit after task completion (Claude does it)
+- Keep stash functionality for failure cases
+
+## Implementation Steps
+
+1. **Update execution prompt** (`src/prompts/execution-prompt.ts` or similar)
+   - Add explicit instructions for Claude to commit after making changes
+   - Specify commit message format: `[project-name] task description`
+   - Instruct to include outcome file in the commit
+   - Example instruction:
+     ```
+     After completing your work, commit all changes with:
+     git add -A && git commit -m "[project-name] brief description of changes"
+
+     Include the outcome file in your commit.
+     ```
+
+2. **Remove smart commit logic** (`src/core/git.ts`)
+   - Remove `commitTaskChanges` function
+   - Remove baseline-related functions:
+     - `getTaskChangedFiles`
+     - Any baseline tracking utilities
+   - Keep `stashChanges` for failure handling
+   - Keep `isGitRepo` for validation
+
+3. **Update `raf do` command** (`src/commands/do.ts`)
+   - Remove baseline capture before task execution
+   - Remove commit call after task success
+   - Keep stash call on task failure
+   - Remove commit hash tracking (no longer relevant)
+
+4. **Update outcome generation**
+   - Ensure outcome file is written BEFORE Claude is asked to commit
+   - Or instruct Claude to write the outcome as part of its work
+
+5. **Simplify git.ts exports**
+   - Export only necessary functions:
+     - `isGitRepo`
+     - `stashChanges`
+     - `getChangedFiles` (for status display if needed)
+
+6. **Update tests**
+   - Remove tests for smart commit logic
+   - Add tests for new prompt instructions
+   - Update integration tests
+
+## Acceptance Criteria
+- [ ] Execution prompt includes commit instructions for Claude
+- [ ] Commit message format is `[project-name] task description`
+- [ ] Smart commit logic (baseline tracking) is removed
+- [ ] RAF does not commit after task completion
+- [ ] Outcome file is committed by Claude
+- [ ] Stash functionality still works on task failure
+- [ ] All tests pass
+
+## Notes
+- This changes the responsibility model: Claude commits, RAF orchestrates
+- If Claude fails to commit, changes remain uncommitted (user can handle manually)
+- Consider adding a fallback commit in RAF if Claude didn't commit - but user chose not to do this
+- Outcome file path needs to be passed to Claude so it knows what to include

package/RAF/003-multi-project-execution/plans/004-auto-commit-planning.md

@@ -0,0 +1,57 @@
+# Task: Auto-Commit After Planning
+
+## Objective
+Automatically commit the RAF project folder (input, decisions, plans) after the planning step completes successfully.
+
+## Context
+When a project is planned, the `RAF/NNN-project-name/` folder is created with `input.md`, `decisions/DECISIONS.md`, and plan files in `plans/`. These should be committed to preserve the planning work and make it easy to share or review the project plan.
+
+## Requirements
+- After `raf plan` completes successfully, commit the project folder
+- Commit message format: `RAF(project-name): Plan complete`
+- Only commit files within the project folder: `RAF/NNN-project-name/**`
+- Do not commit if planning was cancelled or failed
+- Do not commit unrelated changes in the repository
+
+## Implementation Steps
+
+1. **Add commit function for planning** (`src/core/git.ts`)
+   - Create `commitProjectFolder(projectPath, projectName)` function
+   - Stage only files within the project folder
+   - Use commit message: `RAF(project-name): Plan complete`
+
+2. **Update `raf plan` command** (`src/commands/plan.ts`)
+   - After successful Claude interactive session completion
+   - After plan files are created
+   - Call `commitProjectFolder` with project path and name
+   - Handle commit failure gracefully (log warning, don't fail the command)
+
+3. **Implement selective staging**
+   - Use `git add RAF/NNN-project-name/` to stage only project files
+   - Verify files are staged before committing
+   - Skip commit if no files to commit (edge case)
+
+4. **Add error handling**
+   - Catch git errors and log them
+   - Don't fail the plan command if commit fails
+   - Inform user that commit failed but planning succeeded
+
+5. **Update tests**
+   - Test that commit happens after successful planning
+   - Test commit message format
+   - Test that only project files are committed
+   - Test graceful handling of commit failures
+
+## Acceptance Criteria
+- [ ] After successful `raf plan`, project folder is committed
+- [ ] Commit message is `RAF(project-name): Plan complete`
+- [ ] Only files in `RAF/NNN-project-name/` are committed
+- [ ] Unrelated changes in repo are not committed
+- [ ] Planning doesn't fail if commit fails
+- [ ] User is informed of commit success/failure
+- [ ] Tests cover commit scenarios
+
+## Notes
+- This runs after the interactive Claude session, not during
+- If user manually committed during planning, this will be a no-op (nothing to commit)
+- Consider: what if there are staged changes before planning? Should we stash first? Decision: No, just commit project folder specifically

package/RAF/003-multi-project-execution/plans/005-rerun-failed-tasks.md

@@ -0,0 +1,69 @@
+# Task: Support Re-Running Failed/Pending Tasks
+
+## Objective
+Allow users to re-run `raf do project-name` on a project that has already been executed, automatically resuming from failed or pending tasks.
+
+## Context
+Currently, running `raf do` on a project that has been executed just shows statistics. Users need the ability to retry failed tasks (e.g., after API unavailability, token limits reached) without manually tracking state. The system should derive what needs to be done from the folder structure.
+
+## Requirements
+- `raf do project-name` on an existing project should:
+  - Skip tasks with `## Status: SUCCESS` in their outcome files
+  - Re-run tasks with `## Status: FAILED` in their outcome files
+  - Run tasks with no outcome file (pending)
+- Add `--force` flag to re-run even completed projects (all tasks)
+- If all tasks are complete and no `--force` flag, show message and exit
+- Derive task status from outcome files (implemented in task 001)
+
+## Implementation Steps
+
+1. **Update task selection logic** (`src/commands/do.ts`)
+   - Use derived state to get task statuses
+   - Filter for tasks that are NOT completed (no SUCCESS outcome)
+   - Include failed tasks (FAILED outcome) for retry
+   - Include pending tasks (no outcome file)
+
+2. **Add `--force` flag**
+   - Add `-f, --force` option to `raf do` command
+   - When `--force` is set, run all tasks regardless of status
+   - Consider: should `--force` delete existing outcome files first? Decision: No, let Claude overwrite
+
+3. **Handle already-complete projects**
+   - Check if all tasks have SUCCESS outcomes
+   - If yes and no `--force`, display message: "All tasks completed. Use --force to re-run."
+   - Exit gracefully (exit code 0)
+
+4. **Update execution loop**
+   - Before running a task, check if it should be skipped (SUCCESS outcome exists)
+   - Log which tasks are being skipped
+   - Log which tasks are being retried (had FAILED outcome)
+
+5. **Handle outcome file updates**
+   - When retrying a failed task, the new outcome will overwrite the old one
+   - Ensure outcome file path is consistent
+
+6. **Update console output**
+   - Show clear indication of:
+     - "Skipping task X (already completed)"
+     - "Retrying task X (previously failed)"
+     - "Running task X"
+
+7. **Update tests**
+   - Test resume from failed task
+   - Test skip completed tasks
+   - Test `--force` flag behavior
+   - Test "all complete" message
+
+## Acceptance Criteria
+- [ ] `raf do project-name` skips tasks with SUCCESS outcome
+- [ ] `raf do project-name` retries tasks with FAILED outcome
+- [ ] `raf do project-name` runs tasks without outcome files
+- [ ] `--force` flag runs all tasks regardless of status
+- [ ] Clear console output indicates skip/retry/run status
+- [ ] All tests pass
+
+## Notes
+- Depends on task 001 (state derivation)
+- Task order is determined by plan file numbering (001, 002, etc.)
+- Consider: should we clear FAILED outcome before retry? Decision: No, let new outcome overwrite
+- Edge case: outcome file exists but is empty or malformed - treat as pending

package/RAF/003-multi-project-execution/plans/006-multi-project-execution.md

@@ -0,0 +1,81 @@
+# Task: Multi-Project Execution Support
+
+## Objective
+Allow `raf do` command to accept multiple project names or numbers, executing them sequentially.
+
+## Context
+Users may want to run multiple projects in sequence without manually invoking `raf do` for each one. This is useful for batch processing or running related projects together.
+
+## Requirements
+- Support syntax: `raf do project1 project2 project3`
+- Support number syntax: `raf do 003 004 005`
+- Support mixed syntax: `raf do 003 my-project 005`
+- No range support (e.g., `003-005` is NOT supported)
+- Projects run sequentially (one after another)
+- If a project fails, continue with remaining projects
+- Report summary at end showing status of all projects
+- Each project uses its own timeout (per-task timeout preserved)
+
+## Implementation Steps
+
+1. **Update command argument parsing** (`src/commands/do.ts`)
+   - Change from single `<projectName>` to variadic `<projects...>`
+   - Update Commander.js argument: `.argument('<projects...>', 'Project name(s) or number(s) to execute')`
+
+2. **Create project resolver function**
+   - Function `resolveProjectIdentifier(identifier)` that:
+     - If identifier is numeric (e.g., "003"), find matching project folder
+     - If identifier is a name, use as-is
+     - Return full project name or throw if not found
+
+3. **Update main execution flow**
+   - Loop through all project identifiers
+   - Resolve each to full project name
+   - Execute each project using existing single-project logic
+   - Collect results for each project
+
+4. **Implement continue-on-failure**
+   - Wrap single project execution in try-catch
+   - Log failure and continue to next project
+   - Track which projects succeeded/failed
+
+5. **Create multi-project summary**
+   - After all projects complete, show summary:
+     ```
+     === Multi-Project Summary ===
+     ✓ 003-project-a: Completed (5/5 tasks)
+     ✗ 004-project-b: Failed (3/5 tasks)
+     ✓ 005-project-c: Completed (3/3 tasks)
+
+     Total: 2 completed, 1 failed
+     ```
+
+6. **Handle edge cases**
+   - Project not found by number
+   - Duplicate projects in list (skip duplicates)
+   - Empty project list (show usage help)
+
+7. **Update help text and documentation**
+   - Update `--help` output to show multi-project usage
+   - Add examples: `raf do 003 004` and `raf do project-a project-b`
+
+8. **Update tests**
+   - Test multiple projects execution
+   - Test mixed name/number input
+   - Test continue-on-failure
+   - Test summary output
+   - Test project resolution
+
+## Acceptance Criteria
+- [ ] `raf do project1 project2` executes both projects
+- [ ] `raf do 003 004` resolves numbers to project names
+- [ ] Projects execute sequentially
+- [ ] Failure in one project doesn't stop others
+- [ ] Summary shows results for all projects
+- [ ] Tests cover multi-project scenarios
+
+## Notes
+- Depends on task 005 (single project re-run support)
+- Options like `--timeout` and `--force` apply to all projects
+- Consider: should we support project-specific options? Decision: No, keep simple
+- Exit code: 0 if all succeed, 1 if any fail