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.salesforce.opportunity {created,updated} bus events emitted by the D-130 reconciler / CometD funnel; for each fired opportunity fetches the current record via the Salesforce connection adapter, classifies velocity by deal age (accelerating < 14d / stable 14-30d / stalling > 30d), and upserts the cross-vendor `deal_velocity_signal` enrichment per spec § A.6 (D-130 P6 widening). Salesforce parallel of `deal-velocity-signal-hubspot`; both recipes share `variant_group: deal-velocity-signal` so the marketplace card collapses across vendors. Deterministic — no AI tokens.

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

Reactive alert. Listens to connection.api.salesforce.opportunity updated bus events; for each fired opportunity reads the current record via the Salesforce connection adapter and the cross-vendor `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 + CometD streaming drive the practical 'daily watcher' frequency. Salesforce parallel of `notify-deal-closing-soon-hubspot`; both share `variant_group: notify-deal-closing-soon`.

Reactive alert. Listens to connection.api.salesforce.contact updated bus events; for each fired contact reads the cross-vendor `engagement_score_per_contact` enrichment (filled by the kernel housekeeping producer from D-129 P6 + D-130 P6 widening) and the Salesforce-flavored `lifecycle_stage_inferred_salesforce` topic (filled by the D-130 P6 kernel producer). 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 + CometD streaming drive the practical 'daily watcher' frequency. Salesforce parallel of `surface-low-engagement-contacts-hubspot`; both share `variant_group: surface-low-engagement-contacts`.

Cross-substrate reactive alert. Listens to mail.created events; for each inbound message looks up the sender's canonical email as a Salesforce contact target_id and reads `lifecycle_stage_inferred_salesforce` via enrichment-list. Dispatches a notification when the sender's Salesforce lifecycle inference is `customer` — surfaces 'this customer is asking us something — and they bought from us'. Demonstrates the cross-substrate join the D-130 substrate enables (mail trigger + Salesforce enrichment read on canonical-email target_id; canonical-email matching is contract-level per D-130 P3 reconciler). Salesforce parallel of `notify-new-inquiry-from-existing-customer-hubspot`; both share `variant_group: notify-new-inquiry-from-existing-customer`.

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.