docs: Track A/S contracts + backend index tying the full v3.1 contract set together
- Track A: analytics event pipeline (traffic/catalog/commerce/operational/
quality events), synthetic-traffic separation enforced server-side by
environment/token, never a client-settable flag.
- Track S: 17-role/3-scope RBAC enforcement, audit log, secrets, rate
limiting, step-up auth - closes this session's most serious finding
(admin role model is decorative today, any authenticated admin has
full access regardless of assigned role).
- docs/backend/README.md: index of all 12 contract docs (Phases 1-10 +
2 tracks) in build order, plus what's deliberately excluded (namespace
migration, per-connector adapters, extra payment providers) and the
one thing still genuinely open across all of them - backend ownership.
- Cross-linked from BACKEND-API-REFERENCE.md and the delivery plan so the
index is discoverable from either entry point.
This closes out documentation for every phase/track in
PRODUCT-PLAN-v3.1-DELIVERY-PLAN.md that doesn't require a further business
decision. Nothing left undocumented on our side pending only implementation
and backend-ownership assignment.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-17 23:09:04 +04:00
# Backend Contracts Index — Product Plan v3.1
docs: backend handoff, package usage guide, finalized CI/CD
- docs/backend/BACKEND-HANDOFF.md: single entry point for a backend dev -
reading order, verified infrastructure state (nginx running, Postgres
inactive, no API on :8080, no TLS, no DNS automation, no CI runner),
auth surface, and the day-one setup that is still outstanding
- docs/PACKAGES-USAGE.md: install, required DI providers, full exported
API for both auth mechanisms, and how to ship a package change
- PACKAGE-EXTRACTION.md now covers build/release/infra only and points at
the usage guide; CI section reflects the two real workflows
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-18 01:46:58 +04:00
> **New here? Start with [BACKEND-HANDOFF.md](BACKEND-HANDOFF.md)** — reading order, current infrastructure state, auth surface, and what a working dev environment still needs.
docs: master API surface list, all 86 frontend endpoints in one doc
Generated directly from source (every this.http.get/post/patch/put/delete
call across core/, features/admin/, api.service.ts) rather than written
from memory - a census, not a design doc.
47 already match an existing Phase/Track contract exactly. 24 are inferred
from this codebase's own REST conventions with no contract doc stating them
- each flagged in source at its call site, not just in this doc, so backend
sees the reasoning next to the code. 15 are legacy endpoints
(/category, /cart, /qr, /websession, ...) with no contract anywhere,
still live today.
Biggest concrete gap surfaced: three full admin domains (transactions,
monitoring, moderation) have real UI and real gateways calling
/api/admin/v2/{resource} by convention, with zero backend contract written
for any of them.
One real bug found and fixed while building this, not just flagged:
connector-api.gateway.ts's replay() called
POST /api/admin/v2/integrations/dead-letter/{id}/replay, omitting the
{connectorId} segment the contract's own path requires
(PHASE-4-CONNECTOR-FRAMEWORK-CONTRACT.md §7). Fixed the interface, both
gateway implementations, and the doc entry in the same pass - no callers
existed yet, so this shipped without ever being exercised by a UI.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 21:08:05 +04:00
>
> **Want every endpoint in one place? [FRONTEND-API-SURFACE-COMPLETE.md](FRONTEND-API-SURFACE-COMPLETE.md)** — generated directly from source, all 86 endpoints the frontend currently calls, 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.
docs: backend handoff, package usage guide, finalized CI/CD
- docs/backend/BACKEND-HANDOFF.md: single entry point for a backend dev -
reading order, verified infrastructure state (nginx running, Postgres
inactive, no API on :8080, no TLS, no DNS automation, no CI runner),
auth surface, and the day-one setup that is still outstanding
- docs/PACKAGES-USAGE.md: install, required DI providers, full exported
API for both auth mechanisms, and how to ship a package change
- PACKAGE-EXTRACTION.md now covers build/release/infra only and points at
the usage guide; CI section reflects the two real workflows
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-18 01:46:58 +04:00
docs: Track A/S contracts + backend index tying the full v3.1 contract set together
- Track A: analytics event pipeline (traffic/catalog/commerce/operational/
quality events), synthetic-traffic separation enforced server-side by
environment/token, never a client-settable flag.
- Track S: 17-role/3-scope RBAC enforcement, audit log, secrets, rate
limiting, step-up auth - closes this session's most serious finding
(admin role model is decorative today, any authenticated admin has
full access regardless of assigned role).
- docs/backend/README.md: index of all 12 contract docs (Phases 1-10 +
2 tracks) in build order, plus what's deliberately excluded (namespace
migration, per-connector adapters, extra payment providers) and the
one thing still genuinely open across all of them - backend ownership.
- Cross-linked from BACKEND-API-REFERENCE.md and the delivery plan so the
index is discoverable from either entry point.
This closes out documentation for every phase/track in
PRODUCT-PLAN-v3.1-DELIVERY-PLAN.md that doesn't require a further business
decision. Nothing left undocumented on our side pending only implementation
and backend-ownership assignment.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-17 23:09:04 +04:00
This directory is the complete set of wire contracts for building the backend behind [Product Plan v3.1 ](../PRODUCT-PLAN-v3.1-GAP-ANALYSIS.md ). 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 ](../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 ](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 ](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 ](PHASE-3-CATALOG-OFFER-FULFILLMENT-CONTRACT.md ) | Product/Offer split, inventory/reservations, publish-time executability | Ready |
| [PHASE-4-CONNECTOR-FRAMEWORK-CONTRACT.md ](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 ](PHASE-5-SELLER-PORTAL-CONTRACT.md ) | Seller org/user/membership, seller-scoped order/fulfillment views | Ready |
| [PHASE-6-CART-CHECKOUT-CONTRACT.md ](PHASE-6-CART-CHECKOUT-CONTRACT.md ) | Server-owned cart, checkout session | Ready |
| [PHASE-7-PAYMENTS-RECONCILIATION-CONTRACT.md ](PHASE-7-PAYMENTS-RECONCILIATION-CONTRACT.md ) | Refunds, reconciliation, settlements | Ready |
| [PHASE-8-IDENTITY-MESSAGING-CONTRACT.md ](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 ](PHASE-9-TENANT-REGISTRY-DOMAINS-CONTRACT.md ) | Marketplace registry, Hostinger DNS automation, publish/revision model | Ready |
| [PHASE-10-CONTENT-MODULES-CONTRACT.md ](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 ](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 ](TRACK-S-SECURITY-RBAC-CONTRACT.md ) | 17 roles/3 scopes, enforcement, audit log, secrets, rate limiting, step-up auth | Ready — gates the launch |
docs: partner provisioning API contract, routing context, Track P
A partner integration request landed for programmatic merchant-hierarchy
management (Company/Project/Store/PaymentPoint). Built the answer generically:
partner-specific behaviour is a PartnerProfile config row, and no partner name
appears in any entity, field, endpoint or status value.
New:
- docs/backend/PARTNER-PROVISIONING-API-CONTRACT.md - hierarchy, idempotency,
node-scoped public-key credentials, TEST/LIVE partition, routing context
- docs/context/adrs/ADR-0003-generic-partner-provisioning-api.md
Amended, because the schema impact must land before Phase 1 is implemented:
- Phase 1 gains RoutingContext on CheckoutSession/PaymentIntent/Payment,
frozen at checkout-session creation and immutable after
- Phase 7 gains routing on Refund/ReconciliationRecord, plus the rule that
seller settlement splits happen after routing, never as a hierarchy level
- Phase 9 gains Company/Project above Marketplace and PaymentPoint below it,
with a backfill sequence for existing marketplaces
- Track S gains partner credentials: public key only, node-scoped authority,
rotation with overlap, immediate revoke, audit coverage
Also: Track P (P1-P10) in the delivery plan, and backend ownership closed as
answered across the contract set.
Card payment was checked, not added - qr and card both already ship in
cart.component.ts with separate create paths and status pollers.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 11:22:24 +04:00
| [PARTNER-PROVISIONING-API-CONTRACT.md ](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 |
docs: Track A/S contracts + backend index tying the full v3.1 contract set together
- Track A: analytics event pipeline (traffic/catalog/commerce/operational/
quality events), synthetic-traffic separation enforced server-side by
environment/token, never a client-settable flag.
- Track S: 17-role/3-scope RBAC enforcement, audit log, secrets, rate
limiting, step-up auth - closes this session's most serious finding
(admin role model is decorative today, any authenticated admin has
full access regardless of assigned role).
- docs/backend/README.md: index of all 12 contract docs (Phases 1-10 +
2 tracks) in build order, plus what's deliberately excluded (namespace
migration, per-connector adapters, extra payment providers) and the
one thing still genuinely open across all of them - backend ownership.
- Cross-linked from BACKEND-API-REFERENCE.md and the delivery plan so the
index is discoverable from either entry point.
This closes out documentation for every phase/track in
PRODUCT-PLAN-v3.1-DELIVERY-PLAN.md that doesn't require a further business
decision. Nothing left undocumented on our side pending only implementation
and backend-ownership assignment.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
2026-08-17 23:09:04 +04:00
## 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. See `BACKEND-API-REFERENCE.md` for the current live surface.
- **Per-connector adapters** (Ozon, Wildberries, etc.) — Sprint 0.1 decision: no fixed list. [Phase 4 ](PHASE-4-CONNECTOR-FRAMEWORK-CONTRACT.md ) §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 ](PHASE-7-PAYMENTS-RECONCILIATION-CONTRACT.md ) §4.
## One open item across all of these
docs: partner provisioning API contract, routing context, Track P
A partner integration request landed for programmatic merchant-hierarchy
management (Company/Project/Store/PaymentPoint). Built the answer generically:
partner-specific behaviour is a PartnerProfile config row, and no partner name
appears in any entity, field, endpoint or status value.
New:
- docs/backend/PARTNER-PROVISIONING-API-CONTRACT.md - hierarchy, idempotency,
node-scoped public-key credentials, TEST/LIVE partition, routing context
- docs/context/adrs/ADR-0003-generic-partner-provisioning-api.md
Amended, because the schema impact must land before Phase 1 is implemented:
- Phase 1 gains RoutingContext on CheckoutSession/PaymentIntent/Payment,
frozen at checkout-session creation and immutable after
- Phase 7 gains routing on Refund/ReconciliationRecord, plus the rule that
seller settlement splits happen after routing, never as a hierarchy level
- Phase 9 gains Company/Project above Marketplace and PaymentPoint below it,
with a backfill sequence for existing marketplaces
- Track S gains partner credentials: public key only, node-scoped authority,
rotation with overlap, immediate revoke, audit coverage
Also: Track P (P1-P10) in the delivery plan, and backend ownership closed as
answered across the contract set.
Card payment was checked, not added - qr and card both already ship in
cart.component.ts with separate create paths and status pollers.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 11:22:24 +04:00
**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.