docs/BACKEND_API.md no longer exists as a live file (merged into
BACKEND.md in an earlier consolidation pass, per that doc's own intro
- only docs/archive/BACKEND_API.md remains, historical only). This
mission's "update BACKEND_API.md" instruction is fulfilled by
extending the doc that actually supersedes it: new §11 "Seller
Management (Optional Capability)", added to the top-of-file table of
contents, no existing section renumbered or altered.
Every subsection explicitly tagged Implemented / Planned / Future,
matching the same legend used in docs/architecture/foundation/
Seller-Management.md (the frontend-side capability doc this section
is the backend counterpart to):
- 11.2 Future entities: Marketplace (Implemented, existing
TenantConfig unchanged), Seller/SellerBranding (Planned - frontend
types exist, no backend schema), SellerUser/SellerSettings/
SellerInvitation (Future - no type, no concept, named for roadmap
completeness only).
- 11.3 Future endpoints: Seller CRUD/Activation/Invitations/Branding/
Analytics/Dashboard - all Future, none designed, each noted as
following the existing mock-to-API-gateway pattern (SS8) once built.
- 11.4 Authentication: SellerPermissionRole (4 roles) explicitly
flagged as a separate vocabulary from the existing, live AdminRole -
not merged, no guard wired, zero auth change.
- 11.5 Domain resolution: market.com -> Marketplace is Implemented
today (ADR-001, backend-Host-resolved); nike.market.com -> Marketplace
-> Seller is Future, no backend resolves it - and per the storefront
audit, needs no frontend routing change once it does.
- 11.6 Bootstrap additions: modules/modules.sellerManagement documented
as Implemented-as-contract (typed, always false/absent today);
sellerScope/sellerBranding as Planned with an explicitly flagged open
question (SellerConfig vs SellerBranding nesting not reconciled);
permissions noted as existing/unrelated today.
- 11.7 Checkout modes: Unified Order vs Split Orders - Future, not
designed, flagged as the single most consequential undecided item
for backend design given payments/refunds/reporting all depend on it.
- 11.8 Product ownership: sellerId? on Item/AdminProduct/AdminOrder -
Implemented as schema only (optional, absent = marketplace-owned,
verified backward-compatible via tsc staying clean). Existing
products remain valid with no migration required - NULL/absent
ownership documented as a permanent state, not transitional.
No backend implemented. No frontend code touched. Documentation only.
fa6e5cd68b