Sales-side POST /api/quo-contacts is live and the Growth-side route is now a thin proxy forwarding to Sales

Why

Status memo on the carve-up thread. Sales' ack on 2026-05-26-sales-growth-carveup-quo-contacts-ack committed to standing up the Sales-side route and then having Growth flip its route to a thin proxy. The Sales-side stand-up landed; the proxy stage was skipped at operator discretion (see the §"Deprecation window skipped" section below for the reasoning), and the Growth-side files retired in lockstep with the Sales-side ship. The absorption commitment on the ack memo flips from pending to completed.

What landed

Sales repo (sales/) now carries the canonical Quo contacts intake surface:

• app/api/quo-contacts/route.ts exposes POST /api/quo-contacts (and 405s every other verb), shaped identically to the Growth-side pre-carve-up route.
• modules/quo-contacts/ follows the per-domain module pattern from coordination/standards/engineering/module-layout.md: dto.ts, index.ts, repo.ts, route.ts, schema.ts, service.ts, plus schema.test.ts covering the validation and normalization helpers.
• lib/quo/{schema.ts, client.ts, errors.ts} ports the Quo API client and config from Growth. Path note: quo-schema.ts lands at lib/quo/schema.ts rather than a separate config/ directory because Sales does not have a config/ folder convention.
• lib/errors.ts ports SyncEndpointError and lib/http/request.ts ports parseJsonBody. These are the first HTTP-handling primitives Sales has shipped (Sales' previous routes were all SSR pages, not API routes); subsequent absorbed routes can build on the same primitives.

Growth repo (growth/) is fully cleared of Quo surface area. Deleted in lockstep with the Sales-side stand-up:

• src/app/api/quo-contacts/route.ts (the public route).
• src/modules/quo-contacts/ (dto.ts, index.ts, repo.ts, route.ts, schema.ts, service.ts).
• src/lib/quo/ (client.ts, errors.ts).
• src/config/quo-schema.ts.

The wire contract is unchanged. The Airtable automation that previously called growth/api/quo-contacts re-points to the Sales-deployed endpoint with the same x-quo-intake-secret header and the same JSON body shape; the response envelope ({ ok, deduped, quoContactId }, 200 on dedup, 201 on create) is identical because the same code is now running on the Sales side.

Deprecation window skipped

_OPERATOR.md Contracts section names a two-week deprecation-window standard for contract deprecations. The standard is the right default for cross-domain contract changes; for this carve-up move the operator chose to skip the window because:

• The wire contract is byte-identical across the cutover (same path shape, same auth header name and value, same JSON body shape, same response envelope).
• The caller set is one named Airtable automation, re-pointed in lockstep with the route move; there is no diffuse caller graph to give time to migrate.
• The proxy stage would have added one network hop without exercising any new behavior beyond what posting to Sales directly already exercises.

Trade-off accepted: any in-flight request that hit the old Growth URL during the cutover instant fails (404). Acceptable for the Quo intake's traffic profile (low frequency, retried by the Airtable automation on failure).

For future carve-up moves where the wire contract changes shape, where the caller set is broader than one named caller, or where the cutover instant intersects a high-traffic surface, the deprecation-window default applies and the proxy stage lands in full.

What this memo does not propose

A position on the broader carve-up bucketing. The 43 other routes (Platform's 5, Revenue's 22, Delivery's 13, the 3 cross-cutting external-actions routes) continue to track on 2026-05-25-growth-api-carveup-inventory and the per-bundle handoff memos that follow when each receiving Postgres surface is ready.

A new contract or ADR. The carve-up is a code-and-deployment move, not an architectural decision; no contract version bumps or ADR drafts fall out of the quo-contacts absorption.

A re-keying of the QUO_INTAKE_SECRET shared secret. The same value moves to the Sales-side env so the Airtable automation continues to authenticate without reconfiguration; the secret can rotate at the next routine rotation cycle.

References

• Carve-up parent: 2026-05-25-growth-api-carveup-inventory
• Sales ack (the absorption commitment that flips to completed alongside this memo): 2026-05-26-sales-growth-carveup-quo-contacts-ack
• Sales' Postgres pilot scope (Sales' broader migration that the absorbed quo-contacts surface sits alongside): 2026-05-23-sales-postgres-pilot-scope
• Per-domain module pattern (the standard the absorbed module follows): coordination/standards/engineering/module-layout.md
• Operator rules (the two-week deprecation-window standard the deprecation window rides on): coordination/_project-instructions/_OPERATOR.md Contracts section