feat: add plan granularity constraint to plan-phase and creator
This commit is contained in:
@@ -46,8 +46,16 @@ For the full output format (including Mini-Reflect, Alternatives Considered, and
|
||||
| <option B> | <reason> |
|
||||
|
||||
### Changes
|
||||
1. **`path/file.ext`** — What changes and why
|
||||
1. **`path/file.ext:line`** — What changes and why
|
||||
```language
|
||||
<target code state>
|
||||
```
|
||||
**Verify:** `<command to confirm correctness>`
|
||||
2. **`path/test.ext`** — What tests to add
|
||||
```language
|
||||
<test code>
|
||||
```
|
||||
**Verify:** `<test command>`
|
||||
|
||||
### Test Strategy
|
||||
- <specific test cases>
|
||||
@@ -72,6 +80,7 @@ For the full output format (including Mini-Reflect, Alternatives Considered, and
|
||||
- Name every file. The Maker needs exact paths.
|
||||
- Scope ruthlessly. Adjacent problems go under "Not Doing."
|
||||
- Include test strategy. No proposal is complete without it.
|
||||
- **Granularity:** Each change item must be a 2-5 minute task with exact file path, code block showing the target state, and a verify command. If an item would take >5 minutes, split it. If a non-trivial task has <2 items, you under-specified.
|
||||
- Any Confidence axis < 0.5? Flag it — the orchestrator may pause or escalate.
|
||||
|
||||
## Status Token
|
||||
|
||||
@@ -118,6 +118,46 @@ When the Creator receives structured feedback from a prior cycle, the proposal m
|
||||
|
||||
CRITICAL findings cannot be deferred or disputed — they must be fixed or the proposal will be rejected again.
|
||||
|
||||
## Task Granularity
|
||||
|
||||
Each change item in the Creator's proposal must be a **2-5 minute task** — specific enough that the Maker can implement it without interpretation.
|
||||
|
||||
### Requirements per Change Item
|
||||
|
||||
Every item in the `### Changes` section must include:
|
||||
|
||||
1. **Exact file path** — `src/auth/handler.ts`, not "the auth module"
|
||||
2. **What to change** — a code block showing the target state or transformation
|
||||
3. **How to verify** — a command or check that confirms correctness
|
||||
|
||||
### Good Example
|
||||
|
||||
```markdown
|
||||
1. **`src/auth/handler.ts:48`** — Add input length validation before token processing
|
||||
```typescript
|
||||
if (!token || token.trim().length === 0) {
|
||||
throw new ValidationError('Token must not be empty');
|
||||
}
|
||||
```
|
||||
**Verify:** `npm test -- --grep "empty token"` passes
|
||||
```
|
||||
|
||||
### Bad Example
|
||||
|
||||
```markdown
|
||||
1. **Auth module** — Fix the validation logic
|
||||
```
|
||||
|
||||
This is too vague. Which file? Which function? What does "fix" mean? The Maker will guess.
|
||||
|
||||
### Granularity Check
|
||||
|
||||
- If a single change item would take **>5 minutes**, split it into smaller items
|
||||
- If a non-trivial task has **<2 change items**, it is under-specified — the Creator missed something
|
||||
- Each item should touch **1-2 files** at most. Cross-cutting changes need separate items per file.
|
||||
|
||||
---
|
||||
|
||||
## Explorer Skip Conditions
|
||||
|
||||
Not every task needs Explorer research. Use this decision table:
|
||||
|
||||
Reference in New Issue
Block a user