Project-Template/docs/history/DEVELOPMENT_LOG.md

2.1 KiB

Development log —

Status: Current
Owner: <who maintains this>
Last reviewed: <YYYY-MM-DD>
Governs: the dated record of what happened
Review trigger: Nothing. This file is appended to, never revised.

How to use this

Newest first. One entry per work session, written before you stop — that is step 6 of docs/WORK_CYCLE.md, and the two lines it insists on are Next action and Blockers.

Those two are not decoration. The next session starts by reading the top of this file, and a session that ended without saying what came next hands the one after it a re-derivation instead of a starting point — which is where drift enters. Neither line competes with anything: the live next action is the field on the project at privacyllc.dev and the live blockers are issues in the tracker, while these say what both were at this date. A record of then never disagrees with a record of now.

Append-only by convention. Correcting an old entry rewrites the record of what was known at the time, which is the one thing this file is for. If an entry turns out to be wrong, add a later entry saying so; do not edit the first.

Note the Review trigger above says "nothing", deliberately. A dated log cannot rot the way a description of current state can — the entries were true when written and stay true. It is exempt from review for the same reason a receipt is.

Entries

<What was done, what it proved, and what is still unresolved. Link the commit or the issue rather than restating it — the value here is the reasoning that does not fit in a commit message.>

  • Closed: <#N, #N — or "none", which is also an answer>
  • Next action: <the concrete thing the next session starts on. The same sentence written to the project's nextAction field; specific enough to begin without asking a question.>
  • Blockers: <what is stuck and the issue it is filed as, or "none". "None" written deliberately is worth more than a missing line, which reads as "nobody said" rather than "nothing was".>

<…>