[Product SDK][P1] Prove Product host compatibility before integration

[knzeng-e]

Goal

Make Dotify a first-class Polkadot Product that runs inside the Polkadot Triangle (Polkadot App, Desktop, and Web) through the Product SDK / TrUAPI boundary, while preserving a standalone web build for ordinary browser access.

Why

The current app talks directly to EVM/Substrate RPCs, injected wallets, IPFS gateways, the backend API, and Socket.IO. A sandboxed Polkadot Product must instead use Host-mediated capabilities for chain access, signing, storage, local persistence, permissions, and allowed outbound requests.

Architecture

Introduce a platform adapter boundary:

• platform/domain: product-neutral use cases and types;
• platform/standalone-web: current browser/RPC/wallet adapters;
• platform/polkadot-product: Product SDK adapters for chain-client, signer, cloud-storage, statement-store, local-storage, host detection and permissions;
• shared React UI consuming interfaces rather than concrete providers.

Scope

• Add host detection and capability negotiation.
• Add a Product manifest with least-privilege permissions.
• Route chain reads through @parity/product-sdk-chain-client in Product mode.
• Route signing/submission through @parity/product-sdk-signer / transaction helpers.
• Route Bulletin uploads through cloud-storage where available.
• Route local preferences and cached state through Product local-storage.
• Declare narrow ExternalRequest permissions for the Dotify API, media gateway, signaling/TURN/SFU endpoints.
• Keep a standalone web adapter for users outside the Triangle.
• Pin SDK versions and add a compatibility matrix for Desktop, Web, mobile App, and standalone browser.
• Add smoke tests against Polkadot Desktop and Polkadot Web.

Acceptance criteria

• The same Dotify UI runs in standalone web and Product modes.
• Product mode performs no direct wallet-key access and no undeclared network egress.
• Account derivation and transaction approval are Host-mediated.
• Missing Host capabilities degrade explicitly rather than silently falling back.
• Manifest permissions are minimal, documented, and user-readable.
• A .dot deployment can be loaded by Desktop and Web.
• SDK/TrUAPI versions are pinned and compatibility tests run in CI or a documented release gate.

Guardrail

Do not couple domain logic directly to experimental SDK APIs. TrUAPI/Product SDK are actively evolving; the adapter layer is the shock absorber.

[knzeng-e]

Backlog sync 2026-07-14: this is now a Product SDK feasibility epic, not an implementation ticket. Scope is split into SDK version/Host compatibility, Product account signing and resource allocation, PolkaVM/CDM contract portability, Playground/Bulletin/DotNS deployment, and Statement Store presence constraints. Standalone web remains first-class. Current source of truth: docs/backlog/polkadot-product-readiness-and-killer-dapp-roadmap.md.