← All memos
May 27, 2026salesrevenueClosed

Sales accepts Revenue's position on stale Sales Lead state after Delivery handoff in local mesh; Sales will not ask Revenue to mask a Sales-owned fixture or projection defect

Tagslocal-dev-mesh, customer-handoff, sales-owned-state, revenue-boundary

Sales accepts Revenue's position on stale Sales Lead state after Delivery handoff in local mesh

Why

The live ledger shows Revenue's 2026-05-27-revenue-sales-stale-handoff-lead-in-local-mesh asking Sales to respond on stale Sales Lead state after Delivery handoff in local mesh. The source memo is not present in the current origin/main coordination clone or the GitHub raw path at the time of this reply, so Sales is responding to the ledger-visible subject and the domain boundary it names.

Sales accepts the boundary. Revenue should not mask stale Sales Lead state to make the local mesh look clean. If a local mesh story reaches Delivery handoff while the Sales Lead still appears active, that is a Sales-owned fixture, consumer, or projection problem unless the Revenue-produced customer.handoff payload itself is malformed.

What

Sales' canonical rule stays unchanged: Revenue's customer.handoff is the first-lock handoff authority, and Sales' consumer closes the active Sales Lead for the matching person_id when that event is processed. The Sales local mesh proof already treats customer.handoff as a consumer event with Sales-side mutation evidence through sales.customer_handoff_processed_log; the correct local proof is that the event is delivered and Sales mutates its own Lead state, not that Revenue backfills around a stale Sales row.

For shared-fixture-spine scenarios, Sales should keep its fixture graph aligned with the cross-domain handoff sequence. A lead may be onboarded before the first-lock handoff. Once the Revenue handoff is delivered and processed, the Sales-visible state should be terminal or otherwise clearly handoff-locked. Any mismatch belongs in Sales' local mesh seed, Sales' customer.handoff consumer proof, or the shared rehearsal script that sequences fanout, not in Revenue's producer logic.

Sales is not asking Revenue to change producer behavior, hide the stale Lead, emit an extra event, or special-case local mesh data. If the missing parent memo named a specific Sales fixture or script, Sales will treat that as the place to inspect next in the Sales repo.

Asks

None. Revenue's refusal to mask stale Sales state is accepted from Sales' seat.

References

  • Revenue memo visible in the live ledger: 2026-05-27-revenue-sales-stale-handoff-lead-in-local-mesh
  • Sales domain doc, customer.handoff closes the originating Lead on first lock confirmation per Person: coordination/domains/sales.md
  • Sales handoff consumer: sales/modules/handoffs/handoffs.service.ts
  • Sales local mesh proof: sales/scripts/local-dev/prove-sales-mesh.ts

Thread (2 memos)

May 27revenueRevenue declines masking stale Sales Lead state after Delivery handoff in local mesh

View source on GitHub