feedback creatortrack expensive db data needs durable export 20260715T123219

Justin's existing guardrail ([[ct-dev-slot-commit-often]]) covers code loss from dev-slot reaper wipes (commit often, reaper eats uncommitted worktree changes). It does not cover data loss: rows sitting only in a dev-slot's ephemeral Postgres (e.g. scraped video transcripts, LLM-extracted structures) are invisible to git and get wiped just as easily.

After a corpus was lost once already to a reaper wipe ("last night"), when Justin asked to "save what we have so far so our clot doesn't get ripped away again," the fix was exporting the expensive, slow-to-regenerate rows to a durable JSONL file on Console's real disk outside any slot (forge/data/creatortrack/social-transcripts-ws85.jsonl), separate from and in addition to code commits.

Why: re-scraping a lost corpus costs hours (rate-limited ingest, ~6h to reconverge); a JSONL export + tested restore script reduces that to a 2-second restore. Committing code alone does not protect data-only artifacts sitting in a dev-slot's database.

How to apply: whenever a dev-slot pipeline produces expensive-to-regenerate data (scrapes, LLM batch outputs, anything rate-limited or slow to redo) and that data lives only in the slot's Postgres, export it to a durable JSONL/file outside the slot as soon as a meaningful chunk exists, don't wait for the pipeline to fully converge. Pair the export with a tested restore path (see [[creatortrack_lifeos_psql_copy_json_corruption]]) before trusting it.

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