Use native payment asset labels in UI

[knzeng-e]

Outcome

Dotify no longer displays hard-coded DOT labels across the Classic unlock and artist payment UI. Payment amounts now use the native runtime asset resolved from the connected EVM chain, so Product DevNet/Paseo surfaces display PAS while DOT-backed chains can display DOT.

Issue and context

Refs #85. PR #121 made Classic unlock intents explicitly carry the native runtime asset, but several user-facing components still rendered price strings as DOT. That was misleading on the current Product DevNet/Paseo rail, where the runtime-native token label is PAS.

This PR keeps the money boundary unchanged: pricePlanck remains the authoritative payment amount, Classic unlock still submits msg.value through RuntimeWritePort, and CASH remains unsupported until PCF/Product confirms a settlement receipt or bridge model.

Architecture and key concepts

The catalog hook already resolves nativeRuntimePaymentAsset from the connected chain. This PR exposes that asset through CatalogProvider consumers and threads the symbol into presentational surfaces that render Classic prices.

Runtime flow:

UI resolves EVM chain -> nativeRuntimePaymentAsset -> catalog/player/studio labels -> Classic payment intent -> RuntimeWritePort -> musicRoyPayAccess(contentHash) + msg.value.

No contract, backend, CORS, Fly, Netlify, or env setting changes are included.

How it works

• web/src/hooks/useCatalog.ts now returns nativeRuntimePaymentAsset.
• web/src/features/payments/paymentModel.ts adds nativeRuntimeAmountLabel for visible native amount strings.
• Catalog cards, artist profile cards, player access state, AccessGateOverlay, wallet/account views, and Artist Studio tabs use the resolved symbol.
• The Classic unlock e2e now expects PAS for the current Product DevNet/Paseo config.
• PR documentation now requires pre-PR dependency/SDK, improvement, and philosophical alignment checks.

Design decisions and tradeoffs

I did not rename priceDot or formatWeiAsDot in this PR. Those names are historical and wider than the display bug: they touch API shapes, track types, artist publish, mocks, and tests. The safer scope is to make visible labels honest now, then handle semantic renaming in a dedicated compatibility PR.

I did not update Product SDK dependencies here. The official npm snapshot shows drift and audit risk, but changing SDK/PAPI versions would materially broaden this UI-label PR.

Security, failure, and operations

Authoritative payment amount remains pricePlanck when available; display strings do not drive settlement. Unknown chain metadata falls back to the existing native asset fallback, and this PR does not introduce any frontend secrets or deployment configuration.

No deployment configuration update is required: no env vars, origins, Fly, Netlify, mounts, scaling, or runtime settings changed.

Review guide

Suggested order

1. web/src/features/payments/paymentModel.ts and paymentModel.test.ts: verify the display formatter is intentionally separate from amountPlanck settlement.
2. web/src/hooks/useCatalog.ts: verify the resolved asset is exposed without changing catalog loading or payment execution.
3. web/src/components/AccessGateOverlay.tsx and web/src/views/PlayerView.tsx: verify the unlock gate and player state use the resolved symbol.
4. web/src/views/ListenView.tsx, ArtistProfileView.tsx, YouView.tsx, WalletModal.tsx, and artist tabs: verify all user-facing Classic amount labels receive the symbol.
5. web/e2e/classic-unlock.spec.ts: verify the Product DevNet/Paseo e2e expectation is PAS.
6. docs and PR template: verify the new PR standard is clear and not over-broad.

Verify carefully

• No UI path still tells a Product DevNet user they are paying DOT for Classic unlock.
• pricePlanck remains authoritative and no payment amount is rebuilt from display labels.
• CASH remains non-executable and is not silently converted into native runtime payment.
• The new pre-PR checklist is visible in both docs and PR template.

Validation

Evidence	What it proves
npm view @parity/product-sdk version -> 0.23.0	Official SDK drift checked before PR; repo pins 0.20.1.
npm view @parity/product-sdk-host version -> 0.16.0	Host SDK drift checked; repo pins 0.15.1.
npm view @parity/product-sdk-statement-store version -> 0.6.5	Statement Store drift checked; repo pins 0.6.2.
npm view @polkadot-community-foundation/polkadot-app-deploy version -> 0.13.1	Deploy tool remains current with repo script.
npm view viem version -> 2.55.19	viem drift checked; repo uses ^2.53.1.
npm run test:unit -- paymentModel contracts	Payment formatter, chain metadata, and contract-adjacent unit coverage pass.
npm run build	TypeScript and standalone Vite production build pass.
npm run build:product-devnet	Product build passes; catalog bootstrap fetch failed and kept existing snapshot.
npm run lint	Passes with the existing 3 React Hook dependency warnings in App.tsx and ArtistShell.tsx.
npm run test:e2e -- e2e/classic-unlock.spec.ts	Classic unlock flow passes with PAS display on the current Product DevNet/Paseo config.
git diff --check	No whitespace errors.
npm audit --audit-level=moderate / --omit=dev	Fails on pre-existing high vulnerabilities via Product SDK/PAPI transitives; see follow-up.

Known limitations and follow-ups

• Dependency drift should be handled in a separate SDK/dependency PR: Product SDK 0.20.1 -> 0.23.0, host 0.15.1 -> 0.16.0, statement-store 0.6.2 -> 0.6.5, descriptors 0.8.0 -> 0.10.0, polkadot-api 1.23.3 -> 3.0.0, React 18 -> 19, Vite 6 -> 8, TypeScript 5.6 -> 7. These are not safe to opportunistically update here.
• npm audit currently reports high severity issues through deepmerge-ts/write-package/@polkadot-api/cli/Product SDK and nanoid/@novasamatech/host-api. That needs a dedicated dependency/security pass.
• Internal names like priceDot and formatWeiAsDot remain historical and should be renamed only after API/catalog compatibility is planned.

Pre-PR alignment check

• Dependency / SDK currency: checked against npm registry before opening; drift listed above.
• Improvement flags: dependency/security PR needed; historical native amount naming should be cleaned in a separate compatibility PR.
• Philosophical alignment: this strengthens honest access boundaries and low-friction trust. A user should see the token they are actually asked to pay, without having to understand Product DevNet internals.

Metadata checklist

• Backlog issue linked with reference semantics
• Local backlog document linked: docs/backlog/polkadot-product-readiness-and-killer-dapp-roadmap.md
• Added to Project 5 (Dotify sprints)
• Project Priority, Track, Phase, Type, and Backlog doc mirror the issue
• Workflow status matches draft/review state
• Assignee set
• Applicable labels set
• Applicable milestone set, or confirmed none exists
• Reviewers requested when ownership is known
• Draft/ready state is intentional

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 165431f5b4

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[chatgpt-codex-connector]

Update the artist-publish test to expect PAS

In the Playwright artist-publish scenario, this review panel now renders 0.75 PAS after the configured Paseo chain resolves, but web/e2e/artist-publish.spec.ts still requires 0.75 DOT at lines 84 and 105. Consequently the deterministic publishing test times out both while reviewing the draft and while checking the published catalog card; update those assertions from the same native-payment symbol fixture used by the Classic test.

AGENTS.md reference: AGENTS.md:L29-L30

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Move the pre-PR governance additions out of this ticket

This native-payment-label ticket also imposes new dependency-currency, improvement, and philosophical checks on every future PR, with matching unrelated edits to the knowledge-sharing guide. That process-policy change is independent of the payment UI behavior and substantially broadens the active ticket, so move it to its own backlog scope rather than coupling it to this fix.

AGENTS.md reference: AGENTS.md:L99-L103

Useful? React with 👍 / 👎.

[knzeng-e]

Addressed review feedback in 0d699d5:

• Updated artist-publish e2e expectations to use the native Product DevNet symbol (PAS) and aligned the artist share fixture with the percentage-based UI.
• Removed the pre-PR governance/template additions from this focused payment-label PR; I will keep applying those checks as process and move repo policy changes to a separate scope.

Validation: npm run test:e2e -- e2e/artist-publish.spec.ts; npm run lint; npm run build.

[knzeng-e]

reviewed