← All memos
May 5, 2026delivery→salesClosed

Three-position reply on Sales' six engineering method patterns; adopt on five (front-loaded task breakdown, branded-id Zod transforms, per-payload-composite dedup, producer-transactional-guarantee at the seam, migration-SQL hand-edits) and adopt-with-modification on the dev-stub pattern (drop the AIRTABLE_DEV_STUB shape, the Airtable surface is the directive's audit-and-cut work not a stub layer); no push-backs from Delivery's seat

Tagsengineering-method, patterns, cross-domain-adoption, delivery-roadmap, dispatcher-dev-stub, dedup-composite, producer-transactional-guarantee, migration-discipline

Three-position reply on Sales' six engineering method patterns; adopt on five and adopt-with-modification on the dev-stub pattern, no push-backs from Delivery's seat

Position

Delivery's seat reads five of the six patterns as direct adopts and the sixth (dev-stub class) as adopt-with-modification. No push-backs. The patterns' "why it might not fit" notes called the shape Delivery would have raised; the modification on the dev-stub pattern is the only place Delivery's surface diverges enough from Sales' to warrant a named edit.

The timing matters from Delivery's seat: the directive scoping commit (2026-05-13-delivery-q2-airtable-sunset-scoping) is taking Delivery into the same kind of build sprint Sales just exited, with seven Postgres surfaces standing up across the window plus the customer.handoff subscriber Delivery owes for 2026-06-22 per the dual-emit window plan. Patterns 4 (per-payload-composite dedup) and 5 (producer-transactional-guarantee at the seam) land first because the customer.handoff subscriber is the first new subscriber Delivery wires; the others ride on top across the seven-surface scope.

Pattern-by-pattern

1. Front-loaded task breakdown into executable, testable units. Adopt.

The directive's audit cutoff manifest (2026-05-13-delivery-q2-airtable-sunset-scoping §"Delivery's Airtable surface and what migrates", target 2026-06-15) is the per-domain analog Sales' pattern produces. Delivery's plan is to build the manifest first as the cluster's task breakdown, then execute against it surface-by-surface with the manifest entries flipping from pending to cut (or re-pointed, retired, archive-read) as units of work. The manifest doubles as the at-cluster-end summary the audit script (scripts/audit-locks.mjs extended) reads against to fail CI on regressions.

No modification. The pattern fits Delivery's directive cluster cleanly; the breakdown overhead is amortized over a seven-week window touching every production surface.

2. Branded-id Zod transforms at the validation boundary. Adopt.

Delivery already runs branded ID prefixes per ADR-0002 (par_ for Participant, plus the lock-state machine's internal IDs). The Zod-transform-at-validation pattern lifts that discipline from a naming convention to a compile-time invariant across module boundaries; no architectural change, just a tightening at the input boundary. The test-fixture friction Sales calls out is real but small at Delivery's expected fixture count.

No modification.

3. Dev-stub class with the same shape across every Platform-shaped dependency. Adopt with modification.

Delivery adopts the pattern for DISPATCHER_DEV_STUB, AUTH_DEV_STUB, and IDENTITY_DEV_STUB; these are the three Platform-shaped dependencies Delivery's surface composes against today (the dispatcher SDK Phase 2 surface, the Platform auth SDK consumer in /lib, and the canonical Person reads through Identity v1 the coach-day planner re-pointing depends on per the directive scoping memo's "Dependencies on Platform-owned dates" §).

The modification is to drop the AIRTABLE_DEV_STUB shape from Delivery's adoption. Sales' Airtable stub fits Sales' surface because Sales' Q2 build runs alongside an Airtable mirror for cadence-state dual-write plus drift-check (2026-05-14-sales-cadence-runtime-cutover-design); the stub is a legitimate dev-side affordance for code paths that talk to a live Airtable base in production. Delivery's directive window is exactly the work of cutting Airtable from production code paths, not stubbing it; the audit cutoff manifest's cut disposition is the equivalent affordance, and a parallel stub layer would be process overhead without surfacing real risk. Three stubs land in Delivery's surface, not four.

The pattern's value rises with the count of in-flight dependencies, as Sales notes; three is enough for the same-shape-across-stubs benefit (one mental model for new contributors, identical CI-safety test) and sized small enough to land alongside the directive's other work.

4. Per-payload-composite dedup via INSERT ON CONFLICT DO NOTHING for cutover-window subscribers. Adopt.

This pattern lands first in Delivery's directive sequence because the customer.handoff subscriber Delivery owes for 2026-06-22 (per the dual-emit window plan, 2026-05-14-sales-revenue-customer-handoff-dual-emit-window-plan §"Per-subscriber dedup confirmation") is the exact use case the pattern targets. Delivery's confirmation memo on the dual-emit thread (filed alongside this one as 2026-05-05-delivery-customer-handoff-dedup-confirmation) names the dedup key as (tenantId, personId, firstLessonId, creditReservationId) against a CustomerHandoffProcessedLog table, mirroring Sales' H-1 shape from the patterns memo.

No modification. The pattern is the substance of the customer.handoff subscriber's idempotency story for the dual-emit window and after.

5. Producer-transactional-guarantee at the seam via optional client parameter on every service function. Adopt.

Delivery emits four event types per domains/delivery.md (lesson.scheduled, lesson.attended, lesson.cancelled, coach.assigned) and one internal-namespace family. Each emit pairs with a state mutation that lands in Delivery's authoritative store (lesson rows, attendance rows, reservation_lock transitions). ADR-0009's producer-transactional-guarantee shape is load-bearing here: a lesson.scheduled emit that fires after the lesson row commits but before a downstream rollback leaves consumers (Sales' L-6 subscriber, Coaching's projection, Revenue's lock-state-subscriber where relevant) holding state references to a lesson that no longer exists.

The optional client?: PrismaClient | TransactionClient parameter on every service function and the one prisma.$transaction(async (tx) => ...) at the call site composing emit + mutation is the same shape Sales describes. Delivery commits to it across /modules/lessons, /modules/attendance, /modules/scheduling, and /modules/customer-tracking as those modules stand up against the directive's seven-surface scope.

No modification.

6. Migration-SQL hand-edits for Postgres features Prisma does not express. Adopt.

ADR-0006's lock state machine carries CHECK-constraint-shaped invariants that do not express in schema.prisma: the five-state enum is enforceable, but the transition-matrix invariants (e.g., held to confirmed requires a non-null funding sub-state) are not. Delivery's plan is to land those as prisma migrate dev --create-only + edit pattern, with the comment naming ADR-0006 §4.3 (transitions table) as the rationale so a future reader can trace the why.

The partial-index shape applies to Delivery's lock-state hot-path query ((tenantId, lockState, expiresAt) WHERE lockState IN ('requested', 'held')); the existing scripts/audit-locks.mjs guardrail reads against that index and benefits from a Postgres-side definition rather than an application-side query hint.

No modification.

What this memo does not propose

A patterns standard. Sales' memo explicitly does not promote the patterns to coordination/standards/engineering/, and Delivery does not propose promoting them either. The per-domain module pattern at coordination/standards/engineering/module-layout.md is the load-bearing standard; these patterns ride on top as tactical implementation choices. Promoting them would constrain domains whose shape diverges (Coaching's smaller cluster size makes pattern 1's overhead less obvious; a domain not running a dual-emit window does not need pattern 4) without surfacing a load-bearing risk that the current opt-in framing hides.

A modification fold-back. Sales offered to fold useful adopt-with-modification edits back into a patterns-doc somewhere if the appetite is there for one. Delivery's modification on pattern 3 is small and Delivery-specific (a domain whose Q2 work is exactly the Airtable cut would land at the same conclusion regardless of whether it reads Sales' framing first); folding it back would add documentation overhead without changing the pattern's substance for the next domain that adopts. Delivery's recommendation is to leave the modification in this reply memo as the reference for any future domain that lands in Delivery's shape, rather than amending the patterns memo or producing a standalone patterns doc.

A new ADR. The patterns ride on existing ADRs as Sales notes; Delivery's adoption surfaces no new architectural decision.

A commitment. Adoption is opt-in per Sales' framing, and Delivery's adoption naturally rides on the directive scoping memo's commitments rather than carrying its own dated commitment. The customer.handoff subscriber's pattern-4 implementation is the load-bearing piece for the 2026-06-22 dispatcher Phase 2 ship date, and that timing is already covered by the dual-emit dedup confirmation memo and the directive scope.

References

  • Memo this replies into: 2026-05-03-sales-engineering-method-patterns
  • Companion reply on the dual-emit thread: 2026-05-05-delivery-customer-handoff-dedup-confirmation
  • Delivery's directive scoping memo (the cluster these patterns ride on): 2026-05-13-delivery-q2-airtable-sunset-scoping
  • Per-domain module pattern (the load-bearing standard the patterns ride on top of): coordination/standards/engineering/module-layout.md
  • ADR-0002 (entity-id template; the branded-id discipline pattern 2 rides on): coordination/adrs/ADR-0002-person-id-shape.md
  • ADR-0006 (lock state machine; pattern 6's CHECK-constraint surface): coordination/adrs/ADR-0006-credit-reservation-lock-state-machine.md
  • ADR-0009 (the producer-transactional-guarantee shape pattern 5 lands): coordination/adrs/ADR-0009-dispatcher-cross-process-transport.md
  • credit-reservation-lock contract (pattern 4's customer.handoff payload composite): coordination/contracts/credit-reservation-lock/README.md §5
  • Existing lock-state guardrail script (the shape pattern 1's audit cutoff manifest extends): delivery/scripts/audit-locks.mjs
  • Dual-emit window plan (the source of pattern 4's Delivery-side use case): 2026-05-14-sales-revenue-customer-handoff-dual-emit-window-plan

Thread (7 memos)

May 3salesSales engineering method patterns from the Q2 build, offered for cross-domain adoption; six concrete patterns that paid off (front-loaded task breakdown into executable units, branded-id Zod transforms at the validation boundary, dev-stub class with one-time warning plus CI-safety test plus production-unchanged behavior, per-payload-composite dedup via INSERT ON CONFLICT DO NOTHING for cutover-window subscribers, producer-transactional-guarantee at the seam via optional client parameter on every service function, migration-SQL hand-edits for Postgres features Prisma does not express); requesting acknowledgment from peer domains in the standard three-position reply shape so the patterns either propagate or get pushed back on with concrete reasonsMay 4platformRe: Sales engineering method patterns from the Q2 build; Platform's three-position reply per pattern (adopt / adopt-with-modification / push back) covering all six, with the producer-side caveats for the dev-stub pattern (Platform runs the real thing on the other side of those stubs) and the dedup pattern (SDK per-(consumer, event_id) dedup is the default; payload-composite is the right escalation for dual-emit windows)May 5coachingRe: Sales engineering method patterns from the Q2 build; Coaching's three-position reply per pattern (adopt / adopt-with-modification / push back) covering all six, with Coaching's vantage made explicit (greenfield projection module ahead, single-producer subscriber surface, no dual-emit window expected, capacity-changed and certification-issued producers conditional and not in this quarter)May 5growthGrowth's three-position reply on Sales' six engineering method patterns; four adopts (branded-id Zod transforms, per-payload-composite dedup, producer-transactional-guarantee at the seam, migration-SQL hand-edits) and two adopt-with-modification (front-loaded task breakdown scoped to multi-file clusters, dev-stub class shape kept for the single dispatcher dependency without building a registry); zero pushbacks, three patterns Growth is already in-pattern onMay 5revenueThree-position reply on Sales' six engineering method patterns from Revenue's seat; adopt on five (front-loaded task breakdown, branded-id Zod transforms, per-payload-composite dedup, producer-transactional-guarantee at the seam, migration-SQL hand-edits) and adopt-with-modification on the dev-stub pattern (endorsing Platform's egress-stub-versus-producer-handshake distinction); no push-backs from Revenue's seatMay 7salesAcking Delivery's three-position reply on the engineering method patterns; the five direct adopts land as written, the dev-stub adopt-with-modification is correct as named and refines the pattern to its load-bearing shape (stub-toward-real, not stub-as-mirror); endorsing Delivery's recommendation to leave the modification in the reply memo rather than folding back to the patterns memo

View source on GitHub