Revenue invoices must refresh Square from the canonical Platform Person name
Reported production behavior
An operator corrected a client name through the Sales Workbench's Platform-owned Person name API. The Workbench cards refreshed to the new canonical display name, but a subsequently generated invoice still showed the old name.
Sales traced both invoice paths. The add-on and top-up path sends payer_name to POST /api/v1/orders/invoice-link. The first-lesson path sends customer_name to POST /api/v1/sales-ordering/close. Sales has now changed both callers to load the Person uncached from Platform immediately before invoice submission, so the request snapshot is no longer sourced from the Lead intake record or a mounted UI prop. Sales fails before provider work when Platform cannot return a usable canonical name.
That caller correction is necessary but does not close the provider defect for an existing Revenue Client. Revenue's ensureSquareCustomerBridge currently computes nameSnapshot as client.fullName ?? payerName, and it derives canonical first and last name parts only from client.fullName. A nonblank stale Revenue Client.fullName therefore wins over the corrected request name. Both invoice surfaces call this bridge, so Square can be updated with the old Revenue snapshot after Platform and Sales already show the corrected Person.
Ownership and requested behavior
Platform remains the sole canonical Person writer. Revenue owns its Client projection, Square customer bridge, provider customer updates, and invoice issuance. Sales will not write Revenue Client rows or Square directly.
Revenue, please make invoice-time Square synchronization use the current canonical Platform Person name for the supplied person_id, even when Revenue already has a nonblank older Client.fullName. The preferred implementation is for Revenue to use its existing Platform Identity client with a fresh read before syncSquareCustomer, then use the returned canonical name parts and display name for the provider update. Revenue may refresh its local Client name snapshot as a projection, but it must not become a competing identity writer.
If Revenue instead chooses to treat Sales' now-fresh payer_name and customer_name as authoritative request snapshots for this operation, please amend the relevant contract text because sales-ordering-surface currently describes customer_name as a fallback for a missing usable Revenue client name. In either implementation, regression coverage should prove that a stale nonblank Revenue Client name cannot override a newer canonical Platform Person name on either invoice surface.
Please also document the repair behavior for an already-generated open invoice. If updating the Square customer does not update the name rendered on an existing invoice, Revenue should use its existing cancel and regenerate workflow rather than mutating Sales or Platform history.
Acceptance evidence requested
Revenue's reply should identify the shipped commit and production deployment, cover both invoice-link and sales-ordering close, and distinguish new-invoice correctness from repair of an invoice that already exists. A production-safe proof may use a synthetic Person and invoice. Do not change a real customer's provider invoice without the operator naming the exact target and authorizing that repair.
References
2026-08-03-sales-platform-person-name-edit-api2026-08-03-platform-person-name-edit-production-handoff2026-08-03-sales-person-name-edit-ui-live2026-06-01-sales-revenue-invoice-link-square-customer-name-gap2026-06-01-revenue-invoice-link-payer-name-fallback-shippedcontracts/identity/README.mdcontracts/sales-ordering-surface/README.md- Sales invoice callers:
modules/workbenches/workbench-credit-orders.service.tsandmodules/close-orchestration/close-orchestration.service.ts - Revenue bridge:
modules/square-customer-bridge/service.ts