User flagged: a buyer's cart can span multiple sellers, so 'per-(buyer, seller)' isn't really 1:1. The right framing is per-Payment: Amanat already creates N Payment records for an N-seller cart (one per sellerOfferId), and each gets its own derived destination + RN intent + buyer-side approve+pay tx pair. PRD now explicitly: - Recommends per-Payment keying (which collapses to per-(buyer, sellerOfferId) via the existing uniq_pending_request_network_by_buyer_session index) - Documents the multi-seller cart UX (N approve+pay pairs in sequence, with clear progress indicator, mid-cart abandonment is fine) - Notes RN's ERC20FeeProxy is single-destination by design (no atomic split in v1; future Amanat splitter contract is out of scope) - Updates open questions to monotonic derivation counter, immediate sweep, single-use addresses (no rotation), and cold-payment recovery - Scope explicitly mentions cart-aware buyer UX as part of task #7 Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Taskmaster workspace for Amanat PRDs
This docs-side Taskmaster setup tracks the product/security PRDs from the documentation vault.
Source PRDs
prd-mermaid-diagram-rendering-stabilization.mdprd-platform-audit-remediation-plan-2026-05-24.mdprd-request-network-migration-and-funds-management.md
Usage
From nick-doc, developers can use Taskmaster-compatible tooling against .taskmaster/tasks/tasks.json.
Common commands, once task-master-ai is installed/configured:
task-master list
task-master show 2
task-master show 3.4
task-master next
task-master set-status --id=2.1 --status=in-progress
The Mermaid PRD is already marked done because its source PRD records the full parser sweep as passing. The security and migration PRDs are pending implementation.
No API keys are committed here. Configure API keys locally or in MCP/editor config if AI-assisted Taskmaster commands are needed.