Nicolas
18abae7b6a
Remplace TechStepClassifierService's node-nlp (NlpManager) par services/tech-step-intent-service, un microservice FastAPI/spaCy dedie (PhraseMatcher pour le NER par synonymes, textcat pour la classification d'intention). Corpus (TECH_STEP_TRAINING_DATA) toujours possede par apps/api, pousse au service via POST /v1/train a chaque warm-up ; le service ne touche jamais Postgres (meme posture que services/tech-step-llm-worker). Cote apps/api : - intent-service-client.ts : client HTTP vers le nouveau service - tech-step-matcher.ts : delegue NER + intent classification au client, logique pure (splitIntoClauses, seuil/fallback) inchangee - env.ts : INTENT_SERVICE_BASE_URL/INTENT_SERVICE_SECRET (secret requis, service coeur non optionnel) - server.ts : warm-up avec retry/backoff (service Python demarre a part) - scripts/calibrate-tech-step-threshold.ts : recalibration empirique de CONFIDENCE_THRESHOLD contre le jeu d'eval existant - node-nlp retire (package.json, node-nlp.d.ts, model.nlp du .gitignore) docker-compose.yml : nouveau service tech-step-intent-service (pas de port expose, healthcheck, app en depend). CI : job intent-service-test (pytest) + le job test demarre le service en arriere-plan avant la suite Mocha (jamais de mock d'un service interne, cf specs/dev-conventions.md). Verifie : 26/26 tests pytest du service (dont les offsets caracteres exacts de tech-step-matcher.test.ts), lint + build complets du monorepo, smoke test HTTP reel bout en bout. La suite Mocha et docker compose build/up n'ont pas pu etre executes dans cet environnement (pas de Postgres/Docker disponibles ici) — a confirmer via la CI et en local. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
44 lines
2.2 KiB
Python
44 lines
2.2 KiB
Python
"""Configuration du service, lue depuis l'environnement (`pydantic-settings`).
|
|
|
|
Contrairement à `requireInternalWorker` côté `apps/api`
|
|
(`apps/api/src/middlewares/require-internal-worker.ts`), qui tolère un
|
|
`INTERNAL_WORKER_SECRET` absent (le worker LLM est un job de fond
|
|
optionnel) et échoue "juste" requête par requête dans ce cas, ce service est
|
|
une dépendance coeur : `INTENT_SERVICE_SECRET` absent doit empêcher
|
|
`uvicorn` de démarrer du tout plutôt que de démarrer dans un état où chaque
|
|
requête échouerait silencieusement en boucle — `Settings` n'a donc aucune
|
|
valeur par défaut ni type optionnel pour ce champ, la validation Pydantic
|
|
lève dès l'import de ce module si la variable manque.
|
|
"""
|
|
|
|
from pydantic_settings import BaseSettings, SettingsConfigDict
|
|
|
|
|
|
class Settings(BaseSettings):
|
|
# `env_file=".env"` : lu uniquement en dev natif (`cp .env.example .env`,
|
|
# voir le README de ce service) — sans effet en Docker, où
|
|
# docker-compose.yml passe les variables directement en `environment:`
|
|
# et où aucun `.env` n'est copié dans l'image. Un `.env` absent n'est pas
|
|
# une erreur ici (pydantic-settings ignore silencieusement un fichier
|
|
# manquant) ; c'est bien `intent_service_secret` ci-dessous, sans valeur
|
|
# par défaut, qui fait échouer le démarrage si la variable n'est
|
|
# disponible par aucune des deux voies.
|
|
#
|
|
# `case_sensitive` par défaut (False) : `INTENT_SERVICE_SECRET` (la
|
|
# convention majuscule utilisée partout ailleurs dans le repo, cf.
|
|
# `docker-compose.yml`/`.env.example`) matche bien le champ
|
|
# `intent_service_secret` ci-dessous.
|
|
model_config = SettingsConfigDict(env_file=".env")
|
|
|
|
# Secret partagé attendu sur le header `X-Intent-Service-Secret` de
|
|
# chaque requête (sauf `GET /health`) — voir `security.py`. Doit matcher
|
|
# `INTENT_SERVICE_SECRET` côté `apps/api/src/config/env.ts`.
|
|
intent_service_secret: str
|
|
|
|
# Pas de `port` ici : `uvicorn` prend son port en argument de ligne de
|
|
# commande (`--port`, voir le Dockerfile et le README de ce service),
|
|
# jamais lu depuis `Settings` — une variable d'env dupliquant ce que la
|
|
# commande de démarrage fixe déjà explicitement n'aurait aucun lecteur.
|
|
|
|
|
|
settings = Settings()
|