Repository navigation
feat: /payee dashboard (M3-11) - #31
Merged
Merged
Conversation
Connect a wallet; find every registered payee it's the payout address for (matched against the already-fetched indexer payee list); list each one's locks via a new listLocks(payeeId, state?) in lib/indexer/index.ts, filterable by status and by one specific payment (pasting a claim link reuses /claim/[id]'s own parseClaimLink + computeRefHash check, entirely client-side; the reference and salt never leave the browser). listLocks is callable from the browser too, unlike listPayees, since the dashboard doesn't know which payeeId to ask for until a wallet connects. Each row links to /claim/[id] for the actual release/decline actions; nothing here moves money.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What and why
/payeewas still aPageStub. Builds it: a payee connects their wallet and sees every lock sent to them, filterable by status and by one specific payment. Was blocked onM2-12(indexer list API,DONE) and the indexer actually existing; both are true now (M2-18live on Railway).Changes
lib/indexer/index.ts: newlistLocks(payeeId, state?)andIndexedLocktype/schema, matching the indexer's/lockscontract. UnlikelistPayees(server-only, absolute URL), this one also works from the browser, resolving to the same-origin/locksrewritenext.config.tsalready has, since the dashboard only learns which payeeId to query after a wallet connects client-side.app/payee/payee-logic.ts(+ tests):matchingPayeeIds(wallet address → every payeeId it's the payout for, matched against the already-fetched payee list, no extra round-trip),findByReference(a pasted claim link → the one matching lock, reusingparseClaimLink+computeRefHash, same as/claim/[id]),byNewest.app/payee/usePayeeDashboard.ts,PayeeView.tsx,page.tsx: the page itself, following the housepage.tsx→View.tsx→useX.ts→x-logic.tssplit.messages/en.json: newpages.payee.*keys; reusespages.claim.state.*for lock-state labels rather than duplicating them.Hard rules / invariants touched
ref_hashentirely in the browser; only the hash is ever compared, never sent anywhere./claim/[id], untouched here.Tests
pnpm lint,pnpm typecheck,pnpm test(103/103, 9 new),pnpm buildall green.Verified the data layer end-to-end against real testnet data: with the real indexer URL in
.env.local,curl'd the app's own/locks?payee_id=...(the same-origin rewrite path the browser uses) and got back real, already-created locks in the exact shapelistLocks's Zod schema expects. Visually confirmed the pre-connect page with Playwright: renders cleanly, no console errors.Not independently verified: the post-wallet-connect render with real data. Driving a real wallet browser extension isn't automatable; this is the same limitation already accepted for
/send's wallet step earlier this session. The rendering code reuses already-verified components (AmountDisplay,DateTimeDisplay) and an already-verified pattern (/claim/[id]'sisPayout/WalletBar), and the data it renders is unit-tested and confirmed real, but the actual connected-wallet screen hasn't been eyeballed.Docs / ADR
None needed.
Roadmap
M3-11→DONE. Phase 4 App: 11→12 DONE, 9→8 TODO (42%→46%). All rows: 41→42 DONE, 120→119 TODO (23%→24%). Changelog entry added.Assumptions and open questions
If a human can try this with a real testnet wallet that happens to be one of the three fixture payees' payout address (NG:
GDPUY733T3UNZWG4EQMEBHBDGKD33YSFPOI2RB4AIK2JMOENKEXWK7ZG, KE:GCLMHF7LAR34TSELDNEREYPTNE4K7MMESPS62WXE7ZDLPWIJUF3MC5QM, PH:GBXKOYQ4MJ6UJGQBFXVXOP7XL7SKKJTFTYJUSNREP5FW4IHXPMWY2WSX), that would close the one remaining verification gap. The KE payee already has several real locks in various states on testnet, which would be a good exercise of the status filter.