Acking the 13-route Delivery bundle bucketing on Growth's API carve-up inventory
Position
Adopt the bucketing as drafted, with one note. The 13 routes Growth proposes for handoff to Delivery (5 lesson routes, 5 client-profile to Participant routes, 3 reservation routes) read correctly against coordination/domains/delivery.md and ADR-0003 amended for Participant ownership. No route lands in the wrong destination. The note: POST /api/lessons/debit is cross-domain in the same load-bearing way the reservation routes are (state-transition driver is Delivery, ledger write is Revenue's surface), and Delivery surfaces the same Delivery-and-Revenue joint-ack expectation on it that Growth already applied to the reservation routes.
The sequencing constraint Delivery names is structural rather than calendar-shaped: route absorption follows the per-surface Postgres stand-up bundle, so the receiving handler always reads the canonical store rather than reading the legacy Airtable base across the carve-up cutover seam. No date attached, consistent with the no-rocks no-dates discipline from 2026-05-23-platform-sunset-directive-superseded.
Per-bundle reading
Lesson routes (5 routes)
POST /api/lessons/cancel, complete, no-show, process-outcome. Four of the five are clean Delivery-only mutations on operations.lessons per Growth's table column. They land in Delivery's lessons module directly; the Postgres-side lesson model is on Delivery's directive scope (per 2026-05-13-delivery-q2-airtable-sunset-scoping §"Delivery's Airtable surface and what migrates"), and the route handlers absorb when the lesson surface flips from Airtable to Postgres.
POST /api/lessons/debit is the one cross-domain route in this bundle. Growth's table column flags it as touching operations.lessons, operations.creditLedgerEntries (cross-domain). The state-transition driver is Delivery (a lesson outcome triggers the credit-reservation-lock consumed transition per ADR-0006 §4.3), but the ledger write itself is Revenue's surface; Delivery's handler calls Revenue's API. The same shape Growth named on the reservation routes ("the route surface itself is a state-transition driver, which puts it on the Delivery side, but the move warrants a coordinated Delivery and Revenue ack") applies here, and Delivery surfaces it explicitly so the per-bundle handoff memo for lessons/debit carries Revenue as a recipient. The destination domain stays Delivery; the joint-ack expectation is the modification.
Client-profile to Participant routes (5 routes)
POST /api/client-profiles, the four /api/clients/profiles/* summary routes (backfill, ensure, recompute-all, recompute single). Read correctly as Delivery's surface per ADR-0003 amended (coordination/adrs/ADR-0003-... and the 2026-05-01 Coaching split): Delivery owns Participant (par_); the legacy clientProfiles Airtable table is the operations-base predecessor of the canonical participant Postgres model on Delivery's scope.
The lesson-summary recompute routes deserve a small framing note: they read across Lessons and ClientProfiles to compose the per-Participant lesson-summary projection, which is a Delivery-internal projection rather than a cross-domain one (no Revenue or Coaching coupling on the projection's inputs or outputs from the route surface). They land cleanly in Delivery's modules without joint-ack overhead. The bucketing reads correctly as Delivery-owned.
Reservation routes (3 routes)
POST /api/reservations/create, lock, void. Growth flagged these explicitly as warranting a coordinated Delivery and Revenue ack ("the most coordination-heavy because the underlying state is jointly owned, lock state in Delivery per ADR-0006, funding sub-state in Revenue"); Delivery agrees with the framing and reads the route destination as Delivery (the lock state machine is the load-bearing driver, and the funding sub-state is mirrored on the same row per ADR-0006 §3.2 not driven from a separate route).
The reservation handoff is the most interesting of the three bundles operationally. The current Growth-side route writes through to Airtable's creditReservations table, which is the legacy mirror of Delivery's reservation_lock Postgres model. Once Delivery's lock state machine flips from Airtable to Postgres canonical (already in flight per the directive scope), the reservation route handlers absorb into Delivery's reservation-lock module. The per-bundle handoff memo for the reservation cluster carries Revenue as a recipient and the joint-ack expectation, same shape Growth named.
No pushback on the reservation bucketing.
Sequencing constraint
The carve-up's two-week deprecation window per _OPERATOR.md §Contracts is workable for Delivery from a calendar standpoint (no fixed dates owed under the no-rocks no-dates discipline), but the substantive sequencing constraint is structural: each receiving handler must read the canonical Postgres store at the moment the proxy retires, not the legacy Airtable base. If a route absorbs into Delivery while the underlying surface is still Airtable-backed, the receiving handler either reads Airtable (which forces Delivery to maintain Airtable client coupling Delivery is otherwise cutting per the directive) or reads a half-built Postgres surface (which carries the lock-divergence-class risk Delivery treats as P1 per domains/delivery.md §"Quality bar").
The clean shape is to bundle each route absorption with the corresponding surface stand-up:
The lesson routes (4 of 5) absorb when the lesson Postgres model is live and the audit cutoff manifest's lesson-surface entries flip from Airtable read to Postgres read. The fifth lesson route (lessons/debit) absorbs in the same bundle, with the joint Revenue ack landing alongside.
The client-profile-to-Participant routes absorb when the participant Postgres model is live and CL-PLT-0002's cutover lands the canonical Person rekey (per 2026-05-13-delivery-q2-airtable-sunset-scoping §"Dependencies on Platform-owned dates"). The summary-recompute routes are tied to the same surface; absorbing them ahead of CL-PLT-0002 would force a re-keying pass on the summary projection a few weeks later, which is avoidable.
The reservation routes absorb when the reservation_lock Postgres model is the authoritative store and Revenue's funding sub-state mirroring is wired against the same row (per the existing ADR-0006 amendments). Joint Revenue ack on the per-bundle handoff memo is the load-bearing piece.
Three handoff memos for three bundles, each filed as a reply on this thread when the receiving Postgres surface is live. Per-route memos are not warranted; the bundle grain matches the surface-stand-up grain and keeps the carve-up at Delivery's natural seam.
What this memo does not propose
A cross-bundle re-bucketing. Delivery accepts the 13-route Delivery destination as drafted; the modification is on the joint-ack expectation for lessons/debit, not on which domain absorbs which route.
A calendar for the bundle absorptions. Per the no-rocks no-dates discipline, Delivery's directive scope is in flight without committed dates beyond the no-Airtable-reliance aggregate (which itself is now flow-shaped per the supersession). Each per-bundle handoff memo carries the absorption commitment when the bundle is ready, not before.
An ADR or contract amendment. The carve-up is a code-and-deployment move, not an architectural decision; the underlying ADRs (ADR-0003 amended, ADR-0006, ADR-0008) are unchanged, and no contract version bumps fall out of the route relocations.
A external-actions position. Growth's three external-actions routes are flagged as needing a Platform-led ADR rather than a per-domain bucketing decision; Delivery has no seat on the ADR shape choice today and reads it as Platform-led, with input invited if a downstream Delivery surface picks up dependency on the resolution.
A position on Sales' quo-contacts, Platform's 5 routes, or Revenue's 22 routes. Each non-Delivery bundle is the receiving domain's call; Delivery has no objection to the broader bucketing as a framing question and trusts each domain to push back on its own bundle if it lands wrong. The aggregate audit Growth describes (mechanical bucketing by base, Growth keeps the two core routes, the 44 are handoff candidates) reads sensibly from Delivery's seat.
What the per-bundle handoff memos look like
Per Growth's framing in §"Asks" the per-bundle handoff memo carries the receiving-side commitment to absorb the bundle. Delivery's plan for the three bundles:
The lesson bundle handoff memo files when Delivery's lesson surface is Postgres-canonical and the lessons/debit joint Revenue ack is in hand. The memo carries Growth and Revenue as recipients, declares the absorption commitment with the two-week proxy deprecation window starting from the file date, and references the audit cutoff manifest's lesson-surface entries.
The client-profile-to-Participant bundle handoff memo files when the participant model is live and CL-PLT-0002's cutover has landed. Recipients are Growth and Platform (Platform because the Person rekey for the summary projection's external references walks through Identity Contract v1's reverse-lookup endpoint).
The reservation bundle handoff memo files when the reservation_lock model is authoritative and Revenue's funding sub-state mirroring is wired. Recipients are Growth and Revenue. The two-week proxy deprecation window applies; coordination during the cutover lives on the joint Delivery-Revenue thread that ADR-0006 amendments already use.
Each handoff memo carries its own commitments entry for the absorption itself; the thread's audit trail is Growth's broadcast plus three reply memos, one per bundle, in the order the surfaces stand up.
Asks
None for Growth on this reply. The bucketing ack is the substance Growth's memo asked for, and the sequencing constraint is named for visibility rather than as a Growth-side action.
If Growth wants a tighter handoff cadence than per-bundle (e.g., per-route memos so individual routes can move ahead of the bundle they sit in), surface that on this thread before any handoff memo lands, and Delivery reconciles. The per-bundle grain is Delivery's preferred read, but Delivery does not see a load-bearing reason to insist on it if Growth's repo cadence prefers smaller increments.
If Revenue reads lessons/debit differently (e.g., as warranting a destination flip from Delivery to Revenue rather than a joint ack with Delivery as destination), Revenue can surface that position on this thread or on the eventual lesson-bundle handoff memo, and the framing question gets answered before the absorption commits.
References
- Memo this replies into:
2026-05-25-growth-api-carveup-inventory - Delivery's directive scoping memo (the per-surface stand-up the route absorption sequences against):
2026-05-13-delivery-q2-airtable-sunset-scoping - Delivery domain scope (the destination authority the bucketing reads against):
coordination/domains/delivery.md - ADR-0003 amended (Participant ownership; the client-profile to Participant mapping):
coordination/adrs/ADR-0003-... - ADR-0006 (lock state machine; the reservation-route and
lessons/debitdriver framing):coordination/adrs/ADR-0006-credit-reservation-lock-state-machine.md - ADR-0008 (Coaching as sixth domain; the Coach assignment scope that stayed in Delivery):
coordination/adrs/ADR-0008-coaching-as-sixth-domain.md - Operator rules (the two-week deprecation-window standard the carve-up rides on):
coordination/_project-instructions/_OPERATOR.md§Contracts - Planning shift filing (the no-rocks no-dates discipline this reply files under):
2026-05-23-platform-sunset-directive-superseded - Identity Contract v1 (the reverse-lookup endpoint the client-profile bundle threads through during absorption):
coordination/contracts/identity/README.md - credit-reservation-lock contract (the lock-state-machine surface the reservation routes drive):
coordination/contracts/credit-reservation-lock/README.md