fix(product): align DotNS deploy profile

[knzeng-e]

Outcome

Makes the Product DevNet deployment path resolve the same DotNS generation as the current Product Desktop host, and fails before build, signing, or publication when the installed deployer profile drifts.

Issue and context

Refs #158.

Local scope: docs/backlog/implementation/W13-pilot-release.md and docs/backlog/implementation/evidence/W13.md.

The W13 debug panel was present in Dotify's local Product build but absent from the bundle loaded by Product Desktop. Reproducing the journey with the current Product Desktop source showed that the host still resolved an older Dotify bundle. The deployment command was pinned to @polkadot-community-foundation/polkadot-app-deploy@0.16.2, whose transient DevNet DotNS registry and resolver differ from the stable profile used by the current 0.16.7 deployer and Product host.

This matters because clearing local cache cannot fix an identity mismatch upstream: the host and deploy command must address the same registry, resolver, Publisher, IPFS service, and web gateway before a CID or bundle comparison is meaningful.

Architecture and key concepts

The npm package's embedded assets/environments.json is the authoritative deployment profile. Dotify records the expected Product DevNet identity in a small verifier, then inspects the exact pad package selected by npm exec rather than trusting a separately maintained version string.

flowchart LR
  A[deploy:product-devnet] --> B[check mnemonic is present]
  B --> C[npm exec pad 0.16.7]
  C --> D[inspect package.json and environments.json]
  D -->|exact profile| E[frozen Product build]
  D -->|missing or drifted field| F[stop before signing or publishing]
  E --> G[pad devnet publish]

Loading

The journey harness also requires this preflight statically, so future script edits cannot silently remove it while leaving tests green.

How it works

1. deploy:product-devnet verifies that deployment authorization is available without printing the mnemonic.
2. npm exec --package ...@0.16.7 resolves the actual CLI package.
3. product-deploy-environment-check.mjs locates that executable's package root and compares its version and DevNet fields with the accepted profile.
4. Only a complete match permits the frozen Product build and pad devnet publication command to run.
5. The runbook requires operators to compare DotNS resolver, CID, and served bundle identity before treating browser or Product Desktop cache as the cause.

Design decisions and tradeoffs

• Pin 0.16.7 instead of floating latest, keeping deployment reproducible while matching the current stable host generation.
• Inspect the package actually selected on PATH. A duplicated local environment file could say the right thing while the CLI uses another profile.
• Fail on every missing or mismatched field. Partial identity agreement is not sufficient for an irreversible publication.
• Keep publication manual. This PR changes and verifies the path but does not spend funds, sign, publish, migrate contracts, or promote a pilot identity.
• Do not treat cache clearing as the primary repair. It remains useful only after the host and deployment identities agree.

Security, failure, and operations

No secret, key, or mnemonic is persisted or logged. The verifier reads only public package metadata. Profile drift, a missing devnet entry, an unexpected package, or an unresolved executable all fail closed before the build/publish stages.

The verifier does not prove that a later chain transaction finalized or that a gateway serves the new CID. Those remain post-publication operational checks. Rollback and pilot promotion are still governed by the W13 runbook and require explicit authorization.

Review guide

Suggested order

1. web/scripts/product-deploy-environment-check.mjs: verify the source-of-truth lookup and exact profile invariants.
2. web/package.json: verify the command order and pinned deployer version.
3. web/scripts/product-devnet-journey-harness.mjs: verify deployment evidence cannot pass when the preflight is omitted.
4. The two test files: inspect accepted and rejected profiles plus the static-gate regression.
5. docs/operations/product-devnet-deployment.md and W13 evidence: verify operator sequencing and the honest boundary between local validation and live Product proof.

Verify carefully

• Can any mismatch reach a signing or publication step?
• Does executable discovery inspect the package selected by npm exec, not a coincidental local install?
• Are the registry, resolver, Publisher, IPFS endpoint, and gateway checked together?
• Does the journey harness detect removal of the environment preflight?
• Do the docs avoid claiming that a local build or cache reset proves Product-hosted delivery?

Validation

Evidence	What it proves
npm run verify:product-deploy-environment	The published 0.16.7 package contains the accepted Product DevNet identity.
npm run test:product-deploy-environment	Accepted, transient/mismatched, and missing-profile behavior is deterministic. 3 tests passed.
node --test scripts/product-devnet-journey-harness.test.mjs	The W13 harness enforces the preflight. 21 tests passed.
npm run test:unit	Frontend and supporting unit behavior remains green. 79 files, 647 tests passed.
npm run lint	No lint errors; 3 inherited warnings remain in App.tsx and ArtistShell.tsx.
npm run fmt:check	Formatting passes.
node scripts/backlog-sync.mjs --check --offline	Backlog records remain synchronized.
Frozen Product debug build plus local Playwright inspection	Build succeeds and the served bundle contains Production readiness and Product CDM host smoke, with no page errors.
W13 journey smoke	29 pass, 0 fail, 1 blocked, 1 not-run; only live Product-host and room evidence remains blocked.

Known limitations and follow-ups

• No live DotNS publication was performed in this PR.
• Product Desktop must be tested after an explicitly authorized publish from a clean, merged candidate; the resolved CID and served bundle must be recorded.
• Physical iPhone and supported-device first-sound evidence, an independent guest room, TURN-forced evidence, rollback rehearsal, and pilot evaluation remain W13 acceptance gates.
• The W13 issue stays open until those acceptance gates support a recorded go, hold, or no-go decision.

Metadata checklist

• Backlog issue linked with correct reference semantics (Refs #158)
• Local backlog document linked
• Added to Project 5 (Dotify sprints)
• Project Priority, Track, Phase, Type, and Backlog doc mirror the issue
• Workflow status matches draft/review state (In Progress)
• Assignee set
• Applicable labels set
• Confirmed no applicable milestone exists
• No reviewer requested because no separate owner is known
• Draft state is intentional pending live Product evidence

[netlify]

✅ Deploy Preview for muzinga ready!

Name	Link
🔨 Latest commit	f98901d
🔍 Latest deploy log	https://app.netlify.com/projects/muzinga/deploys/6aba69d0cd9c510008ed51be
😎 Deploy Preview	https://deploy-preview-221--muzinga.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[chatgpt-codex-connector]

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Review	Status	Commit	Review trigger
📝 Code Review	✅ Completed 2026-09-28T13:15:49.187332Z	1419d1b	Draft marked ready

ℹ️ 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" or "@codex security review".

Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 1419d1be99

ℹ️ 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".