claude-prism 1.2.4 → 1.2.6

package/CHANGELOG.md

@@ -0,0 +1,159 @@
+# Changelog
+
+All notable changes to this project will be documented in this file.
+
+The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
+and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
+
+## [1.2.6] — 2026-02-28
+
+### Fixed
+- CHANGELOG.md added to npm package `files` (was missing from published tarball)
+
+## [1.2.5] — 2026-02-28
+
+### Fixed
+- **Global skill missing Essence phase** — `~/.claude/commands/claude-prism/prism.md` was still UDEC (no Essence). `/claude-prism:prism` and `/prism` now correctly start from ESSENCE.
+- **E/E header collision** — `## E — EXECUTE` → `## X — EXECUTE` in slash command/skill files to disambiguate from `## E — ESSENCE`
+- **SKILL.md step numbering** — was `3,2,3,4...`, now continuous `0-32`
+
+### Added
+- **Analysis-only branch** in UNDERSTAND — skip D/E/C when no code change is needed
+- **Verification scoping** in EXECUTE — filter build output to changed files only
+- **Agent failure recovery** in EXECUTE — 3-step protocol (verify → complete → retry)
+- Backported Git-as-Memory, Goal Recitation, Thrashing Detector, quality gates, Plan-Reality sync to `templates/commands/prism.md` (was only in SKILL.md)
+
+### Changed
+- All 4 EUDEC entry points fully synchronized (rules.md, commands/prism.md, SKILL.md, CLAUDE.md)
+- README: updated EUDEC Core Cycle diagram, added v1.2.5 feature highlights, documented global install file tree
+
+## [1.2.4] — 2026-02-25
+
+### Fixed
+- `prism update` in source repo now updates commands/hooks/lib (was early-returning after rules only)
+- All Korean labels → English across all templates (prism.md, SKILL.md, hud.md, omc-hud.mjs)
+
+## [1.2.2] — 2026-02-25
+
+### Fixed
+- HUD statusline Korean labels → English (주간→Wkly, day names)
+
+## [1.2.1] — 2026-02-25
+
+### Fixed
+- Stats template version now matches package.json (was stuck at v0.1.0)
+
+### Changed
+- HUD statusline now fetches usage data directly from Anthropic OAuth API (30s cache TTL)
+- No longer depends on OMC for usage cache refresh
+- Stale cache fallback when API is unreachable
+
+## [1.0.0] — 2026-02-24
+
+### Added
+- `prism analytics [--detail]` CLI command and slash command for usage statistics
+- Session event logging in hook pipeline (blocks/warns automatically recorded)
+- session.mjs included in installed lib files
+- CHANGELOG.md (this file)
+- GitHub Actions CI workflow (test on push/PR)
+- Config schema versioning (`.claude-prism.json` version field)
+- Verification Fallback Ladder (7-level, from automated tests to manual diff)
+- Quality Gates between DECOMPOSE→EXECUTE and EXECUTE→CHECKPOINT
+- Goal Recitation mechanism at batch boundaries
+- Thrashing Detector (oscillation, scope creep, symptom chasing)
+- Git-as-Memory protocol (commit per batch as rollback point)
+- Environment Validation in UNDERSTAND phase
+- Agent Delegation Verification with resource ownership
+- Project-type verification examples (PHP, Static Sites, Scripts, Infra)
+- Negative testing requirement for high-risk changes
+- Project Memory (persistent docs/PROJECT-MEMORY.md)
+
+### Changed
+- SKILL.md fully synchronized with rules.md v3 features (10 items)
+- doctor.md updated to reflect current file structure (was referencing deleted files)
+- plan.md template now includes Related Plans, Codebase Audit, Files in Scope
+- checkpoint.md now includes Plan-Reality sync and freshness verification
+- prism.md + SKILL.md EXECUTE step numbers fixed (no longer collide with DECOMPOSE)
+- Batch size guidance unified to 5-8 for simple/mechanical changes
+- OMC Scope Guard thresholds explained (4 warn / 7 block standalone vs 8/12 with OMC)
+- Section numbering: Assumption Detection now 2-5 (was duplicate 2-4)
+- Command count increased from 7 to 8 (added analytics.md)
+
+### Fixed
+- Self-update detection: source repo now uses local templates instead of npx cache (v0.8.1)
+
+## [0.8.0] — 2026-02-22
+
+### Added
+- UDEC v3 methodology upgrade based on field feedback and research
+- Plan freshness validation and auto/manual verify separation
+- Codebase Audit section in plan template
+- Related Plans section for cross-plan dependency tracking
+- No-test-infra verification row (legacy PHP, WordPress support)
+- [S]-only batch size rule (up to 8 per batch)
+- Advisory decomposition thresholds (coupling-aware)
+- Rationalization Defense entries (4 new)
+- Auto-counting in checkpoint command
+
+### Changed
+- Verification strategy now risk-based (not path-based)
+- Auto vs Manual verification explicitly separated
+
+## [0.7.2] — 2026-02-22
+
+### Added
+- Plan freshness validation at checkpoints
+- Cross-plan overlap detection
+
+## [0.7.0] — 2026-02-20
+
+### Added
+- plan-enforcement hook (warns when editing 6+ files without a plan)
+- Reverted from premature 1.0.0 release
+
+### Changed
+- Restored 3-hook model (commit-guard, test-tracker, plan-enforcement)
+
+## [0.6.0] — 2026-02-19
+
+### Added
+- UDEC v2 methodology
+- Scope guard, debug loop, alignment detection hooks
+
+### Removed
+- Hooks with high false-positive rate (scope-guard, debug-loop, alignment)
+
+## [0.5.0] — 2026-02-18
+
+### Changed
+- English-only base (removed i18n support for simplicity)
+- Unified pipeline runners (pre-tool.mjs, post-tool.mjs)
+
+## [0.4.0] — 2026-02-17
+
+### Added
+- Pipeline engine for running multiple rules per hook
+- Session logging infrastructure
+- Alignment detection hook
+- i18n support (later removed in 0.5.0)
+
+## [0.3.0] — 2026-02-16
+
+### Added
+- Context-aware verification (TDD for logic, build for UI)
+- Adaptive batch sizes
+
+## [0.2.2] — 2026-02-15
+
+### Added
+- Global install (`prism init --global`)
+- OMC skill support
+
+## [0.1.0] — 2026-02-14
+
+### Added
+- Initial release
+- UDEC methodology framework (Understand, Decompose, Execute, Checkpoint)
+- Commit guard hook
+- Test tracker hook
+- 6 slash commands (prism, checkpoint, plan, doctor, stats, help)

package/README.md

@@ -46,18 +46,22 @@ AI coding agents fail in predictable ways:
 Injected into `CLAUDE.md`, EUDEC is a behavioral framework that corrects how AI agents approach tasks:
 
 ```
-┌─────────────────── EUDEC Core Cycle ──────────────────┐
-│ ESSENCE ── Extract core problem → simplify → expand    │
-│   │        Task type derivation from essence           │
-│ UNDERSTAND ── Sufficiency assessment → ask → align     │
-│   │          Environment validation                    │
-│ DECOMPOSE ── Batches → plan file → quality gate        │
-│   │          Codebase audit → cross-plan check         │
-│ EXECUTE ── Adaptive batches → risk-based verification  │
-│   │        Goal recitation → thrashing detection       │
-│ CHECKPOINT ── Report with evidence → plan-reality sync │
-│              (loops back for next batch)                │
-└────────────────────────────────────────────────────────┘
+┌──────────────────── EUDEC Core Cycle ───────────────────┐
+│ ESSENCE ── Extract core problem → simplify → expand      │
+│   │        Task type derivation from essence             │
+│ UNDERSTAND ── Sufficiency assessment → ask → align       │
+│   │          Environment validation                      │
+│   │          Analysis-only branch (skip D/E/C if no code │
+│   │          change needed)                              │
+│ DECOMPOSE ── Batches → plan file → quality gate          │
+│   │          Codebase audit → cross-plan check           │
+│ EXECUTE ── Adaptive batches → Git-as-Memory (commit per  │
+│   │        batch) → risk-based verification              │
+│   │        Goal recitation → thrashing detection         │
+│   │        Verification scoping (changed files only)     │
+│ CHECKPOINT ── Report with evidence → plan-reality sync   │
+│              (loops back for next batch)                  │
+└──────────────────────────────────────────────────────────┘
     │
     ▼
   HANDOFF ── Session transition doc + Project Memory
@@ -75,6 +79,12 @@ Injected into `CLAUDE.md`, EUDEC is a behavioral framework that corrects how AI
 
 **Quality gates** between phases prevent executing on broken baselines.
 
+**New in v1.2.5:**
+- **Analysis-only branch**: When no code change is needed, UNDERSTAND reports findings without entering DECOMPOSE/EXECUTE/CHECKPOINT
+- **Git-as-Memory**: Commits after each batch as rollback points; `git diff` summaries maintain context in long sessions
+- **Verification scoping**: Build check output filtered to changed files only — pre-existing errors are ignored
+- **Agent failure recovery**: 3-step protocol when delegated agents produce incomplete results
+
 ### 2. Three Focused Hooks
 
 Hooks enforce the methodology at critical points. All three are deterministic (no heuristics, no state accumulation issues):
@@ -162,8 +172,10 @@ your-project/
 │   └── settings.json            # Hook registration
 └── docs/plans/                  # Plan files (created during work)
 
-~/.claude/                       # (HUD — global, opt-in)
-└── hud/omc-hud.mjs              # Statusline script
+~/.claude/                       # (global install / HUD)
+├── commands/claude-prism/       # 9 slash commands (--global)
+├── skills/prism/SKILL.md        # /prism skill (--global)
+└── hud/omc-hud.mjs              # Statusline script (--hud)
 ```
 
 ## Configuration

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-prism",
-  "version": "1.2.4",
+  "version": "1.2.6",
   "description": "EUDEC methodology framework for AI coding agents — Essence, Understand, Decompose, Execute, Checkpoint.",
   "type": "module",
   "bin": {
@@ -31,7 +31,8 @@
     "lib/",
     "hooks/",
     "templates/",
-    "README.md"
+    "README.md",
+    "CHANGELOG.md"
   ],
   "repository": {
     "type": "git",

package/templates/commands/claude-prism/prism.md

@@ -5,7 +5,7 @@ When this command is invoked, follow the EUDEC framework strictly:
 ## E — ESSENCE
 
 0. **Extract the essence**: Before exploring code, ask: "What is the core problem here — in one sentence, without naming specific tools?"
-   - Output: `Essence: [one sentence]`
+   - Output: `Essence: [one sentence — no technology/tool names]`
    - Output: `Minimal case: [simplest working version]`
    - Output: `Expansion path: minimal → [step1] → [step2] → [complete]`
 1. **Verify essence quality**:
@@ -30,7 +30,8 @@ When this command is invoked, follow the EUDEC framework strictly:
    - [Sufficient] Specific file, function, symptom mentioned → skip to DECOMPOSE
    - [Partial] Direction clear but details missing → explore then ask 1-2 questions
    - [Insufficient] Abstract, vague, multiple interpretations → must ask questions first
-5. **Check for hidden assumptions** (Red Flag Detection):
+5. **Environment validation**: Verify project builds, dependencies match, env config identified. If any fail → resolve first.
+6. **Check for hidden assumptions** (Red Flag Detection):
 
    | Red Flag | Question to Ask Yourself |
    |----------|-------------------------|
@@ -42,63 +43,74 @@ When this command is invoked, follow the EUDEC framework strictly:
    | No file/function names | [Insufficient]. Must ask. |
    | "just", "simply" | Complexity being underestimated |
 
-6. **Question rules** (if questions needed):
+7. **Question rules** (if questions needed):
    - One question at a time
    - Multiple choice with 2-3 options + recommendation
    - Include reasoning based on code exploration
    - Maximum 3 rounds of questions
-7. **Confirm alignment**: Summarize goal in one sentence, get user approval
-8. **Analysis-only requests**: If no code change is needed (architecture review, cause analysis, investigation), report findings and ask: "Further action needed?" Do NOT proceed to D/E/C unless the user requests implementation.
+8. **Confirm alignment**: Summarize goal in one sentence, get user approval
+9. **Analysis-only requests**: If no code change is needed, report findings and ask: "Further action needed?" Do NOT proceed to D/E/C unless the user requests implementation.
 
 ## D — DECOMPOSE
 
-9. **Assess complexity** (consider BOTH file count AND logic complexity):
-   - [Simple] 1-2 files, minor changes (<50 LOC) → execute directly, no decomposition needed
-   - [Medium] 3-5 files, OR 1-2 files with significant logic changes (50-150 LOC) → 2-3 batches
-   - [Complex] 6+ files, OR substantial architectural changes → 5+ batches, must create plan file
-   - [Complex system] Unclear scope → reduce scope first, then decompose
-10. **Create batches** following the 5 principles:
+10. **Assess complexity** (consider BOTH file count AND logic complexity):
+    - [Simple] 1-2 files, minor changes (<50 LOC) → execute directly, no decomposition needed
+    - [Medium] 3-5 files, OR 1-2 files with significant logic changes (50-150 LOC) → 2-3 batches
+    - [Complex] 6+ files, OR substantial architectural changes → 5+ batches, must create plan file
+    - [Complex system] Unclear scope → reduce scope first, then decompose
+11. **Create batches** following the 5 principles:
     - Unit size: 2-5 minutes each (test/implement/verify as separate steps)
     - Test first: test before implementation in each unit
     - Independent verification: each unit has a pass criterion
     - Files specified: list files to create/modify per unit
     - Dependencies noted: mark if unit depends on a previous one
-11. **Assign size tags** to every task: [S] <30 LOC, [M] 30-100 LOC, [L] >100 LOC
+12. **Assign size tags** to every task: [S] <30 LOC, [M] 30-100 LOC, [L] >100 LOC
     - Batch composition: S+S+M = 1 batch, L = 1 batch alone
-12. **Assign verification strategy** per task: `| Verify: TDD` or `| Verify: Build` or `| Verify: Visual`
-13. **Pre-decomposition checklist**:
+13. **Assign verification strategy** per task: `| Verify: TDD` or `| Verify: Build` or `| Verify: Visual`
+14. **Pre-decomposition checklist**:
+    - **Codebase audit**: grep/search to verify targets actually exist in code
+    - **Cross-plan check**: if other plans exist in `docs/plans/`, identify overlapping files
     - Required types/interfaces have the necessary fields?
     - External package APIs behave as expected?
     - Cross-package dependencies identified and noted as prerequisites?
-14. **Save plan** to `docs/plans/YYYY-MM-DD-<topic>.md`
-15. **Get approval**: "Proceed with this plan?"
+15. **Quality gate**: Plan file exists and targets verified, project builds, dependencies resolved, environment validated. All must pass before execution.
+16. **Save plan** to `docs/plans/YYYY-MM-DD-<topic>.md`
+17. **Get approval**: "Proceed with this plan?"
 
-## E — EXECUTE
+## X — EXECUTE
 
-16. Execute in adaptive batches:
+18. Execute in adaptive batches:
     - Simple changes (imports, types, config): 5-8 per batch
     - Standard changes (feature add/modify): 3-4 per batch
     - Complex changes (new module, architecture): 1-2 per batch
-17. Apply context-aware verification:
-    - `lib/`, `utils/`, `store/`, `hooks/`, `services/` → TDD (failing test → implement → verify)
-    - `components/`, `pages/`, `views/` → Build verification (escalate to TDD if complex logic)
-    - `config/`, `styles/`, `types/` → Build/lint only
-18. **Scope Guard**: Before each change, ask: "Was this requested?" If no → don't do it
-19. **Self-correction triggers**:
-    - Same file edited 3+ times **on the same region/logic** → stop, investigate root cause (progressive edits across different regions — imports, logic, JSX — are normal)
+19. **Git-as-Memory**: commit after each completed batch as a rollback point. Use `git diff` summaries to maintain context in long sessions.
+20. Apply risk-based verification:
+    - **High risk** (business logic, auth, data mutation): TDD — failing test → implement → pass. Include negative tests.
+    - **Medium risk** (new components with logic, API integration): Build + lint pass
+    - **Low risk** (imports, types, style, renaming): Build/lint passes
+    - **No test infra** (legacy PHP, WordPress, etc.): Grep-based static check + syntax validation
+    - Use **Verification Fallback Ladder**: Automated Tests → Approval Testing → Build → Lint → Smoke Check → Manual Diff Review (use highest available level)
+21. **Scope Guard**: Before each change, ask: "Was this requested?" If no → don't do it
+22. **Goal Recitation**: At every batch boundary, re-read the plan and confirm: "Current work aligns with: [original goal]"
+23. **Self-correction triggers (Thrashing Detector)**:
+    - Same file edited 3+ times **on the same region/logic** → stop, investigate root cause
     - File not in plan → pause, ask about scope change
     - 3 consecutive test failures → stop, reconsider approach
     - New package needed → ask user first
     - Adding workarounds on workarounds → design problem, step back
-20. **Verification scoping**: When running build checks (tsc, lint, etc.), filter output to only changed files. Pre-existing errors in other files are not your concern. Example: `tsc --noEmit 2>&1 | grep -i "<changed-file>"`
-21. **Agent failure recovery**: If a delegated agent partially fails or produces incomplete results:
+    - Successive edits reverting previous changes (oscillation) → wrong approach
+    - Scope expanding beyond plan → scope creep, return to DECOMPOSE
+    - Error messages changing type across fixes → chasing symptoms, back to UNDERSTAND
+24. **Verification scoping**: Filter build output to only changed files. Pre-existing errors are not your concern.
+25. **Agent failure recovery**: If a delegated agent partially fails:
     1. Verify actual file state (read the file, not just the agent's report)
     2. If partially correct → complete the remaining work directly
     3. If fully wrong → retry with clearer instructions or execute directly
 
 ## C — CHECKPOINT
 
-22. After each batch, report using this format:
+26. **Quality gate**: All batch tasks terminal, build passes with zero new errors, no uncommitted changes, plan file updated with `[x]` status. If any fail → continue in EXECUTE.
+27. After each batch, report using this format:
 
     | Item | Before | After |
     |------|--------|-------|
@@ -107,12 +119,14 @@ When this command is invoked, follow the EUDEC framework strictly:
     ```
     Phase: [current] | Batch: [N/M] | Tasks: [done/total] ([%])
     [████████░░] 80% — Next: [next batch name]
+    Plan freshness: verified [date] | Remaining targets: [N] confirmed in code
     ```
 
-23. Include: verification results, files modified, tests status
-24. **Checkpoint policy**: after 3 consecutive approvals, increase batch size to 5-8 for the rest of the phase
-25. Ask: "Continue to next batch?"
-26. User can redirect, adjust scope, or stop at any checkpoint
+28. **Plan-Reality sync**: Grep for plan targets, mark vanished targets as "already completed", add newly discovered targets.
+29. Include: verification results, files modified, tests status
+30. **Checkpoint policy**: after 3 consecutive approvals, increase batch size to 5-8 for the rest of the phase
+31. Ask: "Continue to next batch?"
+32. User can redirect, adjust scope, or stop at any checkpoint
 
 ## OMC Integration
 

package/templates/rules.md

@@ -121,6 +121,10 @@ Before moving to DECOMPOSE:
 - No file/function names mentioned → [Insufficient]. Must ask.
 - Words like "just", "simply", "quickly" → complexity is being underestimated.
 
+### 2-6. Analysis-Only Requests
+
+If no code change is needed (architecture review, cause analysis, investigation), report findings and ask: "Further action needed?" Do NOT proceed to DECOMPOSE/EXECUTE/CHECKPOINT unless the user requests implementation.
+
 ---
 
 ## EUDEC 3. DECOMPOSE — Planning Protocol
@@ -254,6 +258,8 @@ Choose verification proportional to the **risk of the change**, not the file pat
 
 **Every change must have SOME verification.** If no tooling exists, `git diff` review is the minimum.
 
+**Verification scoping**: When running build checks (tsc, lint, etc.), filter output to only changed files. Pre-existing errors in other files are not your concern. Example: `tsc --noEmit 2>&1 | grep -i "<changed-file>"`
+
 **Core Rules:**
 1. Never claim completion without fresh **auto** verification evidence
 2. Never commit code that doesn't build
@@ -314,6 +320,11 @@ When delegating work to sub-agents:
 4. **Run build/test** to verify the agent's changes work
 5. **Fix or retry** if incomplete
 
+**Agent failure recovery**: If a delegated agent partially fails or produces incomplete results:
+1. Verify actual file state (read the file, not just the agent's report)
+2. If partially correct → complete the remaining work directly
+3. If fully wrong → retry with clearer instructions or execute directly
+
 **Never mark a delegated task as complete without reading the actual file state.**
 
 ### 4-7. Project-Type Verification Examples

package/templates/skills/prism/SKILL.md

@@ -56,12 +56,12 @@ AI agents optimize for speed, not correctness. Without structure, they skip unde
 ## U — UNDERSTAND
 
 3. **Explore first**: Read package.json, project structure, related files before asking anything
-2. **Assess information sufficiency**:
+4. **Assess information sufficiency**:
    - [Sufficient] Specific file, function, symptom mentioned → skip to DECOMPOSE
    - [Partial] Direction clear but details missing → explore then ask 1-2 questions
    - [Insufficient] Abstract, vague, multiple interpretations → must ask questions first
-3. **Environment validation**: Verify project builds, dependencies match, env config identified. If any fail → resolve first.
-4. **Check for hidden assumptions** (Red Flag Detection):
+5. **Environment validation**: Verify project builds, dependencies match, env config identified. If any fail → resolve first.
+6. **Check for hidden assumptions** (Red Flag Detection):
 
    | Red Flag | Question to Ask Yourself |
    |----------|-------------------------|
@@ -73,56 +73,56 @@ AI agents optimize for speed, not correctness. Without structure, they skip unde
    | No file/function names | [Insufficient]. Must ask. |
    | "just", "simply" | Complexity being underestimated |
 
-5. **Question rules** (if questions needed):
+7. **Question rules** (if questions needed):
    - One question at a time
    - Multiple choice with 2-3 options + recommendation
    - Include reasoning based on code exploration
    - Maximum 3 rounds of questions
-6. **Confirm alignment**: Summarize goal in one sentence, get user approval
-7. **Analysis-only requests**: If no code change is needed, report findings and ask: "Further action needed?" Do NOT proceed to D/E/C unless the user requests implementation.
+8. **Confirm alignment**: Summarize goal in one sentence, get user approval
+9. **Analysis-only requests**: If no code change is needed, report findings and ask: "Further action needed?" Do NOT proceed to D/E/C unless the user requests implementation.
 
 ## D — DECOMPOSE
 
-8. **Assess complexity** (consider BOTH file count AND logic complexity):
-   - [Simple] 1-2 files, minor changes (<50 LOC) → execute directly, no decomposition needed
-   - [Medium] 3-5 files, OR 1-2 files with significant logic changes (50-150 LOC) → 2-3 batches
-   - [Complex] 6+ files, OR substantial architectural changes → 5+ batches, must create plan file
-   - [Complex system] Unclear scope → reduce scope first, then decompose
-9. **Create batches** following the 5 principles:
-   - Unit size: 2-5 minutes each (test/implement/verify as separate steps)
-   - Test first: test before implementation in each unit
-   - Independent verification: each unit has a pass criterion
-   - Files specified: list files to create/modify per unit
-   - Dependencies noted: mark if unit depends on a previous one
-10. **Assign size tags** to every task: [S] <30 LOC, [M] 30-100 LOC, [L] >100 LOC
+10. **Assess complexity** (consider BOTH file count AND logic complexity):
+    - [Simple] 1-2 files, minor changes (<50 LOC) → execute directly, no decomposition needed
+    - [Medium] 3-5 files, OR 1-2 files with significant logic changes (50-150 LOC) → 2-3 batches
+    - [Complex] 6+ files, OR substantial architectural changes → 5+ batches, must create plan file
+    - [Complex system] Unclear scope → reduce scope first, then decompose
+11. **Create batches** following the 5 principles:
+    - Unit size: 2-5 minutes each (test/implement/verify as separate steps)
+    - Test first: test before implementation in each unit
+    - Independent verification: each unit has a pass criterion
+    - Files specified: list files to create/modify per unit
+    - Dependencies noted: mark if unit depends on a previous one
+12. **Assign size tags** to every task: [S] <30 LOC, [M] 30-100 LOC, [L] >100 LOC
     - Batch composition: S+S+M = 1 batch, L = 1 batch alone
-11. **Assign verification strategy** per task: `| Verify: TDD` or `| Verify: Build` or `| Verify: Visual`
-12. **Pre-decomposition checklist**:
+13. **Assign verification strategy** per task: `| Verify: TDD` or `| Verify: Build` or `| Verify: Visual`
+14. **Pre-decomposition checklist**:
     - **Codebase audit**: grep/search to verify targets actually exist in code
     - **Cross-plan check**: if other plans exist in `docs/plans/`, identify overlapping files
     - Required types/interfaces have the necessary fields?
     - External package APIs behave as expected?
     - Cross-package dependencies identified and noted as prerequisites?
-13. **Quality gate**: Plan file exists and targets verified, project builds, dependencies resolved, environment validated. All must pass before execution.
-14. **Save plan** to `docs/plans/YYYY-MM-DD-<topic>.md`
-15. **Get approval**: "Proceed with this plan?"
+15. **Quality gate**: Plan file exists and targets verified, project builds, dependencies resolved, environment validated. All must pass before execution.
+16. **Save plan** to `docs/plans/YYYY-MM-DD-<topic>.md`
+17. **Get approval**: "Proceed with this plan?"
 
-## E — EXECUTE
+## X — EXECUTE
 
-16. Execute in adaptive batches:
+18. Execute in adaptive batches:
     - Simple changes (imports, types, config): 5-8 per batch
     - Standard changes (feature add/modify): 3-4 per batch
     - Complex changes (new module, architecture): 1-2 per batch
-17. **Git-as-Memory**: commit after each completed batch as a rollback point. Use `git diff` summaries to maintain context in long sessions.
-18. Apply risk-based verification:
+19. **Git-as-Memory**: commit after each completed batch as a rollback point. Use `git diff` summaries to maintain context in long sessions.
+20. Apply risk-based verification:
     - **High risk** (business logic, auth, data mutation): TDD — failing test → implement → pass. Include negative tests.
     - **Medium risk** (new components with logic, API integration): Build + lint pass
     - **Low risk** (imports, types, style, renaming): Build/lint passes
     - **No test infra** (legacy PHP, WordPress, etc.): Grep-based static check + syntax validation
     - Use **Verification Fallback Ladder**: Automated Tests → Approval Testing → Build → Lint → Smoke Check → Manual Diff Review (use highest available level)
-19. **Scope Guard**: Before each change, ask: "Was this requested?" If no → don't do it
-20. **Goal Recitation**: At every batch boundary, re-read the plan and confirm: "Current work aligns with: [original goal]"
-21. **Self-correction triggers (Thrashing Detector)**:
+21. **Scope Guard**: Before each change, ask: "Was this requested?" If no → don't do it
+22. **Goal Recitation**: At every batch boundary, re-read the plan and confirm: "Current work aligns with: [original goal]"
+23. **Self-correction triggers (Thrashing Detector)**:
     - Same file edited 3+ times **on the same region/logic** → stop, investigate root cause
     - File not in plan → pause, ask about scope change
     - 3 consecutive test failures → stop, reconsider approach
@@ -131,16 +131,16 @@ AI agents optimize for speed, not correctness. Without structure, they skip unde
     - Successive edits reverting previous changes (oscillation) → wrong approach
     - Scope expanding beyond plan → scope creep, return to DECOMPOSE
     - Error messages changing type across fixes → chasing symptoms, back to UNDERSTAND
-22. **Verification scoping**: Filter build output to only changed files. Pre-existing errors are not your concern.
-23. **Agent failure recovery**: If a delegated agent partially fails:
+24. **Verification scoping**: Filter build output to only changed files. Pre-existing errors are not your concern.
+25. **Agent failure recovery**: If a delegated agent partially fails:
     1. Verify actual file state (read the file, not just the agent's report)
     2. If partially correct → complete the remaining work directly
     3. If fully wrong → retry with clearer instructions or execute directly
 
 ## C — CHECKPOINT
 
-24. **Quality gate**: All batch tasks terminal, build passes with zero new errors, no uncommitted changes, plan file updated with `[x]` status. If any fail → continue in EXECUTE.
-25. After each batch, report using this format:
+26. **Quality gate**: All batch tasks terminal, build passes with zero new errors, no uncommitted changes, plan file updated with `[x]` status. If any fail → continue in EXECUTE.
+27. After each batch, report using this format:
 
     | Item | Before | After |
     |------|--------|-------|
@@ -152,11 +152,11 @@ AI agents optimize for speed, not correctness. Without structure, they skip unde
     Plan freshness: verified [date] | Remaining targets: [N] confirmed in code
     ```
 
-26. **Plan-Reality sync**: Grep for plan targets, mark vanished targets as "already completed", add newly discovered targets.
-27. Include: verification results, files modified, tests status
-28. **Checkpoint policy**: after 3 consecutive approvals, increase batch size to 5-8 for the rest of the phase
-29. Ask: "Continue to next batch?"
-30. User can redirect, adjust scope, or stop at any checkpoint
+28. **Plan-Reality sync**: Grep for plan targets, mark vanished targets as "already completed", add newly discovered targets.
+29. Include: verification results, files modified, tests status
+30. **Checkpoint policy**: after 3 consecutive approvals, increase batch size to 5-8 for the rest of the phase
+31. Ask: "Continue to next batch?"
+32. User can redirect, adjust scope, or stop at any checkpoint
 
 ## OMC Integration