Christian Nennemann
83e09b70f2
Sprint 1 — Workflow Intelligence (A1-A3):
- Conditional escalation: fast→standard on 2+ CRITICALs
- Guardian fast-path: skip remaining reviewers on clean pass
- Confidence-triggered escalation: pause/upgrade/probe on low scores
Sprint 2 — Quality Loop (B1-B2, B5-B6):
- Maker self-review checklist before submitting to Check phase
- Proposal diff ("What Changed") on cycle 2+ revisions
- Convergence detection: escalate to user if same finding persists 2 cycles
- Cross-archetype dedup: merge duplicate findings from different reviewers
Sprint 3 — Completion & Verification (B3-B4):
- Completion promise: user-defined done criteria checked in Act phase
- Post-merge verification: run tests on main, auto-revert on failure
Sprint 4 — Parallel & Scale (C1-C4):
- Parallel team orchestration: 2-3 independent teams with merge gate
- Task dependency graph in autonomous queue format
- Auto-resume on interruption via .archeflow/state.json
- Budget-aware scheduling with automatic workflow downgrade
120 lines
3.4 KiB
Markdown
120 lines
3.4 KiB
Markdown
---
|
|
name: plan-phase
|
|
description: 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
|
|
|
|
```markdown
|
|
## 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
|
|
|
|
```markdown
|
|
## 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:
|
|
|
|
```markdown
|
|
## Proposal: <task> (Revision — Cycle N)
|
|
|
|
### What Changed (vs. prior proposal)
|
|
- <brief delta: what was added, removed, or redesigned>
|
|
|
|
### 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.
|