f9e09b1757
Writes the 14 harvested mechanisms from FORK-ANALYSIS-2026-08-21.md into
the backend contracts. Each section is dated 2026-08-21 and tagged FH-*
so any wording traces back to why it is worded that way.
The through-line: several contracts stated correctness as behaviour
("the webhook must be idempotent"). Behaviour written as an if-statement
gets deleted by a refactor and the failure mode is a double charge. These
sections restate it as schema and mechanism.
PHASE-3 3.1 conditional-write reservation, 409 on zero rows, cart-wide
rollback, 15 min TTL
3.2 InventoryMovement append-only journal with resultingAvailable
6 bulk import idempotent by SKU, rollback while unsold
6a digital code pools, revealed only when paid
PHASE-7 5 unique constraints for payment idempotency and webhook
replay, insert-first handling, signature over raw body,
24h poll as reconciliation not primary
TRACK-S 2.1 session model - 32 bytes stored as SHA-256 only, HttpOnly,
one cookie per contour, Argon2id params, mandatory TOTP
2.2 origin allowlist ahead of routing on every cookie mutation
4.2 AES-256-GCM envelope for stored secrets, HMAC fingerprints
8a order manager as a separate contour, scoped by membership
rows rather than by configuration
PHASE-9 5.1 revision immutability, version = max+1, pointer flipped
in-transaction, operational state does not travel
5.2 clone carry / no-carry list, inventory to zero
5.3 signed read-only preview, non-GET 404s while previewing
6 host normalization, verifiedAt required, cache invalidation
PHASE-10 3a server re-runs the editor's validation, clamp-and-fallback
PHASE-2 3.1 order publicToken, snapshot completeness, never updated
FH-2.12 rejected on the merits: our marketplace lifecycle state machine
is richer than theirs, adopting it would be a downgrade. Recorded in the
TODO so it is not raised again.
Also adds BACKEND-HANDOFF.md sections 0 and 0a - nine falsifiable
invariants as a release gate, each cross-referenced to the contract that
specifies it, plus PR and release discipline. And ADR-0006 recording what
we take, what we reject, what we keep because ours is better, and the
organizational question it deliberately does not settle.
No implementation changes.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Backend Contracts Index — Product Plan v3.1
New here? Start with BACKEND-HANDOFF.md — reading order, current infrastructure state, auth surface, and what a working dev environment still needs.
Implementing tenant routing/nginx? TENANT-API-DOMAIN-HANDOFF.md is the final host normalization, CORS, TLS, reverse-proxy, CI-secret, and acceptance contract.
Want every endpoint in one place? FRONTEND-API-SURFACE-COMPLETE.md — the final handoff doc. Generated directly from source, all 90 endpoints the frontend currently calls plus 3 response-shape additions on existing endpoints, marked Specified / Inferred / Undocumented against the contracts below. Use it to see gaps across all contracts at once; use the individual Phase/Track docs for full entity shapes and invariants.
This directory is the complete set of wire contracts for building the backend behind Product Plan v3.1. Each doc specifies entities, endpoints, and invariants only — never DB schema or service boundaries, which stay backend's own call.
Read order matches build order. Every doc after Phase 1 depends on the ones before it (noted at the top of each). All Sprint 0.1 decisions referenced throughout were answered 2026-08-17 — see PRODUCT-PLAN-v3.1-DELIVERY-PLAN.md Sprint 0.1 for the full record.
Launch-gate phases (P0 — required before production)
| Doc | Covers | Status |
|---|---|---|
| PHASE-1-MONEY-FX-PAYMENTS-CONTRACT.md | Money model, FX quote, price snapshot, server-authoritative checkout amount, payment state machine | Ready |
| PHASE-2-ORDERS-NOTIFICATIONS-CONTRACT.md | Canonical Order/OrderLine/Fulfillment (unified multi-seller), event bus, Notification Center | Ready |
| PHASE-3-CATALOG-OFFER-FULFILLMENT-CONTRACT.md | Product/Offer split, inventory/reservations, publish-time executability | Ready |
| PHASE-4-CONNECTOR-FRAMEWORK-CONTRACT.md | Generic external-order connector framework (no fixed marketplace list) | Ready |
Post-launch-gate phases (P1/P2)
| Doc | Covers | Status |
|---|---|---|
| PHASE-5-SELLER-PORTAL-CONTRACT.md | Seller org/user/membership, seller-scoped order/fulfillment views | Ready |
| PHASE-6-CART-CHECKOUT-CONTRACT.md | Server-owned cart, checkout session | Ready |
| PHASE-7-PAYMENTS-RECONCILIATION-CONTRACT.md | Refunds, reconciliation, settlements | Ready |
| PHASE-8-IDENTITY-MESSAGING-CONTRACT.md | Customer identity, VK ID (built first), OTP, MAX/Telegram bots, Notification Orchestrator | Ready |
| PHASE-9-TENANT-REGISTRY-DOMAINS-CONTRACT.md | Marketplace registry, Hostinger DNS automation, publish/revision model | Ready |
| PHASE-10-CONTENT-MODULES-CONTRACT.md | Gorbushka-class mall/directory content entities | Ready, lowest priority |
Cross-cutting tracks
| Doc | Covers | Status |
|---|---|---|
| TRACK-A-ANALYTICS-CONTRACT.md | Event pipeline, funnel, operational/quality metrics, synthetic-traffic separation | Ready — start alongside Phase 1, longest lead time |
| TRACK-S-SECURITY-RBAC-CONTRACT.md | 17 roles/3 scopes, enforcement, audit log, secrets, rate limiting, step-up auth | Ready — gates the launch |
| PARTNER-PROVISIONING-API-CONTRACT.md | Inbound partner API: merchant hierarchy provisioning, idempotency, public-key credentials, payment routing context | Draft — mapping decided, needs Company/Project entities |
What is deliberately not in this directory
- API namespace migration — Sprint 0.1 decision: new endpoints only use
/api/v2/...etc; legacy endpoints (/cart,/orders,/items) are not being migrated as part of this contract set. SeeBACKEND-API-REFERENCE.mdfor the current live surface. - Per-connector adapters (Ozon, Wildberries, etc.) — Sprint 0.1 decision: no fixed list. Phase 4 §8 is the onboarding runbook; each partner's adapter is written when that partner is actually onboarded.
- Additional payment providers (wallets, BNPL) — open business decision, not yet made. Phase 7 §4.
One open item across all of these
Backend ownership — answered 2026-08-18. A separate backend developer implements against these contracts. This repository's team owns the frontend and owns this contract set — the docs here are the handoff surface between the two, so a change to any contract is a change both sides must see. Keep them current; they are not a one-time deliverable.