# Handoff Blocks

Per-session state captures. Each file represents the state of an equipment
chat session at the point Sam paused it, so the next chat for the same
equipment can resume with full context instead of re-deriving it.

## Filename convention

`<equipment-id>-<YYYY-MM-DD>.md`

Examples:
- `lt180-2026-04-25.md`
- `seadoo-gtx-di-2001-2026-04-26.md`

Multiple handoffs per equipment per day are fine — append `-2`, `-3` etc.

## Required sections

Each handoff block should contain:

```markdown
# Handoff — <equipment description>

**Session date:** YYYY-MM-DD
**Author:** <chat session identifier or "session N">
**Guide version at session end:** v<N>

## Verified configuration

What about the equipment is now confirmed (with sources). e.g. PIN decoded,
EPA label read, model year confirmed, parts catalog code identified.

## Symptoms

What the user reported, with any clarifications captured during the session.

## Diagnoses considered

Each candidate diagnosis with status:
- **Confirmed:** evidence and source
- **Ruled out:** why
- **Open:** what's needed to confirm

## Actions taken this session

What was decided, what was bought, what was done physically (with dates).

## Outstanding decisions

What needs Sam's call, what's waiting on parts, what the next session should
pick up.

## Confidence assessment

The chat's honest read on diagnostic confidence — high / medium / low, and why.
Flag anything the next session should re-verify.
```

## Why these exist

Equipment chat sessions accumulate context over the course of a diagnosis —
label decodes, hypothesis ranking, errata trail, forum threads referenced.
A new session starting cold loses all of that. The handoff block is the
written record that bridges sessions, alongside the versioned guide
itself (which captures the *finalized* output but not the in-flight thinking).

The next session for the same equipment fetches both the latest guide and
the most recent handoff block at session start.