Inside rms-platform: Delivery Monitoring and Wallet Administration

A development deployment at dashboard.cklomino[.]ink exposed seventy frontend modules for an application called rms-platform; the recovered client combined mail views, repository availability checks and wallet-management controls, and its wallet views include mnemonic and ColdKey fields, plus import, preview and claim actions. The backend implementation and its stored records were not recovered.

The Vite server exposed seventy frontend modules

I followed imports exposed by the Vite development server and preserved seventy frontend modules (their embedded source maps included the original TypeScript comments). The recovered application calls itself rms-platform. Its client contains mail metrics, inbox and outbox views, templates, auto-reply controls, a task board, database tables and wallet-management components. The acquisition followed only modules loaded by the application and involved no login or call to the authenticated data API. The source references /api/github-jobs-check/, /api/db/... and /api/admin/wallets/{refresh,preview,claim,claim-all}/. These are strings in the client, not observed requests. The related historical indicator reference records the exact route forms and the evidence index lists hashes for the recovered modules and related samples, while the retained client excerpts are in E06 and E09.

Figure 1. The recovered frontend connects mail views, repository monitoring and wallet-management controls.

One view tracks repositories by clone_url, displays availability labels and offers refresh controls through /api/github-jobs-check/. The feature fits the delivery history: repositories can disappear, move or be replaced, and a status view could help monitor locations used to distribute lures or payloads, though no backend event history was recovered to show whether a repository suspension triggered an alert or a replacement.

Mail, tasks, and wallet controls

The wallet interface contains import, refresh, preview, claim and bulk-claim actions, and the client references routes including:

/api/admin/wallets/refresh/
/api/admin/wallets/preview/
/api/admin/wallets/claim/
/api/admin/wallets/claim-all/

The collection paths and their relationship to the dynamically selected server are listed in the historical indicator reference. Mnemonic and ColdKey fields, Bittensor-related interface language, and references to EVM and Aptos connect the intended wallet workflow to material targeted by the collectors, and the collectors select wallet material that corresponds to these interface fields. No transaction records accompanied the frontend. The sender and harvester tools were recovered separately, and their integration with this application remains unverified.

The SuperAdmin check lives in the client

The client helper grants super-administrator treatment when either a user flag is set or an email comparison matches, and these checks control frontend navigation and protected routes. The missing backend code leaves server-side claim authorization unknown. The signup route displays a disabled-signup message. Roles are defined in the interface. Account creation and user counts require backend records.