Amanat Taskmaster Queue

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 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.