The Salesforce vendor pack — bundles the `salesforce-catalog` D-165 catalog ingredient so every Salesforce Tier-P op (`recued-core.salesforce.opportunity.read`, `contact.read`, `account.search`, `opportunity.create`, …) resolves against one installed binding. Vendor-specific recipes declare `depends_on: ["recued-core.salesforce"]` and read Salesforce sObject fields RAW (`{{step.opportunity.result.StageName}}`, no `properties` nesting) — the catalog op owns only how a recipe-named field folds into the SOQL/REST query (D-182 §3 Tier-P, decision-b). It bundles the Salesforce augmentation producers/alerts (deal health + velocity signals, closing-soon + low-engagement + new-inquiry notifications) and the contact-maintenance write recipes — each binds its op-steps against this pack's own catalog at install (D-182 §3 first-party self-reference), mirroring the HubSpot vendor pack. Installs the catalog dormant until each recipe's Salesforce connection variable is bound to an enrolled connection (Settings → Connections); every call then runs through the D-165 gateway (operation-level risk/grant/approval + per-call audit). Cross-vendor canonical recipes live in `recued-core.crm` instead — install whichever vendor pack matches your CRM and `recued-core.crm` binds the same connection-agnostic recipes to it at dispatch.