Changement d'architecture demande par l'utilisateur : le dataset d'entrainement (TECH_STEP_TRAINING_DATA) quitte apps/api pour vivre entierement dans services/tech-step-intent-service (intent_service/training_data.py). Ce service est desormais autonome : il s'entraine lui-meme une seule fois, a son propre demarrage (PipelineRegistry.initialize, dans le lifespan FastAPI), sans plus dependre d'un POST /v1/train pousse par apps/api (route supprimee). apps/api ne connait plus aucune technique/synonyme, uniquement le resultat de POST /v1/process. Corpus enrichi avec les 48 techniques du lexique fourni (Arroser, Appertiser, Braiser, Caraméliser, Confire, Julienne/Brunoise/Mirepoix/ Paysanne, Cuire à blanc/au bain-marie/à l'étouffée, Déglacer variantes, Emulsionner, Glacer, Pocher, Réduire, Suer, Zester, etc.), soit 74 techniques au total (26 + 48). Integration complete bout en bout : - reference-seed-data.ts : 48 nouvelles entrees TECH_STEPS - apps/web/locales/fr/translation.json : libelles francais correspondants - "Mitonner" fondu comme synonyme de simmer (pas une technique distincte, sa propre definition le dit) - "Blanchir un oeuf" (whiskPale) distingue de "Blanchir un legume" (blanch, existant) via des synonymes en phrase complete plutot qu'au mot nu — filter_spans (deja en place) resout la collision par specificite Impact performance mesure : le corpus elargi (74 classes vs 26) rend l'entrainement bien plus lent a nombre d'iterations egal (150 iterations depassait 17 minutes par run de test) — reduit a 40 iterations apres mesures repetees en local (~200s/locale, ~400s pour fr+en combines). docker-compose.yml (healthcheck start_period 600s), CI (timeout curl 600s) et le README du service documentent ce nouveau temps de demarrage. CONFIDENCE_THRESHOLD recalibre a 0.2 par verification manuelle (0.75 puis 0.45 ne tenaient plus compte tenu du nombre de classes) — marque explicitement comme placeholder en attendant une vraie repasse de calibrate-tech-step-threshold.ts (necessite Postgres, indisponible dans cet environnement). Verifie : 28/28 tests pytest du service (suite complete re-ecrite pour s'entrainer une seule fois par session sur le vrai corpus, fixture partagee dans conftest.py), lint + build complets du monorepo. La suite Mocha d'apps/api reste a confirmer via CI (le root hook mocha n'attend plus l'entrainement, seulement CI's propre attente sur /health). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
31 lines
1.4 KiB
Python
31 lines
1.4 KiB
Python
"""`Settings` (`intent_service/config.py`) lève dès l'import si
|
|
`INTENT_SERVICE_SECRET` est absent — cette variable doit donc être définie
|
|
avant le tout premier `import intent_service...` de la session pytest.
|
|
`conftest.py` est chargé par pytest avant la collecte des modules de test,
|
|
donc avant que `test_routes_process.py`/`test_security.py` n'importent
|
|
`intent_service.main`.
|
|
"""
|
|
|
|
import os
|
|
|
|
os.environ.setdefault("INTENT_SERVICE_SECRET", "pytest-only-secret-not-used-anywhere-else-32ch")
|
|
|
|
import pytest # noqa: E402 — après le `setdefault` ci-dessus, voir le docstring.
|
|
from fastapi.testclient import TestClient # noqa: E402
|
|
|
|
from intent_service.main import app # noqa: E402
|
|
|
|
|
|
@pytest.fixture(scope="session")
|
|
def client():
|
|
"""`TestClient(app)` utilisé comme gestionnaire de contexte déclenche le
|
|
vrai `lifespan` — puisque `main.py`'s `lifespan` entraîne maintenant
|
|
l'intégralité du vrai corpus `training_data.TECH_STEP_TRAINING_DATA`
|
|
(pas un jeu jouet, voir `PipelineRegistry.initialize`), refaire ça une
|
|
fois par fichier de test (ou pire, une fois par test) multiplierait un
|
|
entraînement non négligeable sur toute la suite pour rien — scope
|
|
"session" pour que chaque test ayant besoin d'une vraie app en cours
|
|
d'exécution partage la même instance déjà entraînée.
|
|
"""
|
|
with TestClient(app) as test_client:
|
|
yield test_client
|