Christian Nennemann
5139f1ad89
- Mini-Reflect for fast workflow: Creator must restate task, list assumptions, name highest-damage risk before proposing (catches misunderstandings early) - Alternatives Considered section: Creator must evaluate 2+ approaches with rejection rationale before committing to one (prevents tunnel vision) - Structured confidence scoring: 3-axis table (task understanding, solution completeness, risk coverage) replaces bare 0.0-1.0 number. Low scores trigger targeted action (clarify, upgrade workflow, or research) - Mini-Reflect fallback for skipped tasks: quick reflection even when ArcheFlow doesn't activate (non-trivial single-file changes)
3.3 KiB
3.3 KiB
name, description
| name | description |
|---|---|
| plan-phase | Use when acting as Explorer or Creator in the Plan phase. Defines output formats for research and proposals. |
Plan Phase
Explorer researches, then Creator designs. Sequential — Creator needs Explorer's findings.
Explorer Output Format
## Research: <task>
### Affected Code
- `path/file.ext` — description (L<start>-<end>)
### Dependencies
- What depends on what, what breaks if changed
### Patterns
- How the codebase solves similar problems
### Risks
- What could go wrong
### Recommendation
<one paragraph: approach + rationale>
Creator Output Format
## Proposal: <task>
### Mini-Reflect (fast workflow only — skip if Explorer ran)
- **Task restated:** <one sentence>
- **Assumptions:** 1) ... 2) ... 3) ...
- **Highest-damage risk:** <the one thing that would hurt most if wrong>
### Architecture Decision
<What and WHY>
### Alternatives Considered
| Approach | Why Rejected |
|----------|-------------|
| <option A> | <reason> |
| <option B> | <reason> |
### Changes
1. **`path/file.ext`** — What changes and why
2. **`path/test.ext`** — What tests to add
### Test Strategy
- <specific test cases>
### Confidence
| Axis | Score | Note |
|------|-------|------|
| Task understanding | <0.0-1.0> | <why> |
| Solution completeness | <0.0-1.0> | <gaps?> |
| Risk coverage | <0.0-1.0> | <unknowns?> |
### Risks
- <what could go wrong + mitigations>
### Not Doing
- <adjacent concerns deliberately excluded>
Confidence triggers: If any axis scores below 0.5, flag it to the orchestrator. Low task understanding → clarify with user. Low solution completeness → consider standard workflow. Low risk coverage → spawn targeted Explorer research.
Creator with Prior Feedback (Cycle 2+)
When the Creator receives structured feedback from a prior cycle, the proposal must include an additional section addressing each unresolved issue:
## Proposal: <task> (Revision — Cycle N)
### Prior Feedback Response
| Issue | Source | Action | Rationale |
|-------|--------|--------|-----------|
| SQL injection in user input | Guardian | **Fixed** — added parameterized queries | Direct security fix |
| Assumes single-tenant | Skeptic | **Deferred** — multi-tenant out of scope | Not in task requirements |
| Test names unclear | Sage | **Accepted** — routed to Maker | Implementation concern |
### Architecture Decision
<revised design addressing feedback>
### Changes
<updated file list>
### Test Strategy
<updated test cases>
### Confidence
| Axis | Score | Note |
|------|-------|------|
| Task understanding | <0.0-1.0> | <why> |
| Solution completeness | <0.0-1.0> | <gaps?> |
| Risk coverage | <0.0-1.0> | <unknowns?> |
### Risks
<updated risks — include any new risks from the revision>
### Not Doing
<updated scope boundaries>
Rules for addressing feedback:
- Fixed: Changed the design to resolve the issue. Explain how.
- Deferred: Not addressing now, with explicit reason. Must not be a CRITICAL finding.
- Accepted: Acknowledged and routed to Maker for implementation-level fix.
- Disputed: Disagrees with the finding. Must provide evidence or reasoning.
CRITICAL findings cannot be deferred or disputed — they must be fixed or the proposal will be rejected again.