feat: remix tier gating — t1/t2 behind explicit opt-in (default unchanged)

[mtmtian]

This PR does NOT change the shipped default: REMIX_ENABLED_TIERS defaults to t0_5 only — the borrow-structure-not-pixels policy in remix-brief.ts / competitor-media.ts remains the effective behavior out of the box.

What this adds

Tier codes for t1/t2 exist in the remix worker engine's control plane, but stay behind an explicit env opt-in. Nothing about the default request path changes.

Tier	What it does	Competitor pixels in output?
t0	Your existing single-shot remix path (/api/creatives/remix)	untouched by this PR
t0.5	(#19) Pure text-derived storyboard, no visual reference	zero
t1	Generates using the already-stored Tier-2 competitor video as an @reference for the worker	zero — reference only, no competitor frames in the output
t2	Reuses specific, human-approved clean segments from the stored competitor video (segmentPlan)	yes — output is tagged containsCompetitorFootage: true

Gating mechanics

• REMIX_ENABLED_TIERS (comma-separated, default "t0_5") gates which tiers POST /api/creatives/remix-jobs will accept. Tier not in the set → 403. Tier not a known code → 400.
• t2 requires a validated segmentPlan with at least one action: "reuse" segment, or 400.
• t1/t2 both require the competitor's video to already be stored via your existing Tier-2 "Save video" flow (CompetitorCreative.assetId → Asset.fileUrl) — this reuses your hand-picked, legal-cleared winners gate rather than adding a new one. Missing it → 400 with a "use the Tier-2 Save video flow first" message.
• POST /api/worker/remix-jobs/claim now returns refs: [{url, kind:'video'}] for t1/t2 jobs, pointing the worker at that stored Asset. t0_5 is untouched.
• Every tier still creates the Creative with reviewStatus: 'pending' — the human review gate is identical across tiers, this PR only changes what's allowed to be generated, never what's allowed to ship without review.

Why gate via env instead of code-only

This moves the t1/t2 IP boundary from "not possible in code" to "off by default, explicit config choice + auditable via REMIX_ENABLED_TIERS, gated behind your own Tier-2 hand-picked-video approval step." That gives you (or legal/product) a deliberate lever to pull per deployment, rather than a hardcoded wall — while leaving the out-of-the-box behavior identical to today.

Stacked on #19

This branch is based on feat/remix-worker (#19, still pending review) and includes its commits. Once #19 merges, this diff will automatically shrink to just the tier-gating commit (51c1ce8).

Test plan

• npm run lint — 0 errors (pre-existing warnings only)
• npx tsc --noEmit — clean
• npx playwright test e2e/remix-jobs.spec.ts — 14/14 passing, including new coverage for: unknown-tier 400, t2-without-segmentPlan 400, t2/t1-without-stored-video 400. (The e2e webServer runs with REMIX_ENABLED_TIERS="t0_5,t1,t2" so these 400 branches — which sit downstream of the 403 gate — are exercised; the refs[] happy path requires a stored competitor Asset and is left to cross-repo integration with the worker.)

🤖 Generated with Claude Code

[oratis]

Review — remix tier gating

Everything in the #19 review applies here too, since this branch contains those commits — in particular the /upload state-machine bypass and the non-transactional report writes. This comment covers only what's specific to the tier gating.

First, the good news, because it's the part the PR description leads with and it checks out. parseEnabledTiers() is genuinely fail-closed: unset, empty string, whitespace-only, and malformed CSV (",,,") all collapse to {t0_5}. Tier is computed entirely from server state, validated against KNOWN_TIERS before the enabled-set check, and there's no path for a client to smuggle or escalate one — report and upload never write tier, and the Prisma @default("t0_5") backstops it. With the env var unset, the 403 fires before any DB row is touched. The shipped default does not weaken the current guarantee. The org-scoping fix in bbf02d4 is also complete — claim/route.ts:100-105 correctly scopes both the CompetitorCreative and Asset lookups by job.orgId.

The problem is with the argument built on top of that, which is roughly "this is safe because it's opt-in." Two findings undercut it.

🔴 containsCompetitorFootage is a write-only field

It's set at creatives/remix-jobs/route.ts:173-174 and read nowhere — a repo-wide grep for containsCompetitorFootage and competitorReferenced returns exactly those two write sites and nothing else. It lands in Creative.tags, but creatives/review/page.tsx:31-43 passes an explicit field whitelist to <ReviewClient> that omits tags entirely. And source is hardcoded to 'remix' for every tier at :164.

So in the review queue, a pure structure-derived t0.5 remix and a t2 creative assembled from spliced competitor footage render identically. The human review gate is the backstop this design leans on once t1/t2 is enabled, and as written it has no way to see the one fact that matters.

🔴 REMIX_ENABLED_TIERS is a create-time allowlist, not a kill switch

parseEnabledTiers() is called only at creatives/remix-jobs/route.ts:82. claim/route.ts:97 gates refs[] purely on the already-persisted job.tier and never re-checks the current env.

Concretely: if a competitor asset turns out to be a problem and the env var is reverted, every t2 job already sitting in pending/claimed/running still gets claimed, still receives refs[].url pointing at the stored competitor video, and still gets spliced. The only lever the design offers can't stop work already in flight.

🟡 Supporting gaps

• No logAudit() on t1/t2 job creation. Opting a job into "use real competitor footage" is exactly the class of action AuditAction.competitor.video_store exists for. There's currently no record of who created a t2 job, for which org, against which asset.
• refs[].url is an unsigned, non-expiring public GCS URL (storage.ts:74). This convention predates this PR, but this is the first thing to route IP-sensitive material through it — once obtained (logs, worker dependency, reviewer's browser history) access is permanent and unrevocable.
• The refs[] happy path has no test at all. The added e2e covers only the 400 branches; nothing stores a competitor Asset, creates a t1/t2 job, claims it, and asserts refs[] contents and org scoping. That's the most sensitive path in the PR — the one that hands a competitor video to an external process — and it's also where 51c1ce8 shipped the org-leak that bbf02d4 had to fix, with no regression test now locking that fix in. Compounded by the CI skip noted in feat: remix worker engine (t0.5) — RemixJob orchestration + claim/report/upload #19: none of it runs on the runner.
• segmentPlan duration bound is skipped when cc.duration is falsy (creatives/remix-jobs/route.ts:130-138). If ingest never populated duration, an end far past the real video length passes server-side validation, contrary to the docstring's stated intent of failing here rather than in ffmpeg.
• parseEnabledTiers is case-sensitive with no warning — REMIX_ENABLED_TIERS="T1" silently doesn't enable t1. Fails in the safe direction, but it's a quiet misconfiguration footgun.

Where that leaves us

The env gate is correctly built for what it does. But "no competitor pixels in output" is currently enforced by t1/t2 being unreachable, not by anything that would contain the risk once they're reachable — the audit trail, the reviewer-visible flag, and the ability to halt in-flight work are all absent. The moment the flag includes t1 or t2, that guarantee stops being code-enforced and becomes a process assumption.

That's a product and legal call rather than a purely technical one, and it's ours to make — we'll come back to you on it separately. On the engineering side, before this could be turned on anywhere real we'd want: claim-time re-validation against the current env (or an explicit separate kill switch), the footage flag surfaced in the review UI as a hard visual marker, logAudit() on t1/t2 creation, and real coverage of the refs[] path.

_{Review assisted by Claude Code; every finding above was manually verified against the diff.}

[mtmtian]

Fixes pushed — rebased onto the updated feat/remix-worker + 4 commits (d5c83a6..608ec23)

Everything from the #19 fix round (claim fencing, transactions, CI wiring) applies here via the rebase. Tier-specific findings:

🔴 containsCompetitorFootage write-only → hard visual marker in review (76f0415)

The review page now parses Creative.tags server-side (defensively — tags is free-form for other sources) and passes tier / containsCompetitorFootage / competitorReferenced through the explicit field whitelist. The review card renders a leading badge no reviewer can miss: red ⚠ competitor footage · t2, amber competitor-referenced · t1. A t0.5 remix and a t2 splice no longer render identically.

🔴 REMIX_ENABLED_TIERS create-time-only → claim-time re-validation (d5c83a6)

parseEnabledTiers() is now re-checked inside /claim: the tier filter is in both candidate queries and the atomic updateMany guard. Reverting the env immediately stops every pending/stale t1/t2 job from being claimed — no redeploy-and-wait. Known boundary (documented in the route header): a job already claimed and inside its lease keeps running — the worker already holds the refs; revoking mid-render is not attempted.

🟡 Supporting gaps

• Audit: remix.job_create on every job creation (metadata carries tier), and a new competitor.video_reference action fired at the moment /claim hands out refs[] — filed next to competitor.video_store as the same IP-sensitivity class. Who created a t2 job, and every handout of stored footage to a worker, now leaves a trail.
• refs[] coverage (608ec23): new e2e — t2 happy path (stored org-scoped Asset → claim → refs equals [{url, kind:'video'}]) plus an org-isolation regression that locks the bbf02d4 fix (foreign assetId → refs: []). Asset fixture is inserted via direct SQL (pg, already a dependency) — the generated Prisma client is ESM-only and won't load under Playwright's CJS transform; explained in the spec header. Runs in CI now that feat: remix worker engine (t0.5) — RemixJob orchestration + claim/report/upload #19 wires a real Postgres.
• segmentPlan with unknown source duration (497a01d): now a 400 (re-ingest with duration first) instead of a silent skip of the bounds check.
• Case sensitivity (d5c83a6): tokens are trimmed + lowercased and validated against KNOWN_TIERS; unknown tokens are dropped with a console.warn instead of silently joining the enabled set.
• Unsigned public refs[].url: acknowledged — that's the bucket-wide storage convention predating this PR. If you want signed/expiring URLs for competitor-sourced assets specifically, happy to take that as a follow-up change.

Where that leaves the preconditions you listed

Claim-time re-validation ✅ · reviewer-visible hard marker ✅ · logAudit on t1/t2 ✅ · real refs[] coverage ✅. The shipped default is still t0_5-only and create-time behavior is unchanged. The product/legal call on ever enabling t1/t2 stays yours — code-side, the containment you asked for is in place.

Verification: tsc clean, full Playwright suite 45/45 green locally against live Postgres. One honest gap: the kill-switch filter itself isn't directly e2e-tested — the suite's dev server runs with a fixed env, so flipping REMIX_ENABLED_TIERS mid-suite isn't possible; it's exercised implicitly (all claims run through the tier-filtered path with every tier enabled).