Session handoff

Session Handoff

Overview

Preserve the minimum durable state needed to resume work accurately. A handoff reports reality and constraints; it does not approve work, relax a gate, or turn an intended check into evidence.

When to use

• At the end of unfinished, multi-step, or decision-heavy work.
• Before context compaction, clearing, a long pause, or transfer to another actor.
• After readiness, profile, gate, or premise decisions that must persist.

When NOT to use: a completed trivial task; a conversation with no durable state; or as a substitute for actually running a skipped check.

Process

1. Locate the handoff target. Prefer the project's established handoff file; otherwise propose HANDOFF.md. Preserve prior entries and put the newest first.
2. Record status against evidence with assets/session-handoff.md: done with artifact/test/diff pointers, exact stopping point for in-progress work, and explicitly not-started items.
3. Record decisions and authority. Include rationale, decision owner, and revisit condition. Carry forward readiness outcome, per-step final modes, required gates, friction restrictions, and technical boundaries where relevant.
4. Record reality about checks. Say which checks ran, their result, and which were skipped. Never write "passes" based on intention or an earlier version.
5. Record risks and open premises. Include unsupported reliability or resilience assumptions, unresolved criteria, scope uncertainty, and any condition that would require a new readiness screen or task profile.
6. Write ordered next steps. Make each step cold-start-ready and state the first required human decision. A handoff never carries implicit approval.
7. Keep it compact. Link to artifacts instead of reproducing logs; aim for one page unless the project requires a different format.
8. Checkpoint. Show the entry for human correction before any requested commit or external publication.

Rationalizations

Excuse	Rebuttal
"The chat has the context."	Chat context is volatile and not a durable source of project state.
"Approved earlier" is enough.	Name what was approved, by whom, and what gates remain.
"Tests should pass."	Intention is not evidence; mark them not run.
"A full transcript is safer."	A cold reader needs selected state and pointers, not buried signal.

Red flags

• A done claim without an evidence pointer.
• Final modes or required gates lost between sessions.
• A next step that assumes unrecorded approval.
• Open reliability, resilience, or criterion gaps omitted.
• The handoff restates the plan instead of reporting actual state.

Verification

The handoff is complete when a cold reader can resume without chat history; every done claim has evidence; decisions include owner and rationale; readiness, mode, gate, and boundary constraints survive; skipped checks and open premises are explicit; and the next action does not rely on implicit authority.