rafcode 1.0.0

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

@@ -0,0 +1,63 @@
+# Task: Verify Per-Task Timeout Implementation
+
+## Objective
+Verify that the 60-minute timeout is correctly applied per task (not per project or per retry) and add tests to ensure this behavior.
+
+## Context
+The user wants to ensure that the timeout (default 60 minutes) is applied to each individual task execution, not shared across tasks or accumulated across retries. Based on code review, the current implementation appears correct, but verification and tests are needed.
+
+## Requirements
+- Verify timeout is passed to each Claude execution independently
+- Verify timeout resets for each task
+- Verify timeout resets for each retry attempt
+- Document the timeout behavior clearly
+- Add tests to prevent regression
+
+## Implementation Steps
+
+1. **Code review and verification**
+   - Review `src/core/claude-runner.ts` timeout handling
+   - Trace timeout parameter flow from CLI through to process execution
+   - Confirm `setTimeout` is set up per execution
+   - Document findings
+
+2. **Verify retry behavior**
+   - Check if retries use the same timeout or share elapsed time
+   - Current expectation: each retry gets fresh timeout
+   - Document actual behavior
+
+3. **Add unit tests for timeout** (`src/core/claude-runner.test.ts`)
+   - Test that timeout is passed correctly to spawn
+   - Test that timeout handler kills process
+   - Test that timedOut flag is set correctly
+
+4. **Add integration tests**
+   - Test that multiple tasks each get their own timeout
+   - Test that retry attempts get fresh timeout
+   - Use mock/stub Claude process for testing
+
+5. **Update documentation**
+   - Add comment in code explaining timeout is per-task
+   - Update README or help text if needed
+   - Add note about retry timeout behavior
+
+6. **Consider edge cases**
+   - What happens if timeout is 0? (should be rejected or infinite?)
+   - What happens with very large timeout values?
+   - Ensure timeout parameter validation
+
+## Acceptance Criteria
+- [ ] Code review confirms timeout is per-task execution
+- [ ] Code review confirms retries get fresh timeout
+- [ ] Unit tests verify timeout behavior
+- [ ] Integration tests verify multi-task timeout independence
+- [ ] Documentation updated with timeout behavior
+- [ ] Edge cases handled appropriately
+
+## Notes
+- This is primarily a verification and testing task, not implementation
+- If issues are found, they should be fixed as part of this task
+- Current implementation in claude-runner.ts appears correct based on exploration:
+  - `setTimeout(() => proc.kill('SIGTERM'), timeoutMs)` is set per call
+  - Each task execution is a separate call to `run()` or `runVerbose()`
+- Timeout includes all time Claude is running, including any context it builds

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

@@ -0,0 +1,78 @@
+# Task: Move decisions/DECISIONS.md to decisions.md
+
+## Objective
+Simplify project structure by moving the decisions file from `decisions/DECISIONS.md` to `decisions.md` at the project root.
+
+## Context
+Currently, decisions are stored in a nested folder structure (`decisions/DECISIONS.md`). This adds unnecessary complexity when there's only one decisions file per project. Moving it to `decisions.md` at the project root simplifies the structure and makes it more discoverable.
+
+## Requirements
+- Move `decisions/DECISIONS.md` to `decisions.md` at project root
+- Update `raf plan` command to create `decisions.md` instead of `decisions/DECISIONS.md`
+- Update planning prompt to reference new location
+- Remove empty `decisions/` folder creation
+- Handle migration of existing projects (optional - just document)
+
+## Implementation Steps
+
+1. **Update project folder creation** (`src/commands/plan.ts` or `src/utils/paths.ts`)
+   - Remove `decisions/` folder creation
+   - Create `decisions.md` file directly in project root
+
+2. **Update planning prompt** (`src/prompts/planning-prompt.ts` or similar)
+   - Change path reference from `decisions/DECISIONS.md` to `decisions.md`
+   - Update any instructions that mention the decisions folder
+
+3. **Update path utilities** (`src/utils/paths.ts`)
+   - Update `getDecisionsPath()` or similar function
+   - Return `RAF/NNN-project-name/decisions.md` instead of `RAF/NNN-project-name/decisions/DECISIONS.md`
+
+4. **Update state derivation** (if decisions are used in state)
+   - Check if decisions file is referenced in state derivation
+   - Update paths accordingly
+
+5. **Update documentation**
+   - Update folder structure documentation in CLAUDE.md
+   - Update any references in README
+
+6. **Clean up existing projects (optional)**
+   - Document that existing `decisions/DECISIONS.md` files can be manually moved
+   - Or add migration logic to move file if old location exists
+
+## New Project Structure
+
+Before:
+```
+RAF/001-example-project/
+├── input.md
+├── decisions/
+│   └── DECISIONS.md
+├── plans/
+│   └── ...
+└── outcomes/
+    └── ...
+```
+
+After:
+```
+RAF/001-example-project/
+├── input.md
+├── decisions.md
+├── plans/
+│   └── ...
+└── outcomes/
+    └── ...
+```
+
+## Acceptance Criteria
+- [ ] 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
+
+## Notes
+- This is a minor structural change but improves discoverability
+- Existing projects will continue to work (decisions file location doesn't affect execution)
+- Consider: should we support both locations for backward compatibility? Decision: No, keep it simple

package/RAF/004-task-naming-optimization/decisions.md

@@ -0,0 +1,22 @@
+# Project Decisions
+
+## What exactly should be removed - the SUMMARY.md file generation, the console summary output, or both?
+Remove SUMMARY.md file only - Keep console output, stop generating SUMMARY.md in outcomes/
+
+## For 'support passing full name to the project' - what change do you want?
+Leave optional user-provided name working as is. If name not provided, use Haiku with modified prompt (see task 4 about improving Haiku prompt to use most important task).
+
+## For the numbering prefix problem (what happens after 999?), which approach?
+Alphanumeric base36 (a00-zzz) - Uses 0-9 and a-z, gives ~46,000 combinations in 3 chars.
+
+## Should we migrate existing projects to new format?
+Start fresh, no migration - New projects use base36, old projects stay as-is but mixed formats allowed.
+
+## When should base36 kick in?
+After 999 - Keep familiar 001-999, then a00, a01... for project numbers 1000+.
+
+## How should Haiku identify the 'most important task' from project description?
+Let Haiku decide - Tell Haiku to analyze and pick the most impactful/core task.
+
+## Any specific guidelines for how Haiku should name projects?
+Add 'focus on core feature' - Tell Haiku to name based on the main functionality being built.

package/RAF/004-task-naming-optimization/input.md

@@ -0,0 +1,6 @@
+- [ ] remove summary
+- [ ] support passing full name to the project
+- [ ] investigate that do to with only there numbers prefix (000, 001, NNN), i don't wan't to make 4, since it's ugly, but also adding timestamps or is ugly, what could be good solution so it's user readable and short?
+- [ ] when comming up with project name take most important task for the base name (add this
+  instruction to prompt to claude code haiku)
+

package/RAF/004-task-naming-optimization/outcomes/001-remove-summary-file.md

@@ -0,0 +1,17 @@
+## Status: SUCCESS
+
+# Task 001 - Completed
+
+## Summary
+Let me verify all acceptance criteria are met:
+1. ✅ **SUMMARY.md is no longer created in `outcomes/` directory after task execution** - Removed `saveSummary` method and its call in `do.ts`
+2. ✅ **Console summary output still displays after single project execution** - Lines 437-443 in `do.ts` still print:
+3. ✅ **Console summary output still displays for multi-project execution** - `printMultiProjectSummary()` function at line 453 is unchanged and still displays multi-project results
+4. ✅ **All existing tests pass (or are updated appropriately)** - All 235 tests pass (removed the `saveSummary` test that was no longer applicable)
+5. ✅ **No orphaned code referencing SUMMARY.md generation** - Verified with grep that no references remain in `src/`
+<promise>COMPLETE</promise>
+
+## Details
+- Attempts: 1
+- Elapsed time: 2m 49s
+- Completed at: 2026-01-30T18:55:54.601Z

package/RAF/004-task-naming-optimization/outcomes/002-base36-project-numbering.md

@@ -0,0 +1,32 @@
+## Status: SUCCESS
+
+# Task 002 - Completed
+
+## Summary
+All acceptance criteria are verified. Let me summarize what was implemented:
+## Summary
+Successfully implemented base36 project numbering for RAF. The implementation:
+**New Functions Added to `src/utils/paths.ts`:**
+- `encodeBase36(num)`: Converts numbers >= 1000 to 3-character base36 strings (a00, a01, ..., zzz)
+- `decodeBase36(str)`: Converts base36 strings back to numbers
+- `isBase36Prefix(str)`: Validates if a string is a valid base36 prefix
+- `parseProjectPrefix(prefix)`: Parses either numeric or base36 prefix to a number
+**Updated Functions:**
+- `formatProjectNumber()`: Uses numeric format (001-999) or base36 (a00+)
+- `extractProjectNumber()`: Handles both numeric and base36 prefixes
+- `extractProjectName()`: Handles both formats
+- `getProjectDir()`: Matches both format patterns
+- `getNextProjectNumber()`: Scans for both formats to find max
+- `listProjects()`: Lists both formats with correct numeric values
+- `resolveProjectIdentifier()`: Resolves by numeric, base36 prefix, or name
+- `validateProjectExists()` in validation.ts: Matches both formats
+**Tests Added:**
+- 40 new tests covering all base36 functionality
+- Updated 5 existing tests to reflect new behavior (where 3-letter words like "not" are now valid base36)
+All 275 tests pass.
+<promise>COMPLETE</promise>
+
+## Details
+- Attempts: 1
+- Elapsed time: 6m 19s
+- Completed at: 2026-01-30T19:02:14.551Z

package/RAF/004-task-naming-optimization/outcomes/003-improve-haiku-prompt.md

@@ -0,0 +1,20 @@
+## Status: SUCCESS
+
+# Task 003 - Completed
+
+## Summary
+## Summary
+Successfully improved the Haiku prompt for project naming in `src/utils/name-generator.ts`. The updated prompt now:
+1. **Instructs Haiku to identify the most important task** - "Analyze this project description" and "Focus on the most important or core feature being built"
+2. **Focuses on core feature** - Explicit instruction to focus on what's being built
+3. **Guides toward action-oriented naming** - "The name should be action-oriented, describing what the project does" with concrete examples like 'add-user-auth', 'fix-payment-flow', 'refactor-api-routes'
+4. **Maintains existing constraints** - Still requests kebab-case, 2-4 words, and "Output ONLY the name"
+5. **Preserves fallback behavior** - The `generateFallbackName()` function remains unchanged
+6. **CLI-provided names still bypass Haiku** - Existing behavior in command layer is unchanged
+All 275 tests pass.
+<promise>COMPLETE</promise>
+
+## Details
+- Attempts: 1
+- Elapsed time: 1m 15s
+- Completed at: 2026-01-30T19:03:30.210Z

package/RAF/004-task-naming-optimization/outcomes/SUMMARY.md

@@ -0,0 +1,28 @@
+# Project Summary: task-naming-optimization
+
+**Generated:** 2026-01-30T19:03:30.212Z
+
+## Statistics
+
+- Total: 3
+- Completed: 3
+- Failed: 0
+- Pending: 0
+
+## Tasks
+
+### [x] Task 001
+
+- **Plan:** plans/001-remove-summary-file.md
+- **Status:** completed
+
+### [x] Task 002
+
+- **Plan:** plans/002-base36-project-numbering.md
+- **Status:** completed
+
+### [x] Task 003
+
+- **Plan:** plans/003-improve-haiku-prompt.md
+- **Status:** completed
+

package/RAF/004-task-naming-optimization/plans/001-remove-summary-file.md

@@ -0,0 +1,34 @@
+# Task: Remove SUMMARY.md File Generation
+
+## Objective
+Remove the SUMMARY.md file generation from the outcomes folder while keeping console summary output intact.
+
+## Context
+The project currently generates a SUMMARY.md file in the `outcomes/` directory after task execution completes. The user wants to remove this file generation but keep the console output that shows project execution results.
+
+## Requirements
+- Remove SUMMARY.md file generation from `ProjectManager.saveSummary()`
+- Keep console summary output in `do.ts` (single project and multi-project summaries)
+- Remove the `saveSummary` method or convert it to only handle console output
+- Update any tests that expect SUMMARY.md to be created
+- Do NOT remove the `printMultiProjectSummary()` console functionality
+
+## Implementation Steps
+1. Read `src/core/project-manager.ts` and locate the `saveSummary` method
+2. Remove or disable the file writing logic (the `fs.writeFileSync` call for SUMMARY.md)
+3. Read `src/commands/do.ts` and verify console summary output is preserved
+4. Update any references that call `saveSummary` if needed
+5. Run existing tests and update any that fail due to missing SUMMARY.md
+6. Verify the console output still works correctly
+
+## Acceptance Criteria
+- [ ] SUMMARY.md is no longer created in `outcomes/` directory after task execution
+- [ ] Console summary output still displays after single project execution
+- [ ] Console summary output still displays for multi-project execution
+- [ ] All existing tests pass (or are updated appropriately)
+- [ ] No orphaned code referencing SUMMARY.md generation
+
+## Notes
+- The `saveSummary` method is called in `executeSingleProject()` in do.ts
+- The console output comes from separate code paths - make sure to preserve those
+- Consider whether to remove the method entirely or just the file writing portion

package/RAF/004-task-naming-optimization/plans/002-base36-project-numbering.md

@@ -0,0 +1,56 @@
+# Task: Implement Base36 Project Numbering
+
+## Objective
+Implement alphanumeric base36 numbering for project prefixes that kicks in after project 999, providing ~46,000 combinations in 3 characters.
+
+## Context
+Current project numbering uses 3-digit zero-padded numbers (001-999). The user wants a scalable solution that remains user-readable and short. Base36 encoding (0-9, a-z) allows for 36^3 = 46,656 combinations in 3 characters.
+
+**Numbering scheme:**
+- Projects 1-999: Use current format (001, 002, ..., 999)
+- Projects 1000+: Use base36 format (a00, a01, ..., a0z, a10, ..., zzz)
+
+## Requirements
+- Keep backwards compatibility: existing projects (001-999) continue to work
+- No migration needed: old projects stay as-is
+- New projects after 999 use base36 (a00 = 1000, a01 = 1001, etc.)
+- Support reading both formats when resolving project identifiers
+- Base36 uses lowercase letters only (a-z, not A-Z)
+- Maintain 3-character prefix for consistency
+
+## Implementation Steps
+1. Read `src/utils/paths.ts` - understand current `formatProjectNumber()` and `getNextProjectNumber()` functions
+2. Create helper functions for base36 encoding/decoding:
+   - `encodeBase36(num: number): string` - converts 1000+ to 'a00', 'a01', etc.
+   - `decodeBase36(str: string): number` - converts 'a00' back to 1000
+3. Update `formatProjectNumber(num)`:
+   - If num <= 999: return zero-padded 3-digit string (current behavior)
+   - If num >= 1000: return base36 encoded string
+4. Update `extractProjectNumber(projectPath)`:
+   - Support parsing both numeric (001-999) and base36 (a00-zzz) prefixes
+5. Update `getNextProjectNumber(rafDir)`:
+   - Scan for both numeric and base36 prefixed folders
+   - Return correct next number in sequence
+6. Update `resolveProjectIdentifier()` to handle both formats
+7. Add comprehensive tests for edge cases:
+   - Transition from 999 to a00 (1000)
+   - Mixed folder formats
+   - Base36 parsing and formatting
+8. Update validation in `src/utils/validation.ts` if needed
+
+## Acceptance Criteria
+- [ ] Projects 1-999 use format: 001, 002, ..., 999
+- [ ] Project 1000 uses format: a00
+- [ ] Project 1001 uses format: a01
+- [ ] `raf do 003` still works for existing projects
+- [ ] `raf do a00` works for base36 projects
+- [ ] `raf plan` correctly determines next project number across mixed formats
+- [ ] All tests pass including new base36 tests
+
+## Notes
+- Base36 math: a00 = 10*36^2 + 0*36 + 0 = 12960 in pure base36, but we're using it to represent 1000+
+- Simpler approach: treat a00 as 1000 offset (a00 = 1000, a01 = 1001, etc.)
+  - 'a' represents 1000-1035 (a00-a0z, a10-a1z, a20-a2z)
+  - Each letter block = 36*36 = 1296 numbers
+- Consider edge cases: what if user manually creates folders with inconsistent numbering?
+- Sorting should work: 001 < 002 < 999 < a00 < a01 (lexicographic with numbers before letters)

package/RAF/004-task-naming-optimization/plans/003-improve-haiku-prompt.md

@@ -0,0 +1,50 @@
+# Task: Improve Haiku Prompt for Project Naming
+
+## Objective
+Update the Claude Haiku prompt for project name generation to focus on the core feature and let Haiku decide the most important task.
+
+## Context
+Currently, the Haiku prompt in `src/utils/name-generator.ts` simply says "Generate a short kebab-case project name (2-4 words) for this project description". The user wants improved guidance so that:
+1. Haiku analyzes the project description to identify the most important/impactful task
+2. The name focuses on the core functionality being built
+3. Names are action-oriented and descriptive
+
+## Requirements
+- Update the Haiku prompt to include instructions for:
+  - Analyzing the project description to find the most important task
+  - Focusing on the core feature/functionality
+  - Creating action-oriented names that describe what the project does
+- Keep the existing constraints: kebab-case, 2-4 words, 50 char max
+- Maintain fallback behavior if Haiku fails
+- User-provided names via CLI should still skip Haiku entirely (existing behavior)
+
+## Implementation Steps
+1. Read `src/utils/name-generator.ts` to understand current implementation
+2. Update the prompt string passed to Haiku with improved instructions:
+   ```
+   Analyze this project description and generate a short kebab-case name (2-4 words).
+   Focus on the most important or core feature being built.
+   The name should be action-oriented, describing what the project does.
+   Examples: 'add-user-auth', 'fix-payment-flow', 'refactor-api-routes'
+
+   Project description:
+   {description}
+   ```
+3. Test the new prompt with various project descriptions
+4. Ensure the sanitization and fallback logic still works
+5. Update any tests related to name generation
+
+## Acceptance Criteria
+- [ ] Haiku prompt includes instruction to identify most important task
+- [ ] Haiku prompt includes instruction to focus on core feature
+- [ ] Haiku prompt guides toward action-oriented naming
+- [ ] Generated names are descriptive of project functionality
+- [ ] Existing fallback behavior (if Haiku fails) still works
+- [ ] CLI-provided names still bypass Haiku
+- [ ] All tests pass
+
+## Notes
+- The prompt should not be too long - Haiku has context limits
+- Keep the response format simple (just the name, no explanation)
+- Consider adding "Output only the name, nothing else" to prevent chatty responses
+- Test with edge cases: vague descriptions, multiple tasks, single task

package/RAF/005-task-naming-improvements/decisions.md

@@ -0,0 +1,60 @@
+# Project Decisions
+
+## For `raf status`, should it work exactly like `raf do` where you can pass a number (3, 003), base36 (a00), or project name? Any additional behavior differences?
+Same as `raf do` PLUS support for full folder names like `001-fix-stuff` or `a01-important-project`.
+
+## When using `raf plan` with an existing project identifier (e.g., `raf plan 3`), what should happen?
+Show error saying project already exists, require explicit `--amend` flag to modify existing plans.
+
+## What operations should `--amend` support for existing plans?
+Add new tasks only - only allow adding new tasks to the end of the plan, preserving existing task numbers.
+
+## How should `raf plan --amend` be invoked?
+`raf plan --amend <id>` - require project identifier with --amend flag.
+
+## When in amend mode, should Claude see the existing tasks and their status?
+Full context - show all existing tasks with their status (completed/pending/failed) so Claude can make informed decisions about new tasks.
+
+## Should `raf do` also support full folder names like `001-fix-stuff`?
+Yes, for consistency - all commands should support the same identifier formats.
+
+## In amend mode, how should the user provide input for new tasks?
+Same as current plan implementation - editor first for user to describe new tasks, then interactive Claude session. The only difference is that Claude will have context of existing tasks and their status.
+
+## What should happen if `--amend` is used on a project that's fully completed?
+Allow with warning - show warning that project is complete but allow adding new tasks.
+
+## Should the enhanced identifier support task-level references for future extensibility?
+Yes, design the resolution function to be extensible for task-level references like `001-project/002-task` in the future.
+
+## [Amendment] When should the outcomes be committed - automatically after each task completes, or only when the entire project (all tasks) is marked complete?
+On project complete - commit all outcomes together when the final task in the project is completed.
+
+## [Amendment] What should be included in the commit when the project completes?
+Full project folder - commit the entire project folder (plans, outcomes, decisions, input, etc.).
+
+## [Amendment] How should the commit message be formatted?
+Use format: `RAF(project): outcomes` - e.g., `RAF(005-task-naming-improvements): outcomes`
+
+## [Amendment] Where should this commit logic be triggered from?
+Inside `raf do` - automatically detect project completion at the end of `raf do` when final task succeeds.
+
+## [Amendment] What should happen if there are other uncommitted changes in the repo when project completes?
+Commit only project - stage and commit only the project folder, leave other changes unstaged.
+
+## [Amendment] Should task 005 be updated or should a new task supersede it for the new commit format?
+Update task 005 directly - PENDING tasks are allowed to be amended. Also create a new task to update the amend prompts to reflect this rule.
+
+## [Amendment] What is the exact universal commit schema format?
+- Task commits: `RAF[005:001] project-name task-name`
+- Plan commits: `RAF[005:plan]`
+- Outcome commits: `RAF[005:outcome]`
+
+## [Amendment] Where do task commits happen?
+Claude makes task commits during execution - need to update prompts that Claude uses.
+
+## [Amendment] Should plan commits be automated via Claude or RAF?
+Plan commits are done by RAF programmatically (not Claude) - format `RAF[005:plan]`.
+
+## [Amendment] Should the message be changed from 'Tasks: X, Timeout: Y minutes' to 'Tasks: X, Task timeout: Y minutes'?
+Yes, exactly that - change 'Timeout' to 'Task timeout' keeping the rest of the format.

package/RAF/005-task-naming-improvements/input.md

@@ -0,0 +1,2 @@
+- [ ] support taking number and full plan/task name across the repo, not just for raf do
+- [ ] add --amend option for plan mode to add more task or modify existing plans if they are not completed

package/RAF/005-task-naming-improvements/outcomes/001-enhance-identifier-resolution.md

@@ -0,0 +1,42 @@
+## Status: SUCCESS
+
+# Task 001 - Completed
+
+## Summary
+## Summary
+I have successfully completed Task 001: Enhance Identifier Resolution for Full Folder Names.
+### Changes Made
+**1. `src/utils/paths.ts`** - Enhanced `resolveProjectIdentifier` function:
+- Added support for full folder name format (e.g., `001-fix-stuff`, `a01-important-project`)
+- Uses pattern `^(\d{2,3}|[a-z][0-9a-z]{2})-(.+)$` to detect full folder names
+- Checks full folder names first with exact (case-insensitive) match
+- Returns null for invalid full folder names without falling through to name-based matching
+- Added comprehensive JSDoc documentation describing all supported identifier formats
+- Function design allows for future task-level reference extension (as noted in documentation)
+**2. `tests/unit/paths.test.ts`** - Added 10 new unit tests:
+- Resolve numeric folder name (`001-fix-stuff`)
+- Resolve base36 folder name (`a01-important-project`)
+- Resolve folder with hyphens in name (`001-my-cool-project`)
+- Return null for wrong prefix with correct name format
+- Return null for correct prefix with wrong name format
+- Case-insensitive folder matching
+- 2-digit prefix full folder names
+- Backward compatibility: name-only resolution still works
+- Backward compatibility: number-only resolution still works
+- Exact full folder match preferred over name-only match
+### Acceptance Criteria Verification
+- ✅ `resolveProjectIdentifier('001-fix-stuff')` returns the correct project path
+- ✅ `resolveProjectIdentifier('a01-important-project')` returns the correct project path  
+- ✅ Invalid full folder names (wrong prefix or name) return null
+- ✅ All existing identifier formats continue to work
+- ✅ Unit tests cover the new functionality (10 new tests)
+- ✅ Function design allows for future task-level reference extension
+### Test Results
+- All 285 tests pass
+- TypeScript build succeeds with no errors
+<promise>COMPLETE</promise>
+
+## Details
+- Attempts: 1
+- Elapsed time: 2m 18s
+- Completed at: 2026-01-30T21:22:43.407Z

package/RAF/005-task-naming-improvements/outcomes/002-add-identifier-support-to-status.md

@@ -0,0 +1,38 @@
+## Status: SUCCESS
+
+# Task 002 - Completed
+
+## Summary
+## Summary
+I have successfully completed Task 002: Add Identifier Support to `raf status`.
+### Changes Made
+**1. `src/commands/status.ts`** - Updated to use `resolveProjectIdentifier`:
+- Changed import from `getProjectDir` to `resolveProjectIdentifier`
+- Renamed parameter from `projectName` to `identifier` to reflect broader support
+- Updated help text: `'Project identifier: number (3), name (my-project), or folder (001-my-project)'`
+- Uses `resolveProjectIdentifier` for all identifier resolution
+- Error message includes the identifier that was not found
+**2. `tests/unit/status-command.test.ts`** - Added 24 new tests:
+- Tests for numeric ID resolution (with and without leading zeros)
+- Tests for base36 ID resolution
+- Tests for project name resolution
+- Tests for full folder name resolution (numeric and base36 prefixes)
+- Tests for case-insensitive folder matching
+- Tests for error cases (non-existent identifiers)
+### Acceptance Criteria Verification
+- ✅ `raf status 3` shows status for project 003 - Uses `resolveProjectIdentifier` which resolves numeric IDs
+- ✅ `raf status 001-fix-stuff` shows status for that project - Uses full folder name resolution
+- ✅ `raf status a00-important` shows status for that project - Uses base36 full folder name resolution
+- ✅ Invalid identifiers show helpful error messages - Error message: "Project not found: {identifier}"
+- ✅ `raf status` (no argument) continues to list all projects - Logic unchanged for no-argument case
+- ✅ Tests cover the new identifier support - 24 new tests added
+- ✅ `--json` output works correctly with all identifier formats - Uses same resolution logic
+### Test Results
+- All 309 tests pass
+- TypeScript build succeeds with no errors
+<promise>COMPLETE</promise>
+
+## Details
+- Attempts: 1
+- Elapsed time: 3m 46s
+- Completed at: 2026-01-30T21:26:29.990Z

package/RAF/005-task-naming-improvements/outcomes/003-update-do-for-full-folder-names.md

@@ -0,0 +1,44 @@
+## Status: SUCCESS
+
+# Task 003 - Completed
+
+## Summary
+## Summary
+I have successfully completed Task 003: Update `raf do` for Full Folder Name Support.
+### Changes Made
+**1. `src/commands/do.ts`** - Updated help text and examples:
+- Changed argument description from `'Project name(s) or number(s) to execute'` to `'Project identifier(s): number (3), name (my-project), or folder (001-my-project)'`
+- Added full folder name examples to usage message: `raf do 001-my-project` and `raf do 003 my-project 001-another-project`
+**2. `tests/unit/do-multiproject.test.ts`** - Added 12 new tests:
+- Full folder name resolution (numeric and base36 prefixes)
+- Multiple projects with full folder names
+- Mixed identifier formats
+- Invalid full folder names
+- Duplicate detection
+- Case-insensitive matching
+- Multi-hyphen names
+- 2-digit prefix support
+**3. `tests/unit/do-command.test.ts`** - Created new test file with 20 tests:
+- Single project full folder name resolution
+- Multiple projects with full folder names
+- Mixed formats including all identifier types
+- Error cases for non-matching folder names
+- Backward compatibility tests
+- Project name extraction tests
+### Acceptance Criteria Verification
+- ✅ `raf do 001-fix-stuff` executes the correct project - Uses `resolveProjectIdentifier()` which supports full folder names
+- ✅ `raf do a00-project` executes the correct project - Supports base36 prefixes
+- ✅ `raf do 001-a 002-b` executes multiple projects correctly - Multi-project resolution works
+- ✅ Mixed formats work: `raf do 3 001-fix-stuff my-project` - All identifier formats work together
+- ✅ Error messages are helpful for non-matching full folder names - Returns null (shown as "Project not found")
+- ✅ All existing tests continue to pass - 341 tests pass
+- ✅ New tests cover full folder name scenarios - 32 new tests added
+### Test Results
+- All 341 tests pass
+- TypeScript build succeeds with no errors
+<promise>COMPLETE</promise>
+
+## Details
+- Attempts: 1
+- Elapsed time: 2m 26s
+- Completed at: 2026-01-30T21:28:56.399Z