Captures the runtime-monitoring side of the 2026-05-28 silent-empty-
registry incident retrospective. Pairs with backend commit 28b17f2
(CI typecheck gate). Defines the proposed Gatus probe set, the
/api/health endpoint that has to land first, and a follow-up issue
list. Includes a retrospective table showing what this would have
caught across recent incidents.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Three scoping tiers (ledger-only / +Payment+Dispute / all five financial
models) with concrete time estimates grounded in actual reference counts
from the codebase. Recommends Option 1 (ledger only, 3–4 weeks) as the
right dual-DB shape if a forcing function appears, and explains why it's
not yet worth doing over the 2-week in-place hardening.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Records the current recommendation (stay on Mongo + targeted hardening),
the realistic full-migration cost (3.5–6 months), and the trigger
conditions under which we should revisit the decision. Prompted by the
multi-seller orphan-payment bug on 2026-05-28 — exactly the FK-shaped
class of bug Postgres would prevent, but not by itself worth a migration.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
A (cart-aware buyer UX), D (auto-start sweep cron), and E (recordSweep
$inc accumulation fix) shipped. F (API Reference + Activity Log doc
updates) underway. B (unit tests) and C (live divergent-destination
probe on dev) still pending.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Rewrote §1 of the Wallet/Multichain/Confirmations/AML/Trezor PRD:
- Status promoted from 'Draft' to 'Living', §1 marked 🟡 In progress.
- Decisions taken table captures the locked-in choices (per-(buyer,
sellerOffer, chainId) keying with reuse, monotonic counter,
cron-based sweep, build-only signer default).
- 'What landed in 2.6.42' section enumerates the actual files +
endpoints + env vars so kimi has concrete reference points.
- 'Remaining work for Task #7' table breaks the remainder into six
discrete items (A..F) each with file paths and notes:
A — cart-aware buyer UX (the big one)
B — unit tests
C — live divergent-destination probe
D — optional auto-start cron on boot
E — possible recordSweep accumulation bug to verify+fix
F — API Reference doc updates
- Acceptance criteria annotated with ✅/⏳ per item.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- Handoff doc: mark Task #7 in-progress with what landed (backend
modules, admin UI), what remains (cart-aware buyer UX, unit tests,
live RN divergent-destination probe, optional auto-start cron).
Promote the followups table from 'depends on' to 'status'.
- Environment Variables: add DERIVED_DESTINATION_* block with KMS /
Trezor production guidance.
Code is on backend commit c98b3d7 / frontend commit 82d9a70, both
on integrate-main-into-development.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
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>
In-house Request Network checkout went fully end-to-end on dev today.
A real 0.01 USDC payment flowed through wallet connect -> approve ->
ERC20FeeProxy.transferFromWithReferenceAndFee -> RN webhook ->
TransactionSafetyProvider -> Payment.status=completed -> page success
state. Tx 0x494c77a29161b5100d8e0b1ac675f1822955d0bb3633ecdbfafb886f84f2f320.
Docs:
- New PRD: Wallet, Multichain, Confirmations, AML, Trezor
(5 follow-ups, each sized for an independent contributor)
- Updated PRD: Request Network In-House Checkout (phases 0..3 done,
phase 4 partial, phases 5-6 not started)
- Updated handoff: deployed versions, what is working end-to-end,
follow-up tasks index
Taskmaster: 5 new top-level tasks (#7..#11) covering ephemeral
destination wallets, multichain proxy registry + USDC/USDT, runtime
confirmation thresholds, optional seller-paid AML screening, and
Trezor signing for admin actions. Tasks are scoped fine-grained so
each is independent enough for kimi to pick up.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Four payment-flow concerns surfaced during the RN integration that
need explicit design decisions before scaling:
1. Rabby wallet unsupported by RN's hosted UI - mitigated by
bringing the checkout screen in-house.
2. RN auto-bridges cross-chain payments via LiFi, costing someone
money - mitigated by gating chain selection in our own UI based
on seller-accepted chains.
3. Single shared escrow wallet exposes the whole platform to
sanctioned-funds taint - needs per-escrow ephemeral wallets and
a wallet-abstraction layer.
4. The above pushes RN into a notification-only role - viable but
needs validation tests (webhook reliability, custom destinations,
API-only pricing) before commitment.
Moves the canonical agent rule set into nick-doc/RTK.md (previously only
present in the untracked escrow root). backend/AGENTS.md and
frontend/AGENTS.md now point here instead of duplicating the rules
3-ways and drifting.
New rules introduced as part of this session:
- Every build patch-bumps the version (image tracker on git.manko.yoga
overwrites tags otherwise).
- Pre-deploy CLI verification: smoke tests in scripts/smoke/ must pass
before pushing a build-triggering commit.
- CI notification safety: HTML-escape commit messages and strip git
trailers; never embed {{commit.message}} directly in the telegram
plugin's HTML-formatted body.
Handover doc updated to record that the Request Network checkout flow is
now end-to-end working at 2.6.20 (idempotency in bdbcc32, v2 wire shape
in 40750d3).
Co-Authored-By: Claude Opus 4.7 noreply@anthropic.com
Backend solution (c) shipped in nick/backend@bdbcc32 — endpoint now reuses
existing pending Payments instead of colliding on the unique index.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Captures the E11000 collision on the uniq_pending_request_network_by_buyer_session
index, identifies reused purchaseRequestId as the root cause, and lays out the
mongo unblock, frontend id-rotation, and backend idempotency fixes.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
PRD - TON Wallet Ownership Proof.md:
- Status updated from ready-to-implement -> backend-implemented.
- Added Implementation Status section documenting what is complete
(challenge endpoint, tonProofService.ts, User model fields, 15 tests)
and what remains (frontend proof wiring, verified badge).
- Acceptance criteria updated: backend items checked, frontend pending.
Handoff - Telegram Mini App Debug - 2026-05-24.md:
- New Implemented sections for session 3:
- TON Wallet Ownership Proof backend (full detail of tonProofService,
userController changes, User model fields, 15 unit tests).
- Telegram Mini App shell dir="ltr" + smart displayName fallback.
- Socket status suppressed on /telegram paths.
- EVM WalletConnect stub card (disabled until project ID configured).
- Known Issues: TON proof updated to "frontend wiring pending";
EVM WalletConnect section added with activation steps.
- Current Git State updated to Session 3.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Three-stream audit (security / logic / performance) with 35+ findings
derived from actual source code, each with file:line and remediation
- Audit Index cross-references criticals across streams into prioritized
fix tiers: immediately / before soft launch / before public launch
- Telegram Mini App debug handoff documenting what was implemented and
all remaining work items with exact file lists and test commands
- Updated architecture, data model, auth API, and registration flow docs
to reflect Telegram auth, TON wallet, and email verification additions
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
