docs: add vercel taskmaster share site
This commit is contained in:
Siavash Sameni
11
taskmaster-share/README.md
Normal file
11
taskmaster-share/README.md
Normal file
@@ -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
|
||||
549
taskmaster-share/index.html
Normal file
549
taskmaster-share/index.html
Normal file
@@ -0,0 +1,549 @@
|
||||
<!doctype html>
|
||||
<html lang="en">
|
||||
<head>
|
||||
<meta charset="utf-8" />
|
||||
<meta name="viewport" content="width=device-width, initial-scale=1" />
|
||||
<title>Amanat Taskmaster Queue</title>
|
||||
<style>
|
||||
:root {
|
||||
--ink: #172018;
|
||||
--muted: #667064;
|
||||
--paper: #fbf6e8;
|
||||
--panel: #fffdf5;
|
||||
--line: #ded5bd;
|
||||
--green: #1c7c54;
|
||||
--amber: #b7791f;
|
||||
--red: #b42318;
|
||||
--blue: #245b84;
|
||||
--shadow: 0 18px 60px rgba(39, 32, 18, 0.14);
|
||||
}
|
||||
* { box-sizing: border-box; }
|
||||
body {
|
||||
margin: 0;
|
||||
font-family: ui-serif, Georgia, Cambria, "Times New Roman", serif;
|
||||
color: var(--ink);
|
||||
background:
|
||||
radial-gradient(circle at 15% 10%, rgba(28, 124, 84, 0.18), transparent 28rem),
|
||||
radial-gradient(circle at 90% 5%, rgba(183, 121, 31, 0.16), transparent 24rem),
|
||||
linear-gradient(135deg, #f7efd9 0%, #fbf6e8 48%, #edf4ea 100%);
|
||||
min-height: 100vh;
|
||||
}
|
||||
header {
|
||||
padding: 48px clamp(18px, 4vw, 64px) 28px;
|
||||
border-bottom: 1px solid rgba(80, 67, 41, 0.18);
|
||||
}
|
||||
.hero {
|
||||
max-width: 1180px;
|
||||
margin: 0 auto;
|
||||
display: grid;
|
||||
grid-template-columns: minmax(0, 1.3fr) minmax(280px, 0.7fr);
|
||||
gap: 28px;
|
||||
align-items: end;
|
||||
}
|
||||
h1 {
|
||||
font-size: clamp(2.4rem, 6vw, 5.8rem);
|
||||
line-height: 0.9;
|
||||
letter-spacing: -0.06em;
|
||||
margin: 0;
|
||||
}
|
||||
.lead {
|
||||
color: var(--muted);
|
||||
font-size: 1.1rem;
|
||||
max-width: 760px;
|
||||
line-height: 1.65;
|
||||
margin: 22px 0 0;
|
||||
}
|
||||
.stats {
|
||||
display: grid;
|
||||
grid-template-columns: repeat(2, minmax(0, 1fr));
|
||||
gap: 12px;
|
||||
}
|
||||
.stat {
|
||||
background: rgba(255, 253, 245, 0.78);
|
||||
border: 1px solid var(--line);
|
||||
border-radius: 22px;
|
||||
padding: 18px;
|
||||
box-shadow: var(--shadow);
|
||||
}
|
||||
.stat strong { display: block; font-size: 2.1rem; line-height: 1; }
|
||||
.stat span { color: var(--muted); font-size: 0.9rem; }
|
||||
main {
|
||||
max-width: 1180px;
|
||||
margin: 0 auto;
|
||||
padding: 28px clamp(18px, 4vw, 64px) 64px;
|
||||
}
|
||||
.toolbar {
|
||||
display: flex;
|
||||
gap: 12px;
|
||||
flex-wrap: wrap;
|
||||
align-items: center;
|
||||
margin-bottom: 22px;
|
||||
}
|
||||
input, select, a.button {
|
||||
border: 1px solid var(--line);
|
||||
background: rgba(255, 253, 245, 0.86);
|
||||
border-radius: 999px;
|
||||
padding: 12px 16px;
|
||||
color: var(--ink);
|
||||
font: inherit;
|
||||
text-decoration: none;
|
||||
}
|
||||
input { min-width: min(100%, 360px); flex: 1; }
|
||||
.task {
|
||||
background: rgba(255, 253, 245, 0.9);
|
||||
border: 1px solid var(--line);
|
||||
border-radius: 30px;
|
||||
padding: clamp(20px, 3vw, 32px);
|
||||
box-shadow: var(--shadow);
|
||||
margin: 18px 0;
|
||||
}
|
||||
.task-head, .subtask-top {
|
||||
display: flex;
|
||||
justify-content: space-between;
|
||||
gap: 16px;
|
||||
align-items: flex-start;
|
||||
}
|
||||
.eyebrow {
|
||||
color: var(--green);
|
||||
font-family: ui-monospace, SFMono-Regular, Menlo, monospace;
|
||||
margin: 0 0 6px;
|
||||
text-transform: uppercase;
|
||||
letter-spacing: 0.12em;
|
||||
font-size: 0.78rem;
|
||||
}
|
||||
h2 { font-size: clamp(1.45rem, 3vw, 2.4rem); line-height: 1; margin: 0; letter-spacing: -0.035em; }
|
||||
h3 { margin: 24px 0 10px; }
|
||||
.desc, details p, .subtask p { color: var(--muted); line-height: 1.55; }
|
||||
details {
|
||||
border-top: 1px solid var(--line);
|
||||
border-bottom: 1px solid var(--line);
|
||||
padding: 14px 0;
|
||||
margin-top: 18px;
|
||||
}
|
||||
summary { cursor: pointer; color: var(--blue); font-weight: 700; }
|
||||
.badges { display: flex; gap: 8px; flex-wrap: wrap; justify-content: flex-end; }
|
||||
.badge {
|
||||
display: inline-flex;
|
||||
align-items: center;
|
||||
border-radius: 999px;
|
||||
padding: 5px 10px;
|
||||
font: 700 0.78rem/1 ui-monospace, SFMono-Regular, Menlo, monospace;
|
||||
background: #ece5d2;
|
||||
color: var(--ink);
|
||||
margin-left: 6px;
|
||||
white-space: nowrap;
|
||||
}
|
||||
.done { background: rgba(28, 124, 84, 0.13); color: var(--green); }
|
||||
.pending { background: rgba(183, 121, 31, 0.14); color: var(--amber); }
|
||||
.in-progress { background: rgba(36, 91, 132, 0.13); color: var(--blue); }
|
||||
.blocked, .critical { background: rgba(180, 35, 24, 0.12); color: var(--red); }
|
||||
.priority-high { background: rgba(180, 35, 24, 0.12); color: var(--red); }
|
||||
.priority-medium { background: rgba(183, 121, 31, 0.14); color: var(--amber); }
|
||||
.priority-low { background: rgba(102, 112, 100, 0.12); color: var(--muted); }
|
||||
.subtasks { list-style: none; padding: 0; margin: 0; display: grid; gap: 10px; }
|
||||
.subtask {
|
||||
border: 1px solid rgba(80, 67, 41, 0.16);
|
||||
border-radius: 18px;
|
||||
padding: 14px;
|
||||
background: rgba(247, 239, 217, 0.48);
|
||||
}
|
||||
.sub-id {
|
||||
font-family: ui-monospace, SFMono-Regular, Menlo, monospace;
|
||||
color: var(--green);
|
||||
font-weight: 800;
|
||||
min-width: 42px;
|
||||
}
|
||||
.deps { font-size: 0.9rem; color: var(--blue) !important; }
|
||||
footer { color: var(--muted); text-align: center; padding: 30px; }
|
||||
@media (max-width: 760px) {
|
||||
.hero { grid-template-columns: 1fr; }
|
||||
.stats { grid-template-columns: repeat(2, 1fr); }
|
||||
.task-head, .subtask-top { flex-direction: column; }
|
||||
.badges { justify-content: flex-start; }
|
||||
}
|
||||
</style>
|
||||
</head>
|
||||
<body>
|
||||
<header>
|
||||
<section class="hero">
|
||||
<div>
|
||||
<p class="eyebrow">Amanat docs · Taskmaster</p>
|
||||
<h1>Developer task queue</h1>
|
||||
<p class="lead">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.</p>
|
||||
</div>
|
||||
<aside class="stats">
|
||||
<div class="stat"><strong>4</strong><span>parent tasks</span></div>
|
||||
<div class="stat"><strong>26</strong><span>subtasks</span></div>
|
||||
<div class="stat"><strong>26</strong><span>pending items</span></div>
|
||||
<div class="stat"><strong>4</strong><span>done items</span></div>
|
||||
</aside>
|
||||
</section>
|
||||
</header>
|
||||
<main>
|
||||
<div class="toolbar">
|
||||
<input id="search" type="search" placeholder="Search tasks, subtasks, PRDs..." />
|
||||
<select id="status"><option value="">All statuses</option><option>pending</option><option>done</option><option>in-progress</option><option>blocked</option></select>
|
||||
<select id="priority"><option value="">All priorities</option><option>high</option><option>medium</option><option>low</option></select>
|
||||
<a class="button" href="tasks.json">Raw JSON</a>
|
||||
</div>
|
||||
<section id="tasks">
|
||||
<article class="task" data-status="pending" data-priority="high">
|
||||
<div class="task-head">
|
||||
<div>
|
||||
<p class="eyebrow">Task 2</p>
|
||||
<h2>Implement platform audit remediation plan</h2>
|
||||
</div>
|
||||
<div class="badges"><span class="badge pending">pending</span><span class="badge priority-high">high</span></div>
|
||||
</div>
|
||||
<p class="desc">Address the code-backed security and consistency issues identified in the 2026-05-24 platform audit remediation PRD.</p>
|
||||
<details>
|
||||
<summary>Details and test strategy</summary>
|
||||
<p>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.</p>
|
||||
<p><strong>Test strategy:</strong> 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.</p>
|
||||
|
||||
</details>
|
||||
<h3>Subtasks (7)</h3>
|
||||
<ul class="subtasks">
|
||||
<li class="subtask" data-status="pending" data-priority="high">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">2.1</span>
|
||||
<strong>Secure unauthenticated endpoints and owner enforcement</strong>
|
||||
<span class="badge pending">pending</span>
|
||||
<span class="badge priority-high">high</span>
|
||||
</div>
|
||||
<p>Require authenticateToken and owner/admin checks on exposed payment, AI, and legacy notification routes.</p>
|
||||
|
||||
</li>
|
||||
<li class="subtask" data-status="pending" data-priority="high">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">2.2</span>
|
||||
<strong>Re-enable and scope rate limiting</strong>
|
||||
<span class="badge pending">pending</span>
|
||||
<span class="badge priority-high">high</span>
|
||||
</div>
|
||||
<p>Restore global and route-tiered rate limits for public-sensitive paths.</p>
|
||||
<p class="deps">Depends on: 2.1</p>
|
||||
</li>
|
||||
<li class="subtask" data-status="pending" data-priority="high">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">2.3</span>
|
||||
<strong>Replace stubbed passkey/WebAuthn flow</strong>
|
||||
<span class="badge pending">pending</span>
|
||||
<span class="badge priority-high">high</span>
|
||||
</div>
|
||||
<p>Implement production-grade WebAuthn registration/authentication and shared challenge storage.</p>
|
||||
<p class="deps">Depends on: 2.1</p>
|
||||
</li>
|
||||
<li class="subtask" data-status="pending" data-priority="high">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">2.4</span>
|
||||
<strong>Strengthen DePay/Web3 payment verification</strong>
|
||||
<span class="badge pending">pending</span>
|
||||
<span class="badge priority-high">high</span>
|
||||
</div>
|
||||
<p>Verify transaction recipient, token contract, and amount, not only receipt success.</p>
|
||||
<p class="deps">Depends on: 2.1</p>
|
||||
</li>
|
||||
<li class="subtask" data-status="pending" data-priority="medium">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">2.5</span>
|
||||
<strong>Lock Socket.IO room joins to authenticated context</strong>
|
||||
<span class="badge pending">pending</span>
|
||||
<span class="badge priority-medium">medium</span>
|
||||
</div>
|
||||
<p>Remove trust in client-supplied user/buyer/seller room IDs.</p>
|
||||
<p class="deps">Depends on: 2.1</p>
|
||||
</li>
|
||||
<li class="subtask" data-status="pending" data-priority="medium">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">2.6</span>
|
||||
<strong>Enforce dispute hold before payout and release operations</strong>
|
||||
<span class="badge pending">pending</span>
|
||||
<span class="badge priority-medium">medium</span>
|
||||
</div>
|
||||
<p>Add payment hold state and central release/refund guards that block disputed funds.</p>
|
||||
<p class="deps">Depends on: 2.1, 2.4</p>
|
||||
</li>
|
||||
<li class="subtask" data-status="pending" data-priority="medium">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">2.7</span>
|
||||
<strong>Align documentation, API references, and runtime enums</strong>
|
||||
<span class="badge pending">pending</span>
|
||||
<span class="badge priority-medium">medium</span>
|
||||
</div>
|
||||
<p>Normalize disputed/payment/request status docs and implementation references after security behavior changes.</p>
|
||||
<p class="deps">Depends on: 2.1, 2.2, 2.3, 2.4, 2.5, 2.6</p>
|
||||
</li></ul>
|
||||
</article>
|
||||
|
||||
<article class="task" data-status="pending" data-priority="high">
|
||||
<div class="task-head">
|
||||
<div>
|
||||
<p class="eyebrow">Task 3</p>
|
||||
<h2>Migrate payment architecture toward Request Network and internal funds management</h2>
|
||||
</div>
|
||||
<div class="badges"><span class="badge pending">pending</span><span class="badge priority-high">high</span></div>
|
||||
</div>
|
||||
<p class="desc">Plan and implement provider-neutral payment flows, Request Network pay-in support, funds ledger, webhook reconciliation, release/refund orchestration, UI migration, and SHKeeper decommissioning.</p>
|
||||
<details>
|
||||
<summary>Details and test strategy</summary>
|
||||
<p>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.</p>
|
||||
<p><strong>Test strategy:</strong> 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.</p>
|
||||
<p><strong>Depends on:</strong> 2</p>
|
||||
</details>
|
||||
<h3>Subtasks (7)</h3>
|
||||
<ul class="subtasks">
|
||||
<li class="subtask" data-status="pending" data-priority="high">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">3.1</span>
|
||||
<strong>Introduce provider-neutral payment adapter</strong>
|
||||
<span class="badge pending">pending</span>
|
||||
<span class="badge priority-high">high</span>
|
||||
</div>
|
||||
<p>Decouple checkout, webhook, and payout flows from SHKeeper-specific routes and metadata.</p>
|
||||
|
||||
</li>
|
||||
<li class="subtask" data-status="pending" data-priority="high">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">3.2</span>
|
||||
<strong>Implement Request Network pay-in integration</strong>
|
||||
<span class="badge pending">pending</span>
|
||||
<span class="badge priority-high">high</span>
|
||||
</div>
|
||||
<p>Create Request Network payment requests or Secure Payment Pages for new checkout flows.</p>
|
||||
<p class="deps">Depends on: 3.1</p>
|
||||
</li>
|
||||
<li class="subtask" data-status="pending" data-priority="high">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">3.3</span>
|
||||
<strong>Add funds ledger and escrow state machine</strong>
|
||||
<span class="badge pending">pending</span>
|
||||
<span class="badge priority-high">high</span>
|
||||
</div>
|
||||
<p>Introduce internal funds accounting independent from provider metadata.</p>
|
||||
<p class="deps">Depends on: 3.1</p>
|
||||
</li>
|
||||
<li class="subtask" data-status="pending" data-priority="high">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">3.4</span>
|
||||
<strong>Build Request Network webhook and reconciliation service</strong>
|
||||
<span class="badge pending">pending</span>
|
||||
<span class="badge priority-high">high</span>
|
||||
</div>
|
||||
<p>Process signed Request Network events and repair missed webhook state through reconciliation.</p>
|
||||
<p class="deps">Depends on: 3.2, 3.3</p>
|
||||
</li>
|
||||
<li class="subtask" data-status="pending" data-priority="high">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">3.5</span>
|
||||
<strong>Implement release, refund, and payout orchestration</strong>
|
||||
<span class="badge pending">pending</span>
|
||||
<span class="badge priority-high">high</span>
|
||||
</div>
|
||||
<p>Replace SHKeeper payout tasks and simulated release with auditable transaction instruction and confirmation flows.</p>
|
||||
<p class="deps">Depends on: 3.3, 3.4</p>
|
||||
</li>
|
||||
<li class="subtask" data-status="pending" data-priority="medium">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">3.6</span>
|
||||
<strong>Migrate frontend checkout and admin payment UI</strong>
|
||||
<span class="badge pending">pending</span>
|
||||
<span class="badge priority-medium">medium</span>
|
||||
</div>
|
||||
<p>Update buyer checkout, admin release, seller payout, and payment details for provider-neutral Request Network flows.</p>
|
||||
<p class="deps">Depends on: 3.2, 3.3, 3.5</p>
|
||||
</li>
|
||||
<li class="subtask" data-status="pending" data-priority="medium">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">3.7</span>
|
||||
<strong>Backfill legacy SHKeeper records and decommission provider-specific code</strong>
|
||||
<span class="badge pending">pending</span>
|
||||
<span class="badge priority-medium">medium</span>
|
||||
</div>
|
||||
<p>Migrate historical SHKeeper payment metadata and safely remove legacy wallet monitor/webhook/payout paths after cutoff.</p>
|
||||
<p class="deps">Depends on: 3.3, 3.4, 3.5, 3.6</p>
|
||||
</li></ul>
|
||||
</article>
|
||||
|
||||
<article class="task" data-status="pending" data-priority="high">
|
||||
<div class="task-head">
|
||||
<div>
|
||||
<p class="eyebrow">Task 4</p>
|
||||
<h2>Define backend security and refactor strategy from latest audit</h2>
|
||||
</div>
|
||||
<div class="badges"><span class="badge pending">pending</span><span class="badge priority-high">high</span></div>
|
||||
</div>
|
||||
<p class="desc">Convert the backend stack security/refactor assessment into concrete architecture decisions, documentation deliverables, and developer handoff criteria.</p>
|
||||
<details>
|
||||
<summary>Details and test strategy</summary>
|
||||
<p>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.</p>
|
||||
<p><strong>Test strategy:</strong> 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.</p>
|
||||
|
||||
</details>
|
||||
<h3>Subtasks (9)</h3>
|
||||
<ul class="subtasks">
|
||||
<li class="subtask" data-status="pending" data-priority="high">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">4.1</span>
|
||||
<strong>Assign security ownership and launch decision criteria</strong>
|
||||
<span class="badge pending">pending</span>
|
||||
<span class="badge priority-high">high</span>
|
||||
</div>
|
||||
<p>Define who owns security decisions and what must be true before public launch or migration work proceeds.</p>
|
||||
|
||||
</li>
|
||||
<li class="subtask" data-status="pending" data-priority="high">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">4.2</span>
|
||||
<strong>Produce threat model for escrow platform</strong>
|
||||
<span class="badge pending">pending</span>
|
||||
<span class="badge priority-high">high</span>
|
||||
</div>
|
||||
<p>Document protected assets, actors, trust boundaries, and abuse cases for the financial marketplace.</p>
|
||||
<p class="deps">Depends on: 4.1</p>
|
||||
</li>
|
||||
<li class="subtask" data-status="pending" data-priority="high">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">4.3</span>
|
||||
<strong>Specify funds ledger and escrow state machine</strong>
|
||||
<span class="badge pending">pending</span>
|
||||
<span class="badge priority-high">high</span>
|
||||
</div>
|
||||
<p>Define canonical money movement and legal state transitions before refactor or provider migration.</p>
|
||||
<p class="deps">Depends on: 4.2</p>
|
||||
</li>
|
||||
<li class="subtask" data-status="pending" data-priority="high">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">4.4</span>
|
||||
<strong>Create authorization matrix for REST and Socket.IO</strong>
|
||||
<span class="badge pending">pending</span>
|
||||
<span class="badge priority-high">high</span>
|
||||
</div>
|
||||
<p>Map every endpoint and realtime event to access level, ownership checks, state preconditions, rate-limit tier, and audit-log requirement.</p>
|
||||
<p class="deps">Depends on: 4.2</p>
|
||||
</li>
|
||||
<li class="subtask" data-status="pending" data-priority="high">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">4.5</span>
|
||||
<strong>Decide session, passkey, and admin step-up architecture</strong>
|
||||
<span class="badge pending">pending</span>
|
||||
<span class="badge priority-high">high</span>
|
||||
</div>
|
||||
<p>Choose browser session model and high-risk admin authentication requirements.</p>
|
||||
<p class="deps">Depends on: 4.2</p>
|
||||
</li>
|
||||
<li class="subtask" data-status="pending" data-priority="high">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">4.6</span>
|
||||
<strong>Specify webhook security and provider adapter contracts</strong>
|
||||
<span class="badge pending">pending</span>
|
||||
<span class="badge priority-high">high</span>
|
||||
</div>
|
||||
<p>Define provider-neutral payment interface and signed webhook processing rules.</p>
|
||||
<p class="deps">Depends on: 4.3</p>
|
||||
</li>
|
||||
<li class="subtask" data-status="pending" data-priority="medium">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">4.7</span>
|
||||
<strong>Define secure build and supply-chain policy</strong>
|
||||
<span class="badge pending">pending</span>
|
||||
<span class="badge priority-medium">medium</span>
|
||||
</div>
|
||||
<p>Reduce npm/dependency compromise risk across frontend and any remaining Node services.</p>
|
||||
<p class="deps">Depends on: 4.1</p>
|
||||
</li>
|
||||
<li class="subtask" data-status="pending" data-priority="medium">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">4.8</span>
|
||||
<strong>Make backend-core stack decision</strong>
|
||||
<span class="badge pending">pending</span>
|
||||
<span class="badge priority-medium">medium</span>
|
||||
</div>
|
||||
<p>Choose whether the security-critical backend core remains TypeScript or moves to Go/Kotlin/Rust/Python.</p>
|
||||
<p class="deps">Depends on: 4.2, 4.3, 4.4, 4.5, 4.6, 4.7</p>
|
||||
</li>
|
||||
<li class="subtask" data-status="pending" data-priority="medium">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">4.9</span>
|
||||
<strong>Create migration and operational runbooks</strong>
|
||||
<span class="badge pending">pending</span>
|
||||
<span class="badge priority-medium">medium</span>
|
||||
</div>
|
||||
<p>Document rollout, rollback, and incident response for the selected backend/funds architecture.</p>
|
||||
<p class="deps">Depends on: 4.8</p>
|
||||
</li></ul>
|
||||
</article>
|
||||
|
||||
<article class="task" data-status="done" data-priority="medium">
|
||||
<div class="task-head">
|
||||
<div>
|
||||
<p class="eyebrow">Task 1</p>
|
||||
<h2>Stabilize Mermaid diagram rendering across documentation vault</h2>
|
||||
</div>
|
||||
<div class="badges"><span class="badge done">done</span><span class="badge priority-medium">medium</span></div>
|
||||
</div>
|
||||
<p class="desc">Correct Mermaid syntax/rendering issues across the documentation vault and validate all Mermaid blocks.</p>
|
||||
<details>
|
||||
<summary>Details and test strategy</summary>
|
||||
<p>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.</p>
|
||||
<p><strong>Test strategy:</strong> Run the same mmdc-based syntax validation across all Markdown Mermaid blocks and confirm zero parser failures in Obsidian/markdown previews.</p>
|
||||
|
||||
</details>
|
||||
<h3>Subtasks (3)</h3>
|
||||
<ul class="subtasks">
|
||||
<li class="subtask" data-status="done" data-priority="medium">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">1.1</span>
|
||||
<strong>Fix Security Architecture email/password sequence</strong>
|
||||
<span class="badge done">done</span>
|
||||
<span class="badge priority-medium">medium</span>
|
||||
</div>
|
||||
<p>Normalize parser-sensitive sequence text in 01 - Architecture/Security Architecture.md.</p>
|
||||
|
||||
</li>
|
||||
<li class="subtask" data-status="done" data-priority="medium">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">1.2</span>
|
||||
<strong>Fix authentication login and refresh diagrams</strong>
|
||||
<span class="badge done">done</span>
|
||||
<span class="badge priority-medium">medium</span>
|
||||
</div>
|
||||
<p>Normalize parser-sensitive token and refresh-token sequence text in Authentication Flow.</p>
|
||||
|
||||
</li>
|
||||
<li class="subtask" data-status="done" data-priority="medium">
|
||||
<div class="subtask-top">
|
||||
<span class="sub-id">1.3</span>
|
||||
<strong>Fix chat, delivery, dispute, OAuth, purchase request, referral, registration, and seller-offer diagrams</strong>
|
||||
<span class="badge done">done</span>
|
||||
<span class="badge priority-medium">medium</span>
|
||||
</div>
|
||||
<p>Clean the remaining Mermaid sequence diagrams with invalid or ambiguous syntax.</p>
|
||||
|
||||
</li></ul>
|
||||
</article></section>
|
||||
</main>
|
||||
<footer>Generated from <code>.taskmaster/tasks/tasks.json</code>. Last docs update: 2026-05-24T00:00:00.000Z</footer>
|
||||
<script>
|
||||
const search = document.querySelector('#search');
|
||||
const status = document.querySelector('#status');
|
||||
const priority = document.querySelector('#priority');
|
||||
const cards = [...document.querySelectorAll('.task')];
|
||||
function applyFilters() {
|
||||
const q = search.value.trim().toLowerCase();
|
||||
const s = status.value;
|
||||
const p = priority.value;
|
||||
for (const card of cards) {
|
||||
const text = card.innerText.toLowerCase();
|
||||
const statusMatch = !s || card.dataset.status === s || [...card.querySelectorAll('.subtask')].some((el) => el.dataset.status === s);
|
||||
const priorityMatch = !p || card.dataset.priority === p || [...card.querySelectorAll('.subtask')].some((el) => el.dataset.priority === p);
|
||||
const searchMatch = !q || text.includes(q);
|
||||
card.style.display = statusMatch && priorityMatch && searchMatch ? '' : 'none';
|
||||
}
|
||||
}
|
||||
search.addEventListener('input', applyFilters);
|
||||
status.addEventListener('change', applyFilters);
|
||||
priority.addEventListener('change', applyFilters);
|
||||
</script>
|
||||
</body>
|
||||
</html>
|
||||
384
taskmaster-share/tasks.json
Normal file
384
taskmaster-share/tasks.json
Normal file
@@ -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."
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
12
taskmaster-share/vercel.json
Normal file
12
taskmaster-share/vercel.json
Normal file
@@ -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" }
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
Reference in New Issue
Block a user