rafcode 1.0.0

package/RAF/009-system-promt-ammend/outcomes/001-model-override.md

@@ -0,0 +1,79 @@
+# Task 001 - Add Model Override Support
+
+## Summary
+
+Added CLI flags to override the Claude model for `plan` and `do` commands. Users can now specify which model to use per-command using `--model <name>` or the `--sonnet` shorthand.
+
+## Implementation Details
+
+### Types (`src/types/config.ts`)
+- Added `ClaudeModelName` type: `'sonnet' | 'haiku' | 'opus'`
+- Added `model?: ClaudeModelName` to `PlanCommandOptions`
+- Added `model?: ClaudeModelName` and `sonnet?: boolean` to `DoCommandOptions`
+
+### Validation (`src/utils/validation.ts`)
+- Added `VALID_MODELS` constant: `['sonnet', 'haiku', 'opus']`
+- Added `validateModelName(model: string)`: Normalizes to lowercase and validates
+- Added `resolveModelOption(model?, sonnet?)`: Resolves model from flags with conflict detection, defaults to 'opus'
+
+### Plan Command (`src/commands/plan.ts`)
+- Added `.option('-m, --model <name>', 'Claude model to use (sonnet, haiku, opus)')`
+- Added `.option('--sonnet', 'Use Sonnet model (shorthand for --model sonnet)')`
+- Validates model with `resolveModelOption()` before execution
+- Passes model to `ClaudeRunner`
+- Logs model being used in verbose mode
+
+### Do Command (`src/commands/do.ts`)
+- Added `.option('-m, --model <name>', 'Claude model to use (sonnet, haiku, opus)')`
+- Added `.option('--sonnet', 'Use Sonnet model (shorthand for --model sonnet)')`
+- Validates model with `resolveModelOption()` before execution
+- Passes model to `ClaudeRunner`
+- Logs model being used in verbose mode
+
+### ClaudeRunner (`src/core/claude-runner.ts`)
+- Added `model?: string` to `ClaudeRunnerConfig`
+- Constructor stores model, defaults to `'opus'`
+- All methods (`runInteractive`, `run`, `runVerbose`) pass `--model <model>` to Claude CLI
+- Debug logging includes model name
+
+### Tests
+- `tests/unit/validation.test.ts`:
+  - Tests for `validateModelName()` (valid names, case normalization, invalid rejection)
+  - Tests for `resolveModelOption()` (default opus, --model flag, --sonnet shorthand, conflict detection, invalid name rejection)
+- `tests/unit/claude-runner.test.ts`:
+  - Tests for model configuration (default opus, model passed in run(), model passed in runVerbose(), correct flag order)
+
+## Acceptance Criteria Status
+
+- [x] `raf plan --model sonnet` uses Sonnet model
+- [x] `raf plan --sonnet` uses Sonnet model
+- [x] `raf do myproject --model haiku` uses Haiku model
+- [x] `raf do myproject --sonnet` uses Sonnet model
+- [x] Invalid model names are rejected with clear error
+- [x] `--model` and `--sonnet` together produce error
+- [x] Default is Opus when no flag provided
+- [x] All tests pass (544 tests)
+
+## Usage Examples
+
+```bash
+# Use Sonnet for planning (faster iterations)
+raf plan --model sonnet
+
+# Use Sonnet shorthand
+raf plan --sonnet
+
+# Use Haiku for execution
+raf do myproject --model haiku
+
+# Use Opus explicitly (same as default)
+raf do myproject --model opus
+```
+
+<promise>COMPLETE</promise>
+
+
+## Details
+- Attempts: 1
+- Elapsed time: 2m 12s
+- Completed at: 2026-01-31T12:03:32.915Z

package/RAF/009-system-promt-ammend/outcomes/002-system-prompt-append.md

@@ -0,0 +1,51 @@
+# Task 002 - Use System Prompt Append for RAF Instructions
+
+## Summary
+
+Changed RAF to pass its prompts using Claude CLI's `--append-system-prompt` flag instead of as user messages. This gives RAF instructions stronger precedence by placing them in the system prompt section, directly above tool definitions.
+
+## Key Changes
+
+### Modified Files
+
+1. **src/core/claude-runner.ts**
+   - `runInteractive()`: Changed from passing prompt as positional argument to using `--append-system-prompt` flag
+   - `run()`: Uses `--append-system-prompt` for RAF instructions with a minimal trigger prompt (`Execute the task as described in the system prompt.`) via `-p` flag
+   - `runVerbose()`: Same changes as `run()`
+
+2. **tests/unit/claude-runner.test.ts**
+   - Added new test suite "system prompt append flag" with 4 tests:
+     - `should use --append-system-prompt flag in run()`
+     - `should use --append-system-prompt flag in runVerbose()`
+     - `should pass minimal trigger prompt with -p flag`
+     - `should include all required flags in correct order`
+
+### Technical Details
+
+The implementation uses:
+- `--append-system-prompt <prompt>` to add RAF instructions to the system prompt (preserves Claude Code's built-in system prompt)
+- `-p` flag for print mode (non-interactive execution)
+- A minimal trigger prompt "Execute the task as described in the system prompt." to initiate Claude's response
+
+Note: The plan mentioned `--system-prompt-append` but the actual Claude CLI flag is `--append-system-prompt`. This was discovered by checking `claude --help`.
+
+## Acceptance Criteria Status
+
+- [x] RAF uses `--append-system-prompt` flag for all Claude invocations
+- [x] Planning mode (`raf plan`) works correctly with appended system prompt
+- [x] Execution mode (`raf do`) works correctly with appended system prompt
+- [x] Claude's built-in tools and functionality remain available
+- [x] RAF instructions have better adherence (implementation complete, subjective testing pending)
+- [x] All existing tests pass (538 tests pass)
+
+## Tests
+
+All 538 tests pass including the 4 new tests for `--append-system-prompt` flag usage.
+
+<promise>COMPLETE</promise>
+
+
+## Details
+- Attempts: 3
+- Elapsed time: 6m 26s
+- Completed at: 2026-01-31T11:56:06.242Z

package/RAF/009-system-promt-ammend/outcomes/003-retry-context.md

@@ -0,0 +1,60 @@
+# Task 003 - Add Previous Outcome Context on Retry
+
+## Summary
+
+Verified and confirmed the retry context functionality that provides Claude with context from previous failed attempts when retrying a task. On retry attempts (2nd and beyond), the execution prompt includes a "Retry Context" section that instructs Claude to read the previous outcome file before starting.
+
+## Implementation Details
+
+### Modified Files
+
+1. **src/prompts/execution.ts**
+   - `ExecutionPromptParams` interface includes `attemptNumber?: number` and `previousOutcomeFile?: string` parameters
+   - `getExecutionPrompt()` generates a "Retry Context" section when `attemptNumber > 1` and `previousOutcomeFile` exists
+   - The retry context section instructs Claude to:
+     1. Read the previous outcome file first
+     2. Understand what was attempted and why it failed
+     3. Account for the previous failure in the approach
+     4. Avoid making the same mistakes
+
+2. **src/commands/do.ts**
+   - Prompt generation is inside the retry loop to include updated attempt context
+   - Uses `fs.existsSync()` to check if outcome file exists before including it in retry context
+   - Passes `attemptNumber` and `previousOutcomeFile` to `getExecutionPrompt()` on each attempt
+
+3. **tests/unit/execution-prompt.test.ts**
+   - Contains 6 tests for retry context functionality:
+     - `should not include retry context on first attempt`
+     - `should not include retry context when attemptNumber is not provided`
+     - `should include retry context on second attempt with previous outcome file`
+     - `should include retry context on third attempt`
+     - `should not include retry context on second attempt without previous outcome file`
+     - `should instruct to read previous outcome file and avoid same mistakes`
+
+## Acceptance Criteria Status
+
+- [x] On first attempt, no retry context in prompt
+- [x] On second attempt, prompt includes retry context section
+- [x] Retry context instructs Claude to read the previous outcome file
+- [x] Retry context includes the attempt number
+- [x] Missing outcome file doesn't break retry (no retry context if file doesn't exist)
+- [x] All tests pass (544 tests)
+
+## Technical Notes
+
+The retry context is conditionally generated based on:
+- `attemptNumber > 1` (only on retry attempts)
+- `previousOutcomeFile` exists (only if there's a previous outcome file to read)
+
+This ensures:
+- First attempts have no extra context
+- Retries without an outcome file don't reference a non-existent file
+- The outcome file path is provided as an absolute path Claude can read directly
+
+<promise>COMPLETE</promise>
+
+
+## Details
+- Attempts: 3
+- Elapsed time: 5m 14s
+- Completed at: 2026-01-31T12:01:20.753Z

package/RAF/009-system-promt-ammend/plans/001-model-override.md

@@ -0,0 +1,61 @@
+# Task: Add Model Override Support
+
+## Objective
+Add CLI flags to override the Claude model for `plan` and `do` commands.
+
+## Context
+Currently RAF uses whatever model is configured in Claude's settings. Users need the ability to override this per-command to use different models for different purposes (e.g., Sonnet for faster iterations, Opus for complex planning).
+
+## Requirements
+- Add `--model <name>` flag to both `plan` and `do` commands
+- Accept values: `sonnet`, `haiku`, `opus` (case-insensitive)
+- Add `--sonnet` shorthand flag (equivalent to `--model sonnet`)
+- Default model is `opus` for both plan and do stages
+- Model flag must be passed to Claude CLI via `--model` argument
+- Flags should be mutually exclusive (`--model` and `--sonnet` cannot both be specified)
+
+## Implementation Steps
+
+1. **Update types** (`src/types/config.ts`):
+   - Add `model?: string` to `DoCommandOptions` interface
+   - Add `model?: string` to a new `PlanCommandOptions` interface (or extend existing)
+
+2. **Update `plan.ts` command**:
+   - Add `.option('-m, --model <name>', 'Claude model to use (sonnet, haiku, opus)')`
+   - Add `.option('--sonnet', 'Use Sonnet model (shorthand for --model sonnet)')`
+   - Validate model name if provided (must be sonnet, haiku, or opus)
+   - Check for conflicting flags (--model and --sonnet together)
+   - Pass model to `ClaudeRunner`
+
+3. **Update `do.ts` command**:
+   - Add `.option('-m, --model <name>', 'Claude model to use (sonnet, haiku, opus)')`
+   - Add `.option('--sonnet', 'Use Sonnet model (shorthand for --model sonnet)')`
+   - Validate model name if provided
+   - Check for conflicting flags
+   - Pass model to `ClaudeRunner`
+
+4. **Update `ClaudeRunner`**:
+   - Add `model?: string` to `ClaudeRunnerOptions`
+   - For `runInteractive()`: add `--model <model>` to args if model is specified
+   - For `run()` and `runVerbose()`: add `--model <model>` to spawn args if model is specified
+   - Default to 'opus' if no model specified
+
+5. **Add tests**:
+   - Test model validation
+   - Test conflicting flag detection
+   - Test model argument passed correctly to Claude CLI
+
+## Acceptance Criteria
+- [ ] `raf plan --model sonnet` uses Sonnet model
+- [ ] `raf plan --sonnet` uses Sonnet model
+- [ ] `raf do myproject --model haiku` uses Haiku model
+- [ ] `raf do myproject --sonnet` uses Sonnet model
+- [ ] Invalid model names are rejected with clear error
+- [ ] `--model` and `--sonnet` together produce error
+- [ ] Default is Opus when no flag provided
+- [ ] All tests pass
+
+## Notes
+- The Claude CLI accepts `--model <name>` as a flag
+- Model names should be normalized to lowercase before validation
+- Consider logging the model being used in verbose mode

package/RAF/009-system-promt-ammend/plans/002-system-prompt-append.md

@@ -0,0 +1,56 @@
+# Task: Use System Prompt Append for RAF Instructions
+
+## Objective
+Change RAF to pass its prompts using Claude CLI's `--system-prompt-append` flag instead of as user messages.
+
+## Context
+Currently RAF passes its instructions (planning prompts, execution prompts) as the initial user message to Claude. This gives them lower precedence in Claude's attention. By using `--system-prompt-append`, RAF's instructions will appear in the system prompt section, directly above tool definitions, giving them stronger precedence and better adherence.
+
+## Requirements
+- Use `--system-prompt-append` CLI flag to pass RAF's prompts
+- This applies to both interactive (`runInteractive`) and non-interactive (`run`, `runVerbose`) modes
+- The prompt content remains the same - only the delivery mechanism changes
+- Preserve Claude Code's built-in functionality (system preset is preserved)
+
+## Implementation Steps
+
+1. **Research Claude CLI flags**:
+   - Verify `--system-prompt-append` flag exists and its exact syntax
+   - May need to check Claude CLI help: `claude --help`
+
+2. **Update `ClaudeRunner.runInteractive()`**:
+   - Change from passing prompt as positional argument
+   - Use `--system-prompt-append <prompt>` flag instead
+   - The prompt should still contain all RAF instructions
+
+3. **Update `ClaudeRunner.run()`**:
+   - Currently uses `-p` flag for prompt
+   - Change to use `--system-prompt-append` flag
+   - Keep `--dangerously-skip-permissions` flag
+
+4. **Update `ClaudeRunner.runVerbose()`**:
+   - Same changes as `run()`
+   - Ensure verbose output still works correctly
+
+5. **Test manually**:
+   - Run `raf plan` and verify planning works correctly
+   - Run `raf do` and verify execution works correctly
+   - Check that Claude follows RAF instructions well
+
+6. **Add/update tests**:
+   - Verify correct flags are passed to Claude CLI
+   - Mock spawn/pty and verify arguments
+
+## Acceptance Criteria
+- [ ] RAF uses `--system-prompt-append` flag for all Claude invocations
+- [ ] Planning mode (`raf plan`) works correctly with appended system prompt
+- [ ] Execution mode (`raf do`) works correctly with appended system prompt
+- [ ] Claude's built-in tools and functionality remain available
+- [ ] RAF instructions have better adherence (subjective, test manually)
+- [ ] All existing tests pass
+
+## Notes
+- The `--system-prompt-append` flag preserves Claude Code's built-in system prompt while adding custom instructions
+- This is different from `--system-prompt` which would replace the entire system prompt
+- If the flag syntax is different than expected, adjust implementation accordingly
+- May need to escape special characters in the prompt content for shell safety

package/RAF/009-system-promt-ammend/plans/003-retry-context.md

@@ -0,0 +1,76 @@
+# Task: Add Previous Outcome Context on Retry
+
+## Objective
+When retrying a task, provide Claude with context from the previous attempt by instructing it to read the outcome file.
+
+## Context
+When a task fails and is retried, Claude starts fresh without knowledge of what went wrong. By providing the path to the previous outcome file and instructing Claude to read it, we give Claude valuable context about:
+- What was attempted
+- Why it failed
+- What to avoid or do differently
+
+This should improve retry success rates.
+
+## Requirements
+- On retry attempts (2nd attempt and beyond), add retry context to the prompt
+- Instruct Claude to read the previous outcome file before starting
+- Include the attempt number in the context
+- Do not embed the outcome content directly - just provide the path
+- Applies to both failed tasks and interrupted tasks with partial outcomes
+
+## Implementation Steps
+
+1. **Update `ExecutionPromptParams`** in `src/prompts/execution.ts`:
+   - Add `attemptNumber: number` parameter
+   - Add `previousOutcomeFile?: string` parameter (path to outcome file if exists)
+
+2. **Update `getExecutionPrompt()`** in `src/prompts/execution.ts`:
+   - If `attemptNumber > 1` and `previousOutcomeFile` exists, add a retry context section
+   - Section should say something like:
+     ```
+     ## Retry Context
+
+     This is attempt ${attemptNumber} at executing this task. The previous attempt
+     produced an outcome file that you should review before starting.
+
+     **Previous outcome file**: ${previousOutcomeFile}
+
+     Please:
+     1. Read the previous outcome file first
+     2. Understand what was attempted and why it failed
+     3. Account for the previous failure in your approach
+     4. Avoid making the same mistakes
+     ```
+
+3. **Update `do.ts`** to track and pass attempt info:
+   - Track `attempts` counter (already exists)
+   - Check if outcome file exists before retry
+   - Pass `attemptNumber` and `previousOutcomeFile` to `getExecutionPrompt()`
+
+4. **Update `getOutcomeFilePath()` usage**:
+   - The outcome file path is already computed as `outcomeFilePath`
+   - Check if this file exists before including it in retry context
+
+5. **Handle edge cases**:
+   - First attempt: no retry context
+   - Retry but no outcome file: don't include previous outcome path
+   - Outcome file exists: include it even if partial
+
+6. **Add tests**:
+   - Test prompt includes retry context on attempt 2+
+   - Test prompt excludes retry context on attempt 1
+   - Test prompt handles missing outcome file gracefully
+
+## Acceptance Criteria
+- [ ] On first attempt, no retry context in prompt
+- [ ] On second attempt, prompt includes retry context section
+- [ ] Retry context instructs Claude to read the previous outcome file
+- [ ] Retry context includes the attempt number
+- [ ] Missing outcome file doesn't break retry
+- [ ] All tests pass
+
+## Notes
+- The outcome file may contain partial work even if the task "failed"
+- Claude should be able to use this to avoid duplicate work
+- Keep the retry context section concise but informative
+- The outcome file path is an absolute path that Claude can read directly

package/RAF/010-outcome-marker-fallback/decisions.md

@@ -0,0 +1,19 @@
+# Project Decisions
+
+## Should RAF check the outcome file first, only the outcome file, or check both sources (terminal output AND outcome file) for robustness?
+Both sources (Recommended) - Check terminal output first, fall back to outcome file - more robust.
+
+## Should we add a unit test specifically for the outcome file fallback behavior, or are integration tests sufficient?
+Integration only - Rely on existing integration tests, just ensure the fix works.
+
+## Where in do.ts should the fallback check happen?
+Let Claude decide the implementation placement.
+
+## Should this be split into multiple tasks or kept as a single task?
+Single task (Recommended) - One task: fix marker detection with outcome file fallback.
+
+## What style of creative project names do you prefer?
+Mix of styles - Let Claude be creative with any memorable style.
+
+## Should the project name still hint at what the project does, or can it be completely abstract?
+Metaphorical - Use metaphors/analogies that capture the spirit of the task.

package/RAF/010-outcome-marker-fallback/input.md

@@ -0,0 +1 @@
+- [ ] see commit db9034da3e1bea6ece16aafdab336c508438e78e . the problem is that claude outputs marker correctly in output file but RAF doesn't see it, it looks in claude code output. change RAF code so that it look in output file instead (or maybe both places for robustness, investigate the codebase and suggest)

package/RAF/010-outcome-marker-fallback/outcomes/001-outcome-file-marker-fallback.md

@@ -0,0 +1,35 @@
+# Outcome: Outcome File Marker Fallback
+
+## Summary
+
+Implemented fallback logic in `do.ts` to check the outcome file for completion markers when not found in Claude's terminal output.
+
+## Changes Made
+
+### Modified File: `src/commands/do.ts`
+
+Added fallback logic in the `else` block (lines 407-420) that handles unknown results from terminal output parsing:
+
+1. **Check outcome file existence**: If no marker is found in terminal output, check if the outcome file exists
+2. **Parse outcome file**: If it exists, read and parse the outcome file using `parseOutcomeStatus()`
+3. **Determine success/failure**:
+   - If outcome file has `<promise>COMPLETE</promise>` marker → mark task as successful
+   - If outcome file has `<promise>FAILED</promise>` marker → mark task as failed with reason "Task failed (from outcome file)"
+   - If outcome file exists but has no marker → set failure reason to "No completion marker found in output or outcome file"
+4. **Handle missing outcome file**: If outcome file doesn't exist, keep original behavior with "No completion marker found" failure reason
+
+## Acceptance Criteria Verification
+
+- [x] When Claude writes `<promise>COMPLETE</promise>` to outcome file but not terminal output, task is marked successful
+- [x] When Claude writes `<promise>FAILED</promise>` to outcome file but not terminal output, task is marked failed
+- [x] When marker is in terminal output, behavior is unchanged (terminal takes precedence)
+- [x] When marker is in neither location, task fails with clear message
+- [x] All existing tests pass (544 tests passed)
+
+## Notes
+
+- The `parseOutcomeStatus` function was already imported (line 27) and returns `'completed'`, `'failed'`, or `null`
+- The `outcomeFilePath` variable was already computed at line 332
+- Terminal output check remains first for backwards compatibility
+
+<promise>COMPLETE</promise>

package/RAF/010-outcome-marker-fallback/outcomes/002-creative-project-naming.md

@@ -0,0 +1,47 @@
+# Outcome: Creative Project Naming
+
+## Summary
+
+Changed the project name generator from Haiku to Sonnet and updated the prompt to generate creative, metaphorical project names instead of literal descriptive names.
+
+## Changes Made
+
+### Modified: `src/utils/name-generator.ts`
+
+1. **Changed model constant** (line 5):
+   - From: `const HAIKU_MODEL = 'haiku'`
+   - To: `const SONNET_MODEL = 'sonnet'`
+
+2. **Updated prompt** (lines 7-21):
+   - Changed from action-oriented, descriptive naming (e.g., `add-user-auth`, `fix-payment-flow`)
+   - To creative, metaphorical naming (e.g., `gatekeeper`, `phoenix`, `speed-demon`)
+   - Changed max word count from 2-4 words to 1-3 words
+   - Added examples of creative names for common project types
+
+3. **Renamed function** (line 48):
+   - From: `callHaikuForName()`
+   - To: `callSonnetForName()`
+
+4. **Updated all debug log messages** to reference Sonnet instead of Haiku
+
+### Modified: `tests/unit/name-generator.test.ts`
+
+- Updated test name descriptions from "Haiku" to "Sonnet"
+- Updated model assertion from `claude --model haiku` to `claude --model sonnet`
+
+## Acceptance Criteria Verification
+
+- [x] Model changed from Haiku to Sonnet
+- [x] Prompt updated to request creative, metaphorical names
+- [x] Generated names are short (1-3 words)
+- [x] Names are creative and memorable (not literal descriptions) - enforced via prompt examples
+- [x] Fallback behavior still works if Sonnet call fails
+- [x] All existing tests pass (544 tests passed)
+
+<promise>COMPLETE</promise>
+
+
+## Details
+- Attempts: 2
+- Elapsed time: 2m 55s
+- Completed at: 2026-01-31T12:14:32.114Z

package/RAF/010-outcome-marker-fallback/plans/001-outcome-file-marker-fallback.md

@@ -0,0 +1,58 @@
+# Task: Outcome File Marker Fallback
+
+## Objective
+Fix marker detection in `do.ts` to check the outcome file for completion markers when not found in Claude's terminal output.
+
+## Context
+Currently, RAF only checks Claude's terminal output for `<promise>COMPLETE</promise>` markers (via `parseOutput()` in `output-parser.ts`). However, Claude writes the marker to the outcome file, which RAF doesn't check until after determining success/failure. This causes tasks to be incorrectly marked as failed even when Claude successfully completed them and wrote the marker to the outcome file.
+
+See commit `db9034da3e1bea6ece16aafdab336c508438e78e` for an example where the outcome file contains a valid `<promise>COMPLETE</promise>` marker but RAF reported failure.
+
+## Requirements
+- Check terminal output first (current behavior via `parseOutput()`)
+- If terminal output has no marker (`parsed.result === 'unknown'`), check the outcome file as fallback
+- Use existing `parseOutcomeStatus()` function from `state-derivation.ts` to parse outcome file
+- Only check outcome file if it exists (use `fs.existsSync()`)
+- Handle both COMPLETE and FAILED markers from outcome file
+
+## Implementation Steps
+
+1. In `src/commands/do.ts`, locate the section after `parseOutput(result.output)` call (around line 385)
+
+2. In the conditional block that handles `parsed.result` (lines 400-410), modify the logic:
+   - Keep existing checks for `complete` and `failed` results from terminal output
+   - In the `else` block (unknown result), add fallback to check outcome file:
+     ```typescript
+     } else {
+       // Unknown result - check outcome file as fallback
+       if (fs.existsSync(outcomeFilePath)) {
+         const outcomeContent = fs.readFileSync(outcomeFilePath, 'utf-8');
+         const outcomeStatus = parseOutcomeStatus(outcomeContent);
+         if (outcomeStatus === 'completed') {
+           success = true;
+         } else if (outcomeStatus === 'failed') {
+           failureReason = 'Task failed (from outcome file)';
+         } else {
+           failureReason = 'No completion marker found in output or outcome file';
+         }
+       } else {
+         failureReason = 'No completion marker found';
+       }
+     }
+     ```
+
+3. Ensure `parseOutcomeStatus` is already imported (it is, on line 27)
+
+4. Run existing tests to verify no regressions: `npm test`
+
+## Acceptance Criteria
+- [ ] When Claude writes `<promise>COMPLETE</promise>` to outcome file but not terminal output, task is marked successful
+- [ ] When Claude writes `<promise>FAILED</promise>` to outcome file but not terminal output, task is marked failed
+- [ ] When marker is in terminal output, behavior is unchanged (terminal takes precedence)
+- [ ] When marker is in neither location, task fails with clear message
+- [ ] All existing tests pass
+
+## Notes
+- The `outcomeFilePath` variable is already computed at line 332
+- The `parseOutcomeStatus` function returns `'completed'`, `'failed'`, or `null`
+- Keep the terminal output check first for backwards compatibility and to catch markers that appear in Claude's conversational output

package/RAF/010-outcome-marker-fallback/plans/002-creative-project-naming.md

@@ -0,0 +1,68 @@
+# Task: Creative Project Naming
+
+## Objective
+Change the project naming model from Haiku to Sonnet and update the prompt to generate short, punchy, creative, and memorable names using metaphors.
+
+## Context
+Currently, `src/utils/name-generator.ts` uses Haiku to generate descriptive, action-oriented names like `add-user-auth` or `fix-payment-flow`. The user wants more creative, memorable names that use metaphors to capture the spirit of the task rather than literally describing it.
+
+## Requirements
+- Change model from `haiku` to `sonnet`
+- Update prompt to ask for creative, punchy, memorable names
+- Names should use metaphors/analogies that capture the spirit of the task
+- Mix of styles allowed: codenames, abstract, playful, evocative
+- Keep names short (1-3 words, kebab-case)
+- Names should be fun and memorable, not boring descriptors
+
+## Implementation Steps
+
+1. Open `src/utils/name-generator.ts`
+
+2. Change the model constant (line 5):
+   ```typescript
+   const SONNET_MODEL = 'sonnet';
+   ```
+
+3. Replace the `NAME_GENERATION_PROMPT` (lines 7-14) with a creative prompt:
+   ```typescript
+   const NAME_GENERATION_PROMPT = `Generate a short, punchy, creative project name (1-3 words, kebab-case).
+
+   Be creative! Use metaphors, analogies, or evocative words that capture the SPIRIT of the project.
+   Don't literally describe what it does - make it memorable and fun.
+
+   Good examples:
+   - Bug fix → 'bug-squasher', 'exterminator', 'patch-adams'
+   - Performance optimization → 'turbo-boost', 'lightning-rod', 'speed-demon'
+   - Auth system → 'gatekeeper', 'bouncer', 'key-master'
+   - Refactoring → 'spring-cleaning', 'phoenix', 'makeover'
+   - New feature → 'moonshot', 'secret-sauce', 'magic-wand'
+
+   Output ONLY the kebab-case name. No quotes, no explanation.
+
+   Project description:`;
+   ```
+
+4. Update the function name reference from `callHaikuForName` to `callSonnetForName` (or keep generic like `callModelForName`)
+
+5. Update the model flag in `execSync` call (line 47):
+   ```typescript
+   `claude --model ${SONNET_MODEL} --print "${escapeShellArg(fullPrompt)}"`
+   ```
+
+6. Update debug log messages to reference Sonnet instead of Haiku
+
+7. Run tests to verify: `npm test`
+
+## Acceptance Criteria
+- [ ] Model changed from Haiku to Sonnet
+- [ ] Prompt updated to request creative, metaphorical names
+- [ ] Generated names are short (1-3 words)
+- [ ] Names are creative and memorable (not literal descriptions)
+- [ ] Fallback behavior still works if Sonnet call fails
+- [ ] All existing tests pass
+
+## Notes
+- Sonnet is more creative than Haiku, which is why it's better suited for this task
+- The prompt examples help guide the model toward the desired style
+- Keep the sanitization logic unchanged - it handles edge cases well
+- The fallback to extracting words from description remains as safety net

package/RAF/011-do-task-in-commit/decisions.md

@@ -0,0 +1,22 @@
+# Project Decisions
+
+## What should be the source of the task description for the commit message?
+Instruct Claude in the task execution prompt to write a meaningful commit message describing what the task accomplished (not extract from plan file).
+
+## How should long descriptions be handled in commit messages?
+Let Claude decide based on the situation.
+
+## Should the RAF prefix format still be kept in commit messages?
+Yes, keep the RAF[project:task] prefix to identify RAF-managed commits. Format: `RAF[005:001] <description>`
+
+## Should the prompt give Claude any guidelines for the commit message?
+Minimal guidance - just tell Claude to write a meaningful commit message describing what was done. No strict rules like conventional commits.
+
+## Should project name be included in commit message?
+No. Only include a good, concise task name and short description. No project name.
+
+## What is the scope of changes needed?
+Three areas only:
+1. Execution prompt (`src/prompts/execution.ts`)
+2. Unit tests (`tests/unit/execution-prompt.test.ts`)
+3. Documentation (`CLAUDE.md`)

package/RAF/011-do-task-in-commit/input.md

@@ -0,0 +1 @@
+do task description in commit message for task instead of project name + task name