rafcode 2.5.1 → 3.2.1

package/RAF/{ahslfe-config-wizard/plans/02-refactor-codebase-to-use-config.md → 28-config-wizard/plans/2-refactor-codebase-to-use-config.md}

@@ -7,7 +7,7 @@ Replace all hardcoded settings throughout the codebase with config lookups using
 The codebase has hardcoded model names, effort levels, timeouts, commit formats, and other settings scattered across many files. This task wires everything up to use the centralized config system.
 
 ## Dependencies
-01
+1
 
 ## Requirements
 - Every previously hardcoded user-facing setting must read from config

package/RAF/{ahslfe-config-wizard/plans/03-create-config-documentation.md → 28-config-wizard/plans/3-create-config-documentation.md}

@@ -7,7 +7,7 @@ Create a comprehensive config documentation file bundled in the package that ser
 The `raf config` command will spawn an interactive Claude session that needs full knowledge of the config schema, valid values, defaults, and how to edit the file. This documentation serves double duty: it's readable by users and injected as a system prompt for Claude during config sessions.
 
 ## Dependencies
-01
+1
 
 ## Requirements
 - File location: `src/prompts/config-docs.md` (bundled in package, versioned with code)

package/RAF/{ahslfe-config-wizard/plans/04-implement-raf-config-command.md → 28-config-wizard/plans/4-implement-raf-config-command.md}

@@ -7,7 +7,7 @@ Create the `raf config [prompt]` CLI command that launches an interactive Claude
 Users need a natural-language way to modify their config. This command spawns Claude Sonnet with the config documentation as a system prompt, giving it full knowledge of the schema. It also supports `--reset` to restore defaults.
 
 ## Dependencies
-01, 02, 03
+1, 2, 3
 
 ## Requirements
 

package/RAF/{ahslfe-config-wizard/plans/05-update-claude-md.md → 28-config-wizard/plans/5-update-claude-md.md}

@@ -7,7 +7,7 @@ Update CLAUDE.md with the new config system architecture, the "configurable by d
 CLAUDE.md serves as the project's internal documentation and instruction set. It needs to reflect the new config system so that future Claude sessions (planning, execution) understand how config works. The user also wants an explicit architectural principle: if a feature can be configurable, it should be configurable via config.
 
 ## Dependencies
-01, 02, 03, 04
+1, 2, 3, 4
 
 ## Requirements
 

package/RAF/{ahstvo-token-tracker/plans/03-unify-stream-json-execution.md → 29-token-tracker/plans/3-unify-stream-json-execution.md}

@@ -7,7 +7,7 @@ Switch all task execution modes to use `--output-format stream-json --verbose` s
 Currently `claude-runner.ts` has two execution methods: `run()` (plain text stdout) and `runVerbose()` (stream-json with tool display). Token usage data is only available in stream-json's `result` event. To enable token tracking, all execution must use stream-json format. The difference between verbose and non-verbose becomes purely a display concern — whether tool descriptions are printed to the console.
 
 ## Dependencies
-01
+1
 
 ## Requirements
 - All task execution uses `--output-format stream-json --verbose` flags

package/RAF/{ahstvo-token-tracker/plans/04-token-tracking-cost-calculation.md → 29-token-tracker/plans/4-token-tracking-cost-calculation.md}

@@ -7,7 +7,7 @@ Implement token usage accumulation across tasks and cost calculation using confi
 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
+1, 3
 
 ## Requirements
 - Add pricing config to the RAF config schema with current prices as defaults

package/RAF/{ahstvo-token-tracker/plans/05-token-cost-console-reporting.md → 29-token-tracker/plans/5-token-cost-console-reporting.md}

@@ -7,7 +7,7 @@ Display per-task token usage and cost estimates after each task, and a grand tot
 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
+4
 
 ## Requirements
 - After each task completes, print a concise usage summary line to the console

package/RAF/{ahstvo-token-tracker/plans/06-runtime-verbose-toggle.md → 29-token-tracker/plans/6-runtime-verbose-toggle.md}

@@ -7,7 +7,7 @@ Allow users to press Tab during task execution to toggle verbose mode on/off in
 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
+3
 
 ## Requirements
 - During non-interactive task execution (`raf do`), listen for Tab keypress on `process.stdin`

package/RAF/{ahtahs-token-reaper/plans/02-accumulate-usage-in-retry-loop.md → 30-token-reaper/plans/2-accumulate-usage-in-retry-loop.md}

@@ -7,7 +7,7 @@ Change the retry loop in `do.ts` to collect usage data from every attempt instea
 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
+1
 
 ## Requirements
 - Replace the single `lastUsageData` variable with an array that collects `UsageData` from each attempt

package/RAF/{ahtahs-token-reaper/plans/03-per-attempt-display-formatting.md → 30-token-reaper/plans/3-per-attempt-display-formatting.md}

@@ -7,7 +7,7 @@ Update `formatTaskTokenSummary()` to display a per-attempt breakdown when a task
 With tasks 01 and 02 complete, the `TaskUsageEntry` now contains an `attempts` array with per-attempt `UsageData`. The formatting function needs to render this breakdown so users can see token consumption per retry attempt.
 
 ## Dependencies
-01, 02
+1, 2
 
 ## Requirements
 - When a task has only 1 attempt, output is identical to the current format (no visual change)

package/RAF/{ahvrih-rate-forge/plans/03-rate-limit-estimation.md → 31-rate-forge/plans/3-rate-limit-estimation.md}

@@ -4,7 +4,7 @@
 Add an estimated percentage of the 5-hour rate limit window consumed, displayed after each task and in the grand total summary. Also add token usage tracking and display for `raf plan` interactive sessions.
 
 ## Dependencies
-02
+2
 
 ## Context
 Anthropic's subscription plans use a shared credit pool per 5-hour window. The pool is measured in cost-weighted credits, not raw token count. Heavier models (Opus) consume the pool faster than lighter ones (Haiku) in proportion to their API pricing ratios. Users need visibility into how much of their 5-hour window they've consumed during a RAF session.

package/RAF/{ahvrih-rate-forge/plans/06-sync-readme-with-codebase.md → 31-rate-forge/plans/6-sync-readme-with-codebase.md}

@@ -7,7 +7,7 @@ Fix critical discrepancies between README.md and the actual codebase implementat
 The README documents features that no longer exist (like `--merge` flag) and is missing documentation for major features (post-execution picker, PR creation). This causes user confusion and makes the tool harder to adopt.
 
 ## Dependencies
-01, 05
+1, 5
 
 ## Requirements
 Fix these three critical discrepancies:

package/RAF/{ahvrih-rate-forge/plans/08-plan-execution-metadata.md → 31-rate-forge/plans/8-plan-execution-metadata.md}

@@ -13,7 +13,7 @@ The existing `effort.*` config section (which maps to Claude CLI's `--effort` fl
 Additionally, the planning prompts currently contain restrictive wording that discourages implementation details in plans. This wording should be removed to allow the planning model to include whatever level of detail it deems appropriate.
 
 ## Dependencies
-04
+4
 
 ## Requirements
 

package/RAF/{ahwidh-quick-fix-gremlin/plans/06-sync-worktree-branch-before-execution.md → 32-quick-fix-gremlin/plans/6-sync-worktree-branch-before-execution.md}

@@ -6,7 +6,7 @@ effort: medium
 Before executing tasks in a worktree, rebase the worktree branch onto the latest main branch to ensure it's up-to-date.
 
 ## Dependencies
-03
+3
 
 ## Context
 When using `raf do` in worktree mode, the worktree branch may be behind main (e.g., if other worktree projects were merged into main since this branch was created). Rebasing before execution ensures the branch starts from the latest main, reducing merge conflicts later.

package/RAF/{ahwqwq-model-whisperer/plans/03-add-plan-resume-flag.md → 33-model-whisperer/plans/3-add-plan-resume-flag.md}

@@ -18,7 +18,7 @@ Planning sessions are persisted by Claude CLI as `.jsonl` files under `~/.claude
 - If no worktree path exists and the project used worktree mode, show helpful error
 
 ## Dependencies
-01
+1
 
 ## Implementation Steps
 

package/RAF/{ahwvrz-legacy-sunset/plans/02-fix-resume-worktree-resolution.md → 34-legacy-sunset/plans/2-fix-resume-worktree-resolution.md}

@@ -12,7 +12,7 @@ Running `raf plan --resume ahwvrz-legacy-sunset --worktree` from the main branch
 The `--amend` command already handles this correctly by searching worktree directories first. The `--resume` command needs the same treatment, plus auto-detection so `--worktree` is optional.
 
 ## Dependencies
-01
+1
 
 ## Requirements
 - `runResumeCommand()` must search worktree directories in addition to the main repo

package/RAF/{ahwzmc-echo-forge/plans/03-update-readme.md → 35-echo-forge/plans/3-update-readme.md}

@@ -10,7 +10,7 @@ Enhance the README to better communicate RAF's value proposition and clarify the
 The current README is functional but undersells RAF's capabilities. Key benefits like smart model selection, automatic PR generation, and structured decision-making are buried or absent. The difference between `--amend` (add tasks to a project) and `--resume` (resume a Claude session) is not explained.
 
 ## Dependencies
-01, 02
+1, 2
 
 ## Requirements
 - Rewrite the "Why RAF?" section to better highlight RAF's advanced capabilities

package/RAF/37-flux-weave/decisions.md

@@ -0,0 +1,22 @@
+# Project Decisions
+
+## Should existing projects with base26 IDs be migrated to numeric IDs?
+No migration needed. No need to support old base26 project IDs — consider it a fresh start.
+
+## Should numeric project IDs be zero-padded (e.g., 001-foo) or unpadded (1-foo)?
+No padding. Use simple unpadded numbers: 1-foo, 2-bar, 10-buz, 101-bar.
+
+## When amend produces no new plans but updates decisions/input/plans, what commit message format?
+Use the existing 'Amend' format: `RAF[id] Amend: project-name`.
+
+## For auto-detecting existing projects on `raf plan project-name`, should it use exact or fuzzy matching?
+Exact match only. Only prompt if a project with the exact same name exists.
+
+## Should task IDs follow the same numeric approach as project IDs?
+Yes, same approach — no padding, no migration, fresh start.
+
+## When creating a new project, should we scan all worktrees + main for the highest ID?
+Yes, scan all. Scan main repo RAF/ folder + all worktree RAF/ folders to find the highest numeric ID, then increment.
+
+## Should gaps in the ID sequence be filled or left as-is?
+Gaps are fine. If projects 1, 2, 3, 5 exist, next project is 6 (not 4). Always use max + 1.

package/RAF/37-flux-weave/input.md

@@ -0,0 +1,4 @@
+- [ ] if plan amend has no new plans but decisions, input and plans are update(or any of those) - commit amended changes.
+- [ ] if command is like "raf plan project-name" - make sure to check if project with exact name exist (in main or worktree) and prompt to user whether he wants to amend (probably forgot to put --amend flag)
+- [ ] switch project ids to numbers starting with single numbers (1-foo, 2-bar, ..., 10-buz, 101-bar). don't rely that id is uniq, but make mechanism to not create duplicate ids even if project created in workspace (search all worktrees + main and increment largest id), not alpha chars in id, only numbers
+- [ ] switch task ids to numeric like(1-foo, 2-bar, ..., 10-buz, 101-bar)

package/RAF/37-flux-weave/outcomes/1-numeric-project-ids.md

@@ -0,0 +1,32 @@
+# Outcome: Switch Project IDs to Numeric
+
+## Summary
+Replaced the epoch-based base26 project ID system with sequential numeric IDs (1, 2, 3, ...).
+
+## Key Changes
+
+### Source files modified:
+- **`src/utils/paths.ts`** — Complete rewrite of ID system: removed `encodeBase26`, `decodeBase26`, `isBase26Prefix`, `RAF_EPOCH`, `ID_WIDTH`, `BASE26_ALPHABET`. `getNextProjectNumber()` now scans main RAF dir + worktrees for max ID and returns max+1 (or 1 if no projects). `formatProjectNumber()` returns plain number string. `extractProjectNumber()` extracts numeric prefix. `parseProjectPrefix()` parses numeric strings. All regex patterns updated from `[a-z]{6}` to `\d+`.
+- **`src/core/worktree.ts`** — Updated `resolveWorktreeProjectByIdentifier()` to match by numeric prefix instead of base26.
+- **`src/core/state-derivation.ts`** — Updated `discoverProjects()` to use numeric folder pattern.
+- **`src/utils/validation.ts`** — Updated `validateProjectExists()` regex.
+- **`src/commands/plan.ts`** — Pass `repoBasename` to `getNextProjectNumber()` for worktree scanning.
+- **`src/commands/status.ts`** — Updated help text for identifier argument.
+- **`src/ui/project-picker.ts`** — No logic changes needed (uses updated functions).
+- **`README.md`** — Updated project structure documentation.
+
+### Test files updated (25 files):
+All test files updated to use numeric project IDs instead of base26 IDs.
+
+## Acceptance Criteria Verification
+- [x] New projects get sequential numeric IDs starting from 1
+- [x] `getNextProjectNumber()` scans all worktrees + main to find the highest ID
+- [x] Project folders are named `{number}-{name}` (e.g., `3-auth-system`)
+- [x] `raf plan` creates projects with numeric IDs
+- [x] `raf plan --amend 3` resolves project by numeric ID
+- [x] `raf status` displays projects with numeric IDs correctly
+- [x] Commit messages use numeric IDs: `RAF[3] Plan: auth-system`
+- [x] Worktree paths use numeric IDs
+- [x] All tests pass (1239/1240 — 1 pre-existing failure in name-generator.test.ts unrelated to this change)
+
+<promise>COMPLETE</promise>

package/RAF/37-flux-weave/outcomes/2-numeric-task-ids.md

@@ -0,0 +1,34 @@
+# Outcome: Switch Task IDs to Numeric
+
+## Summary
+Replaced the base36 two-character task ID system with sequential numeric IDs (1, 2, 3, ...) matching the project ID format from task 01.
+
+## Key Changes
+
+### Source files modified:
+- **`src/utils/paths.ts`** — Rewrote task ID system: `TASK_ID_PATTERN` changed from `[0-9a-z]{2}` to `\d+`. `encodeTaskId()` now returns plain `num.toString()`. `decodeTaskId()` now uses `parseInt(str, 10)` with `\d+` validation. Removed `TASK_ID_WIDTH` constant and 1296 max limit. `extractTaskNameFromPlanFile()` regex updated from `^[0-9a-z]{2}-` to `^\d+-`.
+- **`src/core/state-derivation.ts`** — Updated comments from "2-char base36" to "numeric". No logic changes needed (uses `TASK_ID_PATTERN` which was updated).
+- **`src/prompts/execution.ts`** — Changed task number encoding from `taskNumber.toString(36).padStart(2, '0')` to `taskNumber.toString()`.
+- **`src/prompts/planning.ts`** — Updated all examples from `01-`, `02-` to `1-`, `2-`. Updated dependency format examples from `"01, 02"` to `"1, 2"`. Updated task summary examples.
+- **`src/prompts/amend.ts`** — Updated dependency format examples and task numbering references.
+- **`src/commands/plan.ts`** — Updated comment from "decode base36" to "numeric".
+
+### Test files updated (7 files):
+- `tests/unit/paths.test.ts` — Updated `extractTaskNameFromPlanFile` tests for numeric IDs
+- `tests/unit/state-derivation.test.ts` — Updated all plan/outcome filenames and dependency references
+- `tests/unit/execution-prompt.test.ts` — Updated commit format expectations and task ID references
+- `tests/unit/plan-command.test.ts` — Updated all task IDs, filenames, and amend prompt expectations
+- `tests/unit/dependency-integration.test.ts` — Updated all task IDs, dependencies, and filenames
+- `tests/unit/config.test.ts` — Updated task ID in renderCommitMessage test
+- `tests/unit/planning-prompt.test.ts` — Updated plan file path and numbering expectations
+
+## Acceptance Criteria Verification
+- [x] Plan files are created as `1-task-name.md`, `2-task-name.md`, etc.
+- [x] `encodeTaskId(5)` returns `"5"` (not `"05"`)
+- [x] `decodeTaskId("12")` returns `12`
+- [x] Amend flow correctly finds max task number and increments
+- [x] Task commit messages show numeric IDs: `RAF[3:2] Task description`
+- [x] Dependency references in plan frontmatter work with numeric IDs
+- [x] All tests pass (1239/1240 — 1 pre-existing failure in name-generator.test.ts unrelated to this change)
+
+<promise>COMPLETE</promise>

package/RAF/37-flux-weave/outcomes/3-amend-commit-without-new-plans.md

@@ -0,0 +1,23 @@
+# Outcome: Commit Amended Changes When No New Plans Are Created
+
+## Summary
+Fixed the amend flow to always attempt committing after a successful Claude session, regardless of whether new plan files were created. Previously, commits were skipped when no new plans were added, even if decisions.md, input.md, or existing plan files were modified.
+
+## Key Changes
+
+### Source files modified:
+- **`src/commands/plan.ts`** (lines 629-655) — Restructured the post-session logic in `runAmendCommand()`:
+  - Moved `commitPlanningArtifacts()` call outside the `newPlanFiles.length > 0` conditional block
+  - Changed `additionalFiles` from only new plan files to ALL plan files (so modifications to existing plans are staged)
+  - The existing `git diff --cached` check in `commitPlanningArtifacts()` naturally prevents empty commits when nothing changed
+
+## Acceptance Criteria Verification
+- [x] `raf plan --amend` commits when decisions.md is updated but no new plans created — `commitPlanningArtifacts` always stages decisions.md and calls commit
+- [x] `raf plan --amend` commits when existing plan files are modified but no new plans created — all plan files are now staged via `allPlanAbsolutePaths`
+- [x] `raf plan --amend` commits when input.md is updated but no new plans created — `commitPlanningArtifacts` always stages input.md
+- [x] `raf plan --amend` does NOT create an empty commit when nothing changed — `commitPlanningArtifacts` checks `git diff --cached` before committing
+- [x] `raf plan --amend` still commits normally when new plan files ARE created — all plan files are staged regardless
+- [x] Commit message uses 'Amend' format in all cases — `isAmend: true` is always passed
+- [x] All tests pass (1239/1240 — 1 pre-existing failure in name-generator.test.ts unrelated to this change)
+
+<promise>COMPLETE</promise>

package/RAF/37-flux-weave/outcomes/4-auto-detect-existing-project.md

@@ -0,0 +1,30 @@
+# Outcome: Auto-Detect Existing Project on `raf plan project-name`
+
+## Summary
+When `raf plan project-name` is run (without `--amend`) and a project with that name already exists, the user is now prompted interactively: amend it, create a new project, or cancel. Previously the command would just exit with an error.
+
+## Key Changes
+
+### `src/commands/plan.ts`
+- Added `import { select } from '@inquirer/prompts'`
+- Removed the old hard-error check (`resolveProjectIdentifier` → exit 1)
+- Replaced with a prompt-based flow (in non-auto mode):
+  1. Checks main RAF dir with `resolveProjectIdentifierWithDetails`
+  2. Falls back to checking worktrees with `resolveWorktreeProjectByIdentifier`
+  3. If a match is found, shows a `select` prompt: "Yes, amend it" / "No, create a new project" / "Cancel"
+  4. "Yes" → calls `runAmendCommand` with the existing folder name (and `worktreeMode=true` if it's a worktree project)
+  5. "Cancel" → `process.exit(0)`
+  6. "No" / auto mode → continues with normal project creation
+- Removed unused `resolveProjectIdentifier` import
+
+## Acceptance Criteria Verification
+- [x] `raf plan my-project` detects existing project named "my-project" and prompts — uses name-based lookup in `resolveProjectIdentifierWithDetails`
+- [x] Exact match only — "my" does NOT match "my-project" — name comparison is exact (just case-insensitive)
+- [x] Case-insensitive matching — "My-Project" matches "my-project" — both `resolveProjectIdentifierWithDetails` and `resolveWorktreeProjectByIdentifier` use `.toLowerCase()`
+- [x] User can choose to amend, create new, or cancel — three choices in the select prompt
+- [x] Choosing amend redirects to the amend flow correctly — calls `runAmendCommand(existingFolder, model, autoMode, existingWorktreeMode)`
+- [x] Projects in worktrees are also detected — checks `resolveWorktreeProjectByIdentifier` when not found in main
+- [x] `raf plan --amend` is not affected — the new check only runs in `runPlanCommand`, not `runAmendCommand`
+- [x] All tests pass (1239/1240 — 1 pre-existing failure in name-generator.test.ts unrelated to this change)
+
+<promise>COMPLETE</promise>

package/RAF/37-flux-weave/plans/1-numeric-project-ids.md

@@ -0,0 +1,75 @@
+---
+effort: high
+---
+# Task: Switch Project IDs to Numeric
+
+## Objective
+Replace the epoch-based base26 project ID system with sequential numeric IDs (1, 2, 3, ...) that are unique across all worktrees and the main repo.
+
+## Context
+Currently project IDs are 6-character base26 strings derived from Unix timestamps (e.g., "apaerm"). This is hard to read and type. Switching to simple incrementing numbers (1-foo, 2-bar, 10-buz) makes projects easier to reference. No migration of existing projects is needed — treat this as a fresh start. No need to maintain backward compatibility with base26 IDs.
+
+## Requirements
+- Project folder format: `{number}-{name}` (e.g., `1-my-project`, `12-auth-system`)
+- No zero-padding on the number
+- Numbers are only digits — no alpha characters in the ID portion
+- To find the next ID: scan ALL worktrees + main repo's `RAF/` folder for the highest existing numeric ID, then increment by 1
+- If no projects exist, start at 1
+- Project ID uniqueness must be maintained even when projects are created in different worktrees
+- Gaps in the sequence are fine (e.g., 1, 2, 3, 5 → next is 6, not 4). Always use `max(existing IDs) + 1`, never fill gaps
+
+## Implementation Steps
+
+1. **Replace ID encoding/decoding in `src/utils/paths.ts`:**
+   - Remove `encodeBase26()`, `decodeBase26()`, and `RAF_EPOCH` constant
+   - Replace `getNextProjectNumber()` to:
+     - Scan `RAF/` in the main repo for folders matching `^\d+-`
+     - Scan all worktree directories at `~/.raf/worktrees/{repoBasename}/` for folders matching `^\d+-`
+     - Extract the numeric prefix from each folder name
+     - Return `max + 1` (or `1` if none found)
+   - Update `extractProjectNumber()` to extract the numeric prefix (everything before the first `-`)
+
+2. **Update project folder creation in `src/commands/plan.ts`:**
+   - Where `getNextProjectNumber()` is called, use the new numeric ID
+   - Update folder naming from `{base26Id}-{name}` to `{numericId}-{name}`
+
+3. **Update project resolution in `src/utils/paths.ts`:**
+   - `resolveProjectIdentifierWithDetails()` — update matching logic:
+     - Full folder name match (exact)
+     - Numeric prefix match (e.g., input "5" matches "5-auth-system")
+     - Project name match (case-insensitive)
+   - Remove base26-specific matching logic
+
+4. **Update worktree project resolution in `src/core/worktree.ts`:**
+   - `resolveWorktreeProjectByIdentifier()` — same matching changes as above
+   - `computeWorktreePath()` — uses projectId which is now numeric
+   - Update any regex patterns that expect 6-char base26 IDs
+
+5. **Update commit message rendering in `src/utils/config.ts`:**
+   - `renderCommitMessage()` uses `{projectId}` — ensure it works with numeric IDs (should work as-is since it's just string interpolation)
+
+6. **Update `src/core/git.ts`:**
+   - `extractProjectNumber()` or similar functions that parse folder names for the ID portion
+
+7. **Update `src/commands/status.ts`:**
+   - Project listing/display — ensure numeric IDs render correctly
+
+8. **Update any regex patterns across the codebase** that assume project IDs are 6-character lowercase alpha strings (e.g., `[a-z]{6}` patterns).
+
+9. **Update tests** in `tests/` that reference base26 encoding/decoding or use base26 project IDs in fixtures.
+
+## Acceptance Criteria
+- [ ] New projects get sequential numeric IDs starting from 1
+- [ ] `getNextProjectNumber()` scans all worktrees + main to find the highest ID
+- [ ] Project folders are named `{number}-{name}` (e.g., `3-auth-system`)
+- [ ] `raf plan` creates projects with numeric IDs
+- [ ] `raf plan --amend 3` resolves project by numeric ID
+- [ ] `raf status` displays projects with numeric IDs correctly
+- [ ] Commit messages use numeric IDs: `RAF[3] Plan: auth-system`
+- [ ] Worktree paths use numeric IDs
+- [ ] All tests pass
+
+## Notes
+- The `getNextProjectNumber()` function needs access to the git repo root to scan `RAF/` and to `~/.raf/worktrees/` to scan worktrees. It may need the repo basename as a parameter.
+- No backward compatibility with base26 IDs is required — this is a clean break.
+- The worktree scan should handle the case where `~/.raf/worktrees/{repoBasename}/` doesn't exist yet.

package/RAF/37-flux-weave/plans/2-numeric-task-ids.md

@@ -0,0 +1,65 @@
+---
+effort: medium
+---
+# Task: Switch Task IDs to Numeric
+
+## Objective
+Replace the base36 two-character task ID system with sequential numeric IDs (1, 2, 3, ...) matching the same format as the new project IDs.
+
+## Context
+Task IDs are currently 2-character base36 strings (e.g., "01", "0a", "10"). This is confusing because "0a" looks like hex and "10" means 36 in base36. Switching to simple sequential numbers (1-setup-db, 2-create-api, 10-write-tests) is more intuitive. No migration needed — fresh start.
+
+## Dependencies
+1
+
+## Requirements
+- Plan file format: `{number}-{task-name}.md` (e.g., `1-setup-database.md`, `12-write-tests.md`)
+- No zero-padding on the number
+- Only digits in the ID portion — no alpha characters
+- Task numbering starts at 1 within each project
+- The amend flow must find the max existing task number and continue from there
+
+## Implementation Steps
+
+1. **Replace task ID encoding/decoding in `src/utils/paths.ts`:**
+   - Replace `encodeTaskId(num)` — now just returns `num.toString()` (no base36, no padding)
+   - Replace `decodeTaskId(str)` — now just does `parseInt(str, 10)`
+   - Update the regex pattern that extracts task IDs from filenames: change from `^[0-9a-z]{2}-` to `^\d+-`
+   - Remove the 1296 (36*36) max limit — numeric IDs have no practical limit
+
+2. **Update plan file parsing in `src/core/state-derivation.ts`:**
+   - `parsePlanFiles()` or equivalent — update regex to match `^\d+-` prefix
+   - Task ID extraction from filenames
+   - Dependency parsing (dependencies reference task IDs like "01, 02" — now "1, 2")
+
+3. **Update the amend flow in `src/commands/plan.ts`:**
+   - Where `decodeTaskId()` is called to find max task number — use new numeric decode
+   - Where `encodeTaskId()` is called to generate next task number — use new numeric encode
+   - Update the amend template that shows existing tasks and next task number
+
+4. **Update commit message rendering:**
+   - Task commit format `{prefix}[{projectId}:{taskId}]` — ensure numeric task IDs work (e.g., `RAF[3:5] Setup database`)
+
+5. **Update the planning prompt in `src/prompts/planning.ts`:**
+   - The prompt tells Claude to create plan files numbered "01, 02, 03" — update to "1, 2, 3"
+   - Update any examples that show base36 task IDs
+
+6. **Update the amend prompt in `src/prompts/amend.ts`:**
+   - References to task ID format and next task number
+
+7. **Update frontmatter parsing in `src/utils/frontmatter.ts`** if it references task ID format.
+
+8. **Update tests** that use base36 task IDs.
+
+## Acceptance Criteria
+- [ ] Plan files are created as `1-task-name.md`, `2-task-name.md`, etc.
+- [ ] `encodeTaskId(5)` returns `"5"` (not `"05"`)
+- [ ] `decodeTaskId("12")` returns `12`
+- [ ] Amend flow correctly finds max task number and increments
+- [ ] Task commit messages show numeric IDs: `RAF[3:2] Task description`
+- [ ] Dependency references in plan frontmatter work with numeric IDs
+- [ ] All tests pass
+
+## Notes
+- This task follows the same pattern as task 01 (numeric project IDs) but is scoped to task IDs within a project.
+- The planning prompt instructs Claude on the file naming convention, so it must be updated to tell Claude to use numeric prefixes.

package/RAF/37-flux-weave/plans/3-amend-commit-without-new-plans.md

@@ -0,0 +1,54 @@
+---
+effort: medium
+---
+# Task: Commit Amended Changes When No New Plans Are Created
+
+## Objective
+Fix the amend flow to commit changes even when no new plan files are created, as long as decisions.md, input.md, or existing plan files were updated.
+
+## Context
+Currently, `commitPlanningArtifacts()` in the amend flow only commits if new plan files were created. But an amend session might only update decisions.md, modify existing plans, or update input.md without adding new tasks. These changes should still be committed with the 'Amend' format commit message.
+
+## Dependencies
+1
+
+## Requirements
+- When `raf plan --amend` runs and the Claude session completes, commit if ANY of these changed:
+  - `input.md` was updated (new task description appended)
+  - `decisions.md` was updated (new Q&A pairs added)
+  - Existing plan files in `plans/` were modified
+- Use the existing 'Amend' commit message format: `RAF[id] Amend: project-name`
+- If truly nothing changed (no file modifications at all), don't create an empty commit
+
+## Implementation Steps
+
+1. **Examine `commitPlanningArtifacts()` in `src/core/git.ts`** (around line 228):
+   - Currently it receives a list of new plan files and stages them alongside input.md and decisions.md
+   - The issue is likely in how the amend flow in `plan.ts` decides whether to call commit — it may skip the call when no new plan files are detected
+
+2. **Examine the amend flow in `src/commands/plan.ts`** (around line 616-646):
+   - After the Claude session, it checks for new plan files (those with ID >= nextTaskNumber)
+   - If no new plan files are found, it likely skips the commit step
+   - Fix: always attempt to commit after a successful amend session, regardless of whether new plan files were created
+
+3. **Update the commit logic:**
+   - Always stage `input.md` and `decisions.md` (they're almost always updated during amend)
+   - Stage any modified plan files in the `plans/` directory (use `git diff --name-only` or stage the entire plans directory)
+   - Call `commitPlanningArtifacts()` even when the new plan files list is empty
+   - The existing `git diff --cached` check before commit will naturally prevent empty commits
+
+4. **Test the flow:**
+   - Verify that an amend session that only updates decisions still commits
+   - Verify that an amend session with no changes at all doesn't create an empty commit
+
+## Acceptance Criteria
+- [ ] `raf plan --amend` commits when decisions.md is updated but no new plans created
+- [ ] `raf plan --amend` commits when existing plan files are modified but no new plans created
+- [ ] `raf plan --amend` commits when input.md is updated but no new plans created
+- [ ] `raf plan --amend` does NOT create an empty commit when nothing changed
+- [ ] `raf plan --amend` still commits normally when new plan files ARE created
+- [ ] Commit message uses 'Amend' format in all cases
+
+## Notes
+- The `commitPlanningArtifacts()` function already has a `git diff --cached` check that prevents empty commits, so the main fix is ensuring the amend flow always calls commit rather than short-circuiting when no new plans are detected.
+- This depends on task 01 because project ID format changes may affect how `commitPlanningArtifacts` resolves the project ID for the commit message.

package/RAF/37-flux-weave/plans/4-auto-detect-existing-project.md

@@ -0,0 +1,52 @@
+---
+effort: low
+---
+# Task: Auto-Detect Existing Project on `raf plan project-name`
+
+## Objective
+When a user runs `raf plan project-name` without `--amend`, check if a project with that exact name already exists and prompt whether they want to amend it instead.
+
+## Context
+Users sometimes forget to add the `--amend` flag when they want to add tasks to an existing project. Currently, `raf plan project-name` would either create a duplicate or fail. Instead, we should detect the existing project and ask the user if they meant to amend.
+
+## Dependencies
+1
+
+## Requirements
+- Only check for exact name matches (case-insensitive)
+- Search both main repo and all worktrees for the existing project
+- If found, prompt the user: "Project 'project-name' already exists (ID: X). Did you mean to amend it?"
+- If user says yes, redirect to the amend flow
+- If user says no, proceed with creating a new project (or abort — user's choice)
+
+## Implementation Steps
+
+1. **In `src/commands/plan.ts`, in `runPlanCommand()`** (around line 109):
+   - After the project name is determined but before creating the project folder
+   - Check if a project with the exact same name exists using `resolveProjectIdentifierWithDetails()` searching by name
+   - Also check worktrees using `resolveWorktreeProjectByIdentifier()`
+
+2. **Add the user prompt:**
+   - Use the existing interactive prompt pattern (inquirer or similar) already used in the codebase
+   - Show: "Project '{name}' already exists (ID: {id}). Did you want to amend it?"
+   - Options: "Yes, amend it" / "No, create a new project" / "Cancel"
+   - If "Yes", call `runAmendCommand()` with the existing project's ID
+   - If "No", continue with normal project creation
+   - If "Cancel", exit
+
+3. **Handle worktree context:**
+   - If the existing project is in a worktree, the amend redirect should include `--worktree`
+   - If the existing project is in main, redirect without `--worktree`
+
+## Acceptance Criteria
+- [ ] `raf plan my-project` detects existing project named "my-project" and prompts
+- [ ] Exact match only — "my" does NOT match "my-project"
+- [ ] Case-insensitive matching — "My-Project" matches "my-project"
+- [ ] User can choose to amend, create new, or cancel
+- [ ] Choosing amend redirects to the amend flow correctly
+- [ ] Projects in worktrees are also detected
+- [ ] `raf plan --amend` is not affected by this change (no double-prompt)
+
+## Notes
+- This check should only happen in the `raf plan` flow (not `--amend` which already knows it's amending).
+- The prompt should be skipped if running in non-interactive mode (e.g., `--auto` / `-y` flag).

package/RAF/38-dual-wielder/decisions.md

@@ -0,0 +1,44 @@
+# Project Decisions
+
+## How should we handle Codex's lack of a --system-prompt flag?
+Prepend system prompt to user message. Concatenate the system prompt with the user message into a single prompt string.
+
+## Should Codex support extend to interactive planning or only execution?
+Both planning and execution. Support Codex for both `raf plan` and `raf do`.
+
+## How should the provider be selected?
+Global config + CLI override. Default provider in `raf.config.json`, overridable with `--provider` flag on commands.
+
+## What default Codex models should map to effort levels?
+- Low: `codex/gpt-5.3-codex-spark`
+- Medium: `codex/gpt-5.3-codex`
+- High: `codex/gpt-5.4`
+
+Use harness prefix format: `claude/opus`, `codex/gpt-5.4`, etc.
+
+## Should existing shorthand aliases require explicit prefixes?
+No. Unprefixed aliases default to claude/ prefix. Existing configs keep working — `opus` means `claude/opus`. Only codex models need the `codex/` prefix.
+
+## How should Codex interactive planning work?
+PTY spawn like Claude. Spawn `codex` (without exec) via PTY, passing the prompt with system prompt prepended to user message.
+
+## How should output parsing work for Codex?
+Separate parsers, shared interface. Keep parsing logic completely separate for each provider but ensure they expose the same output interface (status, tokens, messages).
+
+## How should `raf do` handle project scanning in worktree mode?
+Merge both worktree and main-repo projects in the picker. When a project exists in both, worktree version takes precedence (dedup). This makes worktree mode show the same unified list as standard mode.
+
+## What's wrong with the `raf plan` amend prompt?
+The existing project check is skipped in auto mode (`-y` flag). The condition `if (projectName && !autoMode)` at plan.ts line 118 bypasses the check entirely. Fix: run the existing project check even in auto mode. When `-y` is used and an existing project is found, either auto-select amend or still prompt (breaking out of auto mode for this safety check).
+
+## Should `raf plan --amend` and auto-detect accept numeric project IDs?
+Yes. Both the explicit `--amend <id>` flow and the auto-detect prompt (`raf plan <identifier>`) should resolve numeric IDs (e.g., `raf plan --amend 38` or `raf plan 38`). Resolution should check both main-repo and worktree projects, consistent with name resolution.
+
+## What kind of Codex testing should be done?
+E2E only — actually run `raf plan` and `raf do` with `--provider codex` against a real dummy Node.js project. No unit tests for now.
+
+## What scenarios should Codex E2E testing cover?
+All scenarios: `raf plan --provider codex`, `raf do --provider codex`, config/model resolution, error handling, and edge cases. Sequential execution is fine (no need for parallel agents).
+
+## How should issues found during Codex testing be handled?
+Document only. List all issues in the outcome file. User decides what to fix after reviewing.