Development Timeline

Show what was delivered, what remains unfinished, and where work waited or repeated. Record stage changes during development and reuse evidence at delivery. When Matt's retro is used, give it these same records for environment-improvement recommendations and link the decisions back. Report generation adds no product gate or further development obligation. Write report content in English unless the user requests another language.

Start and Record Stages

Create a local report directory for the authorized task. Before the first record, read the data and evidence contract and create a short report JSON. Reuse the structure across projects, rather than copying project-specific issue numbers or conclusions.
Record dispatch, stage boundaries, actual reasons for waiting, role changes, key verification or review findings, repairs, and integration. Use record-event.mjs or existing structured runner records. Record meaningful changes rather than every tool call.
Issues, PRs, the tracker, and actual delivery results are authoritative. Distinguish local work, integrated results, and unverified areas. Passing tests alone do not establish issue completion.

node /path/to/development-timeline/scripts/record-event.mjs \
  --journal .scratch/task/events.jsonl start --id sdk-check \
  --lane "API ticket" --kind command --category validation --label "SDK check"
node /path/to/development-timeline/scripts/record-event.mjs \
  --journal .scratch/task/events.jsonl end --id sdk-check --outcome passed

Timestamps default to the actual recording time. Use --at for historical times only when supported by evidence; preserve unknown thinking, queueing, and command start times. Multiple actors can record separate journals and merge them during rendering.