feedback ct slot reaper data loss scope 20260715T100349

The CreatorTrack dev-slot reaper hazard is broader than previously documented (see [[ct-dev-slot-commit-often]]): it's not only uncommitted git changes at risk, it's ANY expensive-to-acquire data living in the slot's local database. During an overnight transcript-ingest task, the :3067 dev server died from Console memory pressure; the warm-slot pool saw the claimed slot's dev server as dead, released the slot, and rebuilt it fresh from the prod clone. All 4 commits survived on the branch, but ~548 rows of transcript data (hours of rate-limited YouTube scraping) were wiped because they only existed in the slot-local DB.

Why: Committing code isn't sufficient protection for work that also writes expensive, slow-to-regenerate data into a warm dev slot's database. A dead dev server process (not just memory-band eviction) is enough to trigger slot release and a destructive rebuild.

How to apply: For any task that ingests/scrapes/generates data into a CT dev-slot DB and that data is costly to reproduce (rate-limited APIs, long scrapes, expensive LLM calls), add a mandatory step to export that data to a durable location outside the slot (e.g. forge/data/creatortrack/*.jsonl) with a documented restore command, as soon as it's captured, not just at the end. Treat slot-local DB state as ephemeral cache, never as the source of truth for anything expensive to regenerate.

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