Build a qdnRequest sandbox/reference Q-App

[QuickMythril]

Local ID: P-APPS-14

Source: maintainer worklog request, 2026-07-07.

Problem

Qortium app authors need a maintained sandbox/reference Q-App that exposes the available window.qdnRequest actions in one place, similar in spirit to Qortal's Q-Sandbox app. Today, app authors have to infer the bridge surface from Home/Core code, scattered examples, or individual apps.

Goal

Build and publish a Qortium-native sandbox app that lets maintainers and app authors discover, exercise, and verify supported qdnRequest actions against the current Home/Core environment.

Suggested scope

• Inventory the currently supported qdnRequest actions exposed by Qortium Home across desktop, Android/native, public-node, custom-node, and local-Core modes.
• Group actions by purpose, such as account/session, QDN read/write, chat, wallet/cross-chain, encryption, app navigation, node/status, and UI/theme/display settings.
• For each action, show the expected request shape, required/optional fields, permission/approval behavior, and a runnable form or example where safe.
• Make unavailable actions clear by environment rather than failing silently.
• Avoid exposing destructive or spend/broadcast actions without explicit guardrails, confirmation, and test-mode guidance.
• Use Qortium-native qdnRequest only; do not reintroduce legacy qortalRequest as the primary path.
• Decide whether this should become a new repo, a new app resource, or a developer page within an existing app before implementation.

Validation

• Run the sandbox in Qortium Home desktop and Android/native where possible.
• Confirm non-destructive read actions work against a synced local Core and a public/custom node where supported.
• Confirm write, wallet, encryption, or broadcast-class actions show safe prompts, test-only paths, or clear unavailable states.
• Keep the action list synchronized with Home bridge changes so the sandbox can become a regression/checklist tool for future releases.

Notes

This is marked needs discussion because the first useful step is to define the repo/resource home and the safe subset of actions that can be exercised directly in a public app.