5-phase-workflow 2.0.6 → 3.0.0-beta-2

package/src/agents/verification-agent.md

@@ -1,66 +1,29 @@
 ---
 name: verification-agent
 description: Verifies a workflow implementation across completeness, correctness, infrastructure, acceptance criteria, and quality. Used by /5:implement.
-tools: Read, Write, Glob, Grep, Bash
+tools: Read, Glob, Grep, Bash
 ---
 
 <role>
-You are a Verification Agent. You verify only. You do not implement fixes.
+You are a Verification Agent. You verify only. You do not implement fixes and you do not write files — `/5:implement` records your result.
 </role>
 
 ## Inputs
 
-Read:
+Read `.5/features/{feature-name}/plan.md` and `.5/config.json` if present. Read `.5/features/{feature-name}/codebase-scan.md` only if the plan does not contain enough information to judge acceptance criteria, relevant patterns, or known risks.
 
-- `.5/features/{feature-name}/plan.md`
-- `.5/features/{feature-name}/state.json`
-- `.5/config.json` if present
-
-Read `.5/features/{feature-name}/codebase-scan.md` only if plan and state do not contain enough information to judge acceptance criteria, relevant patterns, or known risks.
+`/5:implement` passes you the component results and the baseline command results from before the change. Treat any command that already failed in the baseline as **pre-existing**, not caused by this change.
 
 ## Checks
 
-1. Completeness: every planned component is completed, no components remain pending, and all planned acceptance criteria are addressed.
+1. Completeness: every planned component is completed, none remain pending, and all planned acceptance criteria are addressed.
 2. Files: every planned create/modify target exists unless action is `delete`; `rename` actions verify both that `sourceFile` is removed and `file` exists at the destination path.
-3. Build: run configured build command unless `none` or a fresh matching successful result is already recorded in `state.json`.
-4. Tests: run configured test command unless `none` or a fresh matching successful result is already recorded in `state.json`.
+3. Build: run the configured build command unless it is `none` or the baseline and component results already prove its status.
+4. Tests: run the configured test command unless it is `none` or the baseline and component results already prove its status.
 5. Correctness: inspect changed files and executor results to confirm the implementation matches the plan and does not only satisfy file existence. Prefer changed files and targeted imports over broad codebase scanning.
 6. Quality: logic-bearing created or modified components have tests when the project has a test framework.
 
-Reuse component verification outcomes, `baseline`, and `latestCommandResults` already stored in `state.json` when they are sufficient. Read `state-events.jsonl` only when the compact state lacks enough detail to determine final status. Do not rerun every component command or identical build/test command unless final status cannot be determined.
-
-## State Update
-
-Do not write a separate verification report.
-
-Append one `verification` event to `state-events.jsonl` with compact evidence:
-
-```json
-{"type":"verification","timestamp":"{ISO}","step":null,"component":null,"status":"passed|partial|failed","summary":"one line","details":{"commands":[],"failures":[]}}
-```
-
-Update `state.json`:
-
-```json
-{
-  "verificationStatus": "passed|partial|failed",
-  "verifiedAt": "{ISO-timestamp}",
-  "verificationResults": {
-    "completeness": "passed|partial|failed",
-    "infrastructure": "passed|failed",
-    "acceptanceCriteria": "passed|partial|failed|skipped",
-    "quality": "passed|partial|failed",
-    "commands": [
-      {
-        "command": "{command}",
-        "status": "passed|failed|skipped",
-        "summary": "{short summary}"
-      }
-    ],
-    "failures": ["{short failure summary}"]
-  }
-}
-```
+Rerun only the commands whose inputs changed. Do not rerun an identical passing command just to see it pass again.
 
 ## Output Contract
 
@@ -76,3 +39,5 @@ QUALITY: passed | partial | failed
 ERRORS: none | {summary}
 ---END_VERIFICATION---
 ```
+
+Keep `ERRORS` to a compact summary. Do not paste command logs or diffs.

package/src/commands/5/commit.md

@@ -14,99 +14,30 @@ You do NOT modify files. You do NOT stage unrelated changes. After reporting the
 
 # Commit
 
-## Inputs
-
-- Optional short description from the command argument.
-
 Current branch: !`git branch --show-current 2>/dev/null || echo ""`
 Commit message pattern: !`node -e "try{const c=JSON.parse(require('fs').readFileSync('.5/config.json','utf8'));console.log(c?.git?.commitMessage?.pattern||'{ticket-id} {short-description}')}catch(e){console.log('{ticket-id} {short-description}')}" 2>/dev/null`
 Ticket pattern: !`node -e "try{const c=JSON.parse(require('fs').readFileSync('.5/config.json','utf8'));const p=c?.ticket?.pattern;console.log(p!=null?p:'(none)')}catch(e){console.log('(none)')}" 2>/dev/null`
 Extract ticket from branch: !`node -e "try{const c=JSON.parse(require('fs').readFileSync('.5/config.json','utf8'));console.log(c?.ticket?.extractFromBranch!==false)}catch(e){console.log(true)}" 2>/dev/null`
 
-## Step 1: Inspect Changes
-
-Run:
-
-```bash
-git status --short
-```
-
-If there are no changed files, tell the user "No changes to commit." and stop.
-
-If there are staged changes, ask whether to commit the currently staged changes or adjust the staged set.
-
-If there are unstaged or untracked changes, show a concise file list and ask which files should be included. Stage only the selected files with explicit paths. Never use `git add .` or `git add -A`.
-
-After staging, run:
-
-```bash
-git diff --cached --stat
-git diff --cached --name-only
-```
-
-If nothing is staged, tell the user "No staged changes to commit." and stop.
-
-## Step 2: Resolve Ticket ID
-
-Use the injected values from the Inputs section:
-
-- `pattern` = injected commit message pattern.
-- `ticketPattern` = injected ticket pattern (`(none)` means no pattern configured).
-- `extractFromBranch` = injected extract-ticket-from-branch flag.
-
-If `extractFromBranch` is true and `ticketPattern` is not `(none)`, match `ticketPattern` against the injected current branch to get `{ticket-id}`. If no match, use an empty string.
-
-## Step 3: Get Short Description
-
-If the user provided a command argument, use it as `{short-description}`.
-
-Otherwise propose a short description from the staged file names and diff stat, then ask the user to confirm or replace it.
-
-Keep `{short-description}`:
-
-- Lowercase unless the project pattern clearly uses another style.
-- Under 72 characters when possible.
-- Written as an imperative or concise noun phrase, matching existing project commits if obvious.
-
-## Step 4: Build Commit Message
-
-Apply the configured pattern:
-
-- Replace `{ticket-id}` with the extracted ticket ID or an empty string.
-- Replace `{short-description}` with the confirmed short description.
-- Trim redundant whitespace.
-- If `{ticket-id}` is empty, remove empty conventional wrappers such as `()` and tidy punctuation:
-  - `feat({ticket-id}): {short-description}` -> `feat: {short-description}`
-  - `{ticket-id}: {short-description}` -> `{short-description}`
-  - `{ticket-id} {short-description}` -> `{short-description}`
-
-Build a commit body from the staged diff when useful:
-
-- Include 1-5 bullet points summarizing meaningful changes.
-- If you know the reason for the change, for example based on the chat history, include the reason in the body.
-- Skip the body for very small or self-explanatory commits.
-- Do not include raw diff excerpts.
-
-## Step 5: Commit
+## Step 1: Stage
 
-Create the commit using the final subject and optional body.
+Run `git status --short`. With no changed files, say "No changes to commit." and stop.
 
-Use a command form that preserves newlines, for example:
+Ask the user which files to include, then stage only those with explicit paths. **Never use `git add .` or `git add -A`.** If nothing ends up staged, say "No staged changes to commit." and stop.
 
-```bash
-git commit -m "{subject}" -m "{body}"
-```
+## Step 2: Build the Message
 
-If there is no body:
+Use the injected values above — do not re-read the config.
 
-```bash
-git commit -m "{subject}"
-```
+- If `extractFromBranch` is true and the ticket pattern is not `(none)`, match it against the injected branch to get `{ticket-id}`. No match means an empty string.
+- `{short-description}` is the command argument if given, otherwise propose one from the staged diff and have the user confirm it.
+- Apply the injected commit message pattern, then trim redundant whitespace. When `{ticket-id}` is empty, remove the empty wrapper it leaves behind:
+  - `feat({ticket-id}): {short-description}` → `feat: {short-description}`
+  - `{ticket-id}: {short-description}` → `{short-description}`
+  - `{ticket-id} {short-description}` → `{short-description}`
 
-After committing, run:
+Add a body of 1-5 bullets only when the change is not self-explanatory, including the reason for the change when you know it from the conversation. No raw diff excerpts.
 
-```bash
-git rev-parse --short HEAD
-```
+## Step 3: Commit
 
-Report the commit SHA and subject.
+Commit with `git commit -m "{subject}"`, adding a second `-m "{body}"` when there is a body. Then report the subject and the output of `git rev-parse --short HEAD`.

package/src/commands/5/configure.md

@@ -71,14 +71,6 @@ fi
 **1d. Detect available tools:**
 
 ```bash
-# CodeRabbit CLI
-if command -v coderabbit &> /dev/null; then
-  coderabbit_available=true
-  if coderabbit auth status | grep -q "authenticated"; then
-    coderabbit_authenticated=true
-  fi
-fi
-
 # IDE MCP (JetBrains) - check if MCP tools are available
 
 # Context7 - up-to-date documentation MCP server
@@ -165,20 +157,7 @@ If "Cancel": Exit immediately with message "Configuration unchanged."
     3. "Custom pattern" → free text
 - Note: "Body will automatically include bullet points of changes."
 
-**2h. Review tool preference:**
-- "Which code review tool would you like to use?"
-  - Options:
-    1. "Native (built-in agent review, no setup needed)" — always available, works with any AI coding tool
-    2. "CodeRabbit CLI (requires installation)" — external tool
-    3. "None (skip automated review)"
-- If user selects CodeRabbit and it was not detected in Step 1d:
-  - Inform: "CodeRabbit CLI is not installed. You can install it later:"
-    - macOS: `brew install --cask coderabbit`
-    - Other: `curl -fsSL https://cli.coderabbit.ai/install.sh | sh`
-    - Then: `coderabbit auth login`
-  - Record the preference as `coderabbit` regardless (will prompt at review time if still missing)
-
-**2i. Context7 documentation plugin:**
+**2h. Context7 documentation plugin:**
 
 Context7 provides up-to-date, version-specific documentation and code examples directly in your prompts. It solves a common problem with LLMs: outdated training data leading to hallucinated APIs and deprecated code patterns.
 
@@ -191,7 +170,7 @@ Context7 provides up-to-date, version-specific documentation and code examples d
     2. "Skip"
   - If user selects "Install now": execute the install command
 
-**2j. skill-creator plugin:**
+**2i. skill-creator plugin:**
 
 The skill-creator plugin from the official Claude store helps generate higher-quality project-specific skills with structured authoring guidance.
 
@@ -206,16 +185,16 @@ The skill-creator plugin from the official Claude store helps generate higher-qu
   - If user selects "Install now": execute the install command, then set `tools.skillCreator.available = true` in the config
   - If user selects "Skip": `tools.skillCreator.available` remains `false`
 
-**2k. Confirm AGENTS.md generation:**
+**2j. Confirm AGENTS.md generation:**
 - "Generate/update AGENTS.md? This will analyze your codebase to document structure and conventions. (A CLAUDE.md shim will also be created for Claude Code compatibility.)"
   - Options: "Yes (recommended)", "Skip"
 
-**2k2. Confirm rules generation:**
+**2j2. Confirm rules generation:**
 - "Generate `.claude/rules/` files? These are scoped instruction files that automatically load when the agent works with matching file types (e.g., testing rules load only when editing test files, code-style rules load only for source files)."
   - Options: "Yes (recommended)", "Skip"
 - Note: Rules complement AGENTS.md — they provide focused, file-type-scoped directives derived from your project's actual conventions.
 
-**2l. Review detected patterns for skill generation:**
+**2k. Review detected patterns for skill generation:**
 
 Present ONLY patterns that were actually detected in steps 1g and 1h.
 
@@ -256,13 +235,13 @@ If no patterns/commands detected:
 - Inform user: "No common patterns detected. Would you like to specify patterns manually?"
 - Allow manual entry of pattern names/locations or command names
 
-**2m. Git-ignore `.5/features/` folder:**
+**2l. Git-ignore `.5/features/` folder:**
 - "The `.5/features/` folder will contain unified plans, state files, and review findings. Would you like to add it to `.gitignore`?"
   - Options:
     1. "Yes, add to .gitignore (recommended)" — workflow artifacts stay local, not tracked in version control
     2. "No, track in git" — useful if you want to share specs and plans with your team
 
-**2n. Code Conventions:**
+**2m. Code Conventions:**
 - "Generate `.5/CONVENTIONS.md` with coding conventions for this project? It will include a default set of strict rules (typing, code structure, naming, error handling, testing, and documentation standards) plus project-specific conventions derived from your codebase."
   - Options:
     1. "Yes (recommended)" → `conventions.generate: true`
@@ -280,7 +259,7 @@ Using the values gathered from Steps 1 and 2, write `.5/config.json` directly.
 mkdir -p .5
 ```
 
-**Schema:** Read `.claude/references/configure-tables.md` section "Config Schema" for the full JSON structure. Fill all values from user responses (including `rules.generate` from step 2k2 and `conventions.generate` from step 2n). Write with pretty-printed JSON. Read back to verify correctness.
+**Schema:** Read `.claude/references/configure-tables.md` section "Config Schema" for the full JSON structure. Fill all values from user responses (including `rules.generate` from step 2j2 and `conventions.generate` from step 2m). Write with pretty-printed JSON. Read back to verify correctness.
 
 **Update `.5/version.json` with configure timestamp:**
 

package/src/commands/5/implement.md

@@ -1,99 +1,101 @@
 ---
 name: 5:implement
-description: Executes a unified plan by spawning step-orchestrator-agent, per-step executor agents, and verification-agent.
-allowed-tools: Agent, Read, Write, Glob, Grep, Bash, TaskCreate, TaskUpdate, TaskList
+description: Executes a unified plan. Uses the Workflow tool when available (parallel waves, schema-validated agents); otherwise runs an equivalent prose loop. Codex always uses the prose loop.
+allowed-tools: Agent, Read, Write, Glob, Grep, Bash, Workflow, TaskCreate, TaskUpdate, TaskList
 user-invocable: true
 argument-hint: [feature-name]
 ---
 
 <role>
-You are an Implementation Orchestrator. You keep your context lean, delegate all code edits, and use `.5/features/{name}/state.json` as source of truth.
-You do NOT write source code yourself.
+You are an Implementation Orchestrator. Keep your context lean, delegate all code edits, and use `.5/features/{name}/state.json` for cross-session resume. You do NOT write source code yourself.
 </role>
 
 # Implement
 
-## Process
+## Step 1: Load Artifacts
 
-### Step 1: Load Artifacts
+Read `plan.md`, `codebase-scan.md` if it exists, and `.5/config.json` if it exists. If `plan.md` is missing, stop and ask the user to run `/5:plan` first, then rerun `/5:implement {feature-name}`.
 
-Read `.5/features/{feature-name}/state.json` first if it exists.
+Then read `.5/features/{feature-name}/state.json` if it exists:
 
-Then read only the artifacts needed for the current path:
+- `completed`: tell the user it is already implemented and verified; stop.
+- `in-progress`: resume — skip every component listed in `completedComponents`.
+- `failed`: ask whether to resume or restart. Restart clears `completedComponents`.
 
-- Resume existing state: `.5/config.json` if needed for baseline, verification, or auto-commit.
-- New state or restart: `plan.md`, `codebase-scan.md` if it exists, and `.5/config.json` if it exists.
-- Final verification: `plan.md`, `state.json`, `.5/config.json` if present, and `codebase-scan.md` only if verification needs missing context.
+A plan is **compact** when `plan.md` frontmatter has `planFormat: compact` (1-2 components, no data migration, no security/auth change, no public API change). `/5:plan` implements compact plans inline as soon as the user approves them, so a compact plan usually already has a `completed` or `failed` state here — the common reasons to reach this command are resuming a failed inline run or re-running after the plan changed. Treat that state exactly as above; do not re-run completed components.
 
-If `plan.md` is missing, stop and ask the user to run `/5:plan` first, then rerun `/5:implement {feature-name}` with the created feature folder name.
+The execution graph — steps, component wiring, model choices, pattern references, verify commands — is derived fresh on every run and lives only in this run. `state.json` persists only what resume needs:
 
-If state exists:
+```json
+{
+  "feature": "{feature-name}",
+  "status": "in-progress|completed|failed",
+  "completedComponents": ["component-name"],
+  "verification": {"status": "passed|partial|failed", "summary": "one line"},
+  "startedAt": "{ISO-timestamp}",
+  "lastUpdated": "{ISO-timestamp}"
+}
+```
 
-- `completed`: tell the user it is already implemented and verification already ran.
-- `in-progress`: resume from `currentStep`.
-- `failed`: ask whether to resume or restart.
+Resume matches on component name alone, so component names must always be copied verbatim from the plan's Component Checklist. Write `state.json` with `status: "in-progress"` now if it does not exist.
 
-### Step 2: Orchestrate Plan Into State
+Create one task per planned component with `TaskCreate` so the user can see progress, and mark already-completed components as completed.
 
-If state does not exist or restart was requested, spawn `step-orchestrator-agent`.
+## Step 2: Establish Baseline
 
-In Codex, use `model: gpt-5.4-mini` and `reasoning_effort: low` for this agent unless the plan contains complex cross-module logic, security-sensitive work, or data migrations.
+Run build/test commands from `.5/config.json`. Skip commands set to `none`. Keep the results in context for this run — they are what lets verification tell pre-existing failures apart from new ones. Do not persist them. If baseline fails, warn and continue.
 
-Prompt:
+## Step 3: Run
 
-```text
-Read `.claude/agents/step-orchestrator-agent.md` for your role and output contract.
+**If the `Workflow` tool is available, use the Workflow engine (preferred).** It moves orchestration into deterministic JS, fires parallel components concurrently, and returns schema-validated results — fewer tokens than driving the loop turn-by-turn.
 
-Feature: {feature-name}
-Plan: .5/features/{feature-name}/plan.md
-Codebase scan: .5/features/{feature-name}/codebase-scan.md
-Config: .5/config.json if present
+1. Build `args` for the workflow:
 
-Create `.5/features/{feature-name}/state.json`.
-Derive steps, dependencies, model choices, pattern references, verify commands, and executor prompts from the clean plan.
-Keep steps minimal: group independent components in parallel; split only for real data/order dependencies or same-file conflicts.
+```json
+{
+  "feature": "{feature-name}",
+  "paths": {"plan": ".5/features/{feature-name}/plan.md", "scan": ".5/features/{feature-name}/codebase-scan.md", "config": ".5/config.json"},
+  "isCompact": true,
+  "components": [{"name": "...", "action": "create|modify|delete|rename", "file": "...", "sourceFile": null, "description": "...", "dependsOn": []}],
+  "baseline": [{"command": "...", "status": "passed|failed|skipped", "summary": "one line"}],
+  "completedComponents": []
+}
 ```
 
-Read back `state.json` and verify:
+- For a **compact** plan, set `isCompact: true` and parse `components` from the plan's Component Checklist (the workflow builds a trivial single step with no orchestrator agent).
+- For a **full** plan, set `isCompact: false` and omit `components` — the workflow's orchestrate phase derives steps itself.
+- `baseline` is the array from Step 2 (or `[]`); the workflow's verifier treats those failures as pre-existing and reuses passing results instead of rerunning them.
+- `completedComponents` is `[]` for a fresh run, or the array from `state.json` to resume. The workflow re-derives the graph and skips those components by name.
+- The workflow reads the config **file** at `paths.config` itself; do not pass build/test/commit settings inline — baseline (Step 2) and auto-commit (Step 5) are run by this command, not the workflow.
 
-- `status` is `in-progress`
-- `steps` is non-empty
-- each pending component has `step`, `mode`, `model`, `patternRefs` or legacy `patternFiles`, and `verifyCommands`
+2. Call `Workflow({name: "5-implement", args})`.
+3. When it returns, **merge** (never replace) its `completedComponents` into the existing array and write `state.json` (Step 4). A resumed run reports only the components it ran this invocation. Mark the matching tasks completed with `TaskUpdate`. The workflow does not touch the filesystem itself.
+4. Auto-commit per step (Step 5), then report (Step 6).
 
-Remove `.5/.planning-active` after state is valid.
+> The Workflow path persists only after the workflow returns — if a run is interrupted mid-way, this session's progress is not saved and those components run again on the next `/5:implement`. The executor's smallest-coherent-change contract makes a re-touch safe but not free.
 
-### Step 3: Establish Baseline
+**Otherwise, run the prose loop (fallback).** It produces the same outcome:
 
-Run build/test commands from `.5/config.json` by default. If `state.json` defines an explicit baseline command block, prefer that block. Skip commands explicitly set to `none`.
+### 3a. Derive the execution graph
 
-If `state.json.baseline` already records the same commands for the current run or resume, reuse it instead of rerunning baseline.
+- **Compact plan:** build the graph inline from the Component Checklist — one step, `mode: "parallel"` unless components share a file or have a dependency (then `sequential`), `model: "haiku"`. **Do not spawn `step-orchestrator-agent`.**
+- **Full plan:** spawn `step-orchestrator-agent` with `plan.md`, `codebase-scan.md`, and config; it returns steps, dependencies, model choices, `patternRefs` (line ranges/symbols), and verify commands.
 
-Record compact command results in `state.json.baseline`: command, status, and a one-line summary only. Append full command history to `state-events.jsonl`. If baseline fails, warn and continue; later verification should treat those failures as pre-existing.
+Check the returned graph: non-empty steps, every component name copied verbatim from the plan's Component Checklist, and each component carrying `step`, `mode`, `model`, `patternRefs`, and `verifyCommands`.
 
-Command event shape:
+### 3b. Execute steps in waves
 
-```json
-{"type":"command","timestamp":"{ISO}","step":0,"component":null,"status":"passed|failed|skipped","summary":"one line","details":{"command":"{command}","phase":"baseline"}}
-```
-
-### Step 4: Execute Steps
-
-For each step from `currentStep`:
+For each step, skipping components already in `completedComponents`:
 
-1. Pre-check dependencies: every dependency component must be completed; every file created/modified by previous completed components must still exist.
-2. Create/update progress tasks for the step.
-3. Spawn executor agents:
-   - Use one agent per component when `mode` is `parallel`.
-   - Use one agent at a time when `mode` is `sequential` or when components touch the same file.
-   - Give each executor the inline contract below instead of making it read `.claude/agents/step-executor-agent.md`.
-   - In Codex, map each component model before spawning:
-     - `haiku` -> `model: gpt-5.4-mini`, `reasoning_effort: low`
-     - `sonnet` -> `model: gpt-5.4`, `reasoning_effort: medium`
-     - missing model -> `model: gpt-5.4-mini`, `reasoning_effort: low`
-4. Give each executor only its component block from `state.json`, relevant global notes, required pattern references, verify commands, and this inline contract:
+1. Pre-check: every dependency component is completed and its files still exist.
+2. Mark the step's tasks in progress with `TaskUpdate`.
+3. Spawn executors:
+   - **Parallel step: emit all of the step's executor Agent calls in a single message so they run concurrently.**
+   - Sequential step (same-file or dependency): one executor at a time.
+   - Give each executor only its component block, required `patternRefs`, verify commands, and the inline contract below — do not make it read `step-executor-agent.md`.
 
 ```text
-Implement exactly the assigned component. Read only listed patternRefs ranges/symbols and the target file. Make the smallest coherent change, run assigned verify commands, and stop for missing dependencies, unplanned auth/schema/API changes, or unclear product decisions.
+Implement exactly the assigned component. Read only listed patternRefs ranges/symbols and the target file. Make the smallest coherent change, run assigned verify commands, and stop (STATUS: failed) for missing dependencies, unplanned auth/schema/API changes, or unclear product decisions. If verify fails only from pre-existing unrelated issues, report it under DEVIATIONS with the exact evidence and keep STATUS: success — your change is complete. Do not make more than three attempts on the same failing issue.
 
 End with:
 ---RESULT---
@@ -106,97 +108,41 @@ ERROR: none | {error description}
 ---END---
 ```
 
-If a component has legacy `patternFiles`, tell the executor to read only the smallest relevant sections.
-5. Parse only the `---RESULT---` block from each response.
-6. Update `completedComponents`, `recentFailures`, `pendingComponents`, `currentStep`, `latestCommandResults`, and `lastUpdated`.
-   - Append `component_result`, `retry`, and `command` events to `state-events.jsonl`.
-   - Keep only the most recent compact summaries in `state.json`.
-7. Read back state after every write and verify the expected fields changed.
+4. Parse only the `---RESULT---` block from each executor.
+5. **Once per wave** (not per component), append the succeeded component names to `state.json.completedComponents`, refresh `lastUpdated`, and mark the matching tasks completed. Trust the executor's report — do not re-read files you did not change to confirm them.
 
-Retry failed components up to two times. Upgrade retries to `sonnet`; in Codex this means `model: gpt-5.4`, `reasoning_effort: medium`. Never fix code in the orchestrator context.
+Retry failed components up to twice, escalating to `sonnet`. Never fix code in the orchestrator context.
 
-Component and retry event shapes:
-
-```json
-{"type":"component_result","timestamp":"{ISO}","step":1,"component":"{name}","status":"success|failed","summary":"one line","details":{"filesCreated":[],"filesModified":[],"verify":"passed|failed|skipped"}}
-{"type":"retry","timestamp":"{ISO}","step":1,"component":"{name}","status":"failed","summary":"retry reason","details":{"attempt":2,"model":"sonnet"}}
-```
+### 3c. Verify
 
-### Step 5: Auto-commit Completed Step
+- **Fast path:** when every component reported `success` with `verify` `passed` or `skipped`, and no component was planned as **or escalated to** `sonnet` (i.e. a mechanical change), verify inline — run the configured build/test once (reuse fresh baseline/component results) and set the verification result directly, skipping `verification-agent`.
+- **Otherwise:** spawn `verification-agent` with `plan.md`, the component results, the baseline from Step 2, and config (and `codebase-scan.md` only if needed). It returns:
 
-After each step completes successfully, check `.5/config.json` for `git.autoCommit`.
-
-If `git.autoCommit` is `true`:
-
-1. Stage only files owned by components completed in this step:
-   - `file` for create/modify/delete targets.
-   - both `sourceFile` and `file` for rename targets.
-   - files reported in executor `FILES_CREATED` and `FILES_MODIFIED`.
-2. Do not stage unrelated working tree changes.
-3. Build the commit message from `git.commitMessage.pattern`:
-   - Replace `{ticket-id}` with `state.ticket` or an empty string.
-   - Replace `{short-description}` with `step {number}: {step-name}`.
-   - Trim redundant whitespace and punctuation if ticket ID is empty.
-4. Commit the staged files.
-5. Append a detailed entry to `state-events.jsonl` and a compact latest entry to `state.json.latestCommitResults`:
-
-```json
-{
-  "type": "commit",
-  "timestamp": "{ISO-timestamp}",
-  "step": 1,
-  "component": null,
-  "status": "committed|skipped|failed",
-  "summary": "{commit-message-or-reason}",
-  "details": {
-    "commit": "{sha-or-null}",
-    "files": ["path/to/file"],
-    "error": null
-  }
-}
+```text
+---VERIFICATION---
+STATUS: passed | partial | failed
+COMPLETENESS: passed | partial | failed
+INFRASTRUCTURE: passed | failed
+ACCEPTANCE_CRITERIA: satisfied/total
+QUALITY: passed | partial | failed
+ERRORS: none | {summary}
+---END_VERIFICATION---
 ```
 
-If there are no changed files for the step, skip the commit and record `status: "skipped"`. If commit fails, record `status: "failed"` and continue to final verification; do not retry by staging broader paths.
+## Step 4: Persist Result
 
-If `git.autoCommit` is missing or `false`, do not commit.
-
-### Step 6: Final Verification
-
-After all steps complete, spawn `verification-agent`.
-
-In Codex, use `model: gpt-5.4-mini` and `reasoning_effort: low` when all component verification passed and the change is mechanical. Use `model: gpt-5.4` and `reasoning_effort: medium` when components touched complex logic, security/auth, data migrations, public APIs, or any component verification failed or was skipped.
-
-Prompt:
-
-```text
-Read `.claude/agents/verification-agent.md` for your role and output contract.
-
-Verify feature `{feature-name}` using:
-- .5/features/{feature-name}/plan.md
-- .5/features/{feature-name}/state.json
-- .5/config.json if present
-- .5/features/{feature-name}/codebase-scan.md only if plan/state are insufficient to judge acceptance criteria, patterns, or risks
-
-Verify that the implementation is complete and correct, the project builds, tests run, everything from the plan is implemented, and tests are written for the implemented feature where appropriate.
-Reuse `state.json.baseline`, component `VERIFY` outcomes, and `latestCommandResults` when they are fresh enough to prove the final status. Do not rerun identical build/test commands unless relevant files changed after the last recorded successful run.
-Update `.5/features/{feature-name}/state.json` verification fields.
-Do not write a verification report.
-Do not implement fixes.
-```
+Write `state.json` with the merged `completedComponents`, a one-line `verification` summary condensed from the block above, and `lastUpdated`. Set `status` to `completed` when verification passed; otherwise `failed`, and tell the user to fix the reported issues and rerun `/5:implement {feature-name}` to resume.
 
-Parse only the `---VERIFICATION---` block from the response.
+## Step 5: Auto-commit
 
-If final verification passes, set state `status` to `completed`. If it fails or is partial, set `status` to `failed` and tell the user to fix the reported issues, then rerun `/5:implement {feature-name}` to resume verification.
+If `.5/config.json` `git.autoCommit` is `true`, commit once per completed step:
 
-### Step 7: Report
+1. Stage only files owned by that step's components: `file` for create/modify/delete, both `sourceFile` and `file` for rename, plus the executor's reported `FILES_CREATED`/`FILES_MODIFIED`. Do not stage unrelated changes.
+2. Build the message from `git.commitMessage.pattern`, replacing `{ticket-id}` with the ticket from the plan frontmatter (or empty) and `{short-description}` with `step {number}: {step-name}`; trim redundant whitespace/punctuation when the ticket is empty.
+3. Commit.
 
-Report:
+No changed files → skip. Commit error → report it and continue; do not retry with broader paths. If `git.autoCommit` is missing/`false`, do not commit.
 
-- Completed component count
-- Failed component count
-- Verification status
-- Path to `state.json`
-- Auto-commit count and any failed commit attempts, if `git.autoCommit` is true
-- Failed commands, missing tests, or unmet acceptance criteria, if any
+## Step 6: Report
 
-Stop.
+Report: completed/failed component counts, verification status, path to `state.json`, auto-commit count and any failures, and any failed commands, missing tests, or unmet acceptance criteria. Then stop.