[#504] Profile page — activity feed and on-chain history

[realproject7]

Summary

• Replaced separate Donations/Ratings sections with a unified reverse-chronological activity feed
• Event types: Created storyline, Published plot, Bought tokens, Sold tokens, Donated, Rated
• Data from 5 tables (storylines, plots, trade_history, donations, ratings) fetched in parallel
• Each entry shows color-coded event label, story link, detail (amounts/prices/stars), timestamp, and Basescan tx link
• Pagination via "Load more" button (30 entries per page)
• Genesis plots deduplicated with created_storyline events
• Enhanced empty state

Test plan

• Visit a writer profile — verify "Created" and "Published" events appear
• Visit a trader profile — verify "Bought" and "Sold" events with token amounts
• Visit a donor profile — verify "Donated" events with amounts
• Verify feed is sorted reverse-chronologically across all event types
• Verify pagination — click "Load more" to see additional entries
• Verify tx links open correct Basescan pages
• Visit an inactive profile — verify empty state
• Verify genesis plots don't duplicate with created storyline events

Fixes #504

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
plotlink	Ignored		Mar 24, 2026 8:00pm

[project7-interns]

Verdict: REQUEST CHANGES

Summary

The unified feed is a good direction, but the implementation does not match issue #504's required event set. It replaces the required royalty-claim activity with ratings, which are off-chain and outside the ticket.

Findings

• [high] The feed omits the required Claimed royalties event type and instead adds Rated entries from the app-only ratings table.
  • File: src/app/profile/[address]/page.tsx:861
  • Suggestion: Replace the ratings query/rated feed type with actual royalty-claim history so the Activity tab matches #504's acceptance criteria and stays focused on on-chain activity.

Decision

Requesting changes because the Activity tab still does not implement one of the required event types from #504, so the acceptance criteria are not met.

[project7-interns]

Verdict: REQUEST CHANGES

Summary

The feed now includes a claimed-royalties row, but it is still not implemented as actual history. The PR fabricates a "Claimed" entry from the cumulative claimed balance and the current time, so the activity feed can show a false date and cannot link to a real transaction.

Findings

• [high] claimed_royalties is synthesized from cumulative royalty state with timestamp: new Date().toISOString() and no transaction hash, so anyone who has ever claimed royalties will appear to have claimed them "now" on every render.
  • File: src/app/profile/[address]/page.tsx:1001
  • Suggestion: Source royalty claims from real claim transactions/history with the actual timestamp and tx hash, or omit this event until claim history is indexed. Do not fabricate activity rows from cumulative state.

Decision

Requesting changes because #504 is an activity/history ticket, and the current claimed-royalties entry violates reverse-chronological accuracy and the acceptance criterion that entries link to relevant pages/transactions.

[project7-interns]

Verdict: REQUEST CHANGES

Summary

The fake timestamp problem is gone, but the ticket still is not met. Issue #504 requires an activity feed containing all listed event types, and Claimed royalties has been moved out of the feed into a standalone summary card.

Findings

• [high] Claimed royalties is no longer represented as a feed event at all. The PR renders a cumulative summary card instead of a chronological activity row with timestamp/link, so the Activity tab still does not provide the required event type in the feed.
  • File: src/app/profile/[address]/page.tsx:998
  • Suggestion: Either source real royalty-claim events into the feed with their actual timestamps/tx links, or do not treat #504 as complete yet. A summary card does not satisfy the issue's "activity feed with all event types" acceptance criterion.

Decision

Requesting changes because the Activity tab still lacks the required Claimed royalties feed event from #504.

[project7-interns]

Verdict: REQUEST CHANGES

Summary

The feed now uses real transfer logs, but the claim-detection logic is still not correct. It classifies any PLOT_TOKEN transfer from MCV2_BOND to the user as a royalty claim, which also matches normal sell refunds.

Findings

• [high] claimed_royalties is derived from every PLOT_TOKEN Transfer(from=MCV2_BOND, to=address), but selling storyline tokens also returns PLOT_TOKEN from MCV2_BOND to the seller via burn(...). That means normal sell transactions will be mislabeled as royalty claims in the feed.
  • File: src/app/profile/[address]/page.tsx:1005
  • Suggestion: Identify actual claimRoyalties transactions specifically (for example by matching the contract call / receipt data), rather than treating all bond-to-user reserve-token transfers as claims.

Decision

Requesting changes because the current claim-history logic produces false positives and makes the activity feed inaccurate.

[project7-interns]

Verdict: REQUEST CHANGES

Summary

Filtering out trade-linked transfers is the right direction, but the current exclusion set is incomplete. Because it is built from a capped trade_history query, older sell refunds can still show up as fake royalty claims.

Findings

• [high] claimed_royalties excludes only tx hashes from the already-limited trade_history result (.limit(200)), while the royalty-transfer log scan runs from genesis to latest. For active addresses with more than 200 trades, older sell refunds will not be in tradeTxHashes and will still be mislabeled as royalty claims.
  • File: src/app/profile/[address]/page.tsx:904
  • Suggestion: Do not derive claim detection from a truncated trade hash set. Either identify real claimRoyalties calls directly, or build the exclusion against complete trade history for the relevant transfer logs.

Decision

Requesting changes because the feed can still produce false Claimed entries for older sell transactions, so the activity history is not yet reliable.

[project7-interns]

Verdict: REQUEST CHANGES

Summary

I re-reviewed the current head of PR #509, and the older-sell exclusion bug is still present in the code under review. The claim filter is still derived from the capped feed query rather than a complete trade-hash set.

Findings

• [high] claimed_royalties still excludes only tx hashes from the limited tradesRes feed query, so older sell refunds can still be mislabeled as royalty claims.
  • File: src/app/profile/[address]/page.tsx:903
  • Suggestion: Build the exclusion from complete trade history for the address (or identify real claimRoyalties calls directly), not from the PER_SOURCE_LIMIT feed query.

Decision

Requesting changes because the current head can still generate false Claimed entries for older sell transactions, so the activity history remains unreliable.

[project7-interns]

Verdict: REQUEST CHANGES

Summary

The latest head fixes the truncated trade-hash set, but the activity feed still filters trade_history against the wrong contract address. That breaks both the bought/sold entries and the claim-refund exclusion.

Findings

• [high] The Activity tab queries trade_history with contract_address = STORY_FACTORY, but the trade indexers write trade_history.contract_address = MCV2_BOND. As a result, the feed can miss buy/sell events entirely, and the new allTradeTxRows exclusion for claimed_royalties will also miss sell refunds.
  • File: src/app/profile/[address]/page.tsx:903
  • Suggestion: Use the same contract key that trade_history is indexed under (MCV2_BOND) for both the feed trade query and the unbounded tx_hash exclusion query.

Decision

Requesting changes because the current head still cannot reliably show trading activity or distinguish claims from sell refunds, so #504's activity-feed requirements are not met.

[project7-interns]

Verdict: APPROVE

Summary

The latest head resolves the remaining trade-history issues on the Activity tab. trade_history queries now use MCV2_BOND consistently, and the sell-refund exclusion for claimed royalties is built from the full trade hash set rather than the capped feed query.

Findings

• None.

Decision

Approving because the prior requested changes are resolved and the Activity feed now matches the indexed trade data it depends on.

[project7-interns]

Verdict: REQUEST CHANGES

Summary

Revising my review based on the new product direction from @project7. The current claimed-royalties feed entries are still derived heuristically from transfer logs, and the recommended direction is to avoid presenting that as chronological activity until a dedicated claim indexer/event exists.

Findings

• [high] claimed_royalties is still inferred from filtered PLOT_TOKEN transfer logs instead of a dedicated claim event/index. Per the latest product guidance, this should not be shown as chronological feed activity yet.
  • File: src/app/profile/[address]/page.tsx:992
  • Suggestion: Remove claimed_royalties from the chronological feed for now, show cumulative claimed royalties as a static stat from getRoyaltyInfo, and leave a TODO for proper claim-history support once a dedicated indexer exists.

Decision

Requesting changes because the latest project direction is to avoid heuristic claim-history entries in the Activity feed.

[project7-interns]

Verdict: APPROVE

Summary

Superseding my prior request-changes review on the latest head. The PR now follows the operator-directed approach for claimed royalties and fixes the trade_history contract-address mismatch across the profile page.

Findings

• None.

Decision

Approving because the latest revision removes heuristic claimed-royalties feed entries, shows cumulative claimed royalties as a static on-chain profile stat, and uses MCV2_BOND consistently for trade_history lookups.