fix: rotate telemetry and detached worker logs (W2-3) - #485

Symptôme

W2-3 / F9 : telemetry.jsonl et les deux journaux de workers croissent sans rotation. Les handles ouverts par les spawns SessionStart ne sont pas fermés explicitement dans le parent. PR empilée sur #484.

Cause racine

Les trois chemins ouvrent les journaux en append sans politique de taille. Un handler logging local ne coordonnerait pas les processus de hooks indépendants. Le doublon historique session_log.json n'a déjà plus aucun lecteur ni écrivain dans les sources à la base de cette PR.

Changement

Écriture/rotation sous verrou local et interprocessus stable, avec fichier actif et un segment .1. Seuil 5 880 000 octets, dérivé du constat fourni F9 (196 000 octets/jour × 30 jours), sans prétendre l'avoir remesuré en production. Télémétrie : vérification à chaque append en octets UTF-8, lignes entières et compteurs en mémoire conservés. Workers : rotation avant les trois spawns, descripteur du parent fermé après Popen, même en cas d'erreur.

Les journaux de workers respectent désormais la racine CORTEX_CLAUDE_DIR comme la télémétrie ; les tests vérifient une racine distincte de HOME. Le runbook fournit une migration one-shot propriétaire pour le seul fichier legacy, uniquement si son JSON strict correspond au fichier canonique avec types conservés ; liens, données divergentes et clés dupliquées sont refusés. Aucun shim ni migration automatique.

Sources : Python RotatingFileHandler, journalisation multiprocessus, fcntl.flock, msvcrt.locking.

Preuve

Base 288603fb5758522eddf81f3d6d572b09abf61f55, Python 3.13.7, macOS ARM64. Fixture synthétique au seuil F9 : avant, append de six octets → fichier 5 880 006, aucune archive ; après → actif 6, segment précédent 5 880 000. Rapport /private/tmp/cortex-green-w2-3-fixture.json. Fichiers sparse temporaires : tailles logiques, aucun espace physique libéré revendiqué.

Tests : seuil réel F9, multioctets, record trop grand, deux processus écrivant autour d'une rotation, liens, erreurs, handles parents fermés, trois spawns et migration du runbook exécutée sur fixtures. Recherche exacte rg -n -F 'session_log.json' mcp_server scripts vide avant/après ; le répertoire racine hooks/ n'existe pas.

bash /private/tmp/cortex-green-unit-isolated.sh tests_py.shared.test_log_rotation tests_py.core.test_telemetry_rotation tests_py.hooks.test_worker_log_rotation tests_py.scripts.test_log_migration_runbook
bash /private/tmp/cortex-green-local-gates.sh w2-3-final tests_py/core/ tests_py/hooks/ tests_py/shared/ tests_py/scripts/

18 tests ciblés passent en 0,751 s. Gates finaux terminés code 0 : Ruff/format 1 435 fichiers, craftsmanship, Pyright zéro diagnostic ; couches affectées 5 209 passed, 19 skipped, 348 subtests en 49,62 s ; suite complète 7 659 passed, 221 skipped, 348 subtests en 140,21 s. Journal /private/tmp/cortex-green-w2-3-final-gates.log. Charge initiale 4,68 / 10 cœurs ; disque 60 GiB avant/après. PG explicitement absent sur socket privé, SQLite et journaux isolés. Première passe verte (7 658 tests) suivie de cette passe finale après correction prouvée de la comparaison legacy true/1. SHA final 3243dfed51d9b1b2e243918554ea2b83213de864. CI externe 34045319036 terminée verte sur ce SHA.

Conformité

Helpers partagés stdlib seulement ; core n'importe aucune infrastructure. Aucun processus collecteur, aucune nouvelle dépendance ni entrée baseline. Nouveaux modules et fonctions sous les limites du contrat ; dette préexistante des hooks inchangée. Données et journaux de validation privés, un seul travail lourd local.

Candidats issues

Un worker déjà lancé conserve son descripteur et peut dépasser le seuil ou écrire dans .1 après rotation. Windows peut refuser le renommage d'un fichier encore ouvert : l'erreur est rapportée par la frontière existante. Ce n'est pas un quota disque. Un record surdimensionné est conservé entier. La première archive peut contenir tout l'ancien fichier trop grand ; la suivante la remplace. Aucun gain d'énergie ou de disque réel annoncé, aucun ticket créé.

Runbook

Voir docs/runbooks/local-log-rotation.md. Le propriétaire archive l'historique qu'il veut conserver avant activation. La migration legacy est réservée au propriétaire après arrêt des sessions, avec racine explicite ; elle n'est exécutée ni au démarrage ni à l'installation. Aucun journal historique inspecté ou modifié durant cette tâche.