From b84abb4d7563ab4c9c1df7bd0511c2fb0f9c10d5 Mon Sep 17 00:00:00 2001 From: Siavash Sameni Date: Sun, 24 May 2026 09:13:34 +0400 Subject: [PATCH] docs: add vercel taskmaster share site --- taskmaster-share/README.md | 11 + taskmaster-share/index.html | 549 +++++++++++++++++++++++++++++++++++ taskmaster-share/tasks.json | 384 ++++++++++++++++++++++++ taskmaster-share/vercel.json | 12 + 4 files changed, 956 insertions(+) create mode 100644 taskmaster-share/README.md create mode 100644 taskmaster-share/index.html create mode 100644 taskmaster-share/tasks.json create mode 100644 taskmaster-share/vercel.json diff --git a/taskmaster-share/README.md b/taskmaster-share/README.md new file mode 100644 index 0000000..de27486 --- /dev/null +++ b/taskmaster-share/README.md @@ -0,0 +1,11 @@ +# Amanat Taskmaster share site + +Static Vercel share page for the docs-side Taskmaster queue. + +Generated from `../.taskmaster/tasks/tasks.json`. + +Files: + +- `index.html`: readable task dashboard +- `tasks.json`: raw task data for developers/agents +- `vercel.json`: static deployment config diff --git a/taskmaster-share/index.html b/taskmaster-share/index.html new file mode 100644 index 0000000..922bbc0 --- /dev/null +++ b/taskmaster-share/index.html @@ -0,0 +1,549 @@ + + + + + + Amanat Taskmaster Queue + + + +
+
+
+

Amanat docs ยท Taskmaster

+

Developer task queue

+

A shareable static view of the docs-side Taskmaster queue generated from the PRDs and latest backend security/refactor audit. Use this page for planning; use Taskmaster CLI for status updates.

+
+ +
+
+
+
+ + + + Raw JSON +
+
+
+
+
+

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.

    + +
+
+
+ + + + diff --git a/taskmaster-share/tasks.json b/taskmaster-share/tasks.json new file mode 100644 index 0000000..d5d9953 --- /dev/null +++ b/taskmaster-share/tasks.json @@ -0,0 +1,384 @@ +{ + "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, + "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.", + "testStrategy": "Run the same mmdc-based syntax validation across all Markdown Mermaid blocks and confirm zero parser failures in Obsidian/markdown previews.", + "priority": "medium", + "status": "done", + "dependencies": [], + "subtasks": [ + { + "id": 1, + "title": "Fix Security Architecture email/password sequence", + "description": "Normalize parser-sensitive sequence text in 01 - Architecture/Security Architecture.md.", + "details": "Avoid semicolons and ambiguous inline punctuation in sequence messages.", + "status": "done", + "priority": "medium", + "dependencies": [], + "testStrategy": "mmdc parse for the specific block." + }, + { + "id": 2, + "title": "Fix authentication login and refresh diagrams", + "description": "Normalize parser-sensitive token and refresh-token sequence text in Authentication Flow.", + "details": "Split method-like or expression-like message text into parser-safe plain text lines.", + "status": "done", + "priority": "medium", + "dependencies": [], + "testStrategy": "mmdc parse for both Authentication Flow blocks." + }, + { + "id": 3, + "title": "Fix chat, delivery, dispute, OAuth, purchase request, referral, registration, and seller-offer diagrams", + "description": "Clean the remaining Mermaid sequence diagrams with invalid or ambiguous syntax.", + "details": "Split multi-recipient arrows, remove parser-conflicting semicolon/expression text, and keep intent unchanged.", + "status": "done", + "priority": "medium", + "dependencies": [], + "testStrategy": "Full vault mmdc parser sweep across all Mermaid blocks." + } + ] + }, + { + "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.", + "testStrategy": "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.", + "priority": "high", + "status": "pending", + "dependencies": [], + "subtasks": [ + { + "id": 1, + "title": "Secure unauthenticated endpoints and owner enforcement", + "description": "Require authenticateToken and owner/admin checks on exposed payment, AI, and legacy notification routes.", + "details": "Derive notification userId from authenticated principal. Protect payment history and mutation endpoints. Restrict AI calls to authenticated users with per-user budgets. Add denied-access audit logs.", + "status": "pending", + "priority": "high", + "dependencies": [], + "testStrategy": "Unauthorized callers receive 401/403; users cannot access or mutate other users' payments/notifications; admins retain authorized access." + }, + { + "id": 2, + "title": "Re-enable and scope rate limiting", + "description": "Restore global and route-tiered rate limits for public-sensitive paths.", + "details": "Use stricter limits for auth, financial, AI, file upload, and verification paths. Keep public reads at relaxed limits. Add observability for 429 spikes.", + "status": "pending", + "priority": "high", + "dependencies": [ + 1 + ], + "testStrategy": "Exercise configured limits per tier and confirm expected 429 responses without blocking ordinary reads." + }, + { + "id": 3, + "title": "Replace stubbed passkey/WebAuthn flow", + "description": "Implement production-grade WebAuthn registration/authentication and shared challenge storage.", + "details": "Use real attestation/assertion verification, Redis-backed TTL challenges, refresh-token persistence/rotation, and deterministic malformed/reused/expired challenge errors.", + "status": "pending", + "priority": "high", + "dependencies": [ + 1 + ], + "testStrategy": "Registration, login, replay, expired challenge, and refresh-token continuity tests pass." + }, + { + "id": 4, + "title": "Strengthen DePay/Web3 payment verification", + "description": "Verify transaction recipient, token contract, and amount, not only receipt success.", + "details": "Decode ERC-20 Transfer logs, compare recipient against escrow address, validate token contract and decimals-adjusted minimum amount, store verifier evidence and idempotency fingerprint.", + "status": "pending", + "priority": "high", + "dependencies": [ + 1 + ], + "testStrategy": "Reject successful but wrong-recipient/wrong-token/underpaid tx hashes; accept only matching transfers." + }, + { + "id": 5, + "title": "Lock Socket.IO room joins to authenticated context", + "description": "Remove trust in client-supplied user/buyer/seller room IDs.", + "details": "Validate socket handshake token, derive server-side room membership, reject mismatched joins, and monitor suspicious join attempts.", + "status": "pending", + "priority": "medium", + "dependencies": [ + 1 + ], + "testStrategy": "A user cannot subscribe to another user's rooms; legitimate realtime notifications still arrive." + }, + { + "id": 6, + "title": "Enforce dispute hold before payout and release operations", + "description": "Add payment hold state and central release/refund guards that block disputed funds.", + "details": "Introduce explicit dispute hold fields or state, enforce in PaymentCoordinator and payout/release services, return clear 409/423 responses, and backfill/report blocked payments.", + "status": "pending", + "priority": "medium", + "dependencies": [ + 1, + 4 + ], + "testStrategy": "Open dispute blocks release/refund until resolved or explicitly overridden through authorized path." + }, + { + "id": 7, + "title": "Align documentation, API references, and runtime enums", + "description": "Normalize disputed/payment/request status docs and implementation references after security behavior changes.", + "details": "Resolve mismatch around absent dispute module, endpoint names, status enums, and action names across Data Models, API Reference, and Flows.", + "status": "pending", + "priority": "medium", + "dependencies": [ + 1, + 2, + 3, + 4, + 5, + 6 + ], + "testStrategy": "Docs match implemented routes, models, enum values, and state transitions." + } + ] + }, + { + "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", + "dependencies": [ + 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.", + "status": "pending", + "priority": "high", + "dependencies": [], + "testStrategy": "New provider can be selected by feature flag while existing SHKeeper payments remain readable and process late webhooks." + }, + { + "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.", + "status": "pending", + "priority": "high", + "dependencies": [ + 1 + ], + "testStrategy": "Buyer receives hosted payment URL; webhook reconciles matching internal payment only after amount/currency/reference validation." + }, + { + "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.", + "status": "pending", + "priority": "high", + "dependencies": [ + 1 + ], + "testStrategy": "Every pay-in creates immutable ledger entries and payout/refund cannot exceed available held funds or bypass dispute holds." + }, + { + "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.", + "status": "pending", + "priority": "high", + "dependencies": [ + 2, + 3 + ], + "testStrategy": "Invalid signatures reject; duplicate delivery IDs acknowledge without duplicate ledger entries; reconciliation repairs missed state." + }, + { + "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.", + "status": "pending", + "priority": "high", + "dependencies": [ + 3, + 4 + ], + "testStrategy": "Release cannot occur if unpaid, already released, refunded, or disputed; tx hash confirmation updates ledger once; admin can retry/cancel safely." + }, + { + "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.", + "status": "pending", + "priority": "medium", + "dependencies": [ + 2, + 3, + 5 + ], + "testStrategy": "Request Network checkout does not expect walletAddress; admin UI blocks unsafe release; legacy labels are hidden for Request Network records." + }, + { + "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.", + "status": "pending", + "priority": "medium", + "dependencies": [ + 3, + 4, + 5, + 6 + ], + "testStrategy": "Dry-run report includes total, migrated, skipped, ambiguous, failed; no historical transaction hash/invoice/task metadata is lost." + } + ] + }, + { + "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.", + "testStrategy": "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.", + "priority": "high", + "status": "pending", + "dependencies": [], + "subtasks": [ + { + "id": 1, + "title": "Assign security ownership and launch decision criteria", + "description": "Define who owns security decisions and what must be true before public launch or migration work proceeds.", + "details": "Answer ownership questions from the audit: security owner, launch safety bar, whether launch prioritizes hardening or redesign, and whether external penetration testing is required.", + "status": "pending", + "priority": "high", + "dependencies": [], + "testStrategy": "Written owner/RACI and launch gate checklist are accepted by leadership and engineering." + }, + { + "id": 2, + "title": "Produce threat model for escrow platform", + "description": "Document protected assets, actors, trust boundaries, and abuse cases for the financial marketplace.", + "details": "Include buyer, seller, admin, support, unauthenticated attacker, compromised user/admin, provider, malicious webhook sender, browser/backend/database/Redis/provider/wallet/Socket.IO trust boundaries, and abuse cases such as fake payment proof, replayed webhook, arbitrary room join, stolen token, double payout, dispute bypass, email abuse, and AI abuse.", + "status": "pending", + "priority": "high", + "dependencies": [ + 1 + ], + "testStrategy": "Threat model maps each high-risk finding to at least one mitigation task or accepted risk." + }, + { + "id": 3, + "title": "Specify funds ledger and escrow state machine", + "description": "Define canonical money movement and legal state transitions before refactor or provider migration.", + "details": "Create specs for FundsAccount, LedgerEntry, FundsBalance, gross paid, provider fees, platform fees, held, disputed, releasable, released, refunded, idempotency keys, reconciliation behavior, purchase request states, payment states, escrow/funds states, dispute states, valid transitions, forbidden transitions, and release/refund/admin override preconditions.", + "status": "pending", + "priority": "high", + "dependencies": [ + 2 + ], + "testStrategy": "Spec can be used to reject double-release, release-during-dispute, underfunded payout, and ambiguous provider-event scenarios." + }, + { + "id": 4, + "title": "Create authorization matrix for REST and Socket.IO", + "description": "Map every endpoint and realtime event to access level, ownership checks, state preconditions, rate-limit tier, and audit-log requirement.", + "details": "Include public/authenticated/owner/buyer/seller/admin/support/service-role classifications. Socket.IO rooms must be server-derived from authenticated identity, not client-supplied user IDs.", + "status": "pending", + "priority": "high", + "dependencies": [ + 2 + ], + "testStrategy": "No route or socket event remains unmapped; implementation tasks can reference matrix rows directly." + }, + { + "id": 5, + "title": "Decide session, passkey, and admin step-up architecture", + "description": "Choose browser session model and high-risk admin authentication requirements.", + "details": "Decide localStorage versus httpOnly cookies, access/refresh token lifetimes, CSRF strategy, refresh rotation, WebAuthn requirements, OAuth requirements, device/session revocation, and whether payouts/role changes require step-up authentication or two-person approval.", + "status": "pending", + "priority": "high", + "dependencies": [ + 2 + ], + "testStrategy": "Decision record lists chosen model, rejected alternatives, migration cost, and required implementation tasks." + }, + { + "id": 6, + "title": "Specify webhook security and provider adapter contracts", + "description": "Define provider-neutral payment interface and signed webhook processing rules.", + "details": "Document createPayInIntent, getPayInStatus, handleProviderWebhook, createHostedPaymentLink, createReleaseInstruction, createRefundInstruction, getPayoutStatus, searchProviderPayments, raw-body signature verification, replay prevention, delivery ID idempotency, duplicate/unknown event behavior, retry semantics, dead-letter/replay storage, and alert thresholds.", + "status": "pending", + "priority": "high", + "dependencies": [ + 3 + ], + "testStrategy": "Contracts cover SHKeeper legacy, Request Network, manual/admin wallet, invalid signatures, duplicate deliveries, and missed webhook reconciliation." + }, + { + "id": 7, + "title": "Define secure build and supply-chain policy", + "description": "Reduce npm/dependency compromise risk across frontend and any remaining Node services.", + "details": "Specify package manager and lockfile policy, CI install mode, dependency update cadence, advisory monitoring, npm provenance/signature policy where available, secrets handling, reproducible production builds, and separation between frontend npm risk and backend-core risk.", + "status": "pending", + "priority": "medium", + "dependencies": [ + 1 + ], + "testStrategy": "Policy is actionable in CI and includes response steps for compromised package, leaked token, and vulnerable dependency alerts." + }, + { + "id": 8, + "title": "Make backend-core stack decision", + "description": "Choose whether the security-critical backend core remains TypeScript or moves to Go/Kotlin/Rust/Python.", + "details": "Evaluate team capability, two-year maintainability, operational footprint, rewrite cost, dual-stack complexity, auditability, supply-chain exposure, and which modules belong in a payment/auth/escrow core versus the existing marketplace/chat API.", + "status": "pending", + "priority": "medium", + "dependencies": [ + 2, + 3, + 4, + 5, + 6, + 7 + ], + "testStrategy": "Architecture decision record states chosen stack, scope of extraction, non-goals, migration phases, rollback criteria, and owners." + }, + { + "id": 9, + "title": "Create migration and operational runbooks", + "description": "Document rollout, rollback, and incident response for the selected backend/funds architecture.", + "details": "Include SHKeeper legacy read path, provider feature flag, ledger backfill, validation report before enforcement, rollback criteria, webhook cutoff, manual reconciliation, failed webhook, duplicate/missing payment, stuck release, disputed release attempt, compromised admin, leaked API key, provider outage, chain/RPC outage, suspicious payment proof, and npm/package compromise.", + "status": "pending", + "priority": "medium", + "dependencies": [ + 8 + ], + "testStrategy": "Runbooks identify owner, trigger, detection signal, immediate action, recovery action, and post-incident documentation for each scenario." + } + ] + } + ] +} diff --git a/taskmaster-share/vercel.json b/taskmaster-share/vercel.json new file mode 100644 index 0000000..4c183e2 --- /dev/null +++ b/taskmaster-share/vercel.json @@ -0,0 +1,12 @@ +{ + "cleanUrls": true, + "headers": [ + { + "source": "/(.*)", + "headers": [ + { "key": "X-Content-Type-Options", "value": "nosniff" }, + { "key": "Referrer-Policy", "value": "strict-origin-when-cross-origin" } + ] + } + ] +}