rafcode 3.0.0 → 3.8.0

package/src/prompts/config-docs.md

@@ -13,7 +13,7 @@ The config file is a JSON object. All keys are optional at every level. User val
 ```json
 {
   "models": {
-    "plan": "opus"
+    "plan": { "model": "sonnet", "harness": "claude" }
   }
 }
 ```
@@ -24,50 +24,80 @@ The above only changes `models.plan` — all other model settings keep their def
 
 ### `models` — Model Selection
 
-Controls which model is used for each scenario. Values can be a short alias (`"sonnet"`, `"haiku"`, `"opus"`) or a full model ID.
+Controls which model and harness is used for each scenario. Each entry is a `ModelEntry` object with the following shape:
 
-**Model ID format**: Full model IDs follow the pattern `claude-{family}-{version}`, for example:
-- `"claude-opus-4-5-20251101"` — Opus 4.5 from November 2025
-- `"claude-opus-4-6"` — Opus 4.6 (latest)
-- `"claude-sonnet-4-5-20250929"` — Sonnet 4.5 from September 2025
-- `"claude-haiku-4-5-20251001"` — Haiku 4.5 from October 2025
+```json
+{ "model": "<model-name>", "harness": "<harness>", "reasoningEffort": "<effort>", "fast": true }
+```
+
+- **`model`** (required): A short alias (`"sonnet"`, `"haiku"`, `"opus"`) or a full model ID (e.g., `"claude-opus-4-6"`, `"gpt-5.4"`, `"o3"`).
+- **`harness`** (required): The CLI harness — `"claude"` or `"codex"`.
+- **`fast`** (optional): Enable fast mode for faster output. Claude only — uses the same model with ~2.5x faster responses at higher per-token cost. Default: `false`/omitted. Codex does not support fast mode; RAF warns and ignores `fast: true` on Codex entries.
+- **`reasoningEffort`** (optional): Controls reasoning depth. Accepted values differ by harness:
+  - **Claude** (`output_config.effort`): `"low"`, `"medium"`, `"high"` (default), `"max"` (Opus 4.6 only). Supported on Opus 4.5+, Sonnet 4.6+. Haiku does not support reasoning.
+  - **Codex** (`model_reasoning_effort`): `"none"`, `"minimal"`, `"low"`, `"medium"` (default), `"high"`, `"xhigh"`.
 
-**Short aliases**: Using aliases (`"opus"`, `"sonnet"`, `"haiku"`) automatically selects the latest version of that model family.
+**Claude model aliases**: `"opus"`, `"sonnet"`, `"haiku"` automatically select the latest version.
+**Known Codex models**: `"gpt-5.4"`, `"gpt-5.4-2026-03-05"` (pinned), `"gpt-5.4-pro"`, `"gpt-5.4-mini"`, `"gpt-5.4-nano"`, `"o3"`.
 
 | Key | Default | Description |
 |-----|---------|-------------|
-| `models.plan` | `"opus"` | Model used for planning sessions (`raf plan`) |
-| `models.execute` | `"opus"` | Ceiling model for task execution (`raf do`). Per-task models from effort frontmatter are capped to this tier. Also used as the fallback when a plan has no effort frontmatter. |
-| `models.nameGeneration` | `"sonnet"` | Model used for generating project names |
-| `models.failureAnalysis` | `"haiku"` | Model used for analyzing task failures |
-| `models.prGeneration` | `"sonnet"` | Model used for generating PR titles and descriptions |
-| `models.config` | `"sonnet"` | Model used for the interactive config editor (`raf config`) |
+| `models.plan` | `{ "model": "opus", "harness": "claude" }` | Model used for planning sessions (`raf plan`) |
+| `models.execute` | `{ "model": "opus", "harness": "claude" }` | Ceiling model for task execution (`raf do`). Per-task models from effort frontmatter are capped to this tier. Also used as the fallback when a plan has no effort frontmatter. |
+| `models.nameGeneration` | `{ "model": "sonnet", "harness": "claude" }` | Model used for generating project names |
+| `models.failureAnalysis` | `{ "model": "haiku", "harness": "claude" }` | Model used for analyzing task failures |
+| `models.prGeneration` | `{ "model": "sonnet", "harness": "claude" }` | Model used for generating PR titles and descriptions |
+| `models.config` | `{ "model": "sonnet", "harness": "claude" }` | Model used for the interactive config editor (`raf config wizard`) |
+
+**Partial overrides**: When deep-merging, you can override just the `model` or `harness` within an entry:
+
+```json
+{
+  "models": {
+    "execute": { "model": "gpt-5.4", "harness": "codex" }
+  }
+}
+```
 
 ### `effortMapping` — Task Effort to Model Mapping
 
-Maps task complexity labels (in plan frontmatter) to models. When a plan file has `effort: medium`, RAF resolves the execution model using this mapping.
+Maps task complexity labels (in plan frontmatter) to `ModelEntry` objects. When a plan file has `effort: medium`, RAF resolves the execution model using this mapping.
 
 | Key | Default | Description |
 |-----|---------|-------------|
-| `effortMapping.low` | `"sonnet"` | Model for low-complexity tasks |
-| `effortMapping.medium` | `"opus"` | Model for medium-complexity tasks |
-| `effortMapping.high` | `"opus"` | Model for high-complexity tasks |
+| `effortMapping.low` | `{ "model": "sonnet", "harness": "claude" }` | Model for low-complexity tasks |
+| `effortMapping.medium` | `{ "model": "opus", "harness": "claude" }` | Model for medium-complexity tasks |
+| `effortMapping.high` | `{ "model": "opus", "harness": "claude" }` | Model for high-complexity tasks |
 
-Values must be a short alias (`"sonnet"`, `"haiku"`, `"opus"`) or a full model ID.
+Each value is a `ModelEntry` object (same shape as `models.*` entries).
 
 **Interaction with `models.execute`**: The `models.execute` value acts as a ceiling. If a task's effort maps to a more expensive model than the ceiling, the ceiling model is used instead. This gives users budget control while allowing tasks to use cheaper models when appropriate.
 
 Example:
 ```json
 {
-  "models": { "execute": "sonnet" },
-  "effortMapping": { "low": "sonnet", "medium": "opus", "high": "opus" }
+  "models": { "execute": { "model": "sonnet", "harness": "claude" } },
+  "effortMapping": {
+    "low": { "model": "sonnet", "harness": "claude" },
+    "medium": { "model": "opus", "harness": "claude" },
+    "high": { "model": "opus", "harness": "claude" }
+  }
 }
 ```
 - Task with `effort: low` → sonnet (at ceiling)
 - Task with `effort: medium` → sonnet (capped to ceiling, not opus)
 - Task with `effort: high` → sonnet (capped to ceiling, not opus)
 
+**Mixed harnesses**: You can mix Claude and Codex models freely:
+```json
+{
+  "effortMapping": {
+    "low": { "model": "sonnet", "harness": "claude" },
+    "high": { "model": "gpt-5.4", "harness": "codex" }
+  }
+}
+```
+
 ### `timeout` — Task Timeout
 
 - **Type**: number (positive)
@@ -90,7 +120,7 @@ Example:
 
 - **Type**: boolean
 - **Default**: `false`
-- **Description**: When `true`, `raf plan` and `raf do` default to worktree mode (isolated git worktree). Can be overridden per-command with `--worktree` flag.
+- **Description**: When `true`, `raf plan` defaults to worktree mode (isolated git worktree). `raf do` auto-detects worktree projects regardless of this setting.
 
 ### `syncMainBranch` — Sync Main Branch with Remote
 
@@ -110,28 +140,31 @@ Controls the format of git commit messages. Templates use `{placeholder}` syntax
 
 | Key | Default | Description |
 |-----|---------|-------------|
-| `commitFormat.task` | `"{prefix}[{projectId}:{taskId}] {description}"` | Format for task completion commits |
-| `commitFormat.plan` | `"{prefix}[{projectId}] Plan: {projectName}"` | Format for plan creation commits |
-| `commitFormat.amend` | `"{prefix}[{projectId}] Amend: {projectName}"` | Format for plan amendment commits |
+| `commitFormat.task` | `"{prefix}[{projectName}:{taskId}] {description}"` | Format for task completion commits |
+| `commitFormat.plan` | `"{prefix}[{projectName}] Plan: {description}"` | Format for plan creation commits |
+| `commitFormat.amend` | `"{prefix}[{projectName}] Amend: {description}"` | Format for plan amendment commits |
 | `commitFormat.prefix` | `"RAF"` | Prefix string substituted into `{prefix}` placeholder |
 
 #### Template Variables
 
 **Task commits** (`commitFormat.task`):
 - `{prefix}` — The value of `commitFormat.prefix`
-- `{projectId}` — The 6-character project identifier (e.g., `abcdef`)
-- `{taskId}` — The 2-character task identifier (e.g., `01`, `0a`)
+- `{projectName}` — The project name extracted from the folder (e.g., `swiss-army` from `43-swiss-army`)
+- `{projectId}` — Backwards-compatible alias for `{projectName}`
+- `{taskId}` — The task number (e.g., `1`, `10`)
 - `{description}` — A concise description of what was accomplished
 
 **Plan commits** (`commitFormat.plan`):
 - `{prefix}` — The value of `commitFormat.prefix`
-- `{projectId}` — The 6-character project identifier
-- `{projectName}` — The human-readable project name (e.g., `fix-auth-bug`)
+- `{projectName}` — The project name extracted from the folder
+- `{projectId}` — Backwards-compatible alias for `{projectName}`
+- `{description}` — Auto-generated summary from input.md
 
 **Amend commits** (`commitFormat.amend`):
 - `{prefix}` — The value of `commitFormat.prefix`
-- `{projectId}` — The 6-character project identifier
-- `{projectName}` — The human-readable project name
+- `{projectName}` — The project name extracted from the folder
+- `{projectId}` — Backwards-compatible alias for `{projectName}`
+- `{description}` — Auto-generated description of what was amended
 
 Unknown placeholders are left as-is in the output.
 
@@ -153,12 +186,93 @@ Example:
 }
 ```
 
+## Valid Model Names
+
+When configuring models, use one of the known names below. Aliases automatically resolve to the latest version.
+
+### Claude Models (harness: `"claude"`)
+
+| Alias | Resolves To | Notes |
+|-------|------------|-------|
+| `"opus"` | `claude-opus-4-6` | Most capable, highest cost |
+| `"sonnet"` | `claude-sonnet-4-5-20250929` | Balanced capability and cost |
+| `"haiku"` | `claude-haiku-4-5-20251001` | Fastest, lowest cost |
+
+You can also use full model IDs directly for version pinning:
+- `"claude-opus-4-6"`, `"claude-opus-4-5-20251101"`
+- `"claude-sonnet-4-6"`, `"claude-sonnet-4-5-20250929"`
+- `"claude-haiku-4-5-20251001"`
+
+Any string matching the pattern `claude-<family>-*` is accepted as a valid Claude model ID.
+
+### Codex Models (harness: `"codex"`)
+
+| Alias | Resolves To | Notes |
+|-------|------------|-------|
+| `"codex"` | `gpt-5.3-codex` | Lightweight, fast |
+| `"gpt54"` | `gpt-5.4` | Most capable Codex model |
+
+You can also use raw Codex model IDs directly:
+- `"gpt-5.4"`, `"gpt-5.4-2026-03-05"` (pinned), `"gpt-5.4-pro"`, `"gpt-5.4-mini"`, `"gpt-5.4-nano"`
+- `"gpt-5.3-codex"`
+- `"o3"`
+
+Any string matching the pattern `gpt-<version>` or containing a dot-separated version number is accepted as a valid Codex model ID.
+
+### Prefixed Format
+
+You can also use `harness/model` format: `"claude/opus"`, `"codex/gpt-5.4"`. The harness prefix is stripped and used to set the harness field.
+
+## Reasoning Effort
+
+Reasoning effort controls how much thinking the model does before responding. Higher values produce more thorough responses but cost more tokens.
+
+### Claude Reasoning Effort
+
+- **Valid values**: `"low"`, `"medium"`, `"high"` (default), `"max"`
+- **`"max"`** is only available on Opus 4.5+
+- Supported on Opus 4.5+ and Sonnet 4.6+. Haiku does not support reasoning effort.
+- Passed as the `--effort` flag to Claude CLI.
+
+### Codex Reasoning Effort
+
+- **Valid values**: `"none"`, `"minimal"`, `"low"`, `"medium"` (default), `"high"`, `"xhigh"`
+- Passed as `-c model_reasoning_effort="<level>"` to Codex CLI.
+
+### When to Adjust
+
+- **Lower effort** (low/minimal): Simple tasks like renaming, formatting, or config changes. Saves cost and time.
+- **Default effort** (medium/high): Good for most tasks. Balanced cost and quality.
+- **Higher effort** (max/xhigh): Complex architectural decisions, subtle bugs, or security-sensitive code.
+
+Reasoning effort is optional — omit it to use the harness's default.
+
+## Fast Mode
+
+Fast mode enables faster output from Claude by routing requests through a higher-priority serving path. It uses the same model but delivers responses roughly 2.5x faster at a higher per-token cost.
+
+- **Claude only** — Codex does not support fast mode. RAF warns and ignores `fast: true` on Codex entries.
+- **Default**: `false`/omitted (standard speed).
+- Passed as `--settings '{"fastMode": true}'` to Claude CLI.
+- Useful for interactive planning sessions where rapid iteration matters. For batch execution where cost efficiency is the priority, standard mode is recommended.
+
+Example — fast planning, standard execution:
+```json
+{
+  "models": {
+    "plan": { "model": "opus", "harness": "claude", "fast": true },
+    "execute": { "model": "opus", "harness": "claude" }
+  }
+}
+```
+
 ## Validation Rules
 
 The config is validated when loaded. Invalid configs cause an error with a descriptive message. The following rules are enforced:
 
 - **Unknown keys are rejected** at every nesting level. Typos like `"model"` instead of `"models"` will be caught.
-- **Model values** (`models.*`, `effortMapping.*`) must be a short alias (`"sonnet"`, `"haiku"`, `"opus"`) or a full model ID (e.g., `"claude-sonnet-4-5-20250929"`, `"o3"`).
+- **Removed legacy keys** (`provider`, `codexModels`, `codexEffortMapping`) are rejected with helpful migration messages.
+- **Model entries** (`models.*`, `effortMapping.*`) must be `ModelEntry` objects with required `model` and `harness` fields. Plain strings (e.g., `"sonnet"`) are not accepted — use `{ "model": "sonnet", "harness": "claude" }` instead.
 - **`effortMapping` keys** must be `"low"`, `"medium"`, or `"high"`.
 - **`timeout`** must be a positive finite number.
 - **`maxRetries`** must be a non-negative integer.
@@ -167,14 +281,11 @@ The config is validated when loaded. Invalid configs cause an error with a descr
 - **`display` values** (`showCacheTokens`) must be booleans.
 - The config file must be valid JSON containing an object (not an array or primitive).
 
-## CLI Precedence
-
-CLI flags always override config values. For example:
+## Precedence
 
-- `raf do --model haiku` uses Haiku regardless of `models.execute` in config
-- `raf plan --worktree` enables worktree mode regardless of the `worktree` config value
+The harness for each model is set via the `harness` field in each `ModelEntry` in the config. There is no CLI flag to override harnesses at runtime.
 
-The precedence order is: **CLI flag > config file > default value**.
+The precedence order is: **config file > default value**.
 
 ## Example Configs
 
@@ -183,7 +294,7 @@ The precedence order is: **CLI flag > config file > default value**.
 ```json
 {
   "models": {
-    "execute": "sonnet"
+    "execute": { "model": "sonnet", "harness": "claude" }
   }
 }
 ```
@@ -195,8 +306,8 @@ Uses Sonnet instead of Opus for task execution. Everything else stays at default
 ```json
 {
   "models": {
-    "plan": "sonnet",
-    "execute": "sonnet"
+    "plan": { "model": "sonnet", "harness": "claude" },
+    "execute": { "model": "sonnet", "harness": "claude" }
   },
   "worktree": true
 }
@@ -204,22 +315,39 @@ Uses Sonnet instead of Opus for task execution. Everything else stays at default
 
 Uses Sonnet for planning and caps task execution at Sonnet (tasks with `effort: high` will use Sonnet instead of Opus). Defaults to worktree mode.
 
+### Mixed Harnesses — Claude Planning, Codex Execution
+
+```json
+{
+  "models": {
+    "plan": { "model": "opus", "harness": "claude" },
+    "execute": { "model": "gpt-5.4", "harness": "codex" }
+  },
+  "effortMapping": {
+    "low": { "model": "sonnet", "harness": "claude" },
+    "high": { "model": "gpt-5.4", "harness": "codex" }
+  }
+}
+```
+
+Uses Claude Opus for planning but Codex for execution. Low-effort tasks use Claude Sonnet, high-effort tasks use Codex.
+
 ### Full — All Settings Explicit
 
 ```json
 {
   "models": {
-    "plan": "opus",
-    "execute": "opus",
-    "nameGeneration": "sonnet",
-    "failureAnalysis": "haiku",
-    "prGeneration": "sonnet",
-    "config": "sonnet"
+    "plan": { "model": "opus", "harness": "claude" },
+    "execute": { "model": "opus", "harness": "claude" },
+    "nameGeneration": { "model": "sonnet", "harness": "claude" },
+    "failureAnalysis": { "model": "haiku", "harness": "claude" },
+    "prGeneration": { "model": "sonnet", "harness": "claude" },
+    "config": { "model": "sonnet", "harness": "claude" }
   },
   "effortMapping": {
-    "low": "sonnet",
-    "medium": "opus",
-    "high": "opus"
+    "low": { "model": "sonnet", "harness": "claude" },
+    "medium": { "model": "opus", "harness": "claude" },
+    "high": { "model": "opus", "harness": "claude" }
   },
   "timeout": 60,
   "maxRetries": 3,
@@ -227,9 +355,9 @@ Uses Sonnet for planning and caps task execution at Sonnet (tasks with `effort:
   "worktree": false,
   "syncMainBranch": true,
   "commitFormat": {
-    "task": "{prefix}[{projectId}:{taskId}] {description}",
-    "plan": "{prefix}[{projectId}] Plan: {projectName}",
-    "amend": "{prefix}[{projectId}] Amend: {projectName}",
+    "task": "{prefix}[{projectName}:{taskId}] {description}",
+    "plan": "{prefix}[{projectName}] Plan: {description}",
+    "amend": "{prefix}[{projectName}] Amend: {description}",
     "prefix": "RAF"
   },
   "display": {
@@ -245,8 +373,8 @@ This is equivalent to having no config file at all — all values match the defa
 ```json
 {
   "models": {
-    "plan": "claude-opus-4-5-20251101",
-    "execute": "claude-sonnet-4-5-20250929"
+    "plan": { "model": "claude-opus-4-5-20251101", "harness": "claude" },
+    "execute": { "model": "claude-sonnet-4-5-20250929", "harness": "claude" }
   }
 }
 ```
@@ -263,23 +391,25 @@ Uses specific model versions for planning and execution. Useful for pinning to a
 }
 ```
 
-Commits will read `ACME[abcdef:01] Add login page` instead of `RAF[abcdef:01] Add login page`.
+Commits will read `ACME[my-project:1] Add login page` instead of `RAF[my-project:1] Add login page`.
 
 ## Resetting to Defaults
 
-To reset all settings to defaults, delete the config file:
+To reset all settings to defaults, run:
 
 ```bash
-rm ~/.raf/raf.config.json
+raf config reset
 ```
 
-To reset a single setting, remove its key from the config file. Any key not present in the file will use its default value.
+This deletes `~/.raf/raf.config.json` after confirmation.
+
+To reset a single setting, remove its key from the config file or set it back to the default with `raf config set <key> <value>`. Any key not present in the file will use its default value.
 
 ---
 
 ## Config Editing Session Instructions
 
-This section contains instructions for the LLM when operating as the interactive config editor during `raf config` sessions.
+This section contains instructions for the LLM when operating as the interactive config editor during `raf config wizard` sessions.
 
 ### Your Role
 
@@ -303,7 +433,7 @@ You are helping the user view and edit their RAF configuration. Be helpful, expl
 
 After making a change, briefly confirm what was changed and what the effective value is. For example:
 
-> Set `models.execute` to `"sonnet"`. Task execution will now use the Sonnet model instead of Opus.
+> Set `models.execute` to `{ "model": "sonnet", "harness": "claude" }`. Task execution will now use the Sonnet model instead of Opus.
 
 ### Showing Current Config
 
@@ -313,10 +443,24 @@ When the user asks to see their config, show:
 
 Distinguish between user-set values and defaults so the user knows what they've customized.
 
+### Validating Model Names
+
+When the user specifies a model name, check it against the "Valid Model Names" section above:
+
+1. **Known alias or full ID** — Accept it and proceed.
+2. **Unknown model name** — Warn the user that the name isn't in the known list. Suggest they double-check the name. If you have web search capabilities (WebSearch tool), offer to search for the model name to verify it exists. If web search is not available, tell the user to verify the name themselves before saving.
+3. **Common mistakes** — Watch for typos like `"claude-sonnet"` (missing version), `"gpt5.4"` (missing hyphen), or `"Opus"` (capitalized). Suggest the correct form.
+
+When configuring reasoning effort, validate that the value is appropriate for the harness:
+- Claude: `"low"`, `"medium"`, `"high"`, `"max"`
+- Codex: `"none"`, `"minimal"`, `"low"`, `"medium"`, `"high"`, `"xhigh"`
+
+If the user sets reasoning effort on a model that may not support it (e.g., Haiku), warn them.
+
 ### Common User Requests
 
 - **"Show my config"** — Read and display the config file, noting defaults
-- **"Use sonnet for everything"** — Set all `models.*` keys to `"sonnet"`
+- **"Use sonnet for everything"** — Set all `models.*` entries to `{ "model": "sonnet", "harness": "claude" }`
 - **"Reset to defaults"** — Delete the config file (confirm with user first)
 - **"What does X do?"** — Explain the setting using the reference above
 - **"Set timeout to 90"** — Update `timeout` to `90` in the config file

package/src/prompts/execution.ts

@@ -1,4 +1,5 @@
 import { getCommitFormat, getCommitPrefix, renderCommitMessage } from '../utils/config.js';
+import { extractProjectName } from '../utils/paths.js';
 
 /**
  * Maximum characters for a dependency outcome summary.
@@ -91,9 +92,11 @@ ${previousOutcomes.map((o) => `### Task ${o.taskId}\n${o.content}`).join('\n\n')
   // Build example commit message from config template
   const commitTemplate = getCommitFormat('task');
   const commitPrefix = getCommitPrefix();
+  const projectName = extractProjectName(projectPath) ?? projectNumber;
   const exampleCommit = renderCommitMessage(commitTemplate, {
     prefix: commitPrefix,
-    projectId: projectNumber,
+    projectId: projectName,  // backwards compat: {projectId} resolves to projectName
+    projectName,
     taskId: paddedTaskNumber,
     description: '<description>',
   });
@@ -168,20 +171,19 @@ ${depOutcomesFormatted}
 2. Execute the task according to the plan
 3. Verify all acceptance criteria are met
 4. Signal completion with the appropriate marker
-
-## Instructions
 ${retryContextSection}
+## Instructions
+
 ### Step 1: Read the Plan
 
-First, read the plan file to understand exactly what needs to be done.
+Read the plan file to understand exactly what needs to be done.
 
 ### Step 2: Execute the Task
 
-Follow the implementation steps in the plan. Key guidelines:
-- Write clean, maintainable code
-- Follow existing code patterns in the project
-- Add appropriate error handling
+Follow the implementation steps in the plan:
+- Write clean, maintainable code following existing patterns
 - Follow any CLAUDE.md instructions
+- If you encounter blockers, try to resolve them before giving up
 ${dependencyContextSection}${outcomesSection}
 ### Step 3: Verify Completion
 
@@ -192,47 +194,28 @@ Before marking the task complete:
 ${commitInstructions}
 ### Step 4: Write Outcome File
 
-**CRITICAL**: You MUST write an outcome file to document what was accomplished.
-
 **Outcome file path**: \`${outcomeFilePath}\`
 
-The outcome file should contain:
+The outcome file must contain:
 1. A summary of what was done
 2. Key changes made (files modified, features added, etc.)
 3. Any important notes or follow-up items
-4. The completion marker as the LAST line
+4. The completion marker as the LAST line (exactly one marker per file)
 
-**For code tasks**: Summarize what was changed and why
-**For documentation/report tasks**: The outcome IS the deliverable - include the full content
+**For documentation/report tasks**: The outcome IS the deliverable — include the full content.
 
-**CRITICAL**: The outcome file MUST end with one of these markers:
+The outcome file MUST end with one of these markers:
 
-If the task was completed successfully, end the file with:
+On success:
 \`\`\`
 <promise>COMPLETE</promise>
 \`\`\`
 
-If the task failed and cannot be completed, end the file with:
+On failure (do NOT commit — just write the outcome and stop):
 \`\`\`
 <promise>FAILED</promise>
 Reason: [explain why the task failed]
 \`\`\`
 
-## Important Rules
-
-1. ALWAYS read the plan file first
-2. Follow the plan precisely
-3. Do not skip any acceptance criteria
-4. If you encounter blockers, try to resolve them
-5. The outcome file MUST contain EXACTLY ONE completion marker
-6. The completion marker MUST be the LAST line in the outcome file
-7. On SUCCESS: Commit code changes AND outcome file together BEFORE you finish
-8. On FAILURE: Do NOT commit - just write the outcome file with FAILED marker
-
-## Error Handling
-
-If you encounter errors:
-- Try to fix them yourself first
-- If an error prevents completion, write the outcome file with FAILED status and a clear reason
-- Do not mark COMPLETE if there are failing tests or unmet criteria`;
+Do not mark COMPLETE if there are failing tests or unmet criteria.`;
 }