rafcode 3.2.1 → 3.8.0

package/RAF/43-swiss-army/plans/6-add-fast-mode.md

@@ -0,0 +1,46 @@
+---
+effort: high
+---
+# Task: Add Fast Mode to Model Config
+
+## Objective
+Extend ModelEntry with a `fast: boolean` option and wire it to Claude and Codex CLI invocations.
+
+## Context
+Claude Code supports a "fast mode" that uses the same model with faster output. Codex may have similar options. This should be configurable per model entry so users can have fast planning but thorough execution.
+
+## Dependencies
+1, 3
+
+## Requirements
+- Add `fast?: boolean` to the ModelEntry interface in `src/types/config.ts`
+- Research how to pass fast mode to Claude CLI (likely `--fast` flag or similar)
+- Research how to pass fast mode to Codex CLI
+- Wire the fast flag in both ClaudeRunner and CodexRunner
+- Only pass the flag when `fast: true` is set
+- Update config validation to accept the new field
+- Update config-docs.md with fast mode documentation
+- Default to false/omitted (not fast)
+
+## Implementation Steps
+1. Search the web for how Claude Code CLI accepts fast mode (check `claude --help` or docs)
+2. Search the web for how Codex CLI accepts fast/speed options
+3. Read `src/types/config.ts` — add `fast?: boolean` to ModelEntry interface
+4. Read `src/utils/config.ts` — add validation for the `fast` field (boolean type check)
+5. Read `src/core/claude-runner.ts` — add the fast flag to CLI args when `fast: true`
+6. Read `src/core/codex-runner.ts` — add the fast flag to CLI args when `fast: true`
+7. Update `src/prompts/config-docs.md` — document the fast option
+8. Update DEFAULT_CONFIG if fast should have a default value (probably omit = not fast)
+
+## Acceptance Criteria
+- [ ] ModelEntry interface includes `fast?: boolean`
+- [ ] Claude CLI invocations include the fast flag when configured
+- [ ] Codex CLI invocations include the fast flag when configured (or document if unsupported)
+- [ ] Config validation accepts `fast: true/false` on model entries
+- [ ] No fast flag passed when not configured
+- [ ] config-docs.md documents the fast option with examples
+
+## Notes
+- This depends on task 3 (wire reasoning effort) because both modify the same runner files — doing them in sequence avoids conflicts
+- Claude Code fast mode info: "Fast mode for Claude Code uses the same Claude Opus 4.6 model with faster output. It does NOT switch to a different model."
+- If Codex doesn't support a fast mode equivalent, document that and skip the Codex wiring

package/RAF/43-swiss-army/plans/7-config-preset.md

@@ -0,0 +1,51 @@
+---
+effort: high
+---
+# Task: Support Config Presets
+
+## Objective
+Add a preset system that lets users save, load, list, and delete named configuration profiles, enabling easy switching between Claude and Codex setups.
+
+## Context
+Users may want different configurations for different workflows (e.g., a Claude-focused setup vs a Codex-focused setup). Presets store complete config snapshots as named JSON files that can be switched with a single command.
+
+## Dependencies
+1
+
+## Requirements
+- Store presets as JSON files in `~/.raf/presets/<name>.json`
+- Create `~/.raf/presets/` directory if it doesn't exist
+- Implement `raf preset save <name>` — copy current config to a preset file
+- Implement `raf preset load <name>` — copy preset file to active config (overwrite current config)
+- Implement `raf preset list` — show all saved presets with brief info
+- Implement `raf preset delete <name>` — remove a preset file
+- Preset files are complete copies of raf.config.json (not diffs/patches)
+- Show confirmation messages for destructive operations (load overwrites current config)
+- Handle edge cases: preset not found, preset already exists (overwrite with confirmation)
+
+## Implementation Steps
+1. Create a new command file `src/commands/preset.ts`
+2. Add the `preset` command to the CLI with subcommands: save, load, list, delete
+3. Implement `save`: read current `~/.raf/raf.config.json`, write to `~/.raf/presets/<name>.json`
+4. Implement `load`: read `~/.raf/presets/<name>.json`, write to `~/.raf/raf.config.json`, validate the loaded config
+5. Implement `list`: read `~/.raf/presets/` directory, for each file show name and brief summary (e.g., provider info from models)
+6. Implement `delete`: remove `~/.raf/presets/<name>.json` with confirmation
+7. Register the preset command in the main CLI entry point (likely `src/index.ts` or `src/cli.ts`)
+8. Add error handling for missing presets directory, invalid JSON, etc.
+9. Update README.md with preset command documentation
+
+## Acceptance Criteria
+- [ ] `raf preset save claude-setup` saves current config as a named preset
+- [ ] `raf preset load claude-setup` restores the saved config
+- [ ] `raf preset list` shows all available presets
+- [ ] `raf preset delete claude-setup` removes a preset
+- [ ] Preset files stored in `~/.raf/presets/`
+- [ ] Error messages for missing presets, invalid names
+- [ ] Loaded config is validated before applying
+- [ ] README.md updated with preset commands
+
+## Notes
+- Look at how `src/utils/config.ts` reads/writes config files to follow existing patterns
+- The config path is likely defined as a constant — reuse it
+- For `list`, showing the provider from each model entry would help users identify presets at a glance
+- Consider showing a diff or summary when loading a preset so users know what changed

package/RAF/44-config-api-change/decisions.md

@@ -0,0 +1,22 @@
+# Project Decisions
+
+## For task 1, should bare `raf config` still launch the interactive config editor, with the flag behaviors becoming subcommands like `raf config get`, `raf config set`, and `raf config reset`?
+do 'raf config wizard' (spell wizard right) instead for just 'raf config'
+
+## Should preset behavior stay otherwise identical after the move to `raf config preset save|load|list|delete`, and should the old top-level `raf preset` command be removed entirely with no compatibility shim?
+yes behaviour identical to preset, but under config, raf preset should be removed
+
+## For tests, do you want just existing unit tests updated to the new API, or also new coverage for parsing/help/error behavior of the subcommands?
+update existing
+
+## For docs, should README/help text just present the new commands, or include a short breaking-change/migration note too?
+just new commands update
+
+## For the new name-generation task, should Codex-backed project naming produce 3–5 creative kebab-case suggestions like the Claude path, with permission to change Codex invocation and response parsing as needed while keeping Claude behavior unchanged and adding regression tests?
+yes
+
+## When Codex name generation returns fewer than 3 valid suggestions, should RAF still use 1–2 valid Codex suggestions and only fall back to extracted input words when the CLI completely fails or produces no usable suggestions?
+Use 1–2 valid Codex suggestions if that is all Codex returns, and only fall back to extracted input words when the CLI completely fails or produces no usable suggestions.
+
+## Should the Codex path keep the same name instructions and picker behavior as Claude, including 3–5 creative kebab-case suggestions, 1–3 words each, and the existing picker / auto-select-first flow?
+same name instructions

package/RAF/44-config-api-change/input.md

@@ -0,0 +1,5 @@
+change raf config api. it should be like this "raf config set ...", "raf config get" (flags replaced with commands), "raf config preset <preset commands and args>" (moving preset into config namespace), don't worry about breaking change
+
+---
+
+- [ ] name generation with codex doesn't work, name suggestion only one line with first words from input

package/RAF/44-config-api-change/outcomes/1-restructure-config-subcommands.md

@@ -0,0 +1,19 @@
+Implemented the `raf config` CLI refactor from flag-based behavior to explicit subcommands.
+
+Key changes:
+- Refactored [src/commands/config.ts](/Users/eremeev/projects/RAF/src/commands/config.ts) so `raf config` is now a namespace/help entry point with `get`, `set`, `reset`, and `wizard` subcommands.
+- Preserved existing config read/write/reset/session helper behavior, including resolved dot-path reads, JSON-aware value parsing, schema validation, default-pruning, reset confirmation, and broken-config recovery for the interactive editor.
+- Updated config-related user-facing text in [README.md](/Users/eremeev/projects/RAF/README.md), [src/prompts/config-docs.md](/Users/eremeev/projects/RAF/src/prompts/config-docs.md), and [src/commands/preset.ts](/Users/eremeev/projects/RAF/src/commands/preset.ts) to point users at `raf config wizard` / `raf config reset` instead of the removed flag API.
+- Reworked [tests/unit/config-command.test.ts](/Users/eremeev/projects/RAF/tests/unit/config-command.test.ts) to cover the real subcommand API, including bare-help behavior, `get`, `set`, `reset`, and wizard recovery.
+- Updated a few stale tests outside the config command area so the suite matches current CLI behavior and config-driven defaults: [tests/unit/planning-prompt.test.ts](/Users/eremeev/projects/RAF/tests/unit/planning-prompt.test.ts), [tests/unit/amend-prompt.test.ts](/Users/eremeev/projects/RAF/tests/unit/amend-prompt.test.ts), [tests/unit/name-generator.test.ts](/Users/eremeev/projects/RAF/tests/unit/name-generator.test.ts), and [tests/unit/claude-runner-interactive.test.ts](/Users/eremeev/projects/RAF/tests/unit/claude-runner-interactive.test.ts).
+- Added agent notes in [CLAUDE.md](/Users/eremeev/projects/RAF/CLAUDE.md) documenting the prompt-test drift and the need to avoid hardcoded default-provider assumptions in config-sensitive tests.
+
+Verification:
+- `npm run lint`
+- `npm test -- --watchman=false --runInBand tests/unit/config-command.test.ts`
+- `npm test -- --watchman=false --runInBand`
+
+Notes:
+- Jest needed `--watchman=false` in this environment because watchman socket access is blocked in the sandbox.
+
+<promise>COMPLETE</promise>

package/RAF/44-config-api-change/outcomes/2-move-preset-under-config.md

@@ -0,0 +1,17 @@
+Implemented the preset command move from top-level `raf preset` to nested `raf config preset ...` while keeping preset storage and behavior unchanged.
+
+Key changes:
+- Updated `src/commands/config.ts` to register the existing preset command as a nested `config` subcommand.
+- Updated `src/commands/preset.ts` help and runtime guidance so user-facing messages point to `raf config preset ...`.
+- Removed the top-level preset command registration from `src/index.ts`.
+- Updated `README.md` examples and command reference to document presets under `raf config`.
+- Extended `tests/unit/config-command.test.ts` to cover nested preset registration, removal of the top-level command, nested preset save/load/list/delete behavior, and updated guidance strings.
+
+Verification:
+- `npm test -- --watchman=false --runInBand tests/unit/config-command.test.ts`
+- `npm run lint`
+- `npm test -- --watchman=false --runInBand`
+
+Notes:
+- Preset files remain stored at `~/.raf/presets/*.json`; only CLI topology and messaging changed.
+<promise>COMPLETE</promise>

package/RAF/44-config-api-change/outcomes/3-update-existing-tests-for-config-api.md

@@ -0,0 +1,14 @@
+Verified the existing config command test coverage against the refactored config API and confirmed it already matches the planned subcommand-based surface.
+
+Key points:
+- `tests/unit/config-command.test.ts` already asserts `raf config` subcommand registration for `get`, `set`, `reset`, `wizard`, and nested `preset`.
+- The suite already verifies that root-level `--get`, `--set`, and `--reset` behavior is gone and that top-level `raf preset` is not registered.
+- Existing messaging assertions already cover the updated `raf config wizard`, `raf config reset`, and `raf config preset ...` guidance.
+
+Verification:
+- `npm test -- --watchman=false --runInBand tests/unit/config-command.test.ts`
+- `npm run lint`
+
+Notes:
+- No additional code changes were required in this task because the dependency work had already aligned the existing test suite with the new config API.
+<promise>COMPLETE</promise>

package/RAF/44-config-api-change/outcomes/4-update-config-command-docs.md

@@ -0,0 +1,11 @@
+Updated the remaining config command documentation and help text so active user-facing references align with the subcommand-based config API.
+
+Key changes:
+- Updated [src/commands/config.ts](/Users/eremeev/projects/RAF/src/commands/config.ts) command descriptions so generated help text clearly describes the `get`, `set`, `reset`, `wizard`, and nested `preset` hierarchy.
+- Updated [src/commands/preset.ts](/Users/eremeev/projects/RAF/src/commands/preset.ts) help text to describe presets as `raf config preset` subcommands.
+- Updated [src/prompts/config-docs.md](/Users/eremeev/projects/RAF/src/prompts/config-docs.md) so the reset instructions point users to `raf config reset` instead of manually deleting the config file.
+
+Notes:
+- `README.md` already matched the new config command surface from earlier dependency work, so no additional README edits were required in this task.
+- Verification completed with `npm test -- --watchman=false --runInBand tests/unit/config-command.test.ts` and `npm run lint`.
+<promise>COMPLETE</promise>

package/RAF/44-config-api-change/outcomes/5-fix-codex-name-generation.md

@@ -0,0 +1,18 @@
+Implemented the Codex name-generation fix so partial-but-usable model output is preserved instead of collapsing to the extracted-input fallback.
+
+Key changes:
+- Updated `src/utils/name-generator.ts` to use provider-specific CLI invocation for name generation:
+  - Claude keeps the existing `--model --no-session-persistence -p` flow.
+  - Codex now uses `codex exec --skip-git-repo-check --ephemeral --color never -m <model> <prompt>`.
+- Relaxed `generateProjectNames()` so any non-empty sanitized suggestion list is returned, which allows 1-2 valid Codex names to reach the picker / auto-select flow.
+- Kept extracted-word fallback behavior for genuine failure cases only, including CLI failure and outputs that sanitize down to zero usable names.
+- Added focused regression coverage in `tests/unit/name-generator.test.ts` for Codex invocation, Codex partial-result retention, and Codex no-usable-output fallback.
+
+Verification:
+- `npm test -- --watchman=false --runInBand tests/unit/name-generator.test.ts`
+- `npm run lint`
+- `npm test -- --watchman=false --runInBand`
+
+Notes:
+- Claude-backed name generation behavior remains unchanged apart from sharing the same provider-aware helper.
+<promise>COMPLETE</promise>

package/RAF/44-config-api-change/plans/1-restructure-config-subcommands.md

@@ -0,0 +1,37 @@
+---
+effort: medium
+---
+# Task: Restructure Config Command Into Subcommands
+
+## Objective
+Replace the flag-driven `raf config` API with explicit subcommands for reading, writing, resetting, and interactive editing.
+
+## Context
+`src/commands/config.ts` currently mixes interactive editing with `--get`, `--set`, and `--reset` flags on the root `config` command. The new API should be command-oriented instead: `raf config get`, `raf config set`, `raf config reset`, and `raf config wizard`. This is an intentional breaking change, so backward compatibility is not required.
+
+## Requirements
+- Remove the root `--get`, `--set`, and `--reset` options from `raf config`.
+- Add `raf config get [key]` for resolved-config reads, preserving current dot-notation lookup behavior.
+- Add `raf config set <key> <value>` for writes, preserving current parsing, validation, and minimal-config-file behavior.
+- Add `raf config reset` for deleting the config file with the current confirmation flow.
+- Add `raf config wizard [prompt...]` as the only entry point for the interactive config editor.
+- Do not launch the interactive editor from bare `raf config`; treat the root command as a namespace/help entry point.
+- Preserve the current invalid-config recovery behavior for the interactive session, but update any user-facing messages that reference the old flag-based API.
+
+## Implementation Steps
+1. Refactor `src/commands/config.ts` so the root `config` command registers subcommands instead of root-level flags.
+2. Reuse the existing get/set/reset/session helper logic where possible rather than reimplementing behavior.
+3. Move the variadic prompt argument from the root command to the new `wizard` subcommand.
+4. Update command descriptions so `raf config --help` and `raf config <subcommand> --help` reflect the new API cleanly.
+5. Adjust user-facing error and warning strings in config flows that currently mention `raf config`, `--reset`, or the old flag forms.
+
+## Acceptance Criteria
+- [ ] `raf config get` prints the resolved config, and `raf config get <dot.path>` prints the requested value.
+- [ ] `raf config set <dot.path> <value>` updates the user config with the same validation and default-pruning behavior as before.
+- [ ] `raf config reset` deletes the config file only after confirmation.
+- [ ] `raf config wizard [prompt...]` launches the interactive editor and preserves broken-config recovery behavior.
+- [ ] Bare `raf config` no longer launches the interactive editor.
+- [ ] All tests pass.
+
+## Notes
+The user explicitly wants `wizard` to replace the old bare interactive entry. Showing help from bare `raf config` is the sensible default if no subcommand is provided.

package/RAF/44-config-api-change/plans/2-move-preset-under-config.md

@@ -0,0 +1,38 @@
+---
+effort: medium
+---
+# Task: Move Preset Commands Under Config
+
+## Objective
+Nest preset management under the `config` namespace as `raf config preset ...` while keeping preset behavior unchanged.
+
+## Context
+RAF currently exposes presets as a top-level `raf preset` command implemented in `src/commands/preset.ts` and registered in `src/index.ts`. The desired API moves this functionality under `raf config preset`, and the old top-level command should be removed entirely.
+
+## Dependencies
+1
+
+## Requirements
+- Keep preset behavior identical to the current implementation for `save`, `load`, `list`, and `delete`.
+- Expose presets at `raf config preset save <name>`, `load <name>`, `list`, and `delete <name>`.
+- Remove the top-level `raf preset` command and its registration from the CLI.
+- Do not add a compatibility shim, alias, or deprecation path for `raf preset`.
+- Update preset-related help text and runtime messages so they reference `raf config preset ...` instead of `raf preset ...`.
+- Keep preset storage format and location unchanged at `~/.raf/presets/*.json`.
+
+## Implementation Steps
+1. Refactor `src/commands/preset.ts` so it can be registered as a nested `preset` subcommand under `config`.
+2. Wire the nested preset command into `src/commands/config.ts`.
+3. Remove the top-level preset command registration from `src/index.ts`.
+4. Update preset command descriptions and error/help strings that still point users to `raf preset ...`.
+5. Verify the nested command structure remains intuitive in Commander help output.
+
+## Acceptance Criteria
+- [ ] `raf config preset save <name>` saves the current config exactly as the old preset command did.
+- [ ] `raf config preset load <name>`, `list`, and `delete <name>` behave the same as before.
+- [ ] `raf preset` is no longer registered as a top-level command.
+- [ ] User-facing preset messages reference `raf config preset ...`.
+- [ ] All tests pass.
+
+## Notes
+This task should stay focused on command topology and message updates. Preset file semantics should not change.

package/RAF/44-config-api-change/plans/3-update-existing-tests-for-config-api.md

@@ -0,0 +1,38 @@
+---
+effort: low
+---
+# Task: Update Existing Tests For New Config API
+
+## Objective
+Align existing automated test coverage with the new subcommand-based config and preset command surface.
+
+## Context
+The current tests in `tests/unit/config-command.test.ts` assert root-level `--get`, `--set`, and `--reset` options. There does not appear to be an existing dedicated preset test suite, and the user asked to keep test work limited to updating existing coverage rather than expanding into a broad new matrix.
+
+## Dependencies
+1, 2
+
+## Requirements
+- Update existing unit tests to assert subcommand registration instead of the old root-level config flags.
+- Keep test changes scoped to existing suites where practical.
+- Cover the presence of `get`, `set`, `reset`, `wizard`, and nested `preset` under `config`.
+- Remove or rewrite assertions that expect `raf preset` to exist as a top-level command.
+- Update tests that reference old command descriptions, old usage strings, or old recovery/reset messaging.
+- Avoid building a large new preset-specific behavior suite unless a minimal addition is necessary to keep the changed API covered.
+
+## Implementation Steps
+1. Update `tests/unit/config-command.test.ts` to reflect the new `config` subcommand structure.
+2. Adjust existing registration/setup assertions so they validate nested subcommands rather than root options.
+3. Update any existing tests that rely on old error/help text or old command examples.
+4. If no existing suite can reasonably assert removal of top-level `raf preset`, extend the nearest existing command-registration test with the minimum needed coverage.
+5. Run the relevant test suite and fix any fallout from renamed commands or changed help text.
+
+## Acceptance Criteria
+- [ ] Existing tests no longer expect `--get`, `--set`, or `--reset` on the root `config` command.
+- [ ] Existing tests cover `raf config wizard` and nested `raf config preset`.
+- [ ] Existing tests no longer expect a top-level `raf preset` command.
+- [ ] Test scope stays focused on updating current suites rather than adding a broad new matrix.
+- [ ] All tests pass.
+
+## Notes
+Because preset logic is intentionally unchanged, registration and API-surface coverage is more important here than duplicating all preset behavior tests from scratch.

package/RAF/44-config-api-change/plans/4-update-config-command-docs.md

@@ -0,0 +1,36 @@
+---
+effort: low
+---
+# Task: Update Config Command Docs
+
+## Objective
+Refresh README and command/help text so the documented config workflow matches the new command hierarchy.
+
+## Context
+The current docs still describe `raf config` as an interactive editor, document `--reset`, and present presets as `raf preset`. The user only wants the docs updated to the new commands; no migration note or compatibility guidance is needed.
+
+## Dependencies
+1, 2
+
+## Requirements
+- Update `README.md` examples and command reference to use `raf config wizard`, `raf config get`, `raf config set`, `raf config reset`, and `raf config preset ...`.
+- Remove README references to top-level `raf preset` and root-level config flags.
+- Update Commander descriptions/help text so CLI help output matches the new hierarchy.
+- Update internal user-facing config docs and strings that mention the old command surface, including prompt/reference content in `src/prompts/config-docs.md` where relevant.
+- Do not add a breaking-change note, migration section, or compatibility note.
+
+## Implementation Steps
+1. Update `README.md` command overview, examples, and reference tables for the new config API.
+2. Update `src/commands/config.ts` and `src/commands/preset.ts` descriptions so generated help text matches the new structure.
+3. Sweep `src/prompts/config-docs.md` and nearby user-facing strings for stale references to bare `raf config`, `--reset`, and `raf preset`.
+4. Verify the documented commands and examples match the actual Commander registration after Tasks 1 and 2.
+
+## Acceptance Criteria
+- [ ] `README.md` documents only the new config command forms.
+- [ ] CLI help text reflects `wizard`, `get`, `set`, `reset`, and nested `preset`.
+- [ ] No user-facing config docs still instruct users to run `raf preset` or `raf config --reset`.
+- [ ] No migration note or compatibility section is added.
+- [ ] All tests pass.
+
+## Notes
+Keep the doc sweep scoped to active user-facing docs and help text. Archived `RAF/*` history should not be rewritten.

package/RAF/44-config-api-change/plans/5-fix-codex-name-generation.md

@@ -0,0 +1,49 @@
+---
+effort: medium
+---
+# Task: Fix Codex Project Name Generation
+
+## Objective
+Make `raf plan` produce usable creative project name suggestions when `models.nameGeneration.provider` is `codex` instead of degrading to the extracted-input fallback.
+
+## Context
+The current name-generation flow in `src/utils/name-generator.ts` only accepts model output when it can parse enough valid multiline suggestions. When that parsing fails, RAF falls back to `generateFallbackName()`, which just extracts the first meaningful words from the project description. That matches the user-reported Codex failure mode: name suggestion becomes a single low-quality line based on the input text rather than a real generated name.
+
+This task is specifically about the Codex-backed name-generation path. The user wants Codex to follow the same naming instructions and UX as Claude: creative kebab-case suggestions, 1-3 words each, and the existing picker / auto-select-first behavior. If Codex returns only 1-2 valid suggestions, RAF should still use them instead of immediately falling back to extracted input words. The extracted-word fallback should remain only for hard failure or completely unusable output.
+
+This work is independent from Tasks 1-4 in this project.
+
+## Requirements
+- Keep the existing naming instructions and UX consistent with the Claude path:
+  - 3-5 creative kebab-case suggestions when available
+  - 1-3 words per name
+  - existing name picker behavior in interactive mode
+  - existing auto-select-first behavior in auto mode
+- Fix the Codex name-generation path so `models.nameGeneration.provider = codex` produces usable suggestions instead of frequently collapsing into the extracted-input fallback.
+- Adjust parsing/fallback behavior so 1-2 valid Codex suggestions are accepted and surfaced to the user when that is all Codex returns.
+- Preserve the extracted-input fallback for genuine failure cases only, such as CLI failure or no usable suggestions after sanitization.
+- Keep Claude-backed name generation behavior unchanged.
+- Add focused regression coverage for Codex-specific invocation/parsing and the new partial-result fallback threshold.
+
+## Implementation Steps
+1. Inspect the current Codex name-generation execution path in `src/utils/name-generator.ts` and determine why Codex output is being reduced to fallback names.
+2. Update the Codex invocation and any provider-specific response handling needed so Codex can reliably return parsable multiline suggestions while preserving the existing prompt semantics.
+3. Refine `generateProjectNames()` so partial-but-usable model output (1-2 valid names) is retained instead of discarded in favor of the extracted-input fallback.
+4. Keep existing sanitization, deduplication, max-length, picker integration, and auto-select-first behavior intact for both providers.
+5. Add or update unit tests in the name-generation / planning command suites to cover:
+   - Codex provider invocation
+   - Codex multiline suggestion parsing
+   - acceptance of 1-2 valid suggestions
+   - fallback to extracted input words only when no usable model suggestions remain
+6. Run the relevant test suite and update any stale assertions tied to the old fallback threshold or provider assumptions.
+
+## Acceptance Criteria
+- [ ] With `models.nameGeneration.provider` set to `codex`, `raf plan` produces creative suggestions instead of defaulting to a first-words-from-input name on partial model output.
+- [ ] If Codex returns 1-2 valid suggestions, RAF uses those suggestions rather than falling back to extracted input words.
+- [ ] If the Codex CLI call fails or produces no usable suggestions, RAF still falls back to the extracted-input name.
+- [ ] Claude-backed name generation and the existing name picker / auto-select-first flow remain unchanged.
+- [ ] Focused regression tests cover Codex provider behavior and partial-result handling.
+- [ ] All tests pass.
+
+## Notes
+Historical outcome docs elsewhere in `RAF/` may describe older provider-wiring behavior that no longer matches the current implementation. Verify the live code path before assuming prior fixes are still present.

package/RAF/45-signal-cairn/decisions.md

@@ -0,0 +1,7 @@
+# Project Decisions
+
+## For task 1: should the rename be strict and complete everywhere user-facing and internal, meaning config JSON, TypeScript property names, validation/error messages, README/examples, and tests all switch to `harness` with no `provider` mentions left except historical migration warnings if any remain?
+yes, rename everythere
+
+## For task 2: do you want display normalization limited to the two places you named, or should the plan treat it as a global rule for all model display/log output where a model alias like `gpt54` could surface?
+global rule

package/RAF/45-signal-cairn/input.md

@@ -0,0 +1,2 @@
+- [ ] in task status during 'raf do' is says: gpt54. i would like it to look like this "gpt-5.4", take model string from other place. same in "Generating project name suggestions with gpt54" in plan.
+- [ ] in config rename provider to harness. no migration needed

package/RAF/45-signal-cairn/outcomes/1-rename-provider-to-harness.md

@@ -0,0 +1,19 @@
+# Outcome
+
+## Summary
+
+Renamed RAF's per-model config schema from `provider` to `harness` across runtime code, prompts, documentation, and tests without adding compatibility shims. The validator now accepts only `harness`, runner creation and logging use `entry.harness`, and the docs/examples describe the new schema consistently.
+
+## Key Changes
+
+- Updated config types and defaults to use `harness` in [src/types/config.ts](/Users/eremeev/.raf/worktrees/RAF/45-signal-cairn/src/types/config.ts) and propagated that rename through config parsing, validation, merge logic, and model-spec parsing in [src/utils/config.ts](/Users/eremeev/.raf/worktrees/RAF/45-signal-cairn/src/utils/config.ts).
+- Renamed downstream runtime consumers in planning, execution, config, preset listing, runner creation, name generation, and validation so they use harness-based properties and wording.
+- Rewrote user-facing docs and prompt material in [README.md](/Users/eremeev/.raf/worktrees/RAF/45-signal-cairn/README.md), [src/prompts/config-docs.md](/Users/eremeev/.raf/worktrees/RAF/45-signal-cairn/src/prompts/config-docs.md), and [CLAUDE.md](/Users/eremeev/.raf/worktrees/RAF/45-signal-cairn/CLAUDE.md).
+- Refreshed config, name-generation, execution-prompt, dependency, commit-planning, and runner tests to assert on `harness`, and isolated several suites from the machine's real `~/.raf` config so the renamed schema tests are stable.
+
+## Notes
+
+- Verification required bootstrapping the worktree with `npm install` because `node_modules` was absent.
+- Full verification completed with `npm run lint` and `NODE_OPTIONS='--experimental-vm-modules' npx jest --watchman=false`.
+
+<promise>COMPLETE</promise>

package/RAF/45-signal-cairn/outcomes/2-normalize-model-display-names.md

@@ -0,0 +1,18 @@
+# Outcome
+
+## Summary
+
+Centralized user-facing model label formatting so compact aliases now render consistently across RAF command output. In particular, `gpt54` now displays as `gpt-5.4` in planning, execution status, config, and PR-generation logs, while concise Claude labels like `opus`, `sonnet`, and `haiku` remain short and readable.
+
+## Key Changes
+
+- Added shared display helpers in `src/utils/config.ts` that derive user-facing model labels from the existing alias-to-full-ID mapping and support explicit full-ID rendering where needed.
+- Updated user-facing model logging in `src/commands/plan.ts`, `src/commands/do.ts`, `src/commands/config.ts`, and `src/core/pull-request.ts` to use the centralized formatter instead of ad hoc alias shortening.
+- Updated tests in `tests/unit/config.test.ts`, `tests/unit/terminal-symbols.test.ts`, and `tests/unit/command-output.test.ts` to cover normalized display names and canonical `gpt-5.4` task/status output.
+
+## Notes
+
+- `npm run lint` passed.
+- Full verification passed with `NODE_OPTIONS='--experimental-vm-modules' npx jest --watchman=false --runInBand`.
+
+<promise>COMPLETE</promise>

package/RAF/45-signal-cairn/plans/1-rename-provider-to-harness.md

@@ -0,0 +1,40 @@
+---
+effort: high
+---
+# Task: Rename Provider To Harness
+
+## Objective
+Replace the `provider` terminology with `harness` everywhere in RAF's config schema, code, tests, prompts, and documentation without adding migration compatibility.
+
+## Context
+RAF currently models Claude vs Codex selection through `provider` fields and related helper/type names across config parsing, runner creation, command logging, and docs. The user wants that terminology renamed everywhere, not just in JSON config examples. This is a deliberate breaking change for a greenfield project, so the implementation should fully adopt `harness` instead of carrying both terms or adding migration support.
+
+## Requirements
+- Rename the per-model config field from `provider` to `harness` across the entire codebase.
+- Rename internal TypeScript property names, helper parameters, validation paths, prompt/docs examples, README examples, and tests so `provider` is no longer the active term.
+- Preserve existing behavior: RAF must still route model entries to the Claude or Codex CLI correctly after the rename.
+- Do not add migration support, fallback parsing, or compatibility shims for the old `provider` key.
+- Remove or rewrite validation/help text so user-facing config guidance refers to `harness`, not `provider`.
+- Update `DEFAULT_CONFIG` in [src/types/config.ts](/Users/eremeev/.raf/worktrees/RAF/45-signal-cairn/src/types/config.ts) to use the new key, per project instructions.
+- Update `README.md` and generated config docs because this changes the config API.
+- Refresh automated coverage for config validation, config resolution, command logging, and any other code paths that assert on model-entry property names.
+
+## Implementation Steps
+1. Refactor config types in [src/types/config.ts](/Users/eremeev/.raf/worktrees/RAF/45-signal-cairn/src/types/config.ts) so model entries store `harness` instead of `provider`, and rename supporting types/interfaces/helpers where the old terminology is part of the public or internal API.
+2. Update config parsing, validation, and merge logic in [src/utils/config.ts](/Users/eremeev/.raf/worktrees/RAF/45-signal-cairn/src/utils/config.ts) to accept only `harness`, reject stale `provider` keys naturally under the new schema, and keep scenario/effort resolution behavior intact.
+3. Rename downstream call sites in commands, runners, name generation, validation, and core orchestration so they consume `entry.harness` consistently instead of `entry.provider`.
+4. Update prompt/docs sources such as [src/prompts/config-docs.md](/Users/eremeev/.raf/worktrees/RAF/45-signal-cairn/src/prompts/config-docs.md) and [README.md](/Users/eremeev/.raf/worktrees/RAF/45-signal-cairn/README.md) to describe the new schema and examples using `harness`.
+5. Rewrite affected tests to assert on `harness` terminology and current config behavior instead of the removed `provider` field.
+6. Run the relevant test suites covering config, plan/do command model resolution, and docs/config command output; fix stale assertions that still encode the old terminology.
+
+## Acceptance Criteria
+- [ ] Config files and defaults use `harness` instead of `provider`.
+- [ ] Active code paths no longer rely on `entry.provider` or equivalent provider-named config properties.
+- [ ] User-facing docs, prompts, examples, and error/help text describe `harness`, not `provider`.
+- [ ] RAF still resolves Claude vs Codex execution correctly after the rename.
+- [ ] Tests covering config validation/resolution and command behavior pass with the renamed schema.
+- [ ] All tests pass
+
+## Notes
+- Treat this as a full terminology migration inside the current codebase, not a narrow config-file alias.
+- Because the user explicitly does not want migration support, avoid dual-read logic like `harness ?? provider`.

package/RAF/45-signal-cairn/plans/2-normalize-model-display-names.md

@@ -0,0 +1,41 @@
+---
+effort: medium
+---
+# Task: Normalize Model Display Names
+
+## Objective
+Make all user-facing model labels flow through one centralized formatter so aliases like `gpt54` display as canonical names such as `gpt-5.4` during planning and execution.
+
+## Context
+RAF currently mixes display helpers: some places show a full resolved model ID, while others call `getModelShortName()` and end up rendering compact aliases like `gpt54`. The user specifically called out `raf do` task status and the planning log line `Generating project name suggestions with gpt54`, and asked for this to become a global display rule rather than a one-off patch. The implementation should therefore centralize model display formatting and reuse existing model-resolution data instead of hardcoding the string in individual commands.
+
+## Dependencies
+1
+
+## Requirements
+- Introduce or reuse a single helper for user-facing model labels instead of formatting aliases ad hoc at call sites.
+- Ensure `gpt54` displays as `gpt-5.4` anywhere model names are shown to the user, including task status during `raf do` and planning logs during name generation.
+- Apply the same centralized display rule to other command/log surfaces that currently expose model aliases, such as model-selection logs and verbose execution lines.
+- Derive display names from the existing model alias/full-ID mapping source in config utilities rather than scattering special cases.
+- Preserve the current UX where concise Claude labels like `opus`, `sonnet`, and `haiku` remain readable unless a surface already intentionally shows a full resolved model ID.
+- Update tests that assert on task progress formatting, plan logging, config/model helper behavior, and any other user-facing model strings touched by the refactor.
+
+## Implementation Steps
+1. Audit current model-display call sites in [src/commands/plan.ts](/Users/eremeev/.raf/worktrees/RAF/45-signal-cairn/src/commands/plan.ts), [src/commands/do.ts](/Users/eremeev/.raf/worktrees/RAF/45-signal-cairn/src/commands/do.ts), [src/commands/config.ts](/Users/eremeev/.raf/worktrees/RAF/45-signal-cairn/src/commands/config.ts), and any shared terminal helpers to identify where aliases are exposed directly.
+2. Add a centralized display formatter in [src/utils/config.ts](/Users/eremeev/.raf/worktrees/RAF/45-signal-cairn/src/utils/config.ts) or the most appropriate shared utility, backed by the existing alias-to-full-ID mapping so canonical display names come from one source.
+3. Replace direct `getModelShortName()` or equivalent alias formatting at user-facing log/status call sites with the new display helper, including the `raf do` status line and `raf plan` name-generation message.
+4. Keep intentionally full-ID surfaces intact where RAF already means to show the full resolved model, but route those decisions through explicit helper usage so the display policy is clear.
+5. Update and extend unit tests for config display helpers, terminal task-status formatting, and command output expectations so `gpt54` no longer appears in user-facing output.
+6. Run the relevant tests and tighten any stale assertions that still depend on alias-style display strings.
+
+## Acceptance Criteria
+- [ ] `raf do` task status shows `gpt-5.4` instead of `gpt54` when the resolved model is the GPT-5.4 alias.
+- [ ] `raf plan` logs `Generating project name suggestions with gpt-5.4...` when name generation uses that alias.
+- [ ] User-facing model logging/status surfaces use one centralized display formatter instead of per-call-site alias handling.
+- [ ] The formatter derives `gpt-5.4` from shared model metadata rather than a one-off string replacement in command code.
+- [ ] Updated tests cover the new display behavior and pass.
+- [ ] All tests pass
+
+## Notes
+- The goal is display normalization, not a behavioral change to model resolution.
+- Be careful not to regress surfaces that intentionally show full resolved IDs via `resolveFullModelId()`; unify the policy, not necessarily the exact string everywhere.

package/RAF/45-signal-lantern/decisions.md

@@ -0,0 +1,10 @@
+# Project Decisions
+
+## For task 1, what exact format do you want on the task line? Example: `● 01-auth-login (sonnet, low, fast) 12s`. Also, should this apply only to the compact running/completed/failed lines, or also to verbose `Model:` / retry logs?
+In same places where currently model is specified. `● 01-auth-login (sonnet, low, fast) 12s`. Don't display `low` if null and `fast` if falsy (`null` or `false`).
+
+## For task 2, what should the research task answer definitively: only exact dollar cost, or any usable post-run signal from Codex such as tokens, usage limits, or credits?
+Task is not research, do research now and say if it possible to get price in dollars and input output tokens count.
+
+## For task 3, if Codex can provide token counts but not exact price, should RAF still implement token-only summaries for Codex, or should price be shown only when it can be sourced exactly rather than estimated?
+Only show price if we can source price exactly. Provide input and output tokens though.

package/RAF/45-signal-lantern/input.md

@@ -0,0 +1,2 @@
+- [ ] add effort to status line in do for each task where we show model. also indicate if it's fast mode (nothing if fast mode disabled)
+- [ ] does codex have alternative to claude usage / price after execution? research first, create task if where is codex alternative

package/RAF/45-signal-lantern/outcomes/1-add-effort-and-fast-to-do-model-display.md

@@ -0,0 +1,15 @@
+Implemented the `raf do` model display update so existing compact task lines and verbose model logs now append resolved reasoning effort and `fast` metadata when present.
+
+Key changes:
+- Updated [`src/utils/terminal-symbols.ts`](/Users/eremeev/.raf/worktrees/RAF/45-signal-lantern/src/utils/terminal-symbols.ts) to centralize model metadata formatting and allow compact task progress lines to render `(model, effort, fast)` while omitting unavailable metadata.
+- Updated [`src/commands/do.ts`](/Users/eremeev/.raf/worktrees/RAF/45-signal-lantern/src/commands/do.ts) to thread resolved `reasoningEffort` and `fast` through running/completed/failed compact lines and through verbose `Model:` and retry logs.
+- Added coverage in [`tests/unit/terminal-symbols.test.ts`](/Users/eremeev/.raf/worktrees/RAF/45-signal-lantern/tests/unit/terminal-symbols.test.ts), [`tests/unit/command-output.test.ts`](/Users/eremeev/.raf/worktrees/RAF/45-signal-lantern/tests/unit/command-output.test.ts), and new [`tests/unit/do-model-display.test.ts`](/Users/eremeev/.raf/worktrees/RAF/45-signal-lantern/tests/unit/do-model-display.test.ts).
+- Updated [`README.md`](/Users/eremeev/.raf/worktrees/RAF/45-signal-lantern/README.md) to note the enriched non-verbose `raf do` task-line display.
+
+Important notes:
+- Verification commands could not run in this worktree because `node_modules` is absent, so local `jest` and `tsc` binaries were unavailable.
+- Attempted verification:
+  - `npm test -- --runInBand tests/unit/terminal-symbols.test.ts tests/unit/command-output.test.ts tests/unit/do-model-display.test.ts` -> failed with `jest: command not found`
+  - `npm run lint` -> failed with `tsc: command not found`
+
+<promise>COMPLETE</promise>

package/RAF/45-signal-lantern/outcomes/2-capture-codex-post-run-token-usage.md

@@ -0,0 +1,15 @@
+Implemented Codex post-run token usage capture so `codex exec --json` `turn.completed` events now feed RAF's shared usage pipeline instead of being dropped at the runner boundary.
+
+Key changes:
+- Updated `src/parsers/codex-stream-renderer.ts` to extract structured `UsageData` from `turn.completed`, including exact input/output token counts and model-scoped usage while leaving exact cost unavailable.
+- Updated `src/core/codex-runner.ts` to retain streamed Codex usage data and return it through the normal `RunResult.usageData` path used by `raf do`.
+- Refined shared usage/cost types and accumulation in `src/types/config.ts`, `src/utils/token-tracker.ts`, and `src/utils/terminal-symbols.ts` so unknown exact cost remains unavailable across retries and summaries instead of rendering as a fake exact zero.
+- Added coverage in `tests/unit/codex-stream-renderer.test.ts`, new `tests/unit/codex-runner.test.ts`, `tests/unit/token-tracker.test.ts`, and `tests/unit/terminal-symbols.test.ts`.
+
+Important notes:
+- Acceptance criteria around Codex input/output token capture, runner propagation, retry accumulation, and unavailable-cost handling were implemented in code and covered by new/updated unit tests.
+- Verification was limited by the worktree environment because `node_modules` is absent.
+- Attempted verification:
+  - `npm test -- --runInBand tests/unit/codex-stream-renderer.test.ts tests/unit/codex-runner.test.ts tests/unit/token-tracker.test.ts tests/unit/terminal-symbols.test.ts` -> failed with `jest: command not found`
+  - `npm run lint` -> failed with `tsc: command not found`
+<promise>COMPLETE</promise>