dk-local-mock-first-approach

Layer-boundary discipline identifies exactly when to swap surface mocks for real code. This approach reduces risk and rework by enforcing documented mock artifacts and acceptance gates, ensuring teams only commit to implementation after the user experience is validated.

Run the mock-first workflow from Phase 0 to generate and review surface mocks before committing to implementation. The process progresses through exploration, surface mocks, and layered deepening, keeping all decisions documented in tracker.md across sessions.

Yes, mock-first development applies to UI-heavy and multi-layer changes. It produces concrete mock data, acceptance notes, and test plans that can be reused for deeper development, helping teams progressively implement real logic while preserving the UX rationale.

Complex features stall when teams wire APIs and UI before validating the user experience. A mock-first approach surfaces the UX early using documented artifacts and acceptance gates, preventing premature implementation and preserving work across sessions.

Mock-first development is not ideal for simple backend-only changes lacking a user interface. It is designed for UI-heavy or multi-layer changes where teams need realistic surface mocks and documented acceptance gates before committing to full implementation.