Cross-pack WooCommerce customer reply workflow. It reads one WooCommerce order, optional customer context, order notes, and refunds, drafts a plain-text customer reply from explicit owner guidance, and sends through core.mail.send only when send_reply is enabled. After an approved send returns a mail thread, it seeds durable data.shared watch state in the outbound-follow-up-response-watcher namespace so customer replies are surfaced back to the owner with the WooCommerce order context. WooCommerce is read-only in this workflow; it does not edit orders, create refunds, create customer-visible order notes, mutate products, inventory, coupons, shipping, payment gateways, webhooks, WordPress admin surfaces, or arbitrary endpoints.

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.

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.