rafcode 2.5.1 → 3.2.1

package/RAF/38-dual-wielder/plans/3-implement-codex-runner.md

@@ -0,0 +1,94 @@
+---
+effort: high
+---
+# Task: Implement Codex Runner
+
+## Objective
+Implement `CodexRunner` that wraps the Codex CLI (`codex` binary) with the same interface as `ClaudeRunner`.
+
+## Context
+With the runner interface extracted in task 2, we can now implement the Codex-specific runner. Codex CLI has different flags, output formats, and interaction patterns than Claude CLI. Key differences:
+- Non-interactive: `codex exec --full-auto --json` (vs Claude's `-p --output-format stream-json`)
+- Interactive: `codex` TUI via PTY (vs Claude's PTY)
+- No `--system-prompt` flag — system prompt must be prepended to user message
+- JSONL output with different event types (CommandExecution, FileChange, AgentMessage, etc.)
+- Model flag: `-m` (vs `--model`)
+- Permission bypass: `--full-auto` (vs `--dangerously-skip-permissions`)
+
+## Dependencies
+1, 2
+
+## Requirements
+- Implement `CodexRunner` class implementing `ICliRunner`
+- Handle system prompt by prepending it to the user message
+- Parse Codex JSONL events into the shared `RunResult` format
+- Support both interactive (PTY) and non-interactive (exec) modes
+- Discover `codex` binary via `which codex`
+- Build correct CLI arguments for Codex
+- Stream renderer for Codex JSONL events (separate from Claude's stream-renderer)
+
+## Implementation Steps
+
+1. **Create `src/parsers/codex-stream-renderer.ts`**:
+   - Parse Codex JSONL events (one JSON object per line)
+   - Map Codex event types to `RenderResult` (same interface as Claude's renderer):
+     - `AgentMessage` → text content + display
+     - `CommandExecution` → tool display (show command + exit code)
+     - `FileChange` → tool display (show file path + change kind)
+     - `McpToolCall` → tool display
+     - `TodoList` → skip or minimal display
+   - Extract any usage/cost data from Codex events if available
+   - Export `renderCodexStreamEvent(line: string): RenderResult`
+
+2. **Create `src/core/codex-runner.ts`**:
+   - Implement `ICliRunner` interface
+   - `getCodexPath()`: `execSync('which codex', ...)`
+   - Constructor takes `RunnerConfig` (model, provider)
+
+3. **Implement `runInteractive()`**:
+   - Spawn `codex` (no `exec` subcommand) via PTY
+   - Build args: `-m <model>`
+   - Combine system prompt and user message: `"[System Instructions]\n\n{systemPrompt}\n\n[User Request]\n\n{userMessage}"`
+   - Pass combined message as positional argument
+   - Handle PTY stdin/stdout passthrough (same pattern as ClaudeRunner)
+   - Handle cleanup on exit
+
+4. **Implement `run()` / `runVerbose()` (non-interactive execution)**:
+   - Spawn: `codex exec --full-auto --json -m <model> <combined_prompt>`
+   - Build the combined prompt (system + user prompt prepended)
+   - Parse JSONL stdout line by line using `renderCodexStreamEvent()`
+   - Accumulate text content for output
+   - Apply timeout logic (same pattern as ClaudeRunner)
+   - Use shared completion detector for outcome file monitoring
+   - Return `RunResult` with output, exitCode, timedOut, contextOverflow
+
+5. **Implement `runResume()`**:
+   - Throw `Error('Session resume is not supported by Codex CLI')`
+
+6. **Implement `kill()` and `isRunning()`**:
+   - Same pattern as ClaudeRunner (Ctrl+C via PTY write, SIGTERM fallback)
+
+7. **Update `src/core/runner-factory.ts`**:
+   - Import `CodexRunner`
+   - Return `new CodexRunner(config)` for `provider: 'codex'`
+
+8. **Handle Codex-specific edge cases**:
+   - Codex may not report token usage in the same way — handle missing usage data gracefully
+   - Codex `--json` output might include events we don't care about — filter/skip unknown types
+   - `--ephemeral` flag to avoid session persistence pollution
+
+## Acceptance Criteria
+- [ ] `CodexRunner` implements `ICliRunner` fully
+- [ ] `codex exec` spawns correctly with proper flags
+- [ ] System prompt is prepended to user message correctly
+- [ ] JSONL events are parsed and displayed properly in verbose mode
+- [ ] Interactive mode works via PTY
+- [ ] Timeout and completion detection work
+- [ ] `createRunner({ provider: 'codex' })` returns a working CodexRunner
+- [ ] TypeScript compiles without errors
+
+## Notes
+- Test by running `raf do <project> --provider codex` once integrated
+- Codex may not provide `total_cost_usd` in the same format — handle gracefully with zeros
+- The combined prompt approach (prepending system prompt) means Codex sees one large message. This is simpler but less structured than Claude's separate system prompt. It was chosen for simplicity per user decision.
+- Use `--ephemeral` flag in non-interactive mode to keep things clean

package/RAF/38-dual-wielder/plans/4-update-prompts-llm-agnostic.md

@@ -0,0 +1,70 @@
+---
+effort: medium
+---
+# Task: Update Prompts to be LLM-Agnostic
+
+## Objective
+Remove Claude-specific language from all prompt templates so they work with any LLM provider.
+
+## Context
+The prompts in `src/prompts/` contain Claude-specific references like "Claude Code", "Claude CLI", "Claude session", and "Claude model". These need to be made generic since the prompts will now be sent to either Claude or Codex.
+
+## Dependencies
+1
+
+## Requirements
+- Replace Claude-specific references in all prompt files with generic alternatives
+- Update the execution prompt, planning prompt, and amend prompt
+- Keep the prompts' functional content identical — only change naming/branding
+- Update any log messages that reference "Claude" in the runner and command files
+
+## Implementation Steps
+
+1. **Update `src/prompts/execution.ts`**:
+   - Replace "Claude" references in prompt text with generic terms
+   - `"You are executing a planned task for RAF"` — already generic, keep as-is
+   - Check for any Claude-specific tool names or behaviors mentioned in the prompt
+
+2. **Update `src/prompts/planning.ts`**:
+   - `"Take roughly 10-30 minutes of work for Claude"` → `"Take roughly 10-30 minutes of work"`
+   - `"which Claude model will execute the task"` → `"which model will execute the task"`
+   - Review entire planning prompt for Claude-specific language
+
+3. **Update `src/prompts/amend.ts`**:
+   - Same treatment as planning prompt
+   - `"which Claude model will execute the task"` → `"which model will execute the task"`
+
+4. **Update log messages in `src/core/claude-runner.ts`**:
+   - `"Starting interactive Claude session"` → `"Starting interactive session"` or include provider name dynamically
+   - `"Starting Claude execution session"` → `"Starting execution session"`
+   - `"Claude session timed out"` → `"Session timed out"`
+   - `"terminating Claude process"` → `"terminating process"`
+   - `"Claude exited with code"` → `"Process exited with code"`
+   - `"Claude stderr"` → `"Process stderr"`
+
+5. **Update `src/core/pull-request.ts`**:
+   - `callClaudeForPrBody` → `callLlmForPrBody` (or keep internal name, just update error messages)
+   - `"Claude CLI not found"` → make provider-aware or generic
+
+6. **Update `src/index.ts`**:
+   - `.description('RAF - Automated Task Planning & Execution with Claude Code')` → `'RAF - Automated Task Planning & Execution'`
+
+7. **Update `src/parsers/stream-renderer.ts`** doc comments:
+   - `"Event types from claude -p --output-format stream-json --verbose"` → make generic or note it's Claude-specific
+
+8. **Scan for remaining references**:
+   - Search entire `src/` for strings containing "claude" (case-insensitive)
+   - Skip: file names that will be addressed by the runner refactoring, type names with backward-compat re-exports
+   - Update any user-facing messages, error messages, and comments
+
+## Acceptance Criteria
+- [ ] No user-facing prompt text mentions "Claude" specifically
+- [ ] Log messages are provider-generic or include provider name dynamically
+- [ ] CLI description is LLM-agnostic
+- [ ] All prompts still function correctly (no broken templates)
+- [ ] TypeScript compiles without errors
+
+## Notes
+- Internal code comments mentioning "Claude" are lower priority but should be updated where easy
+- File names like `claude-runner.ts` don't need to change — they're internal implementation files for the Claude provider
+- The planning prompt is also used as the system prompt for this very planning session, but that's fine — it's a template, not a runtime concern

package/RAF/38-dual-wielder/plans/5-update-readme-docs.md

@@ -0,0 +1,52 @@
+---
+effort: low
+---
+# Task: Update README and Documentation
+
+## Objective
+Update README.md to reflect multi-provider support, new config options, and the `--provider` CLI flag.
+
+## Context
+The README currently describes RAF as a Claude Code-only tool. With Codex support added, documentation needs to reflect the dual-provider capability.
+
+## Dependencies
+1, 2, 3, 4
+
+## Requirements
+- Document the `provider` config field and `--provider` CLI flag
+- Document harness-prefixed model format (`claude/opus`, `codex/gpt-5.4`)
+- Document Codex-specific configuration (codexModels, codexEffortMapping)
+- Update existing examples that reference Claude-only setup
+- Keep README concise — don't over-document
+
+## Implementation Steps
+
+1. **Update the project description** at the top of README.md:
+   - Mention support for both Claude Code CLI and OpenAI Codex CLI
+
+2. **Add a Provider Configuration section**:
+   - Explain `provider` config field (default: `claude`)
+   - Show `--provider codex` CLI usage
+   - Explain model prefix format with examples
+
+3. **Update the Configuration section**:
+   - Add `codexModels` and `codexEffortMapping` to config example
+   - Show harness-prefixed model examples
+
+4. **Update command examples**:
+   - Add `--provider` flag to `raf do` and `raf plan` examples
+   - Show mixed provider usage
+
+5. **Note limitations**:
+   - Codex doesn't support `--resume` (session resume)
+   - System prompt is prepended to user message for Codex
+
+## Acceptance Criteria
+- [ ] README reflects multi-provider support
+- [ ] New config fields are documented
+- [ ] `--provider` flag is documented for relevant commands
+- [ ] Existing documentation is updated (not just appended)
+
+## Notes
+- Keep the README focused on usage, not implementation details
+- Don't document internal architecture changes (runner interface, etc.)

package/RAF/38-dual-wielder/plans/6-do-unified-project-scanning.md

@@ -0,0 +1,40 @@
+---
+effort: medium
+---
+# Task: Unified Project Scanning in `raf do` Worktree Mode
+
+## Objective
+Make `raf do --worktree` show both worktree and main-repo projects in the interactive picker, instead of only worktree projects.
+
+## Context
+Currently, `raf do` has two scanning modes:
+- **Standard mode**: scans both main-repo and worktree projects (via `pickPendingProject()` + `getPendingWorktreeProjects()`)
+- **Worktree mode** (`--worktree`): only scans worktree projects (via `discoverAndPickWorktreeProject()`)
+
+This is confusing — users expect to see all pending projects regardless of where they live. The fix should make worktree mode also show main-repo projects.
+
+## Requirements
+- In worktree mode, the project picker should show both worktree AND main-repo pending projects
+- When a project exists in both main repo and worktree, the worktree version takes precedence (dedup)
+- The existing threshold filter logic in `discoverAndPickWorktreeProject()` should still apply to worktree projects
+- Main-repo projects should be clearly distinguishable from worktree projects in the picker (if they aren't already)
+- When a main-repo project is selected in worktree mode, the existing worktree creation flow should kick in as normal
+
+## Implementation Steps
+1. Read `src/commands/do.ts` — focus on `discoverAndPickWorktreeProject()` (lines ~659-770) and the standard mode picker logic (lines ~270-299)
+2. Read `src/ui/project-picker.ts` — understand `getPendingWorktreeProjects()` and `pickPendingProject()` and how dedup works
+3. Modify `discoverAndPickWorktreeProject()` to also discover main-repo pending projects using existing utilities
+4. Merge the two lists with worktree versions taking precedence on duplicates
+5. Update the picker display if needed to indicate project source (worktree vs main)
+6. Test the flow manually to ensure both project types appear
+
+## Acceptance Criteria
+- [ ] `raf do --worktree` shows pending projects from both worktree and main repo
+- [ ] Duplicate projects are deduped with worktree version taking precedence
+- [ ] Selecting a main-repo project in worktree mode correctly creates/uses a worktree
+- [ ] Existing worktree-only scanning behavior is replaced by unified scanning
+- [ ] No regressions in standard (non-worktree) mode
+
+## Notes
+- The standard mode already has this merging logic — reuse it rather than reimplementing
+- Be careful with the threshold filter — it should only apply to worktree project filtering, not main-repo projects

package/RAF/38-dual-wielder/plans/7-fix-plan-amend-automode.md

@@ -0,0 +1,51 @@
+---
+effort: medium
+---
+# Task: Fix Plan Amend Prompt and Add Numeric ID Resolution
+
+## Objective
+Fix the bug where `raf plan -y <project-name>` skips the existing project check, and add numeric ID resolution to both the auto-detect prompt and the explicit `--amend` flag.
+
+## Context
+This is a follow-up fix to a previously implemented feature. Two issues:
+
+1. **Auto mode bypass**: The amend prompt (plan.ts lines ~118-161) correctly detects existing projects in both main repo and worktrees, and offers to amend. However, the entire check is gated by `!autoMode`, so running `raf plan -y dual-wielder` when a project named "dual-wielder" already exists will silently create a new project instead of amending.
+
+2. **Numeric ID not supported**: Neither the auto-detect flow nor the explicit `--amend` flag resolve numeric project IDs. `raf plan --amend 38` or `raf plan 38` should find project `38-dual-wielder` and work correctly.
+
+The specific failing case: `raf-dev plan -y dual-wielder` opened fresh planning instead of amending the existing worktree project "dual-wielder".
+
+## Requirements
+- The existing project name check must run even when `-y` (auto mode) is active
+- When an existing project is found in auto mode, the tool should still prompt the user (breaking out of auto mode for this safety check) — silently creating a duplicate would be worse than interrupting auto mode
+- The check should cover both main-repo and worktree projects (it already does, just needs the `!autoMode` gate removed)
+- `raf plan --amend 38` should resolve numeric ID `38` to the matching project in both main-repo and worktrees
+- `raf plan 38` (without --amend) should also detect the existing project by numeric ID and prompt to amend
+- Numeric ID resolution should use the existing `resolveProjectIdentifierWithDetails()` and `resolveWorktreeProjectByIdentifier()` utilities which already support numeric prefix matching
+
+## Implementation Steps
+1. Read `src/commands/plan.ts` — focus on:
+   - The auto mode guard around line 118: `if (projectName && !autoMode)`
+   - The `--amend` flag handling and how it resolves project identifiers
+   - The `runAmendCommand()` function
+2. Read `src/utils/paths.ts` — understand `resolveProjectIdentifierWithDetails()` which already supports numeric prefix matching
+3. Read `src/core/worktree.ts` — understand `resolveWorktreeProjectByIdentifier()` which also supports numeric matching
+4. Remove the `!autoMode` condition so the existing project check runs regardless of mode
+5. Update the auto-detect check to use `resolveProjectIdentifierWithDetails()` (which handles numeric IDs) instead of any name-only matching
+6. Update the `--amend` flag handling to accept numeric IDs, using the same resolution utilities
+7. Ensure resolution checks both main-repo and worktree projects for both flows
+
+## Acceptance Criteria
+- [ ] `raf plan -y <existing-project-name>` detects the existing project and prompts to amend
+- [ ] `raf plan -y <numeric-id>` (e.g., `raf plan -y 38`) detects the existing project and prompts to amend
+- [ ] `raf plan --amend <numeric-id>` resolves the project correctly and enters amend mode
+- [ ] `raf plan --amend <project-name>` continues to work as before
+- [ ] Resolution checks both main-repo and worktree projects in all cases
+- [ ] If user selects "amend", the amend flow runs correctly
+- [ ] If user selects "create new", a new project is created as before
+- [ ] Non-auto-mode behavior is unchanged
+
+## Notes
+- The resolution utilities (`resolveProjectIdentifierWithDetails`, `resolveWorktreeProjectByIdentifier`) already support numeric prefix matching — reuse them rather than adding custom logic
+- The safety prompt intentionally breaks auto mode — duplicating a project name is almost always a mistake
+- Effort bumped to medium since this touches both the auto-detect and --amend flows with ID resolution logic

package/RAF/38-dual-wielder/plans/8-e2e-test-codex-provider.md

@@ -0,0 +1,95 @@
+---
+effort: high
+---
+# Task: E2E Test Codex Provider
+
+## Objective
+Verify the Codex provider integration works end-to-end by running `raf-dev plan` and `raf-dev do` with `--provider codex` against a dummy Node.js project, documenting all issues found.
+
+## Context
+This is a follow-up to task 3 (implement-codex-runner). See outcome: /Users/eremeev/projects/RAF/RAF/38-dual-wielder/outcomes/3-implement-codex-runner.md
+
+Tasks 1-4 added Codex support (config schema, abstract runner, CodexRunner implementation, LLM-agnostic prompts) but none of this has been tested E2E against a real project. This task validates the full integration.
+
+## Dependencies
+3
+
+## Requirements
+- Create a simple dummy Node.js project to use as a test target
+- Run `raf-dev plan` and `raf-dev do` with `--provider codex` and verify real behavior
+- Use `raf-dev` (not `raf`) for all testing — this is the development binary
+- Test all major scenarios: planning, execution, config/model resolution, error handling
+- Document all issues found in the outcome — do NOT auto-create fix tasks
+- Sequential testing is fine (no need for parallel agents)
+
+## Implementation Steps
+
+### Phase 1: Set up dummy project
+
+1. Create a temporary dummy Node.js project folder (e.g., `/tmp/raf-codex-test-project/`) with:
+   - `package.json` with a name and basic scripts
+   - `src/index.ts` — a small file with a few intentional TODOs or bugs (e.g., a function that doesn't handle edge cases)
+   - `tsconfig.json` — basic TypeScript config
+   - Initialize a git repo in it (`git init && git add . && git commit`)
+2. The project should be simple enough that an LLM can meaningfully plan and execute tasks against it
+
+### Phase 2: Test `raf-dev plan --provider codex`
+
+3. Run `raf-dev plan --provider codex` targeting the dummy project
+   - Provide a simple input like "add input validation to the exported functions"
+   - Verify: Does the PTY spawn correctly? Does Codex receive the prompt?
+   - Verify: Are plan files generated with correct frontmatter?
+   - Verify: Does the interactive planning session complete without crashes?
+4. Check the generated plan files — are they well-formed? Do they have the expected structure?
+
+### Phase 3: Test `raf-dev do --provider codex`
+
+5. Run `raf-dev do --provider codex` on the planned project
+   - Verify: Does task execution start correctly?
+   - Verify: Is the `codex exec --full-auto --json --ephemeral` command constructed properly?
+   - Verify: Does JSONL stream output display correctly in verbose mode?
+   - Verify: Does completion detection work (outcome file, commit verification)?
+   - Verify: Does the task complete and produce an outcome file?
+6. Check the outcome files and any commits made — are they correct?
+
+### Phase 4: Test config/model resolution
+
+7. Test that `--provider codex` correctly overrides the default provider in config
+8. Test effort-based model resolution for codex:
+   - A plan with `effort: low` should use `gpt-5.3-codex-spark`
+   - A plan with `effort: medium` should use `gpt-5.3-codex`
+   - A plan with `effort: high` should use `gpt-5.4`
+9. Test explicit model override in plan frontmatter (e.g., `model: codex/gpt-5.4`)
+
+### Phase 5: Test error handling and edge cases
+
+10. Test what happens when `codex` binary is not in PATH (temporarily rename or use a bad path)
+11. Test timeout behavior — does a long-running task get terminated correctly?
+12. Test that `runResume` correctly throws "not supported" for Codex
+13. Test behavior with malformed/unexpected Codex output
+14. Verify that usage data being `undefined` for Codex doesn't break any display or logging code
+
+### Phase 6: Document results
+
+15. Create a comprehensive outcome document listing:
+    - Each scenario tested and its result (PASS/FAIL)
+    - Detailed description of any failures or unexpected behavior
+    - Severity assessment for each issue (critical/major/minor)
+    - Suggested fixes for each issue found
+
+## Acceptance Criteria
+- [ ] Dummy Node.js project created and initialized with git
+- [ ] `raf-dev plan --provider codex` tested and results documented
+- [ ] `raf-dev do --provider codex` tested and results documented
+- [ ] Config/model resolution tested for codex provider
+- [ ] Error handling and edge cases tested
+- [ ] Comprehensive outcome document listing all issues found with severity
+
+## Notes
+- This task requires the `codex` CLI to be installed and available in PATH
+- If Codex CLI is not available, document that as the first finding and test what you can without it (e.g., error handling for missing binary, config resolution logic)
+- Focus on documenting issues clearly — the user will decide what to fix based on the outcome
+- When testing interactively (raf-dev plan), you may need to provide input via the PTY — document any difficulties with this
+- Check `src/core/codex-runner.ts` for the actual command construction to verify correctness
+- Check `src/core/runner-factory.ts` to verify provider routing
+- Check `src/utils/config.ts` for model resolution logic

package/RAF/39-pathless-rover/decisions.md

@@ -0,0 +1,16 @@
+# Project Decisions
+
+## Should the JSONL stream renderer support both old and new event formats, or replace entirely?
+The "old" format is not old — it's the Claude event format. The renderer should add Codex-specific event handling (item.completed, turn.completed, etc.) alongside the existing Claude event handling. Claude should continue to work as before.
+
+## For removing --worktree: when creating a NEW project with raf plan, should it always create a worktree or use config default?
+Config default. --worktree and --no-worktree flags should STILL be supported for `raf plan` (new project creation). They determine where the new project will be created. But for --amend and auto-amend flows, the flag should be removed — auto-detect where the project lives.
+
+## For raf plan --amend: if project exists in main but not worktree, auto-create worktree or amend in-place?
+Amend in-place. Follow where the project lives — if in main repo, amend there; if in worktree, amend there.
+
+## For raf do: just remove --worktree/--no-worktree flags, or deeper refactor?
+Just remove flags. The existing auto-detection logic already scans both worktree and main. Just remove the CLI flags and let auto-detection be the only path.
+
+## Should auto-amend detection (name collision in raf plan) scan worktrees too?
+Yes, scan both main repo and worktrees for name collisions during auto-amend detection.

package/RAF/39-pathless-rover/input.md

@@ -0,0 +1,2 @@
+fix all issues in RAF/38-dual-wielder/outcomes/8-e2e-test-codex-provider.md
+- [ ] raf do should be agnostic of --migration flag, scan worktree and main. remove --worktree entirely. same for --amend flow in raf plan. basically

package/RAF/39-pathless-rover/outcomes/1-fix-codex-stream-renderer.md

@@ -0,0 +1,21 @@
+# Task 1: Fix Codex JSONL Stream Renderer
+
+## Summary
+Updated `codex-stream-renderer.ts` to handle the real Codex CLI event format (nested `item.completed` events) while preserving existing Claude flat-format handlers.
+
+## Changes Made
+
+### File: `src/parsers/codex-stream-renderer.ts`
+- Extended `CodexEvent` interface with `item` (nested object), `message`, and `usage` fields
+- Added `item.completed` handler that dispatches on `item.type`: `agent_message`, `command_execution`, `file_change`
+- Added `item.started` handler (no-op, renders on completion)
+- Added `turn.completed` handler that extracts and displays usage data
+- Added `error` handler — outputs error message in both `display` and `textContent`
+- Added `turn.failed` handler — outputs failure message in both `display` and `textContent`
+- All existing Claude-format handlers (`AgentMessage`, `CommandExecution`, `FileChange`, `McpToolCall`, `TodoList`) remain untouched
+
+## Verification
+- TypeScript compiles without errors (`npm run build`)
+- All acceptance criteria met
+
+<promise>COMPLETE</promise>

package/RAF/39-pathless-rover/outcomes/2-wire-provider-flag.md

@@ -0,0 +1,28 @@
+# Task 2: Wire --provider CLI Flag Through to Runner and Model Resolution
+
+## Summary
+Wired the inert `--provider` CLI flag through to `createRunner()` and `resolveEffortToModel()` in both `do.ts` and `plan.ts`, so that `--provider codex` actually creates a `CodexRunner` and uses the codex effort mapping.
+
+## Changes Made
+
+### File: `src/commands/do.ts`
+- Added `provider` field to `SingleProjectOptions` interface
+- Pass `options.provider` through `executeSingleProject` to the task execution loop
+- Updated `resolveTaskModel()` to accept an optional `provider` parameter and pass it to `resolveEffortToModel()`
+- Pass `provider` to `createRunner({ model, provider })` in the task retry loop
+
+### File: `src/commands/plan.ts`
+- Read `options.provider` in the action handler
+- Pass `provider` through to `runPlanCommand()`, `runAmendCommand()`, and `runResumeCommand()`
+- Pass `provider` to all three `createRunner({ model, provider })` call sites
+- Pass `provider` through the duplicate-project amend redirect flow
+
+## Verification
+- TypeScript compiles without errors (`npm run build`)
+- All acceptance criteria met:
+  - `raf do --provider codex` will create a `CodexRunner` (provider flows to `createRunner`)
+  - `raf plan --provider codex` will create a `CodexRunner` for planning sessions
+  - `resolveEffortToModel` receives the provider param for codex effort mapping
+  - TypeScript compiles cleanly
+
+<promise>COMPLETE</promise>

package/RAF/39-pathless-rover/outcomes/3-remove-worktree-flag-do.md

@@ -0,0 +1,41 @@
+# Task 3: Remove --worktree Flag from raf do — Auto-detect Project Location
+
+## Summary
+Removed `--worktree` and `--no-worktree` CLI flags from `raf do`. Project location (worktree vs main repo) is now always auto-detected. The combined picker and worktree-first resolution are the only code paths.
+
+## Changes Made
+
+### File: `src/commands/do.ts`
+- Removed `-w, --worktree` and `--no-worktree` option lines from `createDoCommand()`
+- Removed `worktreeMode` variable and all assignments to it
+- Removed the early `if (worktreeMode)` block that did worktree-specific setup — the combined picker flow now handles both worktree and main projects
+- Replaced `if (worktreeMode)` in resolution with `if (worktreeRoot)` — when the picker sets worktreeRoot, resolve within that worktree; otherwise auto-detect (worktree first, then main)
+- Moved main branch sync (`pullMainBranch`) to after project resolution, triggered by `worktreeRoot` being set
+- Replaced `worktreeMode && worktreeRoot` guards with just `worktreeRoot`
+- Removed unused `discoverAndPickWorktreeProject` function
+- Cleaned up unused imports: `getWorktreeDefault`, `discoverProjects`, `formatProjectChoice`, `computeWorktreePath`, `computeWorktreeBaseDir`, `validateWorktree`, `listWorktreeProjects`
+
+### File: `src/types/config.ts`
+- Removed `worktree?: boolean` from `DoCommandOptions` interface
+
+### File: `src/commands/plan.ts`
+- Removed `--worktree` from `raf do` suggestions in user-facing log messages (2 locations)
+
+### File: `src/prompts/planning.ts`
+- Removed `worktreeFlag` variable and `worktreeMode` destructuring — `raf do` instruction no longer includes `--worktree`
+
+### File: `src/prompts/amend.ts`
+- Removed `worktreeFlag` variable and `worktreeMode` destructuring — `raf do` instruction no longer includes `--worktree`
+
+### File: `src/prompts/config-docs.md`
+- Updated `worktree` config description to note that `raf do` auto-detects regardless of this setting
+
+## Verification
+- TypeScript compiles without errors (`npm run build`)
+- All acceptance criteria met:
+  - `raf do` CLI no longer accepts `--worktree` or `--no-worktree`
+  - `raf do` (no args) shows combined picker of worktree + main projects
+  - `raf do <project>` auto-detects if project is in worktree or main
+  - Post-execution worktree actions (merge/PR/leave) still work correctly (triggered by `worktreeRoot`)
+
+<promise>COMPLETE</promise>

package/RAF/39-pathless-rover/outcomes/4-remove-worktree-flag-plan-amend.md

@@ -0,0 +1,30 @@
+# Task 4: Remove --worktree Flag from raf plan --amend — Auto-detect Project Location
+
+## Summary
+Modified `runAmendCommand` to auto-detect whether a project lives in a worktree or main repo, removing the `worktreeMode` parameter. The `--worktree`/`--no-worktree` flags remain on the `plan` command for new project creation only.
+
+## Changes Made
+
+### File: `src/commands/plan.ts`
+- Removed `worktreeMode` parameter from `runAmendCommand` signature
+- Replaced the complex worktree-mode branch (manual worktree scanning, branch recreation, fresh worktree creation with file copying) with simple auto-detection: try `resolveWorktreeProjectByIdentifier()` first, fall back to `resolveProjectIdentifierWithDetails()` in main repo
+- Updated both call sites (explicit `--amend` at line ~104 and auto-amend at line ~158) to no longer pass `worktreeMode`
+- Removed `existingWorktreeMode` variable from auto-amend detection flow
+- Removed redundant if/else for `raf do` suggestion (both branches were identical)
+- Simplified `worktreeMode && worktreePath` guard to just `worktreePath`
+- Removed `worktreeMode` from `getAmendPrompt()` call
+- Cleaned up unused imports: `createWorktreeFromBranch`, `branchExists`, `computeWorktreeBaseDir`
+
+### File: `src/prompts/amend.ts`
+- Removed `worktreeMode?: boolean` from `AmendPromptParams` interface
+
+## Verification
+- TypeScript compiles without errors (`npm run build`)
+- All acceptance criteria met:
+  - `raf plan myproject --amend` finds project in worktree without needing `--worktree` flag
+  - `raf plan myproject --amend` finds project in main repo without needing `--no-worktree` flag
+  - `raf plan myproject` (name collision) detects projects in both worktree and main
+  - `--worktree`/`--no-worktree` flags still work for new project creation
+  - TypeScript compiles without errors
+
+<promise>COMPLETE</promise>

package/RAF/39-pathless-rover/outcomes/5-update-prompts-and-docs.md

@@ -0,0 +1,26 @@
+# Task 5: Update Prompts, Docs, and Config Docs for Removed --worktree Flag
+
+## Summary
+Updated README.md to remove stale `--worktree` references for `raf do`. The `raf plan` command still supports `--worktree` for new project creation, so those references were preserved.
+
+## Changes Made
+
+### File: `README.md`
+- Removed `raf do --worktree` and `raf do my-feature -w` examples from the `raf do` usage block
+- Updated "Basic workflow" in Worktree Mode section: `raf do my-feature --worktree` → `raf do my-feature` with note "(auto-detected, no flag needed)"
+- Added bullet in "How it works" section: `raf do` auto-detects whether a project lives in a worktree — no `--worktree` flag needed
+- Clarified `--no-worktree` bullet to specify it applies to `raf plan` (not `raf do`)
+- Removed `-w, --worktree` and `--no-worktree` rows from `raf do` command reference table
+
+## No Changes Needed
+- `src/prompts/planning.ts` — already cleaned up in Task 3
+- `src/prompts/amend.ts` — already cleaned up in Task 3
+- `src/prompts/config-docs.md` — already accurate (references are specific to `raf plan --worktree`, which still has the flag)
+- `src/commands/do.ts` — already cleaned up in Task 3
+
+## Verification
+- TypeScript compiles without errors (`npm run build`)
+- All remaining `--worktree` references are scoped to `raf plan` (still valid)
+- No stale `--worktree` references for `raf do` or `raf plan --amend`
+
+<promise>COMPLETE</promise>

package/RAF/39-pathless-rover/plans/1-fix-codex-stream-renderer.md

@@ -0,0 +1,43 @@
+---
+effort: medium
+---
+# Task: Fix Codex JSONL Stream Renderer for Real Event Format
+
+## Objective
+Update the Codex stream renderer to handle the actual event format emitted by Codex CLI, while preserving existing Claude event handling.
+
+## Context
+The Codex CLI emits events in a nested format (`item.completed` with `item.type` sub-fields) but the renderer expects flat event types (`AgentMessage`, `CommandExecution`). This causes all Codex output to be silently dropped. The existing flat event types are used by Claude's renderer and must be preserved — this is NOT an "old" format, it's the Claude format.
+
+## Requirements
+- Handle real Codex CLI event types: `item.completed`, `item.started`, `turn.completed`, `error`, `turn.failed`
+- For `item.completed`, dispatch on `item.type`: `agent_message` (text in `item.text`), `command_execution` (command in `item.command`), `file_change`
+- Handle `error` and `turn.failed` events — capture error messages in both `display` and `textContent`
+- Extract usage data from `turn.completed` events if available
+- Keep existing `AgentMessage`, `CommandExecution`, `FileChange`, `McpToolCall`, `TodoList` handlers intact — these are for Claude
+- Update the `CodexEvent` interface to model the real nested event structure
+
+## Implementation Steps
+1. Read `src/parsers/codex-stream-renderer.ts` to understand current structure
+2. Update the `CodexEvent` interface to include nested item structure:
+   - Add `item?: { type: string; text?: string; command?: string; exit_code?: number; path?: string; ... }`
+   - Add fields for `error`, `turn.failed`, `turn.completed` events
+3. Add new cases to the switch statement for real Codex event types:
+   - `item.completed` → check `event.item.type` and dispatch to appropriate renderer
+   - `item.started` → optionally render (or skip)
+   - `turn.completed` → extract usage data if present
+   - `error` → render error message in both display and textContent
+   - `turn.failed` → render failure message in both display and textContent
+4. Keep all existing cases (`AgentMessage`, `CommandExecution`, etc.) untouched
+5. Build and verify no type errors
+
+## Acceptance Criteria
+- [ ] Real Codex `item.completed` events with `agent_message` type produce text output
+- [ ] Real Codex `item.completed` events with `command_execution` type show command status
+- [ ] `error` and `turn.failed` events produce visible error output in both display and textContent
+- [ ] Existing Claude event handlers (`AgentMessage`, `CommandExecution`, etc.) continue to work unchanged
+- [ ] TypeScript compiles without errors
+
+## Notes
+- Reference the outcomes file at `RAF/38-dual-wielder/outcomes/8-e2e-test-codex-provider.md` for exact real event JSON samples
+- The `RenderResult` interface from `stream-renderer.ts` is the return type — keep using it