dash-platform-control-center

name	dash-platform-control-center
description	Operate and extend the DASH Singles control center for Dash Platform on testnet. Use when Codex needs to continue the Dash Platform tutorial sequence, inspect or reuse the repository's existing wallet/identity/name/contract/document state, add or update `.env`-backed Dash scripts, or document and verify new on-chain DASH flows in this repository.

Dash Platform Control Center

Start Here

• Work from the repository root.
• Read references/current-state.md before touching wallet, identity, DPNS, contract, or document flows.
• Read references/verified-flows.md for the portable mirror of completed tutorial coverage and SDK deviations.
• Read references/roadmap.md when the user asks to continue the next Dash phase.
• Use repo docs only as secondary sync targets; the skill must stay usable even when copied without the rest of this repository.

Operating Rules

• Treat .env as the operational source of truth for mnemonic-derived resources, identity ids, contract ids, document ids, and revisions.
• Keep DASH_IDENTITY_ID reserved for the primary identity derived from DASH_IDENTITY_INDEX=0. For secondary identities, sync a separate prefix such as DASH_TRANSFER_RECIPIENT or use --no-sync.
• Never print, commit, or duplicate secrets from .env; document only public identifiers and non-sensitive state.
• Reuse existing npm run ... entrypoints before adding new scripts.
• Make new write flows idempotent. If a transaction, identity, contract, or document may already exist, detect and return an already* result instead of re-creating it blindly.
• Sync every successful write back into .env.example, README, the runbook, and these skill-local references when the command surface or persisted state model changes.
• Verify the official Dash docs for the specific tutorial section before implementing it, because the stable docs and the current SDK surface do not always match.
• When updating an existing contract, preserve immutable published config flags unless a live network test proves the change is accepted. The repository's contract already proved that keepsHistory=false -> true is rejected after publish.

Continue the Repository Workflow

1. Confirm the current tutorial target in references/roadmap.md.
2. Inspect the already-verified baseline in references/current-state.md and references/verified-flows.md.
3. Reuse existing scripts to read the live state before changing anything:
   • connectivity and status
   • wallet and Platform funding
   • identity and DPNS name
   • identity update and account-identity retrieval
   • contract register/update/get/history
   • document query, submit, update, delete
   • identity transfer and identity withdrawal
4. Implement only the missing delta for the next tutorial section.
5. Verify on testnet with explicit commands and expected outcomes.
6. Update the skill-local references first, then sync the repo docs so the next session starts from the new baseline.

Known Dash-Specific Deviations

• Use @dashevo/evo-sdk for Platform tutorial work and keep the legacy dash package only for the older connectivity probes.
• For identity creation, prefer the explicit asset-lock flow already implemented in the repository; the higher-level tutorial bridge was not reliable in this environment.
• Build contracts through DataContract.fromJSON(...) after SDK initialization instead of relying on the tutorial-style constructor form.
• Update contracts through sdk.contracts.update({ dataContract, identityKey, signer }), but do not assume every config field is mutable after first publish.
• Build or replace documents through Document.fromJSON(...); document updates are full replacements with the same $id and an incremented $revision.
• Query documents through sdk.documents.query(...) or sdk.documents.get(...), not through the older tutorial surface.
• Respect Platform validation details already learned from live broadcasts: indexed string lengths stay <= 63, index names stay <= 32.
• The stable transfer/withdraw tutorial pages are out of date for the installed SDK. The working methods are sdk.identities.creditTransfer({ ... }) and sdk.identities.creditWithdrawal({ ... }).
• The stable Update an identity and Retrieve an account's identities tutorial pages are also out of date in this environment.
• The repository's identity:update command intentionally automates only the proven safe update path: ensure the withdrawal-compatible transfer key exists. Do not automate tutorial-style key disabling on the live control-center identity unless a new production need is verified first.
• The repository's identity:account-identities command intentionally uses deterministic identity-index scanning through evo-sdk as the default path. The legacy wallet-account route is slower and suited only for deliberate parity probes.
• Credit transfer worked only with the transfer key alias in this environment.
• Tutorial-created identities needed an added purpose=TRANSFER, type=ECDSA_HASH160 key before withdrawals would succeed.
• The current withdrawal-preparation path depends on a live-verified workaround recorded in src/evo/identity-state.mjs: the new hash160-style key uses the first 20 bytes of the transfer public key, not the literal hash160 bytes.

Verification Standard

• Run the smallest set of live commands that proves the new behavior on testnet.
• Record exact commands, key identifiers, and result summaries in the task verification notes.
• Run agentplane doctor and node .agentplane/policy/check-routing.mjs after repo mutations.
• Treat a dirty git tree as a separate risk. Do not hide it; record it explicitly in task findings.

References

• references/current-state.md: public on-chain identifiers, current verified commands, deletion audit state, and the most important repo entrypoints.
• references/verified-flows.md: completed tutorial coverage, verified commands, and known SDK/runtime deviations.
• references/roadmap.md: portable next-phase plan for the remaining tutorial and product work.