Reference creatortrack reaper claimed slot protection
name: CreatorTrack dev-slot reaper: claimed slots now protected in mem-bands 1-2 description: Reaper no longer full-teardowns claimed slots in bands 1-2 (idle detector missed DB writes + API calls); kills next dev process only, worktree+DB survive. Band 3 (>85% mem) still full-teardown. Commit 9138ace, 2026-07-15. type: reference
The dev-slot reaper's idle detector (browser connections + file edits) does not see DB writes or outbound API calls, so a slot mid-ingest (e.g. transcript scraping writing rows to app.social_videos) can look abandoned once the foreground work finishes. Previously, any idle claimed slot in mem-bands 1-2 (none<60%/3h, 60-85%/45m) got a full teardown once its git tree was clean, which deletes the slot DB along with the worktree. This destroyed a slot DB holding ~6 hours of scraped transcript data on 2026-07-15 because the worker had (correctly, per doctrine) committed all code, making the tree look safe to wipe.
Fix (commit 9138ace): idle claimed slots in bands 1-2 now get --server-only teardown — the next dev process is killed (100% of the RAM the reaper exists to reclaim), but the worktree and DB survive and the slot stays claimed so the warm-pool won't reassign it. Discarding a claimed slot's DB now requires a deliberate release. Band 3 (>85% mem, real OOM risk) keeps full-teardown authority regardless of claim state.
Why: a clean git tree certifies code safety, never data safety — see [[feedback_disposable_store_expensive_data_export]].
How to apply: when reasoning about the CreatorTrack dev-slot reaper (reference_creatortrack_dev_slot_reaper.md) or warm-slot pool, assume claimed slots in bands 1-2 are now DB-safe; only band 3 or an explicit release can drop slot data.
[auto-memory session 60d132de-4659-485c-8044-427af0ccce7f, confidence 0.85, mode direct]