Walking skeleton plan

Principles

• Step 1 is a walking skeleton. It runs the main path of the spec end to end: for example "a customer places an order, the system stores it and the order list shows it". Each layer that the main path crosses has the minimum (for example data, logic, interface, tests). It stays in the codebase as the base.
• One capability per step. A step adds one thing: cancel an order, validation, edit, delete, a config option.
• Always integrated. At the end of every step the project builds, the main path works and the full test suite passes.
• No orphan code. Every function, table, dependency and template added in a step has a caller in that same step.
• Testable. Every step says what can be tested when it is done: automated tests and one manual check.
• One feature. A step is not a feature. The whole plan runs on the branch of the feature (git-commit-organizer), with commits per step.

Ordering

1. Walking skeleton first.
2. Next, anything that changes the shape of every later step. Example: the error format of the API before the first endpoints that return errors, so every later endpoint uses it from the start and tests are adapted once.
3. Then features, one per step.
4. Then hardening that does not change the public interface (for example limits, security settings, configuration).
5. Styles and final documentation review last.