Amanat docs ยท Taskmaster

Roadmap

A public planning view generated from the docs-side Taskmaster queue. Track security remediation, payment architecture, Telegram-native work, refactor decisions, and completed documentation work from one place.

Raw JSON
Shipped
In progress
Planned

Task 2

Implement platform audit remediation plan

pendinghigh

Address the code-backed security and consistency issues identified in the 2026-05-24 platform audit remediation PRD.

Details and test strategy

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.

Test strategy: Add focused regression tests for route auth/ownership, passkey challenge/verification, Web3 verification semantics, socket authorization, rate limiting tiers, and payout/release dispute holds. Update API docs after behavior is implemented.

Subtasks (7)

  • 2.1 Secure unauthenticated endpoints and owner enforcement pending high

    Require authenticateToken and owner/admin checks on exposed payment, AI, and legacy notification routes.

  • 2.2 Re-enable and scope rate limiting pending high

    Restore global and route-tiered rate limits for public-sensitive paths.

    Depends on: 2.1

  • 2.3 Replace stubbed passkey/WebAuthn flow pending high

    Implement production-grade WebAuthn registration/authentication and shared challenge storage.

    Depends on: 2.1

  • 2.4 Strengthen DePay/Web3 payment verification pending high

    Verify transaction recipient, token contract, and amount, not only receipt success.

    Depends on: 2.1

  • 2.5 Lock Socket.IO room joins to authenticated context pending medium

    Remove trust in client-supplied user/buyer/seller room IDs.

    Depends on: 2.1

  • 2.6 Enforce dispute hold before payout and release operations pending medium

    Add payment hold state and central release/refund guards that block disputed funds.

    Depends on: 2.1, 2.4

  • 2.7 Align documentation, API references, and runtime enums pending medium

    Normalize disputed/payment/request status docs and implementation references after security behavior changes.

    Depends on: 2.1, 2.2, 2.3, 2.4, 2.5, 2.6

Task 3

Migrate payment architecture toward Request Network and internal funds management

pendinghigh

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 and test strategy

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.

Test strategy: 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.

Depends on: 2

Subtasks (7)

  • 3.1 Introduce provider-neutral payment adapter pending high

    Decouple checkout, webhook, and payout flows from SHKeeper-specific routes and metadata.

  • 3.2 Implement Request Network pay-in integration pending high

    Create Request Network payment requests or Secure Payment Pages for new checkout flows.

    Depends on: 3.1

  • 3.3 Add funds ledger and escrow state machine pending high

    Introduce internal funds accounting independent from provider metadata.

    Depends on: 3.1

  • 3.4 Build Request Network webhook and reconciliation service pending high

    Process signed Request Network events and repair missed webhook state through reconciliation.

    Depends on: 3.2, 3.3

  • 3.5 Implement release, refund, and payout orchestration pending high

    Replace SHKeeper payout tasks and simulated release with auditable transaction instruction and confirmation flows.

    Depends on: 3.3, 3.4

  • 3.6 Migrate frontend checkout and admin payment UI pending medium

    Update buyer checkout, admin release, seller payout, and payment details for provider-neutral Request Network flows.

    Depends on: 3.2, 3.3, 3.5

  • 3.7 Backfill legacy SHKeeper records and decommission provider-specific code pending medium

    Migrate historical SHKeeper payment metadata and safely remove legacy wallet monitor/webhook/payout paths after cutoff.

    Depends on: 3.3, 3.4, 3.5, 3.6

Task 4

Define backend security and refactor strategy from latest audit

pendinghigh

Convert the backend stack security/refactor assessment into concrete architecture decisions, documentation deliverables, and developer handoff criteria.

Details and test strategy

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.

Test strategy: Review and sign off each architecture document with backend, payments, frontend, and operations stakeholders. Confirm every open question has an owner or explicit deferred decision before implementation work begins.

Subtasks (9)

  • 4.1 Assign security ownership and launch decision criteria pending high

    Define who owns security decisions and what must be true before public launch or migration work proceeds.

  • 4.2 Produce threat model for escrow platform pending high

    Document protected assets, actors, trust boundaries, and abuse cases for the financial marketplace.

    Depends on: 4.1

  • 4.3 Specify funds ledger and escrow state machine pending high

    Define canonical money movement and legal state transitions before refactor or provider migration.

    Depends on: 4.2

  • 4.4 Create authorization matrix for REST and Socket.IO pending high

    Map every endpoint and realtime event to access level, ownership checks, state preconditions, rate-limit tier, and audit-log requirement.

    Depends on: 4.2

  • 4.5 Decide session, passkey, and admin step-up architecture pending high

    Choose browser session model and high-risk admin authentication requirements.

    Depends on: 4.2

  • 4.6 Specify webhook security and provider adapter contracts pending high

    Define provider-neutral payment interface and signed webhook processing rules.

    Depends on: 4.3

  • 4.7 Define secure build and supply-chain policy pending medium

    Reduce npm/dependency compromise risk across frontend and any remaining Node services.

    Depends on: 4.1

  • 4.8 Make backend-core stack decision pending medium

    Choose whether the security-critical backend core remains TypeScript or moves to Go/Kotlin/Rust/Python.

    Depends on: 4.2, 4.3, 4.4, 4.5, 4.6, 4.7

  • 4.9 Create migration and operational runbooks pending medium

    Document rollout, rollback, and incident response for the selected backend/funds architecture.

    Depends on: 4.8

Task 5

Deliver Telegram-native app, bot, and wallet experience

pendinghigh

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 and test strategy

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.

Test strategy: 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.

Subtasks (9)

  • 5.1 Define Telegram product surface and flow map pending high

    Document which Amanat workflows live in bot messages, which live in the Mini App, and which remain web/admin-only for first release.

  • 5.2 Build Telegram identity linking and session model pending high

    Implement secure account linking between Telegram users and Amanat accounts.

    Depends on: 5.1

  • 5.3 Implement bot command and notification foundation pending high

    Create the Telegram bot backend for commands, inline keyboards, callback queries, deep links, and outbound notifications.

    Depends on: 5.1, 5.2

  • 5.4 Build Telegram Mini App shell for marketplace workflows pending high

    Deliver the mobile-first Mini App that gives users the full Amanat workflow surface inside Telegram.

    Depends on: 5.1, 5.2

  • 5.5 Add Telegram payment and wallet strategy pending high

    Evaluate and implement safe payment entry points for Telegram-native users without weakening escrow accounting.

    Depends on: 5.2, 5.4

  • 5.6 Expose escrow, delivery, dispute, and release actions safely pending high

    Make Telegram actions useful for real escrow work while preserving backend state authority.

    Depends on: 5.4, 5.5

  • 5.7 Add admin and support surface for Telegram-originated cases pending high

    Give support/admin users visibility and controls for Telegram-originated users, payments, and bot events.

    Depends on: 5.2, 5.3, 5.5

  • 5.8 Add security, compliance, and abuse controls for Telegram pending high

    Threat-model the Telegram surface and add controls before launch.

    Depends on: 5.2, 5.3, 5.5, 5.6

  • 5.9 Prepare QA, rollout, analytics, and launch operations pending high

    Prepare the Telegram app and bot for controlled release.

    Depends on: 5.3, 5.4, 5.5, 5.6, 5.7, 5.8

Task 1

Stabilize Mermaid diagram rendering across documentation vault

donemedium

Correct Mermaid syntax/rendering issues across the documentation vault and validate all Mermaid blocks.

Details and test strategy

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.

Test strategy: Run the same mmdc-based syntax validation across all Markdown Mermaid blocks and confirm zero parser failures in Obsidian/markdown previews.

Subtasks (3)

  • 1.1 Fix Security Architecture email/password sequence done medium

    Normalize parser-sensitive sequence text in 01 - Architecture/Security Architecture.md.

  • 1.2 Fix authentication login and refresh diagrams done medium

    Normalize parser-sensitive token and refresh-token sequence text in Authentication Flow.

  • 1.3 Fix chat, delivery, dispute, OAuth, purchase request, referral, registration, and seller-offer diagrams done medium

    Clean the remaining Mermaid sequence diagrams with invalid or ambiguous syntax.