rafcode 3.2.1 → 3.8.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.claude/settings.local.json +3 -1
- package/CLAUDE.md +0 -1
- package/RAF/41-echo-chamber/decisions.md +13 -0
- package/RAF/41-echo-chamber/input.md +4 -0
- package/RAF/41-echo-chamber/outcomes/1-update-codex-model-defaults.md +24 -0
- package/RAF/41-echo-chamber/outcomes/2-e2e-test-codex-provider.md +74 -0
- package/RAF/41-echo-chamber/plans/1-update-codex-model-defaults.md +28 -0
- package/RAF/41-echo-chamber/plans/2-e2e-test-codex-provider.md +103 -0
- package/RAF/42-patch-parade/decisions.md +29 -0
- package/RAF/42-patch-parade/input.md +9 -0
- package/RAF/42-patch-parade/outcomes/1-fix-codex-model-resolution.md +36 -0
- package/RAF/42-patch-parade/outcomes/2-fix-provider-aware-name-generation.md +31 -0
- package/RAF/42-patch-parade/outcomes/3-fix-codex-error-event-rendering.md +32 -0
- package/RAF/42-patch-parade/outcomes/4-update-cli-help-docs.md +28 -0
- package/RAF/42-patch-parade/outcomes/5-update-default-codex-models-to-gpt-5-4.md +33 -0
- package/RAF/42-patch-parade/outcomes/6-unify-model-config-schema.md +89 -0
- package/RAF/42-patch-parade/plans/1-fix-codex-model-resolution.md +35 -0
- package/RAF/42-patch-parade/plans/2-fix-provider-aware-name-generation.md +38 -0
- package/RAF/42-patch-parade/plans/3-fix-codex-error-event-rendering.md +32 -0
- package/RAF/42-patch-parade/plans/4-update-cli-help-docs.md +31 -0
- package/RAF/42-patch-parade/plans/5-update-default-codex-models-to-gpt-5-4.md +35 -0
- package/RAF/42-patch-parade/plans/6-unify-model-config-schema.md +46 -0
- package/RAF/43-swiss-army/decisions.md +34 -0
- package/RAF/43-swiss-army/input.md +7 -0
- package/RAF/43-swiss-army/outcomes/1-fix-model-validation.md +21 -0
- package/RAF/43-swiss-army/outcomes/2-update-commit-format.md +31 -0
- package/RAF/43-swiss-army/outcomes/3-wire-reasoning-effort.md +28 -0
- package/RAF/43-swiss-army/outcomes/4-remove-provider-flag.md +27 -0
- package/RAF/43-swiss-army/outcomes/5-config-wizard-validation.md +23 -0
- package/RAF/43-swiss-army/outcomes/6-add-fast-mode.md +32 -0
- package/RAF/43-swiss-army/outcomes/7-config-preset.md +31 -0
- package/RAF/43-swiss-army/plans/1-fix-model-validation.md +38 -0
- package/RAF/43-swiss-army/plans/2-update-commit-format.md +46 -0
- package/RAF/43-swiss-army/plans/3-wire-reasoning-effort.md +39 -0
- package/RAF/43-swiss-army/plans/4-remove-provider-flag.md +43 -0
- package/RAF/43-swiss-army/plans/5-config-wizard-validation.md +42 -0
- package/RAF/43-swiss-army/plans/6-add-fast-mode.md +46 -0
- package/RAF/43-swiss-army/plans/7-config-preset.md +51 -0
- package/RAF/44-config-api-change/decisions.md +22 -0
- package/RAF/44-config-api-change/input.md +5 -0
- package/RAF/44-config-api-change/outcomes/1-restructure-config-subcommands.md +19 -0
- package/RAF/44-config-api-change/outcomes/2-move-preset-under-config.md +17 -0
- package/RAF/44-config-api-change/outcomes/3-update-existing-tests-for-config-api.md +14 -0
- package/RAF/44-config-api-change/outcomes/4-update-config-command-docs.md +11 -0
- package/RAF/44-config-api-change/outcomes/5-fix-codex-name-generation.md +18 -0
- package/RAF/44-config-api-change/plans/1-restructure-config-subcommands.md +37 -0
- package/RAF/44-config-api-change/plans/2-move-preset-under-config.md +38 -0
- package/RAF/44-config-api-change/plans/3-update-existing-tests-for-config-api.md +38 -0
- package/RAF/44-config-api-change/plans/4-update-config-command-docs.md +36 -0
- package/RAF/44-config-api-change/plans/5-fix-codex-name-generation.md +49 -0
- package/RAF/45-signal-cairn/decisions.md +7 -0
- package/RAF/45-signal-cairn/input.md +2 -0
- package/RAF/45-signal-cairn/outcomes/1-rename-provider-to-harness.md +19 -0
- package/RAF/45-signal-cairn/outcomes/2-normalize-model-display-names.md +18 -0
- package/RAF/45-signal-cairn/plans/1-rename-provider-to-harness.md +40 -0
- package/RAF/45-signal-cairn/plans/2-normalize-model-display-names.md +41 -0
- package/RAF/45-signal-lantern/decisions.md +10 -0
- package/RAF/45-signal-lantern/input.md +2 -0
- package/RAF/45-signal-lantern/outcomes/1-add-effort-and-fast-to-do-model-display.md +15 -0
- package/RAF/45-signal-lantern/outcomes/2-capture-codex-post-run-token-usage.md +15 -0
- package/RAF/45-signal-lantern/outcomes/3-show-codex-token-summaries-without-fake-cost.md +14 -0
- package/RAF/45-signal-lantern/plans/1-add-effort-and-fast-to-do-model-display.md +38 -0
- package/RAF/45-signal-lantern/plans/2-capture-codex-post-run-token-usage.md +37 -0
- package/RAF/45-signal-lantern/plans/3-show-codex-token-summaries-without-fake-cost.md +40 -0
- package/RAF/46-lantern-arc/decisions.md +19 -0
- package/RAF/46-lantern-arc/input.md +6 -0
- package/RAF/46-lantern-arc/outcomes/1-remove-spark-alias.md +16 -0
- package/RAF/46-lantern-arc/outcomes/2-clean-up-worktree-plan-command.md +30 -0
- package/RAF/46-lantern-arc/outcomes/3-fix-token-usage-accumulation.md +32 -0
- package/RAF/46-lantern-arc/outcomes/4-display-effort-in-compact-mode.md +22 -0
- package/RAF/46-lantern-arc/outcomes/5-codex-fast-mode-research.md +38 -0
- package/RAF/46-lantern-arc/outcomes/6-optimize-llm-prompts.md +39 -0
- package/RAF/46-lantern-arc/plans/1-remove-spark-alias.md +38 -0
- package/RAF/46-lantern-arc/plans/2-clean-up-worktree-plan-command.md +33 -0
- package/RAF/46-lantern-arc/plans/3-fix-token-usage-accumulation.md +33 -0
- package/RAF/46-lantern-arc/plans/4-display-effort-in-compact-mode.md +28 -0
- package/RAF/46-lantern-arc/plans/5-codex-fast-mode-research.md +34 -0
- package/RAF/46-lantern-arc/plans/6-optimize-llm-prompts.md +48 -0
- package/RAF/47-signal-trim/decisions.md +13 -0
- package/RAF/47-signal-trim/input.md +2 -0
- package/RAF/47-signal-trim/plans/1-remove-cache-from-status.md +73 -0
- package/README.md +47 -57
- package/dist/commands/config.d.ts.map +1 -1
- package/dist/commands/config.js +47 -49
- package/dist/commands/config.js.map +1 -1
- package/dist/commands/do.d.ts +2 -0
- package/dist/commands/do.d.ts.map +1 -1
- package/dist/commands/do.js +57 -44
- package/dist/commands/do.js.map +1 -1
- package/dist/commands/plan.d.ts.map +1 -1
- package/dist/commands/plan.js +36 -153
- package/dist/commands/plan.js.map +1 -1
- package/dist/commands/preset.d.ts +3 -0
- package/dist/commands/preset.d.ts.map +1 -0
- package/dist/commands/preset.js +158 -0
- package/dist/commands/preset.js.map +1 -0
- package/dist/core/claude-runner.d.ts +2 -0
- package/dist/core/claude-runner.d.ts.map +1 -1
- package/dist/core/claude-runner.js +36 -12
- package/dist/core/claude-runner.js.map +1 -1
- package/dist/core/codex-runner.d.ts +1 -0
- package/dist/core/codex-runner.d.ts.map +1 -1
- package/dist/core/codex-runner.js +26 -7
- package/dist/core/codex-runner.js.map +1 -1
- package/dist/core/failure-analyzer.js +2 -1
- package/dist/core/failure-analyzer.js.map +1 -1
- package/dist/core/git.d.ts +2 -2
- package/dist/core/git.d.ts.map +1 -1
- package/dist/core/git.js +53 -3
- package/dist/core/git.js.map +1 -1
- package/dist/core/pull-request.js +3 -3
- package/dist/core/pull-request.js.map +1 -1
- package/dist/core/runner-factory.d.ts +4 -4
- package/dist/core/runner-factory.d.ts.map +1 -1
- package/dist/core/runner-factory.js +8 -8
- package/dist/core/runner-factory.js.map +1 -1
- package/dist/core/runner-interface.d.ts +1 -1
- package/dist/core/runner-types.d.ts +17 -4
- package/dist/core/runner-types.d.ts.map +1 -1
- package/dist/parsers/codex-stream-renderer.d.ts +7 -0
- package/dist/parsers/codex-stream-renderer.d.ts.map +1 -1
- package/dist/parsers/codex-stream-renderer.js +37 -4
- package/dist/parsers/codex-stream-renderer.js.map +1 -1
- package/dist/prompts/amend.d.ts.map +1 -1
- package/dist/prompts/amend.js +29 -101
- package/dist/prompts/amend.js.map +1 -1
- package/dist/prompts/execution.d.ts.map +1 -1
- package/dist/prompts/execution.js +17 -34
- package/dist/prompts/execution.js.map +1 -1
- package/dist/prompts/planning.d.ts.map +1 -1
- package/dist/prompts/planning.js +21 -120
- package/dist/prompts/planning.js.map +1 -1
- package/dist/types/config.d.ts +33 -31
- package/dist/types/config.d.ts.map +1 -1
- package/dist/types/config.js +14 -28
- package/dist/types/config.js.map +1 -1
- package/dist/utils/config.d.ts +36 -16
- package/dist/utils/config.d.ts.map +1 -1
- package/dist/utils/config.js +209 -104
- package/dist/utils/config.js.map +1 -1
- package/dist/utils/name-generator.d.ts.map +1 -1
- package/dist/utils/name-generator.js +25 -12
- package/dist/utils/name-generator.js.map +1 -1
- package/dist/utils/terminal-symbols.d.ts +15 -2
- package/dist/utils/terminal-symbols.d.ts.map +1 -1
- package/dist/utils/terminal-symbols.js +36 -4
- package/dist/utils/terminal-symbols.js.map +1 -1
- package/dist/utils/token-tracker.d.ts +6 -1
- package/dist/utils/token-tracker.d.ts.map +1 -1
- package/dist/utils/token-tracker.js +84 -51
- package/dist/utils/token-tracker.js.map +1 -1
- package/dist/utils/validation.d.ts +1 -2
- package/dist/utils/validation.d.ts.map +1 -1
- package/dist/utils/validation.js +4 -25
- package/dist/utils/validation.js.map +1 -1
- package/package.json +1 -1
- package/src/commands/config.ts +60 -63
- package/src/commands/do.ts +63 -51
- package/src/commands/plan.ts +34 -165
- package/src/commands/preset.ts +186 -0
- package/src/core/claude-runner.ts +45 -5
- package/src/core/codex-runner.ts +32 -7
- package/src/core/failure-analyzer.ts +2 -1
- package/src/core/git.ts +57 -3
- package/src/core/pull-request.ts +3 -3
- package/src/core/runner-factory.ts +9 -9
- package/src/core/runner-interface.ts +1 -1
- package/src/core/runner-types.ts +17 -4
- package/src/parsers/codex-stream-renderer.ts +47 -4
- package/src/prompts/amend.ts +29 -101
- package/src/prompts/config-docs.md +206 -62
- package/src/prompts/execution.ts +17 -34
- package/src/prompts/planning.ts +21 -120
- package/src/types/config.ts +47 -58
- package/src/utils/config.ts +248 -115
- package/src/utils/name-generator.ts +29 -13
- package/src/utils/terminal-symbols.ts +46 -6
- package/src/utils/token-tracker.ts +96 -57
- package/src/utils/validation.ts +5 -30
- package/tests/unit/amend-prompt.test.ts +3 -2
- package/tests/unit/claude-runner-interactive.test.ts +21 -3
- package/tests/unit/claude-runner.test.ts +39 -0
- package/tests/unit/codex-runner.test.ts +163 -0
- package/tests/unit/codex-stream-renderer.test.ts +127 -0
- package/tests/unit/command-output.test.ts +57 -0
- package/tests/unit/commit-planning-artifacts-worktree.test.ts +24 -7
- package/tests/unit/commit-planning-artifacts.test.ts +26 -4
- package/tests/unit/config-command.test.ts +215 -303
- package/tests/unit/config.test.ts +319 -235
- package/tests/unit/dependency-integration.test.ts +27 -1
- package/tests/unit/do-model-display.test.ts +35 -0
- package/tests/unit/execution-prompt.test.ts +49 -19
- package/tests/unit/name-generator.test.ts +82 -12
- package/tests/unit/plan-command-auto-flag.test.ts +7 -10
- package/tests/unit/plan-command.test.ts +14 -17
- package/tests/unit/planning-prompt.test.ts +9 -8
- package/tests/unit/terminal-symbols.test.ts +94 -3
- package/tests/unit/token-tracker.test.ts +180 -1
- package/tests/unit/validation.test.ts +9 -41
- package/tests/unit/worktree-flag-override.test.ts +0 -186
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
---
|
|
2
|
+
effort: low
|
|
3
|
+
---
|
|
4
|
+
# Task: Fix Codex Error Event Rendering
|
|
5
|
+
|
|
6
|
+
## Objective
|
|
7
|
+
Render the remaining real-world Codex error event shapes so verbose output shows the actual failure text instead of empty or generic messages.
|
|
8
|
+
|
|
9
|
+
## Context
|
|
10
|
+
The scoped “minor bugs” come from `/Users/eremeev/projects/RAF/RAF/41-echo-chamber/outcomes/2-e2e-test-codex-provider.md`. Two minor renderer gaps remain: `item.completed` events with `item.type: "error"` produce no output, and `turn.failed` events that carry `error.message` fall back to the generic `Turn failed` text.
|
|
11
|
+
|
|
12
|
+
## Requirements
|
|
13
|
+
- Handle `item.completed` events where `item.type === "error"` and render the embedded error message.
|
|
14
|
+
- Handle `turn.failed` events that carry `error.message` and prefer that message over the generic fallback text.
|
|
15
|
+
- Preserve existing rendering behavior for already-supported Codex event types.
|
|
16
|
+
- Add focused tests that use the real event shapes documented in the outcome report.
|
|
17
|
+
|
|
18
|
+
## Implementation Steps
|
|
19
|
+
1. Update the Codex stream renderer switch logic to cover the missing error event variants.
|
|
20
|
+
2. Reuse existing formatting conventions so new error output matches current verbose output style.
|
|
21
|
+
3. Add focused unit tests for both missing event shapes.
|
|
22
|
+
4. Verify no existing renderer tests regress.
|
|
23
|
+
|
|
24
|
+
## Acceptance Criteria
|
|
25
|
+
- [ ] `item.completed` with `item.type: "error"` renders a visible error line.
|
|
26
|
+
- [ ] `turn.failed.error.message` is surfaced in the rendered output.
|
|
27
|
+
- [ ] Existing supported Codex event rendering remains unchanged.
|
|
28
|
+
- [ ] Focused renderer tests cover both real-world bug cases.
|
|
29
|
+
- [ ] All tests pass
|
|
30
|
+
|
|
31
|
+
## Notes
|
|
32
|
+
Keep this task narrowly scoped to the two bugs from the referenced outcome report.
|
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
---
|
|
2
|
+
effort: low
|
|
3
|
+
---
|
|
4
|
+
# Task: Update CLI Help Docs
|
|
5
|
+
|
|
6
|
+
## Objective
|
|
7
|
+
Align user-facing CLI help text and `README.md` with the removal of the `--worktree` and `--no-worktree` flags.
|
|
8
|
+
|
|
9
|
+
## Context
|
|
10
|
+
The user wants the help/docs surface updated to reflect that these flags are removed. In this task, scope is limited to CLI help text and `README.md`; prompt artifacts and archived RAF project docs should not be updated.
|
|
11
|
+
|
|
12
|
+
## Requirements
|
|
13
|
+
- Remove stale references to the removed `--worktree` / `--no-worktree` flags from CLI help text.
|
|
14
|
+
- Update `README.md` so supported flags and usage examples match the actual CLI behavior.
|
|
15
|
+
- Check for both the typo form `--worktreee` and the real flag names while cleaning up docs.
|
|
16
|
+
- Limit documentation changes to CLI help text and `README.md`.
|
|
17
|
+
|
|
18
|
+
## Implementation Steps
|
|
19
|
+
1. Inspect the current command definitions to identify which option declarations still drive stale help output.
|
|
20
|
+
2. Remove or update the relevant help text so `raf ... --help` matches the intended flag surface.
|
|
21
|
+
3. Update the flag tables and any related usage notes in `README.md`.
|
|
22
|
+
4. Verify there are no remaining user-facing references to the removed flags in the scoped files.
|
|
23
|
+
|
|
24
|
+
## Acceptance Criteria
|
|
25
|
+
- [ ] CLI help output no longer lists the removed `--worktree` / `--no-worktree` flags.
|
|
26
|
+
- [ ] `README.md` no longer documents the removed flags.
|
|
27
|
+
- [ ] No prompt docs or archived `RAF/*` artifacts are changed for this task.
|
|
28
|
+
- [ ] All tests pass
|
|
29
|
+
|
|
30
|
+
## Notes
|
|
31
|
+
If removing the help text requires deleting stale Commander option declarations, keep the change tightly scoped to the flag removal.
|
|
@@ -0,0 +1,35 @@
|
|
|
1
|
+
---
|
|
2
|
+
effort: low
|
|
3
|
+
---
|
|
4
|
+
# Task: Update Default Codex Models to GPT-5.4
|
|
5
|
+
|
|
6
|
+
## Objective
|
|
7
|
+
Set every Codex default model entry in RAF's current config schema to the literal model string `gpt-5.4`.
|
|
8
|
+
|
|
9
|
+
## Context
|
|
10
|
+
RAF currently stores Codex defaults in `codexModels` and `codexEffortMapping` under `DEFAULT_CONFIG`. The user wants every Codex slot to use the same default model string `gpt-5.4`, including planning, execution, name generation, failure analysis, PR generation, config assistance, and effort-based task routing. This task is intentionally narrow and updates the existing split-provider schema without redesigning it.
|
|
11
|
+
|
|
12
|
+
## Dependencies
|
|
13
|
+
1
|
|
14
|
+
|
|
15
|
+
## Requirements
|
|
16
|
+
- Update every `DEFAULT_CONFIG.codexModels.*` entry to `gpt-5.4`.
|
|
17
|
+
- Update every `DEFAULT_CONFIG.codexEffortMapping.*` entry to `gpt-5.4`.
|
|
18
|
+
- Keep Claude defaults unchanged.
|
|
19
|
+
- Update any config docs, examples, or tests that currently assert older Codex defaults such as `gpt-5.3-codex`.
|
|
20
|
+
- Do not preserve scenario-specific Codex exceptions; all Codex defaults should be the same literal model string.
|
|
21
|
+
|
|
22
|
+
## Implementation Steps
|
|
23
|
+
1. Update `src/types/config.ts` so every Codex default model slot and Codex effort-mapping slot resolves to `gpt-5.4`.
|
|
24
|
+
2. Search for docs, prompt docs, and tests that embed the previous Codex defaults and update them to match the new default config.
|
|
25
|
+
3. Verify that provider-aware resolution still reads the same config keys and now returns `gpt-5.4` for every default Codex path.
|
|
26
|
+
|
|
27
|
+
## Acceptance Criteria
|
|
28
|
+
- [ ] `DEFAULT_CONFIG.codexModels.plan`, `.execute`, `.nameGeneration`, `.failureAnalysis`, `.prGeneration`, and `.config` are all `gpt-5.4`.
|
|
29
|
+
- [ ] `DEFAULT_CONFIG.codexEffortMapping.low`, `.medium`, and `.high` are all `gpt-5.4`.
|
|
30
|
+
- [ ] Claude defaults remain unchanged.
|
|
31
|
+
- [ ] Any documentation or tests that mention old Codex defaults are updated.
|
|
32
|
+
- [ ] All tests pass
|
|
33
|
+
|
|
34
|
+
## Notes
|
|
35
|
+
Task 6 is expected to replace this split-provider schema later. Keep this task focused on default values only and avoid schema changes here.
|
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
---
|
|
2
|
+
effort: high
|
|
3
|
+
---
|
|
4
|
+
# Task: Unify Model Config Schema
|
|
5
|
+
|
|
6
|
+
## Objective
|
|
7
|
+
Replace RAF's provider-split model configuration with a single provider-aware object schema that stores `model`, `reasoningEffort`, and `provider` together.
|
|
8
|
+
|
|
9
|
+
## Context
|
|
10
|
+
RAF currently spreads model selection across a top-level `provider`, string-valued `models`, string-valued `effortMapping`, and separate Codex-specific `codexModels` / `codexEffortMapping` sections. Existing pending tasks 1 and 2 make that split work correctly, but the user now wants a breaking schema change: every configurable model entry should become an object such as `{ model: "opus", reasoningEffort: "high", provider: "claude" }`, with no top-level `provider` field and no separate Codex-only config branches. This task should preserve the decision from task 5 that Codex defaults use `gpt-5.4`, while removing support for the old config shape and the RAF CLI model-selection flags such as `--model` and `--sonnet`.
|
|
11
|
+
|
|
12
|
+
## Dependencies
|
|
13
|
+
1, 2, 5
|
|
14
|
+
|
|
15
|
+
## Requirements
|
|
16
|
+
- Change the config schema so model-bearing entries are objects with `model`, `reasoningEffort`, and `provider`.
|
|
17
|
+
- Remove the top-level `provider` config field.
|
|
18
|
+
- Remove `codexModels` and `codexEffortMapping`.
|
|
19
|
+
- Remove the old string-only model config shape instead of supporting both schemas in parallel.
|
|
20
|
+
- Remove RAF CLI flags that let users pick a model directly, including `--model`, `--sonnet`, and related validation/help text.
|
|
21
|
+
- Preserve the remaining command behavior by resolving provider and model from the selected config object for each scenario.
|
|
22
|
+
- Keep the config provider-agnostic so users can mix Claude and Codex entries freely across scenarios and effort levels.
|
|
23
|
+
- Add new tests for the new config schema covering validation, default resolution, effort-based resolution, merge behavior, and rejection of removed legacy keys/flags.
|
|
24
|
+
- Update user-facing docs and config docs to reflect the breaking schema change and the removed model-selection flags.
|
|
25
|
+
|
|
26
|
+
## Implementation Steps
|
|
27
|
+
1. Redesign the config types in `src/types/config.ts` around a reusable provider-aware model object and update `DEFAULT_CONFIG` to the new shape.
|
|
28
|
+
2. Rewrite config validation and merge logic in `src/utils/config.ts` to accept only the new schema, reject removed keys, and resolve scenario/effort selections from structured model objects.
|
|
29
|
+
3. Refactor callers such as `src/commands/plan.ts`, `src/commands/do.ts`, name generation, failure analysis, and PR generation so they consume provider/model pairs from the new config objects instead of top-level provider plus split mappings.
|
|
30
|
+
4. Remove RAF CLI model override flags and the related validation paths, while keeping internal provider-runner calls intact.
|
|
31
|
+
5. Carry forward task 5's default decision by making every default Codex-backed config entry use `gpt-5.4` within the new object schema.
|
|
32
|
+
6. Update `README.md`, config documentation, and command help to document the new schema and removed flags.
|
|
33
|
+
7. Add focused automated coverage for the new schema and resolution paths, including failure cases for legacy keys and removed CLI flags.
|
|
34
|
+
|
|
35
|
+
## Acceptance Criteria
|
|
36
|
+
- [ ] Config defaults use provider-aware model objects instead of plain strings.
|
|
37
|
+
- [ ] `provider`, `codexModels`, and `codexEffortMapping` are removed from the supported config schema.
|
|
38
|
+
- [ ] RAF no longer accepts `--model`, `--sonnet`, or equivalent user-facing model-selection flags.
|
|
39
|
+
- [ ] Scenario-based model resolution and effort-based task resolution both read the new object schema correctly.
|
|
40
|
+
- [ ] Default Codex-backed entries in the new schema use `gpt-5.4`.
|
|
41
|
+
- [ ] New tests cover the new schema, merge behavior, resolution behavior, and rejection of removed legacy keys/flags.
|
|
42
|
+
- [ ] User-facing docs describe the new schema and no longer document removed flags.
|
|
43
|
+
- [ ] All tests pass
|
|
44
|
+
|
|
45
|
+
## Notes
|
|
46
|
+
This is an intentional breaking change. Do not add migration compatibility or fallback support for the removed config keys. Assume the existing `--provider` command flag remains unless implementation shows it is fully redundant; the explicit user request only removed direct model-selection flags.
|
|
@@ -0,0 +1,34 @@
|
|
|
1
|
+
# Project Decisions
|
|
2
|
+
|
|
3
|
+
## How should the project name appear in commit messages?
|
|
4
|
+
Use the folder name as-is (kebab-case, without the number prefix). E.g., '43-swiss-army' → 'swiss-army'.
|
|
5
|
+
|
|
6
|
+
## Where should plan/amend commit descriptions come from?
|
|
7
|
+
Auto-generated from plan content. Plan descriptions should be a project summary derived from input.md (e.g., 'Plan: Swiss army knife utilities for config and CLI').
|
|
8
|
+
|
|
9
|
+
## Should commit format templates be configurable?
|
|
10
|
+
Yes — add template strings to raf.config.json with {projectName}, {description} placeholders.
|
|
11
|
+
|
|
12
|
+
## Should model validation keep legacy string-based validation or fully clean up?
|
|
13
|
+
Full cleanup — remove all legacy string-based model validation, only accept ModelEntry objects.
|
|
14
|
+
|
|
15
|
+
## How should config presets be stored and switched?
|
|
16
|
+
Named JSON files stored as ~/.raf/presets/<name>.json, switched with 'raf preset <name>'.
|
|
17
|
+
|
|
18
|
+
## What preset commands are needed?
|
|
19
|
+
Full CRUD: 'raf preset save/load/list/delete <name>'.
|
|
20
|
+
|
|
21
|
+
## Should --provider flag be removed immediately or deprecated?
|
|
22
|
+
Remove immediately — no users, greenfield project.
|
|
23
|
+
|
|
24
|
+
## Should 'fast' be per-model or global?
|
|
25
|
+
Per model entry — each ModelEntry gets fast: true/false, allowing fast planning but thorough execution.
|
|
26
|
+
|
|
27
|
+
## How should the config wizard validate model names?
|
|
28
|
+
Hardcoded list of known-good models in config-docs.md, supplemented with web search guidance in the wizard prompt.
|
|
29
|
+
|
|
30
|
+
## How should reasoning effort be documented?
|
|
31
|
+
General guidance — mention that reasoning effort is available for supporting models, link to provider docs.
|
|
32
|
+
|
|
33
|
+
## What should 'Plan:' commit descriptions look like?
|
|
34
|
+
Project summary style, e.g., 'Plan: Swiss army knife utilities for config and CLI' — summarized from input.md.
|
|
@@ -0,0 +1,7 @@
|
|
|
1
|
+
- [ ] update commit message format. instead of project id it should put project name (every commit type change). also for plan it should follow with short plan description like "Plan: doing important stuff like this, this and this", for "Amend:" should also describe that was amended exactly but short. check if we can describe this format in our config.
|
|
2
|
+
- [ ] reasoningEffort isn't wired to the actual CLI invocation anyway - should be wired
|
|
3
|
+
- [ ] add in src/prompts/config-docs.md and/or config wizard prompt so it validates exact model names and if reasoning effort available, it should search web for these cases.
|
|
4
|
+
- [ ] get rid of --provider flag and relly on model object to always provide it, validate config so provider always either codex or claude
|
|
5
|
+
- [ ] support config presets so i can easily switch between codex and claude configuration. like save user config presets as copy of config file and add preset command to switch
|
|
6
|
+
- [ ] extend model config object with fast: true/false option, research web how to pass fast to claude and codex and wire in the code
|
|
7
|
+
- [ ] getting error in "raf config" after configuring to model objects: Config validation warning: models.plan must be a short alias (sonnet, haiku, opus) or a full model ID (e.g., claude-sonnet-4-5-20250929) <- this is not correct, now we support model objects only
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
# Outcome: Fix Config Validation for Model Objects
|
|
2
|
+
|
|
3
|
+
## Summary
|
|
4
|
+
|
|
5
|
+
The config validation in `src/utils/config.ts` was already correctly updated to validate ModelEntry objects (the `validateModelEntry` function properly rejects strings and requires `{ model, provider }` objects). The prior `config improvements` commit had already implemented the correct validation logic.
|
|
6
|
+
|
|
7
|
+
The one remaining issue was in `src/prompts/config-docs.md`: the LLM session instructions example showed setting a model to a string `"sonnet"` rather than the correct ModelEntry format `{ "model": "sonnet", "provider": "claude" }`. This would cause the config-session LLM to write invalid configs that would then fail validation.
|
|
8
|
+
|
|
9
|
+
## Changes Made
|
|
10
|
+
|
|
11
|
+
- **`src/prompts/config-docs.md`**: Updated the "Explaining Changes" example in the LLM session instructions from `"sonnet"` (string) to `{ "model": "sonnet", "provider": "claude" }` (ModelEntry object).
|
|
12
|
+
|
|
13
|
+
## Acceptance Criteria Status
|
|
14
|
+
|
|
15
|
+
- [x] No validation warnings when config uses ModelEntry objects with valid model names — validation correctly accepts `{ model, provider }` objects
|
|
16
|
+
- [x] Validation correctly rejects malformed ModelEntry objects — errors for missing `model`, missing `provider`, invalid `provider`
|
|
17
|
+
- [x] Error messages reference ModelEntry object format — says "must be a model entry object (e.g. { \"model\": \"opus\", \"provider\": \"claude\" })"
|
|
18
|
+
- [x] Legacy string-based model values are rejected with a helpful migration message — same error message above
|
|
19
|
+
- [x] All existing tests pass — 141 tests pass
|
|
20
|
+
|
|
21
|
+
<promise>COMPLETE</promise>
|
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
# Outcome: Update Commit Message Format
|
|
2
|
+
|
|
3
|
+
## Summary
|
|
4
|
+
|
|
5
|
+
Changed commit messages to use project name (from folder) instead of numeric project ID, and added auto-generated descriptions for Plan and Amend commits.
|
|
6
|
+
|
|
7
|
+
## Changes Made
|
|
8
|
+
|
|
9
|
+
- **`src/types/config.ts`**: Updated DEFAULT_CONFIG commit format templates from `{projectId}` to `{projectName}`, and changed plan/amend templates to use `{description}` for auto-generated summaries
|
|
10
|
+
- **`src/core/git.ts`**: Added `extractPlanDescription()` (reads first line of input.md) and `extractAmendDescription()` (generates description from plan file names). Updated `commitPlanningArtifacts()` to pass `projectName` for both `{projectName}` and `{projectId}` (backwards compat), plus auto-generated `{description}`
|
|
11
|
+
- **`src/prompts/execution.ts`**: Updated `getExecutionPrompt()` to extract project name from path and pass it as both `projectName` and `projectId` variables
|
|
12
|
+
- **`src/prompts/config-docs.md`**: Updated template variable documentation and examples to reflect new format
|
|
13
|
+
- **Tests**: Updated all commit format assertions in `commit-planning-artifacts.test.ts`, `commit-planning-artifacts-worktree.test.ts`, `config.test.ts`, and `execution-prompt.test.ts`
|
|
14
|
+
|
|
15
|
+
## New Commit Format Examples
|
|
16
|
+
|
|
17
|
+
- Task: `RAF[swiss-army:1] Fix auth validation`
|
|
18
|
+
- Plan: `RAF[swiss-army] Plan: update commit message format...`
|
|
19
|
+
- Amend: `RAF[swiss-army] Amend: fix-bug, add-tests`
|
|
20
|
+
|
|
21
|
+
## Acceptance Criteria Status
|
|
22
|
+
|
|
23
|
+
- [x] Task commits use project name: `RAF[swiss-army:01] Description`
|
|
24
|
+
- [x] Plan commits include auto-generated summary: `RAF[swiss-army] Plan: summary from input.md`
|
|
25
|
+
- [x] Amend commits include description: `RAF[swiss-army] Amend: task-names or "updated plans"`
|
|
26
|
+
- [x] Commit format templates are configurable via `commitFormat` in config
|
|
27
|
+
- [x] `{projectName}` placeholder is documented and works in templates
|
|
28
|
+
- [x] Old `{projectId}` placeholder still works for backwards compatibility (resolves to projectName)
|
|
29
|
+
- [x] All existing tests pass (1227 pass, 2 pre-existing failures unrelated to this change)
|
|
30
|
+
|
|
31
|
+
<promise>COMPLETE</promise>
|
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
# Outcome: Wire reasoningEffort to CLI Invocations
|
|
2
|
+
|
|
3
|
+
## Summary
|
|
4
|
+
|
|
5
|
+
Wired the `reasoningEffort` field from ModelEntry config through to actual Claude and Codex CLI invocations. Previously, this field existed in the config type and validation but was never passed to the CLI processes.
|
|
6
|
+
|
|
7
|
+
## Changes Made
|
|
8
|
+
|
|
9
|
+
- **`src/core/runner-types.ts`**: Added `reasoningEffort?: string` to `RunnerConfig` interface
|
|
10
|
+
- **`src/core/claude-runner.ts`**: Store `reasoningEffort` from config; pass as `--effort <level>` flag in interactive, resume, and non-interactive (stream-json) modes
|
|
11
|
+
- **`src/core/codex-runner.ts`**: Store `reasoningEffort` from config; pass as `-c model_reasoning_effort="<level>"` in interactive and exec modes
|
|
12
|
+
- **`src/commands/plan.ts`**: Pass `reasoningEffort` from ModelEntry through to `createRunner()` (3 call sites)
|
|
13
|
+
- **`src/commands/config.ts`**: Pass `reasoningEffort` from ModelEntry through to `createRunner()`
|
|
14
|
+
- **`src/commands/do.ts`**: Pass `reasoningEffort` from ModelEntry through to `createRunner()`
|
|
15
|
+
|
|
16
|
+
## CLI Flags Used
|
|
17
|
+
|
|
18
|
+
- **Claude CLI**: `--effort <level>` (discovered via `claude --help`)
|
|
19
|
+
- **Codex CLI**: `-c model_reasoning_effort="<level>"` (discovered via codex config.toml format)
|
|
20
|
+
|
|
21
|
+
## Acceptance Criteria Status
|
|
22
|
+
|
|
23
|
+
- [x] Claude CLI invocations include reasoning effort flag when configured (`--effort`)
|
|
24
|
+
- [x] Codex CLI invocations include reasoning effort flag when configured (`-c model_reasoning_effort`)
|
|
25
|
+
- [x] No reasoning effort flag is passed when not configured (undefined/omitted) — guarded by `if (this.reasoningEffort)`
|
|
26
|
+
- [x] Existing CLI invocations still work when reasoningEffort is not set — all 1227 tests pass (2 pre-existing failures unrelated)
|
|
27
|
+
|
|
28
|
+
<promise>COMPLETE</promise>
|
|
@@ -0,0 +1,27 @@
|
|
|
1
|
+
# Outcome: Remove --provider Flag
|
|
2
|
+
|
|
3
|
+
## Summary
|
|
4
|
+
|
|
5
|
+
Removed the `--provider` / `-p` CLI flag from both `raf plan` and `raf do` commands. Provider is now exclusively determined by the `provider` field in each ModelEntry in the config file.
|
|
6
|
+
|
|
7
|
+
## Changes Made
|
|
8
|
+
|
|
9
|
+
- **`src/commands/plan.ts`**: Removed `-p, --provider` option, removed `provider` from `PlanCommandOptions` interface, removed provider override from `getModel()` calls
|
|
10
|
+
- **`src/commands/do.ts`**: Removed `-p, --provider` option, removed `providerOverride` from `SingleProjectOptions`, `resolveTaskModel()`, and all `getModel()`/`resolveEffortToModel()` calls
|
|
11
|
+
- **`src/utils/config.ts`**: Simplified `getModel()`, `getEffortMapping()`, and `resolveEffortToModel()` — removed `providerOverride` parameter from all three
|
|
12
|
+
- **`src/types/config.ts`**: Removed `provider` field from `PlanCommandOptions` and `DoCommandOptions` interfaces
|
|
13
|
+
- **`src/core/codex-runner.ts`**: Updated `getModel('execute')` call (was passing `'codex'` as provider override)
|
|
14
|
+
- **`README.md`**: Removed `--provider` from command reference tables and feature descriptions
|
|
15
|
+
- **`src/prompts/config-docs.md`**: Removed CLI precedence section about `--provider` override
|
|
16
|
+
- **`tests/unit/plan-command-auto-flag.test.ts`**: Updated test to verify `--provider` is no longer present
|
|
17
|
+
|
|
18
|
+
## Acceptance Criteria Status
|
|
19
|
+
|
|
20
|
+
- [x] `raf plan --provider` no longer accepted — option removed
|
|
21
|
+
- [x] `raf do --provider` no longer accepted — option removed
|
|
22
|
+
- [x] `getModel()` no longer accepts a provider override parameter — simplified to single `scenario` arg
|
|
23
|
+
- [x] All model resolution uses the provider from ModelEntry config — no override paths remain
|
|
24
|
+
- [x] Documentation updated — README and config-docs cleaned up
|
|
25
|
+
- [x] No dead code related to provider override remains — `providerOverride` grep returns zero results
|
|
26
|
+
|
|
27
|
+
<promise>COMPLETE</promise>
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
# Outcome: Add Model Name & Reasoning Effort Validation to Config Wizard
|
|
2
|
+
|
|
3
|
+
## Summary
|
|
4
|
+
|
|
5
|
+
Added comprehensive model name lists, reasoning effort guidance, and wizard validation instructions to `src/prompts/config-docs.md`. The config wizard agent now has all the information it needs to validate model names against known lists and guide users on reasoning effort configuration.
|
|
6
|
+
|
|
7
|
+
## Changes Made
|
|
8
|
+
|
|
9
|
+
- **`src/prompts/config-docs.md`**:
|
|
10
|
+
- Added "Valid Model Names" section with tables of Claude aliases (opus, sonnet, haiku) and Codex aliases (spark, codex, gpt54), their resolved model IDs, and notes on full model ID patterns
|
|
11
|
+
- Added "Prefixed Format" subsection documenting `provider/model` syntax
|
|
12
|
+
- Added "Reasoning Effort" section with valid values per provider, model support notes, and practical guidance on when to adjust effort levels
|
|
13
|
+
- Added "Validating Model Names" subsection in the Config Editing Session Instructions, instructing the wizard agent to check names against the known list, suggest web search for unknown names, catch common typos, and validate reasoning effort values per provider
|
|
14
|
+
|
|
15
|
+
## Acceptance Criteria Status
|
|
16
|
+
|
|
17
|
+
- [x] config-docs.md contains a list of known valid model names for Claude and Codex — tables with aliases and full IDs for both providers
|
|
18
|
+
- [x] config-docs.md contains general reasoning effort guidance — valid values per provider, support notes, and usage guidance
|
|
19
|
+
- [x] Config wizard prompt instructs the agent to validate model names — "Validating Model Names" section with 3-step validation flow
|
|
20
|
+
- [x] Config wizard prompt instructs web search for unknown model names — step 2 suggests WebSearch tool when available
|
|
21
|
+
- [x] Documentation is clear and concise — organized with tables, grouped by provider, practical guidance included
|
|
22
|
+
|
|
23
|
+
<promise>COMPLETE</promise>
|
|
@@ -0,0 +1,32 @@
|
|
|
1
|
+
# Outcome: Add Fast Mode to Model Config
|
|
2
|
+
|
|
3
|
+
## Summary
|
|
4
|
+
|
|
5
|
+
Extended ModelEntry with a `fast?: boolean` option and wired it to Claude CLI invocations via `--settings '{"fastMode": true}'`. Codex does not support fast mode — documented accordingly.
|
|
6
|
+
|
|
7
|
+
## Changes Made
|
|
8
|
+
|
|
9
|
+
- **`src/types/config.ts`**: Added `fast?: boolean` to `ModelEntry` interface
|
|
10
|
+
- **`src/core/runner-types.ts`**: Added `fast?: boolean` to `RunnerConfig` interface
|
|
11
|
+
- **`src/utils/config.ts`**: Added `fast` to `VALID_MODEL_ENTRY_KEYS`, added boolean validation in `validateModelEntry()`, added merge support in `mergeModelEntry()`
|
|
12
|
+
- **`src/core/claude-runner.ts`**: Store `fast` from config; pass as `--settings '{"fastMode": true}'` in interactive, resume, and non-interactive (stream-json) modes
|
|
13
|
+
- **`src/commands/plan.ts`**: Pass `fast` from ModelEntry through to `createRunner()` (3 call sites)
|
|
14
|
+
- **`src/commands/config.ts`**: Pass `fast` from ModelEntry through to `createRunner()`
|
|
15
|
+
- **`src/commands/do.ts`**: Pass `fast` from ModelEntry through to `createRunner()`
|
|
16
|
+
- **`src/prompts/config-docs.md`**: Added `fast` to ModelEntry shape, added "Fast Mode" section with description, example, and usage guidance
|
|
17
|
+
|
|
18
|
+
## CLI Mechanism
|
|
19
|
+
|
|
20
|
+
- **Claude CLI**: `--settings '{"fastMode": true}'` — enables fast mode via inline settings JSON
|
|
21
|
+
- **Codex CLI**: Not supported — documented as Claude-only feature
|
|
22
|
+
|
|
23
|
+
## Acceptance Criteria Status
|
|
24
|
+
|
|
25
|
+
- [x] ModelEntry interface includes `fast?: boolean`
|
|
26
|
+
- [x] Claude CLI invocations include the fast flag when configured (`--settings '{"fastMode": true}'`)
|
|
27
|
+
- [x] Codex CLI invocations — documented as unsupported (Codex has no fast mode equivalent)
|
|
28
|
+
- [x] Config validation accepts `fast: true/false` on model entries (boolean type check)
|
|
29
|
+
- [x] No fast flag passed when not configured — guarded by `if (this.fast)`
|
|
30
|
+
- [x] config-docs.md documents the fast option with examples
|
|
31
|
+
|
|
32
|
+
<promise>COMPLETE</promise>
|
|
@@ -0,0 +1,31 @@
|
|
|
1
|
+
# Outcome: Support Config Presets
|
|
2
|
+
|
|
3
|
+
## Summary
|
|
4
|
+
|
|
5
|
+
Added a `raf preset` command with save, load, list, and delete subcommands for managing named configuration profiles stored as JSON files in `~/.raf/presets/`.
|
|
6
|
+
|
|
7
|
+
## Changes Made
|
|
8
|
+
|
|
9
|
+
- **`src/commands/preset.ts`** (new): Implements the four subcommands:
|
|
10
|
+
- `save <name>`: Copies current `~/.raf/raf.config.json` to `~/.raf/presets/<name>.json` after validation
|
|
11
|
+
- `load <name>`: Validates the preset, copies it to active config, and shows a brief summary
|
|
12
|
+
- `list`: Shows all presets with provider and execute model info
|
|
13
|
+
- `delete <name>`: Removes a preset file
|
|
14
|
+
- Validates preset names (alphanumeric, hyphens, underscores only)
|
|
15
|
+
- Creates `~/.raf/presets/` directory automatically
|
|
16
|
+
- Validates config on both save and load
|
|
17
|
+
- **`src/index.ts`**: Registered the `preset` command
|
|
18
|
+
- **`README.md`**: Added preset command documentation in both the Commands section and the Command Reference table
|
|
19
|
+
|
|
20
|
+
## Acceptance Criteria Status
|
|
21
|
+
|
|
22
|
+
- [x] `raf preset save claude-setup` saves current config as a named preset
|
|
23
|
+
- [x] `raf preset load claude-setup` restores the saved config
|
|
24
|
+
- [x] `raf preset list` shows all available presets
|
|
25
|
+
- [x] `raf preset delete claude-setup` removes a preset
|
|
26
|
+
- [x] Preset files stored in `~/.raf/presets/`
|
|
27
|
+
- [x] Error messages for missing presets, invalid names
|
|
28
|
+
- [x] Loaded config is validated before applying
|
|
29
|
+
- [x] README.md updated with preset commands
|
|
30
|
+
|
|
31
|
+
<promise>COMPLETE</promise>
|
|
@@ -0,0 +1,38 @@
|
|
|
1
|
+
---
|
|
2
|
+
effort: low
|
|
3
|
+
---
|
|
4
|
+
# Task: Fix Config Validation for Model Objects
|
|
5
|
+
|
|
6
|
+
## Objective
|
|
7
|
+
Fix the config validation error that incorrectly requires model values to be short aliases or full model IDs, when model objects (ModelEntry) are now the only supported format.
|
|
8
|
+
|
|
9
|
+
## Context
|
|
10
|
+
After migrating to ModelEntry objects (model + provider + optional fields), the validation in `src/utils/config.ts` still checks for string-based model values. Running `raf config` produces: "Config validation warning: models.plan must be a short alias (sonnet, haiku, opus) or a full model ID". This is the foundation fix needed before other config changes.
|
|
11
|
+
|
|
12
|
+
## Requirements
|
|
13
|
+
- Remove all legacy string-based model validation from `src/utils/config.ts`
|
|
14
|
+
- Only accept ModelEntry objects (with `model`, `provider`, and optional fields)
|
|
15
|
+
- Validate that each ModelEntry has required `model` (string) and `provider` ("claude" | "codex") fields
|
|
16
|
+
- Validate optional fields like `reasoningEffort` when present
|
|
17
|
+
- Update error messages to reference the ModelEntry object format
|
|
18
|
+
- Update config-docs.md examples if they still show string-based model values
|
|
19
|
+
|
|
20
|
+
## Implementation Steps
|
|
21
|
+
1. Read `src/utils/config.ts` and locate the model validation logic (around lines 92-116 and the `validateConfig` function)
|
|
22
|
+
2. Replace string-based model name validation with ModelEntry object shape validation
|
|
23
|
+
3. Ensure `model` field within ModelEntry is still validated as a valid model name/alias
|
|
24
|
+
4. Ensure `provider` field is validated as "claude" or "codex"
|
|
25
|
+
5. Update any error messages to show correct expected format
|
|
26
|
+
6. Test by reviewing what `raf config` would produce with a valid ModelEntry config
|
|
27
|
+
|
|
28
|
+
## Acceptance Criteria
|
|
29
|
+
- [ ] No validation warnings when config uses ModelEntry objects with valid model names
|
|
30
|
+
- [ ] Validation correctly rejects malformed ModelEntry objects (missing model, missing provider, invalid provider)
|
|
31
|
+
- [ ] Error messages reference ModelEntry object format, not string aliases
|
|
32
|
+
- [ ] Legacy string-based model values are rejected with a helpful migration message
|
|
33
|
+
- [ ] All existing tests pass (if any)
|
|
34
|
+
|
|
35
|
+
## Notes
|
|
36
|
+
- The ModelEntry interface is defined in `src/types/config.ts` (lines 33-40)
|
|
37
|
+
- Valid model aliases: sonnet, haiku, opus (Claude); spark, codex, gpt54 (Codex)
|
|
38
|
+
- Valid full IDs: claude-{family}-{version} pattern, gpt-{major}.{minor} pattern
|
|
@@ -0,0 +1,46 @@
|
|
|
1
|
+
---
|
|
2
|
+
effort: medium
|
|
3
|
+
---
|
|
4
|
+
# Task: Update Commit Message Format
|
|
5
|
+
|
|
6
|
+
## Objective
|
|
7
|
+
Change commit messages to use project name (from folder) instead of project ID, and add auto-generated descriptions for Plan and Amend commits.
|
|
8
|
+
|
|
9
|
+
## Context
|
|
10
|
+
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.
|
|
11
|
+
|
|
12
|
+
## Dependencies
|
|
13
|
+
1
|
|
14
|
+
|
|
15
|
+
## Requirements
|
|
16
|
+
- Extract project name from folder: `43-swiss-army` → `swiss-army` (drop numeric prefix, keep kebab-case)
|
|
17
|
+
- Task commits: `RAF[swiss-army:01] Description here`
|
|
18
|
+
- Plan commits: `RAF[swiss-army] Plan: <summary from input.md>` — a short project summary
|
|
19
|
+
- Amend commits: `RAF[swiss-army] Amend: <description of what was amended>`
|
|
20
|
+
- Update commit format templates in DEFAULT_CONFIG to use `{projectName}` placeholder
|
|
21
|
+
- Make commit format templates configurable in raf.config.json (they already partially are via `commitFormat`)
|
|
22
|
+
- Auto-generate plan description by summarizing plan task names or input.md content
|
|
23
|
+
- Auto-generate amend description from what changed (e.g., amended task names)
|
|
24
|
+
|
|
25
|
+
## Implementation Steps
|
|
26
|
+
1. Read `src/types/config.ts` — update DEFAULT_CONFIG `commitFormat` templates to use `{projectName}` instead of `{projectId}`
|
|
27
|
+
2. Read `src/utils/config.ts` — update `renderCommitMessage()` to populate `{projectName}` variable
|
|
28
|
+
3. Add a utility to extract project name from folder path: strip numeric prefix and dash (e.g., `43-swiss-army` → `swiss-army`)
|
|
29
|
+
4. Read `src/core/git.ts` — update `commitPlanningArtifacts()` and any other commit functions to pass `projectName`
|
|
30
|
+
5. Read `src/prompts/execution.ts` — update the execution prompt's commit message instructions to use new format
|
|
31
|
+
6. For Plan commits: generate description by summarizing plan file names or reading input.md first few lines
|
|
32
|
+
7. For Amend commits: generate description from the amended plan files or changes made
|
|
33
|
+
8. Update config-docs.md to document the new commit format template variables
|
|
34
|
+
|
|
35
|
+
## Acceptance Criteria
|
|
36
|
+
- [ ] Task commits use project name: `RAF[swiss-army:01] Description`
|
|
37
|
+
- [ ] Plan commits include auto-generated summary: `RAF[swiss-army] Plan: summary here`
|
|
38
|
+
- [ ] Amend commits include description: `RAF[swiss-army] Amend: what changed`
|
|
39
|
+
- [ ] Commit format templates are configurable via `commitFormat` in config
|
|
40
|
+
- [ ] `{projectName}` placeholder is documented and works in templates
|
|
41
|
+
- [ ] Old `{projectId}` placeholder still works for backwards compatibility (resolves to same as projectName)
|
|
42
|
+
|
|
43
|
+
## Notes
|
|
44
|
+
- `renderCommitMessage()` in `src/utils/config.ts` (line 624) handles template variable substitution via regex `/\{(\w+)\}/g`
|
|
45
|
+
- Plan description should be concise — one short sentence summarizing the project scope
|
|
46
|
+
- For amend, the description could list which tasks were amended
|
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
---
|
|
2
|
+
effort: medium
|
|
3
|
+
---
|
|
4
|
+
# Task: Wire reasoningEffort to CLI Invocations
|
|
5
|
+
|
|
6
|
+
## Objective
|
|
7
|
+
Pass the `reasoningEffort` field from ModelEntry config to the actual Claude and Codex CLI invocations.
|
|
8
|
+
|
|
9
|
+
## Context
|
|
10
|
+
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.
|
|
11
|
+
|
|
12
|
+
## Dependencies
|
|
13
|
+
1
|
|
14
|
+
|
|
15
|
+
## Requirements
|
|
16
|
+
- Pass `reasoningEffort` to Claude CLI when invoking it (research the correct flag)
|
|
17
|
+
- Pass `reasoningEffort` to Codex CLI when invoking it (research the correct flag)
|
|
18
|
+
- Only include the flag when `reasoningEffort` is explicitly set in the ModelEntry
|
|
19
|
+
- Valid values: 'none', 'minimal', 'low', 'medium', 'high', 'xhigh', 'max'
|
|
20
|
+
|
|
21
|
+
## Implementation Steps
|
|
22
|
+
1. Research how Claude CLI accepts reasoning effort — check `claude --help` or web docs for the flag name (likely `--reasoning-effort` or similar)
|
|
23
|
+
2. Research how Codex CLI accepts reasoning effort — check `codex --help` or web docs
|
|
24
|
+
3. Read `src/core/claude-runner.ts` — add reasoning effort flag to the CLI args array in both interactive and non-interactive modes
|
|
25
|
+
4. Read `src/core/codex-runner.ts` — add reasoning effort flag to the CLI args array in both interactive and exec modes
|
|
26
|
+
5. Ensure the flag is only added when `reasoningEffort` is defined in the ModelEntry
|
|
27
|
+
6. Test that the args are correctly constructed
|
|
28
|
+
|
|
29
|
+
## Acceptance Criteria
|
|
30
|
+
- [ ] Claude CLI invocations include reasoning effort flag when configured
|
|
31
|
+
- [ ] Codex CLI invocations include reasoning effort flag when configured
|
|
32
|
+
- [ ] No reasoning effort flag is passed when not configured (undefined/omitted)
|
|
33
|
+
- [ ] Existing CLI invocations still work when reasoningEffort is not set
|
|
34
|
+
|
|
35
|
+
## Notes
|
|
36
|
+
- ClaudeRunner is at `src/core/claude-runner.ts`, CodexRunner at `src/core/codex-runner.ts`
|
|
37
|
+
- The runner receives model config via RunnerConfig or similar — trace how ModelEntry flows to the runner
|
|
38
|
+
- Claude CLI flag is likely `--reasoning-effort <value>` but verify
|
|
39
|
+
- Codex CLI flag needs research — may differ from Claude
|
|
@@ -0,0 +1,43 @@
|
|
|
1
|
+
---
|
|
2
|
+
effort: medium
|
|
3
|
+
---
|
|
4
|
+
# Task: Remove --provider Flag
|
|
5
|
+
|
|
6
|
+
## Objective
|
|
7
|
+
Remove the `--provider` CLI flag from all commands, relying entirely on the ModelEntry object's `provider` field in config.
|
|
8
|
+
|
|
9
|
+
## Context
|
|
10
|
+
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.
|
|
11
|
+
|
|
12
|
+
## Dependencies
|
|
13
|
+
1
|
|
14
|
+
|
|
15
|
+
## Requirements
|
|
16
|
+
- Remove `--provider` / `-p` option from `raf plan` command
|
|
17
|
+
- Remove `--provider` / `-p` option from `raf do` command
|
|
18
|
+
- Remove the `providerOverride` parameter from `getModel()` in config utils
|
|
19
|
+
- Validate in config that every model entry has a `provider` field (should already be done after task 1)
|
|
20
|
+
- Remove HarnessProvider type if it's only used for the flag (check usage first)
|
|
21
|
+
- Clean up any code paths that handle provider override logic
|
|
22
|
+
|
|
23
|
+
## Implementation Steps
|
|
24
|
+
1. Read `src/commands/plan.ts` — remove `.option('-p, --provider ...')` and all references to `options.provider`
|
|
25
|
+
2. Read `src/commands/do.ts` — remove `.option('-p, --provider ...')` and all references to `options.provider`
|
|
26
|
+
3. Read `src/utils/config.ts` — simplify `getModel()` function to remove `providerOverride` parameter
|
|
27
|
+
4. Search for any other usages of `providerOverride` or the provider flag across the codebase
|
|
28
|
+
5. Check if `HarnessProvider` type is still needed elsewhere; if only used for the flag, consider keeping it for config validation only
|
|
29
|
+
6. Update README.md to remove --provider flag documentation
|
|
30
|
+
7. Update config-docs.md if it references --provider
|
|
31
|
+
|
|
32
|
+
## Acceptance Criteria
|
|
33
|
+
- [ ] `raf plan --provider` no longer accepted
|
|
34
|
+
- [ ] `raf do --provider` no longer accepted
|
|
35
|
+
- [ ] `getModel()` no longer accepts a provider override parameter
|
|
36
|
+
- [ ] All model resolution uses the provider from ModelEntry config
|
|
37
|
+
- [ ] Documentation updated
|
|
38
|
+
- [ ] No dead code related to provider override remains
|
|
39
|
+
|
|
40
|
+
## Notes
|
|
41
|
+
- `getModel()` is at `src/utils/config.ts` line ~409
|
|
42
|
+
- Provider override logic: `if (providerOverride) { return { ...entry, provider: providerOverride }; }`
|
|
43
|
+
- HarnessProvider type may still be needed for the ModelEntry interface itself
|
|
@@ -0,0 +1,42 @@
|
|
|
1
|
+
---
|
|
2
|
+
effort: medium
|
|
3
|
+
---
|
|
4
|
+
# Task: Add Model Name & Reasoning Effort Validation to Config Wizard
|
|
5
|
+
|
|
6
|
+
## Objective
|
|
7
|
+
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.
|
|
8
|
+
|
|
9
|
+
## Context
|
|
10
|
+
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.
|
|
11
|
+
|
|
12
|
+
## Dependencies
|
|
13
|
+
1
|
|
14
|
+
|
|
15
|
+
## Requirements
|
|
16
|
+
- Add a hardcoded list of known-good model names/aliases to config-docs.md for both Claude and Codex
|
|
17
|
+
- Include general guidance about reasoning effort: what it does, which providers support it, valid values
|
|
18
|
+
- 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
|
|
19
|
+
- Don't document model-specific reasoning effort details — keep it general with links to provider docs
|
|
20
|
+
- Validate exact model names in the config wizard conversation (the wizard agent should check names against the list)
|
|
21
|
+
|
|
22
|
+
## Implementation Steps
|
|
23
|
+
1. Read `src/prompts/config-docs.md` — understand current structure
|
|
24
|
+
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.)
|
|
25
|
+
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
|
|
26
|
+
4. Read `src/commands/config.ts` — update the config wizard system prompt to instruct the agent to:
|
|
27
|
+
- Validate model names against the known list
|
|
28
|
+
- If user enters an unknown model name, suggest searching the web for validity
|
|
29
|
+
- Provide reasoning effort guidance when configuring model entries
|
|
30
|
+
5. Ensure the wizard prompt tells the agent to use WebSearch tool if available to verify unfamiliar model names
|
|
31
|
+
|
|
32
|
+
## Acceptance Criteria
|
|
33
|
+
- [ ] config-docs.md contains a list of known valid model names for Claude and Codex
|
|
34
|
+
- [ ] config-docs.md contains general reasoning effort guidance
|
|
35
|
+
- [ ] Config wizard prompt instructs the agent to validate model names
|
|
36
|
+
- [ ] Config wizard prompt instructs web search for unknown model names
|
|
37
|
+
- [ ] Documentation is clear and concise
|
|
38
|
+
|
|
39
|
+
## Notes
|
|
40
|
+
- The config wizard runs as an interactive Claude session with config-docs.md as context
|
|
41
|
+
- The wizard agent may or may not have WebSearch available — the prompt should suggest it as best-effort
|
|
42
|
+
- Keep the model list maintainable — group by provider, note that aliases resolve to specific versions
|