Picking up without rebuilding
Anyone who has left a project for two weeks and come back to it knows the feeling: what was I on?, what was left half done?, why did I do this like that? Now multiply it by several people, several parallel projects and, increasingly, AI assistants that work in sessions and do not remember the previous one.
Continuity cannot depend on memory. It has to be written down, and in a format you can read in a minute.
Two documents, two jobs
The status is a short, structured sheet that is overwritten every time something changes:
- What phase the application is in and which gates it has passed.
- What milestones remain and which are done.
- What is blocking progress and who has to resolve it.
- What the next step is.
The logbook is a chronological record that only grows: every working session adds an entry with what was done, what was decided and what is left. An earlier entry is never corrected; if something was wrong, a new entry says so.
Why two and not one
Because they answer different questions. The status answers 'where are we?' in seconds. The logbook answers 'how did we get here?' when you need to understand a decision or trace an error. Mixing them produces a document too long to read quickly and too heavily edited to trust its history.
Practical rules
- They are updated in the same session, not 'later'.
- They live in the application's repository, next to the code.
- Raw output goes separately: long command output or dumps do not clutter the logbook; they are kept in their own file and cited.
- They are machine-readable: the status has a fixed structure, so the platform can show on a dashboard where each application stands.
With the project's memory solved, it is time to build. And building well starts with a very concrete idea: what gets deployed has to be exactly what was tested.
How we apply it: Platform Engineering.