Task decision contract

The model interprets user/project context; code resolves explicit IDs, never semantic relevance or counts. Record outcome, facts/unknowns, scope, risk, profiles/packs, selected skills/reasons, references, real tools/permissions, ownership, verification and stop/rollback. Revisit on new evidence; omit private reasoning.

Development modes — canonical policy

For repository implementation state DEVELOPMENT_MODE: BUILDER | REVIEW at entry and material transitions. Mode and risk are separate. This core owns cadence; selected procedures add detail without overriding mode or scope.

BUILDER — complete requested functionality

Finish all requested behavior: implement → cheapest relevant check → fix demonstrated failure → continue. Use sufficient expertise; fewer reads is not success. Avoid repeated full-suite runs, blanket audits, unrelated refactors, speculative architecture, docs churn, trivial tests or committees. Reuse existing/platform primitives before abstractions/dependencies. Focused evidence is not whole-product readiness.

REVIEW — validate the completed change

Enter for completed functionality or explicit audit. Freeze feature scope. Inspect the full diff; run required broad gates and relevant integration/E2E/security/data/dependency/performance/accessibility/docs checks. Batch concrete fixes with focused rechecks, then rerun broad gates after material fixes. No speculative features/infinite reviews. Check the complete requested scope; report blockers.

Development economy invariant

Verify affected auth/payment/destructive writes/secrets/production data/concurrency early even in BUILDER without forcing whole-repository REVIEW. Choose one JIT procedure per overlapping concern; reliable-coding is the lean general coding companion.