Approval-gated CRM maintenance write. Update one selected contact's phone number through the canonical contact.update operation after reviewing the read-only maintenance preview. The bound HubSpot or Salesforce contact capability pack owns the write grant, preflight approval, vendor body mapping, and audit row.

Summarize your CRM book of business in one card: account count, total annual revenue, and total headcount. Vendor-neutral: binds to HubSpot companies or Salesforce accounts at pack install. Accounts missing a figure are skipped, never counted as zero.

Rank your CRM accounts by annual revenue and show the top slice as a table — account, domain, industry, revenue. Vendor-neutral: binds to HubSpot companies or Salesforce accounts at pack install; accounts without a revenue figure are excluded from the ranking.

Reactive silent producer. Listens to connection.api.hubspot.deal {created,updated} bus events emitted by the D-129 reconciler / webhook funnel; for each fired deal fetches the current record via the HubSpot connection adapter, classifies velocity by deal age (accelerating < 14d / stable 14-30d / stalling > 30d), and upserts the `deal_velocity_signal` enrichment per spec § A.6 cross-vendor topic. Salesforce-flavored producer ships in D-130 against the same topic. Deterministic — no AI tokens.

Reactive AI producer. Listens to connection.api.hubspot.deal {created,updated} bus events; for each fired deal fetches the current record via the HubSpot connection adapter, AI-scores it 0-100 across stage progression / amount fit / deal age / engagement freshness, and upserts the `deal_health_score` enrichment per spec § A.6 cross-vendor topic. AI-classify routing follows the topic's per-pair trust state (D-132): default `manual` until promoted via Settings → Server → Housekeeping. Salesforce-flavored producer ships in D-130 against the same topic.

Reactive alert. Listens to connection.api.hubspot.deal updated bus events; for each fired deal reads the deal record via the HubSpot connection adapter and the `deal_health_score` enrichment, dispatches a notification when the close date is within a configurable window AND the AI health score is below a configurable floor. The reconciler's poll cadence drives the practical 'daily watcher' frequency — every reconciliation cycle re-fires the trigger on the deal's current state.

Reactive alert. Listens to connection.api.hubspot.contact updated bus events; for each fired contact reads the `engagement_score_per_contact` enrichment (filled by the kernel housekeeping producer from D-129 P6) and `lifecycle_stage_inferred` (also kernel housekeeping). Dispatches a notification when the contact is `customer`-stage AND engagement trajectory is `falling` AND last meaningful touch is older than a configurable threshold. The reconciler's poll cadence drives the practical 'daily watcher' frequency.

Cross-substrate reactive alert. Listens to mail.created events; for each inbound message looks up the sender's canonical email as a HubSpot contact target_id and reads `lifecycle_stage_inferred` via enrichment-list. Dispatches a notification when the sender's HubSpot lifecycle inference is `customer` — surfaces 'this customer is asking us something — and they bought from us'. Demonstrates the cross-substrate join the D-129 substrate enables (mail trigger + HubSpot enrichment read on canonical-email target_id).

Action half for HubSpot deal follow-up. The owner provides a deal id, this recipe re-reads the deal, associated contacts, and recent engagement context from HubSpot, drafts a concise deal follow-up, sends it through the mail-send approval gate, links the sent mail to the CRM deal/contact, and seeds data.shared watch state so the outbound follow-up response watcher and reply conversion options can react when the contact replies. It never updates HubSpot, changes deal stages, creates tasks, or sends without the mail approval boundary.

Read-only daily billing cockpit for a one-person company. It scans recent Stripe invoices, payments, and customers, then shows open invoice pressure, payment exceptions, and customer data gaps without sending invoices, issuing refunds, or changing Stripe records.

Read-only Stripe invoice recovery exception queue. It assumes Stripe native reminders, failed-payment emails, Smart Retries, and Billing Automations own routine recovery. It surfaces invoices that may need owner exception handling: subscription invoices whose recovery has already started and remains unpaid, and normal invoices past the configured exception window. It drafts an owner action plan without sending invoices or emails.

Action half for the Stripe invoice recovery exception queue. Use this only when Stripe native reminders, failed-payment emails, Smart Retries, or Billing Automations are insufficient: missing primary email with an owner-supplied recipient, additional recipient, custom owner context, disabled recovery, or exhausted recovery. The recipe re-reads the invoice and customer live from Stripe, confirms the invoice remains unpaid and exception-eligible, drafts one concise exception note, sends it through the mail-send approval gate, links the sent mail to the Stripe invoice/customer, and seeds data.shared watch state so the watcher can close the loop. It never changes Stripe invoices, payments, customers, subscriptions, refunds, or payouts.

Read-only payment exception queue for Stripe. It separates PaymentIntents that may need customer action from statuses that should stay internal, while assuming Stripe native failed-payment emails, confirmation emails, Smart Retries, and Billing Automations own routine recovery. Customer-actionable rows should only be followed up manually when a documented exception applies.

Action half for the Stripe payment exceptions queue. Use this only when Stripe native failed-payment emails, payment-confirmation emails, Smart Retries, or Billing Automations are insufficient: missing primary email with an owner-supplied recipient, additional recipient, custom owner context, unavailable recovery, disabled recovery, or exhausted recovery. The recipe re-reads the payment and customer live from Stripe, confirms the status requires customer payment action, sends the owner-configured subject/body or a deterministic fallback through the mail-send approval gate, links the sent mail to the Stripe payment/customer, and seeds data.shared watch state so the watcher can close the loop. It never calls AI, captures payments, retries charges, updates payment methods, creates refunds, changes invoices, changes subscriptions, or mutates Stripe records.

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.

Scheduled adopter for Stripe billing recovery exception rows in data.shared. It reads the outbound-follow-up watch ledger, re-reads one watched invoice and one watched payment from Stripe, and marks the shared row responded_closed when the source of truth says the invoice is paid/void/uncollectible or the payment no longer needs customer action. It preserves the origin recipe id and does not send mail, notify customers, update Stripe, retry charges, capture payments, void invoices, or create refunds.