dev-loop

System Prompt Addition

Implement tasks in a structured 3-phase loop:

1. Research+Plan (merged into ONE subprocess call): Analyze the codebase, read relevant files, AND produce a concrete implementation plan in the same response. Search the web only when local code and docs are insufficient. Output: .dev-loop/research-and-plan.md.

2. Execute: Implement the solution based on the research+plan output. On subsequent iterations, also fix all P1 and P2 findings from previous reviews. No P3 is ever requested here. The tool passes only blocking findings into the next execution prompt, so there is no "take a P3 along while the file is open" decision to make. Every P3 is collected across all iterations and appended once to the final output as an offer; the user decides. Caveat: with CLAUDE_SESSION_ENABLED=true all phases share one conversation, so a P3 from an earlier review is still in history and the executor can see it — the guarantee covers the prompt, not the whole context. What holds in both modes is that no P3 gates progress. Why: touching working code for cosmetics widens the diff without functional gain, and since each review re-reads the diff fresh, every P3 fix can surface new P3 — the loop would feed itself and burn iterations on style. Rundenreflexion (from iteration 2 on): before fixing, the executor writes a ## Rundenreflexion section asking whether it is over-building or chasing an edge case, then may defer any P2 finding as - [BEKANNTE GRENZE] <finding> — <reason> instead of fixing it. A P1 can never be deferred this way — enforced in tools/review_loop.py, not only in the prompt. A deferred finding no longer blocks the following round and is listed in the final output as "Bekannte Grenzen", separate from the P3 offer.

3. Dual-Review (both must pass before finishing, both read-only):

   • Quality Review (P1/P2/P3): correctness, security, performance, maintainability, testability, robustness, documentation, compliance. P1 = critical/crash/security | P2 = significant | P3 = minor (non-blocking)
   • Resolution Review (RESOLVED/PARTIAL/UNRESOLVED): does the code solve the original task 100%? Quality is irrelevant here — only task completion matters. Both review phases re-read git diff fresh; they do not trust pinned context.

Loop repeats until both reviews pass. No auto-commit or push. Output written to .dev-loop/.

When CLAUDE_SESSION_ENABLED=true (opt-in), all phases share a Claude --session-id/--resume session for prompt-cache reuse, with iteration-cap=5 rollover.