Estate
Handoff Protocol
Q and Moneypenny deposit deliverables; a Tower cron picks them up and routes delivery through the right persona and channel.
Situation
Q and Moneypenny run in isolated research/briefing sessions with no automated path to deliver an artifact destined for a different channel or persona — the gap surfaced concretely when a Q Research Rhodes itinerary needed to reach the Dig channel (2026-06-26). This protocol closes that gap: producing personas deposit deliverables rather than sending to channels directly, and a mallory-runtime consumer picks them up, resolves the target channel via a semantic alias, and delivers asynchronously with a receipt and audit trail.
Phase 1 (file-based) shipped 2026-06-26, superseding an earlier spec-only PR. Phase 2 (a D1 handoffs table with a Worker delivery endpoint, Discord/Slack support, and a management UI) is deliberately deferred until the file-based shape is validated in production.
Key decisions
File-based store for Phase 1
Deliverables land as Markdown + YAML frontmatter under ~/handoffs/outbound/{persona}/{id}.md; simpler and git-visible, chosen over a D1 row until the shape proves out.
Producers never send directly
Q or any Tower persona calls handoff-deposit.sh to create a handoff; the Tower cron (handoff-deliver.sh, suggested */5) is the only thing that actually delivers.
Atomic pickup + directory-as-ack
The consumer moves a picked-up file to in-flight/, then to delivered/ or failed/ — in Phase 1 the destination directory itself is the receipt; Q confirms by listing delivered/.
Semantic channel aliases
Producers write a target like alex or dig, never a raw platform ID; channels.yaml resolves the alias, and unknown aliases land in failed/ rather than silently misdelivering.
Migration path preserves the shape
Phase 2's D1 handoffs table is designed to reuse the same frontmatter fields as columns, so the file-based Phase 1 shape is the intended migration breadcrumb, not throwaway scaffolding.
Risks & guardrails
Delivery platforms are incomplete
Only Telegram delivery is implemented; Discord and Slack are explicitly not yet built (Phase 1B / Phase 2).
No retraction or editing
Once deposited, a handoff is pending until processed — a producer cannot yet update or withdraw a deliverable before pickup.
Content size limits
Telegram's 4096-char limit is handled by truncation with a note; larger deliverables with images or files are an open question.
Apparent-sender ambiguity
When Q authors a deliverable delivered via Mallory's Telegram, the current mitigation is a [via q-research] prefix rather than a resolved identity model.
docs/estate/08-handoff-protocol.md