claude-prism 1.2.3 → 1.2.5
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
|
@@ -46,18 +46,22 @@ AI coding agents fail in predictable ways:
|
|
|
46
46
|
Injected into `CLAUDE.md`, EUDEC is a behavioral framework that corrects how AI agents approach tasks:
|
|
47
47
|
|
|
48
48
|
```
|
|
49
|
-
|
|
50
|
-
│ ESSENCE ── Extract core problem → simplify → expand
|
|
51
|
-
│ │ Task type derivation from essence
|
|
52
|
-
│ UNDERSTAND ── Sufficiency assessment → ask → align
|
|
53
|
-
│ │ Environment validation
|
|
54
|
-
│
|
|
55
|
-
│ │
|
|
56
|
-
│
|
|
57
|
-
│ │
|
|
58
|
-
│
|
|
59
|
-
│
|
|
60
|
-
|
|
49
|
+
┌──────────────────── EUDEC Core Cycle ───────────────────┐
|
|
50
|
+
│ ESSENCE ── Extract core problem → simplify → expand │
|
|
51
|
+
│ │ Task type derivation from essence │
|
|
52
|
+
│ UNDERSTAND ── Sufficiency assessment → ask → align │
|
|
53
|
+
│ │ Environment validation │
|
|
54
|
+
│ │ Analysis-only branch (skip D/E/C if no code │
|
|
55
|
+
│ │ change needed) │
|
|
56
|
+
│ DECOMPOSE ── Batches → plan file → quality gate │
|
|
57
|
+
│ │ Codebase audit → cross-plan check │
|
|
58
|
+
│ EXECUTE ── Adaptive batches → Git-as-Memory (commit per │
|
|
59
|
+
│ │ batch) → risk-based verification │
|
|
60
|
+
│ │ Goal recitation → thrashing detection │
|
|
61
|
+
│ │ Verification scoping (changed files only) │
|
|
62
|
+
│ CHECKPOINT ── Report with evidence → plan-reality sync │
|
|
63
|
+
│ (loops back for next batch) │
|
|
64
|
+
└──────────────────────────────────────────────────────────┘
|
|
61
65
|
│
|
|
62
66
|
▼
|
|
63
67
|
HANDOFF ── Session transition doc + Project Memory
|
|
@@ -75,6 +79,12 @@ Injected into `CLAUDE.md`, EUDEC is a behavioral framework that corrects how AI
|
|
|
75
79
|
|
|
76
80
|
**Quality gates** between phases prevent executing on broken baselines.
|
|
77
81
|
|
|
82
|
+
**New in v1.2.5:**
|
|
83
|
+
- **Analysis-only branch**: When no code change is needed, UNDERSTAND reports findings without entering DECOMPOSE/EXECUTE/CHECKPOINT
|
|
84
|
+
- **Git-as-Memory**: Commits after each batch as rollback points; `git diff` summaries maintain context in long sessions
|
|
85
|
+
- **Verification scoping**: Build check output filtered to changed files only — pre-existing errors are ignored
|
|
86
|
+
- **Agent failure recovery**: 3-step protocol when delegated agents produce incomplete results
|
|
87
|
+
|
|
78
88
|
### 2. Three Focused Hooks
|
|
79
89
|
|
|
80
90
|
Hooks enforce the methodology at critical points. All three are deterministic (no heuristics, no state accumulation issues):
|
|
@@ -162,8 +172,10 @@ your-project/
|
|
|
162
172
|
│ └── settings.json # Hook registration
|
|
163
173
|
└── docs/plans/ # Plan files (created during work)
|
|
164
174
|
|
|
165
|
-
~/.claude/ # (
|
|
166
|
-
|
|
175
|
+
~/.claude/ # (global install / HUD)
|
|
176
|
+
├── commands/claude-prism/ # 9 slash commands (--global)
|
|
177
|
+
├── skills/prism/SKILL.md # /prism skill (--global)
|
|
178
|
+
└── hud/omc-hud.mjs # Statusline script (--hud)
|
|
167
179
|
```
|
|
168
180
|
|
|
169
181
|
## Configuration
|
package/package.json
CHANGED
|
@@ -5,7 +5,7 @@ When this command is invoked, follow the EUDEC framework strictly:
|
|
|
5
5
|
## E — ESSENCE
|
|
6
6
|
|
|
7
7
|
0. **Extract the essence**: Before exploring code, ask: "What is the core problem here — in one sentence, without naming specific tools?"
|
|
8
|
-
- Output: `Essence: [one sentence]`
|
|
8
|
+
- Output: `Essence: [one sentence — no technology/tool names]`
|
|
9
9
|
- Output: `Minimal case: [simplest working version]`
|
|
10
10
|
- Output: `Expansion path: minimal → [step1] → [step2] → [complete]`
|
|
11
11
|
1. **Verify essence quality**:
|
|
@@ -30,7 +30,8 @@ When this command is invoked, follow the EUDEC framework strictly:
|
|
|
30
30
|
- [Sufficient] Specific file, function, symptom mentioned → skip to DECOMPOSE
|
|
31
31
|
- [Partial] Direction clear but details missing → explore then ask 1-2 questions
|
|
32
32
|
- [Insufficient] Abstract, vague, multiple interpretations → must ask questions first
|
|
33
|
-
5. **
|
|
33
|
+
5. **Environment validation**: Verify project builds, dependencies match, env config identified. If any fail → resolve first.
|
|
34
|
+
6. **Check for hidden assumptions** (Red Flag Detection):
|
|
34
35
|
|
|
35
36
|
| Red Flag | Question to Ask Yourself |
|
|
36
37
|
|----------|-------------------------|
|
|
@@ -42,63 +43,74 @@ When this command is invoked, follow the EUDEC framework strictly:
|
|
|
42
43
|
| No file/function names | [Insufficient]. Must ask. |
|
|
43
44
|
| "just", "simply" | Complexity being underestimated |
|
|
44
45
|
|
|
45
|
-
|
|
46
|
+
7. **Question rules** (if questions needed):
|
|
46
47
|
- One question at a time
|
|
47
48
|
- Multiple choice with 2-3 options + recommendation
|
|
48
49
|
- Include reasoning based on code exploration
|
|
49
50
|
- Maximum 3 rounds of questions
|
|
50
|
-
|
|
51
|
-
|
|
51
|
+
8. **Confirm alignment**: Summarize goal in one sentence, get user approval
|
|
52
|
+
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.
|
|
52
53
|
|
|
53
54
|
## D — DECOMPOSE
|
|
54
55
|
|
|
55
|
-
|
|
56
|
-
|
|
57
|
-
|
|
58
|
-
|
|
59
|
-
|
|
60
|
-
|
|
56
|
+
10. **Assess complexity** (consider BOTH file count AND logic complexity):
|
|
57
|
+
- [Simple] 1-2 files, minor changes (<50 LOC) → execute directly, no decomposition needed
|
|
58
|
+
- [Medium] 3-5 files, OR 1-2 files with significant logic changes (50-150 LOC) → 2-3 batches
|
|
59
|
+
- [Complex] 6+ files, OR substantial architectural changes → 5+ batches, must create plan file
|
|
60
|
+
- [Complex system] Unclear scope → reduce scope first, then decompose
|
|
61
|
+
11. **Create batches** following the 5 principles:
|
|
61
62
|
- Unit size: 2-5 minutes each (test/implement/verify as separate steps)
|
|
62
63
|
- Test first: test before implementation in each unit
|
|
63
64
|
- Independent verification: each unit has a pass criterion
|
|
64
65
|
- Files specified: list files to create/modify per unit
|
|
65
66
|
- Dependencies noted: mark if unit depends on a previous one
|
|
66
|
-
|
|
67
|
+
12. **Assign size tags** to every task: [S] <30 LOC, [M] 30-100 LOC, [L] >100 LOC
|
|
67
68
|
- Batch composition: S+S+M = 1 batch, L = 1 batch alone
|
|
68
|
-
|
|
69
|
-
|
|
69
|
+
13. **Assign verification strategy** per task: `| Verify: TDD` or `| Verify: Build` or `| Verify: Visual`
|
|
70
|
+
14. **Pre-decomposition checklist**:
|
|
71
|
+
- **Codebase audit**: grep/search to verify targets actually exist in code
|
|
72
|
+
- **Cross-plan check**: if other plans exist in `docs/plans/`, identify overlapping files
|
|
70
73
|
- Required types/interfaces have the necessary fields?
|
|
71
74
|
- External package APIs behave as expected?
|
|
72
75
|
- Cross-package dependencies identified and noted as prerequisites?
|
|
73
|
-
|
|
74
|
-
|
|
76
|
+
15. **Quality gate**: Plan file exists and targets verified, project builds, dependencies resolved, environment validated. All must pass before execution.
|
|
77
|
+
16. **Save plan** to `docs/plans/YYYY-MM-DD-<topic>.md`
|
|
78
|
+
17. **Get approval**: "Proceed with this plan?"
|
|
75
79
|
|
|
76
|
-
##
|
|
80
|
+
## X — EXECUTE
|
|
77
81
|
|
|
78
|
-
|
|
82
|
+
18. Execute in adaptive batches:
|
|
79
83
|
- Simple changes (imports, types, config): 5-8 per batch
|
|
80
84
|
- Standard changes (feature add/modify): 3-4 per batch
|
|
81
85
|
- Complex changes (new module, architecture): 1-2 per batch
|
|
82
|
-
|
|
83
|
-
|
|
84
|
-
-
|
|
85
|
-
-
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
-
|
|
86
|
+
19. **Git-as-Memory**: commit after each completed batch as a rollback point. Use `git diff` summaries to maintain context in long sessions.
|
|
87
|
+
20. Apply risk-based verification:
|
|
88
|
+
- **High risk** (business logic, auth, data mutation): TDD — failing test → implement → pass. Include negative tests.
|
|
89
|
+
- **Medium risk** (new components with logic, API integration): Build + lint pass
|
|
90
|
+
- **Low risk** (imports, types, style, renaming): Build/lint passes
|
|
91
|
+
- **No test infra** (legacy PHP, WordPress, etc.): Grep-based static check + syntax validation
|
|
92
|
+
- Use **Verification Fallback Ladder**: Automated Tests → Approval Testing → Build → Lint → Smoke Check → Manual Diff Review (use highest available level)
|
|
93
|
+
21. **Scope Guard**: Before each change, ask: "Was this requested?" If no → don't do it
|
|
94
|
+
22. **Goal Recitation**: At every batch boundary, re-read the plan and confirm: "Current work aligns with: [original goal]"
|
|
95
|
+
23. **Self-correction triggers (Thrashing Detector)**:
|
|
96
|
+
- Same file edited 3+ times **on the same region/logic** → stop, investigate root cause
|
|
89
97
|
- File not in plan → pause, ask about scope change
|
|
90
98
|
- 3 consecutive test failures → stop, reconsider approach
|
|
91
99
|
- New package needed → ask user first
|
|
92
100
|
- Adding workarounds on workarounds → design problem, step back
|
|
93
|
-
|
|
94
|
-
|
|
101
|
+
- Successive edits reverting previous changes (oscillation) → wrong approach
|
|
102
|
+
- Scope expanding beyond plan → scope creep, return to DECOMPOSE
|
|
103
|
+
- Error messages changing type across fixes → chasing symptoms, back to UNDERSTAND
|
|
104
|
+
24. **Verification scoping**: Filter build output to only changed files. Pre-existing errors are not your concern.
|
|
105
|
+
25. **Agent failure recovery**: If a delegated agent partially fails:
|
|
95
106
|
1. Verify actual file state (read the file, not just the agent's report)
|
|
96
107
|
2. If partially correct → complete the remaining work directly
|
|
97
108
|
3. If fully wrong → retry with clearer instructions or execute directly
|
|
98
109
|
|
|
99
110
|
## C — CHECKPOINT
|
|
100
111
|
|
|
101
|
-
|
|
112
|
+
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.
|
|
113
|
+
27. After each batch, report using this format:
|
|
102
114
|
|
|
103
115
|
| Item | Before | After |
|
|
104
116
|
|------|--------|-------|
|
|
@@ -107,12 +119,14 @@ When this command is invoked, follow the EUDEC framework strictly:
|
|
|
107
119
|
```
|
|
108
120
|
Phase: [current] | Batch: [N/M] | Tasks: [done/total] ([%])
|
|
109
121
|
[████████░░] 80% — Next: [next batch name]
|
|
122
|
+
Plan freshness: verified [date] | Remaining targets: [N] confirmed in code
|
|
110
123
|
```
|
|
111
124
|
|
|
112
|
-
|
|
113
|
-
|
|
114
|
-
|
|
115
|
-
|
|
125
|
+
28. **Plan-Reality sync**: Grep for plan targets, mark vanished targets as "already completed", add newly discovered targets.
|
|
126
|
+
29. Include: verification results, files modified, tests status
|
|
127
|
+
30. **Checkpoint policy**: after 3 consecutive approvals, increase batch size to 5-8 for the rest of the phase
|
|
128
|
+
31. Ask: "Continue to next batch?"
|
|
129
|
+
32. User can redirect, adjust scope, or stop at any checkpoint
|
|
116
130
|
|
|
117
131
|
## OMC Integration
|
|
118
132
|
|
package/templates/rules.md
CHANGED
|
@@ -121,6 +121,10 @@ Before moving to DECOMPOSE:
|
|
|
121
121
|
- No file/function names mentioned → [Insufficient]. Must ask.
|
|
122
122
|
- Words like "just", "simply", "quickly" → complexity is being underestimated.
|
|
123
123
|
|
|
124
|
+
### 2-6. Analysis-Only Requests
|
|
125
|
+
|
|
126
|
+
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.
|
|
127
|
+
|
|
124
128
|
---
|
|
125
129
|
|
|
126
130
|
## EUDEC 3. DECOMPOSE — Planning Protocol
|
|
@@ -254,6 +258,8 @@ Choose verification proportional to the **risk of the change**, not the file pat
|
|
|
254
258
|
|
|
255
259
|
**Every change must have SOME verification.** If no tooling exists, `git diff` review is the minimum.
|
|
256
260
|
|
|
261
|
+
**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>"`
|
|
262
|
+
|
|
257
263
|
**Core Rules:**
|
|
258
264
|
1. Never claim completion without fresh **auto** verification evidence
|
|
259
265
|
2. Never commit code that doesn't build
|
|
@@ -314,6 +320,11 @@ When delegating work to sub-agents:
|
|
|
314
320
|
4. **Run build/test** to verify the agent's changes work
|
|
315
321
|
5. **Fix or retry** if incomplete
|
|
316
322
|
|
|
323
|
+
**Agent failure recovery**: If a delegated agent partially fails or produces incomplete results:
|
|
324
|
+
1. Verify actual file state (read the file, not just the agent's report)
|
|
325
|
+
2. If partially correct → complete the remaining work directly
|
|
326
|
+
3. If fully wrong → retry with clearer instructions or execute directly
|
|
327
|
+
|
|
317
328
|
**Never mark a delegated task as complete without reading the actual file state.**
|
|
318
329
|
|
|
319
330
|
### 4-7. Project-Type Verification Examples
|
|
@@ -35,9 +35,9 @@ AI agents optimize for speed, not correctness. Without structure, they skip unde
|
|
|
35
35
|
## E — ESSENCE
|
|
36
36
|
|
|
37
37
|
0. **Extract the essence**: Before exploring code, ask: "What is the core problem here — in one sentence, without naming specific tools?"
|
|
38
|
-
- Output:
|
|
39
|
-
- Output:
|
|
40
|
-
- Output:
|
|
38
|
+
- Output: `Essence: [one sentence — no technology/tool names]`
|
|
39
|
+
- Output: `Minimal case: [simplest working version]`
|
|
40
|
+
- Output: `Expansion path: minimal → [step1] → [step2] → [complete]`
|
|
41
41
|
1. **Verify essence quality**:
|
|
42
42
|
- Does the essence sentence avoid specific technology names? If not → still at solution level, go higher
|
|
43
43
|
- Is the minimal case truly minimal? Can it be reduced further?
|
|
@@ -56,12 +56,12 @@ AI agents optimize for speed, not correctness. Without structure, they skip unde
|
|
|
56
56
|
## U — UNDERSTAND
|
|
57
57
|
|
|
58
58
|
3. **Explore first**: Read package.json, project structure, related files before asking anything
|
|
59
|
-
|
|
59
|
+
4. **Assess information sufficiency**:
|
|
60
60
|
- [Sufficient] Specific file, function, symptom mentioned → skip to DECOMPOSE
|
|
61
61
|
- [Partial] Direction clear but details missing → explore then ask 1-2 questions
|
|
62
62
|
- [Insufficient] Abstract, vague, multiple interpretations → must ask questions first
|
|
63
|
-
|
|
64
|
-
|
|
63
|
+
5. **Environment validation**: Verify project builds, dependencies match, env config identified. If any fail → resolve first.
|
|
64
|
+
6. **Check for hidden assumptions** (Red Flag Detection):
|
|
65
65
|
|
|
66
66
|
| Red Flag | Question to Ask Yourself |
|
|
67
67
|
|----------|-------------------------|
|
|
@@ -73,56 +73,56 @@ AI agents optimize for speed, not correctness. Without structure, they skip unde
|
|
|
73
73
|
| No file/function names | [Insufficient]. Must ask. |
|
|
74
74
|
| "just", "simply" | Complexity being underestimated |
|
|
75
75
|
|
|
76
|
-
|
|
76
|
+
7. **Question rules** (if questions needed):
|
|
77
77
|
- One question at a time
|
|
78
78
|
- Multiple choice with 2-3 options + recommendation
|
|
79
79
|
- Include reasoning based on code exploration
|
|
80
80
|
- Maximum 3 rounds of questions
|
|
81
|
-
|
|
82
|
-
|
|
81
|
+
8. **Confirm alignment**: Summarize goal in one sentence, get user approval
|
|
82
|
+
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.
|
|
83
83
|
|
|
84
84
|
## D — DECOMPOSE
|
|
85
85
|
|
|
86
|
-
|
|
87
|
-
|
|
88
|
-
|
|
89
|
-
|
|
90
|
-
|
|
91
|
-
|
|
92
|
-
|
|
93
|
-
|
|
94
|
-
|
|
95
|
-
|
|
96
|
-
|
|
97
|
-
|
|
86
|
+
10. **Assess complexity** (consider BOTH file count AND logic complexity):
|
|
87
|
+
- [Simple] 1-2 files, minor changes (<50 LOC) → execute directly, no decomposition needed
|
|
88
|
+
- [Medium] 3-5 files, OR 1-2 files with significant logic changes (50-150 LOC) → 2-3 batches
|
|
89
|
+
- [Complex] 6+ files, OR substantial architectural changes → 5+ batches, must create plan file
|
|
90
|
+
- [Complex system] Unclear scope → reduce scope first, then decompose
|
|
91
|
+
11. **Create batches** following the 5 principles:
|
|
92
|
+
- Unit size: 2-5 minutes each (test/implement/verify as separate steps)
|
|
93
|
+
- Test first: test before implementation in each unit
|
|
94
|
+
- Independent verification: each unit has a pass criterion
|
|
95
|
+
- Files specified: list files to create/modify per unit
|
|
96
|
+
- Dependencies noted: mark if unit depends on a previous one
|
|
97
|
+
12. **Assign size tags** to every task: [S] <30 LOC, [M] 30-100 LOC, [L] >100 LOC
|
|
98
98
|
- Batch composition: S+S+M = 1 batch, L = 1 batch alone
|
|
99
|
-
|
|
100
|
-
|
|
99
|
+
13. **Assign verification strategy** per task: `| Verify: TDD` or `| Verify: Build` or `| Verify: Visual`
|
|
100
|
+
14. **Pre-decomposition checklist**:
|
|
101
101
|
- **Codebase audit**: grep/search to verify targets actually exist in code
|
|
102
102
|
- **Cross-plan check**: if other plans exist in `docs/plans/`, identify overlapping files
|
|
103
103
|
- Required types/interfaces have the necessary fields?
|
|
104
104
|
- External package APIs behave as expected?
|
|
105
105
|
- Cross-package dependencies identified and noted as prerequisites?
|
|
106
|
-
|
|
107
|
-
|
|
108
|
-
|
|
106
|
+
15. **Quality gate**: Plan file exists and targets verified, project builds, dependencies resolved, environment validated. All must pass before execution.
|
|
107
|
+
16. **Save plan** to `docs/plans/YYYY-MM-DD-<topic>.md`
|
|
108
|
+
17. **Get approval**: "Proceed with this plan?"
|
|
109
109
|
|
|
110
|
-
##
|
|
110
|
+
## X — EXECUTE
|
|
111
111
|
|
|
112
|
-
|
|
112
|
+
18. Execute in adaptive batches:
|
|
113
113
|
- Simple changes (imports, types, config): 5-8 per batch
|
|
114
114
|
- Standard changes (feature add/modify): 3-4 per batch
|
|
115
115
|
- Complex changes (new module, architecture): 1-2 per batch
|
|
116
|
-
|
|
117
|
-
|
|
116
|
+
19. **Git-as-Memory**: commit after each completed batch as a rollback point. Use `git diff` summaries to maintain context in long sessions.
|
|
117
|
+
20. Apply risk-based verification:
|
|
118
118
|
- **High risk** (business logic, auth, data mutation): TDD — failing test → implement → pass. Include negative tests.
|
|
119
119
|
- **Medium risk** (new components with logic, API integration): Build + lint pass
|
|
120
120
|
- **Low risk** (imports, types, style, renaming): Build/lint passes
|
|
121
121
|
- **No test infra** (legacy PHP, WordPress, etc.): Grep-based static check + syntax validation
|
|
122
122
|
- Use **Verification Fallback Ladder**: Automated Tests → Approval Testing → Build → Lint → Smoke Check → Manual Diff Review (use highest available level)
|
|
123
|
-
|
|
124
|
-
|
|
125
|
-
|
|
123
|
+
21. **Scope Guard**: Before each change, ask: "Was this requested?" If no → don't do it
|
|
124
|
+
22. **Goal Recitation**: At every batch boundary, re-read the plan and confirm: "Current work aligns with: [original goal]"
|
|
125
|
+
23. **Self-correction triggers (Thrashing Detector)**:
|
|
126
126
|
- Same file edited 3+ times **on the same region/logic** → stop, investigate root cause
|
|
127
127
|
- File not in plan → pause, ask about scope change
|
|
128
128
|
- 3 consecutive test failures → stop, reconsider approach
|
|
@@ -131,16 +131,16 @@ AI agents optimize for speed, not correctness. Without structure, they skip unde
|
|
|
131
131
|
- Successive edits reverting previous changes (oscillation) → wrong approach
|
|
132
132
|
- Scope expanding beyond plan → scope creep, return to DECOMPOSE
|
|
133
133
|
- Error messages changing type across fixes → chasing symptoms, back to UNDERSTAND
|
|
134
|
-
|
|
135
|
-
|
|
134
|
+
24. **Verification scoping**: Filter build output to only changed files. Pre-existing errors are not your concern.
|
|
135
|
+
25. **Agent failure recovery**: If a delegated agent partially fails:
|
|
136
136
|
1. Verify actual file state (read the file, not just the agent's report)
|
|
137
137
|
2. If partially correct → complete the remaining work directly
|
|
138
138
|
3. If fully wrong → retry with clearer instructions or execute directly
|
|
139
139
|
|
|
140
140
|
## C — CHECKPOINT
|
|
141
141
|
|
|
142
|
-
|
|
143
|
-
|
|
142
|
+
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.
|
|
143
|
+
27. After each batch, report using this format:
|
|
144
144
|
|
|
145
145
|
| Item | Before | After |
|
|
146
146
|
|------|--------|-------|
|
|
@@ -152,11 +152,11 @@ AI agents optimize for speed, not correctness. Without structure, they skip unde
|
|
|
152
152
|
Plan freshness: verified [date] | Remaining targets: [N] confirmed in code
|
|
153
153
|
```
|
|
154
154
|
|
|
155
|
-
|
|
156
|
-
|
|
157
|
-
|
|
158
|
-
|
|
159
|
-
|
|
155
|
+
28. **Plan-Reality sync**: Grep for plan targets, mark vanished targets as "already completed", add newly discovered targets.
|
|
156
|
+
29. Include: verification results, files modified, tests status
|
|
157
|
+
30. **Checkpoint policy**: after 3 consecutive approvals, increase batch size to 5-8 for the rest of the phase
|
|
158
|
+
31. Ask: "Continue to next batch?"
|
|
159
|
+
32. User can redirect, adjust scope, or stop at any checkpoint
|
|
160
160
|
|
|
161
161
|
## OMC Integration
|
|
162
162
|
|