Challenge non-trivial code decisions with fresh-context review

Doubt-Driven Development challenges non-trivial decisions while changing direction is still inexpensive. It separates an in-flight examination of reasoning from a final review verdict. A fresh-context reviewer receives a small artifact and its contract, then looks for unstated assumptions, edge cases, hidden coupling, violated constraints, and unexpected-input failures.

The process has five steps: CLAIM names the decision and its importance; EXTRACT isolates the smallest reviewable artifact and contract; DOUBT requests adversarial examination; RECONCILE checks every finding against the actual text; STOP enforces a bounded cycle. Keep the proposed conclusion and prior reasoning out of the reviewer's input to reduce agreement bias.

The reviewer receives these two inputs, without the proposed conclusion:

ARTIFACT: <paste artifact>
CONTRACT: <paste contract>

Use for branching logic, boundary-crossing changes, properties a compiler cannot verify, correctness dependent on hidden context, or irreversible consequences. Architectural uncertainty, unfamiliar code, and claims about safety or specification compliance are suitable triggers.

Skip mechanical edits, obvious one-line changes, clear instructions, reading or summarization, and pure tooling operations. An explicit preference for speed over verification is also an exclusion. Repeated review of an unchanged artifact is a warning sign rather than useful progress.

Stop when findings are trivial or already considered, after three cycles, or on an explicit user override. Substantive unresolved findings after the bound require escalation. An artifact too large for that limit should be decomposed.

Input is the relevant diff, focused function, short proposal, or assertion with its supporting evidence, plus the contract it must satisfy. Reviewer output remains evidence to assess, not an automatic verdict.

Classify findings in precedence order: an unclear contract first, then valid actionable defects, then accepted trade-offs, then noise caused by missing context. Fix the contract or artifact as appropriate, record accepted trade-offs, and explain rejected findings. Multiple cycles producing substantive findings but no actionable classifications can indicate review theater.

Run orchestration from the main session with verified reviewer isolation and permissions. A role name alone does not prove fresh context. Nested personas should defer to the main session. A last-resort self-questioning fallback must be disclosed as degraded because it retains the original context.

Interactive cycles must offer a cross-model second opinion after the initial review. External CLI use requires checking availability, testing the binary, confirming exact syntax and flags, and obtaining authorization for each invocation. Supply only the adversarial prompt, artifact, and contract through a literal prompt file and stdin; shell interpolation is unsafe. A read-only filesystem does not itself prevent network disclosure or credential access. Report tool failures and acknowledged skips. Non-interactive contexts skip cross-model review and announce that skip.

The referenced references/orchestration-patterns.md is an external prerequisite from the upstream installation, not a bundled file in this catalog copy. Inspect it before claiming its procedure was followed. TDD's failing RED test can supply the disproof attempt for behavioral claims; source-driven verification and final code review remain complementary.