Receive and leave the handoff document

A rein lineage has exactly one handoff document. The successor session's kickoff points to this one document, and no other. What's written here is only how to decide where it lives and the discipline for reading and writing it -- what actually goes in it (what to write, for which project) is up to whoever writes it.

Receiving side (asked to pick up work, or launched from kickoff)

1. Decide where it lives (check these in order; the first one that resolves wins)

When 2 and 3 disagree, go with 2 (the effective value). rein --cwd <target project> status's handoff: line already shows the effective value, its origin, and whether it exists, all in one place -- checking it once is enough to confirm where you decided it lives.

If it can't be resolved, doesn't exist, or is empty, don't start filling the gap with guesses. Don't go looking for it elsewhere (don't enumerate similarly-named files, working notes, or old logs) -- tell the user where the document was supposed to be and what the situation is, and ask.

2. Read it

• Start from the three sections "Where things stand," "Next steps," and "Standing decisions" (the standing-decisions section constrains everything that follows -- don't skip it). Open "In flight at handover" when you need to decide whether to reload something. What else to read, and how far, is for the handoff document to decide.
• This is the only document. Don't go looking for another one on the assumption that one must exist.

3. Reply on your first turn

• Where things stand (how far the work has gotten)
• What to do next (the next step the document points to)
• Whether you're waiting on the user's judgment (and if so, on what)

Don't send back a long summary of what you read. This one reply should be enough to decide whether you need the user's go-ahead before starting work.

4. Check for concurrent work before starting

• Another session that shares this document may be alive at the same time. Before starting, check who's running with ListAgents, and ask that session directly if your scope looks like it overlaps (the document alone can't tell you what a session running since the handover has already changed).
• Right after a handover runs, read the handover log (handover.log, sitting with the lineage records). Where the records live isn't fixed -- a --root lineage keeps them outside the target project -- so resolve it the same way as the document itself, from the records: line of rein --cwd <target project> status, rather than assuming .rein/. A bug in the handover mechanism itself is only noticeable from a seat that's actually using it. If something looks off, record it wherever that environment keeps such notes.

Leaving side (before requesting a handover)

1. Have the handoff writer update the document before rein request. The document is written by rein's handoff writer (the rein:handoff-writer agent), not by you -- how to write it lives in that agent's definition. A handover request is validated on the assumption that the document is already complete, and it's the only thing the successor reads.
2. Launch the writer with the text rein gives you, exactly as given. rein's handover notices (the usage advisory, the handover trigger, the blocked stop) carry it. If you have no such notice at hand (handing over by hand, before any notice), run rein --cwd <target project> status from this session: its handoff writer: entry prints the same text, with every location filled in. If that entry says it can't, stop and ask the user -- don't build the prompt yourself.
3. Wait for the writer's report, then place the handover request (see /rein:request). While the writer is running, the request is refused (it's a running child).
4. If the request is rejected because the document's section structure doesn't match the template, launch the writer again as in step 2, then retry -- don't fix the document yourself.

The document's location follows the same effective value as the receiving side (rein config get handoff_path); if nothing exists yet, rein --cwd <target project> init creates the template.