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.