08 / Field notes

Leave a trail you can use.

A build note is a handoff to your future self. Keep the information that helps you reproduce a result or understand a decision after the conversation has disappeared.

Record the useful evidence

For a bug, save the smallest input that reproduces it, the command you ran, and the observed output. Include the runtime or package version when it affects behavior. Remove credentials and private data before putting examples in the repository. A precise five-line reproduction often outlasts pages of pasted chat.

Explain the decision once

Write down why you chose a dependency, an output format, or a storage location. Include the constraint that ruled out an obvious alternative. Keep this close to the code or in a short project note. Avoid restating what the implementation already makes clear; preserve the reasoning that would otherwise be lost.

Make the next experiment small

End with one unanswered question and a way to test it. For example, check whether your renamer handles filenames with spaces before adding another naming pattern. If you switch models, record the exact task and reviewed result rather than a vague impression. Useful notes describe evidence and limits, not a leaderboard based on memory.

A brief to adapt
Summarize the verified outcome of this change in four parts: reproduction, decision, check performed, and open question. Include only evidence from this session. Omit secrets and unrelated conversation.