Leave a checkpoint.
Make the next session start from facts, even if a different person or model picks it up.
A long conversation is a poor substitute for a current working state. At a useful stopping point, record what changed and what still needs attention. Keep existing work intact, including changes that predate the assistant's session.
See what is actually there.
In a Git project, inspect the working tree and both staged and unstaged changes. Untracked files need attention too. Do not clean up unfamiliar changes to make the status look tidy; identify their ownership before acting.
git status --short
git diff --stat
git diff --cached --statKeep the useful facts.
Note the requirement, relevant files, completed checks, and the exact part that remains uncertain. Include any setup detail needed to reproduce the result. Avoid a transcript of unsuccessful attempts unless one explains an unresolved constraint.
State: blank-name validation implemented.
Evidence: focused validation check passes.
Open: save-error behavior has not been checked.
Next: run the existing save-error case.
Boundary: unrelated profile styling remains untouched.Verify before continuing.
A note describes an earlier state. At the next session, inspect current changes and confirm the relevant assumptions still hold. Preserve work through your normal version-control process; a checkpoint note alone is not a backup or a commit.
Before moving on