The Salesforce adapter creates no Lead, and the PRD asked for one
Decided
an approved quote syncs to Salesforce as an Account plus a Closed-Won Opportunity, and never as a Lead. The PRD's task 9 asks for "a Lead and an Opportunity". This is a deliberate deviation and it is recorded here rather than quietly satisfied, because the cheapest way to close the gap — create a Lead too — would ship a defect into every tenant's pipeline report.
Why a Lead is the wrong object here
In Salesforce's data model a Lead is an *unqualified enquiry*: someone who might become a customer. Converting a Lead is what produces the Account, Contact and Opportunity, and conversion is a one-way door the CRM tracks as a funnel stage.
The object this code path holds is not an enquiry. It is a quote that has been approved, priced, and margin-checked — signed work with a number on it. Filing that as a Lead means every pipeline report the tenant runs counts won jobs as prospects, conversion rate is computed against a denominator containing its own numerator, and forecast Amount is double-counted the moment someone converts the Lead into the Opportunity we already created.
Creating both a Lead and an Opportunity for the same quote is worse than either alone: it is two records for one commercial event, with no conversion link between them, and nothing downstream can tell that they are the same job.
Leads belong to whatever fills the enquiry form on the marketing site. That is a different code path, a different trigger, and a different object — and if it is wanted, it should be built there rather than bolted to the approval hook because a checklist line asked for the word.
What the code does instead
backend/src/integrations/salesforce/adapter.ts creates or matches the Account, creates the Opportunity at StageName: Closed Won with the quote total as Amount, reads the record back, and records matchesQuoteTotal. Salesforce currency fields are decimal and ours are integer cents, so the conversion happens once and the stored value is verified rather than assumed. That read-back is the part of task 9 that actually mattered — "a quote synced to the cent" — and it is implemented and tested.
What was wrong in the record, and is now fixed
docs/PRD-STATUS.md reported this row as "Lead, Opportunity, and a quote synced to the cent". That was false. The adapter never had Lead code. A status document that credits work which does not exist is worse than one that reports a gap, because the gap at least gets argued about. The row now states the deviation and points here.
What would make this wrong
A tenant whose sales process genuinely begins at quote — where a configured price is the first contact and qualification happens afterwards — would want the Lead. That is a per-tenant workflow choice, not a global one, and the shape it should take is a configurable target object on the connection record, not a second unconditional POST. Nobody has asked for it.