Wire the Product CDM manifest and contract resolver

.gitignore

@@ -8,11 +8,14 @@ dist/
 .playwright*
 !.env.example
 !web/.env.example
+!web/.env.product-devnet
 !contracts/evm/.env.example
 
 web/node_modules/
 web/dist/
 web/dist-bulletin*
+web/dist-product/
+web/*.car
 web/.playwright*
 web/playwright-report/
 web/test-results/

README.md

@@ -34,20 +34,28 @@ aura lights the whole field (`web/src/styles/aura.css`).
 creates one personal `SmartRuntime` per artist, and `ArtistDirectory` indexes
 artist addresses to their runtimes.
 
-**Frontend**: Static React + Vite web app deployed to dot.li.
+**Frontend**: Static React + Vite web app deployed to Netlify and, through the
+Product profile, Bulletin/DotNS at `dotify-test01.dot`.
 
 **WebRTC**: real-time music streaming.
 
 **Socket.IO**: signaling for room discovery and SDP/ICE exchange. A future
 iteration can move signaling to statement-store style infrastructure.
 
-**Product SDK direction**: Dotify remains a standalone web app first. Product
-SDK / Playground / Humanity work is a progressive-enhancement track documented
-in
-[`docs/backlog/polkadot-product-readiness-and-killer-dapp-roadmap.md`](docs/backlog/polkadot-product-readiness-and-killer-dapp-roadmap.md).
-The current SDK snapshot is prototype/reference/unaudited and must be proven
-against Dotify's Host, key-delivery, room, and contract constraints before it
-becomes a production dependency.
+**Product SDK direction**: Dotify now has an adaptive Product DevNet build for
+`dotify-test01.dot`. It keeps standalone link-first rooms and Free listening intact,
+adds explicit app-scoped Product identity, and publishes through
+Bulletin/DotNS. The runtime hooks now sit behind typed ports with the current
+viem implementation and an experimental Product CDM/PAPI adapter boundary.
+The backend key-delivery protocol now has an explicit Product sr25519
+signature scheme that binds the Product account public key to the derived H160
+requester before access checks. The Product frontend can now submit that
+Product proof after explicit host-account connection; contract writes remain
+passkey/EVM until CDM-installed runtime packages and host-signed transaction
+evidence are proven. See
+[`docs/explanation/product-devnet-architecture.md`](docs/explanation/product-devnet-architecture.md)
+and the
+[`Product roadmap`](docs/backlog/polkadot-product-readiness-and-killer-dapp-roadmap.md).
 
 ## Deployed
 
@@ -69,7 +77,7 @@ becomes a production dependency.
 
 **Gateway URL** — <https://paseo-ipfs.polkadot.io/ipfs/bafkr4ibynaanfrddyjgpmut2qrcu6vdttocbp4feyw6vkgxkkhqndjksny>
 
-**DotNS name** — `dotify.dot.li`
+**DotNS name** — `dotify-test01.dev-dot.li`
 
 ## How to run end-to-end (locally)
 
@@ -118,7 +126,8 @@ npm run dev
 
 | Variable                    | Required         | Purpose                                                  |
 | --------------------------- | ---------------- | -------------------------------------------------------- |
-| `API_ORIGIN`                | Production       | Frontend origin allowed by API CORS                      |
+| `API_ORIGIN`                | Compatibility    | Singular frontend CORS origin fallback                   |
+| `API_ORIGINS`               | Production       | Comma-separated exact frontend CORS origins              |
 | `PASEO_ASSET_HUB_RPC`       | Key requests     | Paseo Asset Hub EVM RPC used for access checks           |
 | `DOTIFY_DIRECTORY_ADDRESS`  | Key requests     | ArtistDirectory address used to resolve artist runtimes  |
 | `DOTIFY_CHAIN_ID`           | Key requests     | Chain ID expected in wallet-signed key requests          |
@@ -298,6 +307,10 @@ releasing it. Gated tracks use a signed session or signed key request; the
 backend verifies the requester, resolves the artist runtime, and calls
 `musicAccCanAccess` before releasing a per-track key. If access is denied, the
 UI shows the action needed to unlock the track and plays no protected audio.
+Standalone clients sign with the default `eip191` scheme. Product-host clients
+can use `product-sr25519-v1` by signing the same canonical Dotify message bytes
+with the app-scoped Product account and sending `productPublicKey`; the backend
+derives the H160 requester from that public key before any nonce is consumed.
 
 For registered artist tracks, users without a connected wallet can play Free
 tracks. For gated tracks, they see a sign-in/unlock gate. Dev-account fallback
@@ -430,9 +443,9 @@ handle:
    and decide whether a backend read-through gateway is needed.
 4. Keep demo-mode browser-exposed Pinata/content secrets out of public
    deployments.
-5. Run Product SDK feasibility spikes: Host detection, Product account signing,
-   resource allocation, Playground/Bulletin/DotNS deployment, and PolkaVM/CDM
-   contract portability.
+5. Validate the Product host/account and Bulletin/DotNS deployment baseline,
+   then wire frontend Product-signed key/session requests, resource allocation,
+   and PolkaVM/CDM contract portability.
 6. Add a production artist dashboard on `/artists`: release drafts, edit
    metadata, royalty analytics, and profile verification state.
 7. Deploy and monitor a public signaling server for DotNS / Bulletin builds.

docs/README.md

@@ -15,6 +15,7 @@ Conceptual documents that help you understand why Dotify works the way it does.
 | [Content Protection](./explanation/content-protection.md) | All | Audio encryption pipeline, what it protects, and what it does not |
 | [Royalty Settlement](./explanation/royalty-settlement.md) | All | How DOT payments flow from listener wallet to artist wallet |
 | [Listening Rooms](./explanation/listening-rooms.md) | All | WebRTC peer-to-peer streaming, signaling protocol, known limitations |
+| [Product DevNet Architecture](./explanation/product-devnet-architecture.md) | Maintainers | Dual-host boundaries, Product account capabilities, rooms, storage, and the proposed contract port |
 
 ---
 
@@ -40,6 +41,7 @@ Runbooks for hosted configuration and production validation.
 | Document | Summary |
 |---|---|
 | [Deployment Configuration](./operations/deployment-configuration.md) | Netlify and Fly dashboard settings, secrets, catalog persistence, validation, and the update checklist for future env/config changes |
+| [Product DevNet Deployment](./operations/product-devnet-deployment.md) | Build, publish, validate, and roll back the `dotify-test01.dot` Product DevNet app |
 
 ---
 

docs/backlog/24-access-streaming-v2.md

@@ -139,12 +139,14 @@ P3 first vertical slice delivered (`agent/audio-v2-p3`):
   the browser/device validation matrix, startup telemetry export, and the
   backend read-through gateway decision.
 
-Product SDK replanning note (2026-07-14):
+Product SDK adaptation note (2026-07-26):
 
-- Product SDK (`@parity/product-sdk` 0.17.0 at
-  `2f359bba28ca72855207a0a519d4118b37b4438c`) is prototype/reference/unaudited.
+- Product SDK 0.19.1 and deploy tooling 0.13.1 remain
+  prototype/reference/unaudited.
 - Host APIs are progressive enhancement for Product containers; standalone web
   remains a supported mode.
+- Host detection, explicit Product account identity, a Product DevNet build,
+  canonical room links, and dual-origin Fly configuration are implemented.
 - Product SDK contracts use `pallet-revive`, PolkaVM artifacts, and CDM
   manifests. Dotify's current Hardhat + viem + Paseo Asset Hub EVM path needs a
   portability spike before adopting that layer.

docs/backlog/README.md

@@ -104,18 +104,22 @@ ticket 18 preview assets are consciously retired by access model v2.
 `improvement-plan.md` tracks the July 2026 review of the implementation
 against the product/technical/philosophical memory and the current Parity
 Product SDK direction. The plan is now dual-mode: standalone web remains the
-first public listening path, while Product SDK / Playground / Humanity
-integration is a gated feasibility track. Nothing in that track may imply live
-Host, Statement Store, Product account, Humanity, or `.dot` deployment support
-until the relevant spike proves the current API, environment, and security
-boundary.
+first public listening path, while the Product DevNet build adds
+`dotify-test01.dot`,
+explicit Host detection, app-scoped Product identity, and canonical
+Product-origin room links. The typed runtime ports and experimental
+Product CDM/PAPI adapter boundary are implementation preparation only; they do
+not imply Product-signed contract writes, Statement Store rooms, or Humanity
+decisions. API-side Product-signed key/session verification now exists through
+`product-sr25519-v1`, but the Product frontend still needs to send host-signed
+requests before protected playback can use that identity path.
 
 The Product SDK evidence snapshot used for this replanning is
-`paritytech/product-sdk@2f359bba28ca72855207a0a519d4118b37b4438c`
-(`@parity/product-sdk` 0.17.0), fetched on 2026-07-14. It is explicitly
-prototype / reference / unaudited code. Paseo and Summit are the live preset
-environments; Product SDK contracts target `pallet-revive` / PolkaVM CDM flows,
-not Dotify's current viem + EVM RPC path; Statement Store is useful for small
+`@parity/product-sdk` 0.19.1 and
+`@polkadot-community-foundation/polkadot-app-deploy` 0.13.1,
+verified on 2026-07-26. They remain prototype / reference / unaudited code.
+Product SDK contracts target `pallet-revive` / PolkaVM CDM flows, not Dotify's
+current viem + EVM RPC write path; Statement Store is useful for small
 ephemeral presence, not full chat, SDP/ICE, durable media metadata, or guest
 reactions.
 
@@ -160,9 +164,10 @@ on `main`. The remaining order is:
    signaling and production-env evidence are closed through #36/#37.
 3. Improve room resilience and shared-listening depth only where it preserves
    the link-first guest doctrine.
-4. Run Product SDK feasibility spikes: Host capability detection, Product
-   account signing, resource allocation, PolkaVM/CDM contract portability,
-   Playground/Bulletin/DotNS deployment, and Statement Store presence.
+4. Validate the delivered Product host/account and Bulletin/DotNS baseline,
+   then wire real CDM-installed runtime packages through the Product CDM/PAPI
+   adapter, wire frontend Product-signed key/session requests, and run bounded
+   resource-allocation/Statement Store spikes.
 5. Build live Humanity / Individuality only after the research ticket proves a
    privacy-preserving source, proof shape, address-binding story, and fallback
    UX.

docs/backlog/improvement-plan.md

@@ -62,25 +62,24 @@ Where it falls short of its own standards:
 
 ## Product SDK feasibility track
 
-This track runs in parallel with standalone hardening, but it does not block
-first sound and must not be sold as a delivered capability.
+This track runs in parallel with standalone hardening and does not block first
+sound. Only the baseline rows marked delivered may be presented as live.
 
 Product SDK snapshot used for this plan:
 
-- `paritytech/product-sdk@2f359bba28ca72855207a0a519d4118b37b4438c`
-  (fetched 2026-07-14);
-- `@parity/product-sdk` 0.17.0;
+- `@parity/product-sdk` 0.19.1 (verified 2026-07-26);
+- `@polkadot-community-foundation/polkadot-app-deploy` 0.13.1;
 - explicit prototype / reference / unaudited status;
-- live preset environments: Paseo and Summit;
+- Product target: DevNet Asset Hub / People / Bulletin;
 - contracts package: `pallet-revive`, PolkaVM artifacts, and CDM manifests;
 - Statement Store: 512-byte statement payload, 1024-byte user total, default
   30-second TTL.
 
 | Item | Tracking | Status |
 | --- | --- | --- |
-| Product SDK baseline: pin SDK versions, document compatible Host surfaces, and add feature detection for Host local storage, signing, permissions, resource allocation, payments, and chain support. | #85, `polkadot-product-readiness-and-killer-dapp-roadmap.md` | Proposed |
+| Product SDK baseline: pin SDK versions, detect Host availability, connect an app-scoped account explicitly, and separate presence identity from EVM signing authority. | #85, `polkadot-product-readiness-and-killer-dapp-roadmap.md` | Delivered on Product adaptation branch |
 | Contract portability spike: compare Dotify's current Paseo Asset Hub EVM / viem / Hardhat flow with Product SDK contracts on `pallet-revive`, PolkaVM artifacts, and CDM manifests. | #85 | Proposed |
-| Playground deployment spike: determine whether Dotify's static build can use Playground/Bulletin/DotNS deploy flows without weakening current secret and publication boundaries. | #85 | Proposed |
+| Product deployment baseline: build a browser-safe multi-file bundle, publish through Bulletin/DotNS tooling, preserve backend key custody, and use a canonical public room URL. | #85 | Delivered on Product adaptation branch; live publication pending operator credentials |
 | Statement Store presence spike: use it for small, signed, ephemeral discovery/presence only. Do not move SDP/ICE, full chat history, media metadata, or link-only guest reactions there until signer, TTL, and size constraints are solved. | #89, `20-room-social-layer.md`, `21-room-collaborative-queue.md` | Proposed |
 | Humanity / Individuality research rewrite: prove the canonical live source, privacy-preserving proof shape, product-account/identity-account binding, and fallback UX before promoting Human free from research to build. | #12, `11-proof-of-personhood-integration-research.md` | Open |