drift-ground-truth-fixture-developmentlisted

# Drift Ground-Truth Fixture Development Skill Use this skill when Drift needs reproducible fixture coverage for signal behavior. ## When To Use - A new signal needs baseline TP and TN coverage - A false positive or false negative needs to become a regression fixture - A threshold or calibration change needs boundary coverage - A benign lookalike case needs a confounder fixture - A signal depends on history-like data and needs `file_history_overrides` ## Core Rules 1. **Run the Drift Policy Gate first.** Fixtures should validate admissible work, not justify inadmissible work. 2. **Keep fixtures minimal and deterministic.** No external dependencies, no hidden runtime assumptions. 3. **Every fixture needs explicit expectations.** Empty fixtures are invalid. 4. **Prefer source-like realism over size.** Small but representative beats large and noisy. 5. **Use fixture kinds intentionally.** TP/TN are the baseline; boundary and confounder cases are for calibration and trust hardening. 6. **Fixture und Logik zusammen bauen — nicht alle Fixtures zuerst.** Eine TP-Fixture schreiben, die passende Signal-Logik implementieren, dann TN. Horizontales Batch-Schreiben produziert Tests gegen imaginiertes Verhalten. 7. **Nur an echten Systemgrenzen mocken.** Externe APIs, Zeit und Dateisystem sind valide Mock-Ziele. Interne Signal-Methoden, AST-Helfer und Scoring-Zwischenwerte nicht — teste ausschließlich den Public-Output von `analyze()`. Kurzregel: AST/Scoring = in-process, direkt testb