[builtbyrishabh]

Refs #19

User-facing problem

The launch blockers had no repeatable automated product contract, no honest manual checklist, and no durable record separating checks actually performed from production-only work.

Implementation summary

• Expand automated coverage to 32 tests across five files.
• Test prompt bounds/UUID keys, six-round overflow and underflow, lifecycle transitions, canonical refunds, environment validation, privacy predicates, publication authorization structure, generation idempotency, disabled audio regeneration, export claim ordering, safe status serialization, migration defaults, and CI command presence.
• Extract round-bound assertions so the tested guard is the production guard.
• Add pnpm verify:launch for the repeatable local quality sequence.
• Add a preview/production checklist using only PASS, FAIL, BLOCKED, and NOT RUN.
• Add dated local evidence without claiming vendor, payment, two-account, migration, deployment, backup, or rollback checks were run.

Migration notes

No database migration. This PR verifies migrations from earlier stack layers but does not apply them.

Security and financial invariants

The automated contract fails if public queries lose publication filtering, owner publication loses atomic authorization/completion checks, audio regeneration returns, export invokes Remotion before claiming, internal diagnostics enter status output, round bounds move after provider work, or required CI commands disappear.

Tests and checks run

• PASS: pnpm test — 32 tests across 5 files
• PASS: pnpm typecheck
• PASS: pnpm lint with non-secret production placeholders
• PASS: pnpm format:check
• PASS: git diff --check
• PASS: production pnpm build — 18 routes
• PASS: frozen install evidence inherited from the unchanged lockfile on this stack
• PASS: critical audit findings reduced from 5 to 0
• FAIL: high-severity dependency audit still reports 31 findings; CI remains configured to fail on high severity

Manual checks not run / blocked

• NOT RUN: two-account Clerk privacy and ownership flows.
• NOT RUN: migrated preview database and lifecycle refresh/reconnect scenarios.
• NOT RUN: concurrent debit/refund/export integration tests against live services.
• NOT RUN: Stripe test-mode payment and webhook replay.
• NOT RUN: production deployment, backup restore, rollback drill, or vendor dashboards.
• BLOCKED: retry-safe paid generation pending [P1] Durable generation: asset registry, per-round checkpointing, bounded parallelism #17.
• BLOCKED: honest identity/navigation pending [P0 launch blocker] Honest product surface: real identity, label unfinished navigation #12.
• BLOCKED: legal/refund/operations readiness pending [P2] Post-alpha: delete lifecycle, ops runbook, legal surfaces, support timelines #18.

Stack dependency and merge order

Stack PR 5 of 5. Base: launch/16-durable-job-status. Merge #13, #14, #15, #16, then #19. This PR references rather than closes #19 because production-only checks remain pending.

Known limitations

Source-contract tests deliberately protect critical query/mutation structure but do not replace database concurrency integration tests. The checklist must be rerun on a migrated preview environment before launch approval.

Rollback implications

This layer contains tests/docs and a pure round-bound extraction. It can be reverted without data changes, but doing so removes launch regression coverage and evidence discipline.

🤖 Generated with Claude Code

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
anime-room	Ready	Preview, Comment	Jul 17, 2026 2:51pm

[coderabbitai]

Warning

Review limit reached

@D33ADLOCK, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 42 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Free

Run ID: 160caaf3-e3d7-45be-a272-2d016348399f

📥 Commits

Reviewing files that changed from the base of the PR and between 0c0d739 and b3f8b45.

📒 Files selected for processing (8)

• docs/launch-verification-checklist.md
• docs/launch-verification-evidence-2026-07-17.md
• package.json
• src/inngest/roundBounds.test.ts
• src/inngest/roundBounds.ts
• src/inngest/roundBundle.ts
• src/launch-readiness.contract.test.ts
• src/lib/schemas/job.test.ts

---

Note

🎁 Summarized by CodeRabbit Free

Your organization is on the Free plan. CodeRabbit will generate a high-level summary and a walkthrough for each pull request. For a comprehensive line-by-line review, please upgrade your subscription to CodeRabbit Pro by visiting https://app.coderabbit.ai/login.

_{Comment @coderabbitai help to get the list of available commands.}