rafcode 2.1.1 → 2.3.0

package/RAF/ahstvo-token-tracker/plans/04-token-tracking-cost-calculation.md

@@ -0,0 +1,56 @@
+# Task: Add Token Tracking and Cost Calculation
+
+## Objective
+Implement token usage accumulation across tasks and cost calculation using configurable per-model pricing.
+
+## Context
+After task execution is unified to stream-json (task 03), each task returns `UsageData` with token counts. This task adds the infrastructure to accumulate usage across multiple tasks and calculate estimated costs based on configurable pricing.
+
+## Dependencies
+01, 03
+
+## Requirements
+- Add pricing config to the RAF config schema with current prices as defaults
+- Pricing is per-model, per-direction (input vs output), in dollars per million tokens
+- Support pricing tiers: standard (prompts <= 200K tokens) and extended (prompts > 200K tokens) for Opus and Sonnet; flat rate for Haiku
+- Cache read tokens should use a discounted price (typically 90% off input price — check Claude pricing page)
+- Cache creation tokens should use standard input price
+- Accumulate usage data across all tasks in a project execution run
+- Calculate estimated cost from token counts × configurable prices
+
+## Implementation Steps
+1. Define pricing types and add pricing config to the config schema in `src/types/config.ts` with default values:
+   - Opus: $15/MTok input, $75/MTok output (standard tier)
+   - Sonnet: $3/MTok input, $15/MTok output
+   - Haiku: $1/MTok input, $5/MTok output
+   - Cache read discount: 90% off input price
+   - Cache creation: same as input price
+2. Add config validation for pricing fields in `src/utils/config.ts`
+3. Add pricing accessor helpers (e.g., `getPricing(model)`)
+4. Create a `TokenTracker` utility (e.g., `src/utils/token-tracker.ts`) that:
+   - Accepts `UsageData` from each task execution
+   - Accumulates totals (input, output, cache read, cache creation tokens per model)
+   - Calculates cost from token counts × configured prices
+   - Provides per-task summaries and a grand total
+5. Map model IDs from CLI output (e.g., `claude-opus-4-6`) to pricing tiers — the modelUsage keys are full model IDs, so need a mapping from full ID to pricing category (opus/sonnet/haiku)
+6. Update config docs in `src/prompts/config-docs.md`
+7. Add tests for cost calculation and token accumulation
+
+## Acceptance Criteria
+- [ ] Pricing config added with sensible defaults matching current Claude API pricing
+- [ ] `TokenTracker` accumulates usage across multiple tasks correctly
+- [ ] Cost calculation is accurate: `tokens × price_per_token` for each category
+- [ ] Per-model pricing works (different costs for opus vs sonnet vs haiku)
+- [ ] Cache tokens use discounted pricing
+- [ ] Config validation accepts valid pricing, rejects invalid
+- [ ] All tests pass
+
+## Notes
+- Current pricing (as of 2026-02-10):
+  - Opus 4.6: $15/MTok input, $75/MTok output (standard ≤200K context)
+  - Sonnet 4.5: $3/MTok input, $15/MTok output
+  - Haiku 4.5: $1/MTok input, $5/MTok output
+  - Cache read is typically 10% of input price
+  - Cache creation is typically 25% more than input price
+- Model ID mapping: `claude-opus-4-6` → opus pricing, `claude-sonnet-4-5-*` → sonnet pricing, etc. Use a pattern-based lookup
+- Consider whether to track extended context pricing (>200K tokens) — may not be worth the complexity initially since RAF tasks rarely exceed 200K

package/RAF/ahstvo-token-tracker/plans/05-token-cost-console-reporting.md

@@ -0,0 +1,55 @@
+# Task: Add Token/Cost Reporting to Console Output
+
+## Objective
+Display per-task token usage and cost estimates after each task, and a grand total after all tasks complete.
+
+## Context
+With token tracking infrastructure in place (task 04), this task wires it into the `raf do` execution flow to display usage reports in the terminal. This is the user-facing part of the feature.
+
+## Dependencies
+04
+
+## Requirements
+- After each task completes, print a concise usage summary line to the console
+- After all tasks finish (or project completes), print a grand total summary
+- Show: input tokens, output tokens, cache tokens (combined read+creation), estimated cost in USD
+- Format numbers with thousands separators for readability (e.g., `12,345`)
+- Format cost as USD with 2-4 decimal places (e.g., `$1.23` or `$0.0042`)
+- Keep the output compact — avoid verbose multi-line reports for each task
+- Respect the existing console output style (chalk colors, log levels, etc.)
+
+## Implementation Steps
+1. In `src/commands/do.ts`, instantiate a `TokenTracker` at the start of project execution
+2. After each task execution, feed the returned `UsageData` into the tracker
+3. Print a per-task summary line after each task completes (e.g., `  Tokens: 5,234 in / 1,023 out | Cache: 18,500 read | Est. cost: $0.42`)
+4. After all tasks complete, print a total summary section with aggregated stats
+5. Handle edge cases: tasks that fail before returning usage data, context overflow, timeouts
+6. Use existing logging/formatting utilities (chalk, logger) for consistent styling
+7. Update CLAUDE.md and README.md to document the token tracking feature
+
+## Acceptance Criteria
+- [ ] Per-task token summary displayed after each task completion
+- [ ] Grand total displayed after all tasks finish
+- [ ] Numbers are formatted with thousands separators
+- [ ] Cost displayed in USD format
+- [ ] Failed tasks that have partial usage data are still included in totals
+- [ ] Tasks with no usage data (timeout, crash) are handled gracefully
+- [ ] Output is compact and doesn't overwhelm the console
+- [ ] CLAUDE.md updated with token tracking documentation
+- [ ] All tests pass
+
+## Notes
+- Example per-task output format:
+  ```
+  Task 01 complete ✓
+    Tokens: 5,234 in / 1,023 out | Cache: 18,500 read | Est. cost: $0.42
+  ```
+- Example total output format:
+  ```
+  ── Token Usage Summary ──────────────────
+  Total tokens: 45,678 in / 12,345 out
+  Cache: 125,000 read / 8,000 created
+  Estimated cost: $3.75
+  ─────────────────────────────────────────
+  ```
+- These are just examples — the implementing agent should match the existing output style

package/RAF/ahstvo-token-tracker/plans/06-runtime-verbose-toggle.md

@@ -0,0 +1,48 @@
+# Task: Add Runtime Verbose Toggle During Task Execution
+
+## Objective
+Allow users to press Tab during task execution to toggle verbose mode on/off in real-time, showing or hiding tool-use activity lines.
+
+## Context
+After task 03 unifies all execution to stream-json, the underlying data stream always includes tool-use events. Verbose mode becomes purely a display concern — whether to print tool descriptions (e.g., "Reading src/file.ts", "Running: npm test") to the console. This makes runtime toggling straightforward: listen for Tab key on stdin and flip a boolean that controls display output.
+
+## Dependencies
+03
+
+## Requirements
+- During non-interactive task execution (`raf do`), listen for Tab keypress on `process.stdin`
+- Pressing Tab toggles verbose display: tool-use lines are shown or hidden
+- The initial state matches the `--verbose` flag (off by default, on if `--verbose` was passed)
+- Display a brief indicator when toggling (e.g., `[verbose: on]` / `[verbose: off]`)
+- stdin must be in raw mode to capture individual keypresses without requiring Enter
+- Restore stdin to normal mode after task execution completes (or on process exit)
+- Do not interfere with Ctrl+C signal handling (SIGINT must still work)
+- Do not interfere with the child process — stdin is already `'ignore'` for spawned Claude
+
+## Implementation Steps
+1. Before starting task execution in `do.ts`, set up `process.stdin` in raw mode to capture keypresses
+2. Listen for the Tab key (character code `\t` or `0x09`) on the stdin `data` event
+3. Maintain a `verboseDisplay` boolean that the stream-json renderer checks before printing tool-use lines
+4. On Tab press, flip the boolean and print a brief status indicator
+5. Pass the `verboseDisplay` reference (or a callback/event emitter) to the stream renderer so it can check the current state for each event
+6. On task completion (or process exit/error), restore stdin to cooked mode and remove the listener
+7. Integrate with the shutdown handler to ensure clean terminal state on Ctrl+C
+8. Add tests for the toggle mechanism
+
+## Acceptance Criteria
+- [ ] Tab key toggles verbose display during task execution
+- [ ] Initial verbose state matches the `--verbose` CLI flag
+- [ ] Tool-use lines appear/disappear immediately on toggle
+- [ ] Brief status indicator shown on toggle
+- [ ] Ctrl+C still works for graceful shutdown
+- [ ] Terminal state is properly restored after execution
+- [ ] No interference with child process stdin
+- [ ] Works correctly across multiple sequential tasks
+- [ ] All existing tests pass
+
+## Notes
+- Node.js `process.stdin.setRawMode(true)` is already used in `runInteractive()` so the pattern is familiar in this codebase
+- The shutdown handler in `src/core/shutdown-handler.ts` already manages terminal cleanup — coordinate with it
+- Since the child process has `stdio: ['ignore', 'pipe', 'pipe']`, parent stdin is free to use for keypress detection
+- Consider showing the toggle hint at the start of execution: `Press Tab to toggle verbose mode`
+- Edge case: if stdin is not a TTY (piped input), skip the keypress listener entirely

package/RAF/ahstvo-token-tracker/plans/07-readme-config-docs.md

@@ -0,0 +1,44 @@
+# Task: Document raf config in README and Strengthen README Update Policy
+
+## Objective
+Add `raf config` documentation to README.md and add explicit guidance in CLAUDE.md about keeping the README updated when CLI commands or important features change.
+
+## Context
+The `raf config` command is fully implemented but completely missing from the user-facing README. Users have no way to discover that configuration is possible, how to use it, or what can be configured. Additionally, CLAUDE.md's "Important Reminders" section should be more explicit about when README updates are required to prevent this gap from recurring.
+
+## Requirements
+
+### README updates
+- Add a `raf config` section alongside the existing command documentation sections (`raf plan`, `raf do`, `raf status`)
+- Keep it brief and consistent with the existing README style
+- Include: command usage, what it does (interactive Claude session for config), basic config file example, 1-2 common use cases
+- Add `raf config` to the Command Reference table at the bottom
+- Mention the config file location (`~/.raf/raf.config.json`) and three-tier precedence (CLI flag > config > defaults)
+- Do NOT duplicate the full config schema — reference that `raf config` itself provides interactive help
+
+### CLAUDE.md updates
+- Expand the "Important Reminders" section to explicitly state that README must be updated when:
+  - New CLI commands are added
+  - Existing command APIs change (new flags, changed behavior)
+  - Important features are added (like worktrees, config, token tracking)
+- Keep the reminder actionable and specific, not vague
+
+## Implementation Steps
+1. Read the current README.md to understand section ordering, style, and formatting conventions
+2. Add a `### raf config` section after the existing `raf status` section, following the same format
+3. Include a minimal config example showing 2-3 common settings (e.g., changing default model, setting worktree default)
+4. Add `raf config` entries to the Command Reference tables
+5. Update CLAUDE.md's "Important Reminders" with explicit README update policy
+
+## Acceptance Criteria
+- [ ] README has a `raf config` section with usage and basic example
+- [ ] `raf config` appears in the Command Reference table
+- [ ] Config file location and precedence rules are mentioned
+- [ ] CLAUDE.md has explicit guidance about when to update README
+- [ ] No existing README content is broken or removed
+- [ ] Documentation tone and style match the rest of the README
+
+## Notes
+- The existing README documents `raf config` options: `--reset` flag and inline prompt (`raf config "use haiku"`) — these should be mentioned
+- Look at `src/prompts/config-docs.md` for the full config reference — pick 2-3 of the most common/useful settings for the README example
+- The README currently has a "Features" section that lists 7 features — consider adding "Configurable" to that list if not present

package/RAF/ahtahs-token-reaper/decisions.md

@@ -0,0 +1,37 @@
+# Project Decisions
+
+## For the per-task token summary, should it show accumulated total or per-attempt breakdown?
+Per-attempt breakdown — show token usage for each attempt individually, plus a combined total.
+
+## Should per-attempt breakdown appear in normal output or only with --verbose?
+Always show breakdown — per-attempt details shown regardless of verbose flag for full cost transparency.
+
+## Should TokenTracker store per-attempt data, or should accumulation happen in do.ts?
+Tracker stores attempts — TokenTracker gains a richer data model with per-attempt entries. addTask accepts an array of UsageData. Centralized logic.
+
+## Should the grand total summary also show per-attempt breakdown?
+Grand total only — the final summary shows combined totals. Per-attempt detail is available in individual task summaries above.
+
+## What format for the model name in log messages?
+"...with sonnet" style — append 'with <model>' before the ellipsis, e.g., "Generating project name suggestions with sonnet..."
+
+## Should the model name be the short alias or full model ID?
+Short alias — display friendly names like 'sonnet', 'haiku', 'opus'. Cleaner output.
+
+## Should model-in-log apply only to name generation or all Claude calls?
+All Claude calls — add model names to all log messages where RAF invokes Claude (name generation, failure analysis, PR generation, config session).
+
+## When config is invalid, should `raf config` silently fall back or warn?
+Warn then continue — show a warning about the invalid config, then launch the interactive session normally with defaults.
+
+## Should config resilience apply to all commands or only `raf config`?
+Only `raf config` — it's the recovery tool. Other commands can still fail fast on invalid config.
+
+## When verbose is ON, should the task name and elapsed time be shown as a header?
+No header at all — when verbose is ON, only show Claude's raw output and tool descriptions. No task name or timer.
+
+## When toggling back to verbose OFF, should the timer resume or reset?
+Resume counting — timer continues from actual elapsed time since task start.
+
+## When verbose is ON, should tool use descriptions still be shown?
+Show both — show Claude's text AND tool use descriptions (→ Reading file.ts, → Running: npm test, etc.).

package/RAF/ahtahs-token-reaper/input.md

@@ -0,0 +1,20 @@
+- [ ] **Accumulate token usage across retry attempts** When a task retries, this assignment overwrites prior `usageData`, and the tracker is only updated once after the retry loop, so tokens/cost from earlier failed attempts are dropped. In any task that takes multiple attempts, the per-task and total summaries underreport actual consumption, which skews cost reporting for long or flaky runs.
+
+---
+
+when i switch to verbose mode is see output together with timer and task name repeating on each line. could you remove interactive timer when verbose mode is on, and put it back on OFF. and don't put task on each line when in V ON mode. see log: ```● 01-extend-token-tracker-data-model 34s  [verbose: on]
+		● 01-extend-token-tracker-data-model 37s  → Updating task list
+
+		● 01-extend-token-tracker-data-model 39sNow let me add the `accumulateUsage()` function. I'll add it before the TokenTracker class.
+
+		● 01-extend-token-tracker-data-model 46s  → Editing /Users/eremeev/.raf/worktrees/RAF/ahtahs-token-reaper/src/utils/token-tracker.ts
+
+		● 01-extend-token-tracker-data-model 50s  → Updating task list
+
+		● 01-extend-token-tracker-data-model 52sNow let me update the `addTask()` method to accept an array.
+
+		● 01-extend-token-tracker-data-model 53s  → Reading /Users/eremeev/.raf/worktrees/RAF/ahtahs-token-reaper/src/utils/token-tracker.ts
+
+		● 01-extend-token-tracker-data-model 55sNow let me update the `addTask()` method to accept an array of UsageData.
+
+		● 01-extend-token-tracker-data-model 56s  [verbose: off]```

package/RAF/ahtahs-token-reaper/outcomes/01-extend-token-tracker-data-model.md

@@ -0,0 +1,42 @@
+# Task 01: Extend TokenTracker Data Model
+
+## Summary
+
+Refactored TokenTracker to accept and store per-attempt UsageData entries per task, enabling accurate token tracking across retries.
+
+## Changes Made
+
+### src/utils/token-tracker.ts
+- Added `attempts: UsageData[]` field to `TaskUsageEntry` interface
+- Created `accumulateUsage()` utility function that merges multiple UsageData objects into one, summing all token fields and merging modelUsage maps (handles different models across attempts)
+- Updated `addTask()` signature to accept `UsageData[]` instead of single `UsageData`
+- `addTask()` now calls `accumulateUsage()` to compute combined usage and stores raw attempts for future display breakdowns
+
+### src/commands/do.ts
+- Updated two call sites to wrap single `lastUsageData` in array `[lastUsageData]`
+- Added TODO comments indicating these should pass all attempt data once retry loop accumulates them
+
+### tests/unit/token-tracker.test.ts
+- Updated all existing test calls to use array syntax `[usage]`
+- Added new tests for:
+  - `accumulateUsage()` function (empty array, single element, multi-element, multi-model merging, non-mutation)
+  - Multi-attempt accumulation in `addTask()`
+  - Cost calculation for multi-model retry scenarios
+  - `attempts` array storage in entries
+
+## Acceptance Criteria Verification
+
+- [x] `TaskUsageEntry` has an `attempts: UsageData[]` field
+- [x] `addTask()` accepts an array and correctly accumulates tokens across attempts
+- [x] `accumulateUsage()` correctly sums all token fields including per-model breakdowns
+- [x] `getTotals()` returns correct grand totals when tasks have multiple attempts
+- [x] Single-attempt tasks behave identically to before
+- [x] All existing and new token-tracker tests pass (27 tests)
+
+## Notes
+
+- The `accumulateUsage()` function handles the case where different attempts use different models (e.g., Opus on first attempt, Sonnet on retry due to fallback)
+- `calculateCost()` was left unchanged as designed - it operates on the accumulated UsageData
+- Pre-existing test failures in validation.test.ts and claude-runner-interactive.test.ts are unrelated to this task
+
+<promise>COMPLETE</promise>

package/RAF/ahtahs-token-reaper/outcomes/02-accumulate-usage-in-retry-loop.md

@@ -0,0 +1,31 @@
+# Task 02: Accumulate Usage in Retry Loop
+
+## Summary
+
+Modified the retry loop in `do.ts` to collect usage data from every attempt instead of overwriting it, and pass the full array to TokenTracker for accurate token tracking across retries.
+
+## Changes Made
+
+### src/commands/do.ts
+- Replaced `let lastUsageData: UsageData | undefined` with `const attemptUsageData: UsageData[] = []`
+- Changed from overwriting `lastUsageData = result.usageData` to `attemptUsageData.push(result.usageData)` when usage data is present
+- Updated success path (lines ~1091-1095): now checks `attemptUsageData.length > 0` and passes the full array to `tokenTracker.addTask()`
+- Updated failure path (lines ~1118-1122): same change, passes full array for partial data tracking
+- Removed TODO comments that were added in Task 01 as placeholders
+
+## Acceptance Criteria Verification
+
+- [x] Usage data from all retry attempts is collected in an array
+- [x] The full array is passed to `tokenTracker.addTask()`
+- [x] Attempts with no usage data (timeout/crash) are excluded from the array (only push when `result.usageData` is defined)
+- [x] Single-attempt tasks still work correctly (array of length 1)
+- [x] All tests pass (token-tracker: 27 tests, do-*: 44 tests)
+
+## Notes
+
+- The `lastOutput` variable remains unchanged as designed - only final output matters for result parsing
+- The existing tests from Task 01 already cover the accumulation logic in `TokenTracker` and `accumulateUsage()`
+- The change is minimal and surgical - only the usage data collection mechanism was updated
+- Edge cases (timeouts, crashes, context overflow) correctly result in no usage data being pushed for that attempt
+
+<promise>COMPLETE</promise>

package/RAF/ahtahs-token-reaper/outcomes/03-per-attempt-display-formatting.md

@@ -0,0 +1,60 @@
+# Task 03: Per-Attempt Display Formatting
+
+## Summary
+
+Updated `formatTaskTokenSummary()` to display a per-attempt breakdown when a task took multiple attempts, while keeping single-attempt output unchanged.
+
+## Changes Made
+
+### src/utils/terminal-symbols.ts
+- Added import for `TaskUsageEntry` type from token-tracker
+- Created internal `formatTokenLine()` helper function that formats a single line of token usage (used for both attempts and totals)
+- Updated `formatTaskTokenSummary()` signature to accept:
+  - `entry: TaskUsageEntry` (replaces separate `usage` and `cost` parameters)
+  - `calculateAttemptCost?: (usage: UsageData) => CostBreakdown` (optional callback for per-attempt cost calculation)
+- Single-attempt behavior: When `entry.attempts.length <= 1`, output is identical to previous format: `"  Tokens: X in / Y out | Cache: ... | Est. cost: $X.XX"`
+- Multi-attempt behavior: Shows per-attempt breakdown with:
+  - Each attempt on its own line: `"    Attempt N: X in / Y out | Cache: ... | Est. cost: $X.XX"`
+  - Total line at the end: `"    Total: X in / Y out | Cache: ... | Est. cost: $X.XX"`
+
+### src/commands/do.ts
+- Updated both call sites (success and failure paths) to pass the full `TaskUsageEntry` and the `calculateCost` callback:
+  - `logger.dim(formatTaskTokenSummary(entry, (u) => tokenTracker.calculateCost(u)))`
+
+### tests/unit/terminal-symbols.test.ts
+- Added import for `TaskUsageEntry` type
+- Created `makeEntry()` helper to construct `TaskUsageEntry` objects for testing
+- Reorganized `formatTaskTokenSummary` tests into two describe blocks:
+  - `single-attempt tasks`: 6 tests verifying unchanged behavior for single-attempt scenarios
+  - `multi-attempt tasks`: 4 tests covering multi-attempt formatting, cost calculation, cache tokens, and 3+ attempts
+
+## Example Output
+
+**Single-attempt (unchanged):**
+```
+  Tokens: 5,234 in / 1,023 out | Cache: 18,500 read | Est. cost: $0.42
+```
+
+**Multi-attempt (new):**
+```
+    Attempt 1: 1,234 in / 567 out | Est. cost: $0.02
+    Attempt 2: 2,345 in / 890 out | Est. cost: $0.04
+    Total: 3,579 in / 1,457 out | Est. cost: $0.06
+```
+
+## Acceptance Criteria Verification
+
+- [x] Single-attempt tasks display identically to current format
+- [x] Multi-attempt tasks show per-attempt lines plus a total
+- [x] Formatting is clean and readable in terminal output
+- [x] `formatTokenTotalSummary()` is unchanged
+- [x] All call sites updated
+- [x] All tests pass (135 tests including 10 new tests for this feature)
+
+## Notes
+
+- The `calculateAttemptCost` callback is optional; when not provided, per-attempt costs show `$0.00` (the total still shows accurate accumulated cost)
+- Per-attempt lines use 4-space indent to visually nest under the task, while single-attempt uses 2-space indent
+- Cache tokens are included in per-attempt breakdowns when present
+
+<promise>COMPLETE</promise>

package/RAF/ahtahs-token-reaper/outcomes/04-add-model-name-to-claude-call-logs.md

@@ -0,0 +1,57 @@
+# Task 04: Add Model Name to Claude Invocation Logs
+
+## Summary
+
+Added a `getModelShortName()` utility function and updated all four Claude invocation log messages to display the short model alias (e.g., "sonnet", "haiku", "opus").
+
+## Changes Made
+
+### src/utils/config.ts
+- Added `getModelShortName(modelId: string)` utility function that:
+  - Returns short aliases (`opus`, `sonnet`, `haiku`) as-is
+  - Extracts family from full model IDs (e.g., `claude-sonnet-4-5-20250929` → `sonnet`)
+  - Returns unknown model IDs as-is for graceful fallback
+
+### src/commands/plan.ts
+- Added import for `getModel` and `getModelShortName`
+- Updated name generation log: `"Generating project name suggestions with ${nameModel}..."`
+
+### src/commands/do.ts
+- Added import for `getModel` and `getModelShortName`
+- Updated failure analysis log: `"Analyzing failure with ${analysisModel}..."`
+
+### src/core/pull-request.ts
+- Added import for `getModelShortName`
+- Added new log message in `generatePrBody()`: `"Generating PR with ${prModel}..."`
+
+### src/commands/config.ts
+- Added import for `getModelShortName`
+- Consolidated two log lines into one: `"Starting config session with ${configModel}..."`
+  - Previously: "Starting config session with Claude..." + "Using model: ${model}"
+  - Now: single line with short model name
+
+### tests/unit/config.test.ts
+- Added import for `getModelShortName`
+- Added test suite with 3 test cases:
+  - `should return short aliases as-is`
+  - `should extract family from full model IDs`
+  - `should return unknown model IDs as-is`
+
+## Acceptance Criteria Verification
+
+- [x] All four Claude invocation points show the model short name in their log messages
+  - Name generation: `"Generating project name suggestions with sonnet..."`
+  - Failure analysis: `"Analyzing failure with haiku..."`
+  - PR generation: `"Generating PR with sonnet..."`
+  - Config session: `"Starting config session with sonnet..."`
+- [x] Short name extraction works for full model IDs and already-short names
+- [x] Log format follows the "...with <model>..." pattern
+- [x] Unit tests cover the short name utility (3 tests)
+- [x] All tests pass (95 config tests, 1156 total passing)
+
+## Notes
+
+- Pre-existing test failures in `validation.test.ts` and `claude-runner-interactive.test.ts` are unrelated to this task
+- The `getModelShortName()` function reuses logic similar to `resolveModelPricingCategory()` but returns the original string for unknown models instead of `null`
+
+<promise>COMPLETE</promise>

package/RAF/ahtahs-token-reaper/outcomes/05-handle-invalid-config-in-raf-config.md

@@ -0,0 +1,46 @@
+# Task 05: Handle Invalid Config Gracefully in raf config Command
+
+## Summary
+
+Made `raf config` resilient to invalid or corrupt config files so it can serve as the recovery path for broken configurations. Previously, if `~/.raf/raf.config.json` contained invalid JSON or failed schema validation, `raf config` would crash before the interactive session could launch, blocking users from fixing the issue.
+
+## Changes Made
+
+### src/commands/config.ts
+- Added import for `resetConfigCache` from config utilities
+- Added import for `DEFAULT_CONFIG` from types/config
+- Wrapped `getModel('config')` and `getEffort('config')` calls in try-catch block
+- On error, falls back to `DEFAULT_CONFIG.models.config` ('sonnet') and `DEFAULT_CONFIG.effort.config` ('medium')
+- Displays warning message with the specific error: "Config file has errors, using defaults: {message}"
+- Provides guidance: "Fix the config in this session or run `raf config --reset` to start fresh."
+- Calls `resetConfigCache()` to clear any broken cached config
+- The interactive Claude session still receives the broken config file contents via `getCurrentConfigState()`, so the user can see and fix the issue
+
+### tests/unit/config-command.test.ts
+- Added imports for `resolveConfig`, `getModel`, `getEffort`, `resetConfigCache`, and `DEFAULT_CONFIG`
+- Added `resetConfigCache()` calls to beforeEach/afterEach for test isolation
+- Added new test suite "Error recovery - invalid config fallback" with 6 tests:
+  - Throws on invalid JSON when resolving config
+  - Throws on schema validation failure when resolving config
+  - Default fallback values are correct for config scenario
+  - Raw file contents readable even with invalid JSON
+  - Raw file contents readable even with schema validation failure
+  - resetConfigCache clears the cached config
+
+## Acceptance Criteria Verification
+
+- [x] `raf config` launches successfully even when `~/.raf/raf.config.json` is invalid JSON
+- [x] `raf config` launches successfully even when config fails schema validation
+- [x] A clear warning is displayed to the user about the config error
+- [x] The interactive session uses default model/effort values as fallback
+- [x] The broken config content is still visible in the session for the user to fix
+- [x] Other commands (`raf plan`, `raf do`, `raf status`) still fail fast on invalid config
+- [x] All tests pass (121 config-related tests, 1162 total passing; pre-existing failures in validation.test.ts and claude-runner-interactive.test.ts are unrelated)
+
+## Notes
+
+- The error handling is specific to `raf config` - other commands continue to fail fast on invalid config as expected
+- The `getCurrentConfigState()` function reads raw file content without JSON parsing, so broken content is always available to Claude in the session
+- The `--reset` option doesn't need this fix since it deletes the file without loading it
+
+<promise>COMPLETE</promise>

package/RAF/ahtahs-token-reaper/outcomes/06-fix-verbose-toggle-timer-display.md

@@ -0,0 +1,38 @@
+# Task 06: Fix Verbose Toggle Timer Display
+
+## Summary
+
+Modified the timer callback in `do.ts` to check the verbose toggle state on each tick. When verbose is toggled ON at runtime, the status line is immediately cleared and updates are skipped. When toggled back OFF, the timer resumes displaying with the accurate elapsed time.
+
+## Changes Made
+
+### src/commands/do.ts
+- Updated the `onTick` callback (lines 915-923) to check `verboseToggle.isVerbose` on every tick
+- When verbose is ON: calls `statusLine.clear()` and returns early (skipping the update)
+- When verbose is OFF: updates the status line as normal with task progress
+- The timer continues tracking elapsed time internally regardless of display state
+
+### tests/unit/timer-verbose-integration.test.ts (new file)
+- Created new test file with 5 tests covering the timer-verbose integration:
+  - `should update status line when verbose is off`
+  - `should clear status line and skip update when verbose is toggled on`
+  - `should resume updating status line when verbose is toggled back off`
+  - `should track elapsed time correctly regardless of verbose state`
+  - `should not create timer callback when started with verbose flag`
+
+## Acceptance Criteria Verification
+
+- [x] Toggling verbose ON clears the status line and stops timer/task-name display
+- [x] Toggling verbose OFF resumes the timer/status line with correct elapsed time
+- [x] No task name prefix appears on verbose output lines (status line cleared immediately)
+- [x] Starting with `--verbose` flag still works as before (no timer callback created)
+- [x] Timer internally tracks elapsed time correctly regardless of display state
+- [x] All existing tests pass (1167 passing; 3 pre-existing failures in validation.test.ts and claude-runner-interactive.test.ts are unrelated)
+
+## Notes
+
+- The fix is minimal: just 4 lines added to the existing `onTick` callback
+- The `statusLine.clear()` call happens on every tick while verbose is on, which is safe because the clear operation is idempotent
+- The next tick after toggling verbose OFF will immediately show the correct elapsed time since the timer tracks time independently
+
+<promise>COMPLETE</promise>

package/RAF/ahtahs-token-reaper/plans/01-extend-token-tracker-data-model.md

@@ -0,0 +1,36 @@
+# Task: Extend TokenTracker to store per-attempt usage data
+
+## Objective
+Refactor TokenTracker to accept and store an array of per-attempt UsageData entries per task, instead of a single UsageData.
+
+## Context
+Currently TokenTracker stores one `UsageData` per task via `addTask(taskId, usage)`. When a task retries, only the last attempt's data reaches the tracker. To fix underreporting, the tracker needs to accept multiple attempt entries per task and compute totals from all of them.
+
+## Requirements
+- Change `TaskUsageEntry` to hold an array of attempt `UsageData` entries alongside the aggregated totals
+- Update `addTask()` to accept an array of `UsageData` (one per attempt) instead of a single `UsageData`
+- The per-entry `usage` field should be the sum of all attempts (for backward compatibility with `getTotals()`)
+- The per-entry `cost` field should be the sum of all attempts' costs
+- Store the raw per-attempt data so formatting functions can display breakdowns
+- `getTotals()` should continue to work correctly — it already sums across entries, so as long as each entry's `usage` is the accumulated total, no changes needed there
+- Add a helper method or utility to merge/accumulate multiple `UsageData` objects into one
+- Maintain backward compatibility: if only one attempt occurred, behavior is identical to today
+- Cover changes with unit tests
+
+## Implementation Steps
+1. Add an `attempts` field to `TaskUsageEntry` that stores the array of individual `UsageData` objects
+2. Create an `accumulateUsage()` utility that merges multiple `UsageData` into a single combined `UsageData` (summing all token fields and merging `modelUsage` maps)
+3. Update `addTask()` signature to accept `UsageData[]` — it calls `accumulateUsage()` to compute the combined `usage` and `calculateCost()` on the combined result
+4. Update existing tests and add new tests for multi-attempt accumulation
+
+## Acceptance Criteria
+- [ ] `TaskUsageEntry` has an `attempts: UsageData[]` field
+- [ ] `addTask()` accepts an array and correctly accumulates tokens across attempts
+- [ ] `accumulateUsage()` correctly sums all token fields including per-model breakdowns
+- [ ] `getTotals()` returns correct grand totals when tasks have multiple attempts
+- [ ] Single-attempt tasks behave identically to before
+- [ ] All existing and new tests pass
+
+## Notes
+- The `accumulateUsage()` helper should handle merging `modelUsage` maps where different attempts may use different models (e.g., attempt 1 uses Opus, retry uses Sonnet via fallback)
+- Keep `calculateCost()` unchanged — it operates on a single `UsageData` which is the accumulated total

package/RAF/ahtahs-token-reaper/plans/02-accumulate-usage-in-retry-loop.md

@@ -0,0 +1,36 @@
+# Task: Accumulate usage data across retry attempts in the retry loop
+
+## Objective
+Change the retry loop in `do.ts` to collect usage data from every attempt instead of overwriting it, and pass the full array to TokenTracker.
+
+## Context
+The retry loop in `src/commands/do.ts` (around line 908-1021) currently declares a single `lastUsageData` variable that gets overwritten on each retry attempt. After the loop, only the final attempt's data is passed to `tokenTracker.addTask()`. This must change to collect all attempts' data.
+
+## Dependencies
+01
+
+## Requirements
+- Replace the single `lastUsageData` variable with an array that collects `UsageData` from each attempt
+- Push each attempt's `usageData` into the array (when present) instead of overwriting
+- After the retry loop, pass the full array to `tokenTracker.addTask()` (using the new signature from task 01)
+- Both success and failure paths (lines ~1090 and ~1117) should pass the array
+- Handle edge case: some attempts may not produce `usageData` (timeout, crash) — skip those entries
+- Cover changes with tests
+
+## Implementation Steps
+1. Replace `let lastUsageData: UsageData | undefined` with `const attemptUsageData: UsageData[] = []`
+2. Inside the retry loop, change the overwrite (`lastUsageData = result.usageData`) to a push (`attemptUsageData.push(result.usageData)`) when `result.usageData` is defined
+3. Update the success path: call `tokenTracker.addTask(task.id, attemptUsageData)` when the array is non-empty
+4. Update the failure path: same change
+5. Add/update tests to verify accumulation across retries
+
+## Acceptance Criteria
+- [ ] Usage data from all retry attempts is collected in an array
+- [ ] The full array is passed to `tokenTracker.addTask()`
+- [ ] Attempts with no usage data (timeout/crash) are excluded from the array
+- [ ] Single-attempt tasks still work correctly (array of length 1)
+- [ ] All tests pass
+
+## Notes
+- The variable `lastOutput` should remain as-is (overwritten each attempt) since only the final output matters for result parsing
+- Look at the `result.output` fallback path (line 971-974) — the old code had a fallback where `lastUsageData = result.output` which seems like a type issue; clean this up if it's not needed