rafcode 1.0.0

package/RAF/013-dependencies-watchdog/plans/003-parse-dependencies-update-state.md

@@ -0,0 +1,46 @@
+# Task: Parse Dependencies and Update State Derivation
+
+## Objective
+Add dependency parsing to plan file reading and extend state derivation to include a new `blocked` status.
+
+## Context
+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
+
+## Requirements
+- Parse `## Dependencies` section from plan files
+- Extract comma-separated task IDs (e.g., "001, 002" → ["001", "002"])
+- Add new `blocked` status to `DerivedTask` type (in addition to pending, completed, failed)
+- A task is `blocked` when any of its dependencies have status `failed` or `blocked`
+- Add new `<promise>BLOCKED</promise>` marker recognition in outcome parsing
+- Update `DerivedTask` interface to include `dependencies: string[]` field
+- Update `getNextExecutableTask()` to skip blocked tasks
+
+## Implementation Steps
+1. Update `src/types/index.ts`:
+   - Add `'blocked'` to TaskStatus union type
+   - Add `dependencies: string[]` to DerivedTask interface
+2. Create dependency parser in `src/parsers/` or add to existing parser:
+   - Function to extract Dependencies section from plan content
+   - Parse comma-separated IDs into string array
+   - Handle missing section (return empty array)
+3. Update `src/core/state-derivation.ts`:
+   - Modify `deriveProjectState()` to read dependencies from each plan
+   - Add logic to determine blocked status based on dependency states
+   - Update `parseOutcomeStatus()` to recognize BLOCKED marker
+4. Update `getNextExecutableTask()` to skip blocked tasks (don't return them for execution)
+
+## Acceptance Criteria
+- [ ] DerivedTask includes dependencies array
+- [ ] TaskStatus includes 'blocked'
+- [ ] Dependencies correctly parsed from plan files
+- [ ] Tasks with failed/blocked dependencies have status 'blocked'
+- [ ] BLOCKED marker recognized in outcome files
+- [ ] getNextExecutableTask() skips blocked tasks
+
+## Notes
+- Blocked status is derived, not persisted - calculated each time state is derived
+- A task becomes blocked when ANY dependency fails (not all)
+- Blocked tasks stay blocked until the failed dependency is fixed and re-run

package/RAF/013-dependencies-watchdog/plans/004-implement-dependency-checking-in-do.md

@@ -0,0 +1,48 @@
+# Task: Implement Dependency Checking in `raf do`
+
+## Objective
+Update the `raf do` command to detect blocked tasks and automatically create blocked outcome files instead of attempting execution.
+
+## Context
+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
+
+## Requirements
+- Before executing a task, check if it's blocked (has failed/blocked dependencies)
+- For blocked tasks, skip Claude execution entirely
+- Generate a blocked outcome file with:
+  - Explanation of which dependency failed
+  - List of failed/blocked dependency task IDs
+  - End with `<promise>BLOCKED</promise>` marker
+- Show clear console output when a task is blocked
+- Update progress display to show blocked tasks distinctly
+- Blocked tasks should be processed in order (to cascade blocking properly)
+
+## Implementation Steps
+1. Update `src/commands/do.ts` task execution loop:
+   - Before calling Claude, check task status from derived state
+   - If status is `blocked`, skip execution and generate blocked outcome
+2. Create blocked outcome generator (can be in `do.ts` or separate module):
+   - Generate structured outcome explaining the block
+   - Include failed dependency info
+   - End with BLOCKED marker
+3. Update console output for blocked tasks:
+   - Show message like "Task 003 blocked by failed dependency: 002"
+   - Use distinct color/formatting (e.g., yellow for blocked vs red for failed)
+4. Ensure proper cascade: after marking a task blocked, re-derive state before next task
+5. Update summary output to show blocked count separately from failed
+
+## Acceptance Criteria
+- [ ] Blocked tasks are detected and skipped
+- [ ] Blocked outcome file created with proper format and BLOCKED marker
+- [ ] Console shows clear blocked message with dependency info
+- [ ] Blocking cascades properly (if 001 fails, 002 blocked, 003 depends on 002 also blocked)
+- [ ] Summary shows blocked tasks separately from failed
+- [ ] No Claude execution attempted for blocked tasks
+
+## Notes
+- Blocked outcome files are generated by RAF, not Claude (unlike normal outcomes)
+- The BLOCKED marker ensures consistency with the outcome file convention
+- Re-deriving state after each task ensures cascading works correctly

package/RAF/013-dependencies-watchdog/plans/005-update-execution-prompts.md

@@ -0,0 +1,44 @@
+# Task: Update Execution Prompts with Dependency Context
+
+## Objective
+Modify the execution system prompt to include outcome summaries of completed dependency tasks, giving Claude full context when executing dependent tasks.
+
+## Context
+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
+
+## Requirements
+- Execution prompt should include dependency task outcomes when relevant
+- Show outcome summaries (not full content) to manage context size
+- Clearly label which outcomes are from dependencies vs previous tasks
+- Only include outcomes for tasks listed in Dependencies section
+- Handle case where task has no dependencies (no extra context)
+
+## Implementation Steps
+1. Update `src/prompts/execution.ts`:
+   - Accept dependency information (list of dependency task IDs)
+   - Accept dependency outcomes (map of task ID to outcome content)
+   - Add new section to prompt: "## Dependency Context"
+2. Create outcome summarizer (if needed):
+   - Extract key information from outcome files for context
+   - Or include full outcome if reasonably sized
+3. Update `src/commands/do.ts` to pass dependency info to execution prompt:
+   - Read dependency outcomes from project
+   - Pass to prompt builder
+4. Format the dependency context section:
+   - List each dependency task with its outcome summary
+   - Make clear these tasks have already completed successfully
+
+## Acceptance Criteria
+- [ ] Execution prompt includes dependency context section when task has dependencies
+- [ ] Dependency outcomes clearly labeled by task ID
+- [ ] Claude receives useful context about what dependencies accomplished
+- [ ] Tasks without dependencies have no extra context section
+- [ ] Context size remains reasonable (summarize if needed)
+
+## Notes
+- This is about providing context, not validation - blocked tasks are handled in task 004
+- Focus on giving Claude actionable information about the state of the project
+- Consider truncating very long outcomes to avoid context bloat

package/RAF/013-dependencies-watchdog/plans/006-add-tests.md

@@ -0,0 +1,54 @@
+# Task: Add Tests for Dependency Features
+
+## Objective
+Create comprehensive tests for all dependency-related functionality to ensure reliable behavior.
+
+## Context
+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
+
+## Requirements
+- Unit tests for dependency parsing
+- Unit tests for blocked status derivation
+- Unit tests for getNextExecutableTask with blocked tasks
+- Integration tests for the full blocking flow
+- Test edge cases: no dependencies, multiple dependencies, cascading blocks
+
+## Implementation Steps
+1. Add tests in `src/parsers/__tests__/` for dependency parsing:
+   - Parse valid Dependencies section
+   - Handle missing Dependencies section (returns empty array)
+   - Handle malformed input gracefully
+   - Parse multiple dependencies
+2. Add tests in `src/core/__tests__/state-derivation.test.ts`:
+   - Task blocked when single dependency fails
+   - Task blocked when any of multiple dependencies fails
+   - Cascading: task blocked when dependency is blocked
+   - Task not blocked when all dependencies completed
+   - BLOCKED marker recognition
+3. Add tests for getNextExecutableTask:
+   - Skip blocked tasks
+   - Return null when all remaining tasks blocked
+   - Handle mixed states (some completed, some pending, some blocked)
+4. Add tests for execution prompt generation with dependencies:
+   - Include dependency context when present
+   - Omit section when no dependencies
+5. Add integration test for full flow (if test infrastructure supports):
+   - Mock project with dependencies
+   - Simulate failure of one task
+   - Verify dependent tasks get blocked
+
+## Acceptance Criteria
+- [ ] Dependency parsing tests pass
+- [ ] Blocked status derivation tests pass
+- [ ] getNextExecutableTask tests cover blocked scenarios
+- [ ] Prompt generation tests verify dependency context
+- [ ] All new code has >80% test coverage
+- [ ] Tests follow existing patterns in the codebase
+
+## Notes
+- Follow TDD where possible - write tests for each component as it's implemented
+- Use mocking for Claude calls to test execution flow without actual API calls
+- Ensure tests run in isolation (don't depend on file system state)

package/RAF/013-dependencies-watchdog/plans/007-add-act-alias.md

@@ -0,0 +1,26 @@
+# Task: Add 'act' Alias for 'do' Command
+
+## Objective
+Add 'act' as a complete alias for the 'raf do' command, allowing users to run `raf act` instead of `raf do`.
+
+## Context
+Some users may prefer the command name "act" over "do" as it's more descriptive ("take action on tasks"). This is a simple UX improvement that adds choice without changing any behavior.
+
+## Requirements
+- `raf act` should be identical to `raf do` in all respects
+- All options and arguments must work exactly the same
+- Help text should show `act` as an alias of `do`
+
+## Implementation Steps
+1. Open `src/commands/do.ts`
+2. Add `.alias('act')` to the command definition chain (after `.description()`)
+3. Verify the alias works by building and testing manually
+
+## Acceptance Criteria
+- [ ] `raf act <project>` executes tasks just like `raf do <project>`
+- [ ] `raf act --help` shows the same options as `raf do --help`
+- [ ] All flags (`-m`, `--sonnet`, `-y`, `--retries`, etc.) work with `raf act`
+- [ ] `raf --help` shows `act` as an alias or separate command
+
+## Notes
+Commander.js provides the `.alias()` method which makes this a one-line change.

package/RAF/013-dependencies-watchdog/plans/008-add-exit-message.md

@@ -0,0 +1,31 @@
+# Task: Add Exit Instructions After Planning
+
+## Objective
+After Claude finishes creating plans, display a message instructing the user how to exit Claude (double Ctrl-C) and how to execute the tasks.
+
+## Context
+When `raf plan` runs, Claude operates in an interactive TTY session. After planning is complete, users may not know how to exit the Claude session. This message provides clear guidance.
+
+## Requirements
+- Show message after Claude completes plan creation
+- Message should mention: "Press Ctrl-C twice to exit"
+- Message should mention: "Then run: raf do <project>"
+- Keep the message simple and generic (don't include specific project identifier)
+
+## Implementation Steps
+1. Open `src/prompts/planning.ts`
+2. In the system prompt, add a "Step 4: Confirm Completion" section after "Step 3: Create Plan Files"
+3. Instruct Claude to output a completion message that includes:
+   - Confirmation that planning is done
+   - "Press Ctrl-C twice to exit"
+   - "Then run: raf do <project>"
+4. Similarly update `src/prompts/amend.ts` to include the same exit message for amendment mode
+
+## Acceptance Criteria
+- [ ] After `raf plan` completes, Claude displays exit instructions
+- [ ] After `raf plan --amend` completes, Claude displays exit instructions
+- [ ] Message is clear and actionable
+- [ ] Message uses generic `<project>` placeholder (not actual project name)
+
+## Notes
+The message should be part of Claude's output (in the system prompt), not RAF's output after Claude exits. This ensures the user sees it while Claude is still running.

package/RAF/014-watchdog/decisions.md

@@ -0,0 +1,16 @@
+# Project Decisions
+
+## For --amend after project name, should the syntax be `raf plan <identifier> --amend` (flag is boolean, identifier is the positional argument)?
+Support both syntaxes - Support both `raf plan --amend <id>` and `raf plan <id> --amend`
+
+## For the details section, what exactly should be removed from successful outcomes?
+Remove entire `## Details` section - No metadata at all on success (no attempts, elapsed time, or timestamp)
+
+## When a task succeeds after prior failures (retry), should the `## Failure History` section still be included in the outcome?
+~~Keep failure history on success after retries~~ REVISED: Move failure history to console output at end of `raf do`
+
+## Where should the failure history be moved to?
+Console output at end of `raf do` - Show failure history in the terminal summary, not in outcome files
+
+## When should failure history appear in console output?
+For any task that had retries - Show retry history even for tasks that eventually succeeded after failures

package/RAF/014-watchdog/input.md

@@ -0,0 +1,2 @@
+- [ ] support --amend after project name/id
+- [ ] append details to output file only if task failed

package/RAF/014-watchdog/outcomes/001-amend-flag-position.md

@@ -0,0 +1,50 @@
+# Outcome: Support --amend flag after project identifier
+
+## Summary
+
+Successfully implemented support for both `raf plan <project> --amend` and `raf plan --amend <project>` syntaxes for the amend command.
+
+## Changes Made
+
+### 1. Modified `src/commands/plan.ts`
+
+- Changed `--amend` from a value-taking option (`-a, --amend <identifier>`) to a boolean flag (`-a, --amend`)
+- Updated `PlanCommandOptions` interface: changed `amend?: string` to `amend?: boolean`
+- Updated action handler to:
+  - Use the positional `projectName` argument as the identifier when `--amend` is set
+  - Show clear error message if `--amend` is used without a project identifier
+  - Error message guides users with both valid syntaxes
+
+### 2. Added `tests/unit/plan-command-amend-flag.test.ts`
+
+New test file covering:
+- `--amend` flag acceptance and `-a` shorthand
+- Boolean flag verification (no required argument)
+- Positional argument availability with `--amend` flag
+- Structural support for both syntax variants
+
+## Key Implementation Details
+
+The key insight is that Commander.js handles boolean flags and positional arguments separately:
+- When `--amend` takes a `<value>`, it consumes the next argument
+- When `--amend` is a boolean flag, the positional argument remains available
+
+Both syntaxes now work because:
+- `raf plan myproject --amend` → positional arg = "myproject", amend = true
+- `raf plan --amend myproject` → positional arg = "myproject", amend = true
+
+## Acceptance Criteria Verification
+
+- [x] `raf plan myproject --amend` works (opens editor for amendment)
+- [x] `raf plan --amend myproject` still works (backward compatibility via positional arg)
+- [x] `raf plan --amend` without identifier shows helpful error message
+- [x] All existing tests pass (717 tests)
+- [x] New tests added for both syntax variants
+
+<promise>COMPLETE</promise>
+
+
+## Details
+- Attempts: 1
+- Elapsed time: 2m 5s
+- Completed at: 2026-01-31T17:10:51.923Z

package/RAF/014-watchdog/outcomes/002-details-only-on-failure.md

@@ -0,0 +1,58 @@
+# Outcome: Remove details and failure history from successful outcomes
+
+## Summary
+
+Successfully implemented the behavior change to clean up successful task outcomes while preserving debugging information in failed outcomes.
+
+## Changes Made
+
+### 1. Modified `src/commands/do.ts`
+
+- **Renamed `formatFailureHistory` to `formatRetryHistoryForConsole`**: The function now formats retry history for console output instead of markdown files
+- **Added `TaskRetryHistory` interface**: Tracks retry information per task (taskId, taskName, failureHistory, finalAttempt, success)
+- **Added `projectRetryHistory` array**: Collects retry information during task execution for all tasks that had failures
+- **Removed `## Details` section from successful outcomes**: Claude-written outcomes are now preserved as-is without appending metadata
+- **Removed `## Failure History` from all outcome files**: No longer inserted into outcome files for either success or failure
+- **Kept `## Details` section for failed outcomes**: Still includes attempts, elapsed time, timestamp, and stash name for debugging
+- **Added retry history console output**: At the end of project execution, shows retry history for any task that had failures
+
+### 2. Updated `tests/unit/outcome-content.test.ts`
+
+- Rewrote tests to verify new behavior
+- Added tests for successful outcomes having no `## Details` or `## Failure History`
+- Added tests for failed outcomes keeping `## Details` section
+- Added tests for `formatRetryHistoryForConsole` function
+
+### 3. Updated `tests/unit/failure-history.test.ts`
+
+- Updated to test the renamed `formatRetryHistoryForConsole` function
+- Updated test expectations to match the new console output format
+- Tests verify proper indentation, task name formatting, and attempt tracking
+
+## Acceptance Criteria Verification
+
+- [x] Successful task outcomes do not contain `## Details` section
+- [x] Successful task outcomes do not contain `## Failure History` section
+- [x] Failed task outcomes still contain `## Details` section with all metadata
+- [x] Console output shows retry history for any task that had failures before completing
+- [x] All existing tests pass (725 tests)
+- [x] New/updated tests verify the behavior change
+
+## Console Output Format
+
+When tasks have retries, the output at the end of execution looks like:
+
+```
+Retry history:
+  Task 001 (my-task):
+    Attempt 1: Failed - Connection timeout
+    Attempt 2: Succeeded
+```
+
+<promise>COMPLETE</promise>
+
+
+## Details
+- Attempts: 1
+- Elapsed time: 5m 27s
+- Completed at: 2026-01-31T17:16:19.006Z

package/RAF/014-watchdog/plans/001-amend-flag-position.md

@@ -0,0 +1,34 @@
+# Task: Support --amend flag after project identifier
+
+## Objective
+Allow `--amend` flag to be used after the project identifier, in addition to the existing syntax.
+
+## Context
+Currently `raf plan --amend <identifier>` works, but users may naturally type `raf plan <identifier> --amend`. Both syntaxes should be supported for better UX.
+
+## Requirements
+- Support `raf plan <identifier> --amend` (flag after positional argument)
+- Keep existing `raf plan --amend <identifier>` working (backward compatibility)
+- The positional argument becomes the project identifier in amend mode
+- Show clear error if `--amend` is used without a project identifier
+
+## Implementation Steps
+1. Read `src/commands/plan.ts` to understand current implementation
+2. Change `--amend` option from requiring an argument (`-a, --amend <identifier>`) to a boolean flag (`-a, --amend`)
+3. Update action handler logic:
+   - If `--amend` flag is set, use the positional `projectName` argument as the identifier
+   - If positional argument is missing when `--amend` is set, show error message
+4. Update the `PlanCommandOptions` interface to make `amend` a boolean
+5. Update tests in `tests/unit/plan-command.test.ts` to cover both syntaxes
+6. Run tests to verify changes
+
+## Acceptance Criteria
+- [ ] `raf plan myproject --amend` works (opens editor for amendment)
+- [ ] `raf plan --amend myproject` still works (backward compatibility via positional arg)
+- [ ] `raf plan --amend` without identifier shows helpful error message
+- [ ] All existing tests pass
+- [ ] New tests added for both syntax variants
+
+## Notes
+- Commander.js allows boolean options with `-a, --amend` syntax (no angle brackets)
+- The positional argument `[projectName]` will serve as the identifier in amend mode

package/RAF/014-watchdog/plans/002-details-only-on-failure.md

@@ -0,0 +1,46 @@
+# Task: Remove details and failure history from successful outcomes
+
+## Objective
+Remove the `## Details` section from successful outcomes and move failure history to console output instead of outcome files.
+
+## Context
+Currently, the `## Details` section (attempts, elapsed time, timestamp) and `## Failure History` section are appended to outcome files. This adds noise to successful outcomes. Instead:
+- Successful outcomes should be clean (no metadata)
+- Failed outcomes keep `## Details` for debugging
+- Failure/retry history should appear in terminal output at the end of `raf do`
+
+## Requirements
+- Remove `## Details` section from successful task outcomes
+- Remove `## Failure History` section from all outcome files
+- Keep `## Details` section for failed task outcomes (with attempts, elapsed time, timestamp, stash name)
+- Show retry history in console output for any task that had failures (even if eventually successful)
+- Do not modify the `<promise>COMPLETE</promise>` or `<promise>FAILED</promise>` markers
+
+## Implementation Steps
+1. Read `src/commands/do.ts` to understand current outcome file generation (lines 595-730)
+2. In the success branch (around line 595):
+   - Remove the `## Details` section append
+   - Remove the `failureHistorySection` insertion into outcome file
+3. Collect retry information during task execution:
+   - Track which tasks had failures before completing
+   - Store the failure history data (task id, attempt numbers, reasons)
+4. Add summary output at end of project execution:
+   - After the completion summary, show retry history for tasks that had failures
+   - Format: "Task X: Attempt 1 failed (reason), Attempt 2 succeeded" or similar
+5. Update/add tests:
+   - `tests/unit/outcome-content.test.ts`: successful outcomes have no `## Details` or `## Failure History`
+   - `tests/unit/do-command.test.ts`: verify retry history appears in console output
+6. Run tests to verify changes
+
+## Acceptance Criteria
+- [ ] Successful task outcomes do not contain `## Details` section
+- [ ] Successful task outcomes do not contain `## Failure History` section
+- [ ] Failed task outcomes still contain `## Details` section with all metadata
+- [ ] Console output shows retry history for any task that had failures before completing
+- [ ] All existing tests pass
+- [ ] New/updated tests verify the behavior change
+
+## Notes
+- The `formatFailureHistory` function may need to be repurposed for console output
+- Consider both verbose and minimal output modes for the retry summary
+- Lines to modify are approximately 606-730 in do.ts

package/RAF/015-name-lottery/decisions.md

@@ -0,0 +1,14 @@
+# Project Decisions
+
+## For the auto-generated project names, what style should the random names follow?
+Use existing name generation with Claude - it gives a list of names, pick the first in the list automatically.
+
+## Should the --auto/-y flag also skip any other interactive prompts during planning, or just the name selection?
+Name only - only auto-select the project name, keep other prompts interactive.
+
+## For task 2 (amend prompt for 'raf do'): Where exactly should the instruction to commit plan files be added?
+Git commit section - add to the existing git commit instructions in the task execution prompt.
+
+## For task 3 (input.md handling in amend): When appending to input.md, should there be a visual separator between the original and new content?
+Just horizontal rule (---) between the original and new content.
+

package/RAF/015-name-lottery/input.md

@@ -0,0 +1,3 @@
+- [ ] if --auto or -y flag is provided - randomly select project name in the case name was not provided (raf plan -y)
+- [ ] mention in amend prompt for "raf do" that it should also commit plan files
+- [ ] during "raf plan --amend id" (amend flow) RAF overrides input.md with ammended tasks, it should rather concatanated it to input.md. make sure that as user input to claude you provide only new part of input during amend flow

package/RAF/015-name-lottery/outcomes/001-auto-pick-project-name.md

@@ -0,0 +1,31 @@
+# Outcome: Auto-pick project name with -y flag
+
+## Summary
+
+Implemented automatic project name selection when running `raf plan -y` without providing a project name.
+
+## Changes Made
+
+### Modified Files
+
+1. **src/commands/plan.ts** (lines 129-136)
+   - Added logic to check if `autoMode` is true AND no `projectName` was provided
+   - In this case, the first name from `generateProjectNames()` is automatically selected
+   - Logs the auto-selected name: `Auto-selected project name: <name>`
+   - Skips the interactive `pickProjectName()` call in auto mode
+
+2. **tests/unit/plan-command-auto-flag.test.ts**
+   - Added new test suite `auto-name selection behavior` with 2 tests:
+     - Verifies command structure supports auto-selection flow (--auto flag with optional argument)
+     - Verifies projectName argument is optional (required: false)
+
+## Acceptance Criteria Verified
+
+- [x] `raf plan -y` (no project name) auto-selects the first generated name
+- [x] `raf plan my-project -y` uses the provided name (unchanged behavior)
+- [x] `raf plan` (no -y flag) still shows the interactive picker
+- [x] Auto-selected name is logged to inform the user
+- [x] All existing tests pass (727 tests)
+- [x] New test covers the auto-select behavior
+
+<promise>COMPLETE</promise>

package/RAF/015-name-lottery/outcomes/002-mention-plan-files-in-commit.md

@@ -0,0 +1,23 @@
+# Outcome: Mention plan files in git commit instructions
+
+## Summary
+
+Updated the task execution prompt to explicitly mention that plan files should be included in git commits.
+
+## Changes Made
+
+### Modified Files
+
+1. **src/prompts/execution.ts** (line 95)
+   - Added a sub-bullet under the `git add -A` instruction
+   - New text: "This includes any new plan files in the `plans/` folder"
+   - Keeps the instruction concise and integrated with existing commit flow
+
+## Acceptance Criteria Verified
+
+- [x] Git Instructions section mentions plan files
+- [x] Instruction is clear and concise
+- [x] Does not break existing prompt structure (TypeScript compiles)
+- [x] Execution prompt unit tests pass (43 tests)
+
+<promise>COMPLETE</promise>

package/RAF/015-name-lottery/outcomes/003-fix-input-md-in-amend-flow.md

@@ -0,0 +1,44 @@
+# Outcome: Fix input.md handling in amend flow
+
+## Summary
+
+Modified the amend flow to append new task descriptions to `input.md` with a horizontal rule separator, and removed the unused `inputContent` parameter from the amend prompt.
+
+## Changes Made
+
+### Modified Files
+
+1. **src/commands/plan.ts** (lines 321-326)
+   - Added code to append new task description to `input.md` after user input is captured
+   - Uses `\n\n---\n\n` as separator between original and new content
+   - Handles edge cases: empty original content, whitespace-only content
+   - Removed `inputContent: originalInput` from `getAmendPrompt()` call
+
+2. **src/prompts/amend.ts** (line 5)
+   - Removed `inputContent: string` from `AmendPromptParams` interface
+   - This param was never used in the prompt generation (Claude reads input.md directly)
+
+3. **tests/unit/plan-command.test.ts**
+   - Updated all test cases to not pass `inputContent` parameter
+   - Fixed formatting issues from replacement
+
+4. **tests/unit/plan-command-amend-input.test.ts** (new file)
+   - Added 6 new tests for the input.md append behavior:
+     - Appending with separator to existing content
+     - Handling empty original input
+     - Handling non-existent input.md
+     - Multiple amend operations (each with separator)
+     - Trailing whitespace handling
+     - Whitespace-only content treated as empty
+
+## Acceptance Criteria Verified
+
+- [x] New task descriptions are appended to input.md (not overwriting)
+- [x] Horizontal rule (`---`) separates original from new content
+- [x] Claude receives only the new task description in the user message
+- [x] Original input.md content is preserved
+- [x] Multiple amend operations append correctly (each with separator)
+- [x] Tests cover the append behavior (6 new tests)
+- [x] All existing tests pass (733 tests total)
+
+<promise>COMPLETE</promise>

package/RAF/015-name-lottery/plans/001-auto-pick-project-name.md

@@ -0,0 +1,38 @@
+# Task: Auto-pick project name with -y flag
+
+## Objective
+When `raf plan -y` is run without a project name, automatically pick the first generated name instead of prompting the user.
+
+## Context
+The `-y`/`--auto` flag currently only skips Claude's permission prompts for file operations. Users want it to also skip the interactive name picker when no project name is explicitly provided, making the planning flow fully automated.
+
+## Requirements
+- When `-y`/`--auto` flag is set AND no project name is provided:
+  - Generate name suggestions using the existing `generateProjectNames()` function
+  - Automatically select the first name from the list (no user interaction)
+  - Log which name was auto-selected
+- When `-y` flag is NOT set OR a project name IS provided:
+  - Behavior remains unchanged (use existing logic)
+- User feedback should be provided about the auto-selected name
+
+## Implementation Steps
+1. Read `src/commands/plan.ts` to understand the current flow
+2. In `runPlanCommand()` (around lines 122-129), modify the name generation logic:
+   - Check if `autoMode` is true AND no `projectName` was provided
+   - If so, generate names with `generateProjectNames()` and take the first one
+   - Log the auto-selected name (e.g., "Auto-selected project name: xyz")
+   - Skip the call to `pickProjectName()` in this case
+3. Add a test case for auto-name selection in the plan command tests
+
+## Acceptance Criteria
+- [ ] `raf plan -y` (no project name) auto-selects the first generated name
+- [ ] `raf plan my-project -y` uses the provided name (unchanged behavior)
+- [ ] `raf plan` (no -y flag) still shows the interactive picker
+- [ ] Auto-selected name is logged to inform the user
+- [ ] All existing tests pass
+- [ ] New test covers the auto-select behavior
+
+## Notes
+- The `generateProjectNames()` function returns 3-5 names; we just need the first one
+- Fallback behavior already exists in `generateProjectNames()` if Claude fails
+- File: `src/commands/plan.ts`, function: `runPlanCommand()`