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

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -6,18 +6,18 @@
6
6
 
7
7
  **Project setup** — The `/5:configure` command detects your stack, generates a `CLAUDE.md` / `AGENTS.md` tailored to your project, writes a `.5/index/` knowledge base, and installs project-specific skills and rules. This gives every AI session the right context from the start rather than letting the model guess.
8
8
 
9
- **Status line** — foifi installs an informative Claude Code status line that surfaces the active feature, current workflow phase, and relevant state directly in the terminal footer. No more digging through files to remember where you left off.
9
+ **Status line** — foifi installs a Claude Code status line that surfaces the installed version, available updates, and pending reconfigure/migration reminders directly in the terminal footer.
10
10
 
11
11
  **Structured implementation workflow** — Instead of asking Claude or Codex to "just implement this," foifi enforces a three-phase loop:
12
- 1. **Plan** (`/5:plan`) — writes a single human-reviewed `plan.md` with scope, acceptance criteria, component checklist, and decisions.
13
- 2. **Implement** (`/5:implement`) — an orchestrator agent turns the plan into a typed execution graph (`state.json`), then delegates each component to a focused executor agent. A verification agent checks completeness, correctness, and test coverage at the end of every run.
14
- 3. **Review** (`/5:review`) — triages changed files, produces structured findings, and feeds them into `/5:address-review-findings` for interactive fix decisions and PR replies.
12
+ 1. **Plan** (`/5:plan`) — wraps Claude Code's native plan mode and persists the approved result as a single human-reviewed `plan.md` with scope, acceptance criteria, component checklist, and decisions. Run it again on the same feature to refine that plan. Small plans are implemented right there on approval; larger ones hand off to step 2.
13
+ 2. **Implement** (`/5:implement`) — an orchestrator agent turns the plan into a typed execution graph, then delegates each component to a focused executor agent, firing independent components in parallel waves. A verification agent checks completeness, correctness, and test coverage at the end of every run.
14
+ 3. **Review** (`/5:review`) — wraps Claude Code's built-in `code-review` skill, produces structured findings, and feeds them into `/5:address-review-findings` for interactive fix decisions and PR replies.
15
15
 
16
- This separation keeps planning readable, implementation mechanical, and review structured.
16
+ This separation keeps planning readable, implementation mechanical, and review structured. Where Claude Code ships a native capability, foifi wraps it rather than reimplementing it — what foifi adds is the durable repo-local artifact and the ticket/config conventions around it.
17
17
 
18
18
  **Code review and findings** — `/5:review` triages changed files and produces structured `review-findings-*.md`. `/5:address-review-findings` presents each finding interactively, records `fix`/`wont_fix`/`wait` decisions, applies approved local fixes, handles PR comment replies, and keeps a decision log — all without losing context between sessions.
19
19
 
20
- **Plan management helpers** — `/5:discuss-feature` refines an existing plan in conversation. `/5:split` breaks a large plan into smaller linked child plans. `/5:unlock` clears a stale planning lock. `/5:reconfigure` refreshes docs and skills when the project evolves.
20
+ **Plan management helpers** — `/5:split` breaks a large plan into smaller linked child plans. `/5:reconfigure` refreshes docs and skills when the project evolves.
21
21
 
22
22
  **Codex support** — Every command has a `$5-*` Codex equivalent. Codex runs are token-budgeted: simple steps use a lighter model and low reasoning, complex or security-sensitive steps escalate automatically.
23
23
 
@@ -81,24 +81,22 @@ $5-review
81
81
  $5-address-review-findings {feature-name}
82
82
  ```
83
83
 
84
- Verification runs at the end of `/5:implement` and records concise results in `state.json`.
84
+ Verification runs at the end of `/5:implement` and records a concise result in `state.json`.
85
85
 
86
86
  ## Commands
87
87
 
88
88
  | Command | Purpose |
89
89
  |---------|---------|
90
90
  | `/5:configure` / `$5-configure` | Detect project settings and write the CONFIGURE plan |
91
- | `/5:plan` / `$5-plan` | Create one unified `plan.md` from requirements, codebase exploration, and user decisions |
92
- | `/5:discuss-feature` / `$5-discuss-feature` | Refine an existing `plan.md` |
91
+ | `/5:plan` / `$5-plan` | Create one unified `plan.md` from requirements, codebase exploration, and user decisions — or refine an existing one |
93
92
  | `/5:split` / `$5-split` | Split an existing plan into smaller linked plans for separate implementation |
94
- | `/5:implement` / `$5-implement` | Derive `state.json`, execute steps with agents, and verify inline |
93
+ | `/5:implement` / `$5-implement` | Derive the execution graph, execute steps with agents, and verify inline |
95
94
  | `/5:review` / `$5-review` | Review code changes and save findings |
96
95
  | `/5:commit` / `$5-commit` | Create a git commit using the configured commit message template |
97
96
  | `/5:address-review-findings` / `$5-address-review-findings` | Decide on review findings interactively, then apply approved fixes and PR comments |
98
97
  | `/5:reconfigure` / `$5-reconfigure` | Refresh docs, index, skills, and rules |
99
98
  | `/5:update` / `$5-update` | Upgrade installed workflow files |
100
99
  | `/5:eject` / `$5-eject` | Stop workflow-managed updates |
101
- | `/5:unlock` / `$5-unlock` | Remove a stale planning guard lock |
102
100
  | `/5:synchronize-agents` / `$5-synchronize-agents` | Sync user content between Claude Code and Codex |
103
101
 
104
102
  ## Artifacts
@@ -107,8 +105,7 @@ Each feature lives under `.5/features/{feature-name}/`:
107
105
 
108
106
  - `plan.md` - single human-reviewed planning artifact
109
107
  - `codebase-scan.md` - cached discovery used to reduce repeated scanning
110
- - `state.json` - enriched execution state derived by `step-orchestrator-agent`
111
- - `state-events.jsonl` - detailed execution history for retries, commands, commits, and verification
108
+ - `state.json` - small resume record: status, completed components, verification result
112
109
  - `split-manifest-*.json` - parent feature record for child plans created by `/5:split`
113
110
  - `review-findings-*.md` - review output for `/5:address-review-findings`
114
111
  - `review-decisions-*.json` - interactive fix/wont-fix/wait decisions for local findings
@@ -116,13 +113,15 @@ Each feature lives under `.5/features/{feature-name}/`:
116
113
 
117
114
  ## Design
118
115
 
119
- Planning stays human-readable. `plan.md` contains scope, acceptance criteria, decisions, module impact, and a clean component checklist. Small low-risk changes can use the compact plan template. Plans intentionally do not ask the planner to fill model choices, verify commands, step grouping, or pattern-file wiring.
116
+ Planning stays human-readable. Claude Code's native plan mode does the exploring, the asking, and the approval gate; `/5:plan` contributes the ticket lookup, the feature folder convention, and the artifact schema, then persists the approved plan. `plan.md` contains scope, acceptance criteria, decisions, module impact, and a clean component checklist. Small low-risk changes can use the compact plan template. Plans intentionally do not ask the planner to fill model choices, verify commands, step grouping, or pattern-file wiring.
120
117
 
121
- Implementation is mechanical. `step-orchestrator-agent` reads `plan.md` and `codebase-scan.md`, derives the execution graph into compact `state.json`, then `/5:implement` delegates each component to `step-executor-agent` with an inline executor contract. Pattern context is passed as targeted references instead of broad file lists so executors can read only the relevant ranges. Detailed history is appended to `state-events.jsonl`. This reduces planning token cost and avoids brittle prompt-table metadata.
118
+ Delegation is matched to the size of the job. Approving a plan means you want it built, so `/5:plan` finishes compact plans itself — for one or two files, the already-warm session beats anything an orchestrator can set up. Full plans go to `/5:implement`, where the cost is repaid: `step-orchestrator-agent` reads `plan.md` and `codebase-scan.md` and returns an execution graph, then each component goes to a `step-executor-agent` with an inline executor contract, independent components firing in parallel. Pattern context is passed as targeted references instead of broad file lists so executors read only the relevant ranges, and mechanical components run on a cheaper model than the ones that need reasoning.
122
119
 
123
- Verification uses a dedicated agent. `/5:implement` runs `verification-agent` at the end and records a concise final status in `state.json` without generating an extra report.
120
+ State is kept to what is actually read. The execution graph is derived fresh on every run and never written to disk; `state.json` persists only the status, the completed component names, and the verification result, which is all a resume needs. Component names are copied verbatim from the plan's checklist, so a re-derived graph still matches what already ran. Live progress comes from the task list, not from a file.
124
121
 
125
- Review is risk-based. Native review triages changed files first and reads full files only for risky changes or when diff context is insufficient. `/5:address-review-findings` presents each finding one by one with a recommendation, records `fix`/`wont_fix`/`wait` decisions, then coordinates narrower helpers for approved local fixes, PR comment triage, and PR replies so the common path stays compact.
122
+ Verification uses a dedicated agent. `/5:implement` runs `verification-agent` at the end, passing it the pre-change baseline so pre-existing failures are not blamed on the change, and records a concise final status without generating an extra report.
123
+
124
+ Review delegates to Claude Code's built-in `code-review` skill (default effort `high`, override with `/5:review {low|medium|high|max}`) and maps its findings into the workflow's findings file. Where that skill is unavailable — Codex, for example — a built-in review agent takes over and triages changed files by risk instead. `/5:address-review-findings` presents each finding one by one with a recommendation, records `fix`/`wont_fix`/`wait` decisions, then coordinates narrower helpers for approved local fixes, PR comment triage, and PR replies so the common path stays compact.
126
125
 
127
126
  Reconfiguration uses a compact `.5/reconfigure-manifest.json` to pass refresh decisions to documentation and skill generation helpers without duplicating long detection summaries in prompts.
128
127
 
package/bin/install.js CHANGED
@@ -372,7 +372,14 @@ const LEGACY_REMOVED_FILES = [
372
372
  'skills/5-verify-implementation',
373
373
  'skills/5-review-code',
374
374
  'skills/5-quick-implement',
375
- 'skills/configure-project'
375
+ 'skills/configure-project',
376
+ // v2.2: native plan mode replaces the plan guard; /5:plan absorbed discuss-feature
377
+ 'hooks/plan-guard.js',
378
+ 'commands/5/unlock.md',
379
+ 'commands/5/discuss-feature.md',
380
+ 'templates/workflow/STATE.json',
381
+ 'skills/5-unlock',
382
+ 'skills/5-discuss-feature'
376
383
  ];
377
384
 
378
385
  // Get list of workflow-owned files/directories (not user-created)
@@ -388,6 +395,11 @@ function getWorkflowManagedFiles() {
388
395
  'verification-agent.md'
389
396
  ],
390
397
 
398
+ // Workflows: Claude Code only (Workflow tool). Not installed for Codex.
399
+ workflows: [
400
+ '5-implement.js'
401
+ ],
402
+
391
403
  // Skills: specific skill directories
392
404
  skills: [
393
405
  'configure-docs-index',
@@ -401,7 +413,6 @@ function getWorkflowManagedFiles() {
401
413
  'statusline.js',
402
414
  'check-updates.js',
403
415
  'check-reconfig.js',
404
- 'plan-guard.js',
405
416
  'config-guard.js'
406
417
  ],
407
418
 
@@ -426,7 +437,6 @@ function getWorkflowManagedFiles() {
426
437
  // Workflow output templates
427
438
  'workflow/PLAN.md',
428
439
  'workflow/PLAN-COMPACT.md',
429
- 'workflow/STATE.json',
430
440
  'workflow/REVIEW-FINDINGS.md',
431
441
  'workflow/REVIEW-SUMMARY.md',
432
442
  'workflow/FIX-PLAN.md'
@@ -451,6 +461,13 @@ function getFileManifest() {
451
461
  manifest.push(`agents/${agent}`);
452
462
  }
453
463
 
464
+ // Workflows are files (Claude Code only)
465
+ if (managed.workflows) {
466
+ for (const wf of managed.workflows) {
467
+ manifest.push(`workflows/${wf}`);
468
+ }
469
+ }
470
+
454
471
  // Skills are directories
455
472
  for (const skill of managed.skills) {
456
473
  manifest.push(`skills/${skill}`);
@@ -557,7 +574,20 @@ This skill was authored for Claude Code. Map these tool references:
557
574
  | \`Glob\` | \`glob\` / \`list_directory\` |
558
575
  | \`Grep\` | \`grep\` / \`search\` |
559
576
  | \`TaskCreate/TaskUpdate\` | Track progress internally |
560
- | \`EnterPlanMode\` | Not available — use structured output instead |
577
+ | \`Workflow\` | Not available — run the command's prose fallback loop instead |
578
+ | \`Skill(skill="code-review")\` | Not available — run the command's prose fallback loop instead |
579
+ | \`EnterPlanMode\` | Not available — run the command's prose fallback loop instead |
580
+
581
+ ## Model Mapping (single source of truth)
582
+ When a skill, plan, or execution-graph component names a model, map it to Codex as:
583
+
584
+ | Named model | Codex model | reasoning_effort |
585
+ |-------------|-------------|------------------|
586
+ | \`haiku\` (or unset) | \`gpt-5.4-mini\` | \`low\` |
587
+ | \`sonnet\` | \`gpt-5.4\` | \`medium\` |
588
+ | Explore / explorer agent | \`gpt-5.4-mini\` (\`agent_type: explorer\`) | \`low\` |
589
+
590
+ This table is authoritative — skill bodies do not repeat per-call model mappings.
561
591
 
562
592
  ## Codex Token Budget
563
593
  - Default to \`gpt-5.4-mini\` with \`reasoning_effort: low\` for exploration, orchestration, simple implementation, and mechanical file edits.
@@ -565,12 +595,14 @@ This skill was authored for Claude Code. Map these tool references:
565
595
  - Use stronger models only when a previous cheaper attempt failed for reasoning reasons.
566
596
  - Keep the parent skill context lean: delegate read-heavy exploration to explorer agents and pass only compact findings, target paths, pattern references, and command summaries between agents.
567
597
 
568
- ## Guard Rules (replaces plan-guard hook)
569
- During the planning phase ($5-plan):
598
+ ## Guard Rules (Codex has no plan mode)
599
+ Claude Code enforces these at the harness level via native plan mode. Codex has no equivalent, so honour them yourself while running \`$5-plan\`, **until the user approves the plan**:
570
600
  - Do NOT write to any file outside \`.5/\`
571
601
  - Do NOT write source code — only the unified plan and scan cache
572
602
  - Do NOT spawn implementation agents — only Explore/research agents
573
603
 
604
+ After approval, \`$5-plan\` implements compact plans inline and hands larger ones to \`$5-implement\`.
605
+
574
606
  ## Update & Migration Notices (replaces statusline hooks)
575
607
  At the very start of this skill, before doing anything else, read these two files if they exist:
576
608
  - \`.5/.update-cache.json\` — if \`latestAvailableVersion\` is set, compare it to \`packageVersion\` in \`.5/version.json\`. If a newer version is available, tell the user: "foifi update available: <version> — run \`npx foifi --codex --upgrade\` to update."
@@ -696,6 +728,25 @@ function selectiveUpdate(targetPath, sourcePath) {
696
728
  log.success('Updated agents/ (workflow files only)');
697
729
  }
698
730
 
731
+ // Update workflow scripts (Claude Code only — Workflow tool)
732
+ if (managed.workflows && managed.workflows.length > 0) {
733
+ const workflowsSrc = path.join(sourcePath, 'workflows');
734
+ const workflowsDest = path.join(targetPath, 'workflows');
735
+ if (!fs.existsSync(workflowsDest)) {
736
+ fs.mkdirSync(workflowsDest, { recursive: true });
737
+ }
738
+ for (const wf of managed.workflows) {
739
+ const src = path.join(workflowsSrc, wf);
740
+ const dest = path.join(workflowsDest, wf);
741
+ if (fs.existsSync(src)) {
742
+ fs.copyFileSync(src, dest);
743
+ } else {
744
+ log.warn(`Workflow source missing, skipped: ${wf}`);
745
+ }
746
+ }
747
+ log.success('Updated workflows/ (workflow files only)');
748
+ }
749
+
699
750
  // Update specific skills
700
751
  const skillsSrc = path.join(sourcePath, 'skills');
701
752
  const skillsDest = path.join(targetPath, 'skills');
@@ -1022,7 +1073,7 @@ function checkExistingInstallation(targetPath) {
1022
1073
  function showCommandsHelp(isGlobal) {
1023
1074
  if (activeRuntime === 'codex') {
1024
1075
  log.info('Available skills (invoke with $ prefix in Codex):');
1025
- log.info(' $5-plan - Create unified plan');
1076
+ log.info(' $5-plan - Create or refine a unified plan');
1026
1077
  log.info(' $5-split - Split plan into smaller plans');
1027
1078
  log.info(' $5-implement - Execute implementation + verification');
1028
1079
  log.info(' $5-review - Code review');
@@ -1031,11 +1082,10 @@ function showCommandsHelp(isGlobal) {
1031
1082
  log.info(' $5-configure - Interactive project setup');
1032
1083
  log.info(' $5-reconfigure - Refresh docs/skills (no Q&A)');
1033
1084
  log.info(' $5-eject - Eject from update mechanism');
1034
- log.info(' $5-unlock - Remove planning guard lock');
1035
1085
  log.info(' $5-synchronize-agents - Sync user content between runtimes');
1036
1086
  } else {
1037
1087
  log.info('Available commands:');
1038
- log.info(' /5:plan - Create unified plan');
1088
+ log.info(' /5:plan - Create or refine a unified plan');
1039
1089
  log.info(' /5:split - Split plan into smaller plans');
1040
1090
  log.info(' /5:implement - Execute implementation + verification');
1041
1091
  log.info(' /5:review - Code review');
@@ -1044,7 +1094,6 @@ function showCommandsHelp(isGlobal) {
1044
1094
  log.info(' /5:configure - Interactive project setup');
1045
1095
  log.info(' /5:reconfigure - Refresh docs/skills (no Q&A)');
1046
1096
  log.info(' /5:eject - Eject from update mechanism');
1047
- log.info(' /5:unlock - Remove planning guard lock');
1048
1097
  log.info(' /5:synchronize-agents - Sync user content between runtimes');
1049
1098
  }
1050
1099
  log.info('');
@@ -1059,8 +1108,8 @@ function performFreshInstall(targetPath, sourcePath, isGlobal) {
1059
1108
  log.success(`Created ${targetPath}`);
1060
1109
  }
1061
1110
 
1062
- // Copy directories
1063
- const dirs = ['commands', 'agents', 'skills', 'hooks', 'templates', 'references'];
1111
+ // Copy directories (workflows is Claude Code only; performCodexFreshInstall never copies it)
1112
+ const dirs = ['commands', 'agents', 'workflows', 'skills', 'hooks', 'templates', 'references'];
1064
1113
  for (const dir of dirs) {
1065
1114
  const src = path.join(sourcePath, dir);
1066
1115
  const dest = path.join(targetPath, dir);
@@ -1143,6 +1192,38 @@ function removeContextForkFromSkills(targetPath) {
1143
1192
  } catch (e) {}
1144
1193
  }
1145
1194
 
1195
+ // Remove the plan-guard PreToolUse hook entry from an existing settings.json.
1196
+ // Native plan mode enforces read-only planning at the harness level, so the hook
1197
+ // is gone. Claude Code only — Codex never had a settings.json.
1198
+ function removePlanGuardHook(targetPath) {
1199
+ const settingsFile = path.join(targetPath, 'settings.json');
1200
+ if (!fs.existsSync(settingsFile)) return;
1201
+ try {
1202
+ const settings = JSON.parse(fs.readFileSync(settingsFile, 'utf8'));
1203
+ const pre = settings.hooks && settings.hooks.PreToolUse;
1204
+ if (!Array.isArray(pre)) return;
1205
+ const kept = pre.filter(entry =>
1206
+ !(entry.hooks || []).some(h => typeof h.command === 'string' && h.command.includes('plan-guard.js')));
1207
+ if (kept.length === pre.length) return;
1208
+ if (kept.length) settings.hooks.PreToolUse = kept;
1209
+ else delete settings.hooks.PreToolUse;
1210
+ if (settings.hooks && !Object.keys(settings.hooks).length) delete settings.hooks;
1211
+ fs.writeFileSync(settingsFile, JSON.stringify(settings, null, 2));
1212
+ log.info('Removed plan-guard hook from settings.json (native plan mode replaces it)');
1213
+ } catch (e) {}
1214
+ }
1215
+
1216
+ // Delete the stale .5/.planning-active marker. It only existed to drive plan-guard.
1217
+ function removePlanningActiveMarker(dataDir) {
1218
+ try {
1219
+ const marker = path.join(dataDir, '.planning-active');
1220
+ if (fs.existsSync(marker)) {
1221
+ fs.unlinkSync(marker);
1222
+ log.info('Removed stale .5/.planning-active marker');
1223
+ }
1224
+ } catch (e) {}
1225
+ }
1226
+
1146
1227
  // Perform update (preserves user-created files, updates .5/ data directory)
1147
1228
  function performUpdate(targetPath, sourcePath, isGlobal, versionInfo) {
1148
1229
  log.header(`Updating from ${versionInfo.installed || 'legacy'} to ${versionInfo.available}`);
@@ -1164,6 +1245,10 @@ function performUpdate(targetPath, sourcePath, isGlobal, versionInfo) {
1164
1245
  // Strip `context: fork` from generated skills — caused infinite loops
1165
1246
  removeContextForkFromSkills(targetPath);
1166
1247
 
1248
+ // Native plan mode replaces the plan-guard hook and its marker file
1249
+ removePlanGuardHook(targetPath);
1250
+ removePlanningActiveMarker(dataDir);
1251
+
1167
1252
  // Flag v1 → v2 major upgrade so statusline can prompt for reconfigure
1168
1253
  const prevMajor = versionInfo.installed ? parseInt(versionInfo.installed.split('.')[0], 10) : 0;
1169
1254
  const newMajor = versionInfo.available ? parseInt(versionInfo.available.split('.')[0], 10) : 0;
@@ -1213,14 +1298,13 @@ The workflow provides structured feature development:
1213
1298
  All workflow state lives in \`.5/\` at the project root:
1214
1299
  - \`.5/config.json\` — Project configuration
1215
1300
  - \`.5/features/{name}/plan.md\` — Unified plan
1216
- - \`.5/features/{name}/state.json\` — Implementation state
1301
+ - \`.5/features/{name}/state.json\` — Implementation resume state
1217
1302
 
1218
1303
  ## Guard Rules
1219
1304
 
1220
- During the planning phase ($5-plan):
1305
+ During the planning phase ($5-plan), until the user approves the plan:
1221
1306
  - Do NOT write files outside \`.5/\`
1222
1307
  - Do NOT write source code — only the unified plan and scan cache
1223
- - The \`.5/.planning-active\` marker indicates planning is in progress
1224
1308
 
1225
1309
  ## Configuration
1226
1310
 
@@ -1417,6 +1501,9 @@ function performCodexUpdate(targetPath, sourcePath, isGlobal, versionInfo) {
1417
1501
  // Rename create-* skill dirs to bare pattern names (create-dto → dto)
1418
1502
  renameCreateSkills(targetPath);
1419
1503
 
1504
+ // The plan-guard marker is shared .5/ state; Codex has no settings.json hook to remove
1505
+ removePlanningActiveMarker(dataDir);
1506
+
1420
1507
  // Flag v1 → v2 major upgrade so skills can prompt for reconfigure
1421
1508
  const prevMajor = versionInfo.installed ? parseInt(versionInfo.installed.split('.')[0], 10) : 0;
1422
1509
  const newMajor = versionInfo.available ? parseInt(versionInfo.available.split('.')[0], 10) : 0;
@@ -1668,6 +1755,17 @@ function uninstall() {
1668
1755
  }
1669
1756
  log.success('Removed workflow agents (preserved user-created agents)');
1670
1757
 
1758
+ // Remove only workflow-managed workflow scripts (Claude Code only)
1759
+ if (managed.workflows) {
1760
+ for (const wf of managed.workflows) {
1761
+ const wfPath = path.join(targetPath, 'workflows', wf);
1762
+ if (fs.existsSync(wfPath)) {
1763
+ fs.unlinkSync(wfPath);
1764
+ }
1765
+ }
1766
+ log.success('Removed workflow scripts');
1767
+ }
1768
+
1671
1769
  // Remove only workflow-managed skills
1672
1770
  for (const skill of managed.skills) {
1673
1771
  const skillPath = path.join(targetPath, 'skills', skill);
@@ -14,9 +14,10 @@ The workflow separates human decisions from mechanical execution.
14
14
 
15
15
  - `plan.md` is the only planning artifact.
16
16
  - `codebase-scan.md` caches discovery so later phases avoid repeated scanning.
17
- - `state.json` is generated by `step-orchestrator-agent` and drives implementation.
18
- - `state-events.jsonl` stores detailed execution history so `state.json` stays compact.
19
- - `verification-agent` records final verification status in `state.json`.
17
+ - The execution graph is derived by `step-orchestrator-agent` on every run and is never written to disk.
18
+ - `state.json` persists only what a resume needs: status, completed component names, and the verification result.
19
+
20
+ Where Claude Code ships a native capability, the workflow wraps it: `/5:plan` runs inside native plan mode and `/5:review` calls the built-in `code-review` skill. Codex has neither, so both commands keep a prose fallback.
20
21
 
21
22
  This keeps planning short and reviewable while still giving implementation agents enough structured data to work reliably.
22
23
 
@@ -56,41 +57,46 @@ The planner gathers requirements, explores the codebase, asks targeted questions
56
57
 
57
58
  The component checklist has only four columns: component, action, target path, intent. It does not contain step grouping, model selection, verify commands, or pattern-reference wiring.
58
59
 
60
+ Which template gets chosen also decides what happens on approval: a compact plan is implemented immediately in the same session, while a full plan stops after writing the artifacts and points you at `/5:implement`.
61
+
59
62
  ## Refining A Plan
60
63
 
61
64
  Run:
62
65
 
63
66
  ```text
64
- /5:discuss-feature {feature-name}
67
+ /5:plan {feature-name}
65
68
  ```
66
69
 
67
- Use this when the reviewed plan needs changed scope, additional acceptance criteria, or a corrected component checklist.
70
+ With an existing `plan.md`, `/5:plan` enters refine mode: it seeds plan mode with the current plan, discusses the changes, then overwrites the file and appends a `## Discussion History` entry. Use this when the reviewed plan needs changed scope, additional acceptance criteria, or a corrected component checklist.
68
71
 
69
72
  ## Implement
70
73
 
74
+ Compact plans never reach this command. Approving a plan means you want it built, so `/5:plan` implements a 1-2 component plan inline in the session that planned it and writes the same `state.json` — orchestration would cost more than it saves at that size. What follows applies to full plans.
75
+
71
76
  Run:
72
77
 
73
78
  ```text
74
79
  /5:implement {feature-name}
75
80
  ```
76
81
 
82
+ Prefer a fresh context first — `/clear` in Claude Code, a new conversation in Codex. This command needs only `plan.md` and `codebase-scan.md`, and dropping the planning conversation is the point of the handoff. It is a recommendation, not a requirement.
83
+
77
84
  Implementation does three things:
78
85
 
79
- 1. Spawns `step-orchestrator-agent` to derive compact `state.json` from `plan.md` and `codebase-scan.md`.
86
+ 1. Spawns `step-orchestrator-agent` to derive the execution graph from `plan.md` and `codebase-scan.md` — steps, execution mode, dependency edges, model choice, targeted pattern references, and verify commands.
80
87
  2. Spawns executor agents for each component using an inline executor contract, parallelizing independent work.
81
- 3. Spawns `verification-agent` to verify completeness, correctness, build/tests, acceptance criteria, and test coverage, then records the result in `state.json`.
88
+ 3. Spawns `verification-agent` to verify completeness, correctness, build/tests, acceptance criteria, and test coverage.
89
+
90
+ The graph is transient. `state.json` records only:
82
91
 
83
- `state.json` tracks:
92
+ - `status` — `in-progress`, `completed`, or `failed`
93
+ - `completedComponents` — the names of components that finished
94
+ - `verification` — final status plus a one-line summary
95
+ - `startedAt` / `lastUpdated`
84
96
 
85
- - steps and execution mode
86
- - pending/completed/failed components
87
- - dependency edges
88
- - targeted pattern references
89
- - verify commands
90
- - baseline and verification results
91
- - compact latest command/commit summaries, with detailed history in `state-events.jsonl`
97
+ Live progress during a run comes from the task list rather than the file.
92
98
 
93
- If implementation is interrupted, rerun `/5:implement {feature-name}` to resume from the recorded step.
99
+ If implementation is interrupted, rerun `/5:implement {feature-name}` to resume. The graph is re-derived and components already in `completedComponents` are skipped — which works because component names are copied verbatim from the plan's checklist. Note that the Workflow path writes `state.json` only when the run returns, so a run killed mid-way repeats the components it had finished.
94
100
 
95
101
  Verification runs inline during `/5:implement`. It checks planned files, final build/test commands, acceptance criteria, and recorded component verification outcomes.
96
102
 
@@ -102,13 +108,13 @@ Run:
102
108
  /5:review
103
109
  ```
104
110
 
105
- Review can use native agent review or CodeRabbit if configured. Native review triages changed files by risk and reads full files only for high-risk changes or when diff context is insufficient. It saves findings to:
111
+ On Claude Code, review delegates to the built-in `code-review` skill. Effort defaults to `high`; pass `/5:review low|medium|high|max` to override. Where that skill is unavailable (Codex), a built-in review agent triages changed files by risk and reads full files only for high-risk changes or when diff context is insufficient. Either way it saves findings to:
106
112
 
107
113
  ```text
108
114
  .5/features/{feature-name}/review-findings-{timestamp}.md
109
115
  ```
110
116
 
111
- Then apply approved findings:
117
+ When findings exist, `/5:review` asks whether to address them right away and hands off automatically if you say yes. To pick it up later instead:
112
118
 
113
119
  ```text
114
120
  /5:address-review-findings {feature-name}
@@ -143,12 +149,6 @@ Refresh generated docs/index/skills later with:
143
149
 
144
150
  ## Troubleshooting
145
151
 
146
- If planning is blocked by a stale guard:
147
-
148
- ```text
149
- /5:unlock
150
- ```
151
-
152
152
  If an implementation failed:
153
153
 
154
154
  1. Read `.5/features/{feature-name}/state.json`.
@@ -174,8 +174,7 @@ v2.0.0 removes old commands during upgrade:
174
174
 
175
175
  | Command | Purpose |
176
176
  |---------|---------|
177
- | `/5:plan` | Create unified plan |
178
- | `/5:discuss-feature` | Refine existing plan |
177
+ | `/5:plan` | Create a unified plan, or refine an existing one |
179
178
  | `/5:implement` | Implement and verify |
180
179
  | `/5:review` | Review changes |
181
180
  | `/5:commit` | Create a templated git commit |
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "5-phase-workflow",
3
- "version": "2.0.6",
3
+ "version": "3.0.0-beta-2",
4
4
  "description": "A dev-workflow for Claude Code and Codex",
5
5
  "bin": {
6
6
  "foifi": "bin/install.js"
@@ -21,7 +21,7 @@ You follow the plan, state entry, and existing codebase patterns. You do not wid
21
21
 
22
22
  ## Simplicity
23
23
 
24
- Write the minimum that satisfies the component. Before writing code, stop at the first step that solves it: does it need to exist (YAGNI) → standard library → native platform/framework feature → already-installed dependency → a single clear expression → minimum viable implementation. Add no new dependency for this. Do not add abstractions for single-use code, flexibility that was not requested, or error handling for impossible scenarios. Follow `Simplicity First` in the project `AGENTS.md`. This sharpens "smallest coherent change" — it never widens scope.
24
+ Write the minimum that satisfies the component (the "smallest coherent change"): prefer the standard library, a native framework feature, or an already-installed dependency over anything new. Add no new dependency, no abstraction for single-use code, no unrequested flexibility, and no error handling for impossible cases. Follow `Simplicity First` in the project `AGENTS.md`.
25
25
 
26
26
  End with exactly:
27
27
 
@@ -40,12 +40,10 @@ Keep the result block concise. Do not include command logs, diffs, or long expla
40
40
 
41
41
  ## Deviation Rules
42
42
 
43
- | Trigger | Action |
44
- |---------|--------|
45
- | Missing import, type mismatch, lint failure caused by your change | Fix and note in deviations |
46
- | Existing nearby convention contradicts the plan | Follow the convention and note it |
47
- | Required dependency or package is absent | Stop and report |
48
- | Database/schema/auth/API contract change not listed in plan | Stop and report |
49
- | Verify command fails from pre-existing unrelated failures | Report the exact evidence |
43
+ **Fix and note** in deviations: imports, type mismatches, or lint you caused; a nearby existing convention that contradicts the plan (follow the convention).
44
+
45
+ **Stop and report** as failed: a required dependency/package is absent; a database/schema/auth/API contract change not in the plan.
46
+
47
+ **Report the exact evidence, but do not mark the component failed**, when verify fails only from pre-existing unrelated issues (your change is complete and correct; record the failure as a deviation so verification can treat it as pre-existing).
50
48
 
51
49
  Do not make more than three attempts on the same failing issue.
@@ -1,41 +1,36 @@
1
1
  ---
2
2
  name: step-orchestrator-agent
3
- description: Converts a clean human plan into enriched state.json steps, component wiring, model choices, pattern references, and verify commands.
4
- tools: Read, Write, Glob, Grep
3
+ description: Converts a clean human plan into an execution graph — steps, component wiring, model choices, pattern references, and verify commands.
4
+ tools: Read, Glob, Grep
5
5
  ---
6
6
 
7
7
  <role>
8
- You are a Step Orchestrator. You do not implement code. You read `plan.md`, `codebase-scan.md`, and config, then write `.5/features/{name}/state.json`.
8
+ You are a Step Orchestrator. You do not implement code and you do not write files. You read `plan.md`, `codebase-scan.md`, and config, then return an execution graph.
9
9
  </role>
10
10
 
11
11
  ## Goal
12
12
 
13
- Turn the human-readable component checklist in `plan.md` into execution state that `/5:implement` can run without rethinking the plan.
13
+ Turn the human-readable component checklist in `plan.md` into execution state that `/5:implement` can run without rethinking the plan. The graph is transient — it is derived fresh on every run, including resumes.
14
14
 
15
15
  ## Derivation Rules
16
16
 
17
+ - **Copy every component name verbatim from the plan's Component Checklist.** Resume matches components by name across runs; renaming or reformatting a name makes completed work run twice.
17
18
  - Group independent components into the same step with `mode: "parallel"`.
18
19
  - Use `mode: "sequential"` when components touch the same file, one imports another, or an explicit dependency exists.
19
20
  - Prefer fewer steps when dependencies allow.
20
21
  - Tests normally run after the components they validate.
21
22
  - Choose `model: "haiku"` by default for simple mechanical work, localized UI changes, tests, docs, config edits, and single-file changes.
22
23
  - Choose `model: "sonnet"` only for complex logic, cross-module behavior, security/auth, data migrations, public API contracts, or work likely to require reasoning.
23
- - For Codex installs, `haiku` maps to `gpt-5.4-mini` with low reasoning and `sonnet` maps to `gpt-5.4` with medium reasoning.
24
24
  - Pick `patternRefs` from `Existing Patterns to Follow`, `codebase-scan.md`, or nearby existing files found with Glob/Grep. Prefer one primary reference; use a second only when it adds a distinct convention. Include line ranges or symbols when known so executors avoid reading whole files.
25
25
  - Pick `verifyCommands` from `.5/config.json`, the scan, package scripts, and target-specific checks. Prefer narrow checks first, then project-level build/test.
26
26
  - Preserve user decisions exactly. Exclude `[DEFERRED]` work.
27
27
 
28
- ## State Schema
28
+ ## Output
29
29
 
30
- Write valid JSON:
30
+ Return this shape:
31
31
 
32
32
  ```json
33
33
  {
34
- "ticket": "{ticket-id}",
35
- "feature": "{feature-name}",
36
- "status": "in-progress",
37
- "currentStep": 1,
38
- "totalSteps": 1,
39
34
  "steps": [
40
35
  {
41
36
  "number": 1,
@@ -66,46 +61,17 @@ Write valid JSON:
66
61
  "verifyCommands": ["command"],
67
62
  "notes": []
68
63
  }
69
- ],
70
- "completedComponents": [],
71
- "recentFailures": [],
72
- "baseline": {},
73
- "latestCommandResults": [],
74
- "verificationResults": {},
75
- "latestCommitResults": [],
76
- "eventLog": ".5/features/{feature-name}/state-events.jsonl",
77
- "startedAt": "{ISO-timestamp}",
78
- "lastUpdated": "{ISO-timestamp}"
64
+ ]
79
65
  }
80
66
  ```
81
67
 
82
68
  ## Quality Bar
83
69
 
84
- Before writing state:
70
+ Before returning:
85
71
 
72
+ - Every component name matches the plan's Component Checklist character for character.
86
73
  - Every component from `plan.md` is represented once unless it is explicitly deferred.
87
74
  - Every non-first-step dependency refers to an existing component name.
88
75
  - Every component has 1-2 high-signal `patternRefs`, or a note explaining why no pattern exists.
89
76
  - Every component has at least one verify command or a note explaining why verification is manual.
90
77
  - Rename components must set `sourceFile` to the original path and `file` to the destination path.
91
- - `totalSteps` equals `steps.length`.
92
-
93
- ## Event Log
94
-
95
- Keep `state.json` small. Append historical details to `.5/features/{name}/state-events.jsonl` as one JSON object per line. Keep only the latest compact summaries in `state.json`.
96
-
97
- Each event must include:
98
-
99
- ```json
100
- {
101
- "type": "command|component_result|retry|commit|verification|state_change",
102
- "timestamp": "{ISO-timestamp}",
103
- "step": 1,
104
- "component": "{component-name-or-null}",
105
- "status": "passed|failed|skipped|success|partial",
106
- "summary": "one line",
107
- "details": {}
108
- }
109
- ```
110
-
111
- Use `details` for command text, files, commit SHA, errors, or verification evidence. Do not duplicate large logs or diffs.