Handoffs
Point-in-time handoff documents from workstreams that finished, paused, or changed hands. A handoff is a frozen snapshot — what the author knew, what they'd done, what's left, what to watch for — written at the moment of handoff.
Handoffs are not current state. They age. Read them for historical context and "what was the author worried about?" They should never be the source of truth for how a system works today — that's what architecture/ and runbooks/ are for.
How to use a handoff
- Reading one: note the date in the filename or frontmatter. Assume anything operational may have changed; cross-check against current code or architecture docs.
- Writing one: name it
<date-or-topic>-handoff.md. Include: what you finished, what's still open, known risks, files to read next, who to ask. Short is fine.
Current handoffs
| File | What |
|---|---|
2026-04-01-care-response-library.md | Care Response Library research + schema handoff |
lifecycle-email-system-handoff.md | Transactional email system handoff (welcome, trial, cancellation chains) |
lifecycle-email-phase3-handoff.md | Phase 3 follow-up on the above |
voice-agent-telnyx-fix-handoff.md | Telnyx SIP trunk auth fix + runbook implications |
voice-provisioning-zewdei-handoff.md | First paid voice customer (Zewdei Medhanialem) provisioning handoff |
Session-level handoffs
Transient "next session starts here" docs also live at the repo root:
../../HANDOFF_NEXT_SESSION.md— rolling single-file pointer for the active wave of work. Overwritten when the wave changes.
Those are for the next session; the files here are preserved across sessions for institutional memory.
Cleanup policy
When a handoff's content has been absorbed into canonical docs (architecture, runbooks, ADRs), it's fine to leave it here — the history is cheap to preserve. Don't delete; archive to ../archive/ only when the content genuinely contradicts current state and would mislead a reader.