5-phase-workflow 3.0.1 → 3.1.0

package/src/skills/review-style/SKILL.md

@@ -0,0 +1,142 @@
+---
+name: review-style
+description: Review changes against coding and documentation standards (repo standards plus a list of style skills), then optionally fix the findings. Use when the user wants a style, standards or conventions review of a branch, a commit range or uncommitted work.
+---
+
+# Review style
+
+Review a change against two kinds of standards:
+
+- **Repo standards**: whatever the repository documents about how code is written.
+- **Styles**: the style skills listed below. They apply in every repository.
+
+Repo standards always win. Where a repo standard endorses something a style would flag, the style finding is
+**suppressed**.
+
+## Styles
+
+Each path is relative to this skill's base directory. Add a style by adding one line.
+
+- `../fowler-code-smells/SKILL.md`
+- `../cognitive-load/SKILL.md`
+- `../documentation-style/SKILL.md`. It applies only to code comments, doc comments and Markdown files.
+- `../baseline-conventions/SKILL.md`
+
+## Process
+
+### 1. Pin the scope
+
+The caller's words pick one of these modes:
+
+| Mode | Example | Diff |
+|------|---------|------|
+| Since fixed point plus uncommitted (default) | `/review-style master` | `git diff $(git merge-base <fixed-point> HEAD)`, plus untracked files |
+| Committed only | `/review-style master committed only` | `git diff <fixed-point>...HEAD` |
+| Uncommitted only | `/review-style uncommitted` | `git diff HEAD`, plus untracked files |
+| Staged only | `/review-style staged` | `git diff --cached` |
+| Unstaged only | `/review-style unstaged` | `git diff`, plus untracked files |
+
+When the words don't clearly name a mode, ask. When a mode needs a fixed point and none is given, ask for it.
+Offer the merge-base with the default branch (`master` or `main`) as the suggested answer.
+
+When the caller names files, limit the diff to them, for example `git diff <fixed-point> -- <files>`. Other
+changed files stay out of the review and out of the fixes.
+
+Untracked files are those from `git ls-files --others --exclude-standard`. In the modes whose diff says "plus
+untracked files", add each one to the diff as a new file whose every line is added. The other modes leave them out.
+
+Confirm the fixed point resolves with `git rev-parse`. Stop when the diff is empty. Write the diff to one temp
+file, in the scratchpad when there is one. Also note `git log <fixed-point>..HEAD --oneline` when the mode
+includes commits.
+
+The step is done when one diff file exists and every reviewer will read that same file.
+
+### 2. Collect the repo standards
+
+Search the repository for every file that documents how code is written:
+
+- `CODING_STANDARDS.md`, `CONTRIBUTING.md`, `CODESTYLE.md`, `STYLEGUIDE.md`, and docs about style or conventions.
+  Look at the repository root, `.github/` and `docs/`.
+- `CLAUDE.md` and `AGENTS.md` at every level, plus every file they link to about code, tests or docs.
+  The block between `<!-- foifi:start` and `<!-- foifi:end -->` holds workflow rules, not repository
+  standards; count only the files it links under "Standards". In a legacy file that says a workflow generated it
+  from a template, count only the parts it names as repository standards.
+
+Skip linter and formatter configs. Tooling enforces them already.
+
+### 3. Resolve the styles
+
+Turn each path in [Styles](#styles) into an absolute path from this skill's base directory. Reviewers don't
+know that directory, so they only get absolute paths.
+
+### 4. Review in parallel
+
+Start both reviewers in one message, as foreground sub-agents:
+
+- One **repo reviewer** for all repo standards together, when step 2 found any.
+- One **style reviewer** for all styles together. Two reviewers keep the token cost flat as styles are added.
+
+Each prompt carries:
+
+- The diff file path and the commit list.
+- Its standards: the repo standard files, or the absolute paths of every style's `SKILL.md`. The style
+  reviewer reads each `SKILL.md` and every file it links to, and applies each style only where it says it
+  applies.
+- For the style reviewer, the repo standard files too, so they can suppress overridden findings.
+- The **context rule**: before judging a hunk, read its whole enclosing method and type. Follow the calls,
+  types and parents it touches whenever a rule needs them. Search the repository when a rule asks about
+  duplication.
+- The **scope rule**: anchor every finding on a changed line. Flag a problem in surrounding code only when the
+  change creates or worsens it, such as adding a fourth level of nesting. Leave problems that already existed
+  alone. Lift this rule only when the caller asked for it.
+- The brief:
+
+  > Apply every rule of your standard to every changed hunk. Report each finding as:
+  > `path:line`, a title of a few words, the quoted code, the rule (standard file plus rule name), hard or judgement, and a suggested
+  > fix in a few words. Every finding gets a suggested fix. Use one sentence when a few words can't carry it. A breach of a repo standard may be hard. A style finding is always a judgement call. Skip anything
+  > tooling enforces.
+  >
+  > Style reviewer only: when a repo standard endorses what your style would flag, report it under
+  > **Suppressed**, citing the repo rule that overrides it.
+
+### 5. Merge and report
+
+- Merge findings that flag the same line for the same reason. Cite every rule involved.
+- Number the findings `F1`, `F2`, … and group them by file.
+- Write each finding in this shape. ⛔️ marks a hard breach of a repo standard. ⚠️ marks a judgement call.
+  The title names the problem in a few words.
+  ```
+  - <icon> **<ID> <title>** _(<lines>)_
+    <what is wrong and why>
+    → <fix> _(<standards>)_
+  ```
+  For example:
+  ```
+  - ⛔️ **F1 Javadoc repeats the accessor** _(:71)_
+    `@return the entity links.` adds nothing the method name doesn't say.
+    → Drop the line. _(Repo comment rules, Doc)_
+  - ⚠️ **F7 Plural name on an invariant checker** _(:12)_
+    The plural name suggests a collection, but the class checks an invariant.
+    → Rename to `DocumentEntityLinkInvariantHelper`. _(Cog)_
+  ```
+- Every finding shows its fix. When a reviewer sent none, write one.
+- List suppressed findings in a separate **Suppressed** section, each with its overriding repo rule.
+- End with one line: findings per standard, hard violations count, and the worst issue.
+
+### 6. Fix
+
+When the caller asked for a report only, stop after step 5. When the caller asked for fixes up front, fix every
+finding. Otherwise, and only when there are findings, ask: fix all, fix hard violations only, fix the IDs I list,
+or fix nothing.
+
+Start one **fixer** sub-agent with:
+
+- The selected findings, verbatim, with their rule references.
+- The absolute paths of all standards, so it can look a rule up.
+- The brief:
+
+  > Fix each finding in the working tree. Then run the repository's documented cheap check, such as compile
+  > and format, the way its `CLAUDE.md` or `CONTRIBUTING.md` says. Leave the changes uncommitted. Report
+  > each ID as fixed or skipped, with the reason for every skip.
+
+Suppressed findings are never fixed. Relay the fixer's report.

package/src/templates/AGENTS.md

@@ -1,37 +1,35 @@
-# Repository Guide
+<!-- foifi:start — Managed by foifi. /5:reconfigure rewrites everything up to foifi:end. Everything outside this block belongs to the repository and ranks above it: it is part of the repository's own standards. -->
 
-{PROJECT_OVERVIEW}
+# Workflow Rules (foifi)
 
 ## Build & Run Commands
 
 {BUILD_RUN_COMMANDS}
 
-## Skill Usage
+## Commit Messages
 
-Before implementing changes, always check the available skills for relevant implementation guidance.
+{COMMIT_MESSAGE_RULE}
 
-Use skills to understand project-specific workflows, commands, testing expectations, and implementation conventions before editing code.
+## Standards
 
-## Commit Messages
+These rules decide how code is written here, in this order:
+
+1. **This repository's own standards always win.** They are everything in `AGENTS.md` and `CLAUDE.md` outside this block, plus these files:
+
+{REPO_STANDARDS_LINKS}
 
-Use the `/5:commit` command or `$5-commit` skill when creating commits. It reads `.5/config.json` and applies the configured `git.commitMessage.pattern`, including ticket IDs from branch names when configured.
+2. **The workflow's style skills set the baseline** wherever the repository's standards say nothing: `fowler-code-smells`, `cognitive-load`, `documentation-style`, and `baseline-conventions`. Follow them when you write or review code. Where a repository standard endorses something a style would flag, the repository standard wins.
+3. **The workflow rules below** (Simplicity First, Testing, Surgical Changes, Goal-Driven Execution) apply as well. When a repository standard asks for more, such as a changelog entry or a test, do what it asks.
 
-## Workflow Rules
+Run the `review-style` skill to check a change against all of them.
 
-When running `/5:` workflow commands, follow the command instructions exactly as written.
-Do not skip steps, combine phases, or proceed to actions not specified in the current command.
-Each phase produces a specific artifact - do not create artifacts belonging to other phases.
+## Planning
 
-## Coding Guidelines
+Plan non-trivial changes in plan mode (Codex: run `$5-plan`). Shape each plan as the change needs; add a mermaid diagram when a flow, state machine, or component relationships explain the change better than text, and plan what the repository standards require, such as tests or a changelog entry.
 
-{CONVENTIONS_REFERENCE}
+When the request names a ticket, fetch it (Jira MCP or `gh issue view`) and confirm its content with the user before planning.
 
-1. Prefer explicit types or contracts for public APIs, data transfer shapes, service methods, hooks, and async return values where the language supports them.
-2. Keep comments and docs concise; document constraints and non-obvious behavior, not the obvious.
-3. Keep files focused and bounded; split broad controllers, services, hooks, and components early.
-4. Extract helpers or classes when logic starts mixing orchestration, parsing, IO, and mapping in one place.
-5. Favor SRP and DRY, but follow surrounding module conventions before introducing new abstractions.
-6. Keep features modular: wire backend providers in feature modules, keep UI state in hooks, and avoid cross-layer shortcuts.
+After the user approves a plan, run `/5:implement {plan-path}` (Codex: `$5-implement {plan-path}`). Do not implement the plan any other way.
 
 ## Simplicity First
 
@@ -86,7 +84,7 @@ When your changes create orphans:
 
 The test: Every changed line should trace directly to the user's request.
 
-Before you report a task as done, check your own diff (`git status --short` and `git diff --stat`): revert files and changes that do not trace to the request, and remove new dependencies nobody asked for. For a deeper pass, run `/5:lean-check` (Codex: `$5-lean-check`).
+Before you report a task as done, check your own diff (`git status --short` and `git diff --stat`): revert files and changes that do not trace to the request. For every dependency the diff adds: keep it and name it in your reply if the user asked for it; otherwise remove it with the package manager and use existing code, the standard library, or an installed dependency instead. For a deeper pass, run `/5:lean-check` (Codex: `$5-lean-check`).
 
 ## Goal-Driven Execution
 
@@ -110,10 +108,4 @@ Strong success criteria let you loop independently. Weak criteria ("make it work
 
 {PROJECT_DOCUMENTATION_LINKS}
 
-## Codebase Index
-
-{CODEBASE_INDEX_LINKS}
-
-Use the `use-index` skill before running broad Glob/Grep scans. It handles freshness checks, file selection by task type, and fallback strategies. If index files are more than one day old, regenerate them by running `.5/index/rebuild-index.sh` before relying on them.
-
-{CUSTOM_DOCUMENTATION}
+<!-- foifi:end -->

package/src/templates/workflow/REVIEW-FINDINGS.md

@@ -8,12 +8,7 @@
 
 ## How to Use This File
 
-1. Review this file if you want context before applying fixes
-2. Run: `/5:address-review-findings`
-3. The command will present each finding one by one with a recommendation
-4. Choose `fix`, `wont_fix`, `wait`, or provide textual instructions
-
-The command records your decisions separately and applies only findings marked `fix`.
+`/5:review` hands this file to `/5:address-review-findings`, which fixes the clear findings on its own and asks you, one question at a time, about the rest. Run `/5:address-review-findings --interactive` to decide on every finding yourself.
 
 ---
 
@@ -44,6 +39,4 @@ The command records your decisions separately and applies only findings marked `
 - Questions: {N}
 - Manual Review: {N}
 
-**Next Steps:**
-1. Run: `/5:address-review-findings`
-2. Decide on each finding interactively
+**Next Step:** `/5:address-review-findings` (runs automatically after `/5:review`)

package/src/workflows/5-implement.js

@@ -1,9 +1,9 @@
 export const meta = {
   name: '5-implement',
-  description: 'Execute a unified plan: derive steps, run executors in parallel waves, verify. Claude Code only; Codex uses the prose loop.',
-  whenToUse: 'Invoked by the /5:implement command when the Workflow tool is available. Reads args from the command, returns the run result for the command to persist to the slim state.json.',
+  description: 'Execute a full plan: derive steps, run executors in parallel waves, verify. Claude Code only; Codex uses the prose loop.',
+  whenToUse: 'Invoked by the /5:implement command for full plans when the Workflow tool is available. Compact plans never reach it; the command implements them inline.',
   phases: [
-    { title: 'Orchestrate', detail: 'derive steps + components (agent for non-trivial plans, inline for compact)' },
+    { title: 'Orchestrate', detail: 'one orchestrator agent derives steps + components' },
     { title: 'Execute', detail: 'one executor agent per component; parallel components fire together per step' },
     { title: 'Verify', detail: 'inline when all passed + mechanical, else one verification agent' }
   ]
@@ -15,12 +15,11 @@ export const meta = {
 // the canonical human-readable contract; keep these prompts in sync with them.
 //
 // This script has NO filesystem access. It orchestrates agents and RETURNS the
-// final result. The /5:implement command (which has Write) persists the slim
-// state.json and runs auto-commit after this returns.
+// final result. The /5:implement command runs the fast-path build/test check and
+// auto-commit after this returns. Nothing is persisted: a rerun starts over.
 //
-// The execution graph (steps/components) is derived fresh on every run and is
-// NOT persisted. Resume works because component names are copied verbatim from
-// the plan's Component Checklist, so re-derivation is stable by name.
+// Models: haiku for mechanical work, sonnet for ordinary logic, opus at effort
+// medium for complex work and for every retry.
 // ─────────────────────────────────────────────────────────────────────────────
 
 const RESULT_SCHEMA = {
@@ -41,13 +40,12 @@ const RESULT_SCHEMA = {
 const VERIFICATION_SCHEMA = {
   type: 'object',
   additionalProperties: false,
-  required: ['status', 'completeness', 'infrastructure', 'quality', 'scope'],
+  required: ['status', 'completeness', 'infrastructure', 'scope'],
   properties: {
     status: { enum: ['passed', 'partial', 'failed'] },
     completeness: { enum: ['passed', 'partial', 'failed'] },
     infrastructure: { enum: ['passed', 'failed'] },
     acceptanceCriteria: { type: 'string', description: 'satisfied/total, e.g. "3/3"' },
-    quality: { enum: ['passed', 'partial', 'failed'] },
     scope: { enum: ['passed', 'drift'] },
     commands: {
       type: 'array',
@@ -81,7 +79,7 @@ const STATE_SCHEMA = {
           number: { type: 'integer' },
           name: { type: 'string' },
           mode: { enum: ['parallel', 'sequential'] },
-          model: { enum: ['haiku', 'sonnet'] },
+          model: { enum: ['haiku', 'sonnet', 'opus'] },
           components: { type: 'array', items: { type: 'string' } }
         }
       }
@@ -97,7 +95,7 @@ const STATE_SCHEMA = {
           action: { enum: ['create', 'modify', 'delete', 'rename'] },
           step: { type: 'integer' },
           mode: { enum: ['parallel', 'sequential'] },
-          model: { enum: ['haiku', 'sonnet'] },
+          model: { enum: ['haiku', 'sonnet', 'opus'] },
           file: { type: 'string' },
           sourceFile: { type: ['string', 'null'] },
           description: { type: 'string' },
@@ -130,17 +128,15 @@ function orchestratorPrompt(a) {
 
 Feature: ${a.feature}
 Plan: ${a.paths.plan}
-Codebase scan: ${a.paths.scan} (read only if present)
 Config: ${a.paths.config} (read only if present)
 
-Turn the lean component checklist in the plan into steps + components:
-- COPY EVERY COMPONENT NAME VERBATIM from the plan's Component Checklist. Resume matches components by name across runs, so a renamed or reformatted name makes completed work run twice.
+The plan has no fixed shape. Derive the components from whatever it describes: one component per target file (or tightly coupled file group), named in short kebab-case, then turn them into steps + components:
 - Group independent components into one step with mode "parallel"; use "sequential" only when components touch the same file, one imports another, or there is an explicit dependency.
 - Prefer fewer steps. Tests run after the components they validate.
-- model "haiku" by default (mechanical, UI, tests, docs, config, single-file). model "sonnet" only for complex logic, cross-module, security/auth, migrations, or public API.
-- 1-2 high-signal patternRefs per component with line ranges or symbols so executors avoid whole-file reads.
+- model "haiku" for mechanical work (UI tweaks, tests, docs, config, simple single-file edits); "sonnet" for ordinary logic; "opus" only for complex logic, cross-module behavior, security/auth, data migrations, or public API contracts.
+- 1-2 high-signal patternRefs per component with line ranges or symbols so executors avoid whole-file reads. Take them from the plan where it names patterns, else find them with Glob/Grep.
 - verifyCommands: narrowest relevant check first, then project build/test.
-- Exclude [DEFERRED] work. Represent every other component once. dependsOn must reference existing component names.
+- Exclude work the plan defers or rules out. Represent every other component once. dependsOn must reference existing component names.
 
 Return an object matching the schema (steps[] and pendingComponents[]).`
 }
@@ -148,6 +144,9 @@ Return an object matching the schema (steps[] and pendingComponents[]).`
 function executorPrompt(c, a, opts) {
   const refs = (c.patternRefs || []).map(r => `  - ${r.file}${r.read ? ` (${r.read})` : ''}${r.reason ? ` — ${r.reason}` : ''}`).join('\n') || '  - none'
   const verify = (c.verifyCommands || []).join(' && ') || 'infer the narrowest relevant test/build command'
+  const standards = a.standards || {}
+  const repoStandards = (standards.repo || []).map(f => `  - ${f}`).join('\n') || '  - none found'
+  const styles = (standards.styles || []).map(f => `  - ${f}`).join('\n') || '  - none found'
   const retry = opts && opts.retry
     ? '\nThis is a RETRY of a failed attempt — read the error context carefully and correct the root cause.'
     : ''
@@ -158,23 +157,27 @@ Action: ${c.action}
 Target file: ${c.file}${c.sourceFile ? `\nSource file (rename from): ${c.sourceFile}` : ''}
 Intent: ${c.description || ''}
 
-Read only these pattern references (ranges/symbols), plus the target file for modify/rename:
+Read only these pattern references (ranges/symbols), plus the target file for modify/rename — and for create when it already exists:
 ${refs}
 
-Rules: smallest coherent change; reuse what already exists in this codebase before writing new code, then prefer stdlib, native platform features, and installed dependencies; touch only the target file and what it strictly needs (its test, an import site); mirror existing naming/exports/layout/tests; follow any local skill or rule; add no new dependency; no abstraction or error handling beyond what the intent requires. Fix mechanical issues you cause (imports, types, lint). STOP and report failed for missing dependencies, unplanned auth/schema/API/contract changes, or unclear product decisions. If verify fails only from pre-existing unrelated issues, report that as a deviation with the exact evidence — do not mark the component failed. Do not make more than three attempts on the same failing issue.
+Standards — read the parts that apply to your target and follow them. Repository standards win over the style skills.
+Repository standards:
+${repoStandards}
+Style skills:
+${styles}
+
+Rules: Nothing is persisted between runs, so your work may already be done: for \`create\`, read the target first when it exists — if it already fulfils the intent, report success with no change; otherwise complete it, never overwrite it blindly. Smallest coherent change; reuse what already exists in this codebase before writing new code, then prefer stdlib, native platform features, and installed dependencies; touch only the target file and what it strictly needs (its test, an import site); mirror existing naming/exports/layout/tests; follow any local skill or rule; add no new dependency; no abstraction or error handling beyond what the intent requires. Fix mechanical issues you cause (imports, types, lint). STOP and report failed for missing dependencies, unplanned auth/schema/API/contract changes, or unclear product decisions. If verify fails only from pre-existing unrelated issues, report that as a deviation with the exact evidence — do not mark the component failed. Do not make more than three attempts on the same failing issue.
 
 Then run: ${verify}
 
 Return structured output: status, filesCreated, filesModified, verify, deviations (none or brief), skipped (none, or what you deliberately did not build — add when ...), error (none or description). Keep it concise — no logs or diffs unless failed.`
 }
 
-function verifyPrompt(a, results, resumeDone) {
+function verifyPrompt(a, results) {
   const ran = results.flatMap(s => s.items.map(i =>
-    `  step ${s.step} ${i.component.name}: ${i.result ? i.result.status : 'no result'} (verify ${i.result ? i.result.verify : '?'})${i.escalated ? ' [escalated to sonnet]' : ''}`))
-  const prior = [...(resumeDone || [])]
-    .filter(n => !results.some(s => s.items.some(i => i.component.name === n)))
-    .map(n => `  ${n}: completed in a prior session`)
-  const summary = [...ran, ...prior].join('\n') || '  (no components ran this invocation)'
+    `  step ${s.step} ${i.component.name}: ${i.result ? i.result.status : 'no result'} (verify ${i.result ? i.result.verify : '?'})${i.escalated ? ' [escalated to opus]' : ''}`))
+  const summary = ran.join('\n') || '  (no components ran)'
+  const repoStandards = ((a.standards && a.standards.repo) || []).join(', ') || 'none found'
   const baseline = (a.baseline && a.baseline.length)
     ? a.baseline.map(b => `  ${b.command || b.details && b.details.command || '?'}: ${b.status}${b.summary ? ` — ${b.summary}` : ''}`).join('\n')
     : '  (none recorded)'
@@ -183,6 +186,7 @@ function verifyPrompt(a, results, resumeDone) {
 Feature: ${a.feature}
 Plan: ${a.paths.plan}
 Config: ${a.paths.config} (read only if present)
+Repository standards: ${repoStandards}
 
 Baseline (pre-change) command results — treat any failure listed here as PRE-EXISTING, not caused by this change:
 ${baseline}
@@ -190,40 +194,16 @@ ${baseline}
 Component results:
 ${summary}
 
-Checks: completeness (every planned component done, acceptance criteria addressed); files exist for create/modify, rename moved correctly, delete removed; build + test pass (reuse the baseline and component results above when they already prove status — rerun only the commands whose inputs changed, not identical passing ones); correctness (inspect changed files, not just existence); quality (logic-bearing changes have tests when a test framework exists); scope (run \`git status --short\` and \`git diff HEAD --stat\`, and read untracked files directly since \`git diff HEAD\` omits them: every changed file traces to a planned component — its target, its test, or an import site; flag files outside the plan, work the plan's Scope marks Out or [DEFERRED], new dependencies no component requires, and unrequested abstractions — report drift only in scope; it does not change status). Prefer changed files over broad scanning.
+Checks — only whether the plan was built and works; code quality and correctness belong to /5:review, which runs next: completeness (every planned component done, and any acceptance criteria the plan states addressed); files exist for create/modify, rename moved correctly, delete removed; build + test pass (reuse the baseline and component results above when they already prove status — rerun only the commands whose inputs changed, not identical passing ones); scope (run \`git status --short\` and \`git diff HEAD --stat\`, and read untracked files directly since \`git diff HEAD\` omits them: every changed file traces to a planned component — its target, its test, an import site, or a file a repository standard requires (such as a changelog entry); flag files outside the plan, work the plan rules out or defers, new dependencies no component requires, and unrequested abstractions — report drift only in scope; it does not change status). Prefer changed files over broad scanning.
 
-Return structured output: status, completeness, infrastructure, acceptanceCriteria ("satisfied/total"), quality, scope, commands[], failures[] (one "drift: {path} — {why}" entry per drift finding).`
+Return structured output: status, completeness, infrastructure, acceptanceCriteria ("satisfied/total"), scope, commands[], failures[] (one "drift: {path} — {why}" entry per drift finding).`
 }
 
 // ── Helpers ──────────────────────────────────────────────────────────────────
 
-// Build a single trivial step in JS for compact plans (no orchestrator agent).
-function compactSteps(components) {
-  const norm = components.map((c, i) => ({
-    name: c.name,
-    action: c.action || 'modify',
-    step: 1,
-    mode: 'parallel',
-    model: c.model || 'haiku',
-    file: c.file,
-    sourceFile: c.sourceFile || null,
-    description: c.description || '',
-    dependsOn: c.dependsOn || [],
-    patternRefs: c.patternRefs || [],
-    verifyCommands: c.verifyCommands || [],
-    notes: []
-  }))
-  // If two components write the same file or one depends on another, fall back to sequential.
-  const files = norm.map(c => c.file)
-  const fileConflict = new Set(files).size !== files.length
-  const hasDep = norm.some(c => c.dependsOn && c.dependsOn.length)
-  const mode = (fileConflict || hasDep) ? 'sequential' : 'parallel'
-  norm.forEach(c => { c.mode = mode })
-  const stepModel = norm.some(c => c.model === 'sonnet') ? 'sonnet' : 'haiku'
-  return {
-    steps: [{ number: 1, name: 'implement', mode, model: stepModel, components: norm.map(c => c.name) }],
-    pendingComponents: norm
-  }
+// Model options per tier. Opus runs at medium effort: deep enough for complex work, cheaper than high.
+function modelOpts(model) {
+  return model === 'opus' ? { model: 'opus', effort: 'medium' } : { model: model || 'haiku' }
 }
 
 async function runStep(step, components, a) {
@@ -234,28 +214,28 @@ async function runStep(step, components, a) {
   if (step.mode === 'parallel' && stepComps.length > 1) {
     // Fire every parallel component together — true concurrency, one wave.
     waveResults = await parallel(stepComps.map(c => () =>
-      agent(executorPrompt(c, a), { label: `exec:${c.name}`, phase: 'Execute', model: c.model || 'haiku', schema: RESULT_SCHEMA })
+      agent(executorPrompt(c, a), { label: `exec:${c.name}`, phase: 'Execute', ...modelOpts(c.model), schema: RESULT_SCHEMA })
         .then(result => ({ component: c, result }))
         .catch(() => ({ component: c, result: null }))))
   } else {
     waveResults = []
     for (const c of stepComps) {
-      const result = await agent(executorPrompt(c, a), { label: `exec:${c.name}`, phase: 'Execute', model: c.model || 'haiku', schema: RESULT_SCHEMA })
+      const result = await agent(executorPrompt(c, a), { label: `exec:${c.name}`, phase: 'Execute', ...modelOpts(c.model), schema: RESULT_SCHEMA })
         .catch(() => null)
       waveResults.push({ component: c, result })
     }
   }
 
-  // Retry failed OR crashed (null) components up to twice, escalating to sonnet.
+  // Retry failed OR crashed (null) components up to twice, escalating to opus.
   // A crashed agent (null result) is retried too — an infra error should not be
   // treated more harshly than a clean structured failure.
   for (const wr of waveResults) {
     let attempt = 1
     while ((wr.result == null || wr.result.status === 'failed') && attempt <= 2) {
-      log(`retry ${wr.component.name} (attempt ${attempt + 1}) on sonnet`)
+      log(`retry ${wr.component.name} (attempt ${attempt + 1}) on opus`)
       wr.escalated = true
       const retried = await agent(executorPrompt(wr.component, a, { retry: true }),
-        { label: `retry:${wr.component.name}`, phase: 'Execute', model: 'sonnet', schema: RESULT_SCHEMA }).catch(() => null)
+        { label: `retry:${wr.component.name}`, phase: 'Execute', ...modelOpts('opus'), schema: RESULT_SCHEMA }).catch(() => null)
       if (retried) wr.result = retried
       attempt++
     }
@@ -267,35 +247,25 @@ async function runStep(step, components, a) {
 // ── Main ─────────────────────────────────────────────────────────────────────
 
 const a = args || {}
-const resumeDone = new Set(a.completedComponents || [])
 
 phase('Orchestrate')
-if (resumeDone.size) log(`resume: ${resumeDone.size} component(s) already complete, matched by name`)
-let plan
-if (a.isCompact && Array.isArray(a.components) && a.components.length) {
-  log(`compact plan: ${a.components.length} component(s), no orchestrator agent`)
-  plan = compactSteps(a.components)
-} else {
-  plan = await agent(orchestratorPrompt(a), { label: 'orchestrate', phase: 'Orchestrate', schema: STATE_SCHEMA })
-}
+const plan = await agent(orchestratorPrompt(a), { label: 'orchestrate', phase: 'Orchestrate', schema: STATE_SCHEMA })
 const steps = plan.steps
 const components = plan.pendingComponents
 
 phase('Execute')
 const results = []
 for (const step of steps) {
-  const remaining = components.filter(c => step.components.includes(c.name) && !resumeDone.has(c.name))
-  if (!remaining.length) { log(`step ${step.number} already complete (resume), skipping`); continue }
-  const stepResult = await runStep({ ...step, components: remaining.map(c => c.name) }, components, a)
-  results.push(stepResult)
+  results.push(await runStep(step, components, a))
 }
 
 phase('Verify')
 const allItems = results.flatMap(s => s.items)
 const allPassed = allItems.length > 0 && allItems.every(i => i.result && i.result.status === 'success' && i.result.verify !== 'failed')
-// Non-mechanical when a component was planned as sonnet OR needed a sonnet retry to pass —
-// either signals reasoning-level work that warrants the full verification agent.
-const usedSonnet = components.some(c => (c.model || 'haiku') === 'sonnet') || allItems.some(i => i.escalated)
+// Mechanical when every component was planned as haiku and none needed a retry; anything
+// else signals reasoning-level work that warrants the full verification agent.
+const usedOpus = components.some(c => c.model === 'opus') || allItems.some(i => i.escalated)
+const mechanical = !usedOpus && components.every(c => (c.model || 'haiku') === 'haiku')
 // Deterministic scope signal: files an executor touched beyond its planned target(s).
 // Tests and import sites are legitimate, so this is reported for the user, never a failure.
 const extraFiles = allItems.flatMap(i => {
@@ -306,29 +276,21 @@ const extraFiles = allItems.flatMap(i => {
 })
 if (extraFiles.length) log(`scope: ${extraFiles.length} file(s) touched outside planned targets`)
 let verification
-if (allPassed && !usedSonnet) {
-  log('all components passed + mechanical (no sonnet, no escalation) — inline verify, no verification agent')
-  // No git access here: /5:implement runs the fast-path scope check itself when it sees inline: true.
-  verification = { status: 'passed', completeness: 'passed', infrastructure: 'passed', acceptanceCriteria: 'n/a', quality: 'passed', commands: [], failures: [], inline: true }
+if (allPassed && mechanical) {
+  log('all components passed + mechanical — no verification agent; /5:implement runs build/test and the scope check')
+  // No shell access here: /5:implement runs build/test and the scope check itself when it sees inline: true.
+  verification = { status: 'passed', completeness: 'passed', infrastructure: 'passed', acceptanceCriteria: 'n/a', commands: [], failures: [], inline: true }
 } else {
-  if (!allItems.length) log('no components ran this invocation (resume) — verifying the already-completed feature against the plan')
-  verification = await agent(verifyPrompt(a, results, resumeDone), {
-    label: 'verify', phase: 'Verify', model: usedSonnet ? 'sonnet' : 'haiku', schema: VERIFICATION_SCHEMA
+  verification = await agent(verifyPrompt(a, results), {
+    label: 'verify', phase: 'Verify', ...modelOpts(usedOpus ? 'opus' : 'sonnet'), schema: VERIFICATION_SCHEMA
   })
 }
 
-// Union prior + newly-succeeded so the command can MERGE (not replace) completed history on resume.
-const newlyCompleted = allItems.filter(i => i.result && i.result.status === 'success').map(i => i.component.name)
-const completedComponents = [...new Set([...resumeDone, ...newlyCompleted])]
-
-// Returned to the /5:implement command, which persists the slim state.json and auto-commits.
-// steps + components are returned for reporting and per-step staging only — they are NOT persisted;
-// the next run re-derives them, and resume matches on completedComponents by name.
+// Returned to the /5:implement command for the fast-path check, per-step staging, and the report.
 return {
   feature: a.feature,
   steps,
   components,
-  completedComponents,
   results: results.map(s => ({
     step: s.step,
     name: s.name,