rafcode 3.0.0 → 3.8.0

package/RAF/43-swiss-army/plans/2-update-commit-format.md

@@ -0,0 +1,46 @@
+---
+effort: medium
+---
+# Task: Update Commit Message Format
+
+## Objective
+Change commit messages to use project name (from folder) instead of project ID, and add auto-generated descriptions for Plan and Amend commits.
+
+## Context
+Currently commits use numeric project IDs like `RAF[005:01]`. The new format should use the project folder name (kebab-case, without number prefix) and provide meaningful descriptions for plan/amend commits summarized from the project's input.md.
+
+## Dependencies
+1
+
+## Requirements
+- Extract project name from folder: `43-swiss-army` → `swiss-army` (drop numeric prefix, keep kebab-case)
+- Task commits: `RAF[swiss-army:01] Description here`
+- Plan commits: `RAF[swiss-army] Plan: <summary from input.md>` — a short project summary
+- Amend commits: `RAF[swiss-army] Amend: <description of what was amended>`
+- Update commit format templates in DEFAULT_CONFIG to use `{projectName}` placeholder
+- Make commit format templates configurable in raf.config.json (they already partially are via `commitFormat`)
+- Auto-generate plan description by summarizing plan task names or input.md content
+- Auto-generate amend description from what changed (e.g., amended task names)
+
+## Implementation Steps
+1. Read `src/types/config.ts` — update DEFAULT_CONFIG `commitFormat` templates to use `{projectName}` instead of `{projectId}`
+2. Read `src/utils/config.ts` — update `renderCommitMessage()` to populate `{projectName}` variable
+3. Add a utility to extract project name from folder path: strip numeric prefix and dash (e.g., `43-swiss-army` → `swiss-army`)
+4. Read `src/core/git.ts` — update `commitPlanningArtifacts()` and any other commit functions to pass `projectName`
+5. Read `src/prompts/execution.ts` — update the execution prompt's commit message instructions to use new format
+6. For Plan commits: generate description by summarizing plan file names or reading input.md first few lines
+7. For Amend commits: generate description from the amended plan files or changes made
+8. Update config-docs.md to document the new commit format template variables
+
+## Acceptance Criteria
+- [ ] Task commits use project name: `RAF[swiss-army:01] Description`
+- [ ] Plan commits include auto-generated summary: `RAF[swiss-army] Plan: summary here`
+- [ ] Amend commits include description: `RAF[swiss-army] Amend: what changed`
+- [ ] Commit format templates are configurable via `commitFormat` in config
+- [ ] `{projectName}` placeholder is documented and works in templates
+- [ ] Old `{projectId}` placeholder still works for backwards compatibility (resolves to same as projectName)
+
+## Notes
+- `renderCommitMessage()` in `src/utils/config.ts` (line 624) handles template variable substitution via regex `/\{(\w+)\}/g`
+- Plan description should be concise — one short sentence summarizing the project scope
+- For amend, the description could list which tasks were amended

package/RAF/43-swiss-army/plans/3-wire-reasoning-effort.md

@@ -0,0 +1,39 @@
+---
+effort: medium
+---
+# Task: Wire reasoningEffort to CLI Invocations
+
+## Objective
+Pass the `reasoningEffort` field from ModelEntry config to the actual Claude and Codex CLI invocations.
+
+## Context
+The `reasoningEffort` field exists in the ModelEntry interface and config validation, but is never passed to the CLI when spawning claude or codex processes. This makes it a no-op configuration.
+
+## Dependencies
+1
+
+## Requirements
+- Pass `reasoningEffort` to Claude CLI when invoking it (research the correct flag)
+- Pass `reasoningEffort` to Codex CLI when invoking it (research the correct flag)
+- Only include the flag when `reasoningEffort` is explicitly set in the ModelEntry
+- Valid values: 'none', 'minimal', 'low', 'medium', 'high', 'xhigh', 'max'
+
+## Implementation Steps
+1. Research how Claude CLI accepts reasoning effort — check `claude --help` or web docs for the flag name (likely `--reasoning-effort` or similar)
+2. Research how Codex CLI accepts reasoning effort — check `codex --help` or web docs
+3. Read `src/core/claude-runner.ts` — add reasoning effort flag to the CLI args array in both interactive and non-interactive modes
+4. Read `src/core/codex-runner.ts` — add reasoning effort flag to the CLI args array in both interactive and exec modes
+5. Ensure the flag is only added when `reasoningEffort` is defined in the ModelEntry
+6. Test that the args are correctly constructed
+
+## Acceptance Criteria
+- [ ] Claude CLI invocations include reasoning effort flag when configured
+- [ ] Codex CLI invocations include reasoning effort flag when configured
+- [ ] No reasoning effort flag is passed when not configured (undefined/omitted)
+- [ ] Existing CLI invocations still work when reasoningEffort is not set
+
+## Notes
+- ClaudeRunner is at `src/core/claude-runner.ts`, CodexRunner at `src/core/codex-runner.ts`
+- The runner receives model config via RunnerConfig or similar — trace how ModelEntry flows to the runner
+- Claude CLI flag is likely `--reasoning-effort <value>` but verify
+- Codex CLI flag needs research — may differ from Claude

package/RAF/43-swiss-army/plans/4-remove-provider-flag.md

@@ -0,0 +1,43 @@
+---
+effort: medium
+---
+# Task: Remove --provider Flag
+
+## Objective
+Remove the `--provider` CLI flag from all commands, relying entirely on the ModelEntry object's `provider` field in config.
+
+## Context
+The `--provider` flag is redundant now that every ModelEntry includes a `provider` field. Since this is a greenfield project with no users, it can be removed immediately without deprecation.
+
+## Dependencies
+1
+
+## Requirements
+- Remove `--provider` / `-p` option from `raf plan` command
+- Remove `--provider` / `-p` option from `raf do` command
+- Remove the `providerOverride` parameter from `getModel()` in config utils
+- Validate in config that every model entry has a `provider` field (should already be done after task 1)
+- Remove HarnessProvider type if it's only used for the flag (check usage first)
+- Clean up any code paths that handle provider override logic
+
+## Implementation Steps
+1. Read `src/commands/plan.ts` — remove `.option('-p, --provider ...')` and all references to `options.provider`
+2. Read `src/commands/do.ts` — remove `.option('-p, --provider ...')` and all references to `options.provider`
+3. Read `src/utils/config.ts` — simplify `getModel()` function to remove `providerOverride` parameter
+4. Search for any other usages of `providerOverride` or the provider flag across the codebase
+5. Check if `HarnessProvider` type is still needed elsewhere; if only used for the flag, consider keeping it for config validation only
+6. Update README.md to remove --provider flag documentation
+7. Update config-docs.md if it references --provider
+
+## Acceptance Criteria
+- [ ] `raf plan --provider` no longer accepted
+- [ ] `raf do --provider` no longer accepted
+- [ ] `getModel()` no longer accepts a provider override parameter
+- [ ] All model resolution uses the provider from ModelEntry config
+- [ ] Documentation updated
+- [ ] No dead code related to provider override remains
+
+## Notes
+- `getModel()` is at `src/utils/config.ts` line ~409
+- Provider override logic: `if (providerOverride) { return { ...entry, provider: providerOverride }; }`
+- HarnessProvider type may still be needed for the ModelEntry interface itself

package/RAF/43-swiss-army/plans/5-config-wizard-validation.md

@@ -0,0 +1,42 @@
+---
+effort: medium
+---
+# Task: Add Model Name & Reasoning Effort Validation to Config Wizard
+
+## Objective
+Update config-docs.md and the config wizard prompt to include a hardcoded list of valid model names and general reasoning effort guidance, with instructions to search the web for latest information.
+
+## Context
+The config wizard (used by `raf config`) needs to help users pick valid model names and understand reasoning effort options. Currently, config-docs.md doesn't provide enough guidance on which exact model names are valid or which models support reasoning effort.
+
+## Dependencies
+1
+
+## Requirements
+- Add a hardcoded list of known-good model names/aliases to config-docs.md for both Claude and Codex
+- Include general guidance about reasoning effort: what it does, which providers support it, valid values
+- Add instructions in the config wizard prompt to search the web for latest model names if the user wants to use a model not in the list
+- Don't document model-specific reasoning effort details — keep it general with links to provider docs
+- Validate exact model names in the config wizard conversation (the wizard agent should check names against the list)
+
+## Implementation Steps
+1. Read `src/prompts/config-docs.md` — understand current structure
+2. Add a "Valid Model Names" section with known aliases and full IDs for Claude (sonnet, haiku, opus, claude-sonnet-4-5-20250929, etc.) and Codex (spark, codex, gpt54, gpt-5.4, etc.)
+3. Add a "Reasoning Effort" section with general guidance: available for supporting models, valid values (none, minimal, low, medium, high, xhigh, max), link to Anthropic/OpenAI docs
+4. Read `src/commands/config.ts` — update the config wizard system prompt to instruct the agent to:
+   - Validate model names against the known list
+   - If user enters an unknown model name, suggest searching the web for validity
+   - Provide reasoning effort guidance when configuring model entries
+5. Ensure the wizard prompt tells the agent to use WebSearch tool if available to verify unfamiliar model names
+
+## Acceptance Criteria
+- [ ] config-docs.md contains a list of known valid model names for Claude and Codex
+- [ ] config-docs.md contains general reasoning effort guidance
+- [ ] Config wizard prompt instructs the agent to validate model names
+- [ ] Config wizard prompt instructs web search for unknown model names
+- [ ] Documentation is clear and concise
+
+## Notes
+- The config wizard runs as an interactive Claude session with config-docs.md as context
+- The wizard agent may or may not have WebSearch available — the prompt should suggest it as best-effort
+- Keep the model list maintainable — group by provider, note that aliases resolve to specific versions

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>