nick/nick-doc
3
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

docs: refresh taskmaster roadmap share

Browse Source
This commit is contained in:
Siavash Sameni
2026-05-24 09:54:04 +04:00
parent 5188cba9e2
commit 1a2b9f1f5d
5 changed files with 859 additions and 179 deletions
Download Patch File Download Diff File Expand all files Collapse all files

21
.taskmaster/tasks/task-5.md Normal file
View File

@@ -0,0 +1,21 @@
# Task 5: Deliver Telegram-native app, bot, and wallet experience
Status: pending
Priority: high
Source PRD: `.taskmaster/docs/prd-telegram-native-app-bot-wallet.md`
Create a Telegram bot plus Mini App surface so users can complete Amanat buyer, seller, escrow, chat, dispute, payment, release/refund, and support workflows from inside Telegram.
This is a separate product delivery track from platform hardening and Request Network migration. Identity, bot navigation, Mini App shell, and notifications can start behind feature flags. Wallet/payment crediting and release/refund actions must use canonical backend authorization, provider adapter, funds ledger, escrow state machine, idempotency, and dispute holds.
Subtasks:
1. Define Telegram product surface and flow map.
2. Build Telegram identity linking and session model.
3. Implement bot command and notification foundation.
4. Build Telegram Mini App shell for marketplace workflows.
5. Add Telegram payment and wallet strategy.
6. Expose escrow, delivery, dispute, and release actions safely.
7. Add admin and support surface for Telegram-originated cases.
8. Add security, compliance, and abuse controls for Telegram.
9. Prepare QA, rollout, analytics, and launch operations.

395
.taskmaster/tasks/tasks.json
View File

@@ -1,20 +1,8 @@
{
"master": {
"metadata": {
"projectName": "Amanat Documentation PRDs",
"created": "2026-05-24T00:00:00.000Z",
"updated": "2026-05-24T00:00:00.000Z",
"description": "Taskmaster task queue generated from docs-side PRDs for developer sharing.",
"sourcePrds": [
".taskmaster/docs/prd-mermaid-diagram-rendering-stabilization.md",
".taskmaster/docs/prd-platform-audit-remediation-plan-2026-05-24.md",
".taskmaster/docs/prd-request-network-migration-and-funds-management.md",
".taskmaster/docs/audit-backend-stack-security-and-refactor-assessment-2026-05-24.md"
]
},
"tasks": [
{
"id": 1,
"id": "1",
"title": "Stabilize Mermaid diagram rendering across documentation vault",
"description": "Correct Mermaid syntax/rendering issues across the documentation vault and validate all Mermaid blocks.",
"details": "Source PRD: .taskmaster/docs/prd-mermaid-diagram-rendering-stabilization.md. Scope covered 57 Mermaid blocks and 11 failing blocks. The source PRD records that all targeted files now pass mmdc parse validation and the full vault sweep passes.",
@@ -31,7 +19,8 @@
"status": "done",
"priority": "medium",
"dependencies": [],
"testStrategy": "mmdc parse for the specific block."
"testStrategy": "mmdc parse for the specific block.",
"parentId": "undefined"
},
{
"id": 2,
@@ -41,7 +30,8 @@
"status": "done",
"priority": "medium",
"dependencies": [],
"testStrategy": "mmdc parse for both Authentication Flow blocks."
"testStrategy": "mmdc parse for both Authentication Flow blocks.",
"parentId": "undefined"
},
{
"id": 3,
@@ -51,12 +41,13 @@
"status": "done",
"priority": "medium",
"dependencies": [],
"testStrategy": "Full vault mmdc parser sweep across all Mermaid blocks."
"testStrategy": "Full vault mmdc parser sweep across all Mermaid blocks.",
"parentId": "undefined"
}
]
},
{
"id": 2,
"id": "2",
"title": "Implement platform audit remediation plan",
"description": "Address the code-backed security and consistency issues identified in the 2026-05-24 platform audit remediation PRD.",
"details": "Source PRD: .taskmaster/docs/prd-platform-audit-remediation-plan-2026-05-24.md. Target backend hardening first, then documentation/runtime alignment. Delivery order suggested by PRD: security/auth, rate limiting, passkeys, Web3 verification, socket hardening, dispute hold controls, docs/API alignment.",
@@ -73,7 +64,8 @@
"status": "pending",
"priority": "high",
"dependencies": [],
"testStrategy": "Unauthorized callers receive 401/403; users cannot access or mutate other users' payments/notifications; admins retain authorized access."
"testStrategy": "Unauthorized callers receive 401/403; users cannot access or mutate other users' payments/notifications; admins retain authorized access.",
"parentId": "undefined"
},
{
"id": 2,
@@ -85,7 +77,8 @@
"dependencies": [
1
],
"testStrategy": "Exercise configured limits per tier and confirm expected 429 responses without blocking ordinary reads."
"testStrategy": "Exercise configured limits per tier and confirm expected 429 responses without blocking ordinary reads.",
"parentId": "undefined"
},
{
"id": 3,
@@ -97,7 +90,8 @@
"dependencies": [
1
],
"testStrategy": "Registration, login, replay, expired challenge, and refresh-token continuity tests pass."
"testStrategy": "Registration, login, replay, expired challenge, and refresh-token continuity tests pass.",
"parentId": "undefined"
},
{
"id": 4,
@@ -109,7 +103,8 @@
"dependencies": [
1
],
"testStrategy": "Reject successful but wrong-recipient/wrong-token/underpaid tx hashes; accept only matching transfers."
"testStrategy": "Reject successful but wrong-recipient/wrong-token/underpaid tx hashes; accept only matching transfers.",
"parentId": "undefined"
},
{
"id": 5,
@@ -121,7 +116,8 @@
"dependencies": [
1
],
"testStrategy": "A user cannot subscribe to another user's rooms; legitimate realtime notifications still arrive."
"testStrategy": "A user cannot subscribe to another user's rooms; legitimate realtime notifications still arrive.",
"parentId": "undefined"
},
{
"id": 6,
@@ -134,7 +130,8 @@
1,
4
],
"testStrategy": "Open dispute blocks release/refund until resolved or explicitly overridden through authorized path."
"testStrategy": "Open dispute blocks release/refund until resolved or explicitly overridden through authorized path.",
"parentId": "undefined"
},
{
"id": 7,
@@ -151,115 +148,178 @@
5,
6
],
"testStrategy": "Docs match implemented routes, models, enum values, and state transitions."
"testStrategy": "Docs match implemented routes, models, enum values, and state transitions.",
"parentId": "undefined"
}
]
},
{
"id": 3,
"id": "3",
"title": "Migrate payment architecture toward Request Network and internal funds management",
"description": "Plan and implement provider-neutral payment flows, Request Network pay-in support, funds ledger, webhook reconciliation, release/refund orchestration, UI migration, and SHKeeper decommissioning.",
"details": "Source PRD: .taskmaster/docs/prd-request-network-migration-and-funds-management.md. The PRD recommends phased migration behind a provider adapter, Secure Payment Pages first, platform-controlled escrow/payee destination, and a first-class internal funds ledger before release/refund enforcement.",
"testStrategy": "Use feature flags, provider fixture tests, webhook signature/idempotency tests, ledger invariant tests, migration dry-run reports, and limited cohort rollout before default provider switch.",
"priority": "high",
"status": "pending",
"status": "in-progress",
"dependencies": [
2
"2"
],
"subtasks": [
{
"id": 1,
"title": "Introduce provider-neutral payment adapter",
"description": "Decouple checkout, webhook, and payout flows from SHKeeper-specific routes and metadata.",
"details": "Define createPayInIntent, getPayInStatus, handleProviderWebhook, createHostedPaymentLink, createReleaseInstruction, createRefundInstruction, getPayoutStatus, and searchProviderPayments. Add provider values shkeeper, request_network, manual, admin_wallet and PAYMENT_PROVIDER feature flag.",
"title": "Define provider-neutral payment contracts and adapter",
"description": "Create provider-agnostic payment interface with pay-in, webhook, payout/refund instruction creation, status lookup, and search methods.",
"details": "",
"status": "pending",
"priority": "high",
"dependencies": [],
"testStrategy": "New provider can be selected by feature flag while existing SHKeeper payments remain readable and process late webhooks."
"parentTaskId": 3,
"parentId": "undefined"
},
{
"id": 2,
"title": "Implement Request Network pay-in integration",
"description": "Create Request Network payment requests or Secure Payment Pages for new checkout flows.",
"details": "Store requestId, paymentReference, securePaymentUrl, token, merchantReference, network, invoiceCurrency, and paymentCurrency. Validate supported networks/currencies before creating links.",
"title": "Implement provider configuration, feature flags, and safe rollback",
"description": "Add runtime provider selection, rollout controls, env validation, and one-command kill-switch to revert to SHKeeper.",
"details": "",
"status": "pending",
"priority": "high",
"dependencies": [
1
"3.1"
],
"testStrategy": "Buyer receives hosted payment URL; webhook reconciles matching internal payment only after amount/currency/reference validation."
"parentTaskId": 3,
"parentId": "undefined"
},
{
"id": 3,
"title": "Add funds ledger and escrow state machine",
"description": "Introduce internal funds accounting independent from provider metadata.",
"details": "Add FundsAccount, LedgerEntry, derived FundsBalance, expected/held/releasable/releasing/released/refunded/disputed/failed states, fee representation, and release/refund invariant checks.",
"title": "Create internal funds and payment ledger model",
"description": "Define FundsAccount, immutable LedgerEntry, and balance/query views for expected/held/releasable/released/refunded/disputed states.",
"details": "",
"status": "pending",
"priority": "high",
"dependencies": [
1
"3.1"
],
"testStrategy": "Every pay-in creates immutable ledger entries and payout/refund cannot exceed available held funds or bypass dispute holds."
"parentTaskId": 3,
"parentId": "undefined"
},
{
"id": 4,
"title": "Build Request Network webhook and reconciliation service",
"description": "Process signed Request Network events and repair missed webhook state through reconciliation.",
"details": "Add /api/payment/request-network/webhook, verify raw-body x-request-network-signature, store delivery ID/retry/event/request/payment reference/payload hash, support test webhooks, and add scheduled payment search/status reconciliation.",
"title": "Build migration and indexing plan for existing SHKeeper records",
"description": "Add DB indexes for payment/provider fields and run backfill to produce a migration report with skipped/failed/ambiguous historical entries.",
"details": "",
"status": "pending",
"priority": "high",
"dependencies": [
2,
3
"3.3"
],
"testStrategy": "Invalid signatures reject; duplicate delivery IDs acknowledge without duplicate ledger entries; reconciliation repairs missed state."
"parentTaskId": 3,
"parentId": "undefined"
},
{
"id": 5,
"title": "Implement release, refund, and payout orchestration",
"description": "Replace SHKeeper payout tasks and simulated release with auditable transaction instruction and confirmation flows.",
"details": "Create release/refund service consuming ledger balances, generate Request Network payout or direct admin wallet instructions, store unsigned tx payloads, signer, submitted hash, confirmation status, provider status, and require admin/operator authorization plus dispute checks.",
"title": "Implement Request Network pay-in intent and secure payment pages",
"description": "Add Request Network intent/service layer, secure payment URLs, and validation of network/currency/reference/amount before setting paid state.",
"details": "",
"status": "pending",
"priority": "high",
"dependencies": [
3,
4
"3.2"
],
"testStrategy": "Release cannot occur if unpaid, already released, refunded, or disputed; tx hash confirmation updates ledger once; admin can retry/cancel safely."
"parentTaskId": 3,
"parentId": "undefined"
},
{
"id": 6,
"title": "Migrate frontend checkout and admin payment UI",
"description": "Update buyer checkout, admin release, seller payout, and payment details for provider-neutral Request Network flows.",
"details": "Replace ShkeeperPayment with CryptoPayment/RequestNetworkPayment redirect flow, keep legacy SHKeeper only for legacy records, replace ShkeeperPayout with release queue/admin payout UI, and show provider IDs, payment references, hosted links, ledger balances, webhook/reconciliation status.",
"title": "Implement signed Request Network webhook intake",
"description": "Build /api/payment/request-network/webhook with raw-body signature verification, idempotent delivery handling, and immutable event audit rows.",
"details": "",
"status": "pending",
"priority": "medium",
"dependencies": [
2,
3,
5
"3.2"
],
"testStrategy": "Request Network checkout does not expect walletAddress; admin UI blocks unsafe release; legacy labels are hidden for Request Network records."
"parentTaskId": 3,
"parentId": "undefined"
},
{
"id": 7,
"title": "Backfill legacy SHKeeper records and decommission provider-specific code",
"description": "Migrate historical SHKeeper payment metadata and safely remove legacy wallet monitor/webhook/payout paths after cutoff.",
"details": "Backfill provider namespace, create ledger entries for trusted completed SHKeeper payments, mark legacyProvider, keep webhook tail period, and produce decommission checklist for env vars, docs, labels, routes, and runbooks.",
"title": "Implement reconciliation and repair jobs",
"description": "Add periodic Request Network payment search/reconciliation and manual replay support to fix missed or delayed events.",
"details": "",
"status": "pending",
"priority": "medium",
"dependencies": [
3,
4,
5,
6
"3.5",
"3.6"
],
"testStrategy": "Dry-run report includes total, migrated, skipped, ambiguous, failed; no historical transaction hash/invoice/task metadata is lost."
"parentTaskId": 3,
"parentId": "undefined"
},
{
"id": 8,
"title": "Replace checkout and payment UI with provider-neutral flows",
"description": "Introduce provider-neutral payment components, remove SHKeeper walletAddress assumptions for RN, and keep legacy path only for existing SHKeeper records.",
"details": "",
"status": "pending",
"dependencies": [
"3.5"
],
"parentTaskId": 3,
"parentId": "undefined"
},
{
"id": 9,
"title": "Add payout/release and refund orchestration using ledger gates",
"description": "Create release/refund instruction queue with signer, tx payloads, provider tx hash, and strict ledger invariants before action.",
"details": "",
"status": "pending",
"dependencies": [
"3.3",
"3.7"
],
"parentTaskId": 3,
"parentId": "undefined"
},
{
"id": 10,
"title": "Update release/refund APIs and marketplace release paths",
"description": "Refactor release routes to consume ledger state and provider-neutral contracts; deprecate direct simulation where possible.",
"details": "",
"status": "pending",
"dependencies": [
"3.8",
"3.9"
],
"parentTaskId": 3,
"parentId": "undefined"
},
{
"id": 11,
"title": "Add comprehensive observability, runbooks, and incident controls",
"description": "Track webhook latency, ledger imbalance, release failures, and reconciliation lag with alerts, on-call runbooks, and rollback procedures.",
"details": "",
"status": "pending",
"dependencies": [
"3.6",
"3.8",
"3.9",
"3.10"
],
"parentTaskId": 3,
"parentId": "undefined"
},
{
"id": 12,
"title": "Add end-to-end integration, migration, and rollback test suites",
"description": "Cover backend contract tests, provider fixture tests, UI acceptance, rollout simulation, DRYRUN migration, and release rollback rehearsals.",
"details": "",
"status": "pending",
"dependencies": [
"3.6",
"3.10",
"3.11"
],
"parentTaskId": 3,
"parentId": "undefined"
}
]
],
"updatedAt": "2026-05-24T05:52:52.473Z"
},
{
"id": 4,
"id": "4",
"title": "Define backend security and refactor strategy from latest audit",
"description": "Convert the backend stack security/refactor assessment into concrete architecture decisions, documentation deliverables, and developer handoff criteria.",
"details": "Source audit: .taskmaster/docs/audit-backend-stack-security-and-refactor-assessment-2026-05-24.md. This task is advisory/architecture-focused and should run in parallel with immediate hardening. It should produce the decision artifacts needed before any backend-core rewrite or provider migration is started.",
@@ -276,7 +336,8 @@
"status": "pending",
"priority": "high",
"dependencies": [],
"testStrategy": "Written owner/RACI and launch gate checklist are accepted by leadership and engineering."
"testStrategy": "Written owner/RACI and launch gate checklist are accepted by leadership and engineering.",
"parentId": "undefined"
},
{
"id": 2,
@@ -288,7 +349,8 @@
"dependencies": [
1
],
"testStrategy": "Threat model maps each high-risk finding to at least one mitigation task or accepted risk."
"testStrategy": "Threat model maps each high-risk finding to at least one mitigation task or accepted risk.",
"parentId": "undefined"
},
{
"id": 3,
@@ -300,7 +362,8 @@
"dependencies": [
2
],
"testStrategy": "Spec can be used to reject double-release, release-during-dispute, underfunded payout, and ambiguous provider-event scenarios."
"testStrategy": "Spec can be used to reject double-release, release-during-dispute, underfunded payout, and ambiguous provider-event scenarios.",
"parentId": "undefined"
},
{
"id": 4,
@@ -312,7 +375,8 @@
"dependencies": [
2
],
"testStrategy": "No route or socket event remains unmapped; implementation tasks can reference matrix rows directly."
"testStrategy": "No route or socket event remains unmapped; implementation tasks can reference matrix rows directly.",
"parentId": "undefined"
},
{
"id": 5,
@@ -324,7 +388,8 @@
"dependencies": [
2
],
"testStrategy": "Decision record lists chosen model, rejected alternatives, migration cost, and required implementation tasks."
"testStrategy": "Decision record lists chosen model, rejected alternatives, migration cost, and required implementation tasks.",
"parentId": "undefined"
},
{
"id": 6,
@@ -336,7 +401,8 @@
"dependencies": [
3
],
"testStrategy": "Contracts cover SHKeeper legacy, Request Network, manual/admin wallet, invalid signatures, duplicate deliveries, and missed webhook reconciliation."
"testStrategy": "Contracts cover SHKeeper legacy, Request Network, manual/admin wallet, invalid signatures, duplicate deliveries, and missed webhook reconciliation.",
"parentId": "undefined"
},
{
"id": 7,
@@ -348,7 +414,8 @@
"dependencies": [
1
],
"testStrategy": "Policy is actionable in CI and includes response steps for compromised package, leaked token, and vulnerable dependency alerts."
"testStrategy": "Policy is actionable in CI and includes response steps for compromised package, leaked token, and vulnerable dependency alerts.",
"parentId": "undefined"
},
{
"id": 8,
@@ -365,7 +432,8 @@
6,
7
],
"testStrategy": "Architecture decision record states chosen stack, scope of extraction, non-goals, migration phases, rollback criteria, and owners."
"testStrategy": "Architecture decision record states chosen stack, scope of extraction, non-goals, migration phases, rollback criteria, and owners.",
"parentId": "undefined"
},
{
"id": 9,
@@ -377,10 +445,161 @@
"dependencies": [
8
],
"testStrategy": "Runbooks identify owner, trigger, detection signal, immediate action, recovery action, and post-incident documentation for each scenario."
"testStrategy": "Runbooks identify owner, trigger, detection signal, immediate action, recovery action, and post-incident documentation for each scenario.",
"parentId": "undefined"
}
]
},
{
"id": "5",
"title": "Deliver Telegram-native app, bot, and wallet experience",
"description": "Create a Telegram bot plus Mini App surface so users can complete Amanat buyer, seller, escrow, chat, dispute, payment, release/refund, and support workflows from inside Telegram.",
"details": "Source PRD: .taskmaster/docs/prd-telegram-native-app-bot-wallet.md. Keep this as a separate delivery track from security remediation and Request Network migration. Identity, bot navigation, Mini App shell, and notifications can start behind flags; wallet/payment crediting and release/refund actions must use canonical backend authorization, provider adapter, funds ledger, escrow state machine, idempotency, and dispute holds.",
"testStrategy": "Use Telegram sandbox and production bot separation, Mini App client matrix testing, provider/wallet payment fixtures, backend authorization and ledger invariant tests, webhook/callback replay tests, and staged rollout analytics before launch.",
"status": "pending",
"dependencies": [],
"priority": "high",
"subtasks": [
{
"id": 1,
"title": "Define Telegram product surface and flow map",
"description": "Document which Amanat workflows live in bot messages, which live in the Mini App, and which remain web/admin-only for first release.",
"details": "Map buyer, seller, admin/support, unauthenticated, linked-user, and unlinked-user journeys. Specify deep-link entry points for request details, offer review, payment, dispute, delivery evidence, and account linking. Separate first-release scope from later enhancements and map every Telegram action to backend API/state transitions.",
"status": "pending",
"dependencies": [],
"priority": "high",
"testStrategy": "See Telegram-native PRD acceptance criteria.",
"parentId": "undefined"
},
{
"id": 2,
"title": "Build Telegram identity linking and session model",
"description": "Implement secure account linking between Telegram users and Amanat accounts.",
"details": "Backend must verify Telegram Mini App initData before creating a Telegram session. Store an auditable Telegram user ID to Amanat user link. Support existing users, new users, unlinking, blocked accounts, duplicate-link attempts, session expiry, replay protection, rate limits, and audit logs.",
"status": "pending",
"dependencies": [
1
],
"priority": "high",
"testStrategy": "See Telegram-native PRD acceptance criteria.",
"parentId": "undefined"
},
{
"id": 3,
"title": "Implement bot command and notification foundation",
"description": "Create the Telegram bot backend for commands, inline keyboards, callback queries, deep links, and outbound notifications.",
"details": "Support start/help/link/status/request/offer/payment/dispute/settings basics. Use short opaque IDs or signed tokens for callback payloads. Process incoming updates idempotently with rate limits. Respect notification preferences, quiet/error states, failed delivery, blocked bot, and retry observability.",
"status": "pending",
"dependencies": [
1,
2
],
"priority": "high",
"testStrategy": "See Telegram-native PRD acceptance criteria.",
"parentId": "undefined"
},
{
"id": 4,
"title": "Build Telegram Mini App shell for marketplace workflows",
"description": "Deliver the mobile-first Mini App that gives users the full Amanat workflow surface inside Telegram.",
"details": "Use Telegram theme, safe-area, viewport, back button, haptics, and main/bottom button patterns. Support browsing requests, creating/editing requests, reviewing offers, payment state, evidence uploads, delivery actions, and dispute actions. Launch from bot profile, menu button, inline buttons, and direct links with startapp context. Handle unlinked accounts, expired sessions, unsupported clients, and fallback web links.",
"status": "pending",
"dependencies": [
1,
2
],
"priority": "high",
"testStrategy": "See Telegram-native PRD acceptance criteria.",
"parentId": "undefined"
},
{
"id": 5,
"title": "Add Telegram payment and wallet strategy",
"description": "Evaluate and implement safe payment entry points for Telegram-native users without weakening escrow accounting.",
"details": "Compare Bot API payments/Stars, Wallet Pay, TON Pay, TON Connect, Request Network links, and existing crypto checkout. Select a first payment path and document rejected options. Store provider, Telegram user ID, deep-link source, payment reference, invoice/order/request ID, currency, amount, expiration, and idempotency key. Wallet/TON flows must validate recipient, asset, amount, memo/reference, confirmation status, and reconciliation evidence before crediting escrow. Refund/release behavior must remain compatible with canonical ledger and dispute holds.",
"status": "pending",
"dependencies": [
2,
4
],
"priority": "high",
"testStrategy": "See Telegram-native PRD acceptance criteria.",
"parentId": "undefined"
},
{
"id": 6,
"title": "Expose escrow, delivery, dispute, and release actions safely",
"description": "Make Telegram actions useful for real escrow work while preserving backend state authority.",
"details": "Telegram users can see current escrow state, next allowed actions, and blockers. Delivery confirmation, evidence upload, refund request, dispute open/respond, and release approval must route through backend precondition checks. High-risk actions require fresh confirmation and audit logging with Telegram context. Disputed or held funds cannot be released through Telegram shortcuts.",
"status": "pending",
"dependencies": [
4,
5
],
"priority": "high",
"testStrategy": "See Telegram-native PRD acceptance criteria.",
"parentId": "undefined"
},
{
"id": 7,
"title": "Add admin and support surface for Telegram-originated cases",
"description": "Give support/admin users visibility and controls for Telegram-originated users, payments, and bot events.",
"details": "Admin UI/API should show Telegram linked identity, bot notification status, launch source, payment provider, and wallet/payment references. Support can resend links, revoke Telegram link, block bot access, and inspect Telegram-originated events. Admin overrides must use the same step-up or two-person policy as web flows when configured.",
"status": "pending",
"dependencies": [
2,
3,
5
],
"priority": "high",
"testStrategy": "See Telegram-native PRD acceptance criteria.",
"parentId": "undefined"
},
{
"id": 8,
"title": "Add security, compliance, and abuse controls for Telegram",
"description": "Threat-model the Telegram surface and add controls before launch.",
"details": "Cover forged init data, callback replay, deep-link parameter tampering, phishing links, bot token leakage, spam, account takeover, wallet spoofing, fake payment proof, and support impersonation. Document secrets, bot webhook endpoints, Wallet Pay keys, TON Connect manifest, CORS, CSP, allowed origins, rate limits, and monitoring for update failures, abnormal callbacks, payment mismatches, blocked notifications, and suspicious wallet activity.",
"status": "pending",
"dependencies": [
2,
3,
5,
6
],
"priority": "high",
"testStrategy": "See Telegram-native PRD acceptance criteria.",
"parentId": "undefined"
},
{
"id": 9,
"title": "Prepare QA, rollout, analytics, and launch operations",
"description": "Prepare the Telegram app and bot for controlled release.",
"details": "Test Telegram iOS, Android, Desktop, Web, light/dark themes, compact/fullscreen modes, slow network, blocked bot, expired sessions, and payment cancellation. Keep sandbox/test bot and production bot environments separated. Roll out through feature flags, internal allowlist, beta cohort, and production enablement. Track activation, linked accounts, request creation, offer response, payment start/completion, dispute activity, release approval, and notification opt-outs. Add runbooks for bot outage, Telegram API outage, payment provider outage, stuck payment, duplicate callback, suspicious wallet proof, and compromised bot token.",
"status": "pending",
"dependencies": [
3,
4,
5,
6,
7,
8
],
"priority": "high",
"testStrategy": "See Telegram-native PRD acceptance criteria.",
"parentId": "undefined"
}
]
}
]
],
"metadata": {
"version": "1.0.0",
"lastModified": "2026-05-24T05:52:52.473Z",
"taskCount": 5,
"completedCount": 1,
"tags": [
"master"
]
}
}
}
}