# Standalone image for services/tech-step-intent-service — hors du build
# apps/api (voir services/tech-step-llm-worker/Dockerfile pour le précédent
# direct : un service Python/spaCy n'a rien à faire dans l'image Node de
# l'API, et inversement). Rien n'est persisté sur disque (pas de VOLUME,
# contrairement au worker LLM) : tout l'état (textcat/matcher entraînés)
# vit en mémoire, reconstruit à chaque `/v1/train` depuis un corpus que ce
# service ne possède pas lui-même (voir intent_service/README.md).
FROM python:3.12-slim AS base
RUN apt-get update && apt-get install -y --no-install-recommends ca-certificates && rm -rf /var/lib/apt/lists/*
COPY --from=ghcr.io/astral-sh/uv:latest /uv /usr/local/bin/uv
WORKDIR /service

FROM base AS build
# `uv.lock` est commité pour ce service (même rigueur que
# `pnpm-lock.yaml`/`--frozen-lockfile` pour apps/api et
# services/tech-step-llm-worker) — `--frozen` échoue bruyamment si
# `pyproject.toml` a dérivé du lock plutôt que de re-résoudre en silence.
# `--no-install-project` sépare l'installation des dépendances (dont les
# wheels de modèles spaCy, pinnés par URL dans pyproject.toml) de la copie
# du code applicatif, pour que le cache de layer Docker survive à un
# changement dans intent_service/ sans retélécharger ~80 Mo de modèles.
# Chemins préfixés par `services/tech-step-intent-service/` : le contexte
# de build est la racine du repo (`docker-compose.yml`'s `build.context: .`),
# même convention que `services/tech-step-llm-worker/Dockerfile`.
COPY services/tech-step-intent-service/pyproject.toml services/tech-step-intent-service/uv.lock ./
RUN uv sync --frozen --no-install-project --no-dev
COPY services/tech-step-intent-service/intent_service ./intent_service
RUN uv sync --frozen --no-dev

FROM base AS runtime
ENV PYTHONUNBUFFERED=1
COPY --from=build /service /service
EXPOSE 8000
CMD ["uv", "run", "uvicorn", "intent_service.main:app", "--host", "0.0.0.0", "--port", "8000"]