Read-only Stripe customer cleanup queue. It finds customers missing email or display name so billing, support, and invoice follow-up stay usable without automatically updating Stripe records.

Reactive reply-side of the outbound follow-up loop. On every inbound mail it matches the message by thread against durable data.shared watch state seeded by TWO producers — outbound-follow-up-pressure-producer (status followup_due, watched_contact = the primary recipient) and send-support-reply-from-mail (status watching_customer_response, watched_contact = the customer). It confirms the reply's sender is that watched contact — recovering the contact from the linked source mail (via the stored record_id) when a producer denormalized no address, and failing closed (skipping) when it cannot establish the counterparty — then classifies the reply, advances the shared state to responded_closed or response_needs_owner, and links the reply mail to the watched source mail. Those state transitions are what unified-work-queue and weekly-owner-review read to surface or retire the follow-up. It never sends mail or mutates an external system.

Reactive outbound mirror of outbound-follow-up-response-watcher. It fires on the same data.mail created stream but processes the OWNER's outbound sends rather than inbound replies: when the owner sends on a thread already tracked in data.shared watch state, it confirms the sender is the owner (derived from the linked source mail's From via the stored record_id) and refreshes the row to watching_customer_response with a fresh last_outbound_at and sent_message_id, moving the ball back to the contact. Refresh-only: it never creates rows (the pressure producer and the send recipes own creation) and never reopens responded_closed threads, and it fails closed (skips) when it cannot confirm the owner or find a matching row. This captures owner replies sent from a normal mail client, which the send recipes cannot record.

Neutral detection recipe for the outbound follow-up loop. It scans one response_needs_owner data.shared watch row, fetches the reply body, extracts possible conversion facets for meeting, task, insight note, commitment, and linked CRM deal next-step updates, writes compatible proposal rows for the matching owner-invoked action recipes, records a per-reply notification marker, and sends one notification that the reply has conversion options. It does not choose an action and never creates calendar events, tasks, notes, commitments, or CRM updates. User intent is expressed later by running one or more manual action recipes.

Owner-invoked create half of the meeting-request conversion edge. It reads one awaiting_owner_approval proposal written by outbound-follow-up-meeting-request-calendar (optionally targeted by proposal_thread_key), creates the calendar event from the proposal's already-extracted schedule, links the event back to the reply and source mail, closes the follow-up loop on the source watch row, and marks the proposal scheduled. This recipe is manual-only on purpose: the calendar create (and, on some providers, the attendee invite) is an outward-facing action, and running it is the owner's explicit approval. It takes no calendar action when there is no pending proposal or the proposal lacks a concrete start and end time.

Owner-invoked create half of the task conversion edge. It reads one awaiting_owner_approval proposal written by outbound-follow-up-task-from-reply, optionally targeted by proposal_thread_key, creates a Recued task from the proposal, links the task back to the reply and source mail, closes the source follow-up watch row, and marks the proposal created. This recipe is manual-only on purpose: running it is the owner's approval to turn the proposed reply action into durable work.

Owner-invoked create half of the customer-insight note conversion edge. It reads one awaiting_owner_approval proposal written by outbound-follow-up-insight-note-from-reply, optionally targeted by proposal_thread_key, creates a Recued note from the proposal, links the note back to the reply and source mail, and records the note id on the source follow-up watch row WITHOUT closing the loop — an insight note is complementary memory capture, so the thread stays open (its status is preserved) for the actual task/meeting/reply. It marks the proposal created so it is not re-proposed. This recipe is manual-only on purpose: running it is the owner's approval to turn the proposed customer signal into durable relationship memory.

Owner-invoked create half of the commitment conversion edge. It reads one awaiting_owner_approval proposal written by outbound-follow-up-commitment-from-reply, optionally targeted by proposal_thread_key, creates a Recued commitment from the proposal, links the commitment back to the reply and source mail, and records the commitment id on the source follow-up watch row WITHOUT closing the loop. A commitment is complementary accountability capture, so the thread keeps its current status for the actual task/meeting/reply. It marks the proposal created so it is not re-proposed. This recipe is manual-only on purpose: running it is the owner's approval to turn the proposed promise into durable work.

Housekeeping GC for the outbound follow-up loop. data.shared writes do not honor ttl (the durable store rejects it), so the per-thread conversion proposals written by the calendar/task/insight-note/commitment/CRM deal update detectors would otherwise persist forever after they are approved. This daily auto_run lists the outbound-follow-up namespace and deletes only proposal rows in a terminal status (scheduled / task_created / note_created / commitment_created / crm_deal_updated). It is safe because re-proposal is already blocked by the conversion id recorded on the source watch row for one-shot conversions (calendar_source_id / task_id / insight_note_id / commitment_id), while CRM deal-update duplicates for the same reply are blocked by the per-reply notification marker plus pending proposal rows. It never touches the watch rows themselves (they stay for re-open on a later reply), and it leaves awaiting_owner_approval proposals alone (they carry no timestamp, so a stale-unactioned proposal cannot be aged out here — record a created_at on proposals if that is wanted later).