perf(capture): reuse a resident embedding worker

[cdeust]

Symptôme

W3-1c / F1 : chaque capture admise relançait Python, le handler et le modèle, même au cours de la même session.

Cause racine

La durée de vie du processus d’encodage était celle du hook. Les singletons du store et du modèle ne pouvaient pas être réutilisés entre événements.

Changement

Le hook conserve filtrage, nettoyage et payload remember, puis transmet à un worker résident par CORTEX_CLAUDE_DIR résolu. Socket UNIX privé, vérification des UID des deux pairs, lease flock, un travail actif et une place en attente. Le worker traite les requêtes sur sa boucle persistante et ferme ses stores avant de libérer sa lease. Les erreurs sont visibles ; il n’exécute pas l’inférence dans le hook en secours.

L’ACK signifie admis en mémoire volatile, pas écrit en base. Un crash après ACK peut perdre le travail accepté ; aucune répétition automatique d’une livraison incertaine. Le premier chargement reste froid. La plateforme Windows est explicitement refusée pour ce mécanisme UNIX.

Preuve

Avant 198d6b13ce89cefe560e24da9cf98ebf565f42c9, après 806f66a088514b82a914c42746e8d4814a323abd. macOS ARM64, Python3.13.7, modèle neural réel en cache durable, SQLite jetable. Quatre répétitions, première écartée ; un seul travail lourd local.

Mesure sur les captures de session	Avant	Après
CPU médian du hook	2,80 s	0,05 s
Wall médiane du hook	3,40 s	0,10 s
RSS max médiane du hook	491487232 octets	26755072 octets
remember chaud, p50	2796,931 ms	12,262 ms
premier remember après	—	2955,573 ms
Processus/modèles pour quatre événements	4/4	1/1

Le worker conserve environ493Mo résidents. Les sept encodages chauds diagnostiques ont une médiane CPU8,850ms. Ces mesures sont distinctes du CPU du hook. Chaque payload, toutes les colonnes hors created_at/heat_base_set_at/last_accessed et tous les vecteurs bruts1536octets sont conservés. Les PID65493/66832 de cette mesure ont été arrêtés après vérification d'identité, leur sortie est vérifiée. Pas de gain d'énergie physique revendiqué. Ce nouvel A/B ne mesure pas séparément le coût marginal du verrou par rapport à une ancienne session.

/Users/cdeust/Developments/anthropic-partnership/Cortex/.venv/bin/python /private/tmp/cortex-green-w3-capture-measure.py --phase c --before /private/tmp/cortex-green-w3-1b-final --after /private/tmp/cortex-green-w3-1c-gate-fix --output /private/tmp/cortex-green-w3-1c-capture-ci-repair --project /private/tmp/cortex-green-hook-fixture/project --cache-root /Users/cdeust/.cache --timeout-seconds 10 --poll-seconds 0.01 --worker-idle-seconds 300 --execute
bash /private/tmp/cortex-green-local-gates.sh w3-1c-final-ordered-v3 tests_py/hooks tests_py/infrastructure

Report /private/tmp/cortex-green-w3-1c-capture-ci-repair/report.json, commandes enfant et diagnostics inclus ; relecture des lignes/vecteurs /private/tmp/cortex-green-w3-1c-capture-ci-repair-proof.json. uptime08:38→08:40, charge3,11→4,40 pour10cœurs ; df -h /38Gi avant/après.

Les traces CI Python3.10 et SQLite ont révélé deux défauts corrigés : Future.TimeoutError était distinct du builtin avant3.11, et un second client pouvait inspecter le socket entre bind et chmod. Toutes les connexions passent désormais sous le verrou de publication, sans relâcher les permissions0600 ; envoi et admission restent hors verrou. Trois régressions échouent sur le vrai Python3.10.18 avant, puis29 tests du cycle/protocole/sécurité passent après. Le test de publication force cette fenêtre par événements. Source : contrat Future TimeoutError.

Gates finaux sur806f66a0 : uv verrouillé, Ruff/format, craftsmanship et Pyright (zéro diagnostic) verts. Couches : 1111 passed, 101 skipped, 3 warnings, 16 subtests passed in 47.66s. Suite complète : 7781 passed, 221 skipped, 3 warnings, 429 subtests passed in 154.44s (0:02:34). Log /private/tmp/cortex-green-w3-1c-final-ordered-v3-gates.log, PG volontairement inaccessible. uptime/df -h / encadrent la suite dans ce journal. CI GitHub entièrement verte sur806f66a0 :18contrôles réussis et3ignorés attendus, dont Python3.10 et SQLite réussis.

La gate globale reproduce.sh après W3 reste ouverte ; la référence6ec76a0e échoue déjà à certains floors. Le contrôle scalaire/batch a conduit à corriger séparément W3-4 ; aucun floor n’est abaissé. PR brouillon tant que la qualité complète n’est pas validée.

État CI du 2026-09-07 : tous les contrôles de 806f66a088514b82a914c42746e8d4814a323abd sont réussis ou attendus ignorés. La première reproduction complète de la pile W3 sur 0b978d7 a terminé avec échec des floors existants ; les trois passes LoCoMo sont terminées, sans recul des moyennes MRR/R10 par rapport à la référence. La CI verte ne clôt pas cette gate.

Reproduction complète commune à la pile W3 — trois passes LoCoMo terminées

Le vrai pilote reproduce.sh a terminé sur 0b978d7, après tous les contrôles W3 verts. Référence : 6ec76a0. Le tableau compare les premières passes complètes, valeurs arrondies ; il ne remplace pas la moyenne LoCoMo sur trois passes.

Corpus	Questions	MRR avant → après	Recall@10 avant → après	Durée en secondes avant → après
LongMemEval	500	0,904988 → 0,904988	0,978000 → 0,978000	1676,888 → 1680,788
LoCoMo	1982	0,781201 → 0,780265	0,889001 → 0,887487	2051,173 → 2042,735
BEAM	395	0,533336 → 0,532453	0,716944 → 0,716667	744,912 → 740,546

Sortie du pilote : 1. Le floor MRR LongMemEval et les deux floors LoCoMo échouent ; ils échouaient déjà sur main. Aucun seuil n'est abaissé. Les deux répétitions LoCoMo prescrites par reproduce.sh:338–350 sont terminées sur la même tête. Moyenne MRR avant → après : 0,779867618 → 0,781210992 ; Recall@10 : 0,889505550 → 0,889505550. Aucun recul n'est observé sur ces deux moyennes LoCoMo ; cela ne démontre pas une amélioration statistique ni une garantie générale. Les seuils effectifs MRR 0,800 / Recall@10 0,910 restent manqués. BEAM n'a pas de seuil dans le pilote : ses minima ont été demandés au propriétaire, aucune réussite BEAM n'est inventée.

Commande effective du pilote, dans chaque arbre figé et l'environnement fermé consigné par le lanceur :

bash benchmarks/_green_reproduce_transport_local.sh --no-ablation

Ce fichier temporaire est le pilote original avec une insertion de transport UNIX vers son propre conteneur ; protocoles, données, modèles et floors ne sont pas réécrits. Commande exacte de lancement W3 :

python3 /private/tmp/cortex-green-run-private-quality.py /Users/cdeust/Developments/anthropic-partnership/Cortex final-w3-worker-fixed-r1

Python 3.12.11/macOS ARM64, Torch 2.13.0, sentence-transformers 5.6.1 et psycopg 3.3.5 ; mêmes versions et poids de modèles vérifiés dans les manifestes. MiniLM révision 1110a243, reranker L-12 actif. Sur 10 cœurs, charge 1 min référence 2,369→5,647 et W3 2,854→5,404. Espace libre enregistré dans les manifestes : référence 50 543 837 184 → 49 479 544 832 octets, W3 40 884 998 144 → 40 118 521 856 octets ; uptime initial et df -h / avant/après dans les logs. Un seul travail lourd local. Aucun gain d'énergie ou de latence globale n'est revendiqué.

Preuves complètes : référence /private/tmp/cortex-green-final-main/benchmarks/results/repro/20260907T015046Z/, W3 benchmarks/results/repro/20260907T071015Z/, comparaison /private/tmp/cortex-green-final-w3-quality-comparison.json. Les trois résultats, MANIFEST et preuve de transport sont présents. Le conteneur 92770dee et son ancien socket ont été vérifiés absents après nettoyage : /private/tmp/cortex-green-final-w3-r1-cleanup-proof.json. Les deux répétitions supplémentaires sont terminées, avec nettoyage vérifié. La gate globale reste ouverte et cette PR reste en brouillon.

Répétitions LoCoMo W3 — 1 982 questions chacune

Passe	MRR	Recall@10	Secondes	Dossier de résultats
1	0,780265244	0,887487386	2042,735	20260907T071015Z
2	0,782550294	0,891523713	2032,414	20260907T082518Z
3	0,780817436	0,889505550	2036,426	20260907T085915Z

Les passes 2 et 3 utilisent la même commande de lancement, avec les labels final-w3-worker-fixed-r2 et final-w3-worker-fixed-r3 et l'option --only locomo. Chaque passe crée puis supprime ses propres ressources. Les trois conteneurs et anciens dossiers de sockets sont vérifiés absents dans /private/tmp/cortex-green-final-w3-r1-cleanup-proof.json, -r2-cleanup-proof.json et -r3-cleanup-proof.json. Valeurs intégrales et moyenne : /private/tmp/cortex-green-final-w3-locomo-three-runs.json.

Conformité

• Règles1–2 : branche par item, base W3-1b, commits conventionnels et gates ordonnés verts avant push ; pas de fusion.
• Règle3 : craftsmanship vert, baseline non élargie ; TTL300s issu du timeout MCP existant, délai10s issu du timeout du hook, capacité1 de rendez-vous structurelle ; enveloppe issue des limites de contenu existantes. Sources dans capture-worker-design.md.
• Règle4 : erreurs explicites, modèle hors/tmp, aucun fallback d’inférence dans le hook ; cache résident nommé comme remplaçant du processus jetable.
• Règle5 : SQLite et état du worker jetables ; qualité globale ouverte.
• Règles6–7 : une charge lourde à la fois ; aucune opération sur les données de production.
• Règles8–9 : aucune issue ouverte ; rapports datés aux SHA finaux ci-dessus.
• Règle10 : porte de confiance du reranker inchangée.

Candidats issues

Une livraison durable après ACK nécessiterait un autre contrat : elle n’est pas revendiquée ici. Le coût froid et la mémoire résidente restent explicites. Le chargement hooks→handlers existant est réutilisé sans nouvelle exemption de couche.

Runbook

Aucune migration ni purge. Le worker démarre à la première capture et expire après300s d’inactivité suivant la dernière requête terminée ; CORTEX_CAPTURE_IDLE_SECONDS configure cette durée avec validation stricte. Les demandes actives/en attente n’expirent pas par ce TTL. Consulter le journal privé rotatif du worker pour les erreurs. Une capture exclue par le mode W3-1b ne démarre pas le worker.