Historical snapshot archived 2026-09-25. This records an earlier review or plan, not current implementation or live ticket state. For current work, follow root AGENTS.md, the relevant BloxClips skill, and owning repository source/tests. Preserve approved decisions as evidence; verify their present authority before acting.

Risks, Unknowns, and Questions

This document records evidence-backed concerns without changing behavior. “Risk” does not automatically mean a confirmed bug.

Confirmed risks

View tracking and campaign expiry are not wired

src/scheduler.ts exports startScheduler, but repository-wide search found no caller in current TypeScript entrypoints. The API explicitly starts other schedulers. Accepted submissions may therefore receive no periodic metric polling/campaign expiry under the visible startup commands.

Entire dashboard is frontend-admin-gated

BloxClips-frontend/app/dashboard/layout.tsx requires /api/admin/check for every nested page, including creator campaigns, submissions, payout, and profile. Backend creator APIs require authentication rather than admin. Onboarding directs users to /dashboard. This access behavior is both broad and surprising.

In-process scheduling and state assume a narrow topology

Timers, rate limits, caches, payout callbacks, SSE polling, and PV tracker locking are process-local. Multiple API replicas can duplicate jobs and split throttling/cache state. A process crash loses timer callbacks. Payout early-state recovery partially compensates; most other timers do not have distributed coordination.

Legacy and current payout systems coexist

Legacy admin payout endpoints/Submission.paidOut and current delta PayoutItem review/send code are both present. Stats and balance code consult different mixtures of these fields. Any payout or earnings change can double-count, omit, or mutate the wrong cohort if only one path is considered.

Campaign eligibility is duplicated

Campaign lists compute canSubmit and the UI filters actions, while POST /api/submissions performs a separate validation sequence. Not every visible campaign toggle is clearly enforced in that creation handler (acceptingSubmissions, paused, requireNewUploads, and some media/minimum conditions require careful verification). Frontend disabling is not security/business enforcement.

Sensitive tax/payment work has non-obvious side effects

Admin payout approval increments paid-view/amount bookkeeping and snapshots tax/referral state before explicit send. Terminal send failure must reverse it. Submission item decisions can deny/flag and stop tracking. Profile edits can invalidate tax forms. These transitions must be changed atomically across utilities and audit/notification behavior.

File-backed PV tracker

PV tracker state lives in assets/pv-tracker-state.json, is mutated by admin routes/autosync, and uses only an in-process running guard. Concurrent instances, deployment replacement, or missing persistent disk can lose/corrupt operational data.

Manually duplicated API contract

Endpoint paths, JSON names, string states, monetary meanings, and ID conventions are manually duplicated across repositories. There is no schema generation or cross-repository compile check.

Duplicate active/legacy integrations diverge

Contact, booking, Whop count, and Roblox proxy functionality exists on both sides or in multiple variants. The active public contact path bypasses backend persisted abuse evidence; active booking bypasses backend BookingRequest. Operators may inspect a backend admin screen that does not contain leads created by the current public UI.

Production mock-mode defaults

PayPal, NowPayments, and Tax1099 default to mock when mode variables are unset. This supports local boot but makes explicit deployment configuration essential.

Ambiguous behavior

• It is unclear whether ordinary clippers should currently access dashboard pages or whether the product is temporarily admin-only.
• getCampaignSpend, campaign list earnings, approval freeze logic, and payout-time earnings do not obviously apply minimums/caps/fee burn identically. The intended accounting authority needs confirmation.
• customRate is per 1,000 in calculations, while at least some admin display/log wording suggests per million.
• PayPalAccount retains OAuth-token fields while current comments/routes describe saved-email verification.
• UserChannel, Discord Ticket, old generated JS in src/, and several frontend components may be supported through unobserved operational paths.
• The checked-in .env includes program/pause variables, but referral runtime helpers hardcode revenue-share/unpaused behavior.
• Live-session component mounting and intended notification SSE coverage are unclear.

Documentation mismatches

• Backend README/structure docs say SQLite and WAL; current Prisma datasource is PostgreSQL.
• Backend docs variously reference Supabase, Neon, DigitalOcean, Cloudflare, and PM2; current production ownership/topology is not provable.
• Frontend README is primarily scaffold text and does not describe dashboard/API behavior.
• .env.template is useful but not exhaustive; source accepts aliases and additional operational variables.
• Referral test comments recommend node --import ts-node/register; this failed under the audited Node 22/CommonJS setup. The --require ts-node/register form passed the three database-free files.
• Backend comments say email verification gates the first upload/payout, while both frontend wrappers and backend checks are commented out.
• CONTEXT.md mentions a different working branch/Windows path than the audited checkout (main on Linux).

Potentially dead or legacy code

Evidence is static repository search; dynamic imports or external launchers could change conclusions.

• src/scheduler.ts: implemented but no TypeScript entrypoint caller.
• Frontend BookCallScheduler.tsx: no import found; active page uses Calendly.
• Frontend ContactForm.tsx: no active page import; active contact uses BookCallForm and Next handler.
• Frontend LiveSessionUpdates.tsx: no import found.
• Commented EmailGate boundaries in submission and payout flows.
• Checked-in compiled .js/.d.ts/.map beside some backend TS source: not used by declared build output.
• Legacy payout endpoints and PayPal OAuth fields: still reachable/persisted in source, so “legacy” does not mean safe to remove.

Questions for previous developers

1. What exact production processes/commands are running for frontend, API, bot, and workers?
2. Is startScheduler invoked by an external/private launcher, or is periodic campaign tracking unintentionally disabled?
3. Should non-admin clippers enter /dashboard? If yes, when and why was the global admin gate added?
4. Which payout path is authoritative, and what historical rows depend on the legacy admin flow?
5. What is the canonical accounting definition for campaign spend, minimum-view thresholds, platform fee burn, and custom rates?
6. Which contact and booking systems are operational: Next+Resend/Calendly, or backend contact/Google Calendar?
7. Is PV tracker JSON stored on durable shared disk, and is only one API instance guaranteed?
8. What are the active production infrastructure/database providers and deployment pipeline?
9. Are email verification gates intentionally disabled? What fraud/security control replaced them?
10. Are AFFILIATE_PROGRAM_MODE and REVENUE_SHARE_PAUSED intended to work, despite hardcoded helpers?
11. Which generated backend artifacts and Discord-era tables/workflows remain operationally required?
12. Is Whop intentionally limited to a marketing member count, or does another private service own membership/product integration?
13. Is there a sanitized database/seed and a supported end-to-end test account matrix for each OAuth/payment rail?
14. What alerts or dashboards monitor failed schedulers, payout recovery, scrape failure rates, and webhook delivery?