Development Modes — current implementation track

Baseline

Current released baseline: v0.11.1 on main.

The original Development Modes work exists in:

• PR DKF Development Modes — Increment 001: policy architecture foundation #42 — Increment 001 policy architecture foundation, head ef3b118004a846ab9989dc41b995f5c8494d4064
• PR DKF Development Modes — Increment 002: initialization and persistent configuration #43 — Increment 002 initialization/persistence, head b66a9b8d833848ba86c0240d68971ee12ad97875

Those branches were created before the v0.11.0 Secrets & Configuration Readiness Gate and v0.11.1 Live UI Preview/Token Efficiency release and are no longer valid merge bases.

Required work

• Reconcile Increment 001 against current v0.11.1 architecture and mandatory controls.
• Independently verify MOD-001–MOD-011 against the reconciled implementation.
• Reconcile Increment 002 on top of the accepted Increment 001.
• Independently verify INIT-001–INIT-011, migration behavior, history, CLI behavior, and no silent overrides.
• Implement Increment 003: lifecycle, artifact selection, planning/contracts and Autopilot consume selected mode while mandatory safety/acceptance controls remain non-configurable.
• Implement Increment 004: mode-aware documentation/artifact behavior.
• Implement Increment 005: migration, cross-mode compatibility and real host acceptance.
• Run Ubuntu/Windows npm run release:validate on the final integrated branch.
• Complete Product Owner host acceptance before release/version claims.

Product constraints retained

• Modes are developer-facing methodologies, not a way to weaken mandatory DKF reliability controls.
• The intended choices remain Rapid, Balanced (default), Spec-Driven, Doc-Driven, and Maintenance & Evolution.
• Maintenance is an existing-project context layered over a methodology and requires repository audit.
• Selected mode must be persisted, inspectable, changeable with explicit history, and consumed deterministically.
• Do not publish partial Development Modes behavior as shipped capability.

Supersession policy

PRs #42 and #43 are historical implementation evidence. New work should start from current main; do not attempt to merge those stale branches directly.