Feedback dev slot data needs durable export
name: Dev-slot databases: committed code survives reaper, DB data does not description: Data living only in a dev-slot's database (scrapes, ingests, LLM outputs) is not protected by 'commit often' — the reaper's safety check only looks at git, not DB contents. type: feedback
A CreatorTrack transcript-ingest job populated a dev-slot's disposable database with 548 scraped YouTube transcripts, all code was committed, but the reaper still wiped the whole slot (DB included) after 3h of ingest silence, because its safety check only asks "any uncommitted git changes?" and has no concept of valuable data sitting outside git. The scrape had to restart from zero.
Why: git commits protect code, not database rows. Any expensive-to-regenerate dataset (web scrapes, LLM extraction passes, long-running ingests) that lands in a dev-slot Postgres instance is exactly as ephemeral as the slot itself, regardless of commit hygiene.
How to apply: for any future large/slow/expensive data-producing job that runs inside a CreatorTrack dev slot (or any disposable sandbox), export the data to a plain file on durable storage (Console's real disk, outside the slot) as a standing practice during the job, not as a recovery step after a wipe. Treat "commit often" ([[ct-dev-slot-commit-often]]) as necessary but not sufficient — it only covers code. Pair it with a durable export path for anything landing in the slot's DB. This is distinct from the reaper's own claimed-slot protection fixes (band-1/2 teardown guard, protect-list), which reduce the chance of a wipe but don't eliminate the risk — the export is the real safety net.
[auto-memory session 60d132de-4659-485c-8044-427af0ccce7f, confidence 0.85, mode direct]