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

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

@@ -7,39 +7,43 @@ argument-hint: [feature-name]
 ---
 
 <role>
-You are an Implementation Orchestrator. Keep your context lean, delegate all code edits, and use `.5/features/{name}/state.json` as the durable source of truth for cross-session resume. 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
 
-## Step 1: Load Artifacts & Decide Path
+## Step 1: Load Artifacts
 
-Read `.5/features/{feature-name}/state.json` first if it exists. Then read only what the current path needs:
+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}`.
 
-- 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.
-
-If `plan.md` is missing, stop and ask the user to run `/5:plan` first, then rerun `/5:implement {feature-name}`.
-
-State machine, if state exists:
+Then read `.5/features/{feature-name}/state.json` if it exists:
 
 - `completed`: tell the user it is already implemented and verified; stop.
-- `in-progress`: resume from `currentStep` (only run components not in `completedComponents`).
-- `failed`: ask whether to resume or restart.
+- `in-progress`: resume — skip every component listed in `completedComponents`.
+- `failed`: ask whether to resume or restart. Restart clears `completedComponents`.
 
-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).
+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.
 
-Remove `.5/.planning-active` once you have a valid plan to execute.
+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:
 
-## Step 2: Establish Baseline
+```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}"
+}
+```
 
-Run build/test commands from `.5/config.json` (or an explicit baseline block in `state.json`). Skip commands set to `none`. If `state.json.baseline` already records the same commands for this run/resume, reuse it.
+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.
 
-Record compact results in `state.json.baseline` (command, status, one-line summary). Append full history to `state-events.jsonl`. If baseline fails, warn and continue; verification treats those as pre-existing.
+Create one task per planned component with `TaskCreate` so the user can see progress, and mark already-completed components as completed.
 
-```json
-{"type":"command","timestamp":"{ISO}","step":0,"component":null,"status":"passed|failed|skipped","summary":"one line","details":{"command":"{command}","phase":"baseline"}}
-```
+## Step 2: Establish Baseline
+
+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.
 
 ## Step 3: Run
 
@@ -54,41 +58,41 @@ Record compact results in `state.json.baseline` (command, status, one-line summa
   "isCompact": true,
   "components": [{"name": "...", "action": "create|modify|delete|rename", "file": "...", "sourceFile": null, "description": "...", "dependsOn": []}],
   "baseline": [{"command": "...", "status": "passed|failed|skipped", "summary": "one line"}],
-  "resume": null
+  "completedComponents": []
 }
 ```
 
 - 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 you recorded in Step 2 (or `[]`); the workflow's verifier treats those failures as pre-existing and reuses passing results instead of rerunning them.
-- `resume` is `null` for a fresh run. To resume, pass `{"completedComponents": [...], "steps": [...], "pendingComponents": [...]}` copied verbatim from the existing `state.json`, so the workflow reuses the original steps rather than re-deriving them (re-derivation is non-deterministic and could rename components, breaking resume matching).
+- `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.
 
 2. Call `Workflow({name: "5-implement", args})`.
-3. When it returns, **persist its result** (Step 4): write the returned `steps`, `components`, and `verification` into `state.json`, and **merge** (never replace) the returned `completedComponents` and per-component `results` into the existing arrays — a resumed run reports only the components it ran this invocation, so earlier-session history must be preserved. Append events to `state-events.jsonl`. The workflow does not touch the filesystem itself.
+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).
 
-> Cross-session resume stays durable via `state.json`, but the Workflow path persists **only after the workflow returns** — if a run is interrupted mid-way, this session's progress is not yet saved. On the next `/5:implement`, resume reconciles against the persisted `completedComponents` (only components recorded there are skipped), so re-running a partially-applied step is possible; the executor's smallest-coherent-change contract makes a re-touch safe but not free. Workflow's own in-session resume is a bonus; you are the one who persists state after it returns.
+> 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.
 
-**Otherwise, run the prose loop (fallback).** It produces the same `state.json` outcome:
+**Otherwise, run the prose loop (fallback).** It produces the same outcome:
 
-### 3a. Orchestrate into state
+### 3a. Derive the execution graph
 
-- **Compact plan:** build `state.json` 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 writes `state.json` with steps, dependencies, model choices, `patternRefs` (line ranges/symbols), and verify commands.
+- **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.
 
-Verify `state.json`: `status: in-progress`, non-empty `steps`, each pending component has `step`, `mode`, `model`, `patternRefs` (or legacy `patternFiles`), and `verifyCommands`.
+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`.
 
 ### 3b. Execute steps in waves
 
-For each step from `currentStep`, skipping components already in `completedComponents`:
+For each step, skipping components already in `completedComponents`:
 
 1. Pre-check: every dependency component is completed and its files still exist.
-2. Update progress tasks for the step.
+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`. (For legacy `patternFiles`, tell it to read only the smallest relevant sections.)
+   - 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 (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.
@@ -105,19 +109,14 @@ ERROR: none | {error description}
 ```
 
 4. Parse only the `---RESULT---` block from each executor.
-5. **Once per wave** (not per component), update `completedComponents`, `recentFailures`, `pendingComponents`, `currentStep`, `latestCommandResults`, `lastUpdated`, and append `component_result` / `retry` / `command` events to `state-events.jsonl`. Trust the executor's report — do not re-read files you did not change to confirm them.
-
-```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"}}
-```
+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 twice, escalating to `sonnet`. Never fix code in the orchestrator context.
 
 ### 3c. Verify
 
-- **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), set the verification fields directly, and skip `verification-agent`.
-- **Otherwise:** spawn `verification-agent` with `plan.md`, `state.json`, and config (and `codebase-scan.md` only if needed). It reuses fresh `baseline`/component/`latestCommandResults` instead of rerunning identical passing commands, then updates `state.json` verification fields and returns:
+- **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:
 
 ```text
 ---VERIFICATION---
@@ -130,23 +129,19 @@ ERRORS: none | {summary}
 ---END_VERIFICATION---
 ```
 
-## Step 4: Persist Verification Result
+## Step 4: Persist Result
 
-Set `state.json` `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.
+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.
 
 ## Step 5: Auto-commit
 
 If `.5/config.json` `git.autoCommit` is `true`, commit once per completed step:
 
 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 `state.ticket` (or empty) and `{short-description}` with `step {number}: {step-name}`; trim redundant whitespace/punctuation when the ticket is empty.
-3. Commit, and record a compact entry in `state.json.latestCommitResults` plus a detailed `commit` event:
-
-```json
-{"type":"commit","timestamp":"{ISO}","step":1,"component":null,"status":"committed|skipped|failed","summary":"{message-or-reason}","details":{"commit":"{sha-or-null}","files":["path"],"error":null}}
-```
+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.
 
-No changed files → `status: "skipped"`. Commit error → `status: "failed"`, continue; do not retry with broader paths. If `git.autoCommit` is missing/`false`, do not commit.
+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.
 
 ## Step 6: Report