[#272] Post-E2E cleanup: update StoryFactory address & remove orphan data

[realproject7]

Summary

Fixes #272

• Updated StoryFactory mainnet fallback from v4 (0x92c3bd44...) to v4b (0x9D2AE1E9...8744Cf) in lib/contracts/constants.ts and packages/sdk/src/constants.ts
• Updated DEPLOYMENT_BLOCK / DEPLOYMENT_BLOCK_MAINNET to 43840298 (the v4b deployment block)
• Added migration 00025_cleanup_orphan_storylines.sql to delete storyline IDs 25-33 (orphans from first E2E attempt with wrong content hashes)

Companion PR in plotlink-contracts updates the README with the new address.

Test plan

• Verify npx tsc --noEmit passes
• Verify backfill picks up events from new factory address
• Run migration on staging DB and confirm storylines 25-33 are removed
• Confirm E2E scripts in plotlink-contracts already reference new address

🤖 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 26, 2026 7:19am

[project7-interns]

LGTM. Address updates are consistent across both constants files, deployment block updated correctly, and migration handles all dependent tables in proper FK order with a graceful fallback for notification_queue.

[project7-interns]

Verdict: REQUEST CHANGES

Summary

The address and deployment-block updates look right, but the PR does not fully implement issue #549 and the cleanup migration is broader than the ticketed delete scope.

Findings

• [high] Issue #549 requires resetting or updating backfill_cursor for the redeployed factory, but this diff only updates constants and the cleanup migration. Existing environments can stay pinned to the old cursor and miss events from the v4b deployment.
  • File: lib/contracts/constants.ts:28
  • Suggestion: Add the requested migration or update that resets backfill_cursor to 43840298, or document why it is provably unnecessary.
• [medium] The cleanup migration deletes by storyline_id alone across every table, while issue #549 scoped the cleanup to the affected factory address for tables that carry contract_address. As written, this can delete non-orphan rows if valid records share IDs 25-33.
  • File: supabase/migrations/00025_cleanup_orphan_storylines.sql:7
  • Suggestion: Add the contract-address predicates from issue #549 where those columns exist, and keep any unscoped deletes limited to tables that cannot distinguish by contract.

Decision

Request changes until the missing backfill_cursor handling is included and the migration scope is tightened to the intended orphaned rows.

[project7-interns]

Verdict: REQUEST CHANGES

Summary

The backfill_cursor reset is now covered, but the cleanup migration no longer matches the contract scope specified in issue #549.

Findings

• [high] Issue #549's cleanup SQL scopes the orphaned storyline deletes to the redeployed v4b factory 0x9D2AE1E99D0A6300bfcCF41A82260374e38744Cf, but this migration now filters the affected tables by the old factory 0x92c3bd44fda84e632c3c3cb31387d0c0c1de618d. If the orphaned IDs 25-33 are the rows described in #549, these DELETEs will miss the intended records and leave the cleanup incomplete.
  • File: supabase/migrations/00025_cleanup_orphan_storylines.sql:13
  • Suggestion: Reconcile the migration with issue #549's contract scope. Either target the v4b address from the ticket, or update the ticket/PR with concrete evidence that the orphaned rows actually live on the old factory address.

Decision

Request changes until the cleanup migration is aligned with the actual contract address for the orphaned rows.

[project7-interns]

Verdict: APPROVE

Summary

The PR now covers the Batch 20 cleanup scope: the StoryFactory constants are updated, the orphan-row cleanup is scoped to the v4b contract, and the backfill cursor reset is included.

Findings

• None.

Decision

Approve. The remaining diff is consistent with issue #549 and the requested fixes are addressed.