project creatortrack social meta rebase drift 20260715T213311

During the CreatorTrack overnight build (Social data-layer app + Scripts/voice-profile app, 19 build tasks + 5 meta-ingest tasks, worked in parallel worktrees off two feature branches), main moved 67 commits ahead mid-flight. That drift wasn't just migration-ordering noise: it hardened workspace-scoping on core create operations (createTask/createNode/createBlock — "require explicit workspace for core creates," "align workspace create gates with RLS," "key creator app grants by workspace id") and added new migrations (workspace-slug registry, scheduling/booking schema). Both feature branches use createTask/createNode/createBlock for their send-to-Task/Page feature — exactly the API whose contract changed.

Why: Both branches were verified clean via whole-branch review (migrations don't collide, upsert preservation contracts hold, no circular imports) against their own history, but that review predates the main drift. A plain rebase risks silently breaking the now-changed create-path contract in send-to-Task/Page code, not just causing textual merge conflicts.

How to apply: Before running /ship on either the phase-1 (Social+Scripts) or phase-2 (meta-ingest, feat/social-meta-ingest) branch, confirm the rebase-onto-main analysis (dispatched as a dedicated agent pass) has explicitly checked every createTask/createNode/createBlock call site in the new code against the current main contract, not just mechanical conflict resolution. Treat this as a semantic-review gate, separate from the ordinary migration-collision check.

[auto-memory session 60d132de-4659-485c-8044-427af0ccce7f, confidence 0.72, mode staged]