docs: record Sprint 0.1 decisions across delivery plan, gap analysis, backend contract

User answered 8 of 9 Sprint 0.1 blocking decisions (2026-08-17); backend
ownership stays open pending a clearer re-ask. Recorded and propagated:

- Payment chain unfrozen -> BACKEND-API-REFERENCE.md §7 and the Phase 1
  contract doc's status banner both updated; Phase 1/6/7 unblocked.
- No fixed external-marketplace list -> Phase 4's connector framework
  respecified as config-driven/generic; Sprint 4.2 retired as "per named
  marketplace," replaced with a generic onboarding runbook.
- FX rate source: ours, in-house, as the default (not just a fallback) ->
  Phase 1 contract's `source` field can read "internal" as the normal case.
- VK ID before OTP -> Phase 8 sprints resequenced (VK ID now 8.2, OTP 8.3).
- Multi-seller orders: unified -> Phase 3.3, Phase 5.2, and Z16 updated to
  the resolved model (one Order, per-seller Fulfillment groups).
- "Fixed 5-second payment" claim: confirmed non-issue, PAYMENT_POLL_INTERVAL_MS
  is already 5000 (real polling cadence, not an artificial delay).
- API namespace: new endpoints only (/api/v2/...), no forced migration of
  legacy endpoints.
- Document version: v3.1 is canonical.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

docs/PRODUCT-PLAN-v3.1-GAP-ANALYSIS.md

@@ -251,17 +251,19 @@ Not gaps — assets and risks they should know about before sequencing:
 
 ---
 
-## 6. Decisions we need from them before estimating
+## 6. Decisions — answered 2026-08-17
 
-1. **Who owns the backend?** The plan assumes Platform API, Workers, Integration Hub and Domain Automation exist or will be built. None do. Same team, or a service team we integrate with?
-2. **Is the payment chain unfrozen?** P0-A/P0-C are unbuildable otherwise.
-3. **Which external marketplaces**, by name, for §5 connectors?
-4. **Which FX rate source?** The plan says "configurable external source"; our earlier ask named Rapira as a candidate. Also: does the backend return converted prices, or serve rates for the client to apply? The plan implies the former.
-5. **§14 vs. our approved email/phone OTP spec** — build VK ID first, or finish OTP first?
-6. **Multi-seller orders: unified or split?** Undecided in three of our own documents; the plan requires cart-level seller grouping (§2.5) but never resolves the order-splitting question.
-7. **Where does the "fixed 5-second payment" (§3.2) come from?** We cannot reproduce it in this codebase.
-8. **API namespace migration (§9.3)** — do it now, before new endpoints, or accept two conventions?
-9. **Document version** — the file is v3.1 but the version block says 3.0. Which is canonical for change tracking?
+See [PRODUCT-PLAN-v3.1-DELIVERY-PLAN.md](PRODUCT-PLAN-v3.1-DELIVERY-PLAN.md) Sprint 0.1 for the full record and downstream consequences. Summary:
+
+1. **Backend ownership — still open.** First-pass question wasn't understood; needs re-asking in plain terms before Phase 1 implementation (not just contract-writing) starts.
+2. **Payment chain — unfrozen. Yes.** Phases 1, 6, 7 proceed.
+3. **External marketplaces — no fixed list.** Connectors onboard partners as they arrive; build the Phase 4 framework config-driven/generic, not per-named-provider.
+4. **FX rate source — ours, in-house, as a safety gate.** No external provider committed; backend computes FX authoritatively until/unless one is chosen later.
+5. **§14 vs. OTP — VK ID first, then everything else** ("do all after vk"). Phase 8 resequenced.
+6. **Multi-seller orders — unified.** One `Order` per checkout, seller-scoped `Fulfillment` groups internally. Resolves the three-document disagreement.
+7. **"Fixed 5-second payment" — resolved as a non-issue.** `PAYMENT_POLL_INTERVAL_MS` is already `5000` — that's poll cadence against real provider status, not an artificial delay. Confirmed compliant, no change needed.
+8. **API namespace — new endpoints only, no forced migration.** `/api/v2/...` used for all new Phase 1+ contracts; legacy endpoints stay as-is pending a dedicated migration sprint.
+9. **Document version — v3.1 is canonical.** The source PDF's internal "3.0" version block is stale.
 
 ---