fix(tech-steps): empêche le contexte d'un match d'avaler une correction manuelle voisine

La correction manuelle ne s'affichait pas quand elle portait sur du texte
qui n'était pas une technique à l'origine — reproduit en live : une
description avec un seul match auto-détecté ("mijoter") voit son
contexte de clause s'étendre sur toute la description dès que
splitIntoClauses (tech-step-matcher.ts) n'a trouvé qu'un seul candidat
NER (le cas courant), même quand ce candidat n'a aucun rapport avec le
reste du texte. splitDescriptionByTechSteps avançait alors son curseur
jusqu'à la fin de ce contexte large, ce qui faisait purement et
simplement disparaître (silencieusement, sans erreur) toute correction
manuelle ajoutée plus loin dans la même description — un mot pourtant
sans aucun rapport avec la technique auto-détectée.

Le contexte d'un match est purement cosmétique (StepDescription.tsx le
rend identique à du texte brut depuis que sa mise en valeur dédiée a
été désactivée) et ne doit donc jamais coûter son propre highlight à
un *autre* match. splitDescriptionByTechSteps distingue maintenant
deux notions : le chevauchement entre les spans *keyword* stricts de
deux entrées (toujours un vrai conflit, l'entrée la plus tardive est
toujours ignorée, comportement inchangé) et le chevauchement du
contexte *cosmétique* d'une entrée sur le keyword d'une autre (jamais
un vrai conflit désormais : le contexte est simplement rogné pour
laisser la place, plutôt que l'entrée voisine entière étant abandonnée).

Vérifié en conditions réelles (Docker) : une correction manuelle sur
"materiel" dans "Faire mijoter la sauce, puis ranger le materiel."
s'affiche maintenant correctement à côté du highlight auto "mijoter",
et survit à un rechargement complet de la page.

Nouveau test de régression dans highlight-tech-steps.cy.tsx
reproduisant exactement ce cas ; les 18 tests du fichier (dont tous
les cas de contexte/malformation déjà couverts) passent toujours.

.env.example

@@ -15,43 +15,6 @@ JWT_SECRET=changeme-generate-a-real-random-secret-at-least-32-chars
 # (docker-compose.yml), serving both the API and the built frontend.
 # APP_PORT=3000
 
-# Optional — tag of the prebuilt images the release CI pushes to the Forgejo
-# container registry (git.dev.kyuno.fr/kyuno/batchcooking-{app,intent-service,
-# llm-worker}). Used by `docker compose pull` and a pull-based Portainer
-# stack; leave it `latest` or pin a release tag (e.g. v0.2.4). Ignored when
-# building locally instead (`docker compose build`, or `up` with no image
-# present) — see docker-compose.yml's `image:`/`build:` comment.
-# IMAGE_TAG=latest
-
-# --- Admin surface (apps/web's /admin/* routes + the /admin/* API) --------
-# All optional: an instance that doesn't run the admin app needs none of
-# these. `requireAdmin` fails closed when ADMIN_JWT_SECRET is unset, so
-# leaving it out simply disables every /admin/* route. The admin UI is
-# served by the same app/container as the rest of the frontend — no
-# separate origin, so no CORS entry of its own.
-#
-# Secret for the admin session JWT — MUST be different from JWT_SECRET so an
-# end-user token can never be replayed against /admin/*. Generate your own
-# the same way as JWT_SECRET above.
-# ADMIN_JWT_SECRET=changeme-generate-a-real-random-secret-at-least-32-chars
-# Optional — read only by `src/scripts/create-admin.ts` when its --email /
-# --password / --name flags are omitted (e.g. to bootstrap the first admin
-# from inside the container). Never read by the running server.
-# ADMIN_INITIAL_EMAIL=ops@example.com
-# ADMIN_INITIAL_PASSWORD=changeme-at-least-8-chars
-# ADMIN_INITIAL_NAME=Ops
-#
-# Optional — lets an admin open a Forgejo ticket from a contact message
-# (apps/web's /admin/messages, issue #81). All three needed together: the
-# button stays hidden and the endpoint answers 503 unless all are set to a
-# non-empty value. docker-compose.yml forwards these into the "app"
-# container, so setting them here is enough (a blank value counts as
-# unset). FORGEJO_TOKEN is a personal access token with the write:issue
-# scope — generate it in Forgejo, never commit the real value.
-# FORGEJO_BASE_URL=https://git.example.com
-# FORGEJO_TOKEN=changeme-a-forgejo-personal-access-token
-# FORGEJO_REPO=owner/repo
-
 # Optional — only set this to false if THIS deployment is served over
 # plain HTTP (no TLS in front of it). Left unset, the session cookie
 # requires HTTPS (Secure attribute) as it should for a real deployment;
@@ -59,14 +22,6 @@ JWT_SECRET=changeme-generate-a-real-random-secret-at-least-32-chars
 # browser, so login "succeeds" but every subsequent request 401s.
 # COOKIE_SECURE=false
 
-# Required — secret shared between "app" and "tech-step-intent-service"
-# (docker-compose.yml, apps/api/src/config/env.ts). Unlike
-# INTERNAL_WORKER_SECRET below, there's no "leave it unset" escape hatch:
-# tech-step-intent-service is a core dependency, not an optional background
-# job — without it, no recipe step can have its techniques detected at all.
-# Generate your own the same way as JWT_SECRET above.
-INTENT_SERVICE_SECRET=changeme-generate-a-real-random-secret-at-least-32-chars
-
 # Only needed to run the optional `tech-step-llm-worker` service — shared
 # between it and "app" (docker-compose.yml). Generate your own the same
 # way as JWT_SECRET above; leave both this and the service commented

.github/workflows/ci.yml

@@ -12,53 +12,26 @@ on:
   push:
 
 env:
-  # Hostname `postgres` = the container the `test` job starts itself (see
-  # that job's "Start Postgres" step) — a plain `docker run`, not a
-  # `services:` block, for the same reason the intent-service below can't be
-  # one: this repo's Forgejo `act` runner does not keep a `services:`
-  # container as the *same* instance across a job's steps, so `migrate
-  # deploy` would land the schema in one Postgres and `pnpm --filter api
-  # test`'s `beforeAll` would then hit an empty one ("table … does not
-  # exist" right after "migrations successfully applied"). One long-lived
-  # container in the job, shared by every step, removes that failure mode.
-  DATABASE_URL: "postgresql://ci:ci@postgres:5432/batchcooking_ci?schema=public"
+  DATABASE_URL: "postgresql://ci:ci@localhost:5432/batchcooking_ci?schema=public"
   # Test-only secret, never used outside CI — real deployments must set their own.
   JWT_SECRET: "ci-only-secret-not-used-anywhere-else-32chars+"
   # Same reasoning as JWT_SECRET above — lets tech-step-worker.routes.test.ts
   # exercise the success path (matching secret), not just the "unset"
   # rejection every environment that doesn't set this gets by default.
   INTERNAL_WORKER_SECRET: "ci-only-worker-secret-not-used-anywhere-else-32chars+"
-  # Same reasoning — lets admin-auth.test.ts exercise the admin login
-  # success path + the requireAdmin-guarded routes, not just the "no admin
-  # secret configured -> 401" path.
-  ADMIN_JWT_SECRET: "ci-only-admin-secret-not-used-anywhere-else-32chars+"
-  # Shared between the `test` job's own uvicorn step (below) and apps/api's
-  # IntentServiceClient — that step runs `uvicorn` as a plain background
-  # process (not a `services:` block or even a container) because CI can
-  # only pull a published image, not build
-  # services/tech-step-intent-service/Dockerfile from this checkout.
-  INTENT_SERVICE_BASE_URL: "http://localhost:8000"
-  INTENT_SERVICE_SECRET: "ci-only-intent-secret-not-used-anywhere-else-32chars+"
-  # Same reasoning — lets forgejo.service.test.ts / admin-contact.test.ts
-  # exercise the "configured" path (issue #81). `globalThis.fetch` is stubbed
-  # in those tests, so no real request ever leaves CI; these values only need
-  # to parse (a valid URL and an `owner/repo`).
-  FORGEJO_BASE_URL: "https://forgejo.ci.invalid"
-  FORGEJO_TOKEN: "ci-only-forgejo-token-not-used-anywhere-else"
-  FORGEJO_REPO: "ci/batchcooking"
 
 jobs:
-  # Five independent jobs, no needs: between them — each starts in parallel
+  # Four independent jobs, no needs: between them — each starts in parallel
   # and reports as its own check, instead of the previous single chained
   # "lint-and-test then e2e" pipeline.
   lint:
     runs-on: ubuntu-latest
     steps:
-      - uses: https://github.com/actions/checkout@v4
+      - uses: actions/checkout@v4
 
       - uses: pnpm/action-setup@v4
 
-      - uses: https://github.com/actions/setup-node@v4
+      - uses: actions/setup-node@v4
         with:
           node-version: 22
           cache: pnpm
@@ -68,166 +41,42 @@ jobs:
 
   test:
     runs-on: ubuntu-latest
-    # ~16-19 min of actual work (runs 117-124); the extra budget covers time
-    # spent queued in "Wait for any earlier test job" below. Also a runaway
-    # ceiling — Mocha has no `--exit` (`apps/api/.mocharc.json`), so one
-    # leaked handle would otherwise hang the job until the runner's global
-    # timeout (a `test` job zombied ~1h once). If a hung job hits this
-    # ceiling the runner removes its container, which unblocks the queue.
-    timeout-minutes: 45
+    services:
+      postgres:
+        image: postgres:16-alpine
+        env:
+          POSTGRES_USER: ci
+          POSTGRES_PASSWORD: ci
+          POSTGRES_DB: batchcooking_ci
+        ports:
+          - 5432:5432
+        options: >-
+          --health-cmd pg_isready
+          --health-interval 5s
+          --health-timeout 5s
+          --health-retries 10
     steps:
-      - name: Install curl and the docker CLI
-        run: |
-          apt-get update && apt-get install -y curl docker.io
-
-      # Serialize `test` across every concurrent run. Two `test` jobs must
-      # never overlap: they share one `--name postgres` container on the
-      # runner's shared docker network (next step), so their `prisma migrate
-      # deploy` + `seedReferenceData` (root Mocha `beforeAll`) race —
-      # `Unique constraint failed on (key)` in `seedReferenceData`, "No
-      # pending migrations" when there should be some, `tech_step`/`diet` id
-      # shifts breaking unrelated assertions; and even past that they starve
-      # each other's RAM/CPU (each also trains a spaCy model) until
-      # `resetDatabase()` overruns Mocha's 10s hook timeout and cascades.
-      # Hit repeatedly (PRs #47, #53, #54), each needing an empty-commit
-      # re-trigger once the runner was idle.
-      #
-      # GitHub's `concurrency:` is the native fix but this Forgejo (9.0.3)
-      # predates Actions `concurrency` — it arrived in Forgejo v14 / Gitea
-      # 1.26 and is silently ignored here. A lock object (network, container,
-      # file) would leak: this runner (forgejo-runner v3.5.0) does NOT run a
-      # trailing `if: always()` step after an earlier step fails, so there is
-      # no reliable in-job release. Instead, key off the one thing the runner
-      # *does* always clean up — the job container itself (removed on pass,
-      # fail, and cancel alike): wait while any lower-numbered `test` job's
-      # container is still running. Lower task id goes first, so two jobs
-      # that start together can't deadlock; nothing to release.
-      - name: Wait for any earlier test job
-        run: |
-          my_id="$(printf '%s\n' "${JOB_CONTAINER_NAME:-}" | sed -n 's/.*TASK-\([0-9]\{1,\}\).*/\1/p')"
-          echo "this test job is task ${my_id:-<unknown, not serializing>}"
-          # ~25 min cap (75 * 20s): comfortably covers one earlier run
-          # (the realistic overlap is two runs); a rarer 3-way pile-up whose
-          # wait exceeds this just fails and gets an empty-commit re-run.
-          for attempt in $(seq 1 75); do
-            earlier="$(docker ps --format '{{.Names}}' 2>/dev/null \
-              | sed -n 's/.*TASK-\([0-9]\{1,\}\)_.*_JOB-test$/\1/p' \
-              | awk -v me="${my_id:-0}" 'NF && ($1 + 0) < (me + 0)')"
-            if [ -z "$earlier" ]; then
-              [ "$attempt" -gt 1 ] && echo "earlier test job(s) finished — proceeding"
-              exit 0
-            fi
-            echo "waiting for earlier test job(s): $(printf '%s ' $earlier)(attempt ${attempt})"
-            sleep 20
-          done
-          echo "still blocked by an earlier test job after ~25 min — giving up; a re-run should get through" >&2
-          exit 1
-
-      # Postgres as a plain background container instead of a `services:`
-      # block — see this workflow's top-level `env.DATABASE_URL` comment for
-      # why. Reachable as `postgres` from this job (the runner mounts the
-      # docker socket and runs jobs on a shared user-defined network, so a
-      # `--name postgres` sibling resolves by name); the network is
-      # discovered from the job container itself rather than hardcoded. The
-      # `docker rm -f postgres` below also clears a container left behind by
-      # the previous run (this runner has no reliable post-job cleanup), and
-      # the serialization step above means no other run is using it now.
-      - name: Start Postgres in the background
-        run: |
-          net="$(docker inspect "$(hostname)" \
-            --format '{{range $k, $_ := .NetworkSettings.Networks}}{{$k}} {{end}}' \
-            | awk '{print $1}')"
-          echo "job network: ${net:?could not determine the job container network}"
-          docker rm -f postgres >/dev/null 2>&1 || true
-          # Also drop any `postgres-<suffix>` container. A since-reverted
-          # attempt at per-run Postgres naming on this branch left some
-          # running on this persistent runner (their `if: always()` teardown
-          # never fired — this runner skips trailing steps after a failure),
-          # and nothing else removes them. A second idle Postgres here starves
-          # the runner's RAM and slows every query ~5x → `resetDatabase()`
-          # blows Mocha's 10s hook timeout. Nothing creates `postgres-*` any
-          # more, so this only ever clears that debris.
-          docker ps -aq --filter 'name=^postgres-' | xargs -r docker rm -f >/dev/null 2>&1 || true
-          docker run -d --name postgres --network "$net" \
-            -e POSTGRES_USER=ci -e POSTGRES_PASSWORD=ci -e POSTGRES_DB=batchcooking_ci \
-            postgres:16-alpine
-          for _ in $(seq 1 60); do
-            docker exec postgres pg_isready -U ci -d batchcooking_ci && exit 0
-            sleep 2
-          done
-          echo "Postgres did not become ready in time" >&2
-          docker logs postgres || true
-          exit 1
-
-      - uses: https://github.com/actions/checkout@v4
+      - uses: actions/checkout@v4
 
       - uses: pnpm/action-setup@v4
 
-      - uses: https://github.com/actions/setup-node@v4
+      - uses: actions/setup-node@v4
         with:
           node-version: 22
           cache: pnpm
 
-      - uses: https://github.com/astral-sh/setup-uv@v5
-        with:
-          python-version: "3.12"
-          enable-cache: true
-
-      # A `services:` block can only pull an already-published image — it
-      # can't build services/tech-step-intent-service/Dockerfile from this
-      # checkout. Running `uvicorn` as a plain background step instead: it
-      # keeps running for the rest of this job (steps in one job share the
-      # same process tree), and `pnpm --filter api test` below needs a real
-      # instance to talk to per this repo's "never mock an internal service"
-      # test convention — same "real dependency, started by the job itself"
-      # posture as the Postgres step above, not a mock HTTP server.
-      - name: Install services/tech-step-intent-service
-        working-directory: services/tech-step-intent-service
-        run: uv sync --frozen
-      - name: Start services/tech-step-intent-service in the background
-        working-directory: services/tech-step-intent-service
-        run: |
-          uv run uvicorn intent_service.main:app --host 0.0.0.0 --port 8000 &
-          # `/health` only returns 200 once this service has finished
-          # training itself from scratch (no model ever persisted to disk —
-          # see its own README) — measured at ~3min combined (fr+en) against
-          # the current ~74-technique corpus, down from ~930s once
-          # `spacy.TextCatBOW.v3`'s `length` stopped being left at its
-          # 262144 default (see `_TEXTCAT_MODEL_LENGTH` in
-          # `locale_pipeline.py`, and docker-compose.yml's healthcheck for
-          # the same reasoning). The timeout stays well above that: it's a
-          # ceiling for a slow/contended runner, not a target.
-          timeout 600 bash -c 'until curl -sf http://localhost:8000/health > /dev/null; do sleep 2; done'
-
       - run: pnpm install --frozen-lockfile
       - run: pnpm --filter api exec prisma migrate deploy
       - run: pnpm --filter api test
 
-  intent-service-test:
-    runs-on: ubuntu-latest
-    steps:
-      - uses: https://github.com/actions/checkout@v4
-
-      - uses: https://github.com/astral-sh/setup-uv@v5
-        with:
-          python-version: "3.12"
-          enable-cache: true
-
-      - name: Install services/tech-step-intent-service
-        working-directory: services/tech-step-intent-service
-        run: uv sync --frozen
-      - name: Run pytest
-        working-directory: services/tech-step-intent-service
-        run: uv run pytest -q
-
   build:
     runs-on: ubuntu-latest
     steps:
-      - uses: https://github.com/actions/checkout@v4
+      - uses: actions/checkout@v4
 
       - uses: pnpm/action-setup@v4
 
-      - uses: https://github.com/actions/setup-node@v4
+      - uses: actions/setup-node@v4
         with:
           node-version: 22
           cache: pnpm
@@ -238,22 +87,17 @@ jobs:
   e2e:
     runs-on: ubuntu-latest
     steps:
-      - uses: https://github.com/actions/checkout@v4
-      
-      - name: Install Xvfb and Cypress dependencies
-        run: |
-          apt-get update
-          apt-get install -y xvfb libgtk2.0-0 libgtk-3-0 libgbm-dev libnotify-dev libnss3 libxss1 libasound2 libxtst6 xauth dbus-x11
+      - uses: actions/checkout@v4
 
       - uses: pnpm/action-setup@v4
 
-      - uses: https://github.com/actions/setup-node@v4
+      - uses: actions/setup-node@v4
         with:
           node-version: 22
           cache: pnpm
 
       - name: Cache Cypress binary
-        uses: https://github.com/actions/cache@v4
+        uses: actions/cache@v4
         with:
           path: ~/.cache/Cypress
           key: cypress-${{ runner.os }}-${{ hashFiles('pnpm-lock.yaml') }}
@@ -263,99 +107,9 @@ jobs:
       # download (see apps/web's cypress caveat in the README) — install it
       # explicitly so `cypress run` finds it.
       - run: pnpm --filter web exec cypress install
-      - name: Run E2E tests
-        env:
-          HOST: "0.0.0.0"
-        run: pnpm --filter web e2e
+      - run: pnpm --filter web e2e
       # No dev server needed here — Cypress spins up its own Vite dev
       # server internally for component testing (see cypress.config.ts's
       # `component.devServer`), unlike `e2e` above which needs the real app
       # running first.
       - run: pnpm --filter web cy:run:component
-
-  # Builds and packages a signed, downloadable Android APK on every push to
-  # `main` — issue #64. `needs:` on every other job is what actually makes
-  # this "build, TEST, and package" rather than just "build and package in
-  # parallel with tests that might still be failing": Forgejo/GitHub Actions
-  # has no native way for a job in a *different* workflow file to block on
-  # one here, so this has to live in this same file to get a real dependency
-  # rather than a same-push coincidence. `if:` (not a separate trigger) keeps
-  # every other job running on every branch as today — only this one is
-  # main-only.
-  #
-  # No dedicated Android test suite exists (zero native code beyond the
-  # Capacitor-generated shell) — "testée" is satisfied by gating on the 5
-  # existing jobs, not by inventing an instrumented test suite for this.
-  #
-  # Unverified on this runner as of writing: no Android build has ever run
-  # on this self-hosted Forgejo `act` runner (unlike lint/test/build/e2e,
-  # exercised for months). If SDK installation turns out too slow/heavy here,
-  # cache `~/.android/sdk`/`~/.gradle` (same idea as the Cypress binary cache
-  # in `e2e` above) rather than accepting a slow job on every push.
-  build-android:
-    runs-on: ubuntu-latest
-    needs: [lint, test, intent-service-test, build, e2e]
-    if: github.ref == 'refs/heads/main'
-    steps:
-      - uses: https://github.com/actions/checkout@v4
-
-      - uses: pnpm/action-setup@v4
-
-      - uses: https://github.com/actions/setup-node@v4
-        with:
-          node-version: 22
-          cache: pnpm
-
-      - uses: https://github.com/actions/setup-java@v4
-        with:
-          distribution: temurin
-          # Matches what Android Gradle Plugin 8.x (bundled with the
-          # Capacitor-generated project, see apps/web/android/build.gradle)
-          # expects — bump alongside AGP if that version ever moves.
-          java-version: "21"
-
-      - uses: https://github.com/android-actions/setup-android@v3
-
-      - run: pnpm install --frozen-lockfile
-
-      # Unlike the normal web build (served same-origin as the API), a
-      # packaged Capacitor build runs from the WebView's own local origin and
-      # needs an absolute, public HTTPS URL baked in at build time — see
-      # apps/web/.env.capacitor.example's own comment on this.
-      - name: Build le bundle web pour Capacitor
-        env:
-          VITE_API_URL: ${{ secrets.MOBILE_API_URL }}
-        run: pnpm --filter web build:capacitor
-      - run: pnpm --filter web exec cap sync android
-
-      # Le keystore de release est un secret généré une fois à la main (voir
-      # le README, section "Application mobile") — jamais régénéré ici, un
-      # nouveau keystore casserait la mise à jour de l'appli déjà installée
-      # (Android refuse une signature différente de celle déjà installée).
-      - name: Décode le keystore de release
-        env:
-          ANDROID_KEYSTORE_BASE64: ${{ secrets.ANDROID_KEYSTORE_BASE64 }}
-        run: echo "$ANDROID_KEYSTORE_BASE64" | base64 -d > apps/web/android/app/release.keystore
-
-      - name: Build l'APK signé
-        working-directory: apps/web/android
-        env:
-          ANDROID_KEYSTORE_PATH: release.keystore
-          ANDROID_KEYSTORE_PASSWORD: ${{ secrets.ANDROID_KEYSTORE_PASSWORD }}
-          ANDROID_KEY_ALIAS: ${{ secrets.ANDROID_KEY_ALIAS }}
-          ANDROID_KEY_PASSWORD: ${{ secrets.ANDROID_KEY_PASSWORD }}
-        # chmod défensif : le dev de ce repo se fait sous Windows, où le bit
-        # exécutable git de gradlew ne veut rien dire et peut être reperdu
-        # silencieusement par un futur commit — ne pas dépendre uniquement
-        # du mode suivi par git (voir aussi le fix de ce mode lui-même).
-        run: |
-          chmod +x ./gradlew
-          ./gradlew assembleRelease
-
-      # v4+ exige l'API "Results" de GitHub, que ce runner Forgejo self-hosted
-      # ne supporte pas ("GHESNotSupportedError") — v3 utilise encore
-      # l'ancienne API Artifacts (compatible), seule version utilisable ici.
-      - uses: https://github.com/actions/upload-artifact@v3
-        with:
-          name: batchcooking-release.apk
-          path: apps/web/android/app/build/outputs/apk/release/app-release.apk

.github/workflows/release.yml

@@ -1,243 +1,44 @@
 name: Release
 
-# On a `vX.Y.Z` tag: build the three service images and push them to this
-# Forgejo instance's built-in container registry (git.dev.kyuno.fr/<owner>/
-# batchcooking-{app,intent-service,llm-worker}, tagged with the release tag
-# and `latest`), build+attach a signed Android APK, publish a Forgejo
-# Release, then (best-effort) ping Portainer's deploy webhook. Portainer can
-# pull those prebuilt images (docker-compose.yml references them via
-# ${IMAGE_TAG}) or keep building from the Git remote — `docker-compose.yml`
-# keeps a `build:` fallback next to every `image:`.
+# No image registry involved: Portainer is wired to this repo's Git remote
+# and builds/redeploys apps/api/Dockerfile itself. This workflow sanity-checks
+# that the image actually builds at the tagged commit, publishes a GitHub
+# Release, then (best-effort) pings Portainer's deploy webhook so it doesn't
+# have to wait for its own polling interval.
 on:
   push:
     tags: ["v*.*.*"]
 
 permissions:
   contents: write
-  # Lets this workflow's GITHUB_TOKEN push to the Forgejo container registry
-  # (the `build-and-push-images` job below `docker login`s with it). If a
-  # future instance policy scopes the run token tighter, swap that login's
-  # password for a `write:package` PAT added as a repo secret.
-  packages: write
 
 jobs:
-  # Build the three service images at the tagged commit and push them to the
-  # Forgejo container registry. A successful push also *is* the "does it
-  # still build" check the old `sanity-build` job did (which only covered
-  # apps/api). One sequential job, not a per-image matrix: three concurrent
-  # `docker build`s hammer this single persistent runner's Docker daemon
-  # (the contended resource per project memory `ci-forgejo-runner-constraints`)
-  # for no real gain on a release, which is rare and usually runs alone.
-  build-and-push-images:
+  sanity-build:
     runs-on: ubuntu-latest
     steps:
-      # This runner's job containers don't come with docker preinstalled —
-      # same reason ci.yml's `test` job has to do this before its own
-      # `docker run` calls.
-      - name: Install docker
-        run: apt-get update && apt-get install -y docker.io
+      - uses: actions/checkout@v4
 
-      - uses: https://github.com/actions/checkout@v4
+      # Build only, no push, no registry — just confirms Portainer will be
+      # able to build this same Dockerfile successfully at this tag before
+      # anyone points it at this ref.
+      - run: docker build -f apps/api/Dockerfile .
 
-      - name: Build et push des 3 images vers le registre Forgejo
-        env:
-          # The per-run token Forgejo Actions mints — has `packages: write`
-          # via this workflow's `permissions:` block. `docker login` accepts
-          # it as the password for the actor who pushed the tag.
-          REGISTRY_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        run: |
-          set -eu
-          # $GITHUB_SERVER_URL is "https://git.dev.kyuno.fr" — the registry
-          # is that same host. $GITHUB_REPOSITORY is "<owner>/<repo>"; the
-          # registry namespace is the owner, lower-cased (Forgejo package
-          # names are case-insensitive but the CLI wants a stable form).
-          registry="${GITHUB_SERVER_URL#http*://}"
-          owner="$(printf '%s' "${GITHUB_REPOSITORY%%/*}" | tr '[:upper:]' '[:lower:]')"
-          tag="$GITHUB_REF_NAME"
-          echo "$REGISTRY_TOKEN" | docker login "$registry" -u "$GITHUB_ACTOR" --password-stdin
-
-          # Every Dockerfile's build context is the repo root (see
-          # docker-compose.yml's `build.context: .`), hence the trailing `.`.
-          build_push() {
-            image="$registry/$owner/$1"
-            echo "::group::$1"
-            docker build -f "$2" -t "$image:$tag" -t "$image:latest" .
-            docker push "$image:$tag"
-            docker push "$image:latest"
-            echo "::endgroup::"
-          }
-          build_push batchcooking-app            apps/api/Dockerfile
-          build_push batchcooking-intent-service services/tech-step-intent-service/Dockerfile
-          build_push batchcooking-llm-worker     services/tech-step-llm-worker/Dockerfile
-
-  # Builds the same signed APK as ci.yml's build-android job (issue #64),
-  # with one difference: the version baked into the APK is derived from the
-  # tag itself rather than left at build.gradle's default. Duplicated here
-  # rather than factored into a shared `workflow_call` reusable workflow —
-  # deliberate: reusable-workflow support on this self-hosted Forgejo/act
-  # runner is unverified, and this ~15-line recipe is proven working as-is
-  # in ci.yml; not worth risking a new class of runner-compatibility surprise
-  # (this repo has already hit several — see ci-forgejo-runner-constraints
-  # in project memory) to save a little duplication. Keep both copies in
-  # sync if the Android build steps ever change.
-  build-android-apk:
+  github-release:
     runs-on: ubuntu-latest
+    needs: sanity-build
     steps:
-      - uses: https://github.com/actions/checkout@v4
+      - uses: actions/checkout@v4
 
-      - uses: pnpm/action-setup@v4
-
-      - uses: https://github.com/actions/setup-node@v4
+      - uses: softprops/action-gh-release@v2
         with:
-          node-version: 22
-          cache: pnpm
-
-      - uses: https://github.com/actions/setup-java@v4
-        with:
-          distribution: temurin
-          java-version: "21"
-
-      - uses: https://github.com/android-actions/setup-android@v3
-
-      - run: pnpm install --frozen-lockfile
-
-      - name: Build le bundle web pour Capacitor
-        env:
-          VITE_API_URL: ${{ secrets.MOBILE_API_URL }}
-        run: pnpm --filter web build:capacitor
-      - run: pnpm --filter web exec cap sync android
-
-      - name: Décode le keystore de release
-        env:
-          ANDROID_KEYSTORE_BASE64: ${{ secrets.ANDROID_KEYSTORE_BASE64 }}
-        run: echo "$ANDROID_KEYSTORE_BASE64" | base64 -d > apps/web/android/app/release.keystore
-
-      - name: Dérive versionName/versionCode depuis le tag
-        # GITHUB_REF_NAME = "v1.4.2" pour un tag `v1.4.2` — versionName =
-        # "1.4.2" (sans le `v`), versionCode = majeur*10000 + mineur*100 +
-        # correctif (ex. 1.4.2 -> 10402), un entier strictement croissant à
-        # chaque release comme Android l'exige (jamais réutilisé, jamais
-        # décroissant) tant que chaque partie reste sous 100 (largement
-        # suffisant ici). Exposé aux steps suivants via $GITHUB_ENV plutôt
-        # que recalculé.
-        run: |
-          tag="${GITHUB_REF_NAME#v}"
-          major="$(echo "$tag" | cut -d. -f1)"
-          minor="$(echo "$tag" | cut -d. -f2)"
-          patch="$(echo "$tag" | cut -d. -f3)"
-          # Préfixe 10# : force une lecture en base 10, sinon bash lirait
-          # un composant à zéro non significatif (ex. "08") comme de
-          # l'octal invalide et échouerait.
-          code=$((10#$major * 10000 + 10#$minor * 100 + 10#$patch))
-          echo "Version dérivée du tag $GITHUB_REF_NAME : versionName=$tag versionCode=$code"
-          echo "ANDROID_VERSION_NAME=$tag" >> "$GITHUB_ENV"
-          echo "ANDROID_VERSION_CODE=$code" >> "$GITHUB_ENV"
-
-      - name: Build l'APK signé
-        working-directory: apps/web/android
-        env:
-          ANDROID_KEYSTORE_PATH: release.keystore
-          ANDROID_KEYSTORE_PASSWORD: ${{ secrets.ANDROID_KEYSTORE_PASSWORD }}
-          ANDROID_KEY_ALIAS: ${{ secrets.ANDROID_KEY_ALIAS }}
-          ANDROID_KEY_PASSWORD: ${{ secrets.ANDROID_KEY_PASSWORD }}
-        run: |
-          chmod +x ./gradlew
-          ./gradlew assembleRelease -PandroidVersionName="$ANDROID_VERSION_NAME" -PandroidVersionCode="$ANDROID_VERSION_CODE"
-
-      # Nom de fichier stable, jamais versionné : la page d'accueil (#65)
-      # pointe vers /releases/latest (Forgejo n'a pas l'équivalent du
-      # raccourci GitHub /releases/latest/download/<fichier>, seul
-      # /releases/latest lui-même résout) — un nom stable évite au moins que
-      # l'utilisateur voie un nom de fichier différent à chaque release une
-      # fois sur la page.
-      - name: Renomme l'APK sous un nom stable
-        run: cp apps/web/android/app/build/outputs/apk/release/app-release.apk batchcooking.apk
-
-      # v4+ exige l'API "Results" de GitHub, non supportée par ce Forgejo
-      # self-hosted ("GHESNotSupportedError") — v3 (ancienne API Artifacts)
-      # est la seule utilisable ici, voir ci.yml's build-android pour la
-      # même contrainte déjà rencontrée.
-      - uses: https://github.com/actions/upload-artifact@v3
-        with:
-          name: batchcooking.apk
-          path: batchcooking.apk
-
-  forgejo-release:
-    runs-on: ubuntu-latest
-    needs: [build-and-push-images, build-android-apk]
-    steps:
-      # Ce runner ne fournit ni docker ni curl par défaut dans ses
-      # conteneurs de job — même constat déjà fait pour docker (voir
-      # build-and-push-images) et pour curl dans ci.yml's test job.
-      - name: Install curl
-        run: apt-get update && apt-get install -y curl
-
-      - uses: https://github.com/actions/checkout@v4
-
-      - uses: https://github.com/actions/download-artifact@v3
-        with:
-          name: batchcooking.apk
-
-      # softprops/action-gh-release (l'action GitHub habituelle pour ça)
-      # échoue systématiquement contre ce Forgejo : sa requête de création
-      # de release répond 405 (vérifié en conditions réelles, tag v0.2.0 —
-      # pas un souci de ref bare comme les autres actions de ce fichier,
-      # une vraie incompatibilité d'API entre les deux plateformes qui n'a
-      # pas de contournement connu côté configuration de l'action). Appelle
-      # directement l'API native de Forgejo plutôt qu'une action tierce
-      # dont la compatibilité GitHub-Forgejo n'est pas garantie.
-      #
-      # Pas d'équivalent à `generate_release_notes` ici (fonctionnalité
-      # propre à GitHub, pas répliquée par l'API Forgejo) — le corps de la
-      # release reste minimal, cohérent avec l'absence d'outillage de
-      # changelog ailleurs dans le repo.
-      - name: Crée (ou récupère) la Release Forgejo
-        id: create-release
-        env:
-          FORGEJO_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        run: |
-          api="$GITHUB_API_URL/repos/$GITHUB_REPOSITORY/releases"
-          body="$(printf '{"tag_name":"%s","name":"%s","draft":false,"prerelease":false}' "$GITHUB_REF_NAME" "$GITHUB_REF_NAME")"
-
-          # POST pour créer la release, code HTTP capturé à part. Si le tag est
-          # déjà connu de Forgejo (tag poussé à la main avant ce workflow, ou
-          # ré-exécution du job), l'API répond 409 : on réutilise alors la
-          # release existante au lieu d'échouer — idempotence, cf. l'incident
-          # du tag v0.2.2 poussé en avance qui a fait tomber ce job sur un 409.
-          code="$(curl -sS -o /tmp/release.json -w '%{http_code}' -X POST "$api" \
-            -H "Authorization: token $FORGEJO_TOKEN" \
-            -H "Content-Type: application/json" \
-            -d "$body")"
-
-          if [ "$code" = "409" ]; then
-            echo "Release $GITHUB_REF_NAME déjà existante (HTTP 409) — récupération de son id."
-            curl -fsS "$api/tags/$GITHUB_REF_NAME" \
-              -H "Authorization: token $FORGEJO_TOKEN" -o /tmp/release.json
-          elif [ "$code" -lt 200 ] || [ "$code" -ge 300 ]; then
-            echo "Échec de création de la Release (HTTP $code) : $(cat /tmp/release.json)" >&2
-            exit 1
-          fi
-
-          id="$(grep -o '"id":[0-9]*' /tmp/release.json | head -1 | cut -d: -f2)"
-          if [ -z "$id" ]; then
-            echo "Pas d'id de release trouvé : $(cat /tmp/release.json)" >&2
-            exit 1
-          fi
-          echo "Release $GITHUB_REF_NAME prête (id=$id)"
-          echo "release-id=$id" >> "$GITHUB_OUTPUT"
-
-      - name: Attache l'APK à la Release
-        env:
-          FORGEJO_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-        run: |
-          api="$GITHUB_API_URL/repos/$GITHUB_REPOSITORY/releases/${{ steps.create-release.outputs.release-id }}/assets"
-          curl -fsS -X POST "$api?name=batchcooking.apk" \
-            -H "Authorization: token $FORGEJO_TOKEN" \
-            -F "attachment=@batchcooking.apk"
+          # Auto-generated from merged PRs since the previous tag — no
+          # changelog tooling to maintain, consistent with there being no
+          # versioning tooling elsewhere in the repo yet.
+          generate_release_notes: true
 
   notify-portainer:
     runs-on: ubuntu-latest
-    needs: forgejo-release
+    needs: github-release
     steps:
       - name: Trigger Portainer redeploy
         # Best-effort: does nothing (and doesn't fail the workflow) until

.gitignore

@@ -70,14 +70,12 @@ web_modules/
 .env.*
 !.env.example
 !.env.test.example
-!.env.capacitor.example
 
-# Python virtualenvs/caches for services/tech-step-intent-service (this repo
-# is otherwise all-Node — see that service's own .gitignore for the rest;
-# duplicated here too since some tooling only honors the repo-root file).
-services/tech-step-intent-service/.venv/
-services/tech-step-intent-service/__pycache__/
-services/tech-step-intent-service/.pytest_cache/
+# node-nlp's default auto-save file (apps/api/src/lib/recipe-matching/
+# tech-step-matcher.ts explicitly disables autoSave/autoLoad, but this is a
+# belt-and-suspenders guard against it ever reappearing — a stale trained
+# model on disk must never silently shadow TECH_STEP_TRAINING_DATA).
+model.nlp
 
 # parcel-bundler cache (https://parceljs.org/)
 .cache
@@ -134,11 +132,6 @@ dist
 # Stores VSCode versions used for testing VSCode extensions
 .vscode-test
 
-# JetBrains IDEs (Android Studio opens this repo as a project once the
-# Capacitor Android app exists under apps/web/android — see that folder's own
-# .gitignore for the generated native project's build artefacts).
-/.idea/
-
 # pnpm
 .pnpm-store
 
@@ -169,6 +162,3 @@ tmp-mockups/
 apps/web/cypress/screenshots/
 apps/web/cypress/videos/
 apps/web/cypress/downloads/
-apps/admin-web/cypress/screenshots/
-apps/admin-web/cypress/videos/
-apps/admin-web/cypress/downloads/

README.md

@@ -44,8 +44,6 @@ runtime Node pur (Docker, pas de transpilation à la volée), voir la note dans
 - Node.js 22 (voir `.nvmrc`)
 - pnpm 10 (`corepack enable` puis `corepack use pnpm@10.12.4`, ou installation manuelle)
 - Docker (pour Postgres en local)
-- Python 3.12+ et [`uv`](https://docs.astral.sh/uv/) (pour
-  `services/tech-step-intent-service` en dev natif — requis, voir plus bas)
 
 ## Installation
 
@@ -102,17 +100,6 @@ pnpm --filter api exec prisma migrate dev
 # techniques...) — automatique après `prisma migrate reset`, sinon à la main :
 pnpm --filter api prisma:seed
 
-# Microservice de détection des techniques (spaCy) — requis, `pnpm dev:api`
-# ne peut plus détecter aucune technique de cuisine sans lui. Lance-le en
-# premier et laisse-le tourner : il s'entraîne lui-même à chaque démarrage
-# (~11 minutes pour le corpus actuel, voir son propre README) avant de
-# répondre quoi que ce soit sur /health.
-cd services/tech-step-intent-service
-uv sync
-cp .env.example .env  # édite-le : même INTENT_SERVICE_SECRET que apps/api/.env
-uv run uvicorn intent_service.main:app --reload --port 8000
-cd ../..
-
 # Backend (http://localhost:3000)
 pnpm dev:api
 
@@ -150,7 +137,7 @@ pnpm --filter web cy:run:component  # tests de composant UI isolés (Cypress com
 pnpm build                    # build de tous les workspaces
 ```
 
-La CI GitHub Actions (`.github/workflows/ci.yml`) exécute cinq jobs indépendants (`lint`, `test`, `intent-service-test`, `build`, `e2e` — ce dernier lance aussi `cy:run:component`) en parallèle, sur chaque push (toutes branches) et sur chaque PR vers `main` — pas de chaînage entre eux, chacun apparaît comme son propre check. `test` démarre `services/tech-step-intent-service` en arrière-plan (voir ce fichier) puisque la suite Mocha ne mocke jamais un service interne. Voir aussi [Déploiement](#déploiement) pour le pipeline de release (`.github/workflows/release.yml`).
+La CI GitHub Actions (`.github/workflows/ci.yml`) exécute quatre jobs indépendants (`lint`, `test`, `build`, `e2e` — ce dernier lance aussi `cy:run:component`) en parallèle, sur chaque push (toutes branches) et sur chaque PR vers `main` — pas de chaînage entre eux, chacun apparaît comme son propre check. Voir aussi [Déploiement](#déploiement) pour le pipeline de release (`.github/workflows/release.yml`).
 
 ### Base de test isolée de la base de dev (`apps/api`)
 
@@ -171,13 +158,6 @@ Un garde-fou (`assertRunningAgainstTestDatabase()`) refuse d'exécuter
 `resetDatabase()` si `DATABASE_URL` ne contient ni `"test"` ni `"ci"` — la
 seule base qu'il doit rejeter est ta vraie base de dev.
 
-`services/tech-step-intent-service` doit aussi tourner en local avant
-`pnpm --filter api test` — les tests touchant `tech-step-matcher.ts` passent
-par le vrai service (jamais un mock, voir
-[specs/dev-conventions.md](specs/dev-conventions.md)) et échouent avec une
-erreur de connexion, pas une assertion utile, s'il n'est pas démarré. Voir la
-section [Développement](#développement) ci-dessus.
-
 ## Déploiement
 
 Une seule image Docker (`apps/api/Dockerfile`) sert à la fois l'API et le frontend
@@ -200,25 +180,15 @@ synchronisation de la table `sources` depuis le registre d'adaptateurs de code
 puis `node dist/server.js`. Les trois étapes sont sûres/idempotentes à
 répéter à chaque redémarrage du conteneur.
 
-Le duo `postgres`/`app` de `docker-compose.yml` n'expose donc qu'un seul port
-applicatif, `APP_PORT` (défaut `3000`) — plus de `WEB_PORT`/`CORS_ORIGIN` à
-coordonner entre deux origines, le frontend et l'API sont désormais servis
-depuis la même origine. Les deux autres services du fichier
-(`tech-step-intent-service`, `tech-step-llm-worker`) n'exposent eux aucun port
-au host — voir leurs propres README pour leur rôle.
+`docker-compose.yml` ne définit donc que deux services : `postgres` et `app` (un
+seul port, `APP_PORT`, défaut `3000` — plus de `WEB_PORT`/`CORS_ORIGIN` à
+coordonner entre deux origines, le frontend et l'API sont désormais servis depuis
+la même origine).
 
-**Registre d'image** : la CI de release (voir plus bas) construit et pousse les
-trois images de service — `batchcooking-app`, `batchcooking-intent-service`,
-`batchcooking-llm-worker` — sur le **registre de conteneurs intégré à Forgejo**
-(`git.dev.kyuno.fr/kyuno/…`), taguées à la fois avec le tag de release (`vX.Y.Z`)
-et `latest`. `docker-compose.yml` référence ces images via `IMAGE_TAG` (variable
-d'environnement, défaut `latest` — voir `.env.example`), tout en gardant un bloc
-`build:` local à côté de chaque `image:` : `docker compose pull` récupère les
-images pré-construites, `docker compose up`/`build` retombe sur un build local si
-elles sont absentes. L'instance **Portainer** de production peut donc désormais
-tirer les images pré-construites (stack en mode *pull*, `IMAGE_TAG` pinné sur la
-release voulue) **ou** continuer à builder elle-même depuis le dépôt Git — les
-deux modes fonctionnent avec le même `docker-compose.yml`.
+**Pas de registre d'image** dans cette configuration : l'instance **Portainer** de
+production est reliée directement au dépôt Git et reconstruit elle-même
+`docker-compose.yml`/`apps/api/Dockerfile` à chaque déploiement — la CI ne pousse
+donc aucune image nulle part.
 
 ### Release (`.github/workflows/release.yml`)
 
@@ -229,80 +199,14 @@ git tag vX.Y.Z
 git push --tags
 ```
 
-Le pipeline enchaîne quatre jobs : `build-and-push-images` (build des 3 images à
-ce tag + push sur le registre Forgejo sous `vX.Y.Z` et `latest` — un push
-réussi vaut aussi vérification que tout build encore à ce commit),
-`build-android-apk` (APK signé, `versionName` dérivé du tag), `forgejo-release`
-(crée la Release Forgejo `vX.Y.Z` et y attache `batchcooking.apk`), puis
-`notify-portainer` — envoie une requête au webhook de redeploy de Portainer si
-le secret de dépôt `PORTAINER_WEBHOOK_URL` est configuré (sinon Portainer se
-resynchronise à son prochain polling). Pour l'activer : récupérer l'URL du
-webhook depuis les réglages du stack Portainer, puis l'ajouter comme secret de
-dépôt `PORTAINER_WEBHOOK_URL`.
-
-## Application mobile (Android)
-
-`apps/web` est empaqueté dans une coquille [Capacitor](https://capacitorjs.com/)
-pour Android — le projet natif est versionné dans `apps/web/android/` (issue
-\#39). L'authentification passe par un jeton Bearer stocké dans le stockage
-sécurisé de Capacitor (le cookie de session `SameSite=Lax` ne part pas depuis
-l'origine interne d'une WebView), et `main.tsx` bascule sur `HashRouter` quand
-`Capacitor.isNativePlatform()` est vrai.
-
-**Prérequis** : Android Studio (SDK Android + un JDK ; le JBR fourni avec
-Android Studio suffit). Aucun serveur Postgres/Docker local n'est nécessaire —
-l'appli parle à l'API HTTPS publique.
-
-**Build** — depuis `apps/web/` :
-
-```bash
-# 1. URL publique de l'API, gravée dans le bundle empaqueté (le build web
-#    normal utilise une URL relative « même origine », impossible ici).
-cp .env.capacitor.example .env.capacitor   # puis renseigner VITE_API_URL
-
-# 2. Build web en mode capacitor + synchronisation dans le projet natif.
-pnpm build:capacitor
-npx cap sync android
-
-# 3. Ouvrir dans Android Studio (build/run/émulateur depuis l'IDE)…
-npx cap open android
-# …ou build/run en ligne de commande si un appareil/émulateur est prêt :
-npx cap run android
-```
-
-Le bundle web copié (`apps/web/android/app/src/main/assets/public/`) est
-git-ignoré : il est régénéré par `pnpm build:capacitor && npx cap sync android`.
-Les icônes et le splash sont générés depuis `apps/web/assets/logo.svg` (voir
-`apps/web/assets/README.md`). iOS est hors périmètre pour l'instant (nécessite
-Xcode/macOS).
-
-**CI — build automatique d'un APK signé** (`.github/workflows/ci.yml`, job
-`build-android`, issue #64) : à chaque push sur `main`, une fois les 5 autres
-jobs verts, un APK release signé est construit et déposé comme artefact de
-run téléchargeable. Secrets du dépôt Forgejo requis (Réglages du dépôt →
-Secrets) :
-
-| Secret | Contenu |
-|---|---|
-| `MOBILE_API_URL` | URL HTTPS publique de l'API — même valeur que `VITE_API_URL` dans `.env.capacitor` |
-| `ANDROID_KEYSTORE_BASE64` | Le keystore de release (`.jks`) encodé en base64 |
-| `ANDROID_KEYSTORE_PASSWORD` | Mot de passe du keystore |
-| `ANDROID_KEY_ALIAS` | Alias de la clé dans le keystore |
-| `ANDROID_KEY_PASSWORD` | Mot de passe de la clé |
-
-Le keystore doit être généré **une seule fois**, à la main, et rester stable
-pour toujours : Android refuse d'installer la mise à jour d'une appli signée
-par une clé différente de celle déjà installée.
-
-```bash
-keytool -genkeypair -v -keystore batchcooking-release.jks \
-  -alias batchcooking -keyalg RSA -keysize 2048 -validity 10000
-base64 -w0 batchcooking-release.jks   # → coller comme secret ANDROID_KEYSTORE_BASE64
-```
-
-Conserver le fichier `.jks` et ses mots de passe en lieu sûr en dehors du
-dépôt (jamais commité — voir `apps/web/android/.gitignore`) : le perdre
-empêche de publier toute future mise à jour de l'appli.
+Le pipeline enchaîne trois jobs : `sanity-build` (build de l'image Docker sans
+push, juste pour vérifier qu'elle build encore à ce tag avant de laisser Portainer
+redéployer dessus), `github-release` (crée une Release GitHub avec changelog
+auto-généré à partir des PRs mergées), puis `notify-portainer` — envoie une requête
+au webhook de redeploy de Portainer si le secret de dépôt `PORTAINER_WEBHOOK_URL`
+est configuré (sinon Portainer se resynchronise simplement à son prochain
+polling Git). Pour l'activer : récupérer l'URL du webhook depuis les réglages du
+stack Portainer, puis l'ajouter comme secret GitHub `PORTAINER_WEBHOOK_URL`.
 
 ## Auth (apps/api)
 

apps/api/.env.example

@@ -11,36 +11,10 @@ JWT_SECRET=changeme-generate-a-real-random-secret-at-least-32-chars
 # Optional — defaults shown (see src/config/env.ts)
 # JWT_EXPIRES_IN=7d
 # AUTH_COOKIE_NAME=session
-# CORS_ORIGIN=http://localhost:5173,https://localhost
-# INTENT_SERVICE_BASE_URL=http://localhost:8000
-
-# Required — services/tech-step-intent-service must be running locally (see
-# that service's own README) for any recipe save/preview to detect
-# techniques at all. Must match that service's own INTENT_SERVICE_SECRET.
-# Generate your own the same way as JWT_SECRET above.
-INTENT_SERVICE_SECRET=changeme-generate-a-real-random-secret-at-least-32-chars
+# CORS_ORIGIN=http://localhost:5173
 
 # Only needed if you're running services/tech-step-llm-worker locally —
 # every /internal/tech-steps/* request is rejected outright while unset.
 # Generate your own the same way as JWT_SECRET above; must match the
 # worker's own INTERNAL_WORKER_SECRET.
 # INTERNAL_WORKER_SECRET=changeme-generate-a-real-random-secret-at-least-32-chars
-
-# Only needed to use the admin surface (apps/web's /admin/* routes) — every
-# /admin/* request 401s while unset (`requireAdmin` fails closed). MUST be a
-# different value than JWT_SECRET. Generate your own the same way.
-# ADMIN_JWT_SECRET=changeme-a-different-random-secret-at-least-32-chars
-# Read only by `src/scripts/create-admin.ts` when its --email/--password/
-# --name flags are omitted — never by the running server.
-# ADMIN_INITIAL_EMAIL=ops@example.com
-# ADMIN_INITIAL_PASSWORD=changeme-at-least-8-chars
-# ADMIN_INITIAL_NAME=Ops
-
-# Only needed to create a Forgejo issue from a contact message
-# (apps/web's /admin/messages, issue #81). The button is hidden and the
-# endpoint answers 503 while any of the three is unset. FORGEJO_TOKEN is a
-# personal access token with the write:issue scope — generate it in Forgejo,
-# never commit the real value.
-# FORGEJO_BASE_URL=https://git.example.com
-# FORGEJO_TOKEN=changeme-a-forgejo-personal-access-token
-# FORGEJO_REPO=owner/repo

apps/api/.env.test.example

@@ -14,23 +14,7 @@ DATABASE_URL="postgresql://changeme:changeme@localhost:5432/batchcooking_test?sc
 #   node -e "console.log(require('crypto').randomBytes(48).toString('hex'))"
 JWT_SECRET=changeme-generate-a-real-random-secret-at-least-32-chars
 
-# Required — the Mocha suite exercises the real techStepClassifier, which
-# now round-trips over HTTP to services/tech-step-intent-service (no mocks
-# of internal services, per this repo's test conventions). Start that
-# service locally first (see its own README) with a matching
-# INTENT_SERVICE_SECRET, or every test touching tech-step-matcher.ts fails
-# with a connection error rather than a useful assertion failure.
-INTENT_SERVICE_BASE_URL=http://localhost:8000
-INTENT_SERVICE_SECRET=changeme-generate-a-real-random-secret-at-least-32-chars
-
 # Optional — only needed to exercise tech-step-worker.routes.test.ts's
 # success path (a request with a matching secret); every other test runs
 # fine without it. Any value at least 32 chars works locally.
 # INTERNAL_WORKER_SECRET=changeme-generate-a-real-random-secret-at-least-32-chars
-
-# Optional — set to run admin-auth.test.ts's login success path and the
-# requireAdmin-guarded routes (any value at least 32 chars). Left unset,
-# those cases self-skip and only the "no secret configured -> 401" path
-# runs. Same "optional in test, fail-closed at runtime" posture as
-# INTERNAL_WORKER_SECRET above.
-# ADMIN_JWT_SECRET=changeme-generate-a-real-random-secret-at-least-32-chars

apps/api/.mocharc.json

@@ -2,6 +2,5 @@
   "extension": ["ts"],
   "spec": "test/**/*.test.ts",
   "node-option": ["import=tsx"],
-  "timeout": 10000,
-  "require": ["test-support/mocha-root-hooks.ts"]
+  "timeout": 10000
 }

apps/api/Dockerfile

@@ -60,11 +60,8 @@ COPY --from=build /repo/apps/web/dist ./apps/web/dist
 
 WORKDIR /repo/apps/api
 EXPOSE 3000
-# Applies pending migrations, seeds the reference data (Diet/Category/
-# Allergy — see src/scripts/seed-runtime.ts), then runs any pending one-time
-# data backfill (src/scripts/backfill-runtime.ts) before starting. migrate
-# deploy only applies pending migrations and the seed upserts by unique
-# name, so both are safe to repeat every start; the backfill step gates
-# itself on a `backfill_state` row (no-op once done) and is written never to
-# fail the boot — see its doc comment.
-CMD ["sh", "-c", "node_modules/.bin/prisma migrate deploy && node dist/scripts/seed-runtime.js && node dist/scripts/backfill-runtime.js && node dist/server.js"]
+# Applies pending migrations, then seeds the reference data (Diet/Category/
+# Allergy — see src/scripts/seed-runtime.ts) before starting. Both steps are
+# safe to repeat on every container start: migrate deploy only applies
+# pending migrations, and the seed upserts by unique name.
+CMD ["sh", "-c", "node_modules/.bin/prisma migrate deploy && node dist/scripts/seed-runtime.js && node dist/server.js"]

apps/api/package.json

@@ -23,12 +23,11 @@
     "@batch-cooking/shared": "workspace:*",
     "@prisma/client": "^5.22.0",
     "argon2": "0.31.2",
-    "cookie": "^2.0.1",
     "dotenv": "^16.4.5",
     "express": "^4.21.1",
     "jsonwebtoken": "^9.0.3",
+    "node-nlp": "4.27.0",
     "prisma": "^5.22.0",
-    "socket.io": "^4.8.3",
     "zod": "^3.23.8"
   },
   "devDependencies": {
@@ -40,7 +39,6 @@
     "chai": "^5.1.2",
     "cross-env": "^10.1.0",
     "mocha": "^10.8.2",
-    "socket.io-client": "^4.8.3",
     "supertest": "^7.0.0",
     "tsx": "^4.19.2",
     "typescript": "^5.7.2"

apps/api/prisma/migrations/20260826120000_utensil_catalog/migration.sql

@@ -1,10 +0,0 @@
--- CreateTable
-CREATE TABLE "utensil" (
-    "id" SERIAL NOT NULL,
-    "key" TEXT NOT NULL,
-
-    CONSTRAINT "utensil_pkey" PRIMARY KEY ("id")
-);
-
--- CreateIndex
-CREATE UNIQUE INDEX "utensil_key_key" ON "utensil"("key");

apps/api/prisma/migrations/20260826121000_step_tech_step_metadata/migration.sql

@@ -1,42 +0,0 @@
--- CreateTable
-CREATE TABLE "step_tech_step_ingredient" (
-    "id" SERIAL NOT NULL,
-    "step_id" INTEGER NOT NULL,
-    "tech_step_order" INTEGER NOT NULL,
-    "ingredient_id" INTEGER NOT NULL,
-    "quantity" DECIMAL(10,2),
-    "unit_id" INTEGER,
-    "start" INTEGER NOT NULL,
-    "end" INTEGER NOT NULL,
-    "source" TEXT NOT NULL DEFAULT 'auto',
-
-    CONSTRAINT "step_tech_step_ingredient_pkey" PRIMARY KEY ("id")
-);
-
--- CreateTable
-CREATE TABLE "step_tech_step_utensil" (
-    "id" SERIAL NOT NULL,
-    "step_id" INTEGER NOT NULL,
-    "tech_step_order" INTEGER NOT NULL,
-    "utensil_id" INTEGER NOT NULL,
-    "start" INTEGER NOT NULL,
-    "end" INTEGER NOT NULL,
-    "source" TEXT NOT NULL DEFAULT 'auto',
-
-    CONSTRAINT "step_tech_step_utensil_pkey" PRIMARY KEY ("id")
-);
-
--- AddForeignKey
-ALTER TABLE "step_tech_step_ingredient" ADD CONSTRAINT "step_tech_step_ingredient_step_id_tech_step_order_fkey" FOREIGN KEY ("step_id", "tech_step_order") REFERENCES "step_tech_step"("step_id", "order") ON DELETE CASCADE ON UPDATE CASCADE;
-
--- AddForeignKey
-ALTER TABLE "step_tech_step_ingredient" ADD CONSTRAINT "step_tech_step_ingredient_ingredient_id_fkey" FOREIGN KEY ("ingredient_id") REFERENCES "ingredients"("id") ON DELETE CASCADE ON UPDATE CASCADE;
-
--- AddForeignKey
-ALTER TABLE "step_tech_step_ingredient" ADD CONSTRAINT "step_tech_step_ingredient_unit_id_fkey" FOREIGN KEY ("unit_id") REFERENCES "unit"("id") ON DELETE SET NULL ON UPDATE CASCADE;
-
--- AddForeignKey
-ALTER TABLE "step_tech_step_utensil" ADD CONSTRAINT "step_tech_step_utensil_step_id_tech_step_order_fkey" FOREIGN KEY ("step_id", "tech_step_order") REFERENCES "step_tech_step"("step_id", "order") ON DELETE CASCADE ON UPDATE CASCADE;
-
--- AddForeignKey
-ALTER TABLE "step_tech_step_utensil" ADD CONSTRAINT "step_tech_step_utensil_utensil_id_fkey" FOREIGN KEY ("utensil_id") REFERENCES "utensil"("id") ON DELETE CASCADE ON UPDATE CASCADE;

apps/api/prisma/migrations/20260828120000_admin_user/migration.sql

@@ -1,15 +0,0 @@
--- CreateTable
-CREATE TABLE "admin_users" (
-    "id" SERIAL NOT NULL,
-    "email" TEXT NOT NULL,
-    "password_hash" TEXT NOT NULL,
-    "name" TEXT NOT NULL,
-    "token_version" INTEGER NOT NULL DEFAULT 0,
-    "created_at" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
-    "last_login_at" TIMESTAMP(3),
-
-    CONSTRAINT "admin_users_pkey" PRIMARY KEY ("id")
-);
-
--- CreateIndex
-CREATE UNIQUE INDEX "admin_users_email_key" ON "admin_users"("email");

apps/api/prisma/migrations/20260828130000_admin_metrics/migration.sql

@@ -1,32 +0,0 @@
--- AlterTable: usage-metrics timestamps. Existing rows adopt the migration's
--- own timestamp (acceptable one-off skew for trend charts — same posture as
--- the ingredient_unit_catalog migration).
-ALTER TABLE "user_profiles" ADD COLUMN "created_at" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP;
-ALTER TABLE "recipe" ADD COLUMN "created_at" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP;
-ALTER TABLE "planning" ADD COLUMN "created_at" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP;
-ALTER TABLE "planning_item" ADD COLUMN "created_at" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP;
-
--- CreateTable
-CREATE TABLE "analytics_events" (
-    "id" SERIAL NOT NULL,
-    "type" TEXT NOT NULL,
-    "actor_type" TEXT NOT NULL,
-    "actor_id" INTEGER,
-    "context" JSONB,
-    "created_at" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
-
-    CONSTRAINT "analytics_events_pkey" PRIMARY KEY ("id")
-);
-
--- CreateIndex
-CREATE INDEX "analytics_events_type_created_at_idx" ON "analytics_events"("type", "created_at");
-
--- CreateTable
-CREATE TABLE "worker_heartbeats" (
-    "worker_key" TEXT NOT NULL,
-    "last_seen_at" TIMESTAMP(3) NOT NULL,
-    "last_run_at" TIMESTAMP(3),
-    "last_result" JSONB,
-
-    CONSTRAINT "worker_heartbeats_pkey" PRIMARY KEY ("worker_key")
-);

apps/api/prisma/migrations/20260828140000_ingredient_placeholder/migration.sql

@@ -1,14 +0,0 @@
--- AlterTable: off-catalog ingredient "placeholder" rows. Every existing row
--- is a real seeded catalog entry, so the flag defaults to false and the four
--- new nullable columns stay NULL for them — no backfill needed.
-ALTER TABLE "ingredients" ADD COLUMN "is_placeholder" BOOLEAN NOT NULL DEFAULT false;
-ALTER TABLE "ingredients" ADD COLUMN "display_name" TEXT;
-ALTER TABLE "ingredients" ADD COLUMN "created_by_id" INTEGER;
-ALTER TABLE "ingredients" ADD COLUMN "created_at" TIMESTAMP(3);
-ALTER TABLE "ingredients" ADD COLUMN "reviewed_at" TIMESTAMP(3);
-
--- CreateIndex
-CREATE INDEX "ingredients_is_placeholder_idx" ON "ingredients"("is_placeholder");
-
--- AddForeignKey
-ALTER TABLE "ingredients" ADD CONSTRAINT "ingredients_created_by_id_fkey" FOREIGN KEY ("created_by_id") REFERENCES "user_profiles"("id") ON DELETE SET NULL ON UPDATE CASCADE;

apps/api/prisma/migrations/20260829120000_step_tech_step_temperature/migration.sql

@@ -1,22 +0,0 @@
--- CreateTable: temperatures mentioned in the same clause as a detected
--- technique — regex-extracted (services/tech-step-intent-service), no
--- foreign key of its own (the structured value is the data). Same
--- composite FK + ON DELETE CASCADE shape as step_tech_step_ingredient /
--- step_tech_step_utensil (see 20260826121000_step_tech_step_metadata).
-CREATE TABLE "step_tech_step_temperature" (
-    "id" SERIAL NOT NULL,
-    "step_id" INTEGER NOT NULL,
-    "tech_step_order" INTEGER NOT NULL,
-    "start" INTEGER NOT NULL,
-    "end" INTEGER NOT NULL,
-    "celsius" DECIMAL(6,2),
-    "gas_mark" INTEGER,
-    "qualitative" TEXT,
-    "raw" TEXT NOT NULL,
-    "source" TEXT NOT NULL DEFAULT 'auto',
-
-    CONSTRAINT "step_tech_step_temperature_pkey" PRIMARY KEY ("id")
-);
-
--- AddForeignKey
-ALTER TABLE "step_tech_step_temperature" ADD CONSTRAINT "step_tech_step_temperature_step_id_tech_step_order_fkey" FOREIGN KEY ("step_id", "tech_step_order") REFERENCES "step_tech_step"("step_id", "order") ON DELETE CASCADE ON UPDATE CASCADE;

apps/api/prisma/migrations/20260904120000_backfill_state/migration.sql

@@ -1,11 +0,0 @@
--- CreateTable: idempotency ledger for one-time data backfills run from the
--- production image's start command (apps/api/Dockerfile CMD ->
--- src/scripts/backfill-runtime.ts). One row per completed backfill, keyed
--- by an opaque backfill name; presence of the row is the "already done,
--- don't repeat" signal. See the `BackfillState` model doc comment.
-CREATE TABLE "backfill_state" (
-    "key" TEXT NOT NULL,
-    "completed_at" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
-
-    CONSTRAINT "backfill_state_pkey" PRIMARY KEY ("key")
-);

apps/api/prisma/migrations/20260905120000_leftovers_portions_requested/migration.sql

@@ -1,27 +0,0 @@
--- Splits "portions to prepare" from "portions actually needed" on a
--- planning slot, and adds the two columns a leftovers-serving item needs
--- (its source item + how much of its own pool was thrown away). Purely
--- additive — no existing column renamed. See the `PlanningItem` model doc
--- comments and issue #34.
-
--- `discarded_portions` and `source_planning_item_id` are trivial adds.
-ALTER TABLE "planning_item"
-  ADD COLUMN "discarded_portions" INTEGER NOT NULL DEFAULT 0,
-  ADD COLUMN "source_planning_item_id" INTEGER;
-
--- `portions_requested` is NOT NULL but the table may have rows already:
--- add it nullable, backfill, then lock it down — same discipline as the
--- `ingredient_unit_catalog` / `planning_item_portions` migrations. Every
--- pre-existing row predates this feature, so it had no leftovers:
--- requested == prepared at the time it was added.
-ALTER TABLE "planning_item" ADD COLUMN "portions_requested" INTEGER;
-UPDATE "planning_item" SET "portions_requested" = "portions";
-ALTER TABLE "planning_item" ALTER COLUMN "portions_requested" SET NOT NULL;
-
--- Self-FK for a "leftovers" item pointing back at the item it draws from.
--- ON DELETE CASCADE: removing the source item removes everything served
--- from its pool too (same as the Planning -> PlanningItem cascade).
-ALTER TABLE "planning_item"
-  ADD CONSTRAINT "planning_item_source_planning_item_id_fkey"
-  FOREIGN KEY ("source_planning_item_id") REFERENCES "planning_item"("id")
-  ON DELETE CASCADE ON UPDATE CASCADE;

apps/api/prisma/migrations/20260906120000_tour_scenarios/migration.sql

@@ -1,65 +0,0 @@
--- Guided-tour scenarios, their steps, the catalogue of valid highlight
--- targets, and per-user "seen" progress. All four tables are new — plain
--- CREATEs, nothing to backfill. See issues #42 (the tour engine) and #44
--- (admin CRUD + the DB-backed model this migration implements, which
--- revises #42's originally-planned in-code registry).
-
--- CreateTable
-CREATE TABLE "tour_target" (
-    "key" TEXT NOT NULL,
-    "description" TEXT NOT NULL,
-
-    CONSTRAINT "tour_target_pkey" PRIMARY KEY ("key")
-);
-
--- CreateTable
-CREATE TABLE "tour_scenario" (
-    "id" SERIAL NOT NULL,
-    "key" TEXT NOT NULL,
-    "name" TEXT NOT NULL,
-    "enabled" BOOLEAN NOT NULL DEFAULT true,
-    "created_at" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
-    "updated_at" TIMESTAMP(3) NOT NULL,
-
-    CONSTRAINT "tour_scenario_pkey" PRIMARY KEY ("id")
-);
-
--- CreateTable
-CREATE TABLE "tour_scenario_step" (
-    "id" SERIAL NOT NULL,
-    "scenario_id" INTEGER NOT NULL,
-    "order" INTEGER NOT NULL,
-    "route" TEXT,
-    "target_key" TEXT NOT NULL,
-    "title" TEXT NOT NULL,
-    "content" TEXT NOT NULL,
-
-    CONSTRAINT "tour_scenario_step_pkey" PRIMARY KEY ("id")
-);
-
--- CreateTable
-CREATE TABLE "tour_progress" (
-    "user_profile_id" INTEGER NOT NULL,
-    "scenario_id" INTEGER NOT NULL,
-    "completed_at" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
-
-    CONSTRAINT "tour_progress_pkey" PRIMARY KEY ("user_profile_id","scenario_id")
-);
-
--- CreateIndex
-CREATE UNIQUE INDEX "tour_scenario_key_key" ON "tour_scenario"("key");
-
--- CreateIndex
-CREATE UNIQUE INDEX "tour_scenario_step_scenario_id_order_key" ON "tour_scenario_step"("scenario_id", "order");
-
--- AddForeignKey
-ALTER TABLE "tour_scenario_step" ADD CONSTRAINT "tour_scenario_step_scenario_id_fkey" FOREIGN KEY ("scenario_id") REFERENCES "tour_scenario"("id") ON DELETE CASCADE ON UPDATE CASCADE;
-
--- AddForeignKey
-ALTER TABLE "tour_scenario_step" ADD CONSTRAINT "tour_scenario_step_target_key_fkey" FOREIGN KEY ("target_key") REFERENCES "tour_target"("key") ON DELETE RESTRICT ON UPDATE CASCADE;
-
--- AddForeignKey
-ALTER TABLE "tour_progress" ADD CONSTRAINT "tour_progress_user_profile_id_fkey" FOREIGN KEY ("user_profile_id") REFERENCES "user_profiles"("id") ON DELETE CASCADE ON UPDATE CASCADE;
-
--- AddForeignKey
-ALTER TABLE "tour_progress" ADD CONSTRAINT "tour_progress_scenario_id_fkey" FOREIGN KEY ("scenario_id") REFERENCES "tour_scenario"("id") ON DELETE CASCADE ON UPDATE CASCADE;

apps/api/prisma/migrations/20260908120000_contact_message/migration.sql

@@ -1,23 +0,0 @@
--- Contact-form messages (issue #80). New table only — nothing to backfill.
--- `author_id` is nullable with ON DELETE SET NULL so a report survives its
--- sender's account deletion (same as ingredients.created_by_id).
-
--- CreateTable
-CREATE TABLE "contact_message" (
-    "id" SERIAL NOT NULL,
-    "author_id" INTEGER,
-    "type" TEXT NOT NULL,
-    "message" TEXT NOT NULL,
-    "page_url" TEXT,
-    "user_agent" TEXT,
-    "app_version" TEXT,
-    "created_at" TIMESTAMP(3) NOT NULL DEFAULT CURRENT_TIMESTAMP,
-
-    CONSTRAINT "contact_message_pkey" PRIMARY KEY ("id")
-);
-
--- CreateIndex
-CREATE INDEX "contact_message_created_at_idx" ON "contact_message"("created_at");
-
--- AddForeignKey
-ALTER TABLE "contact_message" ADD CONSTRAINT "contact_message_author_id_fkey" FOREIGN KEY ("author_id") REFERENCES "user_profiles"("id") ON DELETE SET NULL ON UPDATE CASCADE;

apps/api/prisma/migrations/20260908130000_contact_message_forgejo_link/migration.sql

@@ -1,8 +0,0 @@
--- Link a contact message to the Forgejo issue an admin created from it
--- (issue #81). Two nullable columns, no backfill — existing rows have no
--- linked issue.
-
--- AlterTable
-ALTER TABLE "contact_message"
-    ADD COLUMN "forgejo_issue_number" INTEGER,
-    ADD COLUMN "forgejo_issue_url" TEXT;

apps/api/prisma/migrations/20260909120000_recipe_ingredient_quantity_optional/migration.sql

@@ -1,8 +0,0 @@
--- Ingrédients d'assaisonnement « selon le goût » (issue #128, puce 1 de #3) :
--- une ligne de recette peut désormais n'avoir ni quantité ni unité. Purement
--- additif — toutes les lignes existantes gardent leurs valeurs, aucune n'est
--- réécrite.
-
--- AlterTable
-ALTER TABLE "recipe_ingredient" ALTER COLUMN "quantity" DROP NOT NULL;
-ALTER TABLE "recipe_ingredient" ALTER COLUMN "unit_id" DROP NOT NULL;

apps/api/prisma/migrations/20260909130000_drop_recipe_diet/migration.sql

@@ -1,7 +0,0 @@
--- Régimes d'une recette calculés depuis ses ingrédients (issue #131, puce 4
--- de #3) — `RecipeDiet` (tag manuel) est supprimé : `RecipeSummaryView.diets`
--- est désormais dérivé de `IngredientDiet` + de l'allergène `gluten` côté
--- lecture (voir `computeRecipeDietViews`). Aucune donnée à conserver.
-
--- DropTable
-DROP TABLE "recipe_diet";

apps/api/prisma/migrations/20260909140000_tech_step_placeholder/migration.sql

@@ -1,16 +0,0 @@
--- AlterTable: off-catalog technique "placeholder" rows (issue #130, puce 3
--- de #3) — a user names a technique the catalog is missing while correcting a
--- step. Every existing row is a real seeded catalog entry, so the flag
--- defaults to false and the four new nullable columns stay NULL for them —
--- no backfill needed. Mirrors the `ingredients` placeholder migration.
-ALTER TABLE "tech_step" ADD COLUMN "is_placeholder" BOOLEAN NOT NULL DEFAULT false;
-ALTER TABLE "tech_step" ADD COLUMN "display_name" TEXT;
-ALTER TABLE "tech_step" ADD COLUMN "created_by_id" INTEGER;
-ALTER TABLE "tech_step" ADD COLUMN "created_at" TIMESTAMP(3);
-ALTER TABLE "tech_step" ADD COLUMN "reviewed_at" TIMESTAMP(3);
-
--- CreateIndex
-CREATE INDEX "tech_step_is_placeholder_idx" ON "tech_step"("is_placeholder");
-
--- AddForeignKey
-ALTER TABLE "tech_step" ADD CONSTRAINT "tech_step_created_by_id_fkey" FOREIGN KEY ("created_by_id") REFERENCES "user_profiles"("id") ON DELETE SET NULL ON UPDATE CASCADE;

apps/api/prisma/schema.prisma

@@ -49,6 +49,7 @@ model Diet {
   key String @unique
 
   users       UserProfile[]
+  recipes     RecipeDiet[]
   ingredients IngredientDiet[]
 
   @@map("diet")
@@ -102,10 +103,6 @@ model UserProfile {
   tokenVersion Int    @default(0) @map("token_version")
   houseId      Int?   @map("house_id")
   dietId       Int?   @map("diet_id")
-  /// See `Planning.createdAt` — same admin-metrics-only timestamp, added by
-  /// the `admin_metrics` migration for the dashboard's signup curve. No
-  /// application code reads it (auth doesn't need it).
-  createdAt    DateTime @default(now()) @map("created_at")
 
   house               House?                          @relation("HouseMember", fields: [houseId], references: [id], onDelete: SetNull)
   diet                Diet?                           @relation(fields: [dietId], references: [id], onDelete: SetNull)
@@ -124,21 +121,10 @@ model UserProfile {
   /// list regardless of that real-world cardinality.
   administeredHouses  House[]                         @relation("HouseAdmin")
   preferences         UserPreference?
-  /// Guided-tour scenarios this profile has seen (completed or skipped) —
-  /// see {@link TourProgress} and issues #42 / #44.
-  tourProgress        TourProgress[]
   /// Tech-step corrections this profile has submitted (any profile that can
   /// view a recipe may correct its tech-step matches, not just its author —
   /// see `StepTechStepCorrection.correctorId`).
   techStepCorrections StepTechStepCorrection[]
-  /// Placeholder `Ingredient` rows this profile created by typing a free-text
-  /// ingredient the catalog didn't cover — see `Ingredient.isPlaceholder`.
-  createdIngredientPlaceholders Ingredient[] @relation("PlaceholderCreator")
-  /// Placeholder `TechStep` rows this profile proposed while correcting a step
-  /// — see `TechStep.isPlaceholder`.
-  createdTechStepPlaceholders   TechStep[]   @relation("TechStepPlaceholderCreator")
-  /// Contact-form messages this profile has sent — see {@link ContactMessage}.
-  contactMessages               ContactMessage[]
 
   @@map("user_profiles")
 }
@@ -206,12 +192,6 @@ model Planning {
   startDate  DateTime @map("start_date") @db.Date
   finishDate DateTime @map("finish_date") @db.Date
   houseId    Int      @map("house_id")
-  /// When this planning row was first created. Added by the `admin_metrics`
-  /// migration purely for the admin dashboard's activity curves — no
-  /// application code reads it. Rows that predate the migration all get the
-  /// migration's own timestamp (same acceptable one-off skew as the
-  /// `ingredient_unit_catalog` migration), which is fine for a trend chart.
-  createdAt  DateTime @default(now()) @map("created_at")
 
   house House          @relation(fields: [houseId], references: [id], onDelete: Cascade)
   items PlanningItem[]
@@ -225,36 +205,10 @@ model PlanningItem {
   weekDay    String @map("week_day")
   meal       String
   recipeId   Int    @map("recipe_id")
-  /// Portions actually *prepared* for this slot — always a whole multiple
-  /// of `recipe.portions` (a dish is cooked in whole batches). Derived from
-  /// `portionsRequested` + the recipe's yield via `computeBatchedPortions`
-  /// (`@batch-cooking/shared`) in `addPlanningItem`, never sent raw by the
-  /// client. On a "leftovers" item (`sourcePlanningItemId` set) it always
-  /// equals `portionsRequested`.
   portions   Int
-  /// How many portions this slot must actually feed. For a fresh item
-  /// (`sourcePlanningItemId` null), `<= portions` — the gap is this item's
-  /// leftover pool. For a "leftovers" item, always `== portions` (serving
-  /// leftovers prepares nothing new, so it can't generate more — no
-  /// leftovers-on-leftovers).
-  portionsRequested    Int  @map("portions_requested")
-  /// Non-null only on a "leftovers" item: the item whose leftover pool it
-  /// draws from. `onDelete: Cascade` — deleting the source item also
-  /// deletes everything served from its leftovers (same reasoning as the
-  /// existing `Planning` -> `PlanningItem` cascade).
-  sourcePlanningItemId Int? @map("source_planning_item_id")
-  /// Portions of *this* item's leftover pool explicitly thrown away (the
-  /// basket's "jeter" button). Always 0 on a "leftovers" item (its own
-  /// pool is null by construction).
-  discardedPortions    Int  @default(0) @map("discarded_portions")
-  /// See `Planning.createdAt` — same admin-metrics-only timestamp.
-  createdAt  DateTime @default(now()) @map("created_at")
 
   planning Planning @relation(fields: [planningId], references: [id], onDelete: Cascade)
   recipe   Recipe   @relation(fields: [recipeId], references: [id])
-  sourcePlanningItem PlanningItem?  @relation("PlanningItemLeftoverSource", fields: [sourcePlanningItemId], references: [id], onDelete: Cascade)
-  /// The "leftovers" items served from this item's own pool — inverse of `sourcePlanningItem`.
-  leftoverUses       PlanningItem[] @relation("PlanningItemLeftoverSource")
 
   @@map("planning_item")
 }
@@ -365,10 +319,6 @@ model Recipe {
   /// the author had no household yet.
   authorHouseId Int?             @map("author_house_id")
   visibility    RecipeVisibility @default(PERSONAL)
-  /// See `Planning.createdAt` — same admin-metrics-only timestamp, added by
-  /// the `admin_metrics` migration for the dashboard's "recipes created"
-  /// curve. No application code reads it.
-  createdAt     DateTime         @default(now()) @map("created_at")
 
   author        UserProfile        @relation(fields: [authorId], references: [id])
   authorHouse   House?             @relation(fields: [authorHouseId], references: [id], onDelete: SetNull)
@@ -377,6 +327,7 @@ model Recipe {
   steps         Step[]
   planningItems PlanningItem[]
   favoritedBy   RecipeFavorite[]
+  diets         RecipeDiet[]
 
   @@unique([sourceId, externalId])
   @@map("recipe")
@@ -397,6 +348,21 @@ model RecipeFavorite {
   @@map("recipe_favorite")
 }
 
+/// Explicit join table for the recipe <-> diet "associated regime" tags
+/// (e.g. a recipe can be tagged both `Végétarien` and `Sans gluten`) — a
+/// manual reminder set by whoever creates/edits the recipe, not computed
+/// from its ingredients.
+model RecipeDiet {
+  recipeId Int @map("recipe_id")
+  dietId   Int @map("diet_id")
+
+  recipe Recipe @relation(fields: [recipeId], references: [id], onDelete: Cascade)
+  diet   Diet   @relation(fields: [dietId], references: [id], onDelete: Cascade)
+
+  @@id([recipeId, dietId])
+  @@map("recipe_diet")
+}
+
 /// `key` is `@unique` — not in the original spec doc, added so the seed
 /// script (reference-seed-data.ts) can `upsert` by key and stay
 /// idempotent/safe to re-run, same reason as `Diet.key`/`Category.key`. A
@@ -548,38 +514,6 @@ model Ingredient {
   /// ingredient↔recipe linking in the database, the UI only pre-fills the
   /// catalog's own search with this ingredient's name).
   reproducible Boolean               @default(false)
-  /// `true` = a "placeholder" row: a free-text ingredient a user typed on a
-  /// recipe line because the seeded catalog had nothing matching (see
-  /// specs/batch-cooking-modele.md's "ingrédients hors-catalogue"). Such a
-  /// row has `displayName` non-null, a generated `key` (`placeholder:<uuid>`,
-  /// never an i18n label), and the default metadata (`JAR`/`dryGoods`/`other`,
-  /// no allergen/diet links). It is referenced by `RecipeIngredient` like any
-  /// other `Ingredient`, but `GET /reference/ingredients` and
-  /// `ingredient-matcher.ts`'s `loadIngredientCatalog` both exclude it — it is
-  /// never a browsable/matchable target, only a per-line stand-in a
-  /// maintainer later promotes into a real catalog entry by hand. The
-  /// `/admin/catalog/placeholders` view groups these by normalized name so
-  /// the maintainer sees which ingredients the catalog is missing.
-  isPlaceholder Boolean              @default(false) @map("is_placeholder")
-  /// Display name of a placeholder ingredient — the exact text the user
-  /// typed. `null` for a real catalog row (whose label lives in i18n under
-  /// `catalog.ingredients.<key>`). Invariant "non-null iff `isPlaceholder`"
-  /// is enforced service-side, not by the schema (same posture as other
-  /// cross-field invariants here).
-  displayName   String?              @map("display_name")
-  /// Profile that first created this placeholder — context for the admin
-  /// catalog-gap review. `onDelete: SetNull` so deleting an account never
-  /// blocks on, or cascades into, the recipes that still use its placeholder.
-  /// `null` for a real catalog row.
-  createdById   Int?                 @map("created_by_id")
-  /// When this placeholder was created. `null` for a real catalog row (the
-  /// seed carries no timestamp).
-  createdAt     DateTime?            @map("created_at")
-  /// Stamped when an admin has triaged this catalog gap
-  /// (`PATCH /admin/catalog/placeholders/mark-reviewed`) — the group then
-  /// drops out of the default "à traiter" list. `null` while pending / for a
-  /// real catalog row.
-  reviewedAt    DateTime?            @map("reviewed_at")
 
   recipes    RecipeIngredient[]
   allergies  IngredientAllergy[]
@@ -587,13 +521,7 @@ model Ingredient {
   dislikedBy UserProfileDislikedIngredient[]
   /// Diet regimes this ingredient is compatible with — see {@link IngredientDiet}.
   diets      IngredientDiet[]
-  /// Mentions of this ingredient detected in a step's free text alongside a
-  /// technique — see `StepTechStepIngredient`.
-  stepTechSteps StepTechStepIngredient[]
-  /// The profile that created this row when it is a placeholder — see `createdById`.
-  createdBy     UserProfile?          @relation("PlaceholderCreator", fields: [createdById], references: [id], onDelete: SetNull)
 
-  @@index([isPlaceholder])
   @@map("ingredients")
 }
 
@@ -669,12 +597,6 @@ model Unit {
   toBaseFactor Decimal  @default(1) @map("to_base_factor") @db.Decimal(12, 4)
 
   recipeIngredients RecipeIngredient[]
-  /// Ingredient mentions detected alongside a technique in a step's free
-  /// text (e.g. "50g" resolved against this `Unit`) — see
-  /// `StepTechStepIngredient`. Distinct from `recipeIngredients` above
-  /// (the recipe's structured ingredient list): a step can mention a
-  /// quantity+unit that was never itself an ingredient list line.
-  stepTechStepIngredients StepTechStepIngredient[]
 
   @@map("unit")
 }
@@ -686,17 +608,12 @@ model Unit {
 model RecipeIngredient {
   recipeId     Int     @map("recipe_id")
   ingredientId Int     @map("ingredient_id")
-  /// `null` (with `unitId` also `null`) = a "selon le goût" seasoning line —
-  /// salt, pepper… added to taste, with nothing to scale by portions or to
-  /// aggregate on a shopping list. The "both null or neither" invariant is
-  /// enforced service-side (and by `recipeIngredientInputSchema`), not by
-  /// the schema — same posture as this file's other cross-field invariants.
-  quantity     Decimal? @db.Decimal(10, 2)
-  unitId       Int?     @map("unit_id")
+  quantity     Decimal @db.Decimal(10, 2)
+  unitId       Int     @map("unit_id")
 
   recipe     Recipe     @relation(fields: [recipeId], references: [id], onDelete: Cascade)
   ingredient Ingredient @relation(fields: [ingredientId], references: [id], onDelete: Cascade)
-  unit       Unit?      @relation(fields: [unitId], references: [id])
+  unit       Unit       @relation(fields: [unitId], references: [id])
 
   @@id([recipeId, ingredientId])
   @@map("recipe_ingredient")
@@ -710,44 +627,17 @@ model RecipeIngredient {
 /// Matching a step's free text against these (`tech-step-matcher.ts`'s
 /// `TechStepClassifierService`) used to go through a DB-backed
 /// `TechStepMapping` table of per-locale regex expressions — replaced with
-/// a spaCy-based model (`services/tech-step-intent-service`) trained from
-/// in-code data (`tech-step-training-data.ts`) once regexes turned out
-/// unable to generalize past their own literal vocabulary. Nothing
-/// queries/edits that matching data at runtime anymore (it only ever feeds
-/// that service's one-time training pass), so it no longer needs a table
-/// of its own — this row now only exists to be a stable id/key other
-/// tables (`StepTechStep`) reference.
+/// a node-nlp model trained from in-code data
+/// (`tech-step-training-data.ts`) once regexes turned out unable to
+/// generalize past their own literal vocabulary. Nothing queries/edits
+/// that matching data at runtime anymore (it only ever feeds the
+/// classifier's one-time training pass), so it no longer needs a table of
+/// its own — this row now only exists to be a stable id/key other tables
+/// (`StepTechStep`) reference.
 model TechStep {
   id  Int    @id @default(autoincrement())
   key String @unique
 
-  /// `true` = a "placeholder" technique: a free-text technique a user typed
-  /// while correcting a step, because nothing in the seeded catalog matched
-  /// (issue #131 for the ingredient precedent this mirrors — see
-  /// `Ingredient.isPlaceholder`). Such a row has `displayName` non-null, a
-  /// generated `key` (`placeholder:<uuid>`, never an i18n label), no
-  /// training data of its own, and is excluded from
-  /// `GET /reference/tech-steps`. It is still referenced by `StepTechStep`
-  /// like any other technique (the correction that created it applies
-  /// immediately), but a maintainer reviews it at
-  /// `/admin/catalogue` (Techniques tab) and promotes it into the real
-  /// catalog by hand (`reference-seed-data.ts` + `tech-step-training-data.ts`).
-  isPlaceholder Boolean   @default(false) @map("is_placeholder")
-  /// The exact text the user typed — `null` for a real catalog row (whose
-  /// label lives in i18n under `catalog.techSteps.<key>`). Non-null iff
-  /// `isPlaceholder`, enforced service-side.
-  displayName   String?   @map("display_name")
-  /// Profile that first proposed this technique — context for the admin
-  /// review. `onDelete: SetNull` so deleting an account never blocks on the
-  /// recipes still using its placeholder. `null` for a real catalog row.
-  createdById   Int?      @map("created_by_id")
-  /// When this placeholder was proposed. `null` for a real catalog row.
-  createdAt     DateTime? @map("created_at")
-  /// Stamped once a maintainer has triaged this proposal
-  /// (`PATCH /admin/api/catalog/tech-step-placeholders/mark-reviewed`).
-  /// `null` while pending / for a real catalog row.
-  reviewedAt    DateTime? @map("reviewed_at")
-
   steps                  StepTechStep[]
   /// Corrections where this technique was the *previous* (possibly wrong)
   /// match — see `StepTechStepCorrection.previousTechStepId`.
@@ -758,32 +648,10 @@ model TechStep {
   /// Training-corpus suggestions targeting this technique — see
   /// `TechStepTrainingSuggestion`.
   trainingSuggestions    TechStepTrainingSuggestion[]
-  /// The profile that proposed this row when it is a placeholder — see `createdById`.
-  createdBy              UserProfile?                @relation("TechStepPlaceholderCreator", fields: [createdById], references: [id], onDelete: SetNull)
 
-  @@index([isPlaceholder])
   @@map("tech_step")
 }
 
-/// `key` is `@unique`, same bare id+key shape as `TechStep` — no
-/// categorization taxonomy like `Ingredient` needed yet, and no matching
-/// data of its own here either: unlike `TechStep` (whose matching synonyms
-/// used to live in TS and were moved into
-/// `services/tech-step-intent-service`'s `training_data.py`), this catalog
-/// was *born* owned by that service (`utensil_vocabulary.py`) since nothing
-/// pre-existing needed it — this row only exists to be a stable id/key
-/// `StepTechStepUtensil` references, and to carry a French label
-/// (`apps/web`'s `catalog.utensils.<key>`, see `reference-seed-data.ts`'s
-/// `UTENSILS`).
-model Utensil {
-  id  Int    @id @default(autoincrement())
-  key String @unique
-
-  steps StepTechStepUtensil[]
-
-  @@map("utensil")
-}
-
 /// Modeled as one-to-many (a step belongs to exactly one recipe), not the
 /// many-to-many noted in the spec doc: `order` only makes sense scoped to a
 /// single recipe, which isn't reconcilable with steps being shared across
@@ -854,105 +722,11 @@ model StepTechStep {
 
   step     Step     @relation(fields: [stepId], references: [id], onDelete: Cascade)
   techStep TechStep @relation(fields: [techStepId], references: [id], onDelete: Cascade)
-  /// Ingredients mentioned in the same clause as this technique occurrence
-  /// — see `StepTechStepIngredient`.
-  ingredients StepTechStepIngredient[]
-  /// Utensils mentioned in the same clause as this technique occurrence —
-  /// see `StepTechStepUtensil`.
-  utensils    StepTechStepUtensil[]
-  /// Temperatures mentioned in the same clause as this technique occurrence
-  /// — see `StepTechStepTemperature`.
-  temperatures StepTechStepTemperature[]
 
   @@id([stepId, order])
   @@map("step_tech_step")
 }
 
-/// An ingredient mention found in the same *clause* as one `StepTechStep`
-/// occurrence (`tech-step-matcher.ts`'s `matchTechStepSpans` — clauses are
-/// already the unit a technique is judged on, see that file's doc comment,
-/// so "same clause" is the association rule, no dependency-parsing needed).
-/// `quantity`/`unitId` are best-effort, populated only when a leading
-/// numeric expression immediately preceding the ingredient mention resolved
-/// against the `Unit` catalog (`ingredient-matcher.ts`'s
-/// `findIngredientMentions`) — both `null` when the clause names the
-/// ingredient with no quantity ("ajouter le sel"). `start`/`end` are the
-/// ingredient mention's own span in `Step.description`, same `[start, end)`
-/// convention as `StepTechStep.start`/`end`. `source` mirrors
-/// `StepTechStep.source` (`"auto"` today, room for a future user
-/// correction without a shape change).
-model StepTechStepIngredient {
-  id            Int      @id @default(autoincrement())
-  stepId        Int      @map("step_id")
-  techStepOrder Int      @map("tech_step_order")
-  ingredientId  Int      @map("ingredient_id")
-  quantity      Decimal? @db.Decimal(10, 2)
-  unitId        Int?     @map("unit_id")
-  start         Int
-  end           Int
-  source        String   @default("auto")
-
-  stepTechStep StepTechStep @relation(fields: [stepId, techStepOrder], references: [stepId, order], onDelete: Cascade)
-  ingredient   Ingredient   @relation(fields: [ingredientId], references: [id], onDelete: Cascade)
-  unit         Unit?        @relation(fields: [unitId], references: [id])
-
-  @@map("step_tech_step_ingredient")
-}
-
-/// A utensil mention found in the same clause as one `StepTechStep`
-/// occurrence — same association rule as `StepTechStepIngredient` (see its
-/// doc comment). Detected by
-/// `services/tech-step-intent-service`'s own utensil `PhraseMatcher`
-/// (`intent_service/utensil_vocabulary.py`), returned alongside technique
-/// entities in `POST /v1/process` and filtered to this clause's span by
-/// `tech-step-matcher.ts`.
-model StepTechStepUtensil {
-  id            Int    @id @default(autoincrement())
-  stepId        Int    @map("step_id")
-  techStepOrder Int    @map("tech_step_order")
-  utensilId     Int    @map("utensil_id")
-  start         Int
-  end           Int
-  source        String @default("auto")
-
-  stepTechStep StepTechStep @relation(fields: [stepId, techStepOrder], references: [stepId, order], onDelete: Cascade)
-  utensil      Utensil      @relation(fields: [utensilId], references: [id], onDelete: Cascade)
-
-  @@map("step_tech_step_utensil")
-}
-
-/// A temperature mention found in the same *clause* as one `StepTechStep`
-/// occurrence — same association rule as `StepTechStepIngredient` /
-/// `StepTechStepUtensil` (see their doc comments). Detected by
-/// `services/tech-step-intent-service`'s regex pass (`temperature_extraction.py`),
-/// not a `PhraseMatcher` — a temperature is numeric/pattern, not a word from
-/// a finite vocabulary. Carries no foreign key: the structured value *is*
-/// the data. At least one of `celsius` / `gasMark` / `qualitative` is
-/// non-null:
-///   - `celsius`     — an oven/pan temperature in °C (a °F mention is
-///                     converted + rounded upstream).
-///   - `gasMark`     — a gas-mark / thermostat number ("th. 6").
-///   - `qualitative` — "low" | "medium" | "high" ("feu doux/moyen/vif").
-/// `raw` is the exact recognized fragment, `start`/`end` its span in
-/// `Step.description` ([start, end), same as `StepTechStep.start`/`end`).
-/// `source` mirrors the others (`"auto"` only today — no correction UI).
-model StepTechStepTemperature {
-  id            Int      @id @default(autoincrement())
-  stepId        Int      @map("step_id")
-  techStepOrder Int      @map("tech_step_order")
-  start         Int
-  end           Int
-  celsius       Decimal? @db.Decimal(6, 2)
-  gasMark       Int?     @map("gas_mark")
-  qualitative   String?
-  raw           String
-  source        String   @default("auto")
-
-  stepTechStep StepTechStep @relation(fields: [stepId, techStepOrder], references: [stepId, order], onDelete: Cascade)
-
-  @@map("step_tech_step_temperature")
-}
-
 /// One user-submitted correction to a `Step`'s detected techniques —
 /// captures ADD (a missing technique the classifier didn't find),
 /// REMOVE (a wrong technique it did), or RELABEL (both) as a single shape:
@@ -1017,7 +791,7 @@ model StepTechStepCorrection {
 ///
 /// `suggestedSynonyms`/`suggestedUtterances` are native Postgres arrays
 /// (`String[]`), not a join table — unlike this schema's other list-shaped
-/// data (`RecipeIngredient`, `UserProfileAllergy`...), these strings are free text
+/// data (`RecipeDiet`, `UserProfileAllergy`...), these strings are free text
 /// proposed once for a human to read, not ids referencing another catalog
 /// table, so there's nothing for a join table to normalize against.
 model TechStepTrainingSuggestion {
@@ -1036,223 +810,3 @@ model TechStepTrainingSuggestion {
 
   @@map("tech_step_training_suggestion")
 }
-
-// -----------------------------------------------------------------------------
-// Admin application
-// A separate operations app (usage metrics, microservice monitoring, tech-step
-// correction triage) — see specs/backend-architecture.md's "admin" section.
-// -----------------------------------------------------------------------------
-
-/// An operator of the admin application (`apps/admin-web` / the `/admin/*`
-/// API surface). Deliberately its **own** table with **no relation** to
-/// `UserProfile`: admin access is a completely separate concern from being
-/// an end user of the recipe app — a person can be one, both or neither,
-/// and the two auth mechanisms (`requireAdmin` vs `requireAuth`, distinct
-/// cookies, distinct JWT secrets) never overlap. No self-service signup —
-/// the first row is created out-of-band by `src/scripts/create-admin.ts`,
-/// and (for now) there's no in-app admin-management UI.
-model AdminUser {
-  id           Int       @id @default(autoincrement())
-  email        String    @unique
-  /// argon2 hash of the password — same hashing as `UserProfile.passwordHash`
-  /// (`auth.service.ts`'s `hashOptions`, cheaper cost under NODE_ENV=test).
-  passwordHash String    @map("password_hash")
-  /// Display name shown in the admin UI's account menu.
-  name         String
-  /// Bumped to invalidate previously-issued admin JWTs — same mechanism as
-  /// `UserProfile.tokenVersion`, checked on every request by `requireAdmin`.
-  tokenVersion Int       @default(0) @map("token_version")
-  createdAt    DateTime  @default(now()) @map("created_at")
-  /// Stamped on every successful login — a cheap "is this account still in
-  /// use" signal for the operator managing admins by hand.
-  lastLoginAt  DateTime? @map("last_login_at")
-
-  @@map("admin_users")
-}
-
-/// One recorded product event, for the admin dashboard's usage metrics.
-/// Written fire-and-forget by `lib/analytics.service.ts`'s `recordEvent`
-/// from a handful of key service methods (signup, recipe import/create,
-/// planning add, cooking-session open, tech-step correction, shopping-list
-/// view) — never on the request's critical path, so a failed insert is
-/// logged and swallowed, never surfaced to the user.
-///
-/// `type` is a free `String` (`"user.signup"`, `"recipe.imported"`…), not
-/// an enum: adding a new event to instrument is a one-line call site
-/// change with **no migration**. `actorId` is a `UserProfile.id` when
-/// `actorType == "user"` but carries **no FK** — an event is an immutable
-/// historical fact that must outlive the account it describes (a deleted
-/// user's signup still counts on the curve). `context` is a small free
-/// JSON blob (`{ sourceKey, recipeId, … }`) for slicing later; nothing
-/// queries into it today.
-model AnalyticsEvent {
-  id        Int      @id @default(autoincrement())
-  type      String
-  actorType String   @map("actor_type")
-  actorId   Int?     @map("actor_id")
-  context   Json?
-  createdAt DateTime @default(now()) @map("created_at")
-
-  @@index([type, createdAt])
-  @@map("analytics_events")
-}
-
-/// Liveness/last-run record for a background worker that has no inbound
-/// HTTP surface of its own — one row per worker (`workerKey`, today only
-/// `"tech-step-llm-worker"`). The worker POSTs `/internal/tech-steps/heartbeat`
-/// (`requireInternalWorker`) on boot, on every scheduler tick, and after
-/// each job; the admin monitoring board reads this to show the worker as
-/// up / stale / down and to surface its last job result. Upserted, never
-/// accumulated — only the latest state matters.
-model WorkerHeartbeat {
-  workerKey  String    @id @map("worker_key")
-  lastSeenAt DateTime  @map("last_seen_at")
-  /// Set only by a `"job"` heartbeat — the last time the worker actually ran a job (vs. just a tick proving it's alive).
-  lastRunAt  DateTime? @map("last_run_at")
-  /// Small JSON summary of that last job (`{ job, ok, counts }`).
-  lastResult Json?     @map("last_result")
-
-  @@map("worker_heartbeats")
-}
-
-/// Idempotency ledger for one-time data backfills run from the production
-/// image's start command (`src/scripts/backfill-runtime.ts`, invoked in
-/// apps/api/Dockerfile's CMD after `prisma migrate deploy` + `seed-runtime`).
-///
-/// The CMD re-runs on every container start, but a backfill here *rewrites*
-/// existing rows (unlike `seed-runtime`, which only upserts and is safe to
-/// repeat) — e.g. `step_tech_step_metadata_20260904` recomputes every
-/// `StepTechStep` sequence against the intent service. So each backfill
-/// gates itself on a row in this table: `key` present → already done, skip;
-/// absent → run it, then insert the row. A schema migration only ever
-/// creates the table structure; it can't run TypeScript against the intent
-/// service, which is why this is a start-command step and not a migration.
-model BackfillState {
-  key         String   @id
-  completedAt DateTime @default(now()) @map("completed_at")
-
-  @@map("backfill_state")
-}
-
-/// Catalogue des cibles de surlignage valides pour un didacticiel guidé —
-/// même esprit que `TechStep`/`Unit`/`Diet` : une valeur de référence
-/// maintenue par le code, seedée (`reference-seed-data.ts`). Chaque `key`
-/// correspond à un attribut `data-tour-<key>` réellement posé quelque part
-/// dans le frontend ; un admin choisit parmi ces cibles en construisant un
-/// scénario, il ne peut pas en inventer une (poser un nouveau `data-tour-*`
-/// reste un changement de code + une ligne seedée ici). Voir issues #42/#44.
-model TourTarget {
-  key         String @id
-  /// Libellé pour aider l'admin à choisir dans le formulaire, ex.
-  /// "Bouton + d'un créneau du planning".
-  description String
-
-  steps TourScenarioStep[]
-
-  @@map("tour_target")
-}
-
-/// Un scénario de didacticiel — une séquence d'étapes surlignées, rejouable
-/// et éditable depuis l'admin (#44). `key` est une clé stable (comme
-/// `Diet.key`/`Source.key`) : `"general"` / `"techStepMetadata"` pour les
-/// deux scénarios seedés, libre pour un scénario créé par un admin.
-model TourScenario {
-  id        Int      @id @default(autoincrement())
-  key       String   @unique
-  /// Libellé admin, ex. "Tour d'orientation".
-  name      String
-  /// Désactiver sans supprimer — `GET /reference/tours` ne renvoie que les
-  /// scénarios activés.
-  enabled   Boolean  @default(true)
-  createdAt DateTime @default(now()) @map("created_at")
-  updatedAt DateTime @updatedAt @map("updated_at")
-
-  steps    TourScenarioStep[]
-  progress TourProgress[]
-
-  @@map("tour_scenario")
-}
-
-/// Une étape d'un scénario : (si `route` est défini) navigue vers cette
-/// route, puis surligne l'élément portant `data-tour-<targetKey>` avec un
-/// popover `title`/`content`. `title`/`content` sont du **texte libre**
-/// saisi par l'admin, pas des clés i18n (#44 : le chrome de l'UI vient
-/// d'i18next, le contenu administré dynamiquement est du texte, comme le
-/// nom d'une recette).
-model TourScenarioStep {
-  id         Int     @id @default(autoincrement())
-  scenarioId Int     @map("scenario_id")
-  order      Int
-  /// Route React Router à ouvrir avant cette étape ; `null` = rester sur la
-  /// route de l'étape précédente.
-  route      String?
-  targetKey  String  @map("target_key")
-  title      String
-  content    String
-
-  scenario TourScenario @relation(fields: [scenarioId], references: [id], onDelete: Cascade)
-  target   TourTarget   @relation(fields: [targetKey], references: [key])
-
-  @@unique([scenarioId, order])
-  @@map("tour_scenario_step")
-}
-
-/// Présence d'une ligne = ce profil a *vu* ce scénario. Le terminer **ou**
-/// le passer volontairement crée la ligne (pas de re-nag après un skip
-/// délibéré). Révise la version de #42 (`tourKey: String` libre) en une
-/// vraie FK vers `TourScenario` (#44).
-model TourProgress {
-  userProfileId Int      @map("user_profile_id")
-  scenarioId    Int      @map("scenario_id")
-  completedAt   DateTime @default(now()) @map("completed_at")
-
-  userProfile UserProfile  @relation(fields: [userProfileId], references: [id], onDelete: Cascade)
-  scenario    TourScenario @relation(fields: [scenarioId], references: [id], onDelete: Cascade)
-
-  @@id([userProfileId, scenarioId])
-  @@map("tour_progress")
-}
-
-// -----------------------------------------------------------------------------
-// Contact
-// In-app "report a bug / suggestion" form — user-submitted, read-only for
-// admins at /admin/messages. See issues #80 (this) and #81 (turn a message
-// into a Forgejo issue).
-// -----------------------------------------------------------------------------
-
-/// A message sent via the app's contact form (bug, suggestion, other).
-/// Written once by a signed-in user, never edited afterwards — consulted
-/// read-only from the admin app. `authorId` is nullable + `onDelete: SetNull`
-/// (same choice as `Ingredient.createdById`): a bug report keeps its value
-/// even if the account that sent it is deleted in the meantime.
-model ContactMessage {
-  id         Int      @id @default(autoincrement())
-  authorId   Int?     @map("author_id")
-  /// "bug" | "suggestion" | "other" — a plain `String` backed by the shared
-  /// `CONTACT_MESSAGE_TYPES` const (same approach as
-  /// `TechStepTrainingSuggestion.status` / `AnalyticsEvent.type`): adding a
-  /// value is one line, no Postgres enum migration.
-  type       String
-  message    String
-  /// Technical context captured automatically at submit time, for triage —
-  /// all nullable (an older client, or a direct API call, can omit them).
-  pageUrl    String?  @map("page_url")
-  userAgent  String?  @map("user_agent")
-  appVersion String?  @map("app_version")
-  createdAt  DateTime @default(now()) @map("created_at")
-
-  /// Number of the Forgejo issue an admin created from this message via
-  /// `/admin/messages` (issue #81). `null` = no ticket yet. Non-null ⇒ the
-  /// "Créer un ticket" button disappears (one message links to at most one
-  /// issue).
-  forgejoIssueNumber Int?    @map("forgejo_issue_number")
-  /// The issue's html URL (`<base>/<owner>/<repo>/issues/<n>`) — stored
-  /// as-is rather than rebuilt from `FORGEJO_*` config, so the link stays
-  /// correct even if that config changes later.
-  forgejoIssueUrl    String? @map("forgejo_issue_url")
-
-  author UserProfile? @relation(fields: [authorId], references: [id], onDelete: SetNull)
-
-  @@index([createdAt])
-  @@map("contact_message")
-}

apps/api/src/app.ts

@@ -5,19 +5,14 @@ import type { Express, Request, Response } from "express";
 import { env } from "./config/env.js";
 import { errorLogger } from "./middlewares/error-logger.js";
 import { requestLogger } from "./middlewares/request-logger.js";
-import { adminRouter } from "./modules/admin/admin.routes.js";
 import { authRouter } from "./modules/auth/auth.routes.js";
-import { contactRouter } from "./modules/contact/contact.routes.js";
-import { cookingSessionRouter } from "./modules/cooking-session/cooking-session.routes.js";
 import { houseRouter } from "./modules/house/house.routes.js";
 import { techStepWorkerRouter } from "./modules/internal/tech-step-worker.routes.js";
-import { mobileRouter } from "./modules/mobile/mobile.routes.js";
 import { planningRouter } from "./modules/planning/planning.routes.js";
 import { preferencesRouter } from "./modules/preferences/preferences.routes.js";
 import { profileRouter } from "./modules/profile/profile.routes.js";
 import { recipeRouter } from "./modules/recipe/recipe.routes.js";
 import { referenceRouter } from "./modules/reference/reference.routes.js";
-import { shoppingListRouter } from "./modules/shopping-list/shopping-list.routes.js";
 import { sourcesRouter } from "./modules/sources/sources.routes.js";
 
 /**
@@ -36,11 +31,6 @@ export function createServer(): ExpressServer {
   // pipeline (its "finish" listener still fires for a request that never
   // makes it past CORS/body-parsing, not just ones that reach a route).
   server.addMiddleware(requestLogger);
-  // Allowed origin(s) come from `CORS_ORIGIN` (see its own doc comment in
-  // config/env.ts for why the packaged Android app's origin must always be
-  // one of them). The admin surface (`/admin/*`) is served by this same API
-  // and consumed by `apps/web`'s own `/admin/*` routes — same origin as the
-  // rest of the app, so no extra CORS entry.
   server.setupCore({ corsOrigin: env.CORS_ORIGIN });
 
   server.addRoute("get", "/health", (_req: Request, res: Response) => {
@@ -48,40 +38,18 @@ export function createServer(): ExpressServer {
   });
 
   server.mountRouter("/auth", authRouter);
-  // Admin application surface — its own auth (`requireAdmin`, distinct
-  // cookie/secret), never the end-user session. Mounted at `/admin/api`,
-  // *not* bare `/admin`: apps/web's own admin pages live at `/admin/*` too
-  // (`/admin/monitoring`, `/admin/login`...), and this API is served from
-  // the same origin/process as that frontend (see `serveStaticFrontend`
-  // below). A bare `/admin` mount put `GET /admin/monitoring` (API) and the
-  // page route `/admin/monitoring` in direct conflict — Express matches by
-  // path alone, so a hard navigation/refresh on that page was answered by
-  // this router's own handler (raw JSON) instead of falling through to the
-  // SPA's `index.html`. The `/api` segment guarantees no current or future
-  // admin page path can ever collide with an admin API path again.
-  server.mountRouter("/admin/api", adminRouter);
   server.mountRouter("/house", houseRouter);
-  // In-app "signaler un bug / suggestion" form (issue #80) — session
-  // required, one POST. Admins read these rows via `/admin/api/contact`,
-  // never this router.
-  server.mountRouter("/contact", contactRouter);
   // Not user-facing — `services/tech-step-llm-worker` only, guarded by
   // `requireInternalWorker` on every route within (see that router's own
   // doc comment), never `requireAuth`. Mounted alongside the other routers
   // rather than nested under one of them since it isn't scoped to a single
   // recipe/step the way `recipeRouter`'s own correction routes are.
   server.mountRouter("/internal/tech-steps", techStepWorkerRouter);
-  // Public proxy for Forgejo's Releases API (issues #65/#66) — see
-  // mobile.service.ts's doc comment for why this can't just be called
-  // directly from the browser.
-  server.mountRouter("/mobile", mobileRouter);
   server.mountRouter("/planning", planningRouter);
   server.mountRouter("/preferences", preferencesRouter);
   server.mountRouter("/profile", profileRouter);
   server.mountRouter("/recipes", recipeRouter);
   server.mountRouter("/reference", referenceRouter);
-  server.mountRouter("/shopping-list", shoppingListRouter);
-  server.mountRouter("/cooking-session", cookingSessionRouter);
   server.mountRouter("/sources", sourcesRouter);
 
   // Serves the built frontend (production Docker image only — see

apps/api/src/config/env.ts

@@ -13,26 +13,12 @@ import { z } from "zod";
 // separate test database this now requires.
 dotenv.config({ path: process.env.NODE_ENV === "test" ? ".env.test" : ".env" });
 
-/**
- * Treats a blank env var (`FOO=`) as unset. `docker-compose.yml` passes
- * every optional var through as `${FOO:-}`, which resolves to `""` (not an
- * absent key) when the stack's `.env` leaves it empty — and a `.env` file
- * is `.dockerignore`d, so that passthrough is the container's only source
- * of these. Fields that must *fail closed* on a blank value rather than run
- * their own format check against `""` (and crash `parse()` at boot) wrap
- * their schema in this. Used for the `FORGEJO_*` trio below; `COOKIE_SECURE`
- * folds the same `"" -> undefined` step into its own `.transform`.
- */
-const blankAsUnset = (value: unknown): unknown => (value === "" ? undefined : value);
-
 /**
  * Schema for every environment variable the API reads. Parsing (below)
  * fails fast at startup if something required is missing/invalid, instead
- * of surfacing as a confusing runtime error later. Exported so the parsing
- * rules (e.g. `blankAsUnset` on the `FORGEJO_*` trio) can be unit-tested
- * without the process-wide `process.env` the singleton below parses.
+ * of surfacing as a confusing runtime error later.
  */
-export const envSchema = z.object({
+const envSchema = z.object({
   /** Runtime mode — also toggles test-only behavior (e.g. cheaper argon2 cost, see auth.service.ts). */
   NODE_ENV: z.enum(["development", "test", "production"]).default("development"),
   /** Port the HTTP server listens on. */
@@ -48,42 +34,8 @@ export const envSchema = z.object({
   JWT_EXPIRES_IN: z.string().default("7d"),
   /** Name of the httpOnly cookie carrying the session JWT. */
   AUTH_COOKIE_NAME: z.string().default("session"),
-  /**
-   * Origin(s) allowed by CORS, comma-separated — parsed below into a
-   * `string[]` for `ExpressServerCoreOptions.corsOrigin`
-   * (`app.ts`/`express-server.ts`, which passes it straight to the `cors`
-   * package) and reused as-is for the Socket.IO handshake's own CORS config
-   * (`server.ts`, which needs its own since the WS upgrade never runs
-   * through `setupCore`'s middleware).
-   *
-   * Must always include `https://localhost`: the packaged Android app's
-   * WebView is served from exactly that fixed origin (Capacitor's default
-   * for `androidScheme`/hostname — see `apps/web/capacitor.config.ts`'s own
-   * doc comment), and every request it makes to this API — `/auth/login`
-   * and `/auth/signup` included — is genuinely cross-origin, unlike
-   * apps/web's *browser* build, which is served from the very same origin
-   * as this API in production (see docker-compose.yml's `app` service) and
-   * so never needs an entry here at all. Missing this origin doesn't fail
-   * loudly: the `cors` package still answers a preflight `OPTIONS` with 204
-   * for an origin it's about to reject (it only *omits*
-   * `Access-Control-Allow-Origin`), so the request the app's WebView logs
-   * looks identical to a normal one right up until the browser silently
-   * drops the real `POST` — surfacing client-side as a generic "unexpected
-   * error" with no 401/403 anywhere to point at the actual cause. Default
-   * covers both the Vite dev server and the packaged app out of the box; a
-   * real deployment's own web origin (e.g. a production domain) never needs
-   * adding here for the reason above, but the env var still allows
-   * extending/overriding this list (comma-separated) if that ever changes.
-   */
-  CORS_ORIGIN: z
-    .string()
-    .default("http://localhost:5173,https://localhost")
-    .transform((value) =>
-      value
-        .split(",")
-        .map((origin) => origin.trim())
-        .filter((origin) => origin.length > 0),
-    ),
+  /** Origin allowed by CORS — must match wherever apps/web is served from. */
+  CORS_ORIGIN: z.string().default("http://localhost:5173"),
   /**
    * Absolute path to the built frontend (`apps/web/dist`), to serve
    * alongside the API. Optional, no default — only set inside the
@@ -119,64 +71,6 @@ export const envSchema = z.object({
    * fails closed rather than open if a real deployment forgets to set it.
    */
   INTERNAL_WORKER_SECRET: z.string().min(32).optional(),
-  /**
-   * Base URL of `services/tech-step-intent-service` (the spaCy-based
-   * microservice `TechStepClassifierService` delegates NER + intent
-   * classification to, see `lib/recipe-matching/intent-service-client.ts`).
-   * Has a default (unlike `DATABASE_URL`/secrets below) since it isn't
-   * secret and dev natively runs it on a fixed local port — Docker Compose
-   * overrides it to the compose network's service name.
-   */
-  INTENT_SERVICE_BASE_URL: z.string().url().default("http://localhost:8000"),
-  /**
-   * Shared secret sent as an `X-Intent-Service-Secret` header on every call
-   * to `services/tech-step-intent-service`. Unlike `INTERNAL_WORKER_SECRET`
-   * above, **required, no `.optional()`** — that service is a core
-   * dependency (recipe save/preview can no longer detect any technique
-   * without it), not an optional background job; an environment that
-   * forgets to set this must fail loudly at startup, not silently run with
-   * every technique detection request failing one at a time.
-   */
-  INTENT_SERVICE_SECRET: z.string().min(32, "INTENT_SERVICE_SECRET must be at least 32 characters"),
-  /**
-   * Secret used to sign/verify the **admin** session JWT (`lib/admin-jwt.ts`)
-   * — entirely separate from `JWT_SECRET`, so an end-user session token can
-   * never be replayed against `/admin/*` and vice versa. `.optional()`
-   * (unlike `JWT_SECRET`): an instance that doesn't run the admin app at
-   * all never needs it — but `requireAdmin` (`middlewares/require-admin.ts`)
-   * rejects every request outright when it's unset, so the surface fails
-   * closed, same posture as `INTERNAL_WORKER_SECRET`.
-   */
-  ADMIN_JWT_SECRET: z
-    .string()
-    .min(32, "ADMIN_JWT_SECRET must be at least 32 characters")
-    .optional(),
-  /** Name of the httpOnly cookie carrying the admin session JWT — must differ from `AUTH_COOKIE_NAME` so the two sessions coexist in one browser. */
-  ADMIN_COOKIE_NAME: z.string().default("admin_session"),
-  /** Optional seed values read by `src/scripts/create-admin.ts` when its `--email`/`--password`/`--name` flags are omitted — never used by the running server. */
-  ADMIN_INITIAL_EMAIL: z.string().optional(),
-  ADMIN_INITIAL_PASSWORD: z.string().optional(),
-  ADMIN_INITIAL_NAME: z.string().optional(),
-  /**
-   * Forgejo instance + credentials for "create an issue from a contact
-   * message" (`/admin/messages`, issue #81). All three `.optional()` and
-   * checked together by `ForgejoService.isConfigured()` — the feature
-   * **fails closed** when any is missing: the endpoint answers `503` and
-   * the admin UI hides the button (same posture as `ADMIN_JWT_SECRET` /
-   * `INTERNAL_WORKER_SECRET`). Only this one admin action reads them; the
-   * rest of the app never talks to Forgejo.
-   */
-  FORGEJO_BASE_URL: z.preprocess(blankAsUnset, z.string().url().optional()),
-  /** Forgejo personal access token with the `write:issue` (or `issue`) scope. Secret — `.env.example` shows only a `changeme`. */
-  FORGEJO_TOKEN: z.preprocess(blankAsUnset, z.string().optional()),
-  /** Target repo as `owner/repo` (e.g. `kyuno/batchCooking`) — issues are always created here, never a repo chosen at call time. */
-  FORGEJO_REPO: z.preprocess(
-    blankAsUnset,
-    z
-      .string()
-      .regex(/^[^/\s]+\/[^/\s]+$/, "FORGEJO_REPO must look like 'owner/repo'")
-      .optional(),
-  ),
 });
 
 /** Parsed, validated environment — import this instead of reading `process.env` directly anywhere else. */

apps/api/src/db/reference-seed-data.ts

@@ -62,12 +62,11 @@ export const UNITS: Array<{ uid: string; type: UnitType; toBaseFactor: number }>
 //
 // Just a flat list of stable ids here — the actual matching data (per-
 // locale synonym lists + example phrasings the classifier trains on) lives
-// in `services/tech-step-intent-service/intent_service/training_data.py`'s
-// `TECH_STEP_TRAINING_DATA`, not here: it's owned and trained entirely by
-// that separate Python service (see its own README), not read by this
-// seed script at all, so it doesn't belong alongside the rest of this
-// file's DB-seeded reference data. Every entry here must have a matching
-// entry there.
+// in `lib/recipe-matching/tech-step-training-data.ts`'s
+// `TECH_STEP_TRAINING_DATA`, not here: unlike this list, it's read by
+// `TechStepClassifierService`'s training pass, not the seed script, so it
+// doesn't belong alongside the rest of this file's DB-seeded reference
+// data. Every entry here must have a matching entry there.
 export const TECH_STEPS: string[] = [
   "cook",
   "fry",
@@ -95,208 +94,6 @@ export const TECH_STEPS: string[] = [
   "bake",
   "plate",
   "coat",
-  // Lexique de techniques ajouté par la suite — voir
-  // `services/tech-step-intent-service/intent_service/training_data.py`
-  // pour les synonymes/phrases d'exemple de chacune.
-  "baste",
-  "appertize",
-  "whiskPale",
-  "goldenBrown",
-  "braise",
-  "truss",
-  "caramelize",
-  "score",
-  "lineMold",
-  "clarify",
-  "compote",
-  "concasse",
-  "confit",
-  "julienne",
-  "brunoise",
-  "mirepoix",
-  "paysanne",
-  "blindBake",
-  "bainMarie",
-  "smother",
-  "decant",
-  "dilute",
-  "punchDown",
-  "disgorge",
-  "loosen",
-  "shellEgg",
-  "scald",
-  "pod",
-  "emulsify",
-  "hollowOut",
-  "shock",
-  "setGel",
-  "glaze",
-  "thicken",
-  "filet",
-  "proof",
-  "peelBlanch",
-  "whipUp",
-  "moisten",
-  "pasteurize",
-  "poach",
-  "reduce",
-  "rubIn",
-  "dustWithFlour",
-  "sweat",
-  "sift",
-  "toast",
-  "zest",
-];
-
-// Same authoring convention as `TECH_STEPS` right above (stable English
-// camelCase uid, French label in `apps/web`'s `locales/fr/translation.json`
-// under `catalog.utensils.<key>`) — but unlike `TECH_STEPS`, the matching
-// data (per-locale synonym lists a `PhraseMatcher` matches against) lives
-// in `services/tech-step-intent-service/intent_service/utensil_vocabulary.py`'s
-// `UTENSIL_VOCABULARY`, not `training_data.py`: no textcat/training
-// involved, a utensil mention doesn't need to be classified, only matched.
-// Every entry here must have a matching entry there. See
-// `StepTechStepUtensil` in schema.prisma for how a mention gets attached to
-// a detected technique.
-export const UTENSILS: string[] = [
-  "pan",
-  "saucepan",
-  "pot",
-  "knife",
-  "whisk",
-  "bowl",
-  "bakingSheet",
-  "mold",
-  "colander",
-  "cuttingBoard",
-  "oven",
-  "blender",
-  "mixer",
-  "spatula",
-  "ladle",
-  "grater",
-  "rollingPin",
-  "lid",
-  "tongs",
-  "peeler",
-  "sieve",
-  "foodProcessor",
-  "steamerBasket",
-  "skewer",
-  "pastryBrush",
-  "ramekin",
-  "dish",
-  "wok",
-  "thermometer",
-  "mandoline",
-];
-
-// Guided-tour highlight targets (issues #42/#44). Each `key` is the suffix
-// of a `data-tour-<key>` attribute the frontend puts on the element the
-// tour points at; `description` is the hint an admin sees when picking a
-// target in the scenario editor. Reference data maintained here, like
-// `TECH_STEPS`/`UTENSILS` — adding a real new target needs a frontend
-// `data-tour-*` *and* a line here.
-export const TOUR_TARGETS: Array<{ key: string; description: string }> = [
-  { key: "nav-planning", description: "Lien « Planning » de la barre latérale" },
-  { key: "nav-recipes", description: "Lien « Recettes » de la barre latérale" },
-  { key: "nav-shopping-list", description: "Lien « Liste de courses » de la barre latérale" },
-  { key: "planning-grid", description: "La grille du planning de la semaine" },
-  { key: "planning-add-recipe", description: "Bouton « + » d'un créneau du planning" },
-  { key: "planning-cook-button", description: "Bouton « Cuisiner » de l'en-tête du planning" },
-  { key: "shopping-list-summary", description: "La liste de courses générée pour la semaine" },
-  {
-    key: "techstep-description",
-    description: "Le texte d'une étape de recette, avec les techniques surlignées",
-  },
-  {
-    key: "techstep-technique-picker",
-    description: "Le sélecteur de technique du popover de correction",
-  },
-];
-
-// The two tours filed in issue #42, as the DB-backed scenarios #44 defines.
-// Only *created* if absent (an admin owns name/enabled/steps afterwards —
-// see `seedTourScenarios`); `content`/`title` are plain French text, not
-// i18n keys (#44). The second tour is deliberately short for now — issue
-// #36 (correction popover closes mid-selection) is still open, so v1 only
-// covers the gestures that already work (select text, pick a technique).
-export const TOUR_SCENARIOS: Array<{
-  key: string;
-  name: string;
-  steps: Array<{ route: string | null; targetKey: string; title: string; content: string }>;
-}> = [
-  {
-    key: "general",
-    name: "Tour d'orientation",
-    steps: [
-      {
-        route: "/",
-        targetKey: "nav-planning",
-        title: "Votre semaine, ici",
-        content: "Le planning est votre point de départ : ce que vous mangez, jour par jour.",
-      },
-      {
-        route: null,
-        targetKey: "nav-recipes",
-        title: "Vos recettes",
-        content:
-          "Retrouvez vos recettes, importez-en depuis d'autres sites, et filtrez selon vos préférences.",
-      },
-      {
-        route: null,
-        targetKey: "nav-shopping-list",
-        title: "La liste de courses",
-        content:
-          "Générée automatiquement à partir de tout ce que vous avez planifié pour la semaine.",
-      },
-      {
-        route: null,
-        targetKey: "planning-grid",
-        title: "Sept jours, cinq repas",
-        content: "Chaque case est un créneau. Ajoutez-y des recettes, ajustez les portions.",
-      },
-      {
-        route: null,
-        targetKey: "planning-add-recipe",
-        title: "Ajouter une recette",
-        content: "Ce bouton ouvre le sélecteur de recettes pour remplir un créneau.",
-      },
-      {
-        route: null,
-        targetKey: "planning-cook-button",
-        title: "Passer en cuisine",
-        content:
-          "Une fois la semaine planifiée, ce bouton réorganise tout en une séance de cuisine optimisée.",
-      },
-      {
-        route: "/liste-de-courses",
-        targetKey: "shopping-list-summary",
-        title: "Tout ce qu'il vous faut",
-        content: "Les ingrédients de toutes vos recettes de la semaine, regroupés et additionnés.",
-      },
-    ],
-  },
-  {
-    key: "techStepMetadata",
-    name: "Corriger les techniques d'une recette",
-    steps: [
-      {
-        route: null,
-        targetKey: "techstep-description",
-        title: "Les techniques repérées",
-        content:
-          "Les mots surlignés sont des techniques de cuisson détectées automatiquement. Sélectionnez un passage pour le corriger.",
-      },
-      {
-        route: null,
-        targetKey: "techstep-technique-picker",
-        title: "Choisir la bonne technique",
-        content:
-          "Indiquez la technique correcte pour le passage sélectionné — la correction est immédiate.",
-      },
-    ],
-  },
 ];
 
 // The 14 allergens EU Regulation 1169/2011 (Annex II) requires food
@@ -1402,12 +1199,6 @@ export async function seedReferenceData(prisma: PrismaClient): Promise<void> {
     await prisma.techStep.upsert({ where: { key }, update: {}, create: { key } });
   }
 
-  // Utensil: same idempotent bare id/key upsert as TechStep right above —
-  // no matching data alongside it either (see `UTENSILS`' own comment).
-  for (const key of UTENSILS) {
-    await prisma.utensil.upsert({ where: { key }, update: {}, create: { key } });
-  }
-
   // `Allergy` itself carries no `key` — it's the selectable instance of a
   // keyed `Category` (see schema.prisma) — so seeding an allergen means one
   // Category (upserted by key) plus exactly one Allergy row under it,
@@ -1524,47 +1315,4 @@ export async function seedReferenceData(prisma: PrismaClient): Promise<void> {
   if (dietLinks.length > 0) {
     await prisma.ingredientDiet.createMany({ data: dietLinks, skipDuplicates: true });
   }
-
-  await seedTourScenarios(prisma);
-}
-
-/**
- * Seeds the guided-tour reference data (issues #42/#44):
- *
- * - `TourTarget` rows — upserted by key with `update: { description }`, same
- *   as `Unit` above: a reseed must correct an edited hint, not just skip.
- * - `TourScenario` + its steps — **create-if-absent only**. Once a scenario
- *   exists, an admin owns its `name`/`enabled`/steps (that's the whole
- *   point of #44's CRUD), so a later deploy's reseed must never clobber
- *   those. In the test suite every `resetDatabase()` truncates first, so
- *   the defaults are always recreated fresh there.
- */
-async function seedTourScenarios(prisma: PrismaClient): Promise<void> {
-  for (const { key, description } of TOUR_TARGETS) {
-    await prisma.tourTarget.upsert({
-      where: { key },
-      update: { description },
-      create: { key, description },
-    });
-  }
-
-  for (const { key, name, steps } of TOUR_SCENARIOS) {
-    const existing = await prisma.tourScenario.findUnique({ where: { key } });
-    if (existing) continue;
-    await prisma.tourScenario.create({
-      data: {
-        key,
-        name,
-        steps: {
-          create: steps.map((step, index) => ({
-            order: index,
-            route: step.route,
-            targetKey: step.targetKey,
-            title: step.title,
-            content: step.content,
-          })),
-        },
-      },
-    });
-  }
 }

apps/api/src/lib/admin-jwt.ts

@@ -1,59 +0,0 @@
-import jwt from "jsonwebtoken";
-import { env } from "../config/env.js";
-
-/**
- * Decoded contents of an **admin** session JWT, once verified. Deliberately
- * a separate token type from `lib/jwt.ts`'s `AuthTokenPayload`: the admin
- * app authenticates against its own `AdminUser` table with its own secret
- * (`ADMIN_JWT_SECRET`), so an end-user session token and an admin session
- * token are never interchangeable.
- */
-export interface AdminTokenPayload {
-  /** `AdminUser.id` this token authenticates. */
-  adminUserId: number;
-  /** Snapshot of `AdminUser.tokenVersion` at sign time — re-checked against the DB on every request (see `requireAdmin`) to allow server-side invalidation. */
-  tokenVersion: number;
-}
-
-/**
- * The admin JWT secret, or a thrown error if the instance never configured
- * one. A misconfigured admin deployment surfaces as a loud 500 on login
- * rather than a silently-unsigned token; a deployment that doesn't run the
- * admin app at all never reaches here (nothing calls sign/verify), and
- * `requireAdmin` independently fails closed on the same unset value.
- */
-function adminSecret(): string {
-  if (env.ADMIN_JWT_SECRET === undefined) {
-    throw new Error("ADMIN_JWT_SECRET is not configured — cannot issue or verify admin sessions");
-  }
-  return env.ADMIN_JWT_SECRET;
-}
-
-/** Signs a new admin session JWT, expiring per `JWT_EXPIRES_IN` (shared with the end-user token — same "how long a session lasts" policy). */
-export function signAdminToken(payload: AdminTokenPayload): string {
-  return jwt.sign(
-    { sub: String(payload.adminUserId), tokenVersion: payload.tokenVersion },
-    adminSecret(),
-    { expiresIn: env.JWT_EXPIRES_IN as jwt.SignOptions["expiresIn"] },
-  );
-}
-
-/**
- * Verifies an admin session JWT's signature/expiry and decodes it back
- * into an {@link AdminTokenPayload}.
- *
- * @throws {Error} if the token is invalid/expired (from `jwt.verify`) or
- *   structurally malformed (missing/wrong-typed claims).
- */
-export function verifyAdminToken(token: string): AdminTokenPayload {
-  const decoded = jwt.verify(token, adminSecret());
-  const adminUserId = typeof decoded === "object" ? Number(decoded.sub) : Number.NaN;
-  if (
-    typeof decoded !== "object" ||
-    Number.isNaN(adminUserId) ||
-    typeof decoded.tokenVersion !== "number"
-  ) {
-    throw new Error("Malformed admin token payload");
-  }
-  return { adminUserId, tokenVersion: decoded.tokenVersion };
-}

apps/api/src/lib/analytics.service.ts

@@ -1,65 +0,0 @@
-import type { Prisma } from "@prisma/client";
-import { prisma } from "../db/prisma.js";
-import { logger } from "./logger.service.js";
-
-/** Who caused an {@link AnalyticsEvent}. `"user"` pairs with an `actorId` (`UserProfile.id`); `"system"` is a background job; `"anon"` is an unauthenticated request. */
-export type AnalyticsActorType = "user" | "system" | "anon";
-
-/** Optional context for {@link AnalyticsService.recordEvent}. */
-export interface RecordEventOptions {
-  /** `UserProfile.id` — set together with `actorType: "user"` (the default when this is present). */
-  actorId?: number;
-  /** Overrides the inferred actor type (`"user"` when `actorId` is set, else `"anon"`). */
-  actorType?: AnalyticsActorType;
-  /** Small free-form blob for later slicing (`{ sourceKey, recipeId, … }`) — nothing queries into it today. */
-  context?: Prisma.InputJsonValue;
-}
-
-/**
- * Records product usage events for the admin dashboard's metrics (see the
- * `AnalyticsEvent` model doc comment). A class rather than a bare function
- * — same convention as `LoggerService`/`ErrorHandlerService`: `public`
- * `recordEvent` is the API, `_insert` is the internal it fans out to.
- *
- * **Fire-and-forget by contract**: `recordEvent` returns `void`, not a
- * promise. The insert runs detached, and a failure is logged at `warn` and
- * swallowed — analytics must never add latency to, or fail, the request
- * that triggered it. Call sites therefore never `await` it.
- */
-export class AnalyticsService {
-  public recordEvent(type: string, options: RecordEventOptions = {}): void {
-    const actorType: AnalyticsActorType =
-      options.actorType ?? (options.actorId !== undefined ? "user" : "anon");
-
-    void this._insert(type, actorType, options).catch((err: unknown) => {
-      logger.warn("Analytics event insert failed", {
-        eventType: type,
-        error: err instanceof Error ? err.message : String(err),
-      });
-    });
-  }
-
-  private async _insert(
-    type: string,
-    actorType: AnalyticsActorType,
-    options: RecordEventOptions,
-  ): Promise<void> {
-    try {
-      await prisma.analyticsEvent.create({
-        data: {
-          type,
-          actorType,
-          actorId: options.actorId ?? null,
-          context: options.context,
-        },
-      });
-    } catch (err) {
-      // Rethrown so `recordEvent`'s `.catch` above logs it — this layer
-      // just isn't allowed a bare `await` per the repo's convention.
-      throw err;
-    }
-  }
-}
-
-/** Single shared instance — stateless, same reasoning as `logger`. */
-export const analytics = new AnalyticsService();

apps/api/src/lib/forgejo/forgejo.service.ts

@@ -1,102 +0,0 @@
-import { HttpError } from "@batch-cooking/error-tools";
-import { ErrorCode } from "@batch-cooking/shared";
-import { env } from "../../config/env.js";
-import { logger } from "../logger.service.js";
-
-/** The slice of Forgejo's `POST .../issues` response this integration reads. */
-interface ForgejoIssueResponse {
-  number: number;
-  html_url: string;
-}
-
-/**
- * The one place `apps/api` talks to Forgejo — creating an issue from a
- * contact message (`/admin/messages`, issue #81). A class + singleton
- * (`forgejo` below), same convention as `logger` / `analytics`.
- *
- * **Fail-closed**: every method is a no-op / typed error unless all three
- * `FORGEJO_*` env vars are set (see `config/env.ts`). Callers check
- * {@link isConfigured} first and answer `503` themselves; {@link createIssue}
- * re-checks as a backstop.
- */
-export class ForgejoService {
-  /** True once `FORGEJO_BASE_URL`, `FORGEJO_TOKEN` and `FORGEJO_REPO` are all set. */
-  public isConfigured(): boolean {
-    return (
-      env.FORGEJO_BASE_URL !== undefined &&
-      env.FORGEJO_TOKEN !== undefined &&
-      env.FORGEJO_REPO !== undefined
-    );
-  }
-
-  /**
-   * Creates an issue in `FORGEJO_REPO` with the given title/body (no labels
-   * — a deliberate #81 decision, the admin adds them in Forgejo). Returns
-   * the new issue's number and html URL.
-   *
-   * @throws {HttpError} `503 FORGEJO_NOT_CONFIGURED` if the env isn't set,
-   *   `502 FORGEJO_REQUEST_FAILED` on a network error or any non-2xx / non-JSON
-   *   response — the caller leaves the database untouched in that case.
-   */
-  public async createIssue(input: {
-    title: string;
-    body: string;
-  }): Promise<{ number: number; htmlUrl: string }> {
-    if (!this.isConfigured()) {
-      throw new HttpError(
-        503,
-        ErrorCode.FORGEJO_NOT_CONFIGURED,
-        "Forgejo integration is not configured",
-      );
-    }
-    const url = `${env.FORGEJO_BASE_URL}/api/v1/repos/${env.FORGEJO_REPO}/issues`;
-
-    let response: Response;
-    try {
-      response = await fetch(url, {
-        method: "POST",
-        headers: {
-          "Content-Type": "application/json",
-          // Forgejo/Gitea's PAT scheme — `token <pat>`, not `Bearer`.
-          Authorization: `token ${env.FORGEJO_TOKEN}`,
-        },
-        body: JSON.stringify({ title: input.title, body: input.body }),
-      });
-    } catch (err) {
-      logger.warn("Forgejo issue creation failed (network)", {
-        error: err instanceof Error ? err.message : String(err),
-      });
-      throw new HttpError(502, ErrorCode.FORGEJO_REQUEST_FAILED, "Forgejo request failed");
-    }
-
-    if (!response.ok) {
-      const detail = await response.text().catch(() => "");
-      logger.warn("Forgejo issue creation failed", {
-        status: response.status,
-        detail: detail.slice(0, 500),
-      });
-      throw new HttpError(
-        502,
-        ErrorCode.FORGEJO_REQUEST_FAILED,
-        `Forgejo issues API responded ${response.status}`,
-      );
-    }
-
-    try {
-      const data = (await response.json()) as ForgejoIssueResponse;
-      return { number: data.number, htmlUrl: data.html_url };
-    } catch (err) {
-      logger.warn("Forgejo issue creation failed (bad response)", {
-        error: err instanceof Error ? err.message : String(err),
-      });
-      throw new HttpError(
-        502,
-        ErrorCode.FORGEJO_REQUEST_FAILED,
-        "Forgejo response was not valid JSON",
-      );
-    }
-  }
-}
-
-/** Single shared instance — stateless, same reasoning as `logger` / `analytics`. */
-export const forgejo = new ForgejoService();

apps/api/src/lib/monitoring-broadcast.service.ts

@@ -1,95 +0,0 @@
-import type { MonitoringView } from "@batch-cooking/shared";
-import type { Server as SocketIoServer } from "socket.io";
-import { requireAdminSocket } from "../middlewares/require-admin-socket.js";
-import { getMonitoring } from "../modules/admin/admin-monitoring.service.js";
-import { logger } from "./logger.service.js";
-
-/** How often the server re-probes every dependency, in ms — see `MonitoringBroadcastService`. */
-const PROBE_INTERVAL_MS = 60_000;
-
-/** Every authenticated admin socket joins this one room — a single probe loop serves every open tab, instead of each polling independently. */
-const MONITORING_ROOM = "monitoring";
-
-/** Event name every `monitoring:update` push carries — the sole message this service ever emits. */
-const UPDATE_EVENT = "monitoring:update";
-
-/**
- * Pushes the admin monitoring status board to every connected admin over
- * WebSocket, replacing the old `GET /admin/api/monitoring` polling
- * endpoint entirely (removed — see `admin.routes.ts`'s doc comment): one
- * server-side probe loop, shared by every viewer, instead of each browser
- * tab re-probing Postgres/the API/the intent-service/the LLM worker on its
- * own timer.
- *
- * Owns the *whole* `socket.io` server passed to it (`io.use`, top-level
- * `"connection"` handler) — fine while this is the server's only
- * real-time feature; a second one added later should likely get its own
- * namespace rather than share this room's connection handler.
- */
-export class MonitoringBroadcastService {
-  private readonly _io: SocketIoServer;
-  /**
-   * Most recent probe result — replayed to a newly-joined admin
-   * immediately (see the `"connection"` handler below), so a freshly
-   * opened tab isn't left blank for up to a minute waiting for the next
-   * scheduled tick. `null` until the very first probe (kicked off by
-   * {@link start}) completes.
-   */
-  private _lastSnapshot: MonitoringView | null = null;
-  /** Handle for the running probe loop, or `null` before {@link start}/after {@link stop}. */
-  private _intervalHandle: NodeJS.Timeout | null = null;
-
-  public constructor(io: SocketIoServer) {
-    this._io = io;
-    this._io.use(requireAdminSocket);
-    this._io.on("connection", (socket) => {
-      void socket.join(MONITORING_ROOM);
-      if (this._lastSnapshot) {
-        socket.emit(UPDATE_EVENT, this._lastSnapshot);
-      }
-    });
-  }
-
-  /**
-   * Starts the probe loop: one immediate probe (so the very first admin
-   * to connect after a server restart doesn't wait a full minute), then
-   * every {@link PROBE_INTERVAL_MS}. Call once, at server boot
-   * (`server.ts`) — meant to run for the lifetime of the process, same
-   * posture as the tech-step worker's own cron (`server.ts` never calls
-   * {@link stop} today; the process exiting takes the interval with it).
-   */
-  public start(): void {
-    void this._tick();
-    this._intervalHandle = setInterval(() => void this._tick(), PROBE_INTERVAL_MS);
-  }
-
-  /**
-   * Stops the probe loop. Nothing in production calls this today — it
-   * exists so a graceful-shutdown hook could use it later, and so tests
-   * can tear an instance down cleanly instead of leaking a live
-   * `setInterval` past their own lifetime (which would otherwise hold the
-   * whole Mocha process open).
-   */
-  public stop(): void {
-    if (this._intervalHandle) {
-      clearInterval(this._intervalHandle);
-      this._intervalHandle = null;
-    }
-  }
-
-  /** Probes every dependency, caches the result, and broadcasts it to {@link MONITORING_ROOM}. */
-  private async _tick(): Promise<void> {
-    try {
-      this._lastSnapshot = await getMonitoring();
-      this._io.to(MONITORING_ROOM).emit(UPDATE_EVENT, this._lastSnapshot);
-    } catch (err) {
-      // getMonitoring() itself never rejects — every individual probe is
-      // already bounded/caught (see its own doc comment) — so this is
-      // purely defensive, per the repo's await-in-try/catch rule; not
-      // expected to actually fire.
-      logger.error("Monitoring probe tick failed unexpectedly", {
-        error: err instanceof Error ? err.message : String(err),
-      });
-    }
-  }
-}

apps/api/src/lib/recipe-matching/cooking-optimizer.ts

@@ -1,734 +0,0 @@
-import type {
-  CookingBackgroundTaskView,
-  CookingPhaseKind,
-  CookingPhaseNoteView,
-  CookingPhaseView,
-  CookingSessionRecipeRef,
-  CookingTaskIngredientView,
-  CookingTaskView,
-  CookingTemperatureView,
-  TechStepView,
-  UtensilView,
-} from "@batch-cooking/shared";
-
-/**
- * The pure core of the "Calcul batch-cooking" module (`specs/batch-cooking-architecture.md`):
- * takes the week's planned recipes — already resolved to reference views by
- * `cooking-session.service.ts` — and reorganizes their steps into an ordered
- * sequence of {@link CookingPhaseView}s that pools shared preparation and
- * interleaves the recipes so passive cooks (simmer, braise, bake…) run in
- * the background while the cook does active work from another recipe.
- *
- * Pure and synchronous, no database access — same `matchXxx()` pure /
- * `loadXxx()` DB-backed split as `ingredient-matcher.ts` /
- * `tech-step-matcher.ts` / `shopping-list.service.ts`'s
- * `aggregateShoppingList`, so the whole optimization is unit-testable
- * without a Postgres round-trip.
- *
- * Two families of work are *merged* across recipes:
- * - **Preparation** — a `chop`/`peel`/… technique applied to the same
- *   ingredient by two or more recipes, in a step that does nothing but
- *   prep, collapses into one {@link CookingTaskView} of `kind:
- *   "merged-prep"`.
- * - **Setup** — the same `preheat`/`boil`/`bainMarie` action shared across
- *   recipes collapses into one `kind: "merged-setup"` task, but *only when
- *   the action metadata is compatible*: two recipes that both preheat the
- *   oven merge only when they preheat it to the **same temperature**.
- *   Two preheats at different temperatures stay separate (you cannot heat
- *   one oven to two temperatures at once), are ordered coolest-first, and
- *   the mise-en-place phase carries a {@link CookingPhaseNoteView} telling
- *   the cook to run them in sequence.
- *
- * Cooking steps themselves are still never merged (no shared-oven bake
- * batching yet); they're only *reordered* for parallelism.
- */
-
-/**
- * Technique keys (`TechStep.key`, see `reference-seed-data.ts`'s
- * `TECH_STEPS`) that are pure knife/prep work on an ingredient — the only
- * techniques v1 pools across recipes. A *step* counts as prep only when
- * **every** technique it mentions is in here (see {@link isPurePrepStep}):
- * "émincer les oignons" merges, "faire revenir les oignons émincés" does
- * not (its `panFry` keeps it a cooking step).
- */
-const PREP_TECHNIQUES: ReadonlySet<string> = new Set([
-  "chop",
-  "peel",
-  "mince",
-  "julienne",
-  "brunoise",
-  "concasse",
-  "paysanne",
-  "mirepoix",
-  "zest",
-  "score",
-  "pod",
-  "shellEgg",
-  "hollowOut",
-  "filet",
-  "disgorge",
-  "sift",
-  "dustWithFlour",
-  "peelBlanch",
-]);
-
-/**
- * How much of the cook's attention a technique needs once it's under way —
- * the axis that makes parallelism possible.
- *
- * - `"SETUP"` — a short active trigger, then it looks after itself: preheat
- *   the oven, bring a pot of water to the boil. Pooled into the first
- *   ("mise en place") phase so it's running before it's needed, and merged
- *   across recipes when compatible (see {@link extractMergedSetup}).
- * - `"PASSIVE"` — unattended once started (simmer, braise, bake, marinate,
- *   rest…). Scheduled, then floated into every following phase's
- *   `background` until the step that consumes it comes up.
- * - anything not listed here, or a step with no detected technique at all,
- *   is treated as `"ACTIVE"` — hands-on, occupies the cook.
- */
-const SETUP_TECHNIQUES: ReadonlySet<string> = new Set(["preheat", "boil", "bainMarie"]);
-
-/** See {@link SETUP_TECHNIQUES}. */
-const PASSIVE_TECHNIQUES: ReadonlySet<string> = new Set([
-  "simmer",
-  "bake",
-  "roast",
-  "braise",
-  "marinate",
-  "rest",
-  "proof",
-  "confit",
-  "reduce",
-  "blindBake",
-  "compote",
-  "smother",
-  "setGel",
-  "pasteurize",
-  "appertize",
-  "poach",
-  "sweat",
-  "glaze",
-]);
-
-/** Attention class of a single step — see {@link SETUP_TECHNIQUES}. */
-type Attention = "SETUP" | "PASSIVE" | "ACTIVE";
-
-/** One technique occurrence within a step, already scaled to the planned portions. */
-interface OptimizerTechStepInput {
-  techStep: TechStepView;
-  order: number;
-  ingredients: CookingTaskIngredientView[];
-  utensils: UtensilView[];
-  /**
-   * Target temperature(s) named in this same clause (`preheat` → "à 180 °C").
-   * The structured subset only — see {@link CookingTemperatureView}. Not
-   * scaled (a temperature doesn't grow with the portion count). `[]` when
-   * the clause named no temperature.
-   */
-  temperatures: CookingTemperatureView[];
-}
-
-/** One recipe step, as handed to {@link optimizeCookingPlan}. */
-interface OptimizerStepInput {
-  stepId: number;
-  order: number;
-  description: string;
-  techSteps: OptimizerTechStepInput[];
-}
-
-/**
- * One planned recipe, as handed to {@link optimizeCookingPlan}. `portions`
- * is the planning slot's own count and `recipePortions` the recipe's
- * as-written yield — quantities are scaled by `portions / recipePortions`
- * (see {@link scaleOf}). The same recipe planned twice at different portion
- * counts arrives as two entries with the same `recipeId`; that's
- * intentional (two real cooking jobs), and merged-prep still pools their
- * knife work back together.
- */
-interface OptimizerRecipeInput {
-  recipeId: number;
-  name: string;
-  portions: number;
-  recipePortions: number;
-  steps: OptimizerStepInput[];
-}
-
-/** {@link optimizeCookingPlan}'s result — the date-range/legend wrapper is added by the service. */
-interface OptimizeCookingPlanResult {
-  recipes: CookingSessionRecipeRef[];
-  phases: CookingPhaseView[];
-}
-
-export type {
-  OptimizeCookingPlanResult,
-  OptimizerRecipeInput,
-  OptimizerStepInput,
-  OptimizerTechStepInput,
-};
-
-/** Portion scale factor for a recipe — guards a missing/zero as-written yield (bad data) by falling back to 1× rather than dividing by zero. */
-function scaleOf(recipe: OptimizerRecipeInput): number {
-  if (!recipe.recipePortions || recipe.recipePortions <= 0) return 1;
-  return recipe.portions / recipe.recipePortions;
-}
-
-/** A step normalized for scheduling — techniques scaled, attention resolved, ingredients/utensils/temperatures unioned across its technique clauses. */
-interface NormalizedStep {
-  /** Stable within one response: `step:<recipeIndex>:<stepId>` (the index disambiguates the same recipe planned twice). */
-  taskId: string;
-  recipeIndex: number;
-  recipe: CookingSessionRecipeRef;
-  stepId: number;
-  order: number;
-  description: string;
-  techSteps: OptimizerTechStepInput[];
-  attention: Attention;
-  isPurePrep: boolean;
-  /** Every technique in the step is a {@link SETUP_TECHNIQUES} one — eligible to pool via {@link extractMergedSetup}. */
-  isPureSetup: boolean;
-  dominantTechnique: TechStepView | null;
-  ingredients: CookingTaskIngredientView[];
-  utensils: UtensilView[];
-  /** Distinct target temperatures across the step's clauses (see {@link unionTemperatures}) — drives setup pooling and the coolest-first ordering. */
-  temperatures: CookingTemperatureView[];
-  /** Set once merged-prep/merged-setup extraction absorbs this step wholesale — it then produces no standalone task. */
-  absorbed: boolean;
-}
-
-/** Sums two ingredient lines only when it's unambiguous — same unit id and both quantities known; otherwise the pooled line carries no number (see `ShoppingListItemView`'s "don't guess a conversion" rule). */
-function poolIngredient(lines: CookingTaskIngredientView[]): {
-  quantity: number | null;
-  unit: CookingTaskIngredientView["unit"];
-} {
-  const first = lines[0];
-  if (!first) return { quantity: null, unit: null };
-  const unitId = first.unit?.id ?? null;
-  let total = 0;
-  for (const line of lines) {
-    if (line.quantity === null || (line.unit?.id ?? null) !== unitId) {
-      return { quantity: null, unit: null };
-    }
-    total += line.quantity;
-  }
-  return { quantity: total, unit: first.unit };
-}
-
-/** Unions ingredient lines by `(ingredientId, unitId)`, summing quantities within a group the same careful way as {@link poolIngredient}. */
-function unionIngredients(lines: CookingTaskIngredientView[]): CookingTaskIngredientView[] {
-  const groups = new Map<string, CookingTaskIngredientView[]>();
-  for (const line of lines) {
-    const key = `${line.ingredient.id}:${line.unit?.id ?? "x"}`;
-    const group = groups.get(key);
-    if (group) group.push(line);
-    else groups.set(key, [line]);
-  }
-  const out: CookingTaskIngredientView[] = [];
-  for (const group of groups.values()) {
-    const head = group[0];
-    if (!head) continue;
-    const pooled = poolIngredient(group);
-    out.push({ ingredient: head.ingredient, quantity: pooled.quantity, unit: pooled.unit });
-  }
-  return out.sort((a, b) => a.ingredient.key.localeCompare(b.ingredient.key));
-}
-
-/** Unions utensils by id, keeping a stable order by key. */
-function unionUtensils(utensils: UtensilView[]): UtensilView[] {
-  const byId = new Map<number, UtensilView>();
-  for (const utensil of utensils) byId.set(utensil.id, utensil);
-  return [...byId.values()].sort((a, b) => a.key.localeCompare(b.key));
-}
-
-/**
- * A stable canonical string for one temperature — `c<°C>` / `g<gasMark>` /
- * `q<level>`, or `""` when every field is null (shouldn't happen — the
- * upstream extractor guarantees one non-null — but stays total). Two
- * temperatures are "the same" iff their keys are equal: **no conversion**
- * between °C, gas marks and qualitative levels is guessed for a merge
- * decision (same "don't invent a conversion" stance as `ShoppingListItemView`
- * on units). °C is rounded to the nearest degree so `180` and `180.00`
- * (a `Decimal` artefact) collapse.
- */
-function temperatureKey(temperature: CookingTemperatureView): string {
-  if (temperature.celsius !== null) return `c${Math.round(temperature.celsius)}`;
-  if (temperature.gasMark !== null) return `g${temperature.gasMark}`;
-  if (temperature.qualitative !== null) return `q${temperature.qualitative}`;
-  return "";
-}
-
-/** Unions temperatures by {@link temperatureKey}, keeping a stable order by that key. */
-function unionTemperatures(temperatures: CookingTemperatureView[]): CookingTemperatureView[] {
-  const byKey = new Map<string, CookingTemperatureView>();
-  for (const temperature of temperatures) byKey.set(temperatureKey(temperature), temperature);
-  return [...byKey.entries()].sort(([a], [b]) => a.localeCompare(b)).map(([, value]) => value);
-}
-
-/**
- * A single number to *order* temperatures by (coolest first) — **never** used
- * to decide a merge (that's {@link temperatureKey}, exact-match only). Gas
- * marks map via the French `th × 30 ≈ °C` convention and qualitative levels
- * via rough midpoints, purely so a mixed list still sorts sensibly; a
- * temperature-less task sorts first.
- */
-function comparableTemp(temperature: CookingTemperatureView): number {
-  if (temperature.celsius !== null) return temperature.celsius;
-  if (temperature.gasMark !== null) return temperature.gasMark * 30;
-  if (temperature.qualitative !== null) {
-    return { low: 120, medium: 180, high: 240 }[temperature.qualitative];
-  }
-  return Number.NEGATIVE_INFINITY;
-}
-
-/** A setup task's sort position (coolest first) — its lowest target, or "before everything" when it has no detected temperature. */
-function setupTaskTemp(task: CookingTaskView): number {
-  if (task.temperatures.length === 0) return Number.NEGATIVE_INFINITY;
-  return Math.min(...task.temperatures.map(comparableTemp));
-}
-
-/** A step is pure prep only if it has techniques and every one of them is in {@link PREP_TECHNIQUES}. */
-function isPurePrepStep(techSteps: OptimizerTechStepInput[]): boolean {
-  return techSteps.length > 0 && techSteps.every((ts) => PREP_TECHNIQUES.has(ts.techStep.key));
-}
-
-/** A step is pure setup only if it has techniques and every one is in {@link SETUP_TECHNIQUES} — mirror of {@link isPurePrepStep}. */
-function isPureSetupStep(techSteps: OptimizerTechStepInput[]): boolean {
-  return techSteps.length > 0 && techSteps.every((ts) => SETUP_TECHNIQUES.has(ts.techStep.key));
-}
-
-/** Resolves a step's {@link Attention} — SETUP wins, then a *trailing* passive technique, else ACTIVE (see {@link SETUP_TECHNIQUES}). */
-function attentionOf(techSteps: OptimizerTechStepInput[]): Attention {
-  if (techSteps.some((ts) => SETUP_TECHNIQUES.has(ts.techStep.key))) return "SETUP";
-  const last = techSteps[techSteps.length - 1];
-  if (last && PASSIVE_TECHNIQUES.has(last.techStep.key)) return "PASSIVE";
-  return "ACTIVE";
-}
-
-/** Turns one recipe's raw steps into {@link NormalizedStep}s — scales quantities, resolves attention, unions per-clause ingredients/utensils up to the step. */
-function normalizeRecipe(recipe: OptimizerRecipeInput, recipeIndex: number): NormalizedStep[] {
-  const scale = scaleOf(recipe);
-  const recipeRef: CookingSessionRecipeRef = {
-    recipeId: recipe.recipeId,
-    name: recipe.name,
-    portions: recipe.portions,
-  };
-
-  return [...recipe.steps]
-    .sort((a, b) => a.order - b.order)
-    .map((step) => {
-      const techSteps: OptimizerTechStepInput[] = [...step.techSteps]
-        .sort((a, b) => a.order - b.order)
-        .map((ts) => ({
-          techStep: ts.techStep,
-          order: ts.order,
-          ingredients: ts.ingredients.map((line) => ({
-            ingredient: line.ingredient,
-            quantity: line.quantity === null ? null : line.quantity * scale,
-            unit: line.unit,
-          })),
-          utensils: ts.utensils,
-          // Temperatures are not scaled — an oven set to 180 °C for 4
-          // portions is still 180 °C for 8.
-          temperatures: ts.temperatures,
-        }));
-
-      const lastTech = techSteps[techSteps.length - 1];
-      return {
-        taskId: `step:${recipeIndex}:${step.stepId}`,
-        recipeIndex,
-        recipe: recipeRef,
-        stepId: step.stepId,
-        order: step.order,
-        description: step.description,
-        techSteps,
-        attention: attentionOf(techSteps),
-        isPurePrep: isPurePrepStep(techSteps),
-        isPureSetup: isPureSetupStep(techSteps),
-        dominantTechnique: lastTech ? lastTech.techStep : null,
-        ingredients: unionIngredients(techSteps.flatMap((ts) => ts.ingredients)),
-        utensils: unionUtensils(techSteps.flatMap((ts) => ts.utensils)),
-        temperatures: unionTemperatures(techSteps.flatMap((ts) => ts.temperatures)),
-        absorbed: false,
-      } satisfies NormalizedStep;
-    });
-}
-
-/** The prep signature of a pure-prep step — sorted `<techniqueKey>:<ingredientId>` pairs; two steps with the same signature do identical knife work and can be pooled. */
-function prepSignature(step: NormalizedStep): string {
-  const pairs: string[] = [];
-  for (const ts of step.techSteps) {
-    for (const line of ts.ingredients) {
-      pairs.push(`${ts.techStep.key}:${line.ingredient.id}`);
-    }
-  }
-  return [...new Set(pairs)].sort().join("+");
-}
-
-/**
- * The setup signature of a pure-setup step — `<sorted technique keys>|<sorted
- * temperature keys>`. Two steps with the same signature start the *same*
- * appliance in the *same* state and can be pooled. The temperature part is
- * `""` when no temperature was detected, which is a valid signature: two
- * bare "préchauffer le four" steps then share it and merge (the optimistic
- * default — an unknown temperature is assumed compatible). The appliance
- * itself is deliberately not in the key (a `preheat` is the oven either
- * way); its utensils are still unioned onto the pooled task.
- */
-function setupSignature(step: NormalizedStep): string {
-  const techKeys = [...new Set(step.techSteps.map((ts) => ts.techStep.key))].sort().join("+");
-  const tempKeys = step.temperatures
-    .map(temperatureKey)
-    .filter((key) => key !== "")
-    .sort()
-    .join("+");
-  return `${techKeys}|${tempKeys}`;
-}
-
-/** Builds one {@link CookingTaskView} from a normalized step run as written. */
-function stepToTask(step: NormalizedStep): CookingTaskView {
-  return {
-    id: step.taskId,
-    kind: "step",
-    technique: step.dominantTechnique,
-    description: step.description,
-    ingredients: step.ingredients,
-    utensils: step.utensils,
-    // Only a setup step (preheat/boil/…) carries a target temperature the
-    // plan should reason about; every other step leaves it `[]` even if its
-    // text happens to mention degrees.
-    temperatures: step.attention === "SETUP" ? step.temperatures : [],
-    sourceRecipes: [step.recipe],
-    originalSteps: [
-      {
-        recipeId: step.recipe.recipeId,
-        recipeName: step.recipe.name,
-        description: step.description,
-      },
-    ],
-  };
-}
-
-/** Builds the running-in-the-background status line for a passive step already scheduled in an earlier phase. */
-function stepToBackground(step: NormalizedStep): CookingBackgroundTaskView {
-  return {
-    id: `bg:${step.taskId}`,
-    technique: step.dominantTechnique,
-    description: step.description,
-    recipeId: step.recipe.recipeId,
-    recipeName: step.recipe.name,
-  };
-}
-
-/**
- * Pools pure-prep steps that do the *exact same* knife work (same
- * {@link prepSignature}) in two or more distinct recipes into one
- * `merged-prep` {@link CookingTaskView}, and marks every contributing step
- * `absorbed` so it produces no standalone task. A pure-prep step whose
- * signature is unique (only one recipe needs it) is left untouched — it
- * still lands in the mise-en-place phase, just as its own step task.
- *
- * Returns the merged tasks in a stable order (by id).
- */
-function extractMergedPrep(steps: NormalizedStep[]): CookingTaskView[] {
-  const bySignature = new Map<string, NormalizedStep[]>();
-  for (const step of steps) {
-    if (!step.isPurePrep) continue;
-    const signature = prepSignature(step);
-    if (signature === "") continue;
-    const group = bySignature.get(signature);
-    if (group) group.push(step);
-    else bySignature.set(signature, [step]);
-  }
-
-  const merged: CookingTaskView[] = [];
-  for (const [signature, group] of bySignature) {
-    const recipeIndexes = new Set(group.map((s) => s.recipeIndex));
-    if (recipeIndexes.size < 2) continue;
-
-    for (const step of group) step.absorbed = true;
-
-    // Every contributing clause's ingredient lines, pooled per ingredient.
-    const allLines = group.flatMap((s) => s.techSteps.flatMap((ts) => ts.ingredients));
-    const ingredients = unionIngredients(allLines);
-    const utensils = unionUtensils(group.flatMap((s) => s.utensils));
-
-    // Dominant technique of the pool = the first pair's technique (v1
-    // signatures are almost always a single `<technique>:<ingredient>`
-    // pair; a multi-pair signature just takes the earliest).
-    const firstTech = group[0]?.techSteps[0]?.techStep ?? null;
-    const firstIngredientKey = ingredients[0]?.ingredient.key ?? signature;
-
-    // Distinct source recipes / original step texts, in input order.
-    const sourceRecipes: CookingSessionRecipeRef[] = [];
-    const seenRecipe = new Set<number>();
-    const originalSteps: CookingTaskView["originalSteps"] = [];
-    for (const step of [...group].sort((a, b) => a.recipeIndex - b.recipeIndex)) {
-      if (!seenRecipe.has(step.recipeIndex)) {
-        seenRecipe.add(step.recipeIndex);
-        sourceRecipes.push(step.recipe);
-      }
-      originalSteps.push({
-        recipeId: step.recipe.recipeId,
-        recipeName: step.recipe.name,
-        description: step.description,
-      });
-    }
-
-    merged.push({
-      id: `prep:${firstTech ? firstTech.key : "prep"}:${firstIngredientKey}`,
-      kind: "merged-prep",
-      technique: firstTech,
-      description: null,
-      ingredients,
-      utensils,
-      temperatures: [],
-      sourceRecipes,
-      originalSteps,
-    });
-  }
-
-  return merged.sort((a, b) => a.id.localeCompare(b.id));
-}
-
-/**
- * Pools pure-setup steps with the same {@link setupSignature} (same action,
- * same detected temperature) across two or more distinct recipes into one
- * `merged-setup` {@link CookingTaskView}, marking each contributing step
- * `absorbed`. Two `preheat` steps at *different* temperatures have different
- * signatures and are therefore never pooled — {@link detectApplianceTemperatureConflicts}
- * turns that into a phase note. A signature only one recipe needs is left
- * untouched (still lands in mise-en-place as its own step task).
- *
- * Returns the merged tasks sorted by id.
- */
-function extractMergedSetup(steps: NormalizedStep[]): CookingTaskView[] {
-  const bySignature = new Map<string, NormalizedStep[]>();
-  for (const step of steps) {
-    if (!step.isPureSetup) continue;
-    const signature = setupSignature(step);
-    const group = bySignature.get(signature);
-    if (group) group.push(step);
-    else bySignature.set(signature, [step]);
-  }
-
-  const merged: CookingTaskView[] = [];
-  for (const group of bySignature.values()) {
-    const recipeIndexes = new Set(group.map((s) => s.recipeIndex));
-    if (recipeIndexes.size < 2) continue;
-
-    for (const step of group) step.absorbed = true;
-
-    const firstTech = group[0]?.techSteps[0]?.techStep ?? null;
-    const ingredients = unionIngredients(
-      group.flatMap((s) => s.techSteps.flatMap((ts) => ts.ingredients)),
-    );
-    const utensils = unionUtensils(group.flatMap((s) => s.utensils));
-    const temperatures = unionTemperatures(group.flatMap((s) => s.temperatures)).sort(
-      (a, b) => comparableTemp(a) - comparableTemp(b),
-    );
-
-    // Distinct source recipes / original step texts, in input order.
-    const sourceRecipes: CookingSessionRecipeRef[] = [];
-    const seenRecipe = new Set<number>();
-    const originalSteps: CookingTaskView["originalSteps"] = [];
-    for (const step of [...group].sort((a, b) => a.recipeIndex - b.recipeIndex)) {
-      if (!seenRecipe.has(step.recipeIndex)) {
-        seenRecipe.add(step.recipeIndex);
-        sourceRecipes.push(step.recipe);
-      }
-      originalSteps.push({
-        recipeId: step.recipe.recipeId,
-        recipeName: step.recipe.name,
-        description: step.description,
-      });
-    }
-
-    const tempKey = temperatures.map(temperatureKey).join("+");
-    merged.push({
-      id: `setup:${firstTech ? firstTech.key : "setup"}:${tempKey || "any"}`,
-      kind: "merged-setup",
-      technique: firstTech,
-      description: null,
-      ingredients,
-      utensils,
-      temperatures,
-      sourceRecipes,
-      originalSteps,
-    });
-  }
-
-  return merged.sort((a, b) => a.id.localeCompare(b.id));
-}
-
-/**
- * The kitchen has one oven: if the mise-en-place ends up with two or more
- * `preheat` tasks at *distinct known* temperatures, they cannot run at once.
- * Emits a single {@link CookingPhaseNoteView} listing those temperatures
- * coolest-first so the web layer can say "enchaîner 180 °C puis 210 °C".
- * A `preheat` with no detected temperature contributes nothing to the note
- * (it merged optimistically with the other unknowns and we've no number to
- * show).
- */
-function detectApplianceTemperatureConflicts(
-  setupTasks: CookingTaskView[],
-): CookingPhaseNoteView[] {
-  const preheats = setupTasks.filter((task) => task.technique?.key === "preheat");
-  const distinct = unionTemperatures(preheats.flatMap((task) => task.temperatures))
-    .filter((temperature) => temperatureKey(temperature) !== "")
-    .sort((a, b) => comparableTemp(a) - comparableTemp(b));
-
-  const technique = preheats.find((task) => task.technique !== null)?.technique;
-  if (distinct.length < 2 || !technique) return [];
-
-  return [{ kind: "appliance-temperature-conflict", technique, temperatures: distinct }];
-}
-
-/** Maps the input recipe list to its display legend, de-duplicating an exact `(recipeId, portions)` repeat. */
-function toRecipeLegend(recipes: OptimizerRecipeInput[]): CookingSessionRecipeRef[] {
-  const seen = new Set<string>();
-  const out: CookingSessionRecipeRef[] = [];
-  for (const recipe of recipes) {
-    const key = `${recipe.recipeId}:${recipe.portions}`;
-    if (seen.has(key)) continue;
-    seen.add(key);
-    out.push({ recipeId: recipe.recipeId, name: recipe.name, portions: recipe.portions });
-  }
-  return out;
-}
-
-/** A phase is `"finishing"` when everything left in it is plating; otherwise it's a normal `"cooking"` phase. */
-function cookingPhaseKind(tasks: CookingTaskView[]): CookingPhaseKind {
-  return tasks.every((task) => task.technique?.key === "plate") ? "finishing" : "cooking";
-}
-
-/**
- * See the file header. Given the week's planned recipes (already resolved
- * to reference views), returns the display legend plus the ordered phases:
- *
- * 1. **Mise en place** (`"mise-en-place"`) — all prep first (`merged-prep`
- *    tasks, then leftover pure-prep steps), then all setup (`merged-setup`
- *    tasks and leftover `SETUP` steps, ordered coolest-first). Carries an
- *    `appliance-temperature-conflict` note when the week needs the oven at
- *    two or more temperatures. Omitted entirely if it would be empty.
- * 2. **Cooking** (`"cooking"` / `"finishing"`) — the recipes interleaved:
- *    each phase pops the next remaining step of every recipe that still has
- *    one (passive-cook steps first, so long cooks start early). A passive
- *    step scheduled in one phase is echoed in every later phase's
- *    `background` until that recipe's next step is popped.
- */
-export function optimizeCookingPlan(recipes: OptimizerRecipeInput[]): OptimizeCookingPlanResult {
-  const legend = toRecipeLegend(recipes);
-  const normalized = recipes.map((recipe, index) => normalizeRecipe(recipe, index));
-  const allSteps = normalized.flat();
-
-  // Merged-prep first, then merged-setup — each marks its contributing
-  // steps `absorbed`, so the leftover loop below only sees the solo ones.
-  const mergedPrep = extractMergedPrep(allSteps);
-  const mergedSetup = extractMergedSetup(allSteps);
-
-  const phases: CookingPhaseView[] = [];
-
-  // Phase 0 — mise en place: all prep, then all setup. Keeping the two
-  // groups apart (rather than input order) lets the setup group be ordered
-  // coolest-first without disturbing the prep order.
-  const prepTasks: CookingTaskView[] = [...mergedPrep];
-  const setupTasks: CookingTaskView[] = [...mergedSetup];
-  for (const step of allSteps) {
-    if (step.absorbed) continue;
-    if (step.isPurePrep) {
-      prepTasks.push(stepToTask(step));
-      step.absorbed = true; // consumed here, not again in the cooking loop
-    } else if (step.attention === "SETUP") {
-      setupTasks.push(stepToTask(step));
-      step.absorbed = true;
-    }
-  }
-  // Coolest oven first, so a temperature conflict reads "180 °C puis 210 °C";
-  // `id` as a stable tiebreaker keeps the plan deterministic.
-  setupTasks.sort((a, b) => setupTaskTemp(a) - setupTaskTemp(b) || a.id.localeCompare(b.id));
-
-  const miseTasks = [...prepTasks, ...setupTasks];
-  if (miseTasks.length > 0) {
-    phases.push({
-      index: 0,
-      kind: "mise-en-place",
-      tasks: miseTasks,
-      background: [],
-      notes: detectApplianceTemperatureConflicts(setupTasks),
-    });
-  }
-
-  // Cooking phases — one "next step of each recipe" per phase. `hold` keeps
-  // a recipe out of the *next* phase right after it starts a passive cook,
-  // so another recipe's active work fills that phase and the passive cook
-  // shows up as `background` there instead of being immediately followed by
-  // its own next step.
-  const queues = normalized.map((steps) => ({
-    remaining: steps.filter((s) => !s.absorbed),
-    cursor: 0,
-    hold: 0,
-  }));
-  /** Passive steps started in an earlier phase, keyed by recipe index, still "cooking". */
-  const runningPassive = new Map<number, NormalizedStep>();
-
-  while (queues.some((queue) => queue.cursor < queue.remaining.length)) {
-    const phaseSteps: NormalizedStep[] = [];
-    queues.forEach((queue, recipeIndex) => {
-      const next = queue.remaining[queue.cursor];
-      if (!next) return;
-      if (queue.hold > 0) {
-        // Still tending its passive cook this phase — leave it in
-        // `runningPassive` so it renders as background, don't advance.
-        queue.hold--;
-        return;
-      }
-      // This recipe is advancing — whatever passive cook it had going is
-      // now being tended to, so it stops showing as background.
-      runningPassive.delete(recipeIndex);
-      phaseSteps.push(next);
-      queue.cursor++;
-    });
-
-    // Every recipe with steps left is holding on a passive cook — break the
-    // stall by releasing all holds and letting the next iteration advance.
-    if (phaseSteps.length === 0) {
-      for (const queue of queues) queue.hold = 0;
-      continue;
-    }
-
-    // Background = passive cooks from earlier phases not yet resolved above.
-    const background = [...runningPassive.values()].map(stepToBackground);
-
-    // Start the long cooks first within the phase.
-    phaseSteps.sort((a, b) => {
-      const rank = (s: NormalizedStep) => (s.attention === "PASSIVE" ? 0 : 1);
-      return rank(a) - rank(b) || a.recipeIndex - b.recipeIndex;
-    });
-
-    const tasks = phaseSteps.map(stepToTask);
-    phases.push({
-      index: phases.length,
-      kind: cookingPhaseKind(tasks),
-      tasks,
-      background,
-      // Temperature conflicts only matter in mise-en-place, where all the
-      // preheats live; a cooking phase never carries a note today.
-      notes: [],
-    });
-
-    for (const step of phaseSteps) {
-      if (step.attention === "PASSIVE") {
-        runningPassive.set(step.recipeIndex, step);
-        const queue = queues[step.recipeIndex];
-        if (queue) queue.hold = 1;
-      }
-    }
-  }
-
-  // `index` was set from `phases.length` as we went; re-stamp so it always
-  // matches the final array position even if phase 0 was skipped.
-  phases.forEach((phase, index) => {
-    phase.index = index;
-  });
-
-  return { recipes: legend, phases };
-}

apps/api/src/lib/recipe-matching/ingredient-matcher.ts

@@ -1,26 +1,23 @@
 import {
   INGREDIENT_LABEL_SYNONYMS_EN,
-  INGREDIENT_LABEL_SYNONYMS_FR,
   INGREDIENT_LABELS_EN,
-  INGREDIENT_LABELS_FR,
   UNIT_LABELS_EN,
-  UNIT_LABELS_FR,
 } from "@batch-cooking/shared";
 import { prisma } from "../../db/prisma.js";
 import { normalizeText } from "./tech-step-matcher.js";
 
 /**
  * Resolves the free-text `name`/`unit`/`quantity` a `RecipeSourceAdapter`
- * lifts from a recipe source (`ParsedRecipeIngredient`) against our own
- * `Ingredient`/`Unit` reference catalogs — the ingredient-side counterpart
- * to `tech-step-matcher.ts`'s technique detection, built for the same
- * reason: a source's raw text has no idea our catalogs even exist.
+ * lifts from an English-language source (`ParsedRecipeIngredient`) against
+ * our own `Ingredient`/`Unit` reference catalogs — the ingredient-side
+ * counterpart to `tech-step-matcher.ts`'s technique detection, built for
+ * the same reason: an English source's raw text has no idea our catalogs
+ * even exist.
  *
  * Unlike tech steps (regex mappings hand-authored per technique),
- * ingredient/unit labels are plain hand-written text, one table per
- * supported `locale` (`INGREDIENT_LABELS_EN`/`INGREDIENT_LABELS_FR`/
- * `UNIT_LABELS_EN`/`UNIT_LABELS_FR`, `packages/shared`) — matching them
- * against arbitrary free text (extra adjectives, plurals, "large diced
+ * ingredient/unit labels are plain hand-written English text
+ * (`INGREDIENT_LABELS_EN`/`UNIT_LABELS_EN`, `packages/shared`) — matching
+ * them against arbitrary free text (extra adjectives, plurals, "large diced
  * yellow onion" for a catalog entry that's just "Onion") needs its own,
  * lighter algorithm: word-tokenize both sides, naively stem for plurals,
  * then look for the catalog phrase's tokens as a contiguous run inside the
@@ -39,17 +36,17 @@ import { normalizeText } from "./tech-step-matcher.js";
  * one-time training pass.
  */
 
-/** One `Ingredient` row trimmed to what {@link matchIngredientName} needs, alongside its matching label in whichever locale it was loaded for. */
+/** One `Ingredient` row trimmed to what {@link matchIngredientName} needs, alongside its English matching label. */
 export interface IngredientMatchEntry {
   ingredientId: number;
-  /** Matching label — English (`INGREDIENT_LABELS_EN`) or French (`INGREDIENT_LABELS_FR`) depending on which locale {@link loadIngredientCatalog} was called with, e.g. `"Chicken breast"`/`"Blanc de poulet"` — matched against free text, never displayed. */
+  /** English label from `INGREDIENT_LABELS_EN`, e.g. `"Chicken breast"` — matched against free text, never displayed. */
   label: string;
 }
 
-/** One `Unit` row trimmed to what {@link matchUnit} needs, alongside its accepted spellings in whichever locale it was loaded for. */
+/** One `Unit` row trimmed to what {@link matchUnit} needs, alongside its accepted English spellings. */
 export interface UnitMatchEntry {
   unitId: number;
-  /** Accepted spellings — English (`UNIT_LABELS_EN`) or French (`UNIT_LABELS_FR`), e.g. `["tbsp", "tbs", "tablespoon", "tablespoons"]` or `["cuillère à soupe", "cas", ...]`. Unlike English, a French entry can be genuinely multi-word — see `matchUnit`'s own doc comment. */
+  /** Accepted spellings from `UNIT_LABELS_EN`, e.g. `["tbsp", "tbs", "tablespoon", "tablespoons"]`. */
   synonyms: string[];
 }
 
@@ -61,45 +58,19 @@ export interface UnitMatchEntry {
  * of every comparison go through it, not linguistically correct on its
  * own — see the module doc comment.
  */
-function stemWordEn(word: string): string {
+function stemWord(word: string): string {
   if (word.endsWith("ies") && word.length > 4) return `${word.slice(0, -3)}y`;
   if (word.endsWith("es") && word.length > 3) return word.slice(0, -2);
   if (word.endsWith("s") && !word.endsWith("ss") && word.length > 3) return word.slice(0, -1);
   return word;
 }
 
-/**
- * Naive French stemmer — French regular plurals are overwhelmingly just
- * "+s" on the singular (`"carotte"`/`"carottes"`, `"pomme"`/`"pommes"`),
- * unlike English's several suffix patterns, so this only strips a single
- * trailing "s". Deliberately *not* {@link stemWordEn}'s `"es"` rule reused
- * here: applying it to French would silently corrupt any word whose
- * singular itself ends in "e" plus a consonant before the final "s" — e.g.
- * `"carottes"` would wrongly stem to `"carott"` (dropping the "e" that's
- * actually part of the singular `"carotte"`) instead of `"carotte"`,
- * exactly the class of near-miss that made ingredient matching
- * French-locale silently broken before this stemmer existed (almost every
- * regular French plural ends in "es" this way — it's not an edge case).
- * Irregular plurals (`"cheval"`/`"chevaux"`, `"chou"`/`"choux"`) aren't
- * handled — same "consistent, not linguistically perfect" trade-off as
- * {@link stemWordEn}.
- */
-function stemWordFr(word: string): string {
-  if (word.endsWith("s") && !word.endsWith("ss") && word.length > 3) return word.slice(0, -1);
-  return word;
-}
-
-/** Dispatches to {@link stemWordEn}/{@link stemWordFr} by `locale` — any locale other than `"fr"` uses the English rules (the long-standing default, unchanged for every existing caller that doesn't pass a locale at all). */
-function stemWord(word: string, locale: string): string {
-  return locale === "fr" ? stemWordFr(word) : stemWordEn(word);
-}
-
-/** Lowercases, strips diacritics (via `normalizeText`) and splits `text` into stemmed word tokens — empty/non-letter runs are dropped, not kept as empty tokens. `locale` picks the stemming rules (see {@link stemWord}); defaults to `"en"`, the original behavior every pre-existing caller still gets without passing one. */
-function tokenize(text: string, locale = "en"): string[] {
+/** Lowercases, strips diacritics (via `normalizeText`) and splits `text` into stemmed word tokens — empty/non-letter runs are dropped, not kept as empty tokens. */
+function tokenize(text: string): string[] {
   return normalizeText(text)
     .split(/[^a-z]+/)
     .filter((word) => word.length > 0)
-    .map((word) => stemWord(word, locale));
+    .map(stemWord);
 }
 
 /** Whether `needle` appears as a contiguous run inside `haystack`, at any starting position. */
@@ -111,193 +82,22 @@ function containsSubsequence(haystack: string[], needle: string[]): boolean {
   return false;
 }
 
-/** One stemmed word from {@link tokenizeWithOffsets}, alongside its `[start, end)` span in the *original* (un-normalized) text it came from. */
-interface OffsetToken {
-  word: string;
-  start: number;
-  end: number;
-}
-
-/** Matches a run of letters (any script, diacritics included) — the same "word" unit {@link tokenize} splits `normalizeText`'d text on (`/[^a-z]+/`), applied here directly to the *original* text instead so each token keeps its real character offsets. Digits/punctuation are never part of a run, same separator role they play for `tokenize` (a leading quantity is `extractQuantity`'s job, not this module's word-tokenizer's). */
-const LETTER_RUN_PATTERN = /\p{L}+/gu;
-
-/**
- * {@link tokenize}'s positional twin: same stemmed/normalized words, but
- * each one keeps the `[start, end)` span it occupies in `text` — needed by
- * {@link findIngredientMentions} to report *where* a mention is, not just
- * that the catalog has a matching label somewhere. Splitting the original
- * text into letter-runs first (rather than normalizing the whole string up
- * front, the way `tokenize` does, then losing track of offsets) works
- * safely here because `normalizeText` only ever rewrites a character's own
- * form (case/diacritics) — see `_DiacriticsNormalizer`'s doc comment on the
- * Python side, ported from the same guarantee — never merges or splits
- * words, so normalizing one already-isolated run in place can't shift its
- * boundaries relative to the un-normalized text.
- */
-function tokenizeWithOffsets(text: string, locale = "en"): OffsetToken[] {
-  const tokens: OffsetToken[] = [];
-  for (const match of text.matchAll(LETTER_RUN_PATTERN)) {
-    const raw = match[0];
-    const start = match.index ?? 0;
-    const word = stemWord(normalizeText(raw), locale);
-    if (word.length === 0) continue;
-    tokens.push({ word, start, end: start + raw.length });
-  }
-  return tokens;
-}
-
-/**
- * Matches a quantity (integer/decimal/fraction/mixed number, same shapes as
- * {@link extractQuantity}) immediately followed by an optional unit
- * word/phrase (up to three words, e.g. "cuillères à soupe") and an optional
- * connector ("de"/"d'"/"of"/"a"/"an"), anchored at the *end* of whatever
- * string it's tested against (`$`) rather than the start. Anchoring at the
- * end — not the start — is what lets {@link findQuantityBeforeIngredient}
- * test the *whole* text preceding a mention without first having to guess
- * where an unrelated preamble ("ajouter", "puis", an earlier sentence) ends
- * and the quantity phrase begins: whatever doesn't fit the pattern
- * immediately before the ingredient simply isn't part of the match, no
- * separate boundary-finding step needed.
- */
-const QUANTITY_BEFORE_INGREDIENT_PATTERN =
-  /(\d+\s+\d+\/\d+|\d+\/\d+|\d+(?:[.,]\d+)?)\s*((?:\p{L}+\s+){0,2}\p{L}*)\s*(?:de\s|d['’]|of\s|a\s|an\s)?$/u;
-
-/**
- * Best-effort quantity+unit lookup for an ingredient mention {@link findIngredientMentions}
- * just found at `mentionStart` in `text` — looks *only* at what immediately
- * precedes the mention (see {@link QUANTITY_BEFORE_INGREDIENT_PATTERN}), the
- * dominant French/English recipe phrasing ("200g de beurre", "2 cuillères à
- * soupe d'huile", "3 œufs"). Both `null` when nothing recognizable precedes
- * it (no leading digit at all) — same "no match, not an error" posture as
- * {@link extractQuantity}. Doesn't detect a quantity that *follows* its
- * ingredient ("du beurre, 50g") — an accepted gap, same trade-off
- * {@link extractQuantity} already documents for the leading-only case it
- * was built for.
- */
-function findQuantityBeforeIngredient(
-  text: string,
-  mentionStart: number,
-  unitCatalog: UnitMatchEntry[],
-  locale: string,
-): { quantity: number | null; unitId: number | null } {
-  const match = QUANTITY_BEFORE_INGREDIENT_PATTERN.exec(text.slice(0, mentionStart));
-  if (!match) return { quantity: null, unitId: null };
-  const { quantity } = extractQuantity(match[1] ?? "");
-  const unitId = matchUnit(match[2] ?? "", unitCatalog, locale);
-  return { quantity, unitId };
-}
-
-/** One ingredient mention {@link findIngredientMentions} found in a free-text clause, alongside its `[start, end)` span (same convention as `TechStepMatch`, `tech-step-matcher.ts`) and any quantity+unit resolved immediately before it (see {@link findQuantityBeforeIngredient}) — both `null` when the clause names the ingredient with no quantity ("ajouter le sel"). */
-export interface IngredientMention {
-  ingredientId: number;
-  start: number;
-  end: number;
-  quantity: number | null;
-  unitId: number | null;
-}
-
-/**
- * Scans `text` (typically one technique's clause, see `tech-step-matcher.ts`'s
- * `splitIntoClauses`) for every mention of a catalog ingredient, left to
- * right, non-overlapping — the free-text-*scanning* counterpart to
- * {@link matchIngredientName} (which resolves one *already-isolated*
- * ingredient-line string to a single winner, not several mentions spread
- * across a longer text). Same "longest catalog label wins" rule as
- * {@link matchIngredientName}, applied at every token position in turn: once
- * a mention is found, scanning resumes right after it rather than
- * considering a shorter label starting inside an already-matched longer one.
- *
- * `locale` must match whatever `ingredientCatalog`/`unitCatalog` were loaded
- * in (see {@link loadIngredientCatalog}/{@link loadUnitCatalog}) — defaults
- * to `"en"`, same as every other function in this module.
- */
-export function findIngredientMentions(
-  text: string,
-  ingredientCatalog: IngredientMatchEntry[],
-  unitCatalog: UnitMatchEntry[],
-  locale = "en",
-): IngredientMention[] {
-  const tokens = tokenizeWithOffsets(text, locale);
-  if (tokens.length === 0) return [];
-
-  const candidates = ingredientCatalog
-    .map((entry) => ({
-      ingredientId: entry.ingredientId,
-      labelTokens: tokenize(entry.label, locale),
-    }))
-    .filter((entry) => entry.labelTokens.length > 0);
-
-  const mentions: IngredientMention[] = [];
-  let i = 0;
-  while (i < tokens.length) {
-    let best: { ingredientId: number; tokenCount: number } | null = null;
-    for (const candidate of candidates) {
-      const { labelTokens } = candidate;
-      if (i + labelTokens.length > tokens.length) continue;
-      const matches = labelTokens.every((word, offset) => tokens[i + offset]?.word === word);
-      if (!matches) continue;
-      if (
-        best === null ||
-        labelTokens.length > best.tokenCount ||
-        (labelTokens.length === best.tokenCount && candidate.ingredientId < best.ingredientId)
-      ) {
-        best = { ingredientId: candidate.ingredientId, tokenCount: labelTokens.length };
-      }
-    }
-
-    if (best === null) {
-      i += 1;
-      continue;
-    }
-    const startToken = tokens[i];
-    const endToken = tokens[i + best.tokenCount - 1];
-    if (startToken === undefined || endToken === undefined) {
-      // Unreachable — `best` was only ever set above after confirming
-      // `i + labelTokens.length <= tokens.length`, so both tokens exist.
-      // Satisfies `noUncheckedIndexedAccess`.
-      i += 1;
-      continue;
-    }
-    const { quantity, unitId } = findQuantityBeforeIngredient(
-      text,
-      startToken.start,
-      unitCatalog,
-      locale,
-    );
-    mentions.push({
-      ingredientId: best.ingredientId,
-      start: startToken.start,
-      end: endToken.end,
-      quantity,
-      unitId,
-    });
-    i += best.tokenCount;
-  }
-  return mentions;
-}
-
 /**
  * Resolves free-text `name` (a `ParsedRecipeIngredient.name`, e.g. `"large
  * diced yellow onions"`) to the best-matching `Ingredient` in `catalog`, or
  * `null` if nothing matches. Among every catalog entry whose label's words
- * all appear as a contiguous run in `name`, **in the same order**, the one
- * with the most words wins (most specific — "chicken breast" over bare
- * "chicken"); ties break on the lowest `ingredientId`, for a deterministic
- * result independent of catalog order. `locale` must match whatever
- * `catalog`'s labels were loaded in (see {@link loadIngredientCatalog}) —
- * defaults to `"en"`.
+ * all appear as a contiguous run in `name`, the one with the most words
+ * wins (most specific — "chicken breast" over bare "chicken"); ties break
+ * on the lowest `ingredientId`, for a deterministic result independent of
+ * catalog order.
  */
-export function matchIngredientName(
-  name: string,
-  catalog: IngredientMatchEntry[],
-  locale = "en",
-): number | null {
-  const nameTokens = tokenize(name, locale);
+export function matchIngredientName(name: string, catalog: IngredientMatchEntry[]): number | null {
+  const nameTokens = tokenize(name);
   if (nameTokens.length === 0) return null;
 
   let best: { ingredientId: number; tokenCount: number } | null = null;
   for (const entry of catalog) {
-    const labelTokens = tokenize(entry.label, locale);
+    const labelTokens = tokenize(entry.label);
     if (!containsSubsequence(nameTokens, labelTokens)) continue;
     if (
       best === null ||
@@ -314,44 +114,24 @@ export function matchIngredientName(
 }
 
 /**
- * Resolves free-text `unitText` (e.g. `"tbsp"`, `"Cups"`, `"cuillères à
- * soupe de farine"`) to the best-matching `Unit` in `catalog`, or `null` if
- * nothing matches. Same ordered-contiguous-run search as
- * {@link matchIngredientName}, longest match wins — **not** the
- * single-first-word equality check this function used before French
- * support existed: every English unit synonym happens to be one word, so
- * comparing only `unitText`'s first token against each *whole* synonym
- * string used to be enough, but a French unit can be genuinely multi-word
- * (`"cuillère à soupe"`, see `UNIT_LABELS_FR`) — a whole multi-word phrase
- * (spaces and all) can never equal a single extracted token, so that
- * approach would have silently matched nothing for any French unit
- * requiring more than one word. `locale` must match whatever `catalog`'s
- * synonyms were loaded in (see {@link loadUnitCatalog}) — defaults to
- * `"en"`.
+ * Resolves free-text `unitText` (e.g. `"tbsp"`, `"Cups"`) to the matching
+ * `Unit` in `catalog`, or `null` if nothing matches. A unit is a single
+ * word by convention (see `UNIT_LABELS_EN`), so this is a whole-token
+ * equality check (after stemming/normalizing), not the substring search
+ * `matchIngredientName` does — `"cup"` shouldn't match inside an unrelated
+ * longer word.
  */
-export function matchUnit(
-  unitText: string,
-  catalog: UnitMatchEntry[],
-  locale = "en",
-): number | null {
-  const textTokens = tokenize(unitText, locale);
-  if (textTokens.length === 0) return null;
+export function matchUnit(unitText: string, catalog: UnitMatchEntry[]): number | null {
+  const tokens = tokenize(unitText);
+  if (tokens.length === 0) return null;
+  const firstToken = tokens[0];
 
-  let best: { unitId: number; tokenCount: number } | null = null;
   for (const entry of catalog) {
-    for (const synonym of entry.synonyms) {
-      const synonymTokens = tokenize(synonym, locale);
-      if (!containsSubsequence(textTokens, synonymTokens)) continue;
-      if (
-        best === null ||
-        synonymTokens.length > best.tokenCount ||
-        (synonymTokens.length === best.tokenCount && entry.unitId < best.unitId)
-      ) {
-        best = { unitId: entry.unitId, tokenCount: synonymTokens.length };
+    if (entry.synonyms.some((synonym) => stemWord(normalizeText(synonym)) === firstToken)) {
+      return entry.unitId;
     }
   }
-  }
-  return best?.unitId ?? null;
+  return null;
 }
 
 /** What {@link extractQuantity} pulls out of a leading numeric expression, alongside what's left of the string after it. */
@@ -363,10 +143,7 @@ export interface ExtractedQuantity {
 
 // Leading "1 1/2", "1/2", "1.5", "1,5" or "2" (optionally followed by a
 // hyphenated range like "2-3", in which case only the first number counts —
-// good enough for a best-effort quantity, not meant to model ranges. The
-// `[.,]` decimal separator already covers French recipe text ("1,5") as-is,
-// same pattern used for English ("1.5") — no locale-specific handling
-// needed here, unlike tokenize/stemWord above.
+// good enough for a best-effort quantity, not meant to model ranges.
 const LEADING_QUANTITY_PATTERN = /^(\d+)\s+(\d+)\/(\d+)|^(\d+)\/(\d+)|^(\d+(?:[.,]\d+)?)/;
 
 /**
@@ -399,47 +176,18 @@ export function extractQuantity(rawText: string): ExtractedQuantity {
   return { quantity, remainder: trimmed.slice(match[0].length).trim() };
 }
 
-/**
- * Per-locale matching label tables {@link loadIngredientCatalog}/
- * {@link loadUnitCatalog} pick from — the only two locales with any
- * matching data authored yet (see `packages/shared/src/data/`). A locale
- * with no entry here (anything but `"en"`/`"fr"`) falls back to empty
- * tables in both loaders below — the same "no matching-language data,
- * degrade to doing nothing rather than guess" behavior `tech-step-matcher.ts`
- * already has for a locale with no trained mappings, not a thrown error.
- */
-const INGREDIENT_LABELS_BY_LOCALE: Record<string, Record<string, string>> = {
-  en: INGREDIENT_LABELS_EN,
-  fr: INGREDIENT_LABELS_FR,
-};
-const INGREDIENT_LABEL_SYNONYMS_BY_LOCALE: Record<string, Record<string, string[]>> = {
-  en: INGREDIENT_LABEL_SYNONYMS_EN,
-  fr: INGREDIENT_LABEL_SYNONYMS_FR,
-};
-const UNIT_LABELS_BY_LOCALE: Record<string, Record<string, string[]>> = {
-  en: UNIT_LABELS_EN,
-  fr: UNIT_LABELS_FR,
-};
-
-/** Loads the full `Ingredient` catalog as {@link IngredientMatchEntry}s for `locale` (default `"en"`) — one entry per key with an authored label in that locale, plus one extra entry per alternate wording (`INGREDIENT_LABEL_SYNONYMS_EN`/`_FR`, e.g. "Vanilla pod" alongside "Vanilla bean" — see issue #54) sharing the same `ingredientId`; `matchIngredientName` doesn't need to know synonyms exist, it just sees more candidate labels for the same ingredient. An ingredient with no label in `locale` yet is silently skipped, never a matching target — same for every ingredient when `locale` itself has no label table at all (see {@link INGREDIENT_LABELS_BY_LOCALE}). Meant to be fetched once per request and reused across every ingredient line, not re-queried per line. */
-export async function loadIngredientCatalog(locale = "en"): Promise<IngredientMatchEntry[]> {
+/** Loads the full `Ingredient` catalog as {@link IngredientMatchEntry}s — one entry per key with an authored English label (see `INGREDIENT_LABELS_EN`), plus one extra entry per alternate wording (`INGREDIENT_LABEL_SYNONYMS_EN`, e.g. "Vanilla pod" alongside "Vanilla bean" — see issue #54) sharing the same `ingredientId`; `matchIngredientName` doesn't need to know synonyms exist, it just sees more candidate labels for the same ingredient. An ingredient with no English label yet is silently skipped, never a matching target. Meant to be fetched once per request and reused across every ingredient line, not re-queried per line. */
+export async function loadIngredientCatalog(): Promise<IngredientMatchEntry[]> {
   try {
-    const labels = INGREDIENT_LABELS_BY_LOCALE[locale] ?? {};
-    const synonyms = INGREDIENT_LABEL_SYNONYMS_BY_LOCALE[locale] ?? {};
     const ingredients = await prisma.ingredient.findMany({
-      // Placeholder rows (user free-text, `placeholder:<uuid>` key) have no
-      // authored label so they'd be skipped by the `label === undefined`
-      // check below anyway — filtered here too so an import never even
-      // considers resolving one raw line to another line's placeholder.
-      where: { isPlaceholder: false },
       select: { id: true, key: true },
     });
     const catalog: IngredientMatchEntry[] = [];
     for (const ingredient of ingredients) {
-      const label = labels[ingredient.key];
+      const label = INGREDIENT_LABELS_EN[ingredient.key];
       if (label === undefined) continue;
       catalog.push({ ingredientId: ingredient.id, label });
-      for (const synonym of synonyms[ingredient.key] ?? []) {
+      for (const synonym of INGREDIENT_LABEL_SYNONYMS_EN[ingredient.key] ?? []) {
         catalog.push({ ingredientId: ingredient.id, label: synonym });
       }
     }
@@ -452,16 +200,15 @@ export async function loadIngredientCatalog(locale = "en"): Promise<IngredientMa
   }
 }
 
-/** Loads the full `Unit` catalog as {@link UnitMatchEntry}s for `locale` (default `"en"`) — one entry per key with authored synonyms in that locale (see {@link UNIT_LABELS_BY_LOCALE}); a unit with none yet is silently skipped. Meant to be fetched once per request, same reasoning as {@link loadIngredientCatalog}. */
-export async function loadUnitCatalog(locale = "en"): Promise<UnitMatchEntry[]> {
+/** Loads the full `Unit` catalog as {@link UnitMatchEntry}s — one entry per key with authored English synonyms (see `UNIT_LABELS_EN`); a unit with none yet is silently skipped. Meant to be fetched once per request, same reasoning as {@link loadIngredientCatalog}. */
+export async function loadUnitCatalog(): Promise<UnitMatchEntry[]> {
   try {
-    const labels = UNIT_LABELS_BY_LOCALE[locale] ?? {};
     const units = await prisma.unit.findMany({
       select: { id: true, key: true },
     });
     const catalog: UnitMatchEntry[] = [];
     for (const unit of units) {
-      const synonyms = labels[unit.key];
+      const synonyms = UNIT_LABELS_EN[unit.key];
       if (synonyms !== undefined) catalog.push({ unitId: unit.id, synonyms });
     }
     return catalog;

apps/api/src/lib/recipe-matching/intent-service-client.ts

@@ -1,135 +0,0 @@
-import { env } from "../../config/env.js";
-
-/**
- * Thin fetch wrapper around `services/tech-step-intent-service`'s HTTP
- * contract (`POST /v1/process`) — the microservice
- * {@link TechStepClassifierService} (`tech-step-matcher.ts`) delegates NER +
- * intent classification to, in place of the `node-nlp` `NlpManager` it used
- * to own directly. See that service's own README for the full contract and
- * why it never touches Postgres itself — it also owns its own training
- * corpus now (`training_data.py`), trained once at its own startup, so
- * `apps/api` never pushes anything to it; `process()` below is this
- * client's only method.
- *
- * Authenticated with `INTENT_SERVICE_SECRET` — the inverse direction of
- * `requireInternalWorker`'s `INTERNAL_WORKER_SECRET` (this time `apps/api`
- * is the caller, not the callee), but the same "one flat shared secret"
- * shape.
- */
-
-/** One candidate mention one of the service's two `PhraseMatcher`s found — offsets `[start, end)`, same convention as `String.prototype.slice`. Mirrors `EntityPayload` (Python `schemas.py`). `kind` distinguishes a technique mention (`self._matcher`, the corpus-trained one) from a utensil mention (`self._utensil_matcher`, static — see `utensil_vocabulary.py`) — `tech-step-matcher.ts` resolves each against a different catalog (`TechStep`/`Utensil`). */
-export interface IntentServiceEntity {
-  uid: string;
-  start: number;
-  end: number;
-  kind: "technique" | "utensil";
-}
-
-/**
- * A temperature the service recognized in the text — mirrors
- * `TemperaturePayload` (Python `schemas.py`), `gas_mark` camelCased to
- * `gasMark`. A separate list from {@link IntentServiceEntity} (not another
- * `kind`) because it carries structured fields that don't fit an entity's
- * `uid`. At least one of `celsius` / `gasMark` / `qualitative` is non-null.
- */
-export interface IntentServiceTemperature {
-  start: number;
-  end: number;
-  celsius: number | null;
-  gasMark: number | null;
-  qualitative: "low" | "medium" | "high" | null;
-  raw: string;
-}
-
-/** The full result of a `POST /v1/process` call — mirrors `ProcessResponse` (Python `schemas.py`). `intent` is `null` only when `locale` isn't one this service trains for, or `text` is blank; otherwise always a real `uid` (the Python service's `textcat` has no "None" sentinel, unlike node-nlp — see that service's README). `temperatures` is regex-extracted and independent of the model/training (empty when none, not omitted). */
-export interface IntentServiceProcessResult {
-  entities: IntentServiceEntity[];
-  intent: string | null;
-  score: number;
-  temperatures: IntentServiceTemperature[];
-}
-
-/**
- * Client for `services/tech-step-intent-service` — a real class (not a
- * plain object of functions) per this repo's service-style-logic
- * convention, even though it holds no state of its own: it's used as the
- * one shared {@link intentServiceClient} singleton below, same reasoning as
- * `TechStepClassifierService` itself.
- */
-export class IntentServiceClient {
-  /**
-   * Performs a JSON request against the intent service and returns the
-   * parsed body.
-   *
-   * @throws {Error} if the response status is not in the 2xx range, or the
-   *   request itself fails (network error, service down) — left as a plain
-   *   `Error` rather than a typed `HttpError`: this is an internal
-   *   service-to-service call, not a request `apps/api`'s own HTTP layer
-   *   needs to map to a client-facing status code (see
-   *   `TechStepClassifierService.warmUp`'s retry in `server.ts` for how a
-   *   failure here is actually handled).
-   */
-  private async _request<TResponseBody>(
-    path: string,
-    init: RequestInit = {},
-  ): Promise<TResponseBody> {
-    try {
-      const response = await fetch(`${env.INTENT_SERVICE_BASE_URL}${path}`, {
-        ...init,
-        headers: {
-          "Content-Type": "application/json",
-          "X-Intent-Service-Secret": env.INTENT_SERVICE_SECRET,
-          ...init.headers,
-        },
-      });
-      if (!response.ok) {
-        const body = await response.text().catch(() => "");
-        throw new Error(`${init.method ?? "GET"} ${path} failed: ${response.status} ${body}`);
-      }
-      return (await response.json()) as TResponseBody;
-    } catch (err) {
-      // Rethrown as-is — every caller (`TechStepClassifierService`) already
-      // wraps its own `await`s per the repo's try/catch convention; this is
-      // just where the `await` itself has to sit inside one.
-      throw err;
-    }
-  }
-
-  /**
-   * Equivalent to the old `NlpManager.process(locale, text)` — returns every
-   * candidate technique mention (NER) plus the intent classifier's verdict
-   * for `text` as a whole, whether `text` is a full step description or a
-   * single clause `TechStepClassifierService` already cut out of one (this
-   * service doesn't know or care which, exactly like `NlpManager` before
-   * it).
-   */
-  public async process(locale: string, text: string): Promise<IntentServiceProcessResult> {
-    try {
-      // The wire shape uses `gas_mark` (Python field name); everything else
-      // is already camelCase / single-word. Map that one key at the
-      // boundary so the rest of `apps/api` only ever sees `gasMark`.
-      const wire = await this._request<
-        Omit<IntentServiceProcessResult, "temperatures"> & {
-          temperatures: (Omit<IntentServiceTemperature, "gasMark"> & { gas_mark: number | null })[];
-        }
-      >("/v1/process", {
-        method: "POST",
-        body: JSON.stringify({ locale, text }),
-      });
-      return {
-        entities: wire.entities,
-        intent: wire.intent,
-        score: wire.score,
-        temperatures: (wire.temperatures ?? []).map(({ gas_mark, ...rest }) => ({
-          ...rest,
-          gasMark: gas_mark,
-        })),
-      };
-    } catch (err) {
-      throw err;
-    }
-  }
-}
-
-/** Single shared instance — stateless, no reason for more than one (same reasoning as `techStepClassifier`/`prisma`). */
-export const intentServiceClient = new IntentServiceClient();

apps/api/src/lib/recipe-matching/recipe-translation.ts

@@ -100,19 +100,12 @@ export async function translateRecipeSteps(
 }
 
 /**
- * Locale-specific label {@link matchUnit} is fed when a quantity was found
- * but no unit word was — see the `unitId` fallback below. Each is the
- * catalog's generic "counted, no further unit" entry (`Unit.key` `"piece"`)
- * in that locale's own label table (`UNIT_LABELS_EN`/`UNIT_LABELS_FR`,
- * `packages/shared`). A locale with neither entry (anything but
- * `"en"`/`"fr"`) falls back to the English spelling — harmless, since
- * `unitCatalog` itself is already empty for an unsupported locale (see
- * `loadUnitCatalog`), so this fallback lookup finds nothing either way.
+ * English label {@link matchUnit} is fed when a quantity was found but no
+ * unit word was — see the `unitId` fallback below. `"piece"` (`UNIT_LABELS_EN`,
+ * `packages/shared`) is the catalog's generic "counted, no further unit"
+ * entry (French "unité").
  */
-const FALLBACK_COUNT_UNIT_LABEL_BY_LOCALE: Record<string, string> = {
-  en: "piece",
-  fr: "unité",
-};
+const FALLBACK_COUNT_UNIT_LABEL = "piece";
 
 /**
  * Resolves each of `ingredients`' free-text `name`/`unit`/`quantity`
@@ -134,28 +127,20 @@ const FALLBACK_COUNT_UNIT_LABEL_BY_LOCALE: Record<string, string> = {
  * button disabled with no indication why on almost any recipe with a
  * whole-item ingredient. No fallback when `quantity` itself is `null`
  * (e.g. `"To taste"`) — there's nothing to count, so nothing to default.
- *
- * `locale` (default `"en"`, matching every pre-existing caller) must agree
- * with whichever locale `ingredientCatalog`/`unitCatalog` were loaded in
- * (see `loadIngredientCatalog`/`loadUnitCatalog`) — it's threaded through to
- * `matchIngredientName`/`matchUnit` for stemming, and picks the right
- * spelling of the "piece" fallback below.
  */
 export function translateRecipeIngredients(
   ingredients: ParsedRecipeIngredient[],
   ingredientCatalog: IngredientMatchEntry[],
   unitCatalog: UnitMatchEntry[],
-  locale = "en",
 ): TranslatedRecipeIngredient[] {
-  const fallbackCountUnitLabel = FALLBACK_COUNT_UNIT_LABEL_BY_LOCALE[locale] ?? "piece";
   return ingredients.map((ingredient) => {
-    const ingredientId = matchIngredientName(ingredient.name, ingredientCatalog, locale);
+    const ingredientId = matchIngredientName(ingredient.name, ingredientCatalog);
     const extracted = extractQuantity(ingredient.rawText);
     const quantity = ingredient.quantity ?? extracted.quantity;
     const unitText = ingredient.unit ?? extracted.remainder;
     const unitId =
-      matchUnit(unitText, unitCatalog, locale) ??
-      (quantity !== null ? matchUnit(fallbackCountUnitLabel, unitCatalog, locale) : null);
+      matchUnit(unitText, unitCatalog) ??
+      (quantity !== null ? matchUnit(FALLBACK_COUNT_UNIT_LABEL, unitCatalog) : null);
     return { ...ingredient, quantity, ingredientId, unitId };
   });
 }
@@ -288,19 +273,13 @@ export function mergeDuplicateIngredients(
  * locale that doesn't match the actual text's language doesn't degrade
  * gracefully, it just gets things wrong.
  *
- * Ingredient/unit matching has data for `"en"` and `"fr"` today
- * (`INGREDIENT_LABELS_EN`/`_FR`, `UNIT_LABELS_EN`/`_FR`, `packages/shared`)
- * — `loadIngredientCatalog(locale)`/`loadUnitCatalog(locale)` are always
- * called, never specially skipped for a particular locale: a locale with no
- * label table of its own (anything but `"en"`/`"fr"`) just gets back empty
- * catalogs from those two loaders, and `translateRecipeIngredients` over an
- * empty catalog naturally leaves every ingredient's `ingredientId`/`unitId`
- * at the neutral `null` `translateRecipeSteps` already stubs in — the same
- * "no matching-language data" degradation tech-step matching already has
- * for a locale with no mappings, just arrived at by *not* special-casing
- * which locales are "supported" here at all (that's `INGREDIENT_LABELS_BY_LOCALE`/
- * `UNIT_LABELS_BY_LOCALE`'s job, in `ingredient-matcher.ts` — this function
- * doesn't need its own copy of that list to stay in sync with).
+ * Ingredient/unit matching only has English data today
+ * (`INGREDIENT_LABELS_EN`/`UNIT_LABELS_EN`, `packages/shared`) — for any
+ * `locale` other than `"en"` this skips `loadIngredientCatalog`/
+ * `loadUnitCatalog` entirely and leaves every ingredient's `ingredientId`/
+ * `unitId` at the neutral `null` `translateRecipeSteps` already stubs in,
+ * the same "no matching-language data" degradation tech-step matching
+ * already has for a locale with no mappings.
  */
 export async function translateRecipe(
   recipe: ParsedRecipe,
@@ -309,18 +288,15 @@ export async function translateRecipe(
   try {
     const translated = await translateRecipeSteps(recipe, locale);
 
+    if (locale !== "en") return translated;
+
     const [ingredientCatalog, unitCatalog] = await Promise.all([
-      loadIngredientCatalog(locale),
-      loadUnitCatalog(locale),
+      loadIngredientCatalog(),
+      loadUnitCatalog(),
     ]);
     return {
       ...translated,
-      ingredients: translateRecipeIngredients(
-        recipe.ingredients,
-        ingredientCatalog,
-        unitCatalog,
-        locale,
-      ),
+      ingredients: translateRecipeIngredients(recipe.ingredients, ingredientCatalog, unitCatalog),
     };
   } catch (err) {
     // Rethrown as-is — the caller (`sources.service.ts`) already

apps/api/src/lib/recipe-matching/tech-step-eval-dataset.ts

@@ -2,8 +2,8 @@
  * Hand-labeled evaluation set for {@link techStepClassifier} — what
  * `tech-step-eval.test.ts` runs the real classifier against to compute
  * precision/recall/F1 (`tech-step-evaluator.ts`), the objective gate any
- * future change to `services/tech-step-intent-service`'s `training_data.py`
- * must clear (see that module's own doc comment).
+ * future change to `tech-step-training-data.ts` must clear (see that
+ * module's own doc comment).
  *
  * Deliberately *not* reusing `TECH_STEP_TRAINING_DATA`'s own `utterances`
  * verbatim — scoring the classifier against the exact sentences it was
@@ -246,7 +246,7 @@ export const TECH_STEP_EVAL_DATASET: TechStepEvalCase[] = [
   // --- Documented false-positive traps, re-verified with fresh wording ---
   // `brown`'s EN synonyms are verb forms only ("browned"/"browning"), not
   // bare "brown" — precisely so this doesn't false-positive (see that
-  // entry's own comment in training_data.py).
+  // entry's own comment in tech-step-training-data.ts).
   {
     description: "This recipe calls for two tablespoons of brown sugar.",
     locale: "en",

apps/api/src/lib/recipe-matching/tech-step-evaluator.ts

@@ -3,9 +3,8 @@
  * hand-labeled evaluation set (`tech-step-eval-dataset.ts`) — the objective
  * counterpart to the "inspected by eye" verdict every corpus change used to
  * get before this module existed. Every future edit to
- * `services/tech-step-intent-service`'s `training_data.py` (including the
- * LLM-assisted suggestions the worker in `services/tech-step-llm-worker`
- * proposes) is expected to run
+ * `tech-step-training-data.ts` (including the LLM-assisted suggestions the
+ * worker in `services/tech-step-llm-worker` proposes) is expected to run
  * through `tech-step-eval.test.ts`'s regression gate, which calls
  * {@link computeTechStepMetrics} — a corpus change that raises recall on one
  * technique but silently tanks another's precision should fail loudly here,

apps/api/src/lib/recipe-matching/tech-step-matcher.ts

@@ -1,11 +1,6 @@
+import { NlpManager } from "node-nlp";
 import { prisma } from "../../db/prisma.js";
-import {
-  findIngredientMentions,
-  type IngredientMention,
-  loadIngredientCatalog,
-  loadUnitCatalog,
-} from "./ingredient-matcher.js";
-import { type IntentServiceTemperature, intentServiceClient } from "./intent-service-client.js";
+import { TECH_STEP_TRAINING_DATA } from "./tech-step-training-data.js";
 
 /**
  * Auto-detects which cooking techniques (`TechStep`) a free-text recipe
@@ -20,27 +15,25 @@ import { type IntentServiceTemperature, intentServiceClient } from "./intent-ser
  * generalize past its own vocabulary — a step describing melting butter as
  * "jusqu'à ce que le beurre ait disparu dans la poêle" mentions no verb any
  * regex could anchor on, yet unmistakably *means* `melt`. Replaced with a
- * small hybrid pipeline (originally built on `node-nlp`, now entirely
- * delegated to `services/tech-step-intent-service` — a spaCy-based
- * microservice, see {@link IntentServiceClient} and that service's own
- * README):
+ * small hybrid pipeline built on `node-nlp` ({@link TechStepClassifierService}):
  *
- * 1. **NER** (the intent service's `PhraseMatcher`, built from its own
- *    `training_data.py`'s `synonyms`) finds every *candidate* technique
- *    mention in the whole description, each with its exact character span —
- *    mechanically the same job the old regexes did, just as flat synonym
- *    lists instead of hand-written patterns. This step alone is *not* the
- *    final answer — see step 3.
+ * 1. **NER** (node-nlp enum entities, `synonyms` in `TECH_STEP_TRAINING_DATA`)
+ *    finds every *candidate* technique mention in the whole
+ *    description, each with its exact character span — mechanically the
+ *    same job the old regexes did, just as flat synonym lists instead of
+ *    hand-written patterns (node-nlp's own stemmer/fuzzy matching already
+ *    covers minor conjugation/typo variance the regexes had to enumerate
+ *    by hand). This step alone is *not* the final answer — see step 3.
  * 2. The description is cut into clauses around those candidate spans
  *    ({@link splitIntoClauses}) — a step naming two techniques ("Dans une
  *    poêle chaude, faire chauffer une noix de beurre" is both `preheat`
  *    and `melt`) needs each judged on its own surrounding context, not the
  *    whole step lumped into one classification.
- * 3. **NLP intent classification** (the intent service's `textcat`, trained
- *    on its own `training_data.py`'s `utterances`) then classifies each
- *    clause on its own — this is what actually delivers "meaning, not
- *    keywords": the classifier was deliberately trained on paraphrases that
- *    never use the technique's own verb (e.g. "jusqu'à ce que le beurre ait
+ * 3. **NLP intent classification** (node-nlp's `NlpManager`, trained on
+ *    `TECH_STEP_TRAINING_DATA`'s `utterances`) then classifies each clause
+ *    on its own — this is what actually delivers "meaning, not keywords":
+ *    the classifier was deliberately trained on paraphrases that never use
+ *    the technique's own verb (e.g. "jusqu'à ce que le beurre ait
  *    disparu" for `melt`), so a clause reaching it gets labeled by what it
  *    was trained to recognize as *meaning* a technique, not by which
  *    literal word the NER step happened to anchor on. The NER-implied
@@ -56,12 +49,12 @@ import { type IntentServiceTemperature, intentServiceClient } from "./intent-ser
  *
  * `normalizeText` and {@link splitIntoClauses} are pure (no DB/model
  * access) so they stay unit-testable in isolation (see
- * `test/tech-step-matcher.test.ts`); this class only ever needs a
- * `TechStep.key -> id` lookup from the DB, memoized on the shared
- * {@link techStepClassifier} singleton rather than repeated per call — the
- * NLP model itself trains once, inside `services/tech-step-intent-service`'s
- * own startup, entirely independently of this class (see that service's
- * README — this repo no longer pushes any corpus to it over HTTP).
+ * `test/tech-step-matcher.test.ts`); the classifier itself needs a one-time
+ * training pass (`_ensureTrained`, node-nlp's `NlpManager.train()`) plus a
+ * `TechStep.key -> id` lookup from the DB, both memoized on the shared
+ * {@link techStepClassifier} singleton rather than repeated per call —
+ * training is the expensive part (a few hundred ms for this corpus), never
+ * worth redoing per request let alone per step.
  */
 
 /**
@@ -96,15 +89,6 @@ export function normalizeText(text: string): string {
  * Persisted as `StepTechStep.start`/`end`/`contextStart`/`contextEnd`
  * (`recipe.service.ts`) so the recipe detail view can highlight both spans,
  * not just know a technique was mentioned somewhere.
- *
- * `ingredients`/`utensils` are the metadata found in this match's own
- * *clause* (see this file's doc comment, point 2) — an ingredient/utensil
- * mentioned in a different clause of the same description belongs to
- * *that* clause's own match, never this one, the same "judged on its own
- * surrounding context" rule the technique itself is judged by. Always `[]`
- * rather than omitted when nothing was found, so every caller can iterate
- * unconditionally. Persisted as `StepTechStepIngredient`/`StepTechStepUtensil`
- * rows (`recipe.service.ts`).
  */
 export interface TechStepMatch {
   techStepId: number;
@@ -112,33 +96,8 @@ export interface TechStepMatch {
   end: number;
   contextStart: number;
   contextEnd: number;
-  ingredients: IngredientMention[];
-  utensils: UtensilMention[];
-  temperatures: TemperatureMention[];
 }
 
-/**
- * A utensil mention found by the intent service's utensil `PhraseMatcher`
- * (`kind: "utensil"` entities in `IntentServiceProcessResult`, see
- * `intent-service-client.ts`), resolved to a local `Utensil.id` and
- * attributed to whichever clause its span falls inside — same
- * `[start, end)` convention as every other span in this file.
- */
-export interface UtensilMention {
-  utensilId: number;
-  start: number;
-  end: number;
-}
-
-/**
- * A temperature the intent service's regex pass found (`temperatures` in
- * `IntentServiceProcessResult`), attributed to whichever clause its span
- * falls inside — same rule as {@link UtensilMention}. No DB id to resolve
- * (unlike a technique/ingredient/utensil): the structured value *is* the
- * data. Persisted verbatim as a `StepTechStepTemperature` row.
- */
-export type TemperatureMention = IntentServiceTemperature;
-
 /** A candidate technique mention found by NER — the raw material {@link splitIntoClauses} cuts a description around. */
 export interface TechniqueCandidate {
   /** Training-data `uid` this candidate's synonym belongs to (e.g. `"melt"`) — not yet resolved to a DB id at this stage. */
@@ -282,31 +241,18 @@ export function splitIntoClauses(
  * `TECH_STEP_TRAINING_DATA` — see `test/tech-step-matcher.test.ts` for the
  * cases this threshold was picked to pass.
  *
- * Recalibrated for the migration off `node-nlp` to
- * `services/tech-step-intent-service` (spaCy `textcat`, exclusive classes)
- * — its score distribution is meaningfully different from node-nlp's own
- * classifier, and shifts again every time the corpus' technique count
- * changes (more exclusive classes generally means a *lower* natural
- * confidence ceiling, softmax mass spread thinner).
- *
- * Currently `0.25`, set against the corpus as expanded to ~74 techniques
- * (`services/tech-step-intent-service/intent_service/training_data.py`,
- * `_TRAINING_ITERATIONS = 25`, `textcat` trained on each technique's own
- * `synonyms` in addition to its `utterances` — see that constant's own
- * comment for the calibration history) from manual spot-checks, not yet a
- * real `calibrate-tech-step-threshold.ts` sweep against
- * `TECH_STEP_EVAL_DATASET` (needs Postgres — see that script's own doc
- * comment): observed real-case scores ranged `0.31`-`0.89` (`simmer`
- * lowest, still correct in argmax and anchored anyway; `melt` highest, the
- * motivating anchor-less case), against a noise floor around `0.02`
- * (English text through the French classifier). `0.25` sits with real
- * margin above the noise floor and below every real case seen so far, but
- * **this is a placeholder pending the real eval-dataset sweep** — do not
- * treat it as load-bearing precision the way the original `0.45`
- * (calibrated against the ~26-technique corpus, `TECH_STEP_EVAL_DATASET`
- * F1 plateauing exactly there) was.
+ * Raised from `0.65` after finding real (non-adversarial) misclassified
+ * clauses that scored just above the old threshold — e.g. English recipe
+ * text run through the French classifier (which must find *nothing*,
+ * confirmed by `recipe-translation.test.ts`'s own locale-isolation test)
+ * scored `0.69` for `boil`, essentially classifier noise on
+ * out-of-vocabulary input rather than a real, confident verdict. The
+ * clauses this threshold exists to actually trust score far higher in
+ * practice (`0.91`–`1.0` for the real corrected cases found this session)
+ * — `0.75` sits comfortably above the noise floor and below every genuine
+ * match seen so far.
  */
-export const CONFIDENCE_THRESHOLD = 0.25;
+export const CONFIDENCE_THRESHOLD = 0.75;
 
 /**
  * One clause's full classification detail — the finer-grained sibling of
@@ -327,45 +273,70 @@ export interface TechStepClauseClassification {
   end: number;
   /** The clause's NER anchor's own implied technique `uid`, if it had one — same as `TechStepClause.anchor.uid`. */
   anchorUid: string | null;
-  /** The intent classifier's own top guess for this clause, whatever its score — `null` only when the intent service had nothing trained for `locale`, or the clause text was blank. Unlike {@link TechStepMatch}, never silently replaced by the anchor's uid — the whole point of this type is to expose the classifier's raw opinion, confident or not. */
+  /** The intent classifier's own top guess for this clause, whatever its score — `null` only when it returned node-nlp's `"None"` sentinel. Unlike {@link TechStepMatch}, never silently replaced by the anchor's uid — the whole point of this type is to expose the classifier's raw opinion, confident or not. */
   intentUid: string | null;
   /** The intent classifier's own confidence for `intentUid` — `0` when `intentUid` is `null` (nothing to have a score about). */
   score: number;
 }
 
 /**
- * Owns the `TechStep.key -> id` lookup behind {@link matchTechStepSpans} —
+ * Trains and owns the `node-nlp` model behind {@link matchTechStepSpans} —
  * a real class (not a plain object of functions) per this repo's
  * service-style-logic convention, even though it's only ever used as the
  * one shared {@link techStepClassifier} singleton below: it holds real
- * state (the memoized lookup promise), not just grouped stateless helpers.
- * The actual NER/intent-classification model lives entirely in
- * `services/tech-step-intent-service` (a separate process, trained from
- * its own `training_data.py` at its own startup) — this class never
- * trains or pushes anything to it, it only calls `POST /v1/process` and
- * resolves whatever `uid` comes back to a local DB id.
+ * state (the trained model, the memoized training/lookup promises), not
+ * just grouped stateless helpers.
  */
 export class TechStepClassifierService {
-  /** Memoized `TechStep.key -> id` lookup — resolved from the DB once, reused by every call rather than queried per request. `undefined` until the first call starts loading it, after which every caller (concurrent or not) awaits the same promise. */
-  private _techStepIdsLoaded: Promise<void> | undefined;
+  /** node-nlp's manager — both NER (enum entities) and NLP (intent classification) live on the same instance, trained together. */
+  private readonly _manager: NlpManager;
+  /** Memoized training pass — `undefined` until the first call starts it, after which every caller (concurrent or not) awaits the same promise rather than retraining. */
+  private _trained: Promise<void> | undefined;
+  /** Memoized `TechStep.key -> id` lookup — training data only knows techniques by their stable `uid`/`key`, resolved to the real DB id once, alongside training. */
   private _techStepIdByUid: Map<string, number> | undefined;
 
-  /** Same memoized-lookup shape as {@link _techStepIdsLoaded}/{@link _techStepIdByUid}, for `Utensil.key -> id` instead — a `kind: "utensil"` entity from the intent service resolves through this map, never `_techStepIdByUid`. */
-  private _utensilIdsLoaded: Promise<void> | undefined;
-  private _utensilIdByUid: Map<string, number> | undefined;
+  public constructor() {
+    this._manager = new NlpManager({
+      languages: ["fr", "en"],
+      forceNER: true,
+      nlu: { log: false },
+      // node-nlp's enum-entity NER defaults to a fuzzy (Levenshtein-based)
+      // 0.8 accuracy threshold — loose enough that e.g. "faire" (the
+      // generic French helper verb in almost every recipe step) fuzzy-
+      // matches `fry`'s synonym "frire" at 0.80, a false positive found
+      // while tuning this against the real training corpus. `1` (exact,
+      // after node-nlp's own case/accent/stemming normalization — real
+      // conjugation variance is still covered by listing each form in
+      // `tech-step-training-data.ts`) removed it without losing any real
+      // match. Precision matters more than recall for this stage — NER
+      // only proposes candidate split points, `_classifyClause`'s trained
+      // model (not fuzzy string distance) is what actually has to be
+      // right.
+      ner: { threshold: 1 },
+      // node-nlp defaults to `autoSave`/`autoLoad: true` — silently
+      // persisting the trained model to a `model.nlp` file in the process's
+      // cwd, and *loading from that file instead of retraining* the next
+      // time a manager is constructed, if the file already exists. Found
+      // this the hard way: a stray `model.nlp` appeared at the repo root
+      // after running this locally. That's the opposite of what this
+      // service wants — `TECH_STEP_TRAINING_DATA` in code is the single
+      // source of truth this always trains fresh from (see this file's own
+      // doc comment) — a stale on-disk model silently shadowing a
+      // corpus/threshold update would be a nasty, hard-to-notice class of
+      // bug. Both off; nothing here should ever touch disk.
+      autoSave: false,
+      autoLoad: false,
+    });
+  }
 
   /**
-   * Forces the `TechStep.key -> id` lookup to load now, synchronously with
-   * server startup (see `server.ts`, which also retries this against a
-   * not-yet-reachable intent service), rather than stalling whichever
-   * request happens to be first to save/preview a recipe. Doesn't wait on
-   * `services/tech-step-intent-service` finishing its own training — that
-   * service is only ever considered "up" by Docker Compose/CI once it
-   * already is (see that service's `GET /health`), so by the time this
-   * runs in a real deployment it's already trained; a request racing an
-   * intent service that's genuinely still starting just gets an empty
-   * match list back (see `IntentServiceProcessResult`'s own doc comment),
-   * not an error.
+   * Forces training plus node-nlp's own one-time lazy setup (loading its
+   * bundled per-language stemmers/tokenizers on the *first* real
+   * `NlpManager.process()` call takes a few seconds by itself, separate
+   * from and much slower than the ~40ms `train()` pass — measured against
+   * this corpus while tuning the pipeline) to happen now, synchronously
+   * with server startup (see `server.ts`), rather than stalling whichever
+   * request happens to be first to save/preview a recipe.
    */
   public async warmUp(): Promise<void> {
     try {
@@ -389,36 +360,26 @@ export class TechStepClassifierService {
    */
   public async matchTechStepSpans(description: string, locale: string): Promise<TechStepMatch[]> {
     try {
-      await Promise.all([this._ensureTechStepIdsLoaded(), this._ensureUtensilIdsLoaded()]);
+      await this._ensureTrained();
       if (description.trim().length === 0) return [];
 
-      // Loaded fresh per call (once per step, see `recipe.service.ts`'s
-      // `matchStepsTechSteps`) rather than memoized like the id lookups
-      // above — same "cheap enough, and reference data can change between
-      // calls without a restart" posture `loadIngredientCatalog`/
-      // `loadUnitCatalog`'s own doc comments already describe for their
-      // other callers (`ingredient-matcher.ts`, `sources.service.ts`).
-      const [ingredientCatalog, unitCatalog] = await Promise.all([
-        loadIngredientCatalog(locale),
-        loadUnitCatalog(locale),
-      ]);
-
-      // The intent service returns two kinds of candidate (see `kind` on
-      // `IntentServiceEntity`): technique mentions (its corpus-trained
-      // `PhraseMatcher`) and utensil mentions (its static one, see
-      // `utensil_vocabulary.py`). Only the former ever anchor a clause —
-      // `splitIntoClauses` cuts a description around *techniques*, a
-      // mentioned utensil doesn't introduce a clause boundary of its own,
-      // it just gets attributed to whichever clause its span falls inside
-      // (see the loop below). Its `start`/`end` are already `[start, end)`
-      // (matching `String.prototype.slice`), unlike node-nlp's inclusive
-      // `end` — no `+ 1` needed either.
-      const nerResult = await intentServiceClient.process(locale, description);
+      const nerResult = await this._manager.process(locale, description);
       const candidates: TechniqueCandidate[] = nerResult.entities
-        .filter((entity) => entity.kind === "technique")
-        .map((entity) => ({ uid: entity.uid, start: entity.start, end: entity.end }));
-      const utensilEntities = nerResult.entities.filter((entity) => entity.kind === "utensil");
-      const temperatureMentions = nerResult.temperatures;
+        // node-nlp's language plugins also auto-extract their own built-in
+        // entities (numbers, durations, dates…) alongside the enum
+        // entities `_train` registered from `TECH_STEP_TRAINING_DATA` —
+        // `type === "enum"` is what tells the two apart; without this
+        // filter a step like "10 minutes" would hand `splitIntoClauses` a
+        // bogus "duration" candidate that resolves to no real technique.
+        .filter((entity) => entity.type === "enum")
+        .map((entity) => ({
+          uid: entity.entity,
+          start: entity.start,
+          // node-nlp's own `end` is inclusive (verified against a real
+          // trained model) — `+ 1` converts to this module's `[start, end)`
+          // convention, matching `String.prototype.slice`.
+          end: entity.end + 1,
+        }));
 
       const clauses = splitIntoClauses(description, candidates);
       const matches: TechStepMatch[] = [];
@@ -432,42 +393,12 @@ export class TechStepClassifierService {
         // persist a dangling id.
         if (techStepId === undefined) continue;
         const span = clause.anchor ?? { start: clause.start, end: clause.end };
-
-        const ingredients = findIngredientMentions(
-          description.slice(clause.start, clause.end),
-          ingredientCatalog,
-          unitCatalog,
-          locale,
-        ).map((mention) => ({
-          ...mention,
-          start: mention.start + clause.start,
-          end: mention.end + clause.start,
-        }));
-
-        const utensils: UtensilMention[] = utensilEntities.flatMap((entity) => {
-          if (entity.start < clause.start || entity.end > clause.end) return [];
-          const utensilId = this._utensilIdByUid?.get(entity.uid);
-          // Same drift guard as `techStepId` above.
-          return utensilId === undefined
-            ? []
-            : [{ utensilId, start: entity.start, end: entity.end }];
-        });
-
-        // Temperatures carry no id to resolve — kept as-is, just attributed
-        // to the clause whose span contains them (same rule as utensils).
-        const temperatures: TemperatureMention[] = temperatureMentions.filter(
-          (temp) => temp.start >= clause.start && temp.end <= clause.end,
-        );
-
         matches.push({
           techStepId,
           start: span.start,
           end: span.end,
           contextStart: clause.start,
           contextEnd: clause.end,
-          ingredients,
-          utensils,
-          temperatures,
         });
       }
 
@@ -497,13 +428,17 @@ export class TechStepClassifierService {
     locale: string,
   ): Promise<TechStepClauseClassification[]> {
     try {
-      await this._ensureTechStepIdsLoaded();
+      await this._ensureTrained();
       if (description.trim().length === 0) return [];
 
-      const nerResult = await intentServiceClient.process(locale, description);
+      const nerResult = await this._manager.process(locale, description);
       const candidates: TechniqueCandidate[] = nerResult.entities
-        .filter((entity) => entity.kind === "technique")
-        .map((entity) => ({ uid: entity.uid, start: entity.start, end: entity.end }));
+        .filter((entity) => entity.type === "enum")
+        .map((entity) => ({
+          uid: entity.entity,
+          start: entity.start,
+          end: entity.end + 1,
+        }));
 
       const clauses = splitIntoClauses(description, candidates);
       const results: TechStepClauseClassification[] = [];
@@ -521,14 +456,15 @@ export class TechStepClassifierService {
           });
           continue;
         }
-        const result = await intentServiceClient.process(locale, clauseText);
+        const result = await this._manager.process(locale, clauseText);
+        const intentUid = result.intent !== "None" ? result.intent : null;
         results.push({
           clauseText,
           start: clause.start,
           end: clause.end,
           anchorUid,
-          intentUid: result.intent,
-          score: result.intent === null ? 0 : result.score,
+          intentUid,
+          score: intentUid === null ? 0 : result.score,
         });
       }
       return results;
@@ -570,8 +506,8 @@ export class TechStepClassifierService {
       const clauseText = description.slice(clause.start, clause.end).trim();
       if (clauseText.length === 0) return clause.anchor?.uid ?? null;
 
-      const result = await intentServiceClient.process(locale, clauseText);
-      if (result.intent !== null && result.score >= CONFIDENCE_THRESHOLD) {
+      const result = await this._manager.process(locale, clauseText);
+      if (result.intent !== "None" && result.score >= CONFIDENCE_THRESHOLD) {
         return result.intent;
       }
       return clause.anchor?.uid ?? null;
@@ -581,56 +517,52 @@ export class TechStepClassifierService {
   }
 
   /**
-   * Resolves the `uid -> TechStep.id` lookup exactly once — memoized on
-   * `_techStepIdsLoaded` so a burst of concurrent calls (several steps of
-   * the same recipe save, awaited via the same event loop tick) all await
-   * the one in-flight DB query rather than each firing their own.
+   * Trains `_manager` from {@link TECH_STEP_TRAINING_DATA} and resolves the
+   * `uid -> TechStep.id` lookup, both exactly once — memoized on
+   * `_trained` so a burst of concurrent calls (several steps of the same
+   * recipe save, awaited via the same event loop tick) all await the one
+   * in-flight training pass rather than each kicking off their own.
    */
-  private async _ensureTechStepIdsLoaded(): Promise<void> {
-    if (this._techStepIdsLoaded === undefined) {
-      this._techStepIdsLoaded = this._loadTechStepIds();
+  private async _ensureTrained(): Promise<void> {
+    if (this._trained === undefined) {
+      this._trained = this._train();
     }
     try {
-      await this._techStepIdsLoaded;
+      await this._trained;
     } catch (err) {
-      // A failed load must be retried by the *next* call, not leave every
-      // future call permanently rejecting against a stale failed promise.
-      this._techStepIdsLoaded = undefined;
+      // A failed training pass must be retried by the *next* call, not
+      // leave every future call permanently rejecting against a stale
+      // failed promise.
+      this._trained = undefined;
       throw err;
     }
   }
 
-  private async _loadTechStepIds(): Promise<void> {
+  private async _train(): Promise<void> {
     try {
       const techSteps = await prisma.techStep.findMany({ select: { id: true, key: true } });
       this._techStepIdByUid = new Map(techSteps.map((techStep) => [techStep.key, techStep.id]));
-    } catch (err) {
-      throw err; // see matchTechStepSpans()'s catch comment above
+
+      for (const entry of TECH_STEP_TRAINING_DATA) {
+        for (const [locale, data] of [
+          ["fr", entry.fr],
+          ["en", entry.en],
+        ] as const) {
+          if (data.synonyms.length > 0) {
+            this._manager.addNamedEntityText(entry.uid, entry.uid, [locale], data.synonyms);
+          }
+          for (const utterance of data.utterances) {
+            this._manager.addDocument(locale, utterance, entry.uid);
+          }
         }
       }
 
-  /** `Utensil.key -> id` counterpart of {@link _ensureTechStepIdsLoaded} — same memoize-once-retry-on-failure shape. */
-  private async _ensureUtensilIdsLoaded(): Promise<void> {
-    if (this._utensilIdsLoaded === undefined) {
-      this._utensilIdsLoaded = this._loadUtensilIds();
-    }
-    try {
-      await this._utensilIdsLoaded;
-    } catch (err) {
-      this._utensilIdsLoaded = undefined;
-      throw err;
-    }
-  }
-
-  private async _loadUtensilIds(): Promise<void> {
-    try {
-      const utensils = await prisma.utensil.findMany({ select: { id: true, key: true } });
-      this._utensilIdByUid = new Map(utensils.map((utensil) => [utensil.key, utensil.id]));
+      await this._manager.train();
     } catch (err) {
       throw err; // see matchTechStepSpans()'s catch comment above
     }
   }
 }
 
-/** Single shared instance — every caller reuses the one memoized `TechStep.key -> id` lookup rather than re-querying the DB. The actual model training (expensive — a couple of minutes, both locales combined) happens entirely inside `services/tech-step-intent-service`'s own startup, not here — see that service's `_TRAINING_ITERATIONS`. */
+/** Single shared instance — training is expensive enough (a few hundred ms) that every caller must reuse the one already-trained model, never spin up their own. */
 export const techStepClassifier = new TechStepClassifierService();

apps/api/src/lib/recipe-matching/tech-step-persistence.ts

@@ -1,64 +0,0 @@
-import type { Prisma } from "@prisma/client";
-import type { TechStepMatch } from "./tech-step-matcher.js";
-
-/**
- * Turns one step's {@link TechStepMatch}es into the Prisma nested-`create`
- * payload for its `techSteps` relation — the technique row **and** all three
- * of its clause-metadata child sets (`ingredients` / `utensils` /
- * `temperatures`).
- *
- * The single source of truth for that shape. It used to be written out by
- * hand in three places — `recipe.service.ts`'s `createRecipeInternal` and
- * `updateRecipe`, plus `src/scripts/backfill-tech-steps.ts` — and they had
- * drifted: only the create path wrote the metadata children, so **every
- * recipe resaved through the UI, and every recipe the backfill touched,
- * silently lost every ingredient / utensil / temperature the classifier had
- * attributed to its steps**. That left `cooking-optimizer.ts`'s
- * temperature-aware `preheat` grouping (the "don't preheat to 150 °C and
- * 200 °C at once" note) with no data to work from on any recipe that wasn't
- * a pristine, never-edited import. Building the payload once, here, is what
- * stops the three call sites diverging again.
- *
- * `order` is each match's index in `matches` (0-based). Callers pass matches
- * in reading order already; a caller that needs a different base (the
- * backfill, which offsets past untouched `"manual"` rows) overrides `order`
- * on the returned objects before handing them to Prisma.
- */
-export function toStepTechStepCreateInputs(
-  matches: TechStepMatch[],
-): Prisma.StepTechStepUncheckedCreateWithoutStepInput[] {
-  return matches.map((match, order) => ({
-    techStepId: match.techStepId,
-    start: match.start,
-    end: match.end,
-    contextStart: match.contextStart,
-    contextEnd: match.contextEnd,
-    order,
-    ingredients: {
-      create: match.ingredients.map((ingredient) => ({
-        ingredientId: ingredient.ingredientId,
-        quantity: ingredient.quantity,
-        unitId: ingredient.unitId,
-        start: ingredient.start,
-        end: ingredient.end,
-      })),
-    },
-    utensils: {
-      create: match.utensils.map((utensil) => ({
-        utensilId: utensil.utensilId,
-        start: utensil.start,
-        end: utensil.end,
-      })),
-    },
-    temperatures: {
-      create: match.temperatures.map((temperature) => ({
-        start: temperature.start,
-        end: temperature.end,
-        celsius: temperature.celsius,
-        gasMark: temperature.gasMark,
-        qualitative: temperature.qualitative,
-        raw: temperature.raw,
-      })),
-    },
-  }));
-}

apps/api/src/lib/recipe-matching/tech-step-training-data.ts

@@ -0,0 +1,911 @@
+/**
+ * Training corpus for {@link TechStepClassifierService} (`tech-step-matcher.ts`)
+ * — one entry per `TechStep` (`uid` matches `reference-seed-data.ts`'s
+ * `TECH_STEPS`, which still owns the reference `TechStep` rows themselves;
+ * this file replaces `TECH_STEPS[].mappings`' regex expressions as the
+ * *matching* data source).
+ *
+ * Two distinct kinds of content per technique/locale, feeding two distinct
+ * mechanisms of the classifier (see that file's doc comment for why both
+ * are needed):
+ *
+ * - `synonyms` — short literal words/set phrases, fed to node-nlp's NER
+ *   (enum entities). Mechanically equivalent to the old regexes' verb-form
+ *   alternations, just spelled out as plain words instead of a pattern
+ *   (node-nlp's own stemmer/fuzzy matching already covers minor
+ *   conjugation/typo variance that the regexes had to enumerate by hand).
+ *   Used only to find *candidate* technique mentions and cut a step into
+ *   clauses around them — never the final answer on their own.
+ * - `utterances` — full example clauses, fed to node-nlp's NLP Manager as
+ *   training documents for the intent classifier. Deliberately mixes
+ *   keyword-anchored phrasings (reinforces the obvious case) with
+ *   paraphrases that never use the technique's own verb at all (e.g.
+ *   "jusqu'à ce que le beurre ait disparu" for `melt`) — this second kind
+ *   is what actually delivers on "comprendre le sens, pas juste les mots
+ *   clés" (see the PR this file was introduced in): a clause reaching the
+ *   classifier gets labeled by what it's trained to recognize as *meaning*
+ *   this technique, not by which literal word triggered its extraction.
+ *
+ * Kept as static in-code data (not DB rows, unlike the old
+ * `TechStepMapping` table) because nothing needs to query/edit it at
+ * runtime — it only ever feeds one thing, the classifier's one-time
+ * training pass (see `TechStepClassifierService._ensureTrained`) — same
+ * reasoning `INGREDIENT_LABELS_EN` (`packages/shared`) is a plain object,
+ * not a database table.
+ */
+
+/** One technique's matching data for one locale — see this file's doc comment for what each list feeds. */
+export interface TechStepLocaleTrainingData {
+  synonyms: string[];
+  utterances: string[];
+}
+
+/** One technique's full training entry — `uid` must match a `TECH_STEPS[].uid` in `reference-seed-data.ts`. */
+export interface TechStepTrainingEntry {
+  uid: string;
+  fr: TechStepLocaleTrainingData;
+  en: TechStepLocaleTrainingData;
+}
+
+export const TECH_STEP_TRAINING_DATA: TechStepTrainingEntry[] = [
+  {
+    uid: "cook",
+    fr: {
+      synonyms: [
+        "cuire",
+        "cuisez",
+        "cuisant",
+        "cuisson",
+        "cuit",
+        "cuite",
+        "cuites",
+        "cuits",
+        "cuisiner",
+        "cuisinez",
+        "cuisiné",
+        "cuisinée",
+        "faire cuire",
+        "laisser cuire",
+      ],
+      utterances: [
+        "faire cuire à feu moyen",
+        "laisser cuire jusqu'à ce que ce soit prêt",
+        "la cuisson dure environ dix minutes",
+        "jusqu'à ce que la viande ne soit plus rose au centre",
+        "poursuivre la cuisson à couvert",
+        // Two real recipe clauses found misclassified (as `preheat` and
+        // `panFry` respectively, both above the confidence threshold) once
+        // real, longer, comma-heavy sentences started reaching the
+        // classifier — neither error came from a missing keyword (both
+        // clauses' own NER anchor, "laisser cuire"/"faire cuire", was
+        // already right), just the classifier's low-heat/occasional-
+        // stirring phrasing not resembling anything short and clean-cut it
+        // had actually been trained on.
+        "baisser le feu et laisser cuire à découvert encore un quart d'heure",
+        "faire cuire à feu doux en remuant de temps en temps",
+      ],
+    },
+    en: {
+      // NOT "cooked through"/"cooking through" — both are word-prefix
+      // extensions of "cooked"/"cooking" above, so any text containing them
+      // matches BOTH the short and long form as separate overlapping NER
+      // candidates, corrupting clause-splitting (confirmed via "It should
+      // be cooking through evenly", which spuriously grew a second,
+      // wrongly-classified `roast` candidate). See this pattern flagged
+      // throughout the file wherever it was found — the fix is always to
+      // drop the longer, redundant form rather than keep both.
+      synonyms: ["cook", "cooks", "cooked", "cooking"],
+      utterances: [
+        "cook over medium heat",
+        "cook until done",
+        "cooking takes about ten minutes",
+        "until no longer pink in the middle",
+        "continue cooking covered",
+      ],
+    },
+  },
+  {
+    uid: "fry",
+    fr: {
+      synonyms: [
+        "frire",
+        "frit",
+        "frite",
+        "frites",
+        "friture",
+        "faire frire",
+        "faites frire",
+        "bain de friture",
+        "huile de friture",
+      ],
+      utterances: [
+        "faire frire dans l'huile chaude",
+        "plonger dans la friture",
+        "jusqu'à ce que ce soit doré et croustillant à l'extérieur",
+        "l'huile doit être bien chaude avant d'y plonger les morceaux",
+      ],
+    },
+    en: {
+      // NOT "frying oil" — a word-prefix extension of "frying" above (see
+      // the `cook` entry's comment for why that duplicates/corrupts NER
+      // candidates; here it was even worse, misclassifying as `preheat`).
+      synonyms: ["fry", "fries", "fried", "frying", "deep fry", "deep-fried", "deep frying"],
+      utterances: [
+        "fry in hot oil",
+        "deep fry until golden",
+        "until crisp and golden on the outside",
+        "the oil should be very hot before adding the pieces",
+      ],
+    },
+  },
+  {
+    uid: "melt",
+    fr: {
+      synonyms: [
+        "fondre",
+        "fondu",
+        "fondue",
+        "fondues",
+        "faire fondre",
+        "faites fondre",
+        // Also a plausible way to say "melt" (heating something — usually
+        // a fat — until it liquefies), not just a `preheat` phrasing —
+        // restores what the regex-based system anchored on before this
+        // pipeline replaced it.
+        "faire chauffer",
+        "faites chauffer",
+        "liquéfier",
+        "liquéfiez",
+        "liquéfié",
+        "faire liquéfier",
+      ],
+      utterances: [
+        "faire fondre le beurre",
+        "jusqu'à ce que le beurre ait disparu dans la poêle",
+        "le beurre doit être complètement liquide",
+        "laisser le fromage devenir tout liquide sur feu doux",
+      ],
+    },
+    en: {
+      synonyms: ["melt", "melts", "melted", "melting", "liquefy", "liquefied"],
+      utterances: [
+        "melt the butter",
+        "until the butter has completely disappeared into the pan",
+        "the butter should be fully liquid",
+        "let the cheese turn completely liquid over low heat",
+      ],
+    },
+  },
+  {
+    uid: "deglaze",
+    fr: {
+      // NOT "déglacer la poêle"/"déglacer le fond de cuisson" — both are
+      // word-prefix extensions of "déglacer" above (see `cook`'s comment
+      // for why that duplicates NER candidates).
+      synonyms: ["déglacer", "déglacez", "déglacé", "déglacée", "déglaçage"],
+      utterances: [
+        "déglacer avec le vin blanc",
+        "verser le vin dans la poêle chaude pour décoller les sucs",
+        "gratter les sucs de cuisson au fond de la casserole avec un peu de bouillon",
+      ],
+    },
+    en: {
+      // NOT "deglaze the pan" — a word-prefix extension of "deglaze" above
+      // (see `cook`'s comment for why that duplicates NER candidates).
+      synonyms: ["deglaze", "deglazes", "deglazed", "deglazing", "lift the browned bits"],
+      utterances: [
+        "deglaze with white wine",
+        "pour the wine into the hot pan to lift the browned bits",
+        "scrape up the browned bits at the bottom of the pan with a splash of stock",
+      ],
+    },
+  },
+  {
+    uid: "simmer",
+    fr: {
+      synonyms: [
+        "mijoter",
+        "mijotez",
+        "mijote",
+        "mijotant",
+        "mijoté",
+        "frémir",
+        "frémissant",
+        "frémissante",
+        "à petit feu",
+      ],
+      utterances: [
+        "laisser mijoter à feu doux",
+        "faire mijoter pendant une heure",
+        "de petites bulles doivent remonter doucement à la surface",
+        "laisser cuire tout doucement à couvert pendant longtemps",
+      ],
+    },
+    en: {
+      // NOT "simmering gently" — a word-prefix extension of "simmering"
+      // above (see `cook`'s comment for why that duplicates NER candidates).
+      synonyms: ["simmer", "simmers", "simmered", "simmering", "gentle simmer", "low simmer"],
+      utterances: [
+        "let it simmer over low heat",
+        "simmer for one hour",
+        "small bubbles should gently rise to the surface",
+        "let it cook very gently, covered, for a long time",
+      ],
+    },
+  },
+  {
+    uid: "boil",
+    fr: {
+      synonyms: [
+        "bouillir",
+        "bouillant",
+        "bouillie",
+        "bouillies",
+        "ébullition",
+        "porter à ébullition",
+        "gros bouillons",
+      ],
+      utterances: [
+        "porter à ébullition",
+        "faire bouillir l'eau",
+        "de grosses bulles doivent agiter la surface avec force",
+        "jusqu'à ce que ça bouillonne franchement",
+      ],
+    },
+    en: {
+      // NOT "boiling point" — a word-prefix extension of "boiling" above
+      // (see `cook`'s comment for why that duplicates NER candidates).
+      synonyms: ["boil", "boils", "boiled", "boiling", "rolling boil"],
+      utterances: [
+        "bring to a boil",
+        "boil the water",
+        "large bubbles should be vigorously breaking the surface",
+        "until it's rolling vigorously",
+      ],
+    },
+  },
+  {
+    uid: "roast",
+    fr: {
+      // NOT "rôti au four" — a word-prefix extension of "rôti" above (see
+      // `cook`'s comment for why that duplicates NER candidates).
+      synonyms: ["rôtir", "rôti", "rôtie", "rôties", "rôtis", "rôtissage"],
+      utterances: [
+        "faire rôtir la volaille entière",
+        "le rôti doit dorer uniformément de tous les côtés",
+        "cuire la pièce de viande entière au four à chaleur sèche",
+      ],
+    },
+    en: {
+      synonyms: ["roast", "roasts", "roasted", "roasting", "oven-roast", "oven roasted"],
+      utterances: [
+        "roast the whole bird",
+        "it should brown evenly on every side",
+        "cook the whole piece of meat in dry oven heat",
+      ],
+    },
+  },
+  {
+    uid: "grill",
+    fr: {
+      synonyms: [
+        "griller",
+        "grillez",
+        "grillé",
+        "grillée",
+        "grillées",
+        "grillade",
+        "grillades",
+        "barbecue",
+        "au barbecue",
+      ],
+      utterances: [
+        "faire griller sur la grille du barbecue",
+        "marquer les steaks sur une plaque brûlante",
+        "des traces de quadrillage doivent apparaître à la cuisson",
+      ],
+    },
+    en: {
+      synonyms: ["grill", "grills", "grilled", "grilling", "barbecue", "char-grill", "charbroiled"],
+      utterances: [
+        "grill on the barbecue rack",
+        "sear the steaks on a scorching-hot plate",
+        "char marks should appear as it cooks",
+      ],
+    },
+  },
+  {
+    uid: "panFry",
+    fr: {
+      // Deliberately NOT "poêlé"/"poêlée"/"poêlés" here, despite reading
+      // like natural panFry vocabulary: node-nlp's French stemmer reduces
+      // them to the same root as the bare noun "poêle" (a pan), so
+      // registering them made every plain mention of "poêle" — e.g.
+      // `preheat`'s own "la poêle" — a false-positive panFry candidate too.
+      // Found via the "jusqu'à ce que le beurre ait disparu dans la poêle"
+      // regression test, which unexpectedly grew a spurious panFry match.
+      synonyms: ["sauter", "sautez", "sauté", "sautée", "sautées", "sautant", "à la poêle"],
+      utterances: [
+        "faire sauter les légumes à la poêle",
+        "saisir rapidement à feu vif en remuant sans cesse",
+        "faire revenir en remuant vivement dans une poêle très chaude",
+      ],
+    },
+    en: {
+      synonyms: [
+        "sauté",
+        "sauteed",
+        "sautéed",
+        "sauteing",
+        "pan-fry",
+        "pan fried",
+        "pan-fried",
+        "stir-fry",
+        "pan searing",
+        "seared in a pan",
+      ],
+      utterances: [
+        "sauté the vegetables in a pan",
+        "quickly sear over high heat, stirring constantly",
+        "cook briskly, stirring, in a very hot pan",
+      ],
+    },
+  },
+  {
+    uid: "blanch",
+    fr: {
+      synonyms: ["blanchir", "blanchissez", "blanchi", "blanchie", "blanchies", "blanchiment"],
+      utterances: [
+        "faire blanchir les légumes deux minutes dans l'eau bouillante",
+        "plonger brièvement dans l'eau bouillante puis directement dans l'eau glacée",
+        "cuire très rapidement à l'eau bouillante avant de stopper la cuisson au froid",
+      ],
+    },
+    en: {
+      // "parboil" is folded in here rather than kept a separate technique —
+      // in home-cooking usage (as opposed to professional usage, where they
+      // can differ) it names the same "briefly pre-cook in boiling water"
+      // move blanching does.
+      synonyms: [
+        "blanch",
+        "blanches",
+        "blanched",
+        "blanching",
+        "parboil",
+        "parboiled",
+        "parboiling",
+      ],
+      utterances: [
+        "blanch the vegetables for two minutes in boiling water",
+        "briefly plunge into boiling water then straight into ice water",
+        "cook very quickly in boiling water before stopping it cold",
+      ],
+    },
+  },
+  {
+    uid: "marinate",
+    fr: {
+      synonyms: [
+        "mariner",
+        "marinez",
+        "mariné",
+        "marinée",
+        "marinées",
+        "marinade",
+        "macérer",
+        "macérez",
+        "macération",
+        "faire mariner",
+      ],
+      utterances: [
+        "laisser mariner la viande toute la nuit au réfrigérateur",
+        "faire tremper dans la sauce plusieurs heures avant cuisson pour parfumer",
+        "laisser reposer dans le mélange d'huile et d'épices avant de cuisiner",
+      ],
+    },
+    en: {
+      // NOT "marinating for" — a word-prefix extension of "marinating"
+      // above (see `cook`'s comment for why that duplicates NER candidates
+      // — here it was even worse, misclassifying as `simmer`).
+      synonyms: [
+        "marinate",
+        "marinates",
+        "marinated",
+        "marinating",
+        "marinade",
+        "soak in the marinade",
+      ],
+      utterances: [
+        "let the meat marinate overnight in the fridge",
+        "soak in the sauce for several hours before cooking to flavor it",
+        "let it sit in the oil and spice mixture before cooking",
+      ],
+    },
+  },
+  {
+    uid: "chop",
+    fr: {
+      // NOT "hacher grossièrement" — a word-prefix extension of "hacher"
+      // above (see `cook`'s comment for why that duplicates NER candidates).
+      synonyms: [
+        "hacher",
+        "hachez",
+        "haché",
+        "hachée",
+        "hachées",
+        "hachis",
+        "couper en morceaux",
+        "tailler en morceaux",
+      ],
+      utterances: [
+        "hacher finement les oignons",
+        "couper en tout petits morceaux irréguliers au couteau",
+        "réduire les herbes en petits fragments avant de les ajouter",
+      ],
+    },
+    en: {
+      // NOT "chop coarsely" — a word-prefix extension of "chop" above (see
+      // `cook`'s comment for why that duplicates NER candidates).
+      synonyms: ["chop", "chops", "chopped", "chopping", "roughly chop", "coarsely chopped"],
+      utterances: [
+        "finely chop the onions",
+        "cut into small, uneven pieces with a knife",
+        "break the herbs down into small bits before adding them",
+      ],
+    },
+  },
+  {
+    uid: "peel",
+    fr: {
+      synonyms: [
+        "éplucher",
+        "épluchez",
+        "épluché",
+        "épluchée",
+        "épluchées",
+        "épluchage",
+        "peler",
+        "pelez",
+        "pelé",
+        "pelée",
+        "pelées",
+      ],
+      utterances: [
+        "éplucher les pommes de terre",
+        "retirer la peau des carottes avec un économe",
+        "ôter la pelure du fruit avant de le couper",
+      ],
+    },
+    en: {
+      synonyms: ["peel", "peels", "peeled", "peeling", "pare", "pared", "paring"],
+      utterances: [
+        "peel the potatoes",
+        "remove the skin from the carrots with a peeler",
+        "take the skin off the fruit before cutting it",
+      ],
+    },
+  },
+  {
+    uid: "mince",
+    fr: {
+      synonyms: [
+        "émincer",
+        "émincez",
+        "émincé",
+        "émincée",
+        "émincées",
+        "ciseler",
+        "ciselez",
+        "ciselé",
+        "ciselée",
+        "ciselées",
+      ],
+      utterances: [
+        "émincer l'oignon en fines lamelles",
+        "couper en très fines tranches régulières",
+        "détailler en lamelles aussi fines que possible",
+        // Without this, a short clause naming a different vegetable —
+        // "Émincer les tomates" — scored just above `melt`'s confidence
+        // threshold instead (a training-set-composition side effect of
+        // adding utterances elsewhere in this same pass, found by the full
+        // regression suite). A second example anchored on a different noun
+        // widens `mince`'s own region enough to reclaim it.
+        "émincer les tomates en fines rondelles",
+      ],
+    },
+    en: {
+      // NOT "mince finely" — a word-prefix extension of "mince" above (see
+      // `cook`'s comment for why that duplicates NER candidates).
+      synonyms: ["mince", "minces", "minced", "mincing", "thinly slice", "finely mince"],
+      utterances: [
+        "mince the onion into thin strips",
+        "cut into very thin, even slices",
+        "slice into strips as thin as possible",
+      ],
+    },
+  },
+  {
+    uid: "mix",
+    fr: {
+      synonyms: [
+        "mélanger",
+        "mélangez",
+        "mélangé",
+        "mélangée",
+        "mélangées",
+        "mélange",
+        "brasser",
+        "brassez",
+        "amalgamer",
+        "amalgamez",
+      ],
+      utterances: [
+        "mélanger tous les ingrédients dans un saladier",
+        "combiner le sucre et la farine ensemble",
+        "remuer jusqu'à obtenir une préparation homogène",
+      ],
+    },
+    en: {
+      synonyms: [
+        "mix",
+        "mixes",
+        "mixed",
+        "mixing",
+        "combine",
+        "combined",
+        "blend",
+        "blended",
+        "blending",
+        "stir together",
+      ],
+      utterances: [
+        "mix all the ingredients in a bowl",
+        "combine the sugar and flour together",
+        "stir until the mixture is smooth and even",
+      ],
+    },
+  },
+  {
+    uid: "whisk",
+    fr: {
+      synonyms: [
+        "fouetter",
+        "fouettez",
+        "fouetté",
+        "fouettée",
+        "fouettées",
+        "au fouet",
+        "battre au fouet",
+        "monter au fouet",
+      ],
+      utterances: [
+        "fouetter les œufs et le sucre",
+        "battre vigoureusement au fouet jusqu'à ce que ça blanchisse",
+        "travailler énergiquement pour incorporer de l'air au mélange",
+        // Without these, "Fouetter les blancs en neige" misclassified as
+        // `foldIn` — its own training utterance below also happens to say
+        // "les blancs en neige", and node-nlp's intent classifier leaned on
+        // that shared noun phrase over the actual verb. The exact phrase
+        // itself is needed (not just a paraphrase of it) — a longer,
+        // differently-worded utterance alone wasn't enough to outweigh
+        // `foldIn`'s own close phrasing.
+        "fouetter les blancs en neige",
+        "fouetter les blancs en neige jusqu'à ce qu'ils soient fermes",
+      ],
+    },
+    en: {
+      synonyms: ["whisk", "whisks", "whisked", "whisking", "beat", "whip", "whipped", "whipping"],
+      utterances: [
+        "whisk the eggs and sugar",
+        "beat vigorously with a whisk until pale",
+        "work it briskly to whip air into the mixture",
+        "whisk the egg whites until stiff peaks form",
+      ],
+    },
+  },
+  {
+    uid: "foldIn",
+    fr: {
+      synonyms: [
+        "incorporer",
+        "incorporez",
+        "incorporé",
+        "incorporée",
+        "incorporées",
+        // NOT "incorporer délicatement" — it's a superstring of "incorporer"
+        // above, so both would match the same text and hand
+        // `splitIntoClauses` two overlapping candidates for one mention
+        // (found via "Incorporer délicatement la farine" producing two
+        // duplicate matches instead of one).
+        "mélanger délicatement",
+      ],
+      utterances: [
+        "incorporer délicatement les blancs en neige",
+        "ajouter en soulevant doucement la masse pour ne pas casser les bulles",
+        "mélanger tout doucement de bas en haut pour garder l'air emprisonné",
+      ],
+    },
+    en: {
+      synonyms: ["fold in", "folds in", "folded in", "folding in", "gently fold", "fold gently"],
+      utterances: [
+        "gently fold in the beaten egg whites",
+        "add by gently lifting the batter so you don't knock the air out",
+        "very gently stir from the bottom up to keep the air trapped in",
+      ],
+    },
+  },
+  {
+    uid: "setAside",
+    fr: {
+      synonyms: [
+        "réserver",
+        "réservez",
+        "réservé",
+        "réservée",
+        "réservées",
+        "mettre de côté",
+        "laisser de côté",
+      ],
+      utterances: [
+        "réserver au frais en attendant",
+        "mettre de côté pour plus tard",
+        "laisser attendre sur le plan de travail pendant la préparation du reste",
+      ],
+    },
+    en: {
+      synonyms: ["set aside", "sets aside", "setting aside", "set it aside", "reserve", "reserved"],
+      utterances: [
+        "set aside in the fridge for now",
+        "put it aside for later",
+        "let it wait on the counter while you prepare the rest",
+      ],
+    },
+  },
+  {
+    uid: "season",
+    fr: {
+      synonyms: [
+        "assaisonner",
+        "assaisonnez",
+        "assaisonné",
+        "assaisonnée",
+        "assaisonnement",
+        "relever",
+        "relevez",
+        "épicer",
+        "épicez",
+      ],
+      utterances: [
+        "assaisonner avec du sel et du poivre",
+        "rectifier le goût en ajoutant des épices",
+        "ajouter du sel selon votre goût avant de servir",
+      ],
+    },
+    en: {
+      synonyms: ["season", "seasons", "seasoned", "seasoning", "spice it up", "add seasoning"],
+      utterances: [
+        "season with salt and pepper",
+        "adjust the taste by adding spices",
+        "add salt to taste before serving",
+      ],
+    },
+  },
+  {
+    uid: "drain",
+    fr: {
+      synonyms: [
+        "égoutter",
+        "égouttez",
+        "égoutté",
+        "égouttée",
+        "égouttées",
+        "essorer",
+        "essorez",
+        "essoré",
+        "essorée",
+      ],
+      utterances: [
+        "égoutter les pâtes dans une passoire",
+        "verser dans une passoire pour retirer l'eau de cuisson",
+        "laisser l'excédent d'eau s'écouler avant de servir",
+      ],
+    },
+    en: {
+      synonyms: ["drain", "drains", "drained", "draining", "strain", "strained", "straining"],
+      utterances: [
+        "drain the pasta in a colander",
+        "pour into a colander to remove the cooking water",
+        "let the excess water run off before serving",
+      ],
+    },
+  },
+  {
+    uid: "brown",
+    fr: {
+      synonyms: [
+        "faire revenir",
+        "faites revenir",
+        "faire dorer",
+        "faites dorer",
+        "colorer",
+        "colorez",
+        "faire colorer",
+      ],
+      utterances: [
+        "faire revenir les oignons dans l'huile chaude",
+        "faire dorer la viande sur toutes les faces",
+        "saisir jusqu'à ce que la surface prenne une belle couleur caramel",
+      ],
+    },
+    en: {
+      // Verb forms only (not bare "brown"), same reasoning the old regex
+      // doc comment gave — a bare "brown" false-positives on ingredient
+      // descriptions like "brown sugar"/"brown rice", which never get to
+      // the classifier since they're not step text, but keeping the
+      // synonym itself anchored costs nothing and stays consistent.
+      synonyms: ["browned", "browning"],
+      utterances: [
+        "brown the onions in hot oil",
+        "brown the meat on every side",
+        "sear until the surface turns a deep caramel color",
+      ],
+    },
+  },
+  {
+    uid: "rest",
+    fr: {
+      synonyms: ["reposer", "laisser reposer", "laissez reposer", "temps de repos"],
+      utterances: [
+        "laisser reposer la pâte trente minutes",
+        "laisser la viande se détendre hors du four avant de la découper",
+        "attendre quelques minutes avant de servir pour que les jus se répartissent",
+      ],
+    },
+    en: {
+      // Anchored to "let ... rest"/"rest for" rather than bare "rest",
+      // same false-positive reasoning as `brown` above ("the rest of the").
+      synonyms: ["let it rest", "let them rest", "resting for", "rested for", "resting time"],
+      utterances: [
+        "let the dough rest for thirty minutes",
+        "let the meat relax outside the oven before carving it",
+        "wait a few minutes before serving so the juices redistribute",
+      ],
+    },
+  },
+  {
+    uid: "preheat",
+    fr: {
+      synonyms: [
+        "préchauffer",
+        "préchauffez",
+        "préchauffé",
+        "préchauffée",
+        // A pan already described as hot ("poêle chaude") implies it's
+        // been preheated, without the verb itself — the classic "Dans une
+        // poêle chaude, faire chauffer une noix de beurre" case (both
+        // `preheat` and `melt` in one instruction).
+        "poêle chaude",
+        "préchauffage",
+      ],
+      utterances: [
+        "préchauffer le four à 180 degrés",
+        "mettre le four à chauffer avant d'y placer le plat",
+        "allumer le four à l'avance pour qu'il soit à température",
+        // A pan gets preheated too, not just an oven — without an example
+        // like this, "poêle" (which also appears throughout `panFry`'s own
+        // training utterances) biased the classifier toward `panFry` for
+        // any preheating clause that happens to mention a pan, found while
+        // testing against the classic "Préchauffer la poêle, puis faire
+        // fondre le beurre" case.
+        "préchauffer la poêle avant d'y verser l'huile",
+        "faire chauffer la poêle à vide quelques minutes",
+        // "poêle" + "feu vif" together still read as `panFry` (the act of
+        // actually cooking something in it) rather than `preheat` (getting
+        // it hot beforehand, nothing in it yet) without an example this
+        // close to that exact wording — found via "mettre la poêle sur feu
+        // vif" (no food mentioned at all) still classifying as panFry.
+        "mettre la poêle vide sur feu vif avant d'ajouter quoi que ce soit",
+        "mettre la poêle sur feu vif",
+      ],
+    },
+    en: {
+      // NOT "preheating time" — a word-prefix extension of "preheating"
+      // above (see `cook`'s comment for why that duplicates NER candidates).
+      synonyms: ["preheat", "preheats", "preheated", "preheating", "hot pan"],
+      utterances: [
+        "preheat the oven to 180 degrees",
+        "turn the oven on to heat up before putting the dish in",
+        "switch the oven on ahead of time so it's up to temperature",
+        "preheat the pan before adding the oil",
+        "heat the empty pan for a few minutes first",
+      ],
+    },
+  },
+  {
+    uid: "bake",
+    fr: {
+      synonyms: [
+        "cuire au four",
+        "cuisson au four",
+        "enfourner",
+        "enfournez",
+        "au four",
+        "enfourné",
+        "enfournée",
+      ],
+      utterances: [
+        "enfourner pendant quarante-cinq minutes",
+        "mettre au four jusqu'à ce que ce soit doré",
+        "cuire dans le four préchauffé jusqu'à ce que la surface soit ferme",
+      ],
+    },
+    en: {
+      // NOT "baked in the oven" — a word-prefix extension of "baked" above
+      // (see `cook`'s comment for why that duplicates NER candidates).
+      synonyms: ["bake", "bakes", "baked", "baking", "in the oven", "oven-baked"],
+      utterances: [
+        "bake for forty-five minutes",
+        "put it in the oven until golden",
+        "cook in the preheated oven until the surface is firm",
+      ],
+    },
+  },
+  {
+    uid: "plate",
+    fr: {
+      // NOT "dressage de l'assiette" — a word-prefix extension of
+      // "dressage" above (see `cook`'s comment for why that duplicates NER
+      // candidates).
+      synonyms: ["dresser", "dressez", "dressage", "disposer dans l'assiette"],
+      utterances: [
+        "dresser harmonieusement dans les assiettes",
+        "disposer joliment sur l'assiette avant de servir",
+        "présenter avec soin au centre de l'assiette",
+      ],
+    },
+    en: {
+      // NOT "plate up"/"plated nicely" — both are word-prefix extensions of
+      // "plate"/"plated" above (see `cook`'s comment for why that
+      // duplicates NER candidates).
+      synonyms: ["plate", "plates", "plated", "plating"],
+      utterances: [
+        "plate it up nicely",
+        "arrange it neatly on the plate before serving",
+        "present it carefully in the center of the plate",
+      ],
+    },
+  },
+  {
+    uid: "coat",
+    fr: {
+      synonyms: [
+        "napper",
+        "nappez",
+        "nappé",
+        "nappée",
+        "nappées",
+        "nappage",
+        "enrober",
+        "enrobez",
+        "enrobé",
+        "enrobée",
+        "enrobées",
+      ],
+      utterances: [
+        "napper le gâteau de chocolat fondu",
+        "recouvrir uniformément d'une fine couche de sauce",
+        "verser la sauce par-dessus pour bien enrober",
+      ],
+    },
+    en: {
+      // NOT "coat evenly" — a word-prefix extension of "coat" above (see
+      // `cook`'s comment for why that duplicates NER candidates).
+      synonyms: ["coat", "coats", "coated", "coating", "dredge", "dredged", "dredging"],
+      utterances: [
+        "coat the cake with melted chocolate",
+        "cover evenly with a thin layer of sauce",
+        "pour the sauce over it so it's well covered",
+      ],
+    },
+  },
+];

apps/api/src/lib/safe-admin.ts

@@ -1,20 +0,0 @@
-import type { AdminUserView } from "@batch-cooking/shared";
-import type { AdminUser } from "@prisma/client";
-
-/**
- * Shapes a Prisma `AdminUser` into the {@link AdminUserView} sent to the
- * admin client — drops `passwordHash` **and** `tokenVersion` (an internal
- * invalidation counter the client never needs, unlike `SafeUserProfile`
- * which does expose it), and serializes the two dates to ISO strings. The
- * one place this security-relevant stripping happens, same role as
- * `toSafeProfile` (`lib/safe-profile.ts`).
- */
-export function toSafeAdmin(admin: AdminUser): AdminUserView {
-  return {
-    id: admin.id,
-    email: admin.email,
-    name: admin.name,
-    createdAt: admin.createdAt.toISOString(),
-    lastLoginAt: admin.lastLoginAt === null ? null : admin.lastLoginAt.toISOString(),
-  };
-}

apps/api/src/middlewares/require-admin-socket.ts

@@ -1,43 +0,0 @@
-import { parseCookie } from "cookie";
-import type { Socket } from "socket.io";
-import { env } from "../config/env.js";
-import { resolveAdminFromToken } from "./require-admin.js";
-
-/**
- * `socket.io` handshake middleware guarding the admin WebSocket surface —
- * the connection-level equivalent of {@link requireAdmin} (`require-
- * admin.ts`). A `socket.io` handshake is a plain HTTP request that never
- * runs through Express's own middleware stack (`cookie-parser` included),
- * so the raw `Cookie` header has to be parsed by hand here with the
- * `cookie` package (the same one `cookie-parser` itself wraps).
- *
- * Registered via `io.use(requireAdminSocket)` — `socket.io` calls every
- * `io.use` middleware once per connection attempt, before `"connection"`
- * fires, exactly like Express's per-request middleware chain. Calling
- * `next()` with no argument admits the connection; calling it with an
- * `Error` rejects it, which the client sees as a `connect_error` event
- * (`socket.io-client` never even fires `"connect"` for it).
- *
- * On success, stashes the resolved admin on `socket.data.adminUser` —
- * `socket.io`'s per-connection storage bag, the WebSocket equivalent of
- * `res.locals` — for any handler that ends up needing it later.
- */
-export async function requireAdminSocket(
-  socket: Socket,
-  next: (err?: Error) => void,
-): Promise<void> {
-  try {
-    const cookieHeader = socket.handshake.headers.cookie;
-    const token = cookieHeader ? parseCookie(cookieHeader)[env.ADMIN_COOKIE_NAME] : undefined;
-    if (typeof token !== "string") {
-      throw new Error("Not authenticated");
-    }
-
-    socket.data.adminUser = await resolveAdminFromToken(token);
-    next();
-  } catch {
-    // Covers everything resolveAdminFromToken can throw, plus a missing
-    // cookie — same "never distinguish the reason" posture as requireAdmin.
-    next(new Error("Not authenticated"));
-  }
-}

apps/api/src/middlewares/require-admin.ts

@@ -1,88 +0,0 @@
-import { HttpError } from "@batch-cooking/error-tools";
-import { type AdminUserView, ErrorCode } from "@batch-cooking/shared";
-import type { NextFunction, Request, Response } from "express";
-import { env } from "../config/env.js";
-import { prisma } from "../db/prisma.js";
-import { verifyAdminToken } from "../lib/admin-jwt.js";
-import { toSafeAdmin } from "../lib/safe-admin.js";
-
-/**
- * Shape of `res.locals` once {@link requireAdmin} has run successfully.
- * Type a handler's response as `Response<unknown, AdminLocals>` to read
- * `res.locals.adminUser` fully typed, no cast — same `res.locals` (not
- * global `Request` augmentation) approach as {@link AuthLocals}
- * (`require-auth.ts`).
- */
-export interface AdminLocals {
-  /** The authenticated admin operator, resolved from the admin session cookie's JWT. */
-  adminUser: AdminUserView;
-}
-
-/**
- * Verifies an admin session JWT and resolves the `AdminUser` it belongs
- * to — the transport-agnostic core both {@link requireAdmin} (HTTP) and
- * `requireAdminSocket` (`require-admin-socket.ts`, the WebSocket handshake
- * equivalent) build on; they only differ in *where* they read the raw
- * cookie value from (`req.cookies`, already parsed by `cookie-parser`, vs
- * a `socket.io` handshake's raw `Cookie` header, which isn't). Kept here
- * rather than in `lib/admin-jwt.ts`, since it also does the DB
- * `tokenVersion` re-check that file deliberately doesn't know about.
- *
- * @throws {Error} for any failure — malformed/expired JWT, unknown admin,
- *   stale `tokenVersion`, or no `ADMIN_JWT_SECRET` configured (from
- *   {@link verifyAdminToken}). Always the same generic message; callers
- *   map it to their own transport's "unauthenticated" shape.
- */
-export async function resolveAdminFromToken(token: string): Promise<AdminUserView> {
-  const payload = verifyAdminToken(token);
-  const admin = await prisma.adminUser.findUnique({ where: { id: payload.adminUserId } });
-
-  if (!admin || admin.tokenVersion !== payload.tokenVersion) {
-    throw new Error("Not authenticated");
-  }
-
-  return toSafeAdmin(admin);
-}
-
-/**
- * Express middleware guarding every `/admin/api/*` route — the operations
- * UI (`apps/web`'s `/admin/*` pages) authenticating as an `AdminUser`.
- * Reads the admin session cookie (`ADMIN_COOKIE_NAME`, deliberately
- * **not** the same cookie as end-user sessions) and resolves it via
- * {@link resolveAdminFromToken}.
- *
- * A completely separate mechanism from {@link requireAuth}, not layered on
- * it: an end-user session token and an admin session token are never
- * interchangeable in either direction.
- *
- * Fails closed: an unset `ADMIN_JWT_SECRET` (the default for any instance
- * that doesn't run the admin app) makes {@link resolveAdminFromToken}
- * throw, so every request is rejected rather than the surface left open —
- * same posture as `requireInternalWorker`.
- *
- * @throws {HttpError} `401 NOT_AUTHENTICATED` for any failure — missing
- *   cookie or anything {@link resolveAdminFromToken} rejects on. Never
- *   distinguishes the reason.
- */
-export async function requireAdmin(
-  req: Request,
-  res: Response<unknown, AdminLocals>,
-  next: NextFunction,
-) {
-  try {
-    const token = req.cookies?.[env.ADMIN_COOKIE_NAME];
-    if (typeof token !== "string") {
-      throw new HttpError(401, ErrorCode.NOT_AUTHENTICATED, "Not authenticated");
-    }
-
-    res.locals.adminUser = await resolveAdminFromToken(token);
-    next();
-  } catch (err) {
-    if (err instanceof HttpError) {
-      next(err);
-    } else {
-      // Covers everything resolveAdminFromToken can throw.
-      next(new HttpError(401, ErrorCode.NOT_AUTHENTICATED, "Not authenticated"));
-    }
-  }
-}

apps/api/src/middlewares/require-auth.ts

@@ -13,34 +13,16 @@ import { toSafeProfile } from "../lib/safe-profile.js";
  * typed, no cast needed.
  */
 export interface AuthLocals {
-  /** The authenticated profile, resolved from the session cookie's JWT (or an `Authorization: Bearer` one, for cookie-less clients). */
+  /** The authenticated profile, resolved from the session cookie's JWT. */
   userProfile: SafeUserProfile;
 }
 
-/**
- * Pulls the raw JWT out of an `Authorization: Bearer <jwt>` header, or
- * returns `null` if it's absent or malformed. This is the fallback path for
- * clients that can't rely on the `session` cookie — a Capacitor WebView,
- * whose origin never receives a `SameSite=Lax` cookie (see `AuthResponse`
- * in packages/shared). The cookie remains the primary mechanism; this only
- * kicks in when the cookie isn't there.
- */
-function readBearerToken(header: string | undefined): string | null {
-  if (!header?.startsWith("Bearer ")) {
-    return null;
-  }
-  const token = header.slice("Bearer ".length).trim();
-  return token.length > 0 ? token : null;
-}
-
 /**
  * Express middleware guarding routes that require an authenticated
- * profile. Reads the session cookie (falling back to an `Authorization:
- * Bearer <jwt>` header when there's no cookie — see {@link readBearerToken}),
- * verifies the JWT, and re-checks `tokenVersion` against the database — so a
- * stateless JWT can still be invalidated server-side (e.g. on password
- * change / logout-everywhere, once that feature exists) despite carrying no
- * server-side session.
+ * profile. Reads the session cookie, verifies the JWT, and re-checks
+ * `tokenVersion` against the database — so a stateless JWT can still be
+ * invalidated server-side (e.g. on password change / logout-everywhere,
+ * once that feature exists) despite carrying no server-side session.
  *
  * On success, attaches the resolved profile to `res.locals.userProfile`
  * (typed via {@link AuthLocals}) for downstream handlers to use.
@@ -51,9 +33,9 @@ function readBearerToken(header: string | undefined): string | null {
  * project-wide ambient augmentation silently changing every `Request` in
  * the codebase, whether or not it went through this middleware.
  *
- * @throws {HttpError} `401 NOT_AUTHENTICATED` for any failure — no cookie
- *   and no usable Bearer header, malformed/expired JWT, unknown profile, or
- *   stale tokenVersion. Never distinguishes the reason to the client.
+ * @throws {HttpError} `401 NOT_AUTHENTICATED` for any failure — missing
+ *   cookie, malformed/expired JWT, unknown profile, or stale tokenVersion.
+ *   Never distinguishes the reason to the client.
  */
 export async function requireAuth(
   req: Request,
@@ -61,11 +43,7 @@ export async function requireAuth(
   next: NextFunction,
 ) {
   try {
-    const cookieToken = req.cookies?.[env.AUTH_COOKIE_NAME];
-    // Cookie first (the browser's mechanism, unchanged); `Authorization:
-    // Bearer` as a fallback for cookie-less clients — see readBearerToken.
-    const token =
-      typeof cookieToken === "string" ? cookieToken : readBearerToken(req.headers.authorization);
+    const token = req.cookies?.[env.AUTH_COOKIE_NAME];
     if (typeof token !== "string") {
       throw new HttpError(401, ErrorCode.NOT_AUTHENTICATED, "Not authenticated");
     }

apps/api/src/modules/admin/admin-auth.routes.ts

@@ -1,51 +0,0 @@
-import { wrapAsyncHandler } from "@batch-cooking/express-tools";
-import { adminLoginSchema } from "@batch-cooking/shared";
-import { type CookieOptions, type Response, Router } from "express";
-import { env } from "../../config/env.js";
-import { type AdminLocals, requireAdmin } from "../../middlewares/require-admin.js";
-import { adminLogin } from "./admin-auth.service.js";
-
-/** Router mounted at `/admin/api/auth` (via `admin.routes.ts`) — admin login, logout, current-admin. No signup: admins are created out-of-band (`src/scripts/create-admin.ts`). */
-export const adminAuthRouter = Router();
-
-const SEVEN_DAYS_MS = 7 * 24 * 60 * 60 * 1000;
-
-/**
- * Cookie options for the admin session — same shape as `auth.routes.ts`'s
- * end-user cookie (httpOnly, `Secure` in production unless `COOKIE_SECURE`
- * overrides, `SameSite=Lax`), just written under {@link env.ADMIN_COOKIE_NAME}
- * so the two sessions never collide in one browser.
- */
-const adminCookieOptions: CookieOptions = {
-  httpOnly: true,
-  secure: env.COOKIE_SECURE ?? env.NODE_ENV === "production",
-  sameSite: "lax",
-  maxAge: SEVEN_DAYS_MS,
-};
-
-// `res.clearCookie` sets its own expiry — passing `maxAge` alongside is
-// deprecated as of Express 4.20, so the logout route reuses the options
-// minus that one field (same trick as `auth.routes.ts`).
-const { maxAge: _maxAge, ...clearAdminCookieOptions } = adminCookieOptions;
-
-/** Verifies admin credentials and starts an admin session. */
-adminAuthRouter.post(
-  "/login",
-  wrapAsyncHandler(async (req, res) => {
-    const input = adminLoginSchema.parse(req.body);
-    const { admin, token } = await adminLogin(input);
-    res.cookie(env.ADMIN_COOKIE_NAME, token, adminCookieOptions);
-    res.status(200).json(admin);
-  }),
-);
-
-/** Ends the admin session by clearing the cookie. Stateless JWT — nothing to revoke server-side beyond bumping `tokenVersion` (no UI for that yet). */
-adminAuthRouter.post("/logout", (_req, res) => {
-  res.clearCookie(env.ADMIN_COOKIE_NAME, clearAdminCookieOptions);
-  res.status(204).end();
-});
-
-/** Returns the currently authenticated admin. Behind `requireAdmin` — 401s if there's no valid admin session. */
-adminAuthRouter.get("/me", requireAdmin, (_req, res: Response<unknown, AdminLocals>) => {
-  res.status(200).json(res.locals.adminUser);
-});

apps/api/src/modules/admin/admin-auth.service.ts

@@ -1,59 +0,0 @@
-import { HttpError } from "@batch-cooking/error-tools";
-import { type AdminLoginInput, type AdminUserView, ErrorCode } from "@batch-cooking/shared";
-import argon2 from "argon2";
-import { env } from "../../config/env.js";
-import { prisma } from "../../db/prisma.js";
-import { signAdminToken } from "../../lib/admin-jwt.js";
-import { toSafeAdmin } from "../../lib/safe-admin.js";
-
-/** Result of a successful admin login: the safe admin view plus the signed admin session JWT to set as a cookie. */
-interface AdminAuthResult {
-  admin: AdminUserView;
-  token: string;
-}
-
-// Same reasoning as `auth.service.ts`'s `hashOptions`: argon2's real
-// defaults are deliberately expensive; the test suite hashes/verifies
-// against throwaway data many times per run, so a cheaper cost keeps it
-// fast without weakening anything real. Never applies outside NODE_ENV=test.
-const testHashOptions = { memoryCost: 8192, timeCost: 2, parallelism: 1 };
-const hashOptions = env.NODE_ENV === "test" ? testHashOptions : undefined;
-
-/** Exposed so `src/scripts/create-admin.ts` hashes exactly the same way `login` verifies. */
-export function hashAdminPassword(password: string): Promise<string> {
-  return argon2.hash(password, hashOptions);
-}
-
-/**
- * Verifies an admin operator's credentials, stamps `lastLoginAt`, and
- * issues a fresh admin session token.
- *
- * @throws {HttpError} `401 INVALID_CREDENTIALS` for either an unknown email
- *   or a wrong password — deliberately indistinguishable, same reasoning as
- *   `auth.service.ts`'s `login`.
- */
-export async function adminLogin(input: AdminLoginInput): Promise<AdminAuthResult> {
-  try {
-    const admin = await prisma.adminUser.findUnique({ where: { email: input.email } });
-
-    if (!admin || !(await argon2.verify(admin.passwordHash, input.password))) {
-      throw new HttpError(401, ErrorCode.INVALID_CREDENTIALS, "Invalid email or password");
-    }
-
-    const updated = await prisma.adminUser.update({
-      where: { id: admin.id },
-      data: { lastLoginAt: new Date() },
-    });
-
-    const token = signAdminToken({
-      adminUserId: updated.id,
-      tokenVersion: updated.tokenVersion,
-    });
-    return { admin: toSafeAdmin(updated), token };
-  } catch (err) {
-    // Rethrown as-is — `wrapAsyncHandler`/the error middleware handles it,
-    // this service layer just isn't allowed a bare `await` per the repo's
-    // async/try-catch convention.
-    throw err;
-  }
-}

apps/api/src/modules/admin/admin-catalog.routes.ts

@@ -1,80 +0,0 @@
-import { wrapAsyncHandler } from "@batch-cooking/express-tools";
-import {
-  listPlaceholdersQuerySchema,
-  listTechStepPlaceholdersQuerySchema,
-  markPlaceholdersReviewedSchema,
-  markTechStepPlaceholdersReviewedSchema,
-} from "@batch-cooking/shared";
-import { Router } from "express";
-import { requireAdmin } from "../../middlewares/require-admin.js";
-import {
-  listPlaceholderGroups,
-  markPlaceholdersReviewed,
-  pruneOrphanPlaceholders,
-} from "./admin-catalog.service.js";
-import {
-  listTechStepPlaceholders,
-  markTechStepPlaceholdersReviewed,
-} from "./admin-tech-step-catalog.service.js";
-
-/**
- * Router mounted at `/admin/api/catalog` (via `admin.routes.ts`) — every route
- * behind {@link requireAdmin}. Surfaces the off-catalog "placeholders" users
- * typed when the seeded catalog fell short — free-text ingredients on a
- * recipe line, and free-text techniques while correcting a step (issue #130)
- * — so a maintainer can see what's missing and mark gaps as handled.
- */
-export const adminCatalogRouter = Router();
-
-adminCatalogRouter.get(
-  "/placeholders",
-  requireAdmin,
-  wrapAsyncHandler(async (req, res) => {
-    res.status(200).json(await listPlaceholderGroups(listPlaceholdersQuerySchema.parse(req.query)));
-  }),
-);
-
-adminCatalogRouter.patch(
-  "/placeholders/mark-reviewed",
-  requireAdmin,
-  wrapAsyncHandler(async (req, res) => {
-    res
-      .status(200)
-      .json(await markPlaceholdersReviewed(markPlaceholdersReviewedSchema.parse(req.body)));
-  }),
-);
-
-/** Deletes placeholder rows no recipe references any more — see {@link pruneOrphanPlaceholders}. */
-adminCatalogRouter.post(
-  "/placeholders/prune-orphans",
-  requireAdmin,
-  wrapAsyncHandler(async (_req, res) => {
-    res.status(200).json(await pruneOrphanPlaceholders());
-  }),
-);
-
-// --- Missing techniques (issue #130) --------------------------------------
-
-adminCatalogRouter.get(
-  "/tech-step-placeholders",
-  requireAdmin,
-  wrapAsyncHandler(async (req, res) => {
-    res
-      .status(200)
-      .json(await listTechStepPlaceholders(listTechStepPlaceholdersQuerySchema.parse(req.query)));
-  }),
-);
-
-adminCatalogRouter.patch(
-  "/tech-step-placeholders/mark-reviewed",
-  requireAdmin,
-  wrapAsyncHandler(async (req, res) => {
-    res
-      .status(200)
-      .json(
-        await markTechStepPlaceholdersReviewed(
-          markTechStepPlaceholdersReviewedSchema.parse(req.body),
-        ),
-      );
-  }),
-);

apps/api/src/modules/admin/admin-catalog.service.ts

@@ -1,156 +0,0 @@
-import type {
-  CatalogPlaceholderGroupView,
-  ListPlaceholdersQuery,
-  MarkPlaceholdersReviewedInput,
-  PruneOrphansResultView,
-} from "@batch-cooking/shared";
-import { prisma } from "../../db/prisma.js";
-
-/**
- * Grouping key for two placeholder spellings that mean the same missing
- * ingredient — lower-cased, accent-stripped, punctuation-neutralised,
- * whitespace-collapsed. "Piment d'Espelette", "piment d espelette" and
- * "PIMENT  D'ESPELETTE" all normalise to `"piment d espelette"`, so the
- * admin view shows one gap, not three. Pure (no DB) — unit-tested on its
- * own, same split convention as `matchXxx()` vs `loadXxx()` elsewhere.
- */
-export function normalizePlaceholderName(raw: string): string {
-  return raw
-    .normalize("NFD")
-    .replace(/\p{Diacritic}/gu, "")
-    .toLowerCase()
-    .replace(/[^\p{Letter}\p{Number}]+/gu, " ")
-    .trim()
-    .replace(/\s+/g, " ");
-}
-
-/** Prisma `include` for the placeholder query — up to a few `RecipeIngredient` links per row, each with just enough of its recipe for the "seen in…" preview and the distinct-recipe count. */
-const placeholderInclude = {
-  recipes: {
-    take: 5,
-    include: { recipe: { select: { id: true, name: true } } },
-  },
-} as const;
-
-/**
- * Every placeholder `Ingredient` (see `Ingredient.isPlaceholder` in
- * schema.prisma), grouped by {@link normalizePlaceholderName} so a
- * maintainer reviews one row per *missing ingredient* rather than one per
- * recipe line. Ordered by recipe impact (most-requested gap first), then
- * name.
- *
- * `query.reviewed` selects which side to show: omitted / `"false"` drops
- * groups whose every row has already been triaged (`reviewedAt` set) — the
- * default working list; `"true"` keeps only those fully-triaged groups.
- */
-export async function listPlaceholderGroups(
-  query: ListPlaceholdersQuery,
-): Promise<CatalogPlaceholderGroupView[]> {
-  try {
-    const rows = await prisma.ingredient.findMany({
-      where: { isPlaceholder: true },
-      include: placeholderInclude,
-      orderBy: { createdAt: "asc" },
-    });
-
-    /** Accumulator per normalized name — mutated in the loop, shaped into the view after. */
-    interface GroupAccumulator {
-      normalizedName: string;
-      displayNames: Set<string>;
-      ingredientIds: number[];
-      recipeIds: Set<number>;
-      sampleRecipes: Map<number, string>;
-      firstSeenAt: Date | null;
-      allReviewed: boolean;
-    }
-    const groups = new Map<string, GroupAccumulator>();
-
-    for (const row of rows) {
-      const name = row.displayName ?? "";
-      const normalizedName = normalizePlaceholderName(name);
-      let group = groups.get(normalizedName);
-      if (!group) {
-        group = {
-          normalizedName,
-          displayNames: new Set(),
-          ingredientIds: [],
-          recipeIds: new Set(),
-          sampleRecipes: new Map(),
-          firstSeenAt: null,
-          allReviewed: true,
-        };
-        groups.set(normalizedName, group);
-      }
-      if (name.length > 0) group.displayNames.add(name);
-      group.ingredientIds.push(row.id);
-      for (const link of row.recipes) {
-        group.recipeIds.add(link.recipe.id);
-        if (group.sampleRecipes.size < 5) group.sampleRecipes.set(link.recipe.id, link.recipe.name);
-      }
-      if (row.createdAt && (group.firstSeenAt === null || row.createdAt < group.firstSeenAt)) {
-        group.firstSeenAt = row.createdAt;
-      }
-      if (row.reviewedAt === null) group.allReviewed = false;
-    }
-
-    // `reviewed=true` → the archive of handled gaps; anything else → the
-    // working list of gaps still to look at.
-    const wantReviewed = query.reviewed === "true";
-    return [...groups.values()]
-      .filter((group) => group.allReviewed === wantReviewed)
-      .map((group) => ({
-        normalizedName: group.normalizedName,
-        displayNames: [...group.displayNames].sort((a, b) => a.localeCompare(b, "fr")),
-        ingredientIds: group.ingredientIds,
-        recipeCount: group.recipeIds.size,
-        sampleRecipes: [...group.sampleRecipes.entries()].map(([id, name]) => ({ id, name })),
-        firstSeenAt: group.firstSeenAt?.toISOString() ?? null,
-        allReviewed: group.allReviewed,
-      }))
-      .sort(
-        (a, b) => b.recipeCount - a.recipeCount || a.normalizedName.localeCompare(b.normalizedName),
-      );
-  } catch (err) {
-    throw err; // see recipe.service.ts's equivalent catch comment
-  }
-}
-
-/**
- * Stamps `reviewedAt` on the given placeholder ids — a maintainer has seen
- * this gap (and, if it warranted it, added the real catalog entry by hand;
- * this endpoint never touches the catalog itself). Scoped to
- * `isPlaceholder: true` so a stray real id is a silent no-op, not a
- * mislabel. Returns how many rows were actually stamped.
- */
-export async function markPlaceholdersReviewed(
-  input: MarkPlaceholdersReviewedInput,
-): Promise<{ reviewed: number }> {
-  try {
-    const { count } = await prisma.ingredient.updateMany({
-      where: { id: { in: input.ingredientIds }, isPlaceholder: true },
-      data: { reviewedAt: new Date() },
-    });
-    return { reviewed: count };
-  } catch (err) {
-    throw err; // see recipe.service.ts's equivalent catch comment
-  }
-}
-
-/**
- * Deletes placeholder rows no recipe references any more — the debris left
- * when a recipe edit drops a placeholder line (the `RecipeIngredient` row
- * goes, the `Ingredient` row doesn't). A manual GC (button in the admin
- * catalog view, or `scripts/prune-orphan-placeholders.ts`) rather than a
- * cascade: a placeholder is still evidence of a catalog gap even with no
- * live recipe, so dropping it is a deliberate call, not automatic.
- */
-export async function pruneOrphanPlaceholders(): Promise<PruneOrphansResultView> {
-  try {
-    const { count } = await prisma.ingredient.deleteMany({
-      where: { isPlaceholder: true, recipes: { none: {} } },
-    });
-    return { deleted: count };
-  } catch (err) {
-    throw err; // see recipe.service.ts's equivalent catch comment
-  }
-}

apps/api/src/modules/admin/admin-contact.routes.ts

@@ -1,59 +0,0 @@
-import { HttpError } from "@batch-cooking/error-tools";
-import { wrapAsyncHandler } from "@batch-cooking/express-tools";
-import {
-  createForgejoIssueSchema,
-  ErrorCode,
-  listContactMessagesQuerySchema,
-} from "@batch-cooking/shared";
-import { Router } from "express";
-import { requireAdmin } from "../../middlewares/require-admin.js";
-import {
-  createForgejoIssueFromMessage,
-  getForgejoStatus,
-  listContactMessages,
-} from "./admin-contact.service.js";
-
-/**
- * Router mounted at `/admin/api/contact` (via `admin.routes.ts`) — behind
- * {@link requireAdmin}. Backs the `/admin/messages` page: the read-only list
- * of contact-form messages (issue #80), plus "create a Forgejo issue from
- * this message" (issue #81). Still no message-mutation routes — the message
- * itself stays read-only.
- */
-export const adminContactRouter = Router();
-
-adminContactRouter.get(
-  "/",
-  requireAdmin,
-  wrapAsyncHandler(async (req, res) => {
-    res
-      .status(200)
-      .json(await listContactMessages(listContactMessagesQuerySchema.parse(req.query)));
-  }),
-);
-
-// Static path — declared before `/:id/...` so it's never parsed as an id.
-adminContactRouter.get(
-  "/forgejo/status",
-  requireAdmin,
-  wrapAsyncHandler(async (_req, res) => {
-    res.status(200).json(getForgejoStatus());
-  }),
-);
-
-adminContactRouter.post(
-  "/:id/forgejo-issue",
-  requireAdmin,
-  wrapAsyncHandler(async (req, res) => {
-    const id = Number(req.params.id);
-    if (!Number.isInteger(id) || id <= 0) {
-      throw new HttpError(
-        400,
-        ErrorCode.VALIDATION_ERROR,
-        `Not a valid contact message id: ${req.params.id}`,
-      );
-    }
-    const input = createForgejoIssueSchema.parse(req.body);
-    res.status(200).json(await createForgejoIssueFromMessage(id, input));
-  }),
-);

apps/api/src/modules/admin/admin-contact.service.ts

@@ -1,133 +0,0 @@
-import { HttpError } from "@batch-cooking/error-tools";
-import {
-  type ContactMessageAdminView,
-  type ContactMessageType,
-  type CreateForgejoIssueInput,
-  ErrorCode,
-  type ForgejoIntegrationStatus,
-  type ListContactMessagesQuery,
-} from "@batch-cooking/shared";
-import { prisma } from "../../db/prisma.js";
-import { forgejo } from "../../lib/forgejo/forgejo.service.js";
-
-/** How many messages `listContactMessages` returns per call — the page is a triage view, not an export (same cap/rationale as `CORRECTIONS_PAGE_SIZE`). */
-const CONTACT_MESSAGES_PAGE_SIZE = 200;
-
-const contactMessageInclude = {
-  author: { select: { id: true, firstName: true, lastName: true, email: true } },
-} as const;
-
-type ContactMessageRow = Awaited<
-  ReturnType<
-    typeof prisma.contactMessage.findFirstOrThrow<{ include: typeof contactMessageInclude }>
-  >
->;
-
-/** Shapes one Prisma `ContactMessage` row (with {@link contactMessageInclude}) into its admin view. */
-function toContactMessageAdminView(row: ContactMessageRow): ContactMessageAdminView {
-  return {
-    id: row.id,
-    // Safe cast: `POST /contact` validates `type` against
-    // `CONTACT_MESSAGE_TYPES` before insert, so the column only ever holds
-    // one of those values.
-    type: row.type as ContactMessageType,
-    message: row.message,
-    pageUrl: row.pageUrl,
-    userAgent: row.userAgent,
-    appVersion: row.appVersion,
-    createdAt: row.createdAt.toISOString(),
-    // `null` when the sender's account was deleted after sending
-    // (`authorId` is `onDelete: SetNull`).
-    author: row.author,
-    forgejoIssueNumber: row.forgejoIssueNumber,
-    forgejoIssueUrl: row.forgejoIssueUrl,
-  };
-}
-
-/**
- * Every `ContactMessage` for the admin read view (`/admin/messages`, issue
- * #80) — newest first, capped at {@link CONTACT_MESSAGES_PAGE_SIZE}, with an
- * optional single-`type` filter. Read-only: this first version has no
- * triage workflow (status / assignment / notes), so there's no update
- * counterpart.
- */
-export async function listContactMessages(
-  query: ListContactMessagesQuery,
-): Promise<ContactMessageAdminView[]> {
-  try {
-    const rows = await prisma.contactMessage.findMany({
-      where: query.type ? { type: query.type } : {},
-      orderBy: { createdAt: "desc" },
-      take: CONTACT_MESSAGES_PAGE_SIZE,
-      include: contactMessageInclude,
-    });
-    return rows.map(toContactMessageAdminView);
-  } catch (err) {
-    // Rethrown as-is — see `admin-tech-steps.service.ts`'s equivalent catch.
-    throw err;
-  }
-}
-
-/** Whether the "create a Forgejo issue from a message" feature is usable (issue #81) — drives whether the admin UI shows the button. */
-export function getForgejoStatus(): ForgejoIntegrationStatus {
-  return { enabled: forgejo.isConfigured() };
-}
-
-/**
- * Creates a Forgejo issue from contact message `messageId` and records the
- * link on the row (issue #81). The `title`/`body` come from the admin's
- * pre-filled, edited modal.
- *
- * Order matters: every precondition is checked before Forgejo is called,
- * and the row is only touched *after* Forgejo succeeds — a failed call
- * leaves no partial state (no linked issue, button still shown).
- *
- * @throws {HttpError} `503 FORGEJO_NOT_CONFIGURED` (env not set),
- *   `404 CONTACT_MESSAGE_NOT_FOUND`, `409 CONTACT_MESSAGE_ALREADY_LINKED`
- *   (already has an issue), or `502 FORGEJO_REQUEST_FAILED` (the Forgejo
- *   call failed — DB untouched).
- */
-export async function createForgejoIssueFromMessage(
-  messageId: number,
-  input: CreateForgejoIssueInput,
-): Promise<ContactMessageAdminView> {
-  try {
-    if (!forgejo.isConfigured()) {
-      throw new HttpError(
-        503,
-        ErrorCode.FORGEJO_NOT_CONFIGURED,
-        "Forgejo integration is not configured",
-      );
-    }
-
-    const existing = await prisma.contactMessage.findUnique({ where: { id: messageId } });
-    if (!existing) {
-      throw new HttpError(
-        404,
-        ErrorCode.CONTACT_MESSAGE_NOT_FOUND,
-        `Contact message ${messageId} not found`,
-      );
-    }
-    if (existing.forgejoIssueNumber !== null) {
-      throw new HttpError(
-        409,
-        ErrorCode.CONTACT_MESSAGE_ALREADY_LINKED,
-        `Contact message ${messageId} already links to Forgejo issue #${existing.forgejoIssueNumber}`,
-      );
-    }
-
-    // Throws `502 FORGEJO_REQUEST_FAILED` on any failure — propagated below,
-    // before the row is touched.
-    const issue = await forgejo.createIssue({ title: input.title, body: input.body });
-
-    const updated = await prisma.contactMessage.update({
-      where: { id: messageId },
-      data: { forgejoIssueNumber: issue.number, forgejoIssueUrl: issue.htmlUrl },
-      include: contactMessageInclude,
-    });
-    return toContactMessageAdminView(updated);
-  } catch (err) {
-    // Rethrown as-is — see `admin-tech-steps.service.ts`'s equivalent catch.
-    throw err;
-  }
-}

apps/api/src/modules/admin/admin-metrics.routes.ts

@@ -1,22 +0,0 @@
-import { wrapAsyncHandler } from "@batch-cooking/express-tools";
-import { getMetricsSchema } from "@batch-cooking/shared";
-import { Router } from "express";
-import { requireAdmin } from "../../middlewares/require-admin.js";
-import { getMetrics } from "./admin-metrics.service.js";
-
-/** Router mounted at `/admin/api/metrics` (via `admin.routes.ts`) — every route behind {@link requireAdmin}. */
-export const adminMetricsRouter = Router();
-
-/**
- * Returns the admin dashboard's usage metrics — a `snapshot` of current
- * totals plus `?days=` (7–365, default 30) days of daily time series (see
- * {@link getMetrics}). Read-only; no side effects.
- */
-adminMetricsRouter.get(
-  "/",
-  requireAdmin,
-  wrapAsyncHandler(async (req, res) => {
-    const { days } = getMetricsSchema.parse(req.query);
-    res.status(200).json(await getMetrics(days));
-  }),
-);

apps/api/src/modules/admin/admin-metrics.service.ts

@@ -1,242 +0,0 @@
-import type {
-  MetricsBreakdownRow,
-  MetricsEventSeries,
-  MetricsSnapshotView,
-  MetricsTimeBucket,
-  MetricsView,
-} from "@batch-cooking/shared";
-import { prisma } from "../../db/prisma.js";
-
-/** UTC `YYYY-MM-DD` for a `Date` — the bucket key used by {@link bucketByDay}. */
-function utcDayKey(date: Date): string {
-  return date.toISOString().slice(0, 10);
-}
-
-/** Start-of-day (UTC) `Date` that is `daysAgo` days before `from`. */
-function startOfUtcDay(from: Date, daysAgo: number): Date {
-  return new Date(Date.UTC(from.getUTCFullYear(), from.getUTCMonth(), from.getUTCDate() - daysAgo));
-}
-
-/**
- * Buckets `dates` into `days` consecutive daily counts starting at `since`
- * (a start-of-UTC-day `Date`). Every day in the window is present, days
- * with no matching date carry `count: 0`. Pure/synchronous — factored out
- * so the bucketing is unit-testable without a database, same split as
- * `aggregateShoppingList`.
- */
-export function bucketByDay(dates: Date[], since: Date, days: number): MetricsTimeBucket[] {
-  const counts = new Map<string, number>();
-  for (let i = 0; i < days; i++) {
-    const day = new Date(since.getTime() + i * 86_400_000);
-    counts.set(utcDayKey(day), 0);
-  }
-  for (const date of dates) {
-    const key = utcDayKey(date);
-    const current = counts.get(key);
-    if (current !== undefined) counts.set(key, current + 1);
-  }
-  return [...counts.entries()]
-    .sort(([a], [b]) => a.localeCompare(b))
-    .map(([date, count]) => ({ date, count }));
-}
-
-/** Shapes a Prisma `groupBy ... _count` result into the frontend's `{ key, label, count }` rows, sorted by count desc. */
-function toBreakdown(
-  rows: { key: string | null; count: number }[],
-  labelFor: (key: string) => string = (key) => key,
-): MetricsBreakdownRow[] {
-  return rows
-    .map(({ key, count }) => {
-      const resolved = key ?? "unknown";
-      return { key: resolved, label: labelFor(resolved), count };
-    })
-    .sort((a, b) => b.count - a.count);
-}
-
-/** Every point-in-time `COUNT` for the KPI tiles — see {@link MetricsSnapshotView}. */
-async function getSnapshot(): Promise<MetricsSnapshotView> {
-  try {
-    const [
-      admins,
-      users,
-      households,
-      activeHouseholdGroups,
-      recipes,
-      recipesManual,
-      recipesImported,
-      recipeBySourceGroups,
-      sources,
-      plannings,
-      planningItems,
-      steps,
-      detectedTechniques,
-      favorites,
-      corrections,
-      correctionsUnconsumed,
-      correctionsRemoval,
-      trainingSuggestions,
-      suggestionStatusGroups,
-      suggestionSourceTypeGroups,
-    ] = await Promise.all([
-      prisma.adminUser.count(),
-      prisma.userProfile.count(),
-      prisma.house.count(),
-      prisma.planning.groupBy({ by: ["houseId"] }),
-      prisma.recipe.count(),
-      prisma.recipe.count({ where: { sourceId: null } }),
-      prisma.recipe.count({ where: { sourceId: { not: null } } }),
-      prisma.recipe.groupBy({
-        by: ["sourceId"],
-        where: { sourceId: { not: null } },
-        _count: { _all: true },
-      }),
-      prisma.source.findMany({ select: { id: true, key: true, name: true } }),
-      prisma.planning.count(),
-      prisma.planningItem.count(),
-      prisma.step.count(),
-      prisma.stepTechStep.count(),
-      prisma.recipeFavorite.count(),
-      prisma.stepTechStepCorrection.count(),
-      prisma.stepTechStepCorrection.count({ where: { consumedAt: null } }),
-      prisma.stepTechStepCorrection.count({ where: { correctedTechStepId: null } }),
-      prisma.techStepTrainingSuggestion.count(),
-      prisma.techStepTrainingSuggestion.groupBy({ by: ["status"], _count: { _all: true } }),
-      prisma.techStepTrainingSuggestion.groupBy({ by: ["sourceType"], _count: { _all: true } }),
-    ]);
-
-    const sourceById = new Map(sources.map((source) => [source.id, source]));
-
-    return {
-      admins,
-      users,
-      households,
-      activeHouseholds: activeHouseholdGroups.length,
-      recipes,
-      recipesManual,
-      recipesImported,
-      recipesBySource: toBreakdown(
-        recipeBySourceGroups.map((group) => ({
-          key: group.sourceId === null ? null : (sourceById.get(group.sourceId)?.key ?? null),
-          count: group._count._all,
-        })),
-        (key) => {
-          const source = sources.find((s) => s.key === key);
-          return source ? source.name : key;
-        },
-      ),
-      plannings,
-      planningItems,
-      steps,
-      detectedTechniques,
-      favorites,
-      corrections,
-      correctionsUnconsumed,
-      correctionsRemoval,
-      trainingSuggestions,
-      trainingSuggestionsByStatus: toBreakdown(
-        suggestionStatusGroups.map((group) => ({ key: group.status, count: group._count._all })),
-      ),
-      trainingSuggestionsBySourceType: toBreakdown(
-        suggestionSourceTypeGroups.map((group) => ({
-          key: group.sourceType,
-          count: group._count._all,
-        })),
-      ),
-    };
-  } catch (err) {
-    throw err; // see recipe.service.ts's equivalent catch comment
-  }
-}
-
-/**
- * Builds the admin dashboard's full metrics payload — a `snapshot` of
- * current totals plus `rangeDays` days of daily time series, derived from
- * the `createdAt` columns the `admin_metrics` migration added and from the
- * `AnalyticsEvent` table. `days` is the caller-validated `?days=` value
- * (see `getMetricsSchema`, 7–365).
- */
-export async function getMetrics(days: number): Promise<MetricsView> {
-  try {
-    const now = new Date();
-    const since = startOfUtcDay(now, days - 1);
-
-    const [
-      snapshot,
-      signups,
-      recipesCreated,
-      planningItemsAdded,
-      correctionsSubmitted,
-      trainingSuggestions,
-      eventRows,
-    ] = await Promise.all([
-      getSnapshot(),
-      prisma.userProfile.findMany({
-        where: { createdAt: { gte: since } },
-        select: { createdAt: true },
-      }),
-      prisma.recipe.findMany({ where: { createdAt: { gte: since } }, select: { createdAt: true } }),
-      prisma.planningItem.findMany({
-        where: { createdAt: { gte: since } },
-        select: { createdAt: true },
-      }),
-      prisma.stepTechStepCorrection.findMany({
-        where: { createdAt: { gte: since } },
-        select: { createdAt: true },
-      }),
-      prisma.techStepTrainingSuggestion.findMany({
-        where: { createdAt: { gte: since } },
-        select: { createdAt: true },
-      }),
-      prisma.analyticsEvent.findMany({
-        where: { createdAt: { gte: since } },
-        select: { type: true, createdAt: true },
-      }),
-    ]);
-
-    const eventsByType = new Map<string, Date[]>();
-    for (const row of eventRows) {
-      const list = eventsByType.get(row.type);
-      if (list) list.push(row.createdAt);
-      else eventsByType.set(row.type, [row.createdAt]);
-    }
-    const events: MetricsEventSeries[] = [...eventsByType.entries()]
-      .sort(([a], [b]) => a.localeCompare(b))
-      .map(([type, dates]) => ({ type, buckets: bucketByDay(dates, since, days) }));
-
-    return {
-      generatedAt: now.toISOString(),
-      rangeDays: days,
-      snapshot,
-      series: {
-        signups: bucketByDay(
-          signups.map((r) => r.createdAt),
-          since,
-          days,
-        ),
-        recipesCreated: bucketByDay(
-          recipesCreated.map((r) => r.createdAt),
-          since,
-          days,
-        ),
-        planningItemsAdded: bucketByDay(
-          planningItemsAdded.map((r) => r.createdAt),
-          since,
-          days,
-        ),
-        correctionsSubmitted: bucketByDay(
-          correctionsSubmitted.map((r) => r.createdAt),
-          since,
-          days,
-        ),
-        trainingSuggestions: bucketByDay(
-          trainingSuggestions.map((r) => r.createdAt),
-          since,
-          days,
-        ),
-      },
-      events,
-    };
-  } catch (err) {
-    throw err; // see recipe.service.ts's equivalent catch comment
-  }
-}

apps/api/src/modules/admin/admin-monitoring.service.ts

@@ -1,180 +0,0 @@
-import type { MonitoringView, ServiceHealthView, ServiceStatus } from "@batch-cooking/shared";
-import { env } from "../../config/env.js";
-import { prisma } from "../../db/prisma.js";
-
-/** How long each outbound probe (Postgres query, intent-service HTTP) is allowed to take before it counts as `down`. */
-const PROBE_TIMEOUT_MS = 2000;
-
-/**
- * Heartbeat-age thresholds for the LLM worker. Its default cron is weekly
- * (`TECH_STEP_WORKER_CRON`, `0 3 * * 0`), and it also pings on boot/tick —
- * so no ping for **8 days** means it likely missed its last scheduled fire
- * (`degraded`), and none for **3 weeks** means it's almost certainly not
- * running at all (`down`).
- */
-const WORKER_STALE_AFTER_MS = 8 * 24 * 60 * 60 * 1000;
-const WORKER_DOWN_AFTER_MS = 21 * 24 * 60 * 60 * 1000;
-
-const WORKER_KEY = "tech-step-llm-worker";
-
-function nowIso(): string {
-  return new Date().toISOString();
-}
-
-function roundMs(value: number): number {
-  return Math.round(value * 10) / 10;
-}
-
-function errMessage(err: unknown): string {
-  return err instanceof Error ? err.message : String(err);
-}
-
-/** `12500` → `"il y a 12 s"`, `90000` → `"il y a 1 min"`, `172800000` → `"il y a 2 j"`. */
-function formatAgo(ms: number): string {
-  const s = Math.round(ms / 1000);
-  if (s < 60) return `il y a ${s} s`;
-  const m = Math.round(s / 60);
-  if (m < 60) return `il y a ${m} min`;
-  const h = Math.round(m / 60);
-  if (h < 48) return `il y a ${h} h`;
-  return `il y a ${Math.round(h / 24)} j`;
-}
-
-/** `process.uptime()` seconds → `"3 h 12 min"` / `"5 min"` / `"42 s"`. */
-function formatUptime(seconds: number): string {
-  const s = Math.floor(seconds);
-  if (s < 60) return `${s} s`;
-  const m = Math.floor(s / 60);
-  if (m < 60) return `${m} min`;
-  const h = Math.floor(m / 60);
-  return `${h} h ${m % 60} min`;
-}
-
-/** `prisma.$queryRaw\`SELECT 1\`` with a bounded timeout — the DB connectivity probe. */
-async function probePostgres(): Promise<ServiceHealthView> {
-  const start = performance.now();
-  try {
-    // `$queryRaw` doesn't take an AbortSignal — bound it with a race instead.
-    await Promise.race([
-      prisma.$queryRaw`SELECT 1`,
-      new Promise((_resolve, reject) =>
-        setTimeout(() => reject(new Error("timeout")), PROBE_TIMEOUT_MS),
-      ),
-    ]);
-    return {
-      key: "postgres",
-      status: "up",
-      latencyMs: roundMs(performance.now() - start),
-      detail: null,
-      checkedAt: nowIso(),
-    };
-  } catch (err) {
-    return {
-      key: "postgres",
-      status: "down",
-      latencyMs: null,
-      detail: errMessage(err),
-      checkedAt: nowIso(),
-    };
-  }
-}
-
-/** The API itself — trivially "up" (it's answering), reported with its process uptime/memory. */
-function probeApi(): ServiceHealthView {
-  const mem = process.memoryUsage();
-  return {
-    key: "api",
-    status: "up",
-    latencyMs: 0,
-    detail: `uptime ${formatUptime(process.uptime())} · RSS ${Math.round(mem.rss / 1_000_000)} Mo`,
-    checkedAt: nowIso(),
-  };
-}
-
-/** `GET {INTENT_SERVICE_BASE_URL}/health` — no secret needed on that route (see the service's `routes/health.py`). */
-async function probeIntentService(): Promise<ServiceHealthView> {
-  const start = performance.now();
-  try {
-    const res = await fetch(`${env.INTENT_SERVICE_BASE_URL}/health`, {
-      signal: AbortSignal.timeout(PROBE_TIMEOUT_MS),
-    });
-    const latencyMs = roundMs(performance.now() - start);
-    return {
-      key: "intent-service",
-      status: res.ok ? "up" : "degraded",
-      latencyMs,
-      detail: `HTTP ${res.status}`,
-      checkedAt: nowIso(),
-    };
-  } catch (err) {
-    return {
-      key: "intent-service",
-      status: "down",
-      latencyMs: null,
-      detail: errMessage(err),
-      checkedAt: nowIso(),
-    };
-  }
-}
-
-/** Reads the LLM worker's stored `WorkerHeartbeat` (it has no HTTP surface to probe directly) and grades it by age + last job outcome. */
-async function probeWorker(): Promise<ServiceHealthView> {
-  const heartbeat = await prisma.workerHeartbeat.findUnique({ where: { workerKey: WORKER_KEY } });
-  if (!heartbeat) {
-    return {
-      key: WORKER_KEY,
-      status: "unknown",
-      latencyMs: null,
-      detail: "aucun battement reçu",
-      checkedAt: nowIso(),
-      lastRunAt: null,
-      lastResult: null,
-    };
-  }
-
-  const ageMs = Date.now() - heartbeat.lastSeenAt.getTime();
-  const lastResult = (heartbeat.lastResult ?? null) as ServiceHealthView["lastResult"];
-
-  let status: ServiceStatus = "up";
-  if (ageMs > WORKER_DOWN_AFTER_MS) status = "down";
-  else if (ageMs > WORKER_STALE_AFTER_MS || lastResult?.ok === false) status = "degraded";
-
-  return {
-    key: WORKER_KEY,
-    status,
-    latencyMs: null,
-    detail: `dernier battement ${formatAgo(ageMs)}`,
-    checkedAt: nowIso(),
-    lastRunAt: heartbeat.lastRunAt?.toISOString() ?? null,
-    lastResult,
-  };
-}
-
-/**
- * Actively probes every dependency the admin monitoring board watches —
- * Postgres, the API itself, `tech-step-intent-service` (`/health`), and the
- * LLM worker (via its stored heartbeat). Each probe is independent and
- * bounded ({@link PROBE_TIMEOUT_MS}); one being `down` never fails the
- * others or this call as a whole.
- *
- * No HTTP route calls this directly (there was one, `GET
- * /admin/api/monitoring` — removed) — `MonitoringBroadcastService`
- * (`lib/monitoring-broadcast.service.ts`) is the only caller now, on a
- * server-side timer, broadcasting the result over WebSocket instead of
- * each admin's browser polling this on its own.
- */
-export async function getMonitoring(): Promise<MonitoringView> {
-  try {
-    const [postgres, intentService, worker] = await Promise.all([
-      probePostgres(),
-      probeIntentService(),
-      probeWorker(),
-    ]);
-    return {
-      generatedAt: nowIso(),
-      services: [postgres, probeApi(), intentService, worker],
-    };
-  } catch (err) {
-    throw err; // see recipe.service.ts's equivalent catch comment
-  }
-}

apps/api/src/modules/admin/admin-tech-step-catalog.service.ts

@@ -1,87 +0,0 @@
-import type {
-  ListTechStepPlaceholdersQuery,
-  MarkTechStepPlaceholdersReviewedInput,
-  TechStepPlaceholderView,
-} from "@batch-cooking/shared";
-import { prisma } from "../../db/prisma.js";
-
-/**
- * The missing-technique review (issue #130) — the tech-step counterpart of
- * `admin-catalog.service.ts`'s off-catalog *ingredient* review. Kept a flat
- * list rather than grouping near-duplicate spellings the way that one does:
- * correcting a technique — let alone typing one the catalog is missing — is
- * rare enough that a handful of raw rows is all a maintainer ever sees here.
- */
-
-/** Prisma `include` for the placeholder query — a bounded set of the `StepTechStep` rows pointing at this technique, each resolved to just its recipe id/name for the count + "seen in…" preview. */
-const placeholderInclude = {
-  steps: {
-    take: 50,
-    include: { step: { select: { recipe: { select: { id: true, name: true } } } } },
-  },
-} as const;
-
-/**
- * Every placeholder `TechStep` (see `TechStep.isPlaceholder` in
- * schema.prisma), most-impactful first (most distinct recipes, then name).
- *
- * `query.reviewed` selects which side to show: omitted / `"false"` drops
- * rows already triaged (`reviewedAt` set) — the default working list;
- * `"true"` keeps only those.
- */
-export async function listTechStepPlaceholders(
-  query: ListTechStepPlaceholdersQuery,
-): Promise<TechStepPlaceholderView[]> {
-  try {
-    const rows = await prisma.techStep.findMany({
-      where: { isPlaceholder: true },
-      include: placeholderInclude,
-      orderBy: { createdAt: "asc" },
-    });
-
-    const wantReviewed = query.reviewed === "true";
-    return rows
-      .filter((row) => (row.reviewedAt !== null) === wantReviewed)
-      .map((row) => {
-        const recipeById = new Map<number, string>();
-        for (const link of row.steps) {
-          recipeById.set(link.step.recipe.id, link.step.recipe.name);
-        }
-        return {
-          id: row.id,
-          displayName: row.displayName ?? "",
-          createdAt: row.createdAt?.toISOString() ?? null,
-          reviewedAt: row.reviewedAt?.toISOString() ?? null,
-          recipeCount: recipeById.size,
-          sampleRecipes: [...recipeById.entries()].slice(0, 5).map(([id, name]) => ({ id, name })),
-        };
-      })
-      .sort(
-        (a, b) => b.recipeCount - a.recipeCount || a.displayName.localeCompare(b.displayName, "fr"),
-      );
-  } catch (err) {
-    throw err; // see recipe.service.ts's equivalent catch comment
-  }
-}
-
-/**
- * Stamps `reviewedAt` on the given placeholder `TechStep` ids — a
- * maintainer has seen this proposal (and, if it warranted it, promoted it
- * into `reference-seed-data.ts` + `tech-step-training-data.ts` by hand; this
- * endpoint never touches the catalog itself). Scoped to
- * `isPlaceholder: true` so a stray real id is a silent no-op. Returns how
- * many rows were actually stamped.
- */
-export async function markTechStepPlaceholdersReviewed(
-  input: MarkTechStepPlaceholdersReviewedInput,
-): Promise<{ reviewed: number }> {
-  try {
-    const { count } = await prisma.techStep.updateMany({
-      where: { id: { in: input.techStepIds }, isPlaceholder: true },
-      data: { reviewedAt: new Date() },
-    });
-    return { reviewed: count };
-  } catch (err) {
-    throw err; // see recipe.service.ts's equivalent catch comment
-  }
-}

apps/api/src/modules/admin/admin-tech-steps.routes.ts

@@ -1,80 +0,0 @@
-import { HttpError } from "@batch-cooking/error-tools";
-import { wrapAsyncHandler } from "@batch-cooking/express-tools";
-import {
-  ErrorCode,
-  listCorrectionsQuerySchema,
-  listSuggestionsQuerySchema,
-  retrainRequestSchema,
-  trainingDataSnippetQuerySchema,
-  updateTrainingSuggestionSchema,
-} from "@batch-cooking/shared";
-import { Router } from "express";
-import { requireAdmin } from "../../middlewares/require-admin.js";
-import {
-  getTrainingDataSnippet,
-  listCorrections,
-  listSuggestions,
-  runRetrain,
-  updateSuggestion,
-} from "./admin-tech-steps.service.js";
-
-/** Router mounted at `/admin/api/tech-steps` (via `admin.routes.ts`) — every route behind {@link requireAdmin}. Correction/suggestion triage + the retrain trigger. */
-export const adminTechStepsRouter = Router();
-
-adminTechStepsRouter.get(
-  "/suggestions",
-  requireAdmin,
-  wrapAsyncHandler(async (req, res) => {
-    res.status(200).json(await listSuggestions(listSuggestionsQuerySchema.parse(req.query)));
-  }),
-);
-
-adminTechStepsRouter.get(
-  "/corrections",
-  requireAdmin,
-  wrapAsyncHandler(async (req, res) => {
-    res.status(200).json(await listCorrections(listCorrectionsQuerySchema.parse(req.query)));
-  }),
-);
-
-adminTechStepsRouter.get(
-  "/training-data-snippet",
-  requireAdmin,
-  wrapAsyncHandler(async (req, res) => {
-    res
-      .status(200)
-      .json(await getTrainingDataSnippet(trainingDataSnippetQuerySchema.parse(req.query)));
-  }),
-);
-
-adminTechStepsRouter.patch(
-  "/suggestions/:id",
-  requireAdmin,
-  wrapAsyncHandler(async (req, res) => {
-    const id = Number(req.params.id);
-    if (!Number.isInteger(id) || id <= 0) {
-      throw new HttpError(
-        400,
-        ErrorCode.VALIDATION_ERROR,
-        `Not a valid suggestion id: ${req.params.id}`,
-      );
-    }
-    const input = updateTrainingSuggestionSchema.parse(req.body);
-    res.status(200).json(await updateSuggestion(id, input));
-  }),
-);
-
-/**
- * Runs the F1 regression gate then (if it passes) the full step backfill,
- * and marks the given suggestion ids — see {@link runRetrain}. Long-running
- * and process-locked: `409 RETRAIN_ALREADY_RUNNING` if one is already
- * underway.
- */
-adminTechStepsRouter.post(
-  "/retrain",
-  requireAdmin,
-  wrapAsyncHandler(async (req, res) => {
-    const input = retrainRequestSchema.parse(req.body);
-    res.status(200).json(await runRetrain(input));
-  }),
-);

apps/api/src/modules/admin/admin-tech-steps.service.ts

@@ -1,325 +0,0 @@
-import { HttpError } from "@batch-cooking/error-tools";
-import {
-  type CorrectionAdminView,
-  ErrorCode,
-  type ListCorrectionsQuery,
-  type ListSuggestionsQuery,
-  type RetrainRequestInput,
-  type RetrainResultView,
-  type TrainingDataSnippetQuery,
-  type TrainingDataSnippetView,
-  type TrainingSuggestionAdminView,
-  type TrainingSuggestionGroupView,
-  type UpdateTrainingSuggestionInput,
-} from "@batch-cooking/shared";
-import { prisma } from "../../db/prisma.js";
-import {
-  MIN_OVERALL_F1,
-  runTechStepEvalSuite,
-} from "../../lib/recipe-matching/tech-step-eval-runner.js";
-import { backfillTechSteps } from "../../scripts/backfill-tech-steps.js";
-
-/** How many raw corrections `listCorrections` returns per call — the browser is a triage view, not an export. */
-const CORRECTIONS_PAGE_SIZE = 200;
-
-const suggestionInclude = {
-  techStep: { select: { key: true } },
-  sourceCorrection: {
-    include: {
-      step: { select: { id: true, recipeId: true, description: true } },
-      previousTechStep: { select: { key: true } },
-      correctedTechStep: { select: { key: true } },
-    },
-  },
-} as const;
-
-type SuggestionRow = Awaited<
-  ReturnType<
-    typeof prisma.techStepTrainingSuggestion.findFirstOrThrow<{ include: typeof suggestionInclude }>
-  >
->;
-
-/** Shapes one Prisma suggestion row (with {@link suggestionInclude}) into its admin view. */
-function toSuggestionView(row: SuggestionRow): TrainingSuggestionAdminView {
-  const correction = row.sourceCorrection;
-  return {
-    id: row.id,
-    techStepKey: row.techStep.key,
-    locale: row.locale,
-    suggestedSynonyms: row.suggestedSynonyms,
-    suggestedUtterances: row.suggestedUtterances,
-    sourceType: row.sourceType,
-    status: row.status,
-    createdAt: row.createdAt.toISOString(),
-    sourceCorrection: correction
-      ? {
-          id: correction.id,
-          recipeId: correction.step.recipeId,
-          stepId: correction.step.id,
-          clauseText: correction.step.description.slice(correction.start, correction.end),
-          previousTechStepKey: correction.previousTechStep?.key ?? null,
-          correctedTechStepKey: correction.correctedTechStep?.key ?? null,
-        }
-      : null,
-  };
-}
-
-/**
- * Every `TechStepTrainingSuggestion` matching the (all-optional) filters,
- * grouped by technique key — same "one block per technique" organisation
- * as `list-pending-training-suggestions.ts`'s CLI report, which this UI
- * replaces.
- */
-export async function listSuggestions(
-  query: ListSuggestionsQuery,
-): Promise<TrainingSuggestionGroupView[]> {
-  try {
-    const rows = await prisma.techStepTrainingSuggestion.findMany({
-      where: {
-        ...(query.status ? { status: query.status } : {}),
-        ...(query.sourceType ? { sourceType: query.sourceType } : {}),
-        ...(query.locale ? { locale: query.locale } : {}),
-        ...(query.techStepKey ? { techStep: { key: query.techStepKey } } : {}),
-      },
-      orderBy: [{ techStepId: "asc" }, { createdAt: "asc" }],
-      include: suggestionInclude,
-    });
-
-    const byKey = new Map<string, TrainingSuggestionAdminView[]>();
-    for (const row of rows) {
-      const view = toSuggestionView(row);
-      const group = byKey.get(view.techStepKey);
-      if (group) group.push(view);
-      else byKey.set(view.techStepKey, [view]);
-    }
-    return [...byKey.entries()]
-      .sort(([a], [b]) => a.localeCompare(b))
-      .map(([techStepKey, suggestions]) => ({ techStepKey, suggestions }));
-  } catch (err) {
-    throw err; // see recipe.service.ts's equivalent catch comment
-  }
-}
-
-/**
- * Raw `StepTechStepCorrection`s for the admin browser — newest first,
- * capped at {@link CORRECTIONS_PAGE_SIZE}. Unlike the worker's own
- * `getPendingCorrections`, this **includes** the `correctedTechStepId IS NULL`
- * removals ("no technique here") that never become suggestions and are
- * otherwise invisible.
- */
-export async function listCorrections(query: ListCorrectionsQuery): Promise<CorrectionAdminView[]> {
-  try {
-    const consumedFilter =
-      query.consumed === "true"
-        ? { consumedAt: { not: null } }
-        : query.consumed === "false"
-          ? { consumedAt: null }
-          : {};
-    const correctedFilter =
-      query.hasCorrectedTechStep === "true"
-        ? { correctedTechStepId: { not: null } }
-        : query.hasCorrectedTechStep === "false"
-          ? { correctedTechStepId: null }
-          : {};
-
-    const rows = await prisma.stepTechStepCorrection.findMany({
-      where: { ...consumedFilter, ...correctedFilter },
-      orderBy: { createdAt: "desc" },
-      take: CORRECTIONS_PAGE_SIZE,
-      include: {
-        step: { select: { id: true, recipeId: true, description: true } },
-        previousTechStep: { select: { key: true } },
-        correctedTechStep: { select: { key: true } },
-      },
-    });
-
-    return rows.map((row) => ({
-      id: row.id,
-      recipeId: row.step.recipeId,
-      stepId: row.step.id,
-      stepDescription: row.step.description,
-      clauseText: row.step.description.slice(row.start, row.end),
-      start: row.start,
-      end: row.end,
-      previousTechStepKey: row.previousTechStep?.key ?? null,
-      correctedTechStepKey: row.correctedTechStep?.key ?? null,
-      createdAt: row.createdAt.toISOString(),
-      consumedAt: row.consumedAt?.toISOString() ?? null,
-    }));
-  } catch (err) {
-    throw err;
-  }
-}
-
-/**
- * Curates one suggestion — edit its proposed synonyms/utterances and/or
- * flip its `status`. At least one field must be present.
- *
- * @throws {HttpError} `400 VALIDATION_ERROR` if the body is empty.
- * @throws {HttpError} `404 NOT_FOUND` if `id` matches no suggestion.
- */
-export async function updateSuggestion(
-  id: number,
-  input: UpdateTrainingSuggestionInput,
-): Promise<TrainingSuggestionAdminView> {
-  try {
-    if (
-      input.status === undefined &&
-      input.suggestedSynonyms === undefined &&
-      input.suggestedUtterances === undefined
-    ) {
-      throw new HttpError(400, ErrorCode.VALIDATION_ERROR, "Nothing to update");
-    }
-
-    const existing = await prisma.techStepTrainingSuggestion.findUnique({ where: { id } });
-    if (!existing) {
-      throw new HttpError(404, ErrorCode.NOT_FOUND, `Training suggestion ${id} not found`);
-    }
-
-    const updated = await prisma.techStepTrainingSuggestion.update({
-      where: { id },
-      data: {
-        ...(input.status !== undefined ? { status: input.status } : {}),
-        ...(input.suggestedSynonyms !== undefined
-          ? { suggestedSynonyms: input.suggestedSynonyms }
-          : {}),
-        ...(input.suggestedUtterances !== undefined
-          ? { suggestedUtterances: input.suggestedUtterances }
-          : {}),
-      },
-      include: suggestionInclude,
-    });
-    return toSuggestionView(updated);
-  } catch (err) {
-    throw err;
-  }
-}
-
-/** Deduplicates while preserving first-seen order — for pooling synonyms/utterances across suggestions. */
-function dedupe(values: string[]): string[] {
-  return [...new Set(values.map((value) => value.trim()).filter((value) => value.length > 0))];
-}
-
-/** Indents each entry as a Python list literal line (4-space, trailing comma) — the shape `training_data.py`'s blocks use. */
-function pythonListBody(entries: string[]): string {
-  return entries.map((entry) => `    ${JSON.stringify(entry)},`).join("\n");
-}
-
-/**
- * Aggregates the synonyms/utterances of every suggestion matching
- * `techStepKey` + `locale` + `status` into a ready-to-paste
- * `training_data.py` block. **Read-only** — editing that Python file and
- * restarting the intent-service stay a manual maintainer step.
- */
-export async function getTrainingDataSnippet(
-  query: TrainingDataSnippetQuery,
-): Promise<TrainingDataSnippetView> {
-  try {
-    const rows = await prisma.techStepTrainingSuggestion.findMany({
-      where: {
-        locale: query.locale,
-        status: query.status,
-        techStep: { key: query.techStepKey },
-      },
-      select: { suggestedSynonyms: true, suggestedUtterances: true },
-    });
-
-    const synonyms = dedupe(rows.flatMap((row) => row.suggestedSynonyms));
-    const utterances = dedupe(rows.flatMap((row) => row.suggestedUtterances));
-
-    const snippet = [
-      `# ${query.techStepKey} (${query.locale}) — ${rows.length} suggestion(s) "${query.status}"`,
-      `"synonyms": [`,
-      pythonListBody(synonyms),
-      `],`,
-      `"utterances": [`,
-      pythonListBody(utterances),
-      `],`,
-    ]
-      .filter((line) => line.length > 0)
-      .join("\n");
-
-    return {
-      techStepKey: query.techStepKey,
-      locale: query.locale,
-      status: query.status,
-      suggestionCount: rows.length,
-      synonyms,
-      utterances,
-      snippet,
-    };
-  } catch (err) {
-    throw err;
-  }
-}
-
-/** Process-wide lock — the F1 gate + full backfill is heavy and must never run twice concurrently. */
-let retrainInProgress = false;
-
-/**
- * Runs the training-corpus regression gate then, if it passes, backfills
- * every step and marks the given suggestion ids — the same three steps as
- * `scripts/retrain-tech-steps.ts`, callable from the admin UI.
- *
- * **Only meaningful after** a maintainer has hand-edited
- * `services/tech-step-intent-service/intent_service/training_data.py` **and
- * restarted that service** (it trains once at boot) — this endpoint can do
- * neither, and the admin UI states that prominently.
- *
- * A failed gate returns `gatePassed: false` with no backfill / no marking
- * (HTTP 200 — it's an expected outcome to show the operator, not an error).
- *
- * @throws {HttpError} `409 RETRAIN_ALREADY_RUNNING` if a retrain is already in flight.
- */
-export async function runRetrain(input: RetrainRequestInput): Promise<RetrainResultView> {
-  if (retrainInProgress) {
-    throw new HttpError(
-      409,
-      ErrorCode.RETRAIN_ALREADY_RUNNING,
-      "A retrain (F1 gate + backfill) is already running",
-    );
-  }
-  retrainInProgress = true;
-  try {
-    const { overall } = await runTechStepEvalSuite();
-    const gatePassed = overall.f1 >= MIN_OVERALL_F1;
-
-    let backfilled: RetrainResultView["backfilled"] = null;
-    const marked = { applied: 0, rejected: 0 };
-
-    if (gatePassed) {
-      backfilled = await backfillTechSteps();
-
-      const appliedIds = input.appliedIds ?? [];
-      const rejectedIds = input.rejectedIds ?? [];
-      if (appliedIds.length > 0) {
-        const { count } = await prisma.techStepTrainingSuggestion.updateMany({
-          where: { id: { in: appliedIds } },
-          data: { status: "applied" },
-        });
-        marked.applied = count;
-      }
-      if (rejectedIds.length > 0) {
-        const { count } = await prisma.techStepTrainingSuggestion.updateMany({
-          where: { id: { in: rejectedIds } },
-          data: { status: "rejected" },
-        });
-        marked.rejected = count;
-      }
-    }
-
-    return {
-      f1: overall.f1,
-      precision: overall.precision,
-      recall: overall.recall,
-      minF1: MIN_OVERALL_F1,
-      gatePassed,
-      backfilled,
-      marked,
-    };
-  } catch (err) {
-    throw err; // see recipe.service.ts's equivalent catch comment
-  } finally {
-    retrainInProgress = false;
-  }
-}

apps/api/src/modules/admin/admin-tours.routes.ts

@@ -1,80 +0,0 @@
-import { HttpError } from "@batch-cooking/error-tools";
-import { wrapAsyncHandler } from "@batch-cooking/express-tools";
-import {
-  createTourScenarioSchema,
-  ErrorCode,
-  updateTourScenarioSchema,
-} from "@batch-cooking/shared";
-import { Router } from "express";
-import { requireAdmin } from "../../middlewares/require-admin.js";
-import {
-  createTourScenario,
-  deleteTourScenario,
-  listTourScenarios,
-  listTourTargets,
-  updateTourScenario,
-} from "./admin-tours.service.js";
-
-/**
- * Router mounted at `/admin/api/tours` (via `admin.routes.ts`) — every
- * route behind {@link requireAdmin}. Full CRUD over the guided-tour
- * scenarios the public `GET /reference/tours` serves to the web tour
- * engine (issues #42/#44).
- */
-export const adminToursRouter = Router();
-
-/** Express types a numeric route param `string | undefined`; parse + validate here. */
-function parseId(value: string | undefined): number {
-  const id = Number(value);
-  if (!Number.isInteger(id) || id <= 0) {
-    throw new HttpError(400, ErrorCode.VALIDATION_ERROR, `Invalid tour scenario id "${value}"`);
-  }
-  return id;
-}
-
-adminToursRouter.get(
-  "/",
-  requireAdmin,
-  wrapAsyncHandler(async (_req, res) => {
-    res.status(200).json(await listTourScenarios());
-  }),
-);
-
-/** The catalogue of valid highlight targets — for the editor's per-step target picker. */
-adminToursRouter.get(
-  "/targets",
-  requireAdmin,
-  wrapAsyncHandler(async (_req, res) => {
-    res.status(200).json(await listTourTargets());
-  }),
-);
-
-adminToursRouter.post(
-  "/",
-  requireAdmin,
-  wrapAsyncHandler(async (req, res) => {
-    const scenario = await createTourScenario(createTourScenarioSchema.parse(req.body));
-    res.status(201).json(scenario);
-  }),
-);
-
-adminToursRouter.patch(
-  "/:id",
-  requireAdmin,
-  wrapAsyncHandler(async (req, res) => {
-    const scenario = await updateTourScenario(
-      parseId(req.params.id),
-      updateTourScenarioSchema.parse(req.body),
-    );
-    res.status(200).json(scenario);
-  }),
-);
-
-adminToursRouter.delete(
-  "/:id",
-  requireAdmin,
-  wrapAsyncHandler(async (req, res) => {
-    await deleteTourScenario(parseId(req.params.id));
-    res.status(204).end();
-  }),
-);

apps/api/src/modules/admin/admin-tours.service.ts

@@ -1,175 +0,0 @@
-import { HttpError } from "@batch-cooking/error-tools";
-import {
-  type AdminTourScenarioView,
-  type CreateTourScenarioInput,
-  ErrorCode,
-  type TourTargetView,
-  type UpdateTourScenarioInput,
-} from "@batch-cooking/shared";
-import { Prisma } from "@prisma/client";
-import { prisma } from "../../db/prisma.js";
-
-/** Shapes one Prisma `TourScenario` (with its steps) into the admin view. */
-function toAdminView(scenario: {
-  id: number;
-  key: string;
-  name: string;
-  enabled: boolean;
-  steps: Array<{
-    order: number;
-    route: string | null;
-    targetKey: string;
-    title: string;
-    content: string;
-  }>;
-}): AdminTourScenarioView {
-  return {
-    id: scenario.id,
-    key: scenario.key,
-    name: scenario.name,
-    enabled: scenario.enabled,
-    steps: scenario.steps
-      .slice()
-      .sort((a, b) => a.order - b.order)
-      .map((step) => ({
-        order: step.order,
-        route: step.route,
-        targetKey: step.targetKey,
-        title: step.title,
-        content: step.content,
-      })),
-  };
-}
-
-/** Every tour scenario — enabled *and* disabled — with its ordered steps. */
-export async function listTourScenarios(): Promise<AdminTourScenarioView[]> {
-  try {
-    const scenarios = await prisma.tourScenario.findMany({
-      orderBy: { key: "asc" },
-      include: { steps: { orderBy: { order: "asc" } } },
-    });
-    return scenarios.map(toAdminView);
-  } catch (err) {
-    throw err; // see the repo's service-layer try/catch convention
-  }
-}
-
-/** The catalogue of valid highlight targets, for the editor's target picker. */
-export async function listTourTargets(): Promise<TourTargetView[]> {
-  try {
-    return await prisma.tourTarget.findMany({ orderBy: { key: "asc" } });
-  } catch (err) {
-    throw err;
-  }
-}
-
-/**
- * Creates an empty scenario (no steps yet — the editor adds them via
- * {@link updateTourScenario}).
- *
- * @throws {HttpError} `409 TOUR_KEY_ALREADY_IN_USE` if `key` is taken.
- */
-export async function createTourScenario(
-  input: CreateTourScenarioInput,
-): Promise<AdminTourScenarioView> {
-  try {
-    const scenario = await prisma.tourScenario.create({
-      data: { key: input.key, name: input.name },
-      include: { steps: true },
-    });
-    return toAdminView(scenario);
-  } catch (err) {
-    if (err instanceof Prisma.PrismaClientKnownRequestError && err.code === "P2002") {
-      throw new HttpError(
-        409,
-        ErrorCode.TOUR_KEY_ALREADY_IN_USE,
-        `A tour scenario with key "${input.key}" already exists`,
-      );
-    }
-    throw err;
-  }
-}
-
-/**
- * Updates a scenario's `name`/`enabled` and **replaces its entire step
- * list** (delete-all then recreate with `order` = array index) — the same
- * block-replace `updateRecipe` uses for a recipe's steps, not a partial
- * patch. `key` is immutable.
- *
- * @throws {HttpError} `404 TOUR_NOT_FOUND` if `id` matches no scenario.
- * @throws {HttpError} `404 TOUR_TARGET_NOT_FOUND` if a step's `targetKey`
- *   isn't a seeded `TourTarget`.
- */
-export async function updateTourScenario(
-  id: number,
-  input: UpdateTourScenarioInput,
-): Promise<AdminTourScenarioView> {
-  try {
-    const existing = await prisma.tourScenario.findUnique({ where: { id } });
-    if (!existing) {
-      throw new HttpError(404, ErrorCode.TOUR_NOT_FOUND, `No tour scenario with id ${id}`);
-    }
-
-    const targetKeys = [...new Set(input.steps.map((step) => step.targetKey))];
-    if (targetKeys.length > 0) {
-      const known = await prisma.tourTarget.findMany({
-        where: { key: { in: targetKeys } },
-        select: { key: true },
-      });
-      const knownKeys = new Set(known.map((target) => target.key));
-      const unknown = targetKeys.find((key) => !knownKeys.has(key));
-      if (unknown !== undefined) {
-        throw new HttpError(
-          404,
-          ErrorCode.TOUR_TARGET_NOT_FOUND,
-          `No tour target with key "${unknown}"`,
-        );
-      }
-    }
-
-    const [, , scenario] = await prisma.$transaction([
-      prisma.tourScenario.update({
-        where: { id },
-        data: { name: input.name, enabled: input.enabled },
-      }),
-      prisma.tourScenarioStep.deleteMany({ where: { scenarioId: id } }),
-      prisma.tourScenario.update({
-        where: { id },
-        data: {
-          steps: {
-            create: input.steps.map((step, index) => ({
-              order: index,
-              route: step.route,
-              targetKey: step.targetKey,
-              title: step.title,
-              content: step.content,
-            })),
-          },
-        },
-        include: { steps: { orderBy: { order: "asc" } } },
-      }),
-    ]);
-    return toAdminView(scenario);
-  } catch (err) {
-    throw err;
-  }
-}
-
-/**
- * Deletes a scenario. Its steps and every user's `TourProgress` row for it
- * cascade away (a scenario that no longer exists has no "seen" state worth
- * keeping).
- *
- * @throws {HttpError} `404 TOUR_NOT_FOUND` if `id` matches no scenario.
- */
-export async function deleteTourScenario(id: number): Promise<void> {
-  try {
-    const existing = await prisma.tourScenario.findUnique({ where: { id } });
-    if (!existing) {
-      throw new HttpError(404, ErrorCode.TOUR_NOT_FOUND, `No tour scenario with id ${id}`);
-    }
-    await prisma.tourScenario.delete({ where: { id } });
-  } catch (err) {
-    throw err;
-  }
-}

apps/api/src/modules/admin/admin-users.routes.ts

@@ -1,31 +0,0 @@
-import { wrapAsyncHandler } from "@batch-cooking/express-tools";
-import { adminCreateUserSchema } from "@batch-cooking/shared";
-import { Router } from "express";
-import { requireAdmin } from "../../middlewares/require-admin.js";
-import { createUserProfile, listUsers } from "./admin-users.service.js";
-
-/**
- * Router mounted at `/admin/api/users` (via `admin.routes.ts`) — every route
- * behind {@link requireAdmin}. Backs the `/admin/utilisateurs` page: a
- * read-only list of end-user accounts and a "create an account by hand"
- * form. The server generates a one-time temporary password on create and
- * returns it in the response (see `admin-users.service.ts`).
- */
-export const adminUsersRouter = Router();
-
-adminUsersRouter.get(
-  "/",
-  requireAdmin,
-  wrapAsyncHandler(async (_req, res) => {
-    res.status(200).json(await listUsers());
-  }),
-);
-
-adminUsersRouter.post(
-  "/",
-  requireAdmin,
-  wrapAsyncHandler(async (req, res) => {
-    const input = adminCreateUserSchema.parse(req.body);
-    res.status(201).json(await createUserProfile(input));
-  }),
-);

apps/api/src/modules/admin/admin-users.service.ts

@@ -1,145 +0,0 @@
-import { randomInt } from "node:crypto";
-import { HttpError } from "@batch-cooking/error-tools";
-import {
-  type AdminCreateUserInput,
-  type AdminUserCreatedView,
-  type AdminUserListItemView,
-  ErrorCode,
-} from "@batch-cooking/shared";
-import argon2 from "argon2";
-import { env } from "../../config/env.js";
-import { prisma } from "../../db/prisma.js";
-import { analytics } from "../../lib/analytics.service.js";
-
-/**
- * How many accounts `listUsers` returns per call. Like `CONTACT_MESSAGES_PAGE_SIZE`
- * this is a triage view, not an export — the admin creates/looks up a handful
- * of accounts, it never needs the whole table paginated.
- */
-const USERS_PAGE_SIZE = 200;
-
-// Same reasoning as `admin-auth.service.ts`'s / `auth.service.ts`'s `hashOptions`:
-// argon2's real defaults are deliberately expensive; the test suite hashes
-// against throwaway data many times per run, so a cheaper cost keeps it fast
-// without weakening anything real. Never applies outside NODE_ENV=test.
-const testHashOptions = { memoryCost: 8192, timeCost: 2, parallelism: 1 };
-const hashOptions = env.NODE_ENV === "test" ? testHashOptions : undefined;
-
-/**
- * Charset for {@link generateTemporaryPassword} — upper/lower letters + digits,
- * minus the visually ambiguous ones (`0`/`O`/`1`/`l`/`I`), same spirit as
- * `house.service.ts`'s `INVITE_CODE_CHARS`: this string is read off one screen
- * and typed into another (or pasted, but not always).
- */
-const TEMP_PASSWORD_CHARS = "ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnpqrstuvwxyz23456789";
-
-/** Length of a generated temporary password — comfortably above `signupSchema`'s 8-char floor. */
-const TEMP_PASSWORD_LENGTH = 16;
-
-/**
- * A fresh random temporary password for an admin-created account. Uses
- * `node:crypto`'s `randomInt` (not `Math.random`) exactly like
- * `generateInviteCode()` — this value guards a real account until its owner
- * changes it. Returned to the operator once and never stored in plain text.
- */
-function generateTemporaryPassword(): string {
-  let password = "";
-  for (let i = 0; i < TEMP_PASSWORD_LENGTH; i++) {
-    password += TEMP_PASSWORD_CHARS[randomInt(TEMP_PASSWORD_CHARS.length)];
-  }
-  return password;
-}
-
-/** A `UserProfile` row with its household name joined in — the shape {@link toListItem} maps from. */
-type UserRow = Awaited<
-  ReturnType<
-    typeof prisma.userProfile.findFirstOrThrow<{
-      include: { house: { select: { name: true } } };
-    }>
-  >
->;
-
-/** Shapes one Prisma `UserProfile` row (with its `house` name) into the admin list view — drops `passwordHash`/`tokenVersion`, resolves the household name. */
-function toListItem(row: UserRow): AdminUserListItemView {
-  return {
-    id: row.id,
-    firstName: row.firstName,
-    lastName: row.lastName,
-    email: row.email,
-    householdName: row.house?.name ?? null,
-    createdAt: row.createdAt.toISOString(),
-  };
-}
-
-/**
- * Every end-user account for the admin `/admin/utilisateurs` list — newest
- * first, capped at {@link USERS_PAGE_SIZE}. Read-only: this first version has
- * no edit/disable/delete (deleting an account is irreversible and stays a
- * deliberate self-service action in `AccountSettingsPage`).
- */
-export async function listUsers(): Promise<AdminUserListItemView[]> {
-  try {
-    const rows = await prisma.userProfile.findMany({
-      // `id` as a tiebreaker so the order is total even if two accounts share
-      // a `createdAt` (bulk-provisioned in the same tick) — `id` ascends with
-      // `createdAt` anyway.
-      orderBy: [{ createdAt: "desc" }, { id: "desc" }],
-      take: USERS_PAGE_SIZE,
-      include: { house: { select: { name: true } } },
-    });
-    return rows.map(toListItem);
-  } catch (err) {
-    // Rethrown as-is — `wrapAsyncHandler`/the error middleware handles it,
-    // this layer just isn't allowed a bare `await`. Same as `admin-contact.service.ts`.
-    throw err;
-  }
-}
-
-/**
- * Provisions a new end-user account by hand and returns it together with the
- * one-time temporary password the caller must relay to the user. Mirrors
- * `auth.service.ts`'s `signup` for the parts that matter (email-uniqueness
- * check, argon2 hash, `UserProfile` row with `houseId`/`dietId` left `null`)
- * but issues **no session token** — the operator isn't logging in as this
- * user — and generates the password instead of accepting one.
- *
- * @throws {HttpError} `409 EMAIL_ALREADY_IN_USE` if the email is already taken.
- */
-export async function createUserProfile(
-  input: AdminCreateUserInput,
-): Promise<AdminUserCreatedView> {
-  try {
-    const existing = await prisma.userProfile.findUnique({ where: { email: input.email } });
-    if (existing) {
-      throw new HttpError(409, ErrorCode.EMAIL_ALREADY_IN_USE, "Email already in use");
-    }
-
-    const temporaryPassword = generateTemporaryPassword();
-    const passwordHash = await argon2.hash(temporaryPassword, hashOptions);
-
-    const profile = await prisma.userProfile.create({
-      // No household/diet here, same as `signup` — the user picks those in the
-      // onboarding wizard after their first login.
-      data: {
-        firstName: input.firstName,
-        lastName: input.lastName,
-        email: input.email,
-        passwordHash,
-      },
-      include: { house: { select: { name: true } } },
-    });
-
-    // Fire-and-forget, one line, no migration (see `analytics.service.ts`). A
-    // distinct type from `user.signup` so the dashboard can tell hand-provisioned
-    // accounts apart; `actorType: "system"` because the actor is an operator, not
-    // the new user (and `AnalyticsEvent.actorId` only ever means a `UserProfile.id`).
-    analytics.recordEvent("admin.user_created", {
-      actorType: "system",
-      context: { userId: profile.id },
-    });
-
-    return { user: toListItem(profile), temporaryPassword };
-  } catch (err) {
-    throw err; // see listUsers()'s catch comment
-  }
-}

apps/api/src/modules/admin/admin.routes.ts

@@ -1,32 +0,0 @@
-import { Router } from "express";
-import { adminAuthRouter } from "./admin-auth.routes.js";
-import { adminCatalogRouter } from "./admin-catalog.routes.js";
-import { adminContactRouter } from "./admin-contact.routes.js";
-import { adminMetricsRouter } from "./admin-metrics.routes.js";
-import { adminTechStepsRouter } from "./admin-tech-steps.routes.js";
-import { adminToursRouter } from "./admin-tours.routes.js";
-import { adminUsersRouter } from "./admin-users.routes.js";
-
-/**
- * Aggregator for the admin application's API surface, mounted at
- * `/admin/api` in `app.ts` (not bare `/admin` — see that mount point's own
- * comment for why: it would collide with apps/web's `/admin/*` page
- * routes). Every sub-router here backs one of those pages —
- * `/admin/api/auth` is public (login), everything added later
- * (`/admin/api/metrics`, `/admin/api/tech-steps/*`, `/admin/api/catalog/*`)
- * sits behind `requireAdmin` (`middlewares/require-admin.ts`).
- *
- * Monitoring has **no** REST route here on purpose — it's pushed over
- * WebSocket instead (`lib/monitoring-broadcast.service.ts`, wired in
- * `server.ts`), not requested per-page-load. See that service's doc
- * comment for the full mechanism.
- */
-export const adminRouter = Router();
-
-adminRouter.use("/auth", adminAuthRouter);
-adminRouter.use("/metrics", adminMetricsRouter);
-adminRouter.use("/tech-steps", adminTechStepsRouter);
-adminRouter.use("/catalog", adminCatalogRouter);
-adminRouter.use("/tours", adminToursRouter);
-adminRouter.use("/contact", adminContactRouter);
-adminRouter.use("/users", adminUsersRouter);

apps/api/src/modules/auth/auth.routes.ts

@@ -1,10 +1,5 @@
 import { wrapAsyncHandler } from "@batch-cooking/express-tools";
-import {
-  type AuthResponse,
-  deleteAccountSchema,
-  loginSchema,
-  signupSchema,
-} from "@batch-cooking/shared";
+import { deleteAccountSchema, loginSchema, signupSchema } from "@batch-cooking/shared";
 import type { CookieOptions, Response } from "express";
 import { Router } from "express";
 import { env } from "../../config/env.js";
@@ -48,11 +43,7 @@ authRouter.post(
     const input = signupSchema.parse(req.body);
     const { profile, token } = await signup(input);
     res.cookie(env.AUTH_COOKIE_NAME, token, cookieOptions);
-    // Token is echoed in the body too, not just the cookie — see
-    // `AuthResponse` (packages/shared) for why (Capacitor WebView origin
-    // can't receive a SameSite cookie). Purely additive: every existing
-    // profile field stays exactly where it was.
-    res.status(201).json({ ...profile, token } satisfies AuthResponse);
+    res.status(201).json(profile);
   }),
 );
 
@@ -63,7 +54,7 @@ authRouter.post(
     const input = loginSchema.parse(req.body);
     const { profile, token } = await login(input);
     res.cookie(env.AUTH_COOKIE_NAME, token, cookieOptions);
-    res.status(200).json({ ...profile, token } satisfies AuthResponse);
+    res.status(200).json(profile);
   }),
 );
 

apps/api/src/modules/auth/auth.service.ts

@@ -8,7 +8,6 @@ import {
 import argon2 from "argon2";
 import { env } from "../../config/env.js";
 import { prisma } from "../../db/prisma.js";
-import { analytics } from "../../lib/analytics.service.js";
 import { signAuthToken } from "../../lib/jwt.js";
 import { toSafeProfile } from "../../lib/safe-profile.js";
 import { leaveCurrentHouse } from "../house/house.service.js";
@@ -59,8 +58,6 @@ export async function signup(input: SignupInput): Promise<AuthResult> {
       },
     });
 
-    analytics.recordEvent("user.signup", { actorId: profile.id });
-
     const token = signAuthToken({
       userProfileId: profile.id,
       tokenVersion: profile.tokenVersion,

apps/api/src/modules/contact/contact.routes.ts

@@ -1,34 +0,0 @@
-import { wrapAsyncHandler } from "@batch-cooking/express-tools";
-import { submitContactMessageSchema } from "@batch-cooking/shared";
-import { Router } from "express";
-import { type AuthLocals, requireAuth } from "../../middlewares/require-auth.js";
-import { submitContactMessage } from "./contact.service.js";
-
-/**
- * Router mounted at `/contact` in app.ts (issue #80). A single endpoint —
- * `POST /` — for the in-app "signaler un bug / suggestion" form. Requires a
- * session: only signed-in users can send a message, so every report is
- * attributable (see `ContactMessage.authorId`). The admin-side read of
- * these rows lives entirely in the admin router, not here.
- */
-export const contactRouter = Router();
-
-contactRouter.post(
-  "/",
-  requireAuth,
-  wrapAsyncHandler<unknown, AuthLocals>(async (req, res) => {
-    const input = submitContactMessageSchema.parse(req.body);
-    // Read the UA from the request, never from the body — the schema omits
-    // it on purpose so it can't be spoofed. Header can be an array or
-    // absent; normalize to `string | null`.
-    const rawUserAgent = req.headers["user-agent"];
-    const userAgent =
-      typeof rawUserAgent === "string" && rawUserAgent.length > 0 ? rawUserAgent : null;
-    await submitContactMessage(res.locals.userProfile.id, input, userAgent);
-    // 204, not 201-with-a-body: the form has nothing to do with the stored
-    // row, and the shared `ApiClient._request` treats only 204 as bodyless
-    // (a 201 with an empty body makes its `response.json()` throw). Same
-    // "mutation returns nothing" shape as `POST /auth/logout`.
-    res.status(204).end();
-  }),
-);

apps/api/src/modules/contact/contact.service.ts

@@ -1,50 +0,0 @@
-import type { SubmitContactMessageInput } from "@batch-cooking/shared";
-import { prisma } from "../../db/prisma.js";
-import { analytics } from "../../lib/analytics.service.js";
-
-/**
- * Persists one contact-form submission (issue #80). Write-only from the
- * user's side — there is no read/update/delete counterpart here: admins
- * consult these rows through the admin app (`admin-contact.service.ts`, PR
- * 2), never this module.
- *
- * `userAgent` comes straight from the request header, never the body — the
- * shared `submitContactMessageSchema` deliberately omits it so the client
- * can't spoof it. `pageUrl` / `appVersion` are client-supplied context and
- * default to `null` when the (older, or non-web) client didn't send them.
- *
- * Returns nothing: the form only needs to know the write succeeded (a
- * `201`), not the stored row.
- */
-export async function submitContactMessage(
-  authorId: number,
-  input: SubmitContactMessageInput,
-  userAgent: string | null,
-): Promise<void> {
-  try {
-    await prisma.contactMessage.create({
-      data: {
-        authorId,
-        type: input.type,
-        message: input.message,
-        pageUrl: input.pageUrl ?? null,
-        userAgent,
-        appVersion: input.appVersion ?? null,
-      },
-    });
-    // Fire-and-forget (see AnalyticsService's contract) — `admin-metrics`
-    // aggregates `AnalyticsEvent` by `type` generically, so this shows up in
-    // the dashboard series with no extra code; `context.type` lets it be
-    // broken down by bug/suggestion/other.
-    analytics.recordEvent("contact.submitted", {
-      actorType: "user",
-      actorId: authorId,
-      context: { type: input.type },
-    });
-  } catch (err) {
-    // Rethrown as-is — `wrapAsyncHandler` / the error middleware (which
-    // already logs it) handles it; this service layer just isn't allowed a
-    // bare `await` per the repo's async/try-catch convention.
-    throw err;
-  }
-}

apps/api/src/modules/cooking-session/cooking-session.routes.ts

@@ -1,37 +0,0 @@
-import { parseDateOnly } from "@batch-cooking/date-tools";
-import { HttpError } from "@batch-cooking/error-tools";
-import { wrapAsyncHandler } from "@batch-cooking/express-tools";
-import { ErrorCode, getCookingSessionSchema } from "@batch-cooking/shared";
-import { Router } from "express";
-import { type AuthLocals, requireAuth } from "../../middlewares/require-auth.js";
-import { getCookingPlanForDate } from "./cooking-session.service.js";
-
-/** Router mounted at `/cooking-session` in app.ts. */
-export const cookingSessionRouter = Router();
-
-/**
- * Returns the authenticated user's household's optimized cooking plan for
- * the week covering `?date=` (`YYYY-MM-DD`) — every recipe planned that
- * week reorganized into ordered phases (see {@link getCookingPlanForDate}).
- * Always `200`, never `null` — no household or nothing planned that week
- * both come back as a normal `OptimizedCookingPlanView` with empty
- * `recipes`/`phases`. Same request contract as `GET /shopping-list`.
- */
-cookingSessionRouter.get(
-  "/",
-  requireAuth,
-  wrapAsyncHandler<unknown, AuthLocals>(async (req, res) => {
-    const input = getCookingSessionSchema.parse(req.query);
-    const date = parseDateOnly(input.date);
-    if (date === null) {
-      throw new HttpError(
-        400,
-        ErrorCode.VALIDATION_ERROR,
-        `Not a real calendar date: ${input.date}`,
-      );
-    }
-
-    const plan = await getCookingPlanForDate(res.locals.userProfile.houseId, date);
-    res.status(200).json(plan);
-  }),
-);

apps/api/src/modules/cooking-session/cooking-session.service.ts

@@ -1,192 +0,0 @@
-import { type DateTime, getWeekStart, toDateOnly } from "@batch-cooking/date-tools";
-import type { CookingTaskIngredientView, OptimizedCookingPlanView } from "@batch-cooking/shared";
-import type { Prisma } from "@prisma/client";
-import { prisma } from "../../db/prisma.js";
-import {
-  type OptimizerRecipeInput,
-  type OptimizerStepInput,
-  optimizeCookingPlan,
-} from "../../lib/recipe-matching/cooking-optimizer.js";
-import { toIngredientView, toUnitView } from "../recipe/recipe.service.js";
-
-/**
- * Prisma `include` for a `Planning` query that needs, for every item, its
- * recipe's ordered steps with the full detected-technique tree — the raw
- * material the optimizer works on (see `cooking-optimizer.ts`). It's the
- * `steps` sub-tree of `recipe.service.ts`'s own `recipeInclude`, resolved
- * the same way so {@link toIngredientView}/{@link toUnitView} can be reused
- * as-is; deliberately narrower than a full `RecipeView` fetch (no
- * diets/favorites/recipe-level ingredient list — the optimizer reads
- * quantities off the technique clauses, not the recipe header).
- */
-function cookingSessionPlanningInclude() {
-  return {
-    items: {
-      // A "leftovers" item (`sourcePlanningItemId` set) reserves part of an
-      // already-cooked batch — it has nothing to cook, so it must not enter
-      // the optimized cooking plan (issue #34). Excluded at the query so it
-      // never reaches `toOptimizerRecipe`.
-      where: { sourcePlanningItemId: null },
-      include: {
-        recipe: {
-          select: {
-            id: true,
-            name: true,
-            portions: true,
-            steps: {
-              orderBy: { order: "asc" },
-              include: {
-                techSteps: {
-                  orderBy: { order: "asc" },
-                  include: {
-                    techStep: true,
-                    ingredients: {
-                      include: {
-                        ingredient: {
-                          include: {
-                            allergies: { include: { allergy: { include: { category: true } } } },
-                            diets: { include: { diet: true } },
-                          },
-                        },
-                        unit: true,
-                      },
-                    },
-                    utensils: { include: { utensil: true } },
-                    temperatures: true,
-                  },
-                },
-              },
-            },
-          },
-        },
-      },
-    },
-  } satisfies Prisma.PlanningInclude;
-}
-
-type PlanningWithSteps = Prisma.PlanningGetPayload<{
-  include: ReturnType<typeof cookingSessionPlanningInclude>;
-}>;
-type PlanningItemWithSteps = PlanningWithSteps["items"][number];
-
-/**
- * Maps one planning item's recipe (with {@link cookingSessionPlanningInclude})
- * to the optimizer's pure input shape — ingredient/unit/technique/utensil
- * rows resolved to their reference views here so the optimizer itself never
- * touches Prisma. `Decimal` quantities become plain numbers (same
- * `Number(...)` conversion as `recipe.service.ts`'s own view mappers); an
- * unresolved-unit line keeps `unit: null`.
- */
-function toOptimizerRecipe(item: PlanningItemWithSteps): OptimizerRecipeInput {
-  const steps: OptimizerStepInput[] = item.recipe.steps.map((step) => ({
-    stepId: step.id,
-    order: step.order,
-    description: step.description,
-    techSteps: step.techSteps.map((techStep) => {
-      const ingredients: CookingTaskIngredientView[] = techStep.ingredients.map((line) => ({
-        ingredient: toIngredientView(line.ingredient),
-        quantity: line.quantity === null ? null : Number(line.quantity),
-        unit: line.unit === null ? null : toUnitView(line.unit),
-      }));
-      return {
-        techStep: {
-          id: techStep.techStep.id,
-          key: techStep.techStep.key,
-          isPlaceholder: techStep.techStep.isPlaceholder,
-          displayName: techStep.techStep.displayName,
-        },
-        order: techStep.order,
-        ingredients,
-        utensils: techStep.utensils.map(({ utensil }) => ({ id: utensil.id, key: utensil.key })),
-        // Structured value only — `Decimal` °C → plain number, `qualitative`
-        // re-narrowed to the literal union (same posture as
-        // `recipe.service.ts`'s `toStepTechStepViews`).
-        temperatures: techStep.temperatures.map((temperature) => ({
-          celsius: temperature.celsius === null ? null : Number(temperature.celsius),
-          gasMark: temperature.gasMark,
-          qualitative:
-            temperature.qualitative === "low" ||
-            temperature.qualitative === "medium" ||
-            temperature.qualitative === "high"
-              ? temperature.qualitative
-              : null,
-        })),
-      };
-    }),
-  }));
-
-  return {
-    recipeId: item.recipe.id,
-    name: item.recipe.name,
-    // The slot's own portion count vs. the recipe's as-written yield — the
-    // optimizer scales technique-clause quantities by the ratio, same
-    // reasoning as `shopping-list.service.ts`'s `aggregateShoppingList`.
-    portions: item.portions,
-    recipePortions: item.recipe.portions,
-    steps,
-  };
-}
-
-/**
- * Builds the household's optimized cooking plan for the week covering
- * `date` — every recipe planned that week, reorganized into ordered phases
- * that pool shared prep and float passive cooks into the background (see
- * `cooking-optimizer.ts`). `date` follows the same convention as
- * `planning.service.ts`'s `getPlanningForDate` (a caller-parsed `?date=`,
- * not necessarily a Monday).
- *
- * Like `getShoppingListForDate` and unlike `getPlanningForDate`, this
- * **never** returns `null` — no household and "no planning covers this week
- * yet" both degrade to an empty `phases`/`recipes` on an otherwise normal
- * {@link OptimizedCookingPlanView} (the week's date range is always
- * computable from `date` alone).
- */
-export async function getCookingPlanForDate(
-  houseId: number | null,
-  date: DateTime,
-): Promise<OptimizedCookingPlanView> {
-  try {
-    const weekStart = getWeekStart(toDateOnly(date));
-    const weekFinish = weekStart.plus({ days: 6 });
-    const emptyPlan: OptimizedCookingPlanView = {
-      startDate: weekStart.toJSDate().toISOString(),
-      finishDate: weekFinish.toJSDate().toISOString(),
-      recipes: [],
-      phases: [],
-    };
-
-    if (houseId === null) {
-      return emptyPlan;
-    }
-
-    // Same "covering range" lookup as getShoppingListForDate — see
-    // getPlanningForDate's doc comment for the UTC-midnight `Date` rationale.
-    const dateOnly = toDateOnly(date).toJSDate();
-    const planning = await prisma.planning.findFirst({
-      where: {
-        houseId,
-        startDate: { lte: dateOnly },
-        finishDate: { gte: dateOnly },
-      },
-      orderBy: { startDate: "desc" },
-      include: cookingSessionPlanningInclude(),
-    });
-
-    if (!planning) {
-      return emptyPlan;
-    }
-
-    const { recipes, phases } = optimizeCookingPlan(planning.items.map(toOptimizerRecipe));
-    return {
-      startDate: planning.startDate.toISOString(),
-      finishDate: planning.finishDate.toISOString(),
-      recipes,
-      phases,
-    };
-  } catch (err) {
-    // Rethrown as-is — `wrapAsyncHandler`/the error middleware handles it,
-    // this service layer just isn't allowed a bare `await` per the repo's
-    // async/try-catch convention.
-    throw err;
-  }
-}

apps/api/src/modules/internal/tech-step-worker.routes.ts

@@ -3,14 +3,12 @@ import {
   auditBatchQuerySchema,
   submitTrainingSuggestionsSchema,
   workerBatchQuerySchema,
-  workerHeartbeatSchema,
 } from "@batch-cooking/shared";
 import { Router } from "express";
 import { requireInternalWorker } from "../../middlewares/require-internal-worker.js";
 import {
   getAuditBatch,
   getPendingCorrections,
-  recordWorkerHeartbeat,
   submitTrainingSuggestions,
 } from "./tech-step-worker.service.js";
 
@@ -49,19 +47,3 @@ techStepWorkerRouter.post(
     res.status(201).json(await submitTrainingSuggestions(input));
   }),
 );
-
-/**
- * Liveness ping from the worker (which has no inbound HTTP surface of its
- * own) — upserts its `WorkerHeartbeat` row so the admin monitoring board
- * can show it as up / stale / down and surface its last job result. Sent
- * on boot, on every scheduler tick, and after each job.
- */
-techStepWorkerRouter.post(
-  "/heartbeat",
-  requireInternalWorker,
-  wrapAsyncHandler(async (req, res) => {
-    const input = workerHeartbeatSchema.parse(req.body);
-    await recordWorkerHeartbeat(input);
-    res.status(200).json({ ok: true });
-  }),
-);

apps/api/src/modules/internal/tech-step-worker.service.ts

@@ -4,9 +4,7 @@ import {
   type PendingTechStepCorrectionView,
   type SubmitTrainingSuggestionsInput,
   type TechStepAuditClauseView,
-  type WorkerHeartbeatInput,
 } from "@batch-cooking/shared";
-import type { Prisma } from "@prisma/client";
 import { prisma } from "../../db/prisma.js";
 import {
   CONFIDENCE_THRESHOLD,
@@ -201,44 +199,3 @@ export async function submitTrainingSuggestions(
     throw err; // see recipe.service.ts's equivalent catch comment
   }
 }
-
-/**
- * The one worker with a `WorkerHeartbeat` row today — a fixed key, not
- * something the caller supplies (only one worker exists, and letting it
- * name itself would just be a spoofing surface behind the same shared
- * secret).
- */
-const WORKER_KEY = "tech-step-llm-worker";
-
-/**
- * Upserts `services/tech-step-llm-worker`'s heartbeat row (see
- * `POST /internal/tech-steps/heartbeat`). Every ping bumps `lastSeenAt`; a
- * `"job"` ping also records `lastRunAt` + a small `lastResult` summary so
- * the admin monitoring board can show what the worker last did and whether
- * it worked.
- */
-export async function recordWorkerHeartbeat(input: WorkerHeartbeatInput): Promise<void> {
-  try {
-    const now = new Date();
-    const jobResult: Prisma.InputJsonValue | undefined =
-      input.event === "job"
-        ? { job: input.job ?? null, ok: input.ok ?? null, counts: input.counts ?? {} }
-        : undefined;
-
-    await prisma.workerHeartbeat.upsert({
-      where: { workerKey: WORKER_KEY },
-      create: {
-        workerKey: WORKER_KEY,
-        lastSeenAt: now,
-        lastRunAt: input.event === "job" ? now : null,
-        lastResult: jobResult,
-      },
-      update: {
-        lastSeenAt: now,
-        ...(input.event === "job" ? { lastRunAt: now, lastResult: jobResult } : {}),
-      },
-    });
-  } catch (err) {
-    throw err; // see recipe.service.ts's equivalent catch comment
-  }
-}

apps/api/src/modules/mobile/mobile.routes.ts

@@ -1,31 +0,0 @@
-import { wrapAsyncHandler } from "@batch-cooking/express-tools";
-import { Router } from "express";
-import { getLatestApkUrl, getLatestVersion } from "./mobile.service.js";
-
-/**
- * Router mounted at `/mobile` in app.ts. Both routes are deliberately
- * public (no `requireAuth`): the landing page's download link is shown to
- * logged-out visitors, and the native update check (issue #66) runs on
- * every app start, session or not. Both exist purely to work around
- * Forgejo's Releases API sending no CORS headers — see `mobile.service.ts`'s
- * own doc comment for the full story.
- */
-export const mobileRouter = Router();
-
-mobileRouter.get(
-  "/latest-release",
-  wrapAsyncHandler(async (_req, res) => {
-    res.status(200).json({ version: await getLatestVersion() });
-  }),
-);
-
-// A plain redirect, not JSON — lets any caller (the landing page's `<a>`,
-// the update banner's "Mettre à jour" link) use a static href with zero
-// client-side fetch, and always resolves to something useful even if
-// Forgejo is briefly unreachable (see getLatestApkUrl's fallback).
-mobileRouter.get(
-  "/download",
-  wrapAsyncHandler(async (_req, res) => {
-    res.redirect(302, await getLatestApkUrl());
-  }),
-);

apps/api/src/modules/mobile/mobile.service.ts

@@ -1,75 +0,0 @@
-import { HttpError } from "@batch-cooking/error-tools";
-import { ErrorCode } from "@batch-cooking/shared";
-
-/**
- * Forgejo's own Releases API for this repo — public, unauthenticated (the
- * same fact `local-verification-while-ci-disabled` already leans on for
- * CI-status checks without a token). **Must be called server-side, not
- * from the browser**: verified live that Forgejo sends no
- * `Access-Control-Allow-Origin` header on it, so a direct `fetch()` from
- * `apps/web` fails with an opaque CORS error even though the endpoint
- * itself is perfectly reachable — this whole module exists to proxy it
- * from a context CORS doesn't apply to.
- */
-const LATEST_RELEASE_API_URL =
-  "https://git.dev.kyuno.fr/api/v1/repos/kyuno/batchCooking/releases/latest";
-
-/**
- * Human-facing Forgejo release page — safe fallback for {@link getLatestApkUrl}
- * when no matching asset is found (a release with nothing attached yet,
- * Forgejo briefly unreachable, ...). Never a dead link, just a slightly
- * less direct one: the visitor lands on the release itself and can find
- * the asset from there.
- */
-const LATEST_RELEASE_PAGE_URL = "https://git.dev.kyuno.fr/kyuno/batchCooking/releases/latest";
-
-/** Stable filename `release.yml` always attaches the signed APK under — see that workflow's own comment. */
-const APK_ASSET_NAME = "batchcooking.apk";
-
-interface ForgejoReleaseAsset {
-  name: string;
-  browser_download_url: string;
-}
-
-interface ForgejoRelease {
-  tag_name: string;
-  assets: ForgejoReleaseAsset[];
-}
-
-async function fetchLatestRelease(): Promise<ForgejoRelease> {
-  const response = await fetch(LATEST_RELEASE_API_URL);
-  if (!response.ok) {
-    throw new HttpError(
-      502,
-      ErrorCode.INTERNAL_ERROR,
-      `Forgejo releases API responded ${response.status}`,
-    );
-  }
-  return (await response.json()) as ForgejoRelease;
-}
-
-/**
- * The latest tagged Android build's version (e.g. `"v1.4.2"`) — used by the
- * native app's update check (issue #66, `useAppUpdateCheck.ts`).
- */
-export async function getLatestVersion(): Promise<string> {
-  const release = await fetchLatestRelease();
-  return release.tag_name;
-}
-
-/**
- * Where a "download the app" click should end up right now: the actual
- * signed-APK asset of the latest release if one is attached, else
- * {@link LATEST_RELEASE_PAGE_URL} as a safe fallback. Never throws — a
- * download link must always go *somewhere* useful, even when Forgejo is
- * briefly unreachable.
- */
-export async function getLatestApkUrl(): Promise<string> {
-  try {
-    const release = await fetchLatestRelease();
-    const apk = release.assets.find((asset) => asset.name === APK_ASSET_NAME);
-    return apk?.browser_download_url ?? LATEST_RELEASE_PAGE_URL;
-  } catch {
-    return LATEST_RELEASE_PAGE_URL;
-  }
-}

apps/api/src/modules/planning/planning.routes.ts

@@ -1,21 +1,10 @@
 import { parseDateOnly } from "@batch-cooking/date-tools";
 import { HttpError } from "@batch-cooking/error-tools";
 import { wrapAsyncHandler } from "@batch-cooking/express-tools";
-import {
-  addPlanningItemSchema,
-  assignLeftoverSchema,
-  ErrorCode,
-  getPlanningByDateSchema,
-} from "@batch-cooking/shared";
+import { addPlanningItemSchema, ErrorCode, getPlanningByDateSchema } from "@batch-cooking/shared";
 import { Router } from "express";
 import { type AuthLocals, requireAuth } from "../../middlewares/require-auth.js";
-import {
-  addPlanningItem,
-  assignLeftoverPlanningItem,
-  discardLeftover,
-  getPlanningForDate,
-  removePlanningItem,
-} from "./planning.service.js";
+import { addPlanningItem, getPlanningForDate, removePlanningItem } from "./planning.service.js";
 
 /** Router mounted at `/planning` in app.ts. */
 export const planningRouter = Router();
@@ -80,44 +69,6 @@ planningRouter.post(
   }),
 );
 
-/**
- * Serves part of another planning item's leftover pool on a slot — creates
- * a "leftovers" `PlanningItem` (see {@link assignLeftoverPlanningItem}).
- * `POST /items/leftover`, not `/items/:id/...`: the `:id` here would be the
- * *target* slot, which doesn't exist yet — the source is in the body.
- */
-planningRouter.post(
-  "/items/leftover",
-  requireAuth,
-  wrapAsyncHandler<unknown, AuthLocals>(async (req, res) => {
-    const input = assignLeftoverSchema.parse(req.body);
-    const date = parseDateOnly(input.date);
-    if (date === null) {
-      throw new HttpError(
-        400,
-        ErrorCode.VALIDATION_ERROR,
-        `Not a real calendar date: ${input.date}`,
-      );
-    }
-
-    const { id: viewerId, houseId } = res.locals.userProfile;
-    const item = await assignLeftoverPlanningItem(houseId, viewerId, date, input);
-    res.status(201).json(item);
-  }),
-);
-
-/** Throws away item `:id`'s whole remaining leftover pool (idempotent — see {@link discardLeftover}). */
-planningRouter.patch(
-  "/items/:id/discard-leftover",
-  requireAuth,
-  wrapAsyncHandler<unknown, AuthLocals>(async (req, res) => {
-    const id = parsePlanningItemId(req.params.id);
-    const { id: viewerId, houseId } = res.locals.userProfile;
-    const item = await discardLeftover(id, viewerId, houseId);
-    res.status(200).json(item);
-  }),
-);
-
 /** Removes one recipe from a planning slot. */
 planningRouter.delete(
   "/items/:id",

apps/api/src/modules/planning/planning.service.ts

@@ -2,46 +2,13 @@ import { type DateTime, getWeekStart, toDateOnly } from "@batch-cooking/date-too
 import { HttpError } from "@batch-cooking/error-tools";
 import {
   type AddPlanningItemInput,
-  type AssignLeftoverInput,
-  computeAvailableLeftover,
-  computeBatchedPortions,
   ErrorCode,
   type PlanningItemView,
   type PlanningView,
 } from "@batch-cooking/shared";
 import { prisma } from "../../db/prisma.js";
-import { analytics } from "../../lib/analytics.service.js";
 import { assertRecipeVisible } from "../recipe/recipe.service.js";
 
-/**
- * One `PlanningItem` row (with its recipe resolved to `{id, name}`) shaped
- * into the wire {@link PlanningItemView}. The three read/write paths below
- * that return an item — `getPlanningForDate`, `addPlanningItem`,
- * `assignLeftoverPlanningItem`, `discardLeftover` — all go through this so
- * the shape is defined once.
- */
-function toPlanningItemView(item: {
-  id: number;
-  weekDay: string;
-  meal: string;
-  portions: number;
-  portionsRequested: number;
-  discardedPortions: number;
-  sourcePlanningItemId: number | null;
-  recipe: { id: number; name: string };
-}): PlanningItemView {
-  return {
-    id: item.id,
-    weekDay: item.weekDay,
-    meal: item.meal,
-    portions: item.portions,
-    portionsRequested: item.portionsRequested,
-    discardedPortions: item.discardedPortions,
-    sourceItem: item.sourcePlanningItemId !== null ? { id: item.sourcePlanningItemId } : null,
-    recipe: item.recipe,
-  };
-}
-
 /**
  * Finds the household's planning that covers `date` and shapes it into a
  * {@link PlanningView} (recipes resolved to `{id, name}`). `date` is
@@ -96,7 +63,13 @@ export async function getPlanningForDate(
       id: planning.id,
       startDate: planning.startDate.toISOString(),
       finishDate: planning.finishDate.toISOString(),
-      items: planning.items.map(toPlanningItemView),
+      items: planning.items.map((item) => ({
+        id: item.id,
+        weekDay: item.weekDay,
+        meal: item.meal,
+        portions: item.portions,
+        recipe: item.recipe,
+      })),
     };
   } catch (err) {
     // Rethrown as-is — `wrapAsyncHandler`/the error middleware (which
@@ -170,18 +143,6 @@ export async function addPlanningItem(
     }
     await assertRecipeVisible(input.recipeId, viewerId, viewerHouseId);
 
-    // `assertRecipeVisible` already guaranteed the recipe exists and is
-    // visible — this second read just pulls its written yield, needed to
-    // turn "portions requested" into "portions to actually prepare"
-    // (a whole number of batches, see `computeBatchedPortions`). The
-    // `?? 1` never triggers in practice (the assert above threw otherwise);
-    // it only keeps TypeScript happy about `findUnique`'s `| null`.
-    const recipe = await prisma.recipe.findUnique({
-      where: { id: input.recipeId },
-      select: { portions: true },
-    });
-    const { portions } = computeBatchedPortions(recipe?.portions ?? 1, input.portionsRequested);
-
     const weekStart = getWeekStart(toDateOnly(date));
     const planning = await findOrCreatePlanningForWeek(houseId, weekStart);
 
@@ -191,22 +152,18 @@ export async function addPlanningItem(
         weekDay: input.weekDay,
         meal: input.meal,
         recipeId: input.recipeId,
-        portions,
-        portionsRequested: input.portionsRequested,
+        portions: input.portions,
       },
       include: { recipe: { select: { id: true, name: true } } },
     });
 
-    analytics.recordEvent("planning.item_added", {
-      actorId: viewerId,
-      context: {
-        recipeId: input.recipeId,
-        portions,
-        portionsRequested: input.portionsRequested,
-      },
-    });
-
-    return toPlanningItemView(item);
+    return {
+      id: item.id,
+      weekDay: item.weekDay,
+      meal: item.meal,
+      portions: item.portions,
+      recipe: item.recipe,
+    };
   } catch (err) {
     throw err; // see getPlanningForDate()'s catch comment above
   }
@@ -234,139 +191,3 @@ export async function removePlanningItem(id: number, houseId: number | null): Pr
     throw err; // see getPlanningForDate()'s catch comment above
   }
 }
-
-/**
- * Loads a `PlanningItem` (scoped to `houseId`) with everything
- * {@link computeAvailableLeftover} needs — its own portion fields plus how
- * much of its pool has already been served elsewhere (`leftoverUses`) — or
- * throws `404 PLANNING_ITEM_NOT_FOUND` (same "don't confirm what exists"
- * posture as `removePlanningItem`). Shared by
- * {@link assignLeftoverPlanningItem} and {@link discardLeftover}.
- */
-async function loadItemWithLeftoverPool(id: number, houseId: number | null) {
-  const item = await prisma.planningItem.findUnique({
-    where: { id },
-    include: {
-      planning: { select: { houseId: true } },
-      leftoverUses: { select: { portions: true } },
-      recipe: { select: { id: true, name: true } },
-    },
-  });
-  if (!item || houseId === null || item.planning.houseId !== houseId) {
-    throw new HttpError(404, ErrorCode.PLANNING_ITEM_NOT_FOUND, `Planning item ${id} not found`);
-  }
-  return item;
-}
-
-/**
- * Serves `input.portions` of another item's leftover pool on the
- * `(date, weekDay, meal)` slot — creates a "leftovers" `PlanningItem`
- * (`sourcePlanningItemId` set) on the same recipe as its source. Nothing
- * new is cooked for it, so `portions === portionsRequested` and it excludes
- * itself from the shopping list / cooking session (see those services'
- * `where: { sourcePlanningItemId: null }`).
- *
- * The source's `recipeId` is copied, never taken from the client (a
- * leftovers item can only be its source's recipe). `input.portions` is
- * re-checked against the pool actually still available
- * ({@link computeAvailableLeftover}) — trusting a client value here would
- * let a household conjure portions it never cooked.
- *
- * @throws {HttpError} `404 HOUSE_NOT_FOUND` if `houseId` is `null`.
- * @throws {HttpError} `404 PLANNING_ITEM_NOT_FOUND` if `sourceItemId` doesn't exist, belongs to another household, or is itself a leftovers item (no leftovers-on-leftovers).
- * @throws {HttpError} `409 LEFTOVER_QUANTITY_EXCEEDED` if `portions` exceeds the source's still-available pool.
- */
-export async function assignLeftoverPlanningItem(
-  houseId: number | null,
-  viewerId: number,
-  date: DateTime,
-  input: AssignLeftoverInput,
-): Promise<PlanningItemView> {
-  try {
-    if (houseId === null) {
-      throw new HttpError(404, ErrorCode.HOUSE_NOT_FOUND, "Profile has no household");
-    }
-
-    const source = await loadItemWithLeftoverPool(input.sourceItemId, houseId);
-    if (source.sourcePlanningItemId !== null) {
-      // A leftovers item has no pool of its own — serving leftovers cooks
-      // nothing, so it can't be a source for more.
-      throw new HttpError(
-        404,
-        ErrorCode.PLANNING_ITEM_NOT_FOUND,
-        `Planning item ${input.sourceItemId} is not a leftovers source`,
-      );
-    }
-
-    const available = computeAvailableLeftover(source);
-    if (input.portions > available) {
-      throw new HttpError(
-        409,
-        ErrorCode.LEFTOVER_QUANTITY_EXCEEDED,
-        `Item ${source.id} has ${available} leftover portion(s) available, asked for ${input.portions}`,
-      );
-    }
-
-    const weekStart = getWeekStart(toDateOnly(date));
-    const planning = await findOrCreatePlanningForWeek(houseId, weekStart);
-
-    const item = await prisma.planningItem.create({
-      data: {
-        planningId: planning.id,
-        weekDay: input.weekDay,
-        meal: input.meal,
-        recipeId: source.recipeId,
-        portions: input.portions,
-        portionsRequested: input.portions,
-        sourcePlanningItemId: source.id,
-      },
-      include: { recipe: { select: { id: true, name: true } } },
-    });
-
-    analytics.recordEvent("planning.leftover_assigned", {
-      actorId: viewerId,
-      context: { recipeId: source.recipeId, portions: input.portions, sourceItemId: source.id },
-    });
-
-    return toPlanningItemView(item);
-  } catch (err) {
-    throw err; // see getPlanningForDate()'s catch comment above
-  }
-}
-
-/**
- * Throws away the whole still-available leftover pool of item `id`
- * (`discardedPortions += available`) — the basket's "jeter" button.
- * Idempotent: an item with nothing left to discard is returned unchanged,
- * no event recorded.
- *
- * @throws {HttpError} `404 PLANNING_ITEM_NOT_FOUND` — same guard as `removePlanningItem`.
- */
-export async function discardLeftover(
-  id: number,
-  viewerId: number,
-  houseId: number | null,
-): Promise<PlanningItemView> {
-  try {
-    const item = await loadItemWithLeftoverPool(id, houseId);
-    const available = computeAvailableLeftover(item);
-    if (available === 0) {
-      return toPlanningItemView(item);
-    }
-
-    const updated = await prisma.planningItem.update({
-      where: { id },
-      data: { discardedPortions: item.discardedPortions + available },
-      include: { recipe: { select: { id: true, name: true } } },
-    });
-
-    analytics.recordEvent("planning.leftover_discarded", {
-      actorId: viewerId,
-      context: { recipeId: item.recipe.id, portions: available },
-    });
-
-    return toPlanningItemView(updated);
-  } catch (err) {
-    throw err; // see getPlanningForDate()'s catch comment above
-  }
-}

apps/api/src/modules/profile/profile.routes.ts

@@ -1,9 +1,5 @@
-import { HttpError } from "@batch-cooking/error-tools";
 import { wrapAsyncHandler } from "@batch-cooking/express-tools";
 import {
-  type CompletedToursView,
-  completeTourSchema,
-  ErrorCode,
   updateAllergiesSchema,
   updateDietSchema,
   updateDislikedIngredientsSchema,
@@ -12,9 +8,7 @@ import { Router } from "express";
 import { type AuthLocals, requireAuth } from "../../middlewares/require-auth.js";
 import {
   getAllergyIds,
-  getCompletedTourKeys,
   getDislikedIngredientIds,
-  markTourSeen,
   updateAllergies,
   updateDiet,
   updateDislikedIngredients,
@@ -23,14 +17,6 @@ import {
 /** Router mounted at `/profile` in app.ts. Every route requires a session — this is the authenticated user's own profile. */
 export const profileRouter = Router();
 
-/** Express types a route param `string | undefined` even for a segment that always matches when the route does — satisfies TS, unreachable in practice. */
-function requireParam(value: string | undefined): string {
-  if (value === undefined) {
-    throw new HttpError(400, ErrorCode.VALIDATION_ERROR, "Missing route parameter");
-  }
-  return value;
-}
-
 /** The regime step of the profile journey (signup wizard and the `/foyer` settings page both call this). */
 profileRouter.patch(
   "/diet",
@@ -84,29 +70,3 @@ profileRouter.patch(
     res.status(200).json(ids);
   }),
 );
-
-/** Which guided-tour scenarios this profile has already seen — the web tour engine reads this once per session (issues #42/#44). */
-profileRouter.get(
-  "/tours",
-  requireAuth,
-  wrapAsyncHandler<unknown, AuthLocals>(async (_req, res) => {
-    const completedTourKeys = await getCompletedTourKeys(res.locals.userProfile.id);
-    res.status(200).json({ completedTourKeys } satisfies CompletedToursView);
-  }),
-);
-
-/**
- * Marks a guided-tour scenario as seen — idempotent. An empty body means
- * "completed"; `{ "skipped": true }` means the user dismissed it (different
- * analytics event, same "don't re-nag" effect). 404s on an unknown/disabled
- * tour key.
- */
-profileRouter.post(
-  "/tours/:tourKey/complete",
-  requireAuth,
-  wrapAsyncHandler<unknown, AuthLocals>(async (req, res) => {
-    const { skipped } = completeTourSchema.parse(req.body ?? {});
-    await markTourSeen(res.locals.userProfile.id, requireParam(req.params.tourKey), skipped);
-    res.status(204).end();
-  }),
-);

apps/api/src/modules/profile/profile.service.ts

@@ -1,7 +1,6 @@
 import { HttpError } from "@batch-cooking/error-tools";
 import { ErrorCode, type SafeUserProfile } from "@batch-cooking/shared";
 import { prisma } from "../../db/prisma.js";
-import { analytics } from "../../lib/analytics.service.js";
 import { toSafeProfile } from "../../lib/safe-profile.js";
 
 /**
@@ -150,57 +149,3 @@ export async function updateDislikedIngredients(
     throw err; // see updateDiet()'s catch comment above
   }
 }
-
-/**
- * The `key`s of every guided-tour scenario this profile has already seen
- * (completed or skipped — both leave a `TourProgress` row). The web tour
- * engine reads this once per session to decide which tours to auto-start
- * (issues #42/#44).
- */
-export async function getCompletedTourKeys(userProfileId: number): Promise<string[]> {
-  try {
-    const rows = await prisma.tourProgress.findMany({
-      where: { userProfileId },
-      select: { scenario: { select: { key: true } } },
-    });
-    return rows.map((row) => row.scenario.key);
-  } catch (err) {
-    throw err; // see updateDiet()'s catch comment above
-  }
-}
-
-/**
- * Marks a guided-tour scenario as seen by this profile — idempotent upsert,
- * safe to call again (e.g. the engine retries after a flaky network). Emits
- * `tour.completed` or `tour.skipped` for the admin dashboard (issue #44's
- * analytics — the dashboard renders any new `AnalyticsEvent` type
- * generically, no frontend change needed).
- *
- * @throws {HttpError} `404 TOUR_NOT_FOUND` if `tourKey` doesn't match an
- *   **enabled** `TourScenario` (a disabled tour can't be completed).
- */
-export async function markTourSeen(
-  userProfileId: number,
-  tourKey: string,
-  skipped: boolean,
-): Promise<void> {
-  try {
-    const scenario = await prisma.tourScenario.findUnique({ where: { key: tourKey } });
-    if (!scenario?.enabled) {
-      throw new HttpError(404, ErrorCode.TOUR_NOT_FOUND, `No enabled tour with key ${tourKey}`);
-    }
-
-    await prisma.tourProgress.upsert({
-      where: { userProfileId_scenarioId: { userProfileId, scenarioId: scenario.id } },
-      update: {},
-      create: { userProfileId, scenarioId: scenario.id },
-    });
-
-    analytics.recordEvent(skipped ? "tour.skipped" : "tour.completed", {
-      actorId: userProfileId,
-      context: { tourKey },
-    });
-  } catch (err) {
-    throw err; // see updateDiet()'s catch comment above
-  }
-}

apps/api/src/modules/recipe/recipe-tech-step-correction.service.ts

@@ -1,4 +1,3 @@
-import { randomUUID } from "node:crypto";
 import { HttpError } from "@batch-cooking/error-tools";
 import {
   ErrorCode,
@@ -8,7 +7,6 @@ import {
 } from "@batch-cooking/shared";
 import type { Prisma } from "@prisma/client";
 import { prisma } from "../../db/prisma.js";
-import { analytics } from "../../lib/analytics.service.js";
 import { assertRecipeVisible, toStepTechStepViews } from "./recipe.service.js";
 
 /**
@@ -33,24 +31,22 @@ const correctionInclude = {
 } satisfies Prisma.StepTechStepCorrectionInclude;
 
 /**
- * Loads `stepId`'s current `description` (a correction needs its full text
- * now, not just its length — see {@link submitTechStepCorrection}'s
- * `raw` derivation for a manual temperature mention), or throws —
- * `404 STEP_NOT_FOUND` if no such step exists, or if it exists but doesn't
- * belong to `recipeId` (the route's own `:id`/`:stepId` nesting is
- * meaningless otherwise — a request naming a real step under the wrong
- * recipe should look identical to naming one that doesn't exist, same
- * "don't leak which part was wrong" posture `assertRecipeVisible` already
- * has for visibility). Otherwise whatever {@link assertRecipeVisible}
- * throws (`404 RECIPE_NOT_FOUND`, never `403`) if the recipe exists but
- * isn't visible to the viewer.
+ * Loads `stepId`'s current `description` length (the only thing a
+ * correction needs from the step itself), or throws — `404 STEP_NOT_FOUND`
+ * if no such step exists, or if it exists but doesn't belong to `recipeId`
+ * (the route's own `:id`/`:stepId` nesting is meaningless otherwise — a
+ * request naming a real step under the wrong recipe should look identical
+ * to naming one that doesn't exist, same "don't leak which part was wrong"
+ * posture `assertRecipeVisible` already has for visibility). Otherwise
+ * whatever {@link assertRecipeVisible} throws (`404 RECIPE_NOT_FOUND`,
+ * never `403`) if the recipe exists but isn't visible to the viewer.
  */
 async function loadVisibleStepOrThrow(
   recipeId: number,
   stepId: number,
   viewerId: number,
   viewerHouseId: number | null,
-): Promise<{ id: number; description: string }> {
+): Promise<{ id: number; descriptionLength: number }> {
   try {
     const step = await prisma.step.findUnique({
       where: { id: stepId },
@@ -60,7 +56,7 @@ async function loadVisibleStepOrThrow(
       throw new HttpError(404, ErrorCode.STEP_NOT_FOUND, `Step ${stepId} not found`);
     }
     await assertRecipeVisible(step.recipeId, viewerId, viewerHouseId);
-    return { id: step.id, description: step.description };
+    return { id: step.id, descriptionLength: step.description.length };
   } catch (err) {
     throw err; // see recipe.service.ts's equivalent catch comment
   }
@@ -88,75 +84,6 @@ async function assertTechStepsExist(ids: number[]): Promise<void> {
   }
 }
 
-/** Throws `404 INGREDIENT_NOT_FOUND` if any id in `ids` doesn't match a reference `Ingredient` row — same shape as {@link assertTechStepsExist}, checking `input.ingredients[].ingredientId` instead. */
-async function assertIngredientsExist(ids: number[]): Promise<void> {
-  try {
-    const uniqueIds = [...new Set(ids)];
-    if (uniqueIds.length === 0) return;
-    const found = await prisma.ingredient.findMany({
-      where: { id: { in: uniqueIds } },
-      select: { id: true },
-    });
-    const foundIds = new Set(found.map((ingredient) => ingredient.id));
-    const missing = uniqueIds.filter((id) => !foundIds.has(id));
-    if (missing.length > 0) {
-      throw new HttpError(
-        404,
-        ErrorCode.INGREDIENT_NOT_FOUND,
-        `Ingredient ids not found: ${missing.join(", ")}`,
-      );
-    }
-  } catch (err) {
-    throw err; // see loadVisibleStepOrThrow's catch comment
-  }
-}
-
-/** Throws `404 UNIT_NOT_FOUND` if any id in `ids` doesn't match a reference `Unit` row — same shape as {@link assertIngredientsExist}, checking `input.ingredients[].unitId` instead. */
-async function assertUnitsExist(ids: number[]): Promise<void> {
-  try {
-    const uniqueIds = [...new Set(ids)];
-    if (uniqueIds.length === 0) return;
-    const found = await prisma.unit.findMany({
-      where: { id: { in: uniqueIds } },
-      select: { id: true },
-    });
-    const foundIds = new Set(found.map((unit) => unit.id));
-    const missing = uniqueIds.filter((id) => !foundIds.has(id));
-    if (missing.length > 0) {
-      throw new HttpError(
-        404,
-        ErrorCode.UNIT_NOT_FOUND,
-        `Unit ids not found: ${missing.join(", ")}`,
-      );
-    }
-  } catch (err) {
-    throw err; // see loadVisibleStepOrThrow's catch comment
-  }
-}
-
-/** Throws `404 UTENSIL_NOT_FOUND` if any id in `ids` doesn't match a reference `Utensil` row — same shape as {@link assertIngredientsExist}, checking `input.utensils[].utensilId` instead. */
-async function assertUtensilsExist(ids: number[]): Promise<void> {
-  try {
-    const uniqueIds = [...new Set(ids)];
-    if (uniqueIds.length === 0) return;
-    const found = await prisma.utensil.findMany({
-      where: { id: { in: uniqueIds } },
-      select: { id: true },
-    });
-    const foundIds = new Set(found.map((utensil) => utensil.id));
-    const missing = uniqueIds.filter((id) => !foundIds.has(id));
-    if (missing.length > 0) {
-      throw new HttpError(
-        404,
-        ErrorCode.UTENSIL_NOT_FOUND,
-        `Utensil ids not found: ${missing.join(", ")}`,
-      );
-    }
-  } catch (err) {
-    throw err; // see loadVisibleStepOrThrow's catch comment
-  }
-}
-
 /**
  * Renumbers every one of `stepId`'s `StepTechStep` rows' `order` by
  * ascending `start` (nulls-still-possible legacy rows, see that model's
@@ -198,35 +125,6 @@ export async function renumberStepTechSteps(
   }
 }
 
-/** One ingredient/utensil mention the viewer themselves selected, ready to persist — see {@link applyManualCorrection}'s own doc comment for the "manual replaces all" semantics these are written under. */
-interface ManualIngredientMention {
-  ingredientId: number;
-  quantity: number | null;
-  unitId: number | null;
-  start: number;
-  end: number;
-}
-interface ManualUtensilMention {
-  utensilId: number;
-  start: number;
-  end: number;
-}
-/**
- * Same as {@link ManualIngredientMention}, for a temperature — `raw` is
- * already resolved by the caller ({@link submitTechStepCorrection}, which
- * has the step's full `description` text to slice) rather than trusted
- * from the client; see `manualStepTechStepTemperatureInputSchema`'s own
- * doc comment (`packages/shared`) for why.
- */
-interface ManualTemperatureMention {
-  celsius: number | null;
-  gasMark: number | null;
-  qualitative: "low" | "medium" | "high" | null;
-  raw: string;
-  start: number;
-  end: number;
-}
-
 /**
  * Applies a correction's *effect* on `stepId`'s real `StepTechStep`
  * sequence, immediately — not just recorded as a pending suggestion for
@@ -244,28 +142,13 @@ interface ManualTemperatureMention {
  *   `contextEnd` — a correction only ever carries the tight span the user
  *   themselves selected/clicked, nothing wider to highlight around it.
  * - `previousTechStepId` alone (remove, `correctedTechStepId: null`): the
- *   matching existing entry is deleted outright (cascading away any
- *   ingredient/utensil metadata attached to it, auto or manual — nothing
- *   left to attach metadata to once the technique itself is gone). A
- *   no-op if none matches (nothing to remove).
- *
- * `metadata`, when given (only ever alongside a real `correctedTechStepId`
- * — enforced by `submitTechStepCorrectionSchema`, not re-checked here),
- * replaces *every* `StepTechStepIngredient`/`StepTechStepUtensil`/
- * `StepTechStepTemperature` row on this occurrence — `source: "auto"` (the
- * classifier's own detection) and any earlier `"manual"` set alike — with
- * the newly-submitted one. This is "le manuel remplace tout" (confirmed
- * with the user): the resolved `order` this technique ends up at
- * (whichever branch above produced it) is the same `techStepOrder` all
- * three metadata tables key on, so the same `deleteMany` + `createMany`
- * pair below is correct whether this call just updated an existing row
- * (which may already carry auto-detected metadata) or created a brand new
- * one (nothing to delete yet — a no-op `deleteMany`, not a special case).
+ *   matching existing entry is deleted outright. A no-op if none matches
+ *   (nothing to remove).
  *
  * Runs inside the same transaction {@link submitTechStepCorrection} uses
- * for the audit-trail insert, so a request never leaves any of these
- * effects (the permanent correction record, the live sequence change, the
- * metadata replacement) only partially applied.
+ * for the audit-trail insert, so a request never leaves the two effects
+ * (the permanent correction record, the live sequence change) only
+ * partially applied.
  */
 async function applyManualCorrection(
   tx: Prisma.TransactionClient,
@@ -273,11 +156,6 @@ async function applyManualCorrection(
   span: { start: number; end: number },
   previousTechStepId: number | null,
   correctedTechStepId: number | null,
-  metadata?: {
-    ingredients: ManualIngredientMention[];
-    utensils: ManualUtensilMention[];
-    temperatures: ManualTemperatureMention[];
-  },
 ): Promise<void> {
   const existing = await tx.stepTechStep.findMany({ where: { stepId } });
 
@@ -294,12 +172,9 @@ async function applyManualCorrection(
       : undefined;
 
   if (correctedTechStepId !== null) {
-    const order = target
-      ? target.order
-      : existing.reduce((max, row) => Math.max(max, row.order), -1) + 1;
     if (target) {
       await tx.stepTechStep.update({
-        where: { stepId_order: { stepId, order } },
+        where: { stepId_order: { stepId, order: target.order } },
         data: {
           techStepId: correctedTechStepId,
           start: span.start,
@@ -310,64 +185,18 @@ async function applyManualCorrection(
         },
       });
     } else {
+      const nextOrder = existing.reduce((max, row) => Math.max(max, row.order), -1) + 1;
       await tx.stepTechStep.create({
         data: {
           stepId,
           techStepId: correctedTechStepId,
-          order,
+          order: nextOrder,
           start: span.start,
           end: span.end,
           source: "manual",
         },
       });
     }
-
-    if (metadata !== undefined) {
-      await tx.stepTechStepIngredient.deleteMany({ where: { stepId, techStepOrder: order } });
-      await tx.stepTechStepUtensil.deleteMany({ where: { stepId, techStepOrder: order } });
-      if (metadata.ingredients.length > 0) {
-        await tx.stepTechStepIngredient.createMany({
-          data: metadata.ingredients.map((ingredient) => ({
-            stepId,
-            techStepOrder: order,
-            ingredientId: ingredient.ingredientId,
-            quantity: ingredient.quantity,
-            unitId: ingredient.unitId,
-            start: ingredient.start,
-            end: ingredient.end,
-            source: "manual",
-          })),
-        });
-      }
-      if (metadata.utensils.length > 0) {
-        await tx.stepTechStepUtensil.createMany({
-          data: metadata.utensils.map((utensil) => ({
-            stepId,
-            techStepOrder: order,
-            utensilId: utensil.utensilId,
-            start: utensil.start,
-            end: utensil.end,
-            source: "manual",
-          })),
-        });
-      }
-      await tx.stepTechStepTemperature.deleteMany({ where: { stepId, techStepOrder: order } });
-      if (metadata.temperatures.length > 0) {
-        await tx.stepTechStepTemperature.createMany({
-          data: metadata.temperatures.map((temperature) => ({
-            stepId,
-            techStepOrder: order,
-            celsius: temperature.celsius,
-            gasMark: temperature.gasMark,
-            qualitative: temperature.qualitative,
-            raw: temperature.raw,
-            start: temperature.start,
-            end: temperature.end,
-            source: "manual",
-          })),
-        });
-      }
-    }
   } else if (target) {
     await tx.stepTechStep.delete({ where: { stepId_order: { stepId, order: target.order } } });
   }
@@ -381,20 +210,10 @@ function toCorrectionView(correction: CorrectionWithTechSteps): StepTechStepCorr
     start: correction.start,
     end: correction.end,
     previousTechStep: correction.previousTechStep
-      ? {
-          id: correction.previousTechStep.id,
-          key: correction.previousTechStep.key,
-          isPlaceholder: correction.previousTechStep.isPlaceholder,
-          displayName: correction.previousTechStep.displayName,
-        }
+      ? { id: correction.previousTechStep.id, key: correction.previousTechStep.key }
       : null,
     correctedTechStep: correction.correctedTechStep
-      ? {
-          id: correction.correctedTechStep.id,
-          key: correction.correctedTechStep.key,
-          isPlaceholder: correction.correctedTechStep.isPlaceholder,
-          displayName: correction.correctedTechStep.displayName,
-        }
+      ? { id: correction.correctedTechStep.id, key: correction.correctedTechStep.key }
       : null,
     createdAt: correction.createdAt.toISOString(),
   };
@@ -413,13 +232,9 @@ function toCorrectionView(correction: CorrectionWithTechSteps): StepTechStepCorr
  *
  * @throws {HttpError} `404 STEP_NOT_FOUND`/`404 RECIPE_NOT_FOUND` — see
  *   {@link loadVisibleStepOrThrow}. `400 INVALID_CORRECTION_SPAN` if
- *   `start`/`end` (the correction's own span, or any of
- *   `input.ingredients`/`input.utensils`/`input.temperatures`' own spans)
- *   fall outside the step's current `description` (it may have been
- *   edited since the user last saw it). `404 TECH_STEP_NOT_FOUND`/
- *   `404 INGREDIENT_NOT_FOUND`/`404 UNIT_NOT_FOUND`/`404 UTENSIL_NOT_FOUND`
- *   if any referenced id
- *   doesn't exist.
+ *   `start`/`end` fall outside the step's current `description` (it may
+ *   have been edited since the user last saw it). `404 TECH_STEP_NOT_FOUND`
+ *   if either tech-step id doesn't exist.
  */
 export async function submitTechStepCorrection(
   recipeId: number,
@@ -430,62 +245,21 @@ export async function submitTechStepCorrection(
 ): Promise<SubmitTechStepCorrectionResult> {
   try {
     const step = await loadVisibleStepOrThrow(recipeId, stepId, correctorId, viewerHouseId);
-    const descriptionLength = step.description.length;
 
-    const spans = [
-      { start: input.start, end: input.end },
-      ...(input.ingredients ?? []),
-      ...(input.utensils ?? []),
-      ...(input.temperatures ?? []),
-    ];
-    for (const span of spans) {
-      if (span.start >= descriptionLength || span.end > descriptionLength) {
+    if (input.start >= step.descriptionLength || input.end > step.descriptionLength) {
       throw new HttpError(
         400,
         ErrorCode.INVALID_CORRECTION_SPAN,
-          `Span [${span.start}, ${span.end}) falls outside step ${stepId}'s description (length ${descriptionLength})`,
+        `Span [${input.start}, ${input.end}) falls outside step ${stepId}'s description (length ${step.descriptionLength})`,
       );
     }
-    }
 
     const techStepIds = [input.previousTechStepId, input.correctedTechStepId].filter(
       (id): id is number => id !== null && id !== undefined,
     );
     await assertTechStepsExist(techStepIds);
-    await assertIngredientsExist((input.ingredients ?? []).map((i) => i.ingredientId));
-    await assertUnitsExist(
-      (input.ingredients ?? []).flatMap((i) =>
-        i.unitId !== null && i.unitId !== undefined ? [i.unitId] : [],
-      ),
-    );
-    await assertUtensilsExist((input.utensils ?? []).map((u) => u.utensilId));
-
-    const { correction, techSteps, placeholderTechStepId } = await prisma.$transaction(
-      async (tx) => {
-        // A technique the catalog doesn't have (issue #130) — mint a
-        // placeholder `TechStep` for it, in the same transaction as the
-        // correction that references it, then proceed exactly as if its id had
-        // been sent as `correctedTechStepId`. Same shape as
-        // `recipe.service.ts`'s `resolveIngredientLines` does for a
-        // free-text ingredient.
-        const placeholderTechStepId =
-          input.correctedTechStepName !== undefined
-            ? (
-                await tx.techStep.create({
-                  data: {
-                    key: `placeholder:${randomUUID()}`,
-                    isPlaceholder: true,
-                    displayName: input.correctedTechStepName,
-                    createdById: correctorId,
-                    createdAt: new Date(),
-                  },
-                  select: { id: true },
-                })
-              ).id
-            : null;
-        const effectiveCorrectedTechStepId =
-          placeholderTechStepId ?? input.correctedTechStepId ?? null;
 
+    const { correction, techSteps } = await prisma.$transaction(async (tx) => {
       const createdCorrection = await tx.stepTechStepCorrection.create({
         data: {
           stepId: step.id,
@@ -493,7 +267,7 @@ export async function submitTechStepCorrection(
           start: input.start,
           end: input.end,
           previousTechStepId: input.previousTechStepId ?? null,
-            correctedTechStepId: effectiveCorrectedTechStepId,
+          correctedTechStepId: input.correctedTechStepId ?? null,
         },
         include: correctionInclude,
       });
@@ -503,87 +277,17 @@ export async function submitTechStepCorrection(
         step.id,
         { start: input.start, end: input.end },
         input.previousTechStepId ?? null,
-          effectiveCorrectedTechStepId,
-          input.ingredients === undefined &&
-            input.utensils === undefined &&
-            input.temperatures === undefined
-            ? undefined
-            : {
-                ingredients: (input.ingredients ?? []).map((ingredient) => ({
-                  ingredientId: ingredient.ingredientId,
-                  quantity: ingredient.quantity ?? null,
-                  unitId: ingredient.unitId ?? null,
-                  start: ingredient.start,
-                  end: ingredient.end,
-                })),
-                utensils: (input.utensils ?? []).map((utensil) => ({
-                  utensilId: utensil.utensilId,
-                  start: utensil.start,
-                  end: utensil.end,
-                })),
-                // `raw` is derived here (not sent by the client) — see
-                // `ManualTemperatureMention`'s own doc comment.
-                temperatures: (input.temperatures ?? []).map((temperature) => ({
-                  celsius: temperature.celsius ?? null,
-                  gasMark: temperature.gasMark ?? null,
-                  qualitative: temperature.qualitative ?? null,
-                  raw: step.description.slice(temperature.start, temperature.end),
-                  start: temperature.start,
-                  end: temperature.end,
-                })),
-              },
+        input.correctedTechStepId ?? null,
       );
 
-        // Same nested `ingredients`/`utensils`/`temperatures` include as
-        // `recipe.service.ts`'s `recipeInclude` — `toStepTechStepViews`
-        // (reused below) expects it, so the fresh sequence read right after a
-        // manual correction resolves exactly the same way a normal
-        // `GET /recipes/:id` would.
       const freshTechSteps = await tx.stepTechStep.findMany({
         where: { stepId: step.id },
         orderBy: { order: "asc" },
-          include: {
-            techStep: true,
-            ingredients: {
-              include: {
-                ingredient: {
-                  include: {
-                    allergies: { include: { allergy: { include: { category: true } } } },
-                    diets: { include: { diet: true } },
-                  },
-                },
-                unit: true,
-              },
-            },
-            utensils: { include: { utensil: true } },
-            temperatures: true,
-          },
+        include: { techStep: true },
       });
 
-        return { correction: createdCorrection, techSteps: freshTechSteps, placeholderTechStepId };
-      },
-    );
-
-    analytics.recordEvent("tech_step.correction_submitted", {
-      actorId: correctorId,
-      context: {
-        recipeId,
-        stepId,
-        previousTechStepId: input.previousTechStepId ?? null,
-        correctedTechStepId: correction.correctedTechStepId,
-      },
+      return { correction: createdCorrection, techSteps: freshTechSteps };
     });
-    if (placeholderTechStepId !== null) {
-      analytics.recordEvent("tech_step.placeholder_proposed", {
-        actorId: correctorId,
-        context: {
-          recipeId,
-          stepId,
-          techStepId: placeholderTechStepId,
-          name: input.correctedTechStepName ?? "",
-        },
-      });
-    }
 
     return { correction: toCorrectionView(correction), techSteps: toStepTechStepViews(techSteps) };
   } catch (err) {

apps/api/src/modules/recipe/recipe.service.ts

@@ -1,9 +1,7 @@
-import { randomUUID } from "node:crypto";
 import { HttpError } from "@batch-cooking/error-tools";
 import {
   type AllergyView,
   type CreateRecipeInput,
-  computeRecipeDietViews,
   type DietView,
   ErrorCode,
   type IngredientView,
@@ -16,12 +14,10 @@ import {
 } from "@batch-cooking/shared";
 import type { Prisma } from "@prisma/client";
 import { prisma } from "../../db/prisma.js";
-import { analytics } from "../../lib/analytics.service.js";
 import {
   type TechStepMatch,
   techStepClassifier,
 } from "../../lib/recipe-matching/tech-step-matcher.js";
-import { toStepTechStepCreateInputs } from "../../lib/recipe-matching/tech-step-persistence.js";
 
 // No user-language preference exists anywhere in the app yet (a single
 // "fr" translation file, no locale field on User/UserProfile) — steps are
@@ -30,7 +26,7 @@ import { toStepTechStepCreateInputs } from "../../lib/recipe-matching/tech-step-
 // is a parameter rather than baked into that module.
 const DEFAULT_TECH_STEP_LOCALE = "fr";
 
-/** Prisma `include` for every query that needs a full {@link RecipeView} — ingredients resolved to their reference data (name, allergens, diet compatibilities), steps in order, and whether `viewerId` has favorited it. Parameterized by viewer since `favoritedBy` is per-viewer, not a static shape. A recipe's own regimes are no longer stored (issue #131 dropped `RecipeDiet`) — they're computed from the ingredient views by {@link computeRecipeDietViews}. */
+/** Prisma `include` for every query that needs a full {@link RecipeView} — ingredients resolved to their reference data + allergens, steps in order, diet tags, and whether `viewerId` has favorited it. Parameterized by viewer since `favoritedBy` is per-viewer, not a static shape. */
 function recipeInclude(viewerId: number) {
   return {
     ingredients: {
@@ -49,67 +45,22 @@ function recipeInclude(viewerId: number) {
     steps: {
       orderBy: { order: "asc" },
       include: {
-        techSteps: {
-          orderBy: { order: "asc" },
-          include: {
-            techStep: true,
-            // Same `allergies`/`diets` nesting as this function's own
-            // top-level `ingredients` include above — reused by
-            // `toIngredientView` so a mentioned ingredient resolves to the
-            // exact same `IngredientView` shape as the recipe's main
-            // ingredient list, not a second, thinner shape.
-            ingredients: {
-              include: {
-                ingredient: {
-                  include: {
-                    allergies: { include: { allergy: { include: { category: true } } } },
+        techSteps: { orderBy: { order: "asc" }, include: { techStep: true } },
+      },
+    },
     diets: { include: { diet: true } },
-                  },
-                },
-                unit: true,
-              },
-            },
-            utensils: { include: { utensil: true } },
-            temperatures: true,
-          },
-        },
-      },
-    },
     favoritedBy: { where: { userProfileId: viewerId } },
   } satisfies Prisma.RecipeInclude;
 }
 
-/**
- * Every reference `Diet` row (`{ id, key }`), loaded once and memoized —
- * `Diet` is seeded reference data that never changes at runtime, so caching
- * it for the process's lifetime is safe. Used to attach a real `DietView` to
- * the derived gluten-free regime (see {@link loadGlutenFreeDiet}) and to
- * resolve the planning picker's `dietIds` filter / a household's members'
- * regimes for the post-filter in {@link listRecipes}.
- */
-let referenceDietsPromise: Promise<DietView[]> | null = null;
-function loadReferenceDiets(): Promise<DietView[]> {
-  if (referenceDietsPromise === null) {
-    referenceDietsPromise = prisma.diet.findMany({ select: { id: true, key: true } });
-  }
-  return referenceDietsPromise;
-}
-
-/** The reference `glutenFree` {@link DietView} — {@link computeRecipeDietViews} needs it to give the derived gluten-free regime a real `{ id, key }` (no `IngredientDiet` row references it, unlike the other regimes). `undefined` only if the seed somehow lacks the row, in which case gluten-free is simply omitted. */
-async function loadGlutenFreeDiet(): Promise<DietView | undefined> {
-  return (await loadReferenceDiets()).find((diet) => diet.key === "glutenFree");
-}
-
 type RecipeWithDetails = Prisma.RecipeGetPayload<{
   include: ReturnType<typeof recipeInclude>;
 }>;
-/** Exported — `shopping-list.service.ts` fetches its own, narrower ingredient include (no need for a whole `RecipeWithDetails`) but shapes the same `allergies`/`diets` nesting, so it reuses {@link toIngredientView} directly instead of re-deriving this type. */
-export type IngredientWithDetails = RecipeWithDetails["ingredients"][number]["ingredient"];
-/** Exported — see {@link IngredientWithDetails}, same reuse by `shopping-list.service.ts`. `NonNullable` since a `RecipeIngredient.unit` is now `null` on a "selon le goût" line — callers guard that before calling {@link toUnitView}. */
-export type UnitWithDetails = NonNullable<RecipeWithDetails["ingredients"][number]["unit"]>;
+type IngredientWithDetails = RecipeWithDetails["ingredients"][number]["ingredient"];
+type UnitWithDetails = RecipeWithDetails["ingredients"][number]["unit"];
 
-/** Shapes a Prisma `Unit` row into the public {@link UnitView} — same "Decimal → number" conversion `reference.service.ts`'s `getUnits` does. Exported — reused as-is by `shopping-list.service.ts` (a shopping list resolves the same reference data, no need for a second copy of this mapping). */
-export function toUnitView(unit: UnitWithDetails): UnitView {
+/** Shapes a Prisma `Unit` row into the public {@link UnitView} — same "Decimal → number" conversion `reference.service.ts`'s `getUnits` does. */
+function toUnitView(unit: UnitWithDetails): UnitView {
   return {
     id: unit.id,
     key: unit.key,
@@ -118,8 +69,8 @@ export function toUnitView(unit: UnitWithDetails): UnitView {
   };
 }
 
-/** Shapes a Prisma `Ingredient` (with its `allergies`/`diets` relations included) into the public {@link IngredientView} — same flattening as `reference.service.ts`'s `getIngredients`. Exported — see {@link toUnitView}'s doc comment, same reuse by `shopping-list.service.ts`. */
-export function toIngredientView(ingredient: IngredientWithDetails): IngredientView {
+/** Shapes a Prisma `Ingredient` (with its `allergies`/`diets` relations included) into the public {@link IngredientView} — same aplattening as `reference.service.ts`'s `getIngredients`. */
+function toIngredientView(ingredient: IngredientWithDetails): IngredientView {
   return {
     id: ingredient.id,
     key: ingredient.key,
@@ -133,15 +84,13 @@ export function toIngredientView(ingredient: IngredientWithDetails): IngredientV
       kind: allergy.category.kind,
     })),
     diets: ingredient.diets.map(({ diet }) => ({ id: diet.id, key: diet.key })),
-    // A placeholder line round-trips as a normal `Ingredient` with a real
-    // id — the frontend tells it apart by this flag (badge, no
-    // allergen/diet info) and shows `displayName` verbatim instead of
-    // looking up an i18n label that doesn't exist for a `placeholder:` key.
-    isPlaceholder: ingredient.isPlaceholder,
-    displayName: ingredient.displayName,
   };
 }
 
+function toDietView(diet: { id: number; key: string }): DietView {
+  return { id: diet.id, key: diet.key };
+}
+
 /** Deduplicates allergens (by id) across every ingredient of a recipe, for the aggregated "contains" badge — see {@link RecipeSummaryView.allergens}. */
 function aggregateAllergens(ingredients: IngredientView[]): AllergyView[] {
   const byId = new Map<number, AllergyView>();
@@ -153,13 +102,10 @@ function aggregateAllergens(ingredients: IngredientView[]): AllergyView[] {
   return [...byId.values()];
 }
 
-/** Shapes a Prisma `Recipe` (with {@link recipeInclude} included) into the lighter {@link RecipeSummaryView} used by the catalog table — everything `toRecipeView` also needs, factored out since the full detail view is a strict superset. `glutenFreeDiet` (see {@link loadGlutenFreeDiet}) is threaded through only so {@link computeRecipeDietViews} can attach a real `DietView` to the derived gluten-free regime. */
-function toRecipeSummaryView(
-  recipe: RecipeWithDetails,
-  glutenFreeDiet: DietView | undefined,
-): RecipeSummaryView {
-  const ingredientViews = recipe.ingredients.map((recipeIngredient) =>
-    toIngredientView(recipeIngredient.ingredient),
+/** Shapes a Prisma `Recipe` (with {@link recipeInclude} included) into the lighter {@link RecipeSummaryView} used by the catalog table — everything `toRecipeView` also needs, factored out since the full detail view is a strict superset. */
+function toRecipeSummaryView(recipe: RecipeWithDetails): RecipeSummaryView {
+  const allergens = aggregateAllergens(
+    recipe.ingredients.map((recipeIngredient) => toIngredientView(recipeIngredient.ingredient)),
   );
   return {
     id: recipe.id,
@@ -169,9 +115,8 @@ function toRecipeSummaryView(
     portions: recipe.portions,
     authorId: recipe.authorId,
     visibility: recipe.visibility,
-    allergens: aggregateAllergens(ingredientViews),
-    // Computed from the ingredients, not stored — see `RecipeSummaryView.diets`.
-    diets: computeRecipeDietViews(ingredientViews, glutenFreeDiet),
+    allergens,
+    diets: recipe.diets.map((recipeDiet) => toDietView(recipeDiet.diet)),
     isFavorite: recipe.favoritedBy.length > 0,
   };
 }
@@ -198,25 +143,10 @@ export function toStepTechStepViews(
 ): StepTechStepView[] {
   const views: StepTechStepView[] = [];
   for (const stepTechStep of techSteps) {
-    const {
-      start,
-      end,
-      contextStart,
-      contextEnd,
-      techStep,
-      source,
-      ingredients,
-      utensils,
-      temperatures,
-    } = stepTechStep;
+    const { start, end, contextStart, contextEnd, techStep, source } = stepTechStep;
     if (start === null || end === null) continue;
     views.push({
-      techStep: {
-        id: techStep.id,
-        key: techStep.key,
-        isPlaceholder: techStep.isPlaceholder,
-        displayName: techStep.displayName,
-      },
+      techStep: { id: techStep.id, key: techStep.key },
       start,
       end,
       // `source` is a plain DB `String`, not a Prisma enum (see
@@ -227,55 +157,20 @@ export function toStepTechStepViews(
       // `StepTechStepView.source` to the frontend.
       source: source === "manual" ? "manual" : "auto",
       ...(contextStart !== null && contextEnd !== null ? { contextStart, contextEnd } : {}),
-      ingredients: ingredients.map((stepTechStepIngredient) => ({
-        ingredient: toIngredientView(stepTechStepIngredient.ingredient),
-        quantity:
-          stepTechStepIngredient.quantity === null ? null : Number(stepTechStepIngredient.quantity),
-        unit: stepTechStepIngredient.unit === null ? null : toUnitView(stepTechStepIngredient.unit),
-        start: stepTechStepIngredient.start,
-        end: stepTechStepIngredient.end,
-        // Same narrowing posture as the technique's own `source` above.
-        source: stepTechStepIngredient.source === "manual" ? "manual" : "auto",
-      })),
-      utensils: utensils.map((stepTechStepUtensil) => ({
-        utensil: { id: stepTechStepUtensil.utensil.id, key: stepTechStepUtensil.utensil.key },
-        start: stepTechStepUtensil.start,
-        end: stepTechStepUtensil.end,
-        source: stepTechStepUtensil.source === "manual" ? "manual" : "auto",
-      })),
-      temperatures: temperatures.map((stepTechStepTemperature) => ({
-        // `celsius` comes back as a Prisma `Decimal` — plain `number` here,
-        // same treatment as `StepTechStepIngredient.quantity` above.
-        celsius:
-          stepTechStepTemperature.celsius === null ? null : Number(stepTechStepTemperature.celsius),
-        gasMark: stepTechStepTemperature.gasMark,
-        qualitative:
-          stepTechStepTemperature.qualitative === "low" ||
-          stepTechStepTemperature.qualitative === "medium" ||
-          stepTechStepTemperature.qualitative === "high"
-            ? stepTechStepTemperature.qualitative
-            : null,
-        raw: stepTechStepTemperature.raw,
-        start: stepTechStepTemperature.start,
-        end: stepTechStepTemperature.end,
-        // Same narrowing posture as the technique's own `source` above.
-        source: stepTechStepTemperature.source === "manual" ? "manual" : "auto",
-      })),
     });
   }
   return views;
 }
 
-/** Shapes a Prisma `Recipe` (with {@link recipeInclude} included) into the public {@link RecipeView}. `glutenFreeDiet` — see {@link toRecipeSummaryView}. */
-function toRecipeView(recipe: RecipeWithDetails, glutenFreeDiet: DietView | undefined): RecipeView {
+/** Shapes a Prisma `Recipe` (with {@link recipeInclude} included) into the public {@link RecipeView}. */
+function toRecipeView(recipe: RecipeWithDetails): RecipeView {
   const ingredients = recipe.ingredients.map((recipeIngredient) => ({
     ingredient: toIngredientView(recipeIngredient.ingredient),
-    // Both `null` on a "selon le goût" seasoning line — see `RecipeIngredientView`.
-    quantity: recipeIngredient.quantity === null ? null : Number(recipeIngredient.quantity),
-    unit: recipeIngredient.unit === null ? null : toUnitView(recipeIngredient.unit),
+    quantity: Number(recipeIngredient.quantity),
+    unit: toUnitView(recipeIngredient.unit),
   }));
   return {
-    ...toRecipeSummaryView(recipe, glutenFreeDiet),
+    ...toRecipeSummaryView(recipe),
     ingredients,
     steps: recipe.steps.map((step) => ({
       id: step.id,
@@ -328,57 +223,54 @@ function visibleToViewerWhere(
 }
 
 /**
- * The two halves of the planning recipe picker's "convient à tout le foyer"
- * toggle (`suitableForHousehold` on `listRecipes`):
- *  - `allergenWhere` — a `Prisma.RecipeWhereInput` excluding any recipe that
- *    contains an allergen declared by a member (still expressible in SQL).
- *  - `requiredDietKeys` — every regime declared by a member (`omnivore`
- *    dropped: it constrains nothing). A recipe must satisfy *all* of them —
- *    a recipe suiting a vegetarian member doesn't automatically suit a
- *    gluten-free one. Applied as a post-filter in {@link listRecipes} on the
- *    *computed* `RecipeSummaryView.diets`, since regimes are no longer a
- *    stored column to query (issue #131).
- *
- * Computed server-side (a small extra query for the members' allergy/regime
- * data) rather than exposed to the client as raw per-member data: a
- * member's allergies/regime are private the same way visibility already
- * keeps a recipe's existence private. Deliberately excludes
- * `UserProfileDislikedIngredient` — a taste preference, not a safety
- * constraint (see that model's doc comment).
+ * `Recipe` rows that avoid every member of `houseId`'s declared allergens
+ * and, for every member with a declared regime, are tagged with that
+ * regime — the planning recipe picker's "convient à tout le foyer" toggle
+ * (`suitableForHousehold` on `listRecipes`). Computed server-side (a small
+ * extra query to gather the household's members' allergy/regime ids)
+ * rather than exposed to the client as raw per-member data: a member's
+ * allergies/regime are private the same way visibility already keeps a
+ * recipe's existence private (404, never 403) — nothing here should let
+ * one member infer another's medical/dietary info from the shape of a
+ * filtered list. Deliberately excludes `UserProfileDislikedIngredient` —
+ * the schema already treats disliked ingredients as a taste preference,
+ * not a safety constraint (see that model's doc comment), so it doesn't
+ * belong in a filter framed around what's safe/appropriate to serve.
  */
-async function suitableForHousehold(
-  houseId: number,
-): Promise<{ allergenWhere: Prisma.RecipeWhereInput; requiredDietKeys: string[] }> {
+async function suitableForHouseholdWhere(houseId: number): Promise<Prisma.RecipeWhereInput> {
   try {
     const members = await prisma.userProfile.findMany({
       where: { houseId },
-      select: {
-        diet: { select: { key: true } },
-        allergies: { select: { allergyId: true } },
-      },
+      select: { dietId: true, allergies: { select: { allergyId: true } } },
     });
-    const requiredDietKeys = [
-      ...new Set(
-        members
-          .map((member) => member.diet?.key)
-          .filter((key): key is string => key !== undefined && key !== "omnivore"),
-      ),
+    const requiredDietIds = [
+      ...new Set(members.map((m) => m.dietId).filter((id): id is number => id !== null)),
     ];
     const excludedAllergyIds = [
-      ...new Set(members.flatMap((member) => member.allergies.map((allergy) => allergy.allergyId))),
+      ...new Set(members.flatMap((m) => m.allergies.map((a) => a.allergyId))),
     ];
 
-    const allergenWhere: Prisma.RecipeWhereInput =
-      excludedAllergyIds.length > 0
-        ? {
+    const conditions: Prisma.RecipeWhereInput[] = [];
+    if (requiredDietIds.length > 0) {
+      // Every diet declared by a member must be among this recipe's tags —
+      // not "at least one", since a recipe suiting a vegetarian member
+      // doesn't automatically suit a gluten-free one too.
+      conditions.push({
+        AND: requiredDietIds.map((dietId) => ({ diets: { some: { dietId } } })),
+      });
+    }
+    if (excludedAllergyIds.length > 0) {
+      conditions.push({
         ingredients: {
           none: {
-                ingredient: { allergies: { some: { allergyId: { in: excludedAllergyIds } } } },
+            ingredient: {
+              allergies: { some: { allergyId: { in: excludedAllergyIds } } },
             },
           },
+        },
+      });
     }
-        : {};
-    return { allergenWhere, requiredDietKeys };
+    return { AND: conditions };
   } catch (err) {
     // Rethrown as-is — `wrapAsyncHandler`/the error middleware (which
     // already logs it, see `error-logger.ts`) is what actually handles it,
@@ -412,7 +304,7 @@ async function sourceVisibilityWhere(houseId: number | null): Promise<Prisma.Rec
           ).map((row) => row.sourceId);
     return { OR: [{ sourceId: null }, { sourceId: { in: enabledSourceIds } }] };
   } catch (err) {
-    throw err; // see suitableForHousehold()'s catch comment above
+    throw err; // see suitableForHouseholdWhere()'s catch comment above
   }
 }
 
@@ -426,11 +318,11 @@ async function sourceVisibilityWhere(houseId: number | null): Promise<Prisma.Rec
 export interface ListRecipesFilters {
   /** Case-insensitive name substring. */
   search?: string;
-  /** The planning recipe picker's "convient à tout le foyer" toggle — see {@link suitableForHousehold}. */
+  /** The planning recipe picker's "convient à tout le foyer" toggle — see {@link suitableForHouseholdWhere}. */
   suitableForHousehold?: boolean;
   /** Recipe must carry *every* one of these ingredient ids (AND, not "any of") — the planning recipe picker's ingredient filter. */
   ingredientIds?: number[];
-  /** Recipe's *computed* regimes must include *every* one of these diet ids (AND, same reasoning) — the planning recipe picker's regime filter. Applied as a post-filter now that regimes aren't a stored column (issue #131). */
+  /** Recipe must be tagged with *every* one of these diet ids (AND, same reasoning) — the planning recipe picker's regime filter. */
   dietIds?: number[];
 }
 
@@ -450,32 +342,31 @@ export async function listRecipes(
   filters: ListRecipesFilters = {},
 ): Promise<RecipeSummaryView[]> {
   try {
-    const { search, suitableForHousehold: suitable, ingredientIds, dietIds } = filters;
+    const { search, suitableForHousehold, ingredientIds, dietIds } = filters;
     const conditions: Prisma.RecipeWhereInput[] = [await sourceVisibilityWhere(viewerHouseId)];
     if (search) {
       conditions.push({ name: { contains: search, mode: "insensitive" } });
     }
-    // Regimes are computed from ingredients, not a stored column (issue
-    // #131), so the household-regime and `dietIds` filters can't be SQL
-    // anymore — they run as post-filters on the mapped summaries below.
-    // Everything that still *can* be a `where` stays one.
-    let requiredDietKeys: string[] = [];
     // No-op without a household — nothing to filter against, same posture as
     // the `foyer` tab returning everything it can rather than throwing.
-    if (suitable && viewerHouseId !== null) {
-      const household = await suitableForHousehold(viewerHouseId);
-      conditions.push(household.allergenWhere);
-      requiredDietKeys = household.requiredDietKeys;
+    if (suitableForHousehold && viewerHouseId !== null) {
+      conditions.push(await suitableForHouseholdWhere(viewerHouseId));
     }
     if (ingredientIds && ingredientIds.length > 0) {
       // One condition per required id (AND) — a recipe must carry all of
-      // them, not just one.
+      // them, not just one, same "every one, not any one" posture as
+      // suitableForHouseholdWhere's requiredDietIds.
       conditions.push({
         AND: ingredientIds.map((ingredientId) => ({
           ingredients: { some: { ingredientId } },
         })),
       });
     }
+    if (dietIds && dietIds.length > 0) {
+      conditions.push({
+        AND: dietIds.map((dietId) => ({ diets: { some: { dietId } } })),
+      });
+    }
 
     switch (tab) {
       case "favoris":
@@ -495,38 +386,14 @@ export async function listRecipes(
         break;
     }
 
-    const [recipes, referenceDiets] = await Promise.all([
-      prisma.recipe.findMany({
+    const recipes = await prisma.recipe.findMany({
       where: { AND: conditions },
       include: recipeInclude(viewerId),
       orderBy: { name: "asc" },
-      }),
-      loadReferenceDiets(),
-    ]);
-    const glutenFreeDiet = referenceDiets.find((diet) => diet.key === "glutenFree");
-
-    let summaries = recipes.map((recipe) => toRecipeSummaryView(recipe, glutenFreeDiet));
-
-    // Post-filters on the *computed* `diets` (see the comment where the SQL
-    // conditions are built). "Every one, not any one" for both.
-    if (requiredDietKeys.length > 0) {
-      summaries = summaries.filter((summary) =>
-        requiredDietKeys.every((key) => summary.diets.some((diet) => diet.key === key)),
-      );
-    }
-    if (dietIds && dietIds.length > 0) {
-      // `omnivore` in the filter would match nothing (it's never emitted) —
-      // treat it as "no constraint" rather than silently returning an empty list.
-      const requiredIds = dietIds.filter(
-        (id) => referenceDiets.find((diet) => diet.id === id)?.key !== "omnivore",
-      );
-      summaries = summaries.filter((summary) =>
-        requiredIds.every((id) => summary.diets.some((diet) => diet.id === id)),
-      );
-    }
-    return summaries;
+    });
+    return recipes.map(toRecipeSummaryView);
   } catch (err) {
-    throw err; // see suitableForHousehold()'s catch comment above
+    throw err; // see suitableForHouseholdWhere()'s catch comment above
   }
 }
 
@@ -545,23 +412,23 @@ export async function getRecipe(
     if (!canView(recipe, viewerId, viewerHouseId)) {
       throw new HttpError(404, ErrorCode.RECIPE_NOT_FOUND, `Recipe ${id} not found`);
     }
-    return toRecipeView(recipe, await loadGlutenFreeDiet());
+    return toRecipeView(recipe);
   } catch (err) {
-    throw err; // see suitableForHousehold()'s catch comment above
+    throw err; // see suitableForHouseholdWhere()'s catch comment above
   }
 }
 
 /**
- * Creates a recipe with its ingredients and ordered steps in one go —
- * steps' `order` is derived from their position in `input.steps`,
+ * Creates a recipe with its ingredients, ordered steps and diet tags in one
+ * go — steps' `order` is derived from their position in `input.steps`,
  * ingredients reference existing reference `Ingredient` rows by id (see
- * `GET /reference/ingredients`; there's no way to create one here). Its
- * regimes aren't stored — they're computed from the ingredients on read
- * (issue #131). `authorId`/`authorHouseId` are fixed at creation and never
- * change on later edits (see {@link updateRecipe}).
+ * `GET /reference/ingredients`; there's no way to create one here).
+ * `authorId`/`authorHouseId` are fixed at creation and never change on
+ * later edits (see {@link updateRecipe}).
  *
  * @throws {HttpError} `404 INGREDIENT_NOT_FOUND` if any `ingredientId` doesn't match a reference ingredient.
  * @throws {HttpError} `404 UNIT_NOT_FOUND` if any `unitId` doesn't match a reference unit.
+ * @throws {HttpError} `404 DIET_NOT_FOUND` if any `dietId` doesn't match a reference diet.
  */
 export async function createRecipe(
   input: CreateRecipeInput,
@@ -571,7 +438,7 @@ export async function createRecipe(
   try {
     return await createRecipeInternal(input, authorId, authorHouseId, null);
   } catch (err) {
-    throw err; // see suitableForHousehold()'s catch comment above
+    throw err; // see suitableForHouseholdWhere()'s catch comment above
   }
 }
 
@@ -588,6 +455,7 @@ export async function createRecipe(
  *
  * @throws {HttpError} `404 INGREDIENT_NOT_FOUND` if any `ingredientId` doesn't match a reference ingredient.
  * @throws {HttpError} `404 UNIT_NOT_FOUND` if any `unitId` doesn't match a reference unit.
+ * @throws {HttpError} `404 DIET_NOT_FOUND` if any `dietId` doesn't match a reference diet.
  */
 export async function createImportedRecipe(
   input: CreateRecipeInput,
@@ -598,7 +466,7 @@ export async function createImportedRecipe(
   try {
     return await createRecipeInternal(input, authorId, authorHouseId, source);
   } catch (err) {
-    throw err; // see suitableForHousehold()'s catch comment above
+    throw err; // see suitableForHouseholdWhere()'s catch comment above
   }
 }
 
@@ -632,73 +500,6 @@ async function matchStepsTechSteps<T extends { description: string }>(
   );
 }
 
-/** One resolved ingredient line — every `placeholderName` has been turned into a real (placeholder) `ingredientId`, ready for a `RecipeIngredient` create. `quantity`/`unitId` are both `null` for a "selon le goût" seasoning line. */
-interface ResolvedIngredientLine {
-  ingredientId: number;
-  quantity: number | null;
-  unitId: number | null;
-}
-
-/**
- * Turns each `input.ingredients` line into a {@link ResolvedIngredientLine}:
- * a line that already carries an `ingredientId` (a catalog pick, or an
- * existing placeholder round-tripping through an edit) passes through
- * unchanged; a `placeholderName` line gets a fresh placeholder `Ingredient`
- * row (`isPlaceholder: true`, a generated `placeholder:<uuid>` key, the
- * typed text as `displayName`, stamped with `authorId`/now) created via
- * `tx` — so it rolls back together with the recipe if anything later in the
- * same transaction fails, never leaving an orphan behind.
- *
- * Returns the created placeholders separately so the caller can emit one
- * `ingredient.placeholder_created` analytics event per row *after* the
- * transaction commits (the recipe id it wants in the event context doesn't
- * exist yet in here).
- */
-async function resolveIngredientLines(
-  lines: CreateRecipeInput["ingredients"],
-  authorId: number,
-  tx: Prisma.TransactionClient,
-): Promise<{
-  resolved: ResolvedIngredientLine[];
-  createdPlaceholders: { id: number; name: string }[];
-}> {
-  try {
-    const resolved: ResolvedIngredientLine[] = [];
-    const createdPlaceholders: { id: number; name: string }[] = [];
-    for (const line of lines) {
-      if (line.ingredientId !== undefined) {
-        resolved.push({
-          ingredientId: line.ingredientId,
-          quantity: line.quantity ?? null,
-          unitId: line.unitId ?? null,
-        });
-        continue;
-      }
-      // `recipeIngredientInputSchema`'s refine guarantees the other branch.
-      const name = (line.placeholderName ?? "").trim();
-      const placeholder = await tx.ingredient.create({
-        data: {
-          key: `placeholder:${randomUUID()}`,
-          isPlaceholder: true,
-          displayName: name,
-          createdById: authorId,
-          createdAt: new Date(),
-        },
-        select: { id: true },
-      });
-      resolved.push({
-        ingredientId: placeholder.id,
-        quantity: line.quantity ?? null,
-        unitId: line.unitId ?? null,
-      });
-      createdPlaceholders.push({ id: placeholder.id, name });
-    }
-    return { resolved, createdPlaceholders };
-  } catch (err) {
-    throw err; // see suitableForHousehold()'s catch comment above
-  }
-}
-
 async function createRecipeInternal(
   input: CreateRecipeInput,
   authorId: number,
@@ -706,12 +507,9 @@ async function createRecipeInternal(
   source: { sourceId: number; externalId: string; locale: string } | null,
 ): Promise<RecipeView> {
   try {
-    await assertIngredientsExist(
-      input.ingredients.map((i) => i.ingredientId).filter((id): id is number => id !== undefined),
-    );
-    await assertUnitsExist(
-      input.ingredients.flatMap((i) => (i.unitId === undefined ? [] : [i.unitId])),
-    );
+    await assertIngredientsExist(input.ingredients.map((i) => i.ingredientId));
+    await assertUnitsExist(input.ingredients.map((i) => i.unitId));
+    await assertDietsExist(input.dietIds);
     // Matched up front (one call per step, in parallel) rather than inline
     // inside the `steps.create` map below — `techStepClassifier` is async
     // (a trained model, not a pure regex test), so its result has to
@@ -722,16 +520,7 @@ async function createRecipeInternal(
       source?.locale ?? DEFAULT_TECH_STEP_LOCALE,
     );
 
-    // One transaction so the free-text placeholder `Ingredient` rows and the
-    // recipe that references them commit together — a failed recipe create
-    // must never leave orphan placeholders behind.
-    const { created, createdPlaceholders } = await prisma.$transaction(async (tx) => {
-      const { resolved, createdPlaceholders } = await resolveIngredientLines(
-        input.ingredients,
-        authorId,
-        tx,
-      );
-      const created = await tx.recipe.create({
+    const created = await prisma.recipe.create({
       data: {
         name: input.name,
         description: input.description ?? null,
@@ -743,10 +532,10 @@ async function createRecipeInternal(
         sourceId: source?.sourceId ?? null,
         externalId: source?.externalId ?? null,
         ingredients: {
-            create: resolved.map((line) => ({
-              ingredientId: line.ingredientId,
-              quantity: line.quantity,
-              unitId: line.unitId,
+          create: input.ingredients.map((ingredient) => ({
+            ingredientId: ingredient.ingredientId,
+            quantity: ingredient.quantity,
+            unitId: ingredient.unitId,
           })),
         },
         steps: {
@@ -754,49 +543,40 @@ async function createRecipeInternal(
             description: step.description,
             picture: step.picture ?? null,
             order: index,
-              // Technique rows + their clause metadata (ingredients /
-              // utensils / temperatures) — see `toStepTechStepCreateInputs`.
-              // `updateRecipe` below builds the exact same payload from the
-              // same helper so a resave never drops what a create persisted.
-              techSteps: { create: toStepTechStepCreateInputs(matches) },
+            techSteps: {
+              create: matches.map((match, order) => ({
+                techStepId: match.techStepId,
+                start: match.start,
+                end: match.end,
+                contextStart: match.contextStart,
+                contextEnd: match.contextEnd,
+                order,
               })),
             },
+          })),
+        },
+        diets: { create: input.dietIds.map((dietId) => ({ dietId })) },
       },
       include: recipeInclude(authorId),
     });
-      return { created, createdPlaceholders };
-    });
-
-    analytics.recordEvent(source === null ? "recipe.created" : "recipe.imported", {
-      actorId: authorId,
-      context: { recipeId: created.id, sourceId: source?.sourceId ?? null },
-    });
-    for (const placeholder of createdPlaceholders) {
-      analytics.recordEvent("ingredient.placeholder_created", {
-        actorId: authorId,
-        context: { name: placeholder.name, ingredientId: placeholder.id, recipeId: created.id },
-      });
-    }
-
-    return toRecipeView(created, await loadGlutenFreeDiet());
+    return toRecipeView(created);
   } catch (err) {
-    throw err; // see suitableForHousehold()'s catch comment above
+    throw err; // see suitableForHouseholdWhere()'s catch comment above
   }
 }
 
 /**
  * Replaces a recipe's whole content — name/description/picture/visibility
- * and the complete ingredient/step lists (not a partial merge: a line
+ * and the complete ingredient/step/diet lists (not a partial merge: a line
  * missing from `input` is removed, same contract as `PATCH
- * /profile/allergies`). Regimes aren't part of the payload — they're
- * recomputed from the ingredients on the next read (issue #131).
- * `authorId`/`authorHouseId` are untouched — editing never transfers
- * ownership.
+ * /profile/allergies`). `authorId`/`authorHouseId` are untouched — editing
+ * never transfers ownership.
  *
  * @throws {HttpError} `404 RECIPE_NOT_FOUND` if `id` doesn't match any recipe visible to `viewerId`.
  * @throws {HttpError} `403 NOT_RECIPE_AUTHOR` if `viewerId` isn't this recipe's author.
  * @throws {HttpError} `404 INGREDIENT_NOT_FOUND` if any `ingredientId` doesn't match a reference ingredient.
  * @throws {HttpError} `404 UNIT_NOT_FOUND` if any `unitId` doesn't match a reference unit.
+ * @throws {HttpError} `404 DIET_NOT_FOUND` if any `dietId` doesn't match a reference diet.
  */
 export async function updateRecipe(
   id: number,
@@ -806,30 +586,16 @@ export async function updateRecipe(
 ): Promise<RecipeView> {
   try {
     await assertIsAuthor(id, viewerId, viewerHouseId);
-    await assertIngredientsExist(
-      input.ingredients
-        .map((i) => i.ingredientId)
-        .filter((ingredientId): ingredientId is number => ingredientId !== undefined),
-    );
-    await assertUnitsExist(
-      input.ingredients.flatMap((i) => (i.unitId === undefined ? [] : [i.unitId])),
-    );
+    await assertIngredientsExist(input.ingredients.map((i) => i.ingredientId));
+    await assertUnitsExist(input.ingredients.map((i) => i.unitId));
+    await assertDietsExist(input.dietIds);
     const stepsWithTechSteps = await matchStepsTechSteps(input.steps, DEFAULT_TECH_STEP_LOCALE);
 
-    // Interactive transaction (not the array form) so any new free-text
-    // placeholder rows are created in the same atomic unit as the
-    // delete+recreate of the recipe's content. An *existing* placeholder
-    // line round-trips by its real `ingredientId` and is left untouched;
-    // only a brand-new `placeholderName` line creates a row here.
-    const createdPlaceholders = await prisma.$transaction(async (tx) => {
-      await tx.recipeIngredient.deleteMany({ where: { recipeId: id } });
-      await tx.step.deleteMany({ where: { recipeId: id } });
-      const { resolved, createdPlaceholders } = await resolveIngredientLines(
-        input.ingredients,
-        viewerId,
-        tx,
-      );
-      await tx.recipe.update({
+    await prisma.$transaction([
+      prisma.recipeIngredient.deleteMany({ where: { recipeId: id } }),
+      prisma.step.deleteMany({ where: { recipeId: id } }),
+      prisma.recipeDiet.deleteMany({ where: { recipeId: id } }),
+      prisma.recipe.update({
         where: { id },
         data: {
           name: input.name,
@@ -838,10 +604,10 @@ export async function updateRecipe(
           portions: input.portions,
           visibility: input.visibility,
           ingredients: {
-            create: resolved.map((line) => ({
-              ingredientId: line.ingredientId,
-              quantity: line.quantity,
-              unitId: line.unitId,
+            create: input.ingredients.map((ingredient) => ({
+              ingredientId: ingredient.ingredientId,
+              quantity: ingredient.quantity,
+              unitId: ingredient.unitId,
             })),
           },
           steps: {
@@ -849,30 +615,26 @@ export async function updateRecipe(
               description: step.description,
               picture: step.picture ?? null,
               order: index,
-              // Same builder as `createRecipeInternal` — a resave must
-              // persist the clause metadata (ingredients / utensils /
-              // temperatures), not just the technique span. Omitting it
-              // here is what left every edited recipe with temperature-less
-              // `preheat` steps, so `cooking-optimizer.ts` could never spot
-              // an oven-temperature conflict between two of them.
-              techSteps: { create: toStepTechStepCreateInputs(matches) },
+              techSteps: {
+                create: matches.map((match, order) => ({
+                  techStepId: match.techStepId,
+                  start: match.start,
+                  end: match.end,
+                  contextStart: match.contextStart,
+                  contextEnd: match.contextEnd,
+                  order,
                 })),
               },
+            })),
           },
-      });
-      return createdPlaceholders;
-    });
+          diets: { create: input.dietIds.map((dietId) => ({ dietId })) },
+        },
+      }),
+    ]);
 
-    for (const placeholder of createdPlaceholders) {
-      analytics.recordEvent("ingredient.placeholder_created", {
-        actorId: viewerId,
-        context: { name: placeholder.name, ingredientId: placeholder.id, recipeId: id },
-      });
-    }
-
-    return toRecipeView(await findRecipeOrThrow(id, viewerId), await loadGlutenFreeDiet());
+    return toRecipeView(await findRecipeOrThrow(id, viewerId));
   } catch (err) {
-    throw err; // see suitableForHousehold()'s catch comment above
+    throw err; // see suitableForHouseholdWhere()'s catch comment above
   }
 }
 
@@ -905,7 +667,7 @@ export async function deleteRecipe(
 
     await prisma.recipe.delete({ where: { id } });
   } catch (err) {
-    throw err; // see suitableForHousehold()'s catch comment above
+    throw err; // see suitableForHouseholdWhere()'s catch comment above
   }
 }
 
@@ -933,7 +695,7 @@ export async function addFavorite(
       create: { userProfileId: viewerId, recipeId: id },
     });
   } catch (err) {
-    throw err; // see suitableForHousehold()'s catch comment above
+    throw err; // see suitableForHouseholdWhere()'s catch comment above
   }
 }
 
@@ -944,7 +706,7 @@ export async function removeFavorite(id: number, viewerId: number): Promise<void
       where: { userProfileId: viewerId, recipeId: id },
     });
   } catch (err) {
-    throw err; // see suitableForHousehold()'s catch comment above
+    throw err; // see suitableForHouseholdWhere()'s catch comment above
   }
 }
 
@@ -967,7 +729,7 @@ export async function assertRecipeVisible(
       throw new HttpError(404, ErrorCode.RECIPE_NOT_FOUND, `Recipe ${id} not found`);
     }
   } catch (err) {
-    throw err; // see suitableForHousehold()'s catch comment above
+    throw err; // see suitableForHouseholdWhere()'s catch comment above
   }
 }
 
@@ -983,7 +745,7 @@ async function findRecipeOrThrow(id: number, viewerId: number): Promise<RecipeWi
     }
     return recipe;
   } catch (err) {
-    throw err; // see suitableForHousehold()'s catch comment above
+    throw err; // see suitableForHouseholdWhere()'s catch comment above
   }
 }
 
@@ -1002,7 +764,7 @@ async function assertIsAuthor(
       throw new HttpError(403, ErrorCode.NOT_RECIPE_AUTHOR, "Only the recipe's author can do this");
     }
   } catch (err) {
-    throw err; // see suitableForHousehold()'s catch comment above
+    throw err; // see suitableForHouseholdWhere()'s catch comment above
   }
 }
 
@@ -1024,7 +786,7 @@ async function assertIngredientsExist(ingredientIds: number[]): Promise<void> {
       );
     }
   } catch (err) {
-    throw err; // see suitableForHousehold()'s catch comment above
+    throw err; // see suitableForHouseholdWhere()'s catch comment above
   }
 }
 
@@ -1046,6 +808,29 @@ async function assertUnitsExist(unitIds: number[]): Promise<void> {
       );
     }
   } catch (err) {
-    throw err; // see suitableForHousehold()'s catch comment above
+    throw err; // see suitableForHouseholdWhere()'s catch comment above
+  }
+}
+
+/** Throws `404 DIET_NOT_FOUND` if any of `dietIds` doesn't match a reference `Diet` row. */
+async function assertDietsExist(dietIds: number[]): Promise<void> {
+  try {
+    const uniqueIds = [...new Set(dietIds)];
+    if (uniqueIds.length === 0) return;
+    const found = await prisma.diet.findMany({
+      where: { id: { in: uniqueIds } },
+      select: { id: true },
+    });
+    if (found.length !== uniqueIds.length) {
+      const foundIds = new Set(found.map((diet) => diet.id));
+      const missing = uniqueIds.filter((id) => !foundIds.has(id));
+      throw new HttpError(
+        404,
+        ErrorCode.DIET_NOT_FOUND,
+        `Diet(s) not found: ${missing.join(", ")}`,
+      );
+    }
+  } catch (err) {
+    throw err; // see suitableForHouseholdWhere()'s catch comment above
   }
 }

apps/api/src/modules/reference/reference.routes.ts

@@ -6,9 +6,7 @@ import {
   getIngredients,
   getSources,
   getTechSteps,
-  getTours,
   getUnits,
-  getUtensils,
 } from "./reference.service.js";
 
 /**
@@ -57,27 +55,9 @@ referenceRouter.get(
   }),
 );
 
-referenceRouter.get(
-  "/utensils",
-  wrapAsyncHandler(async (_req, res) => {
-    res.status(200).json(await getUtensils());
-  }),
-);
-
 referenceRouter.get(
   "/sources",
   wrapAsyncHandler(async (_req, res) => {
     res.status(200).json(await getSources());
   }),
 );
-
-// Enabled guided-tour scenarios + their steps — read by the web tour
-// engine (issue #42). Public like every route here: the general tour can
-// start right after signup, before onboarding finishes. Admin CRUD of
-// these lives under `/admin/api/tours` (issue #44).
-referenceRouter.get(
-  "/tours",
-  wrapAsyncHandler(async (_req, res) => {
-    res.status(200).json(await getTours());
-  }),
-);

apps/api/src/modules/reference/reference.service.ts

@@ -4,9 +4,7 @@ import type {
   IngredientView,
   SourceView,
   TechStepView,
-  TourScenarioView,
   UnitView,
-  UtensilView,
 } from "@batch-cooking/shared";
 import { prisma } from "../../db/prisma.js";
 
@@ -77,34 +75,11 @@ export async function getUnits(): Promise<UnitView[]> {
 /**
  * All reference cooking techniques, ordered by key (see {@link getDiets}
  * for why) — small, static list (see `reference-seed-data.ts`'s
- * `TECH_STEPS`).
- *
- * Excludes placeholder rows (`TechStep.isPlaceholder` — the free-text
- * techniques users propose when the catalog falls short, issue #130): this
- * is the *browsable* catalog, and a placeholder is a per-correction
- * stand-in, not a real entry anyone should pick again.
+ * `TECH_STEPS`). Not consumed by the recipe UI yet — see {@link TechStepView}.
  */
 export async function getTechSteps(): Promise<TechStepView[]> {
   try {
-    const techSteps = await prisma.techStep.findMany({
-      where: { isPlaceholder: false },
-      select: { id: true, key: true },
-      orderBy: { key: "asc" },
-    });
-    return techSteps.map((techStep) => ({ ...techStep, isPlaceholder: false, displayName: null }));
-  } catch (err) {
-    throw err; // see getDiets()'s catch comment above
-  }
-}
-
-/**
- * All reference cooking utensils, ordered by key (see {@link getDiets} for
- * why) — small, static list (see `reference-seed-data.ts`'s `UTENSILS`),
- * same bare `id`/`key` shape as {@link getTechSteps}.
- */
-export async function getUtensils(): Promise<UtensilView[]> {
-  try {
-    return await prisma.utensil.findMany({ orderBy: { key: "asc" } });
+    return await prisma.techStep.findMany({ orderBy: { key: "asc" } });
   } catch (err) {
     throw err; // see getDiets()'s catch comment above
   }
@@ -144,16 +119,10 @@ export async function getSources(): Promise<SourceView[]> {
  * and compatible diet regimes (see `IngredientDiet`) — same flattening
  * approach as {@link getAllergies}. Ingredients with no linked
  * allergen/diet come back with `allergens: []`/`diets: []`.
- *
- * Excludes placeholder rows (`Ingredient.isPlaceholder` — the free-text
- * ingredients users type when the catalog falls short): this is the
- * *browsable* catalog, and a placeholder is a per-recipe-line stand-in, not
- * a real entry anyone should be able to pick again.
  */
 export async function getIngredients(): Promise<IngredientView[]> {
   try {
     const ingredients = await prisma.ingredient.findMany({
-      where: { isPlaceholder: false },
       include: {
         allergies: { include: { allergy: { include: { category: true } } } },
         diets: { include: { diet: true } },
@@ -176,38 +145,6 @@ export async function getIngredients(): Promise<IngredientView[]> {
         id: diet.id,
         key: diet.key,
       })),
-      // Always a real catalog row here (placeholders are filtered out above).
-      isPlaceholder: false,
-      displayName: null,
-    }));
-  } catch (err) {
-    throw err; // see getDiets()'s catch comment above
-  }
-}
-
-/**
- * Every **enabled** guided-tour scenario with its ordered steps, for the
- * web tour engine (issues #42/#44). A disabled scenario is hidden here
- * without being deleted (an admin can toggle it back on). Steps come back
- * ordered; `route`/`title`/`content` pass straight through.
- */
-export async function getTours(): Promise<TourScenarioView[]> {
-  try {
-    const scenarios = await prisma.tourScenario.findMany({
-      where: { enabled: true },
-      orderBy: { key: "asc" },
-      include: { steps: { orderBy: { order: "asc" } } },
-    });
-    return scenarios.map((scenario) => ({
-      key: scenario.key,
-      name: scenario.name,
-      steps: scenario.steps.map((step) => ({
-        order: step.order,
-        route: step.route,
-        targetKey: step.targetKey,
-        title: step.title,
-        content: step.content,
-      })),
     }));
   } catch (err) {
     throw err; // see getDiets()'s catch comment above

apps/api/src/modules/shopping-list/shopping-list.routes.ts

@@ -1,38 +0,0 @@
-import { parseDateOnly } from "@batch-cooking/date-tools";
-import { HttpError } from "@batch-cooking/error-tools";
-import { wrapAsyncHandler } from "@batch-cooking/express-tools";
-import { ErrorCode, getShoppingListSchema } from "@batch-cooking/shared";
-import { Router } from "express";
-import { analytics } from "../../lib/analytics.service.js";
-import { type AuthLocals, requireAuth } from "../../middlewares/require-auth.js";
-import { getShoppingListForDate } from "./shopping-list.service.js";
-
-/** Router mounted at `/shopping-list` in app.ts. */
-export const shoppingListRouter = Router();
-
-/**
- * Returns the authenticated user's household's shopping list for the week
- * covering `?date=` (`YYYY-MM-DD`) — every ingredient line of every recipe
- * planned that week, summed (see {@link getShoppingListForDate}). Always
- * `200`, never `null` — no household or nothing planned that week both
- * come back as a normal `ShoppingListView` with an empty `items` array.
- */
-shoppingListRouter.get(
-  "/",
-  requireAuth,
-  wrapAsyncHandler<unknown, AuthLocals>(async (req, res) => {
-    const input = getShoppingListSchema.parse(req.query);
-    const date = parseDateOnly(input.date);
-    if (date === null) {
-      throw new HttpError(
-        400,
-        ErrorCode.VALIDATION_ERROR,
-        `Not a real calendar date: ${input.date}`,
-      );
-    }
-
-    const shoppingList = await getShoppingListForDate(res.locals.userProfile.houseId, date);
-    analytics.recordEvent("shopping_list.viewed", { actorId: res.locals.userProfile.id });
-    res.status(200).json(shoppingList);
-  }),
-);

apps/api/src/modules/shopping-list/shopping-list.service.ts

@@ -1,174 +0,0 @@
-import { type DateTime, getWeekStart, toDateOnly } from "@batch-cooking/date-tools";
-import type {
-  IngredientView,
-  ShoppingListItemView,
-  ShoppingListView,
-  UnitView,
-} from "@batch-cooking/shared";
-import type { Prisma } from "@prisma/client";
-import { prisma } from "../../db/prisma.js";
-import { toIngredientView, toUnitView } from "../recipe/recipe.service.js";
-
-/** Prisma `include` for a `Planning` query that needs, for every item, just enough of its recipe to compute a shopping list — `portions` (to scale `RecipeIngredient.quantity`) and the ingredient lines themselves, each resolved the same way `recipe.service.ts`'s own `recipeInclude` resolves them (so {@link toIngredientView}/{@link toUnitView} can be reused as-is). Deliberately narrower than a full `RecipeView` fetch — steps/diets/favorites are never read here. */
-function shoppingListPlanningInclude() {
-  return {
-    items: {
-      // "Leftovers" items (`sourcePlanningItemId` set) reserve a portion of
-      // an already-cooked batch — nothing new to buy for them. Excluded
-      // here so they never reach `aggregateShoppingList`; counting them
-      // would double up the source recipe's ingredients (issue #34).
-      where: { sourcePlanningItemId: null },
-      include: {
-        recipe: {
-          select: {
-            portions: true,
-            ingredients: {
-              include: {
-                ingredient: {
-                  include: {
-                    allergies: { include: { allergy: { include: { category: true } } } },
-                    diets: { include: { diet: true } },
-                  },
-                },
-                unit: true,
-              },
-            },
-          },
-        },
-      },
-    },
-  } satisfies Prisma.PlanningInclude;
-}
-
-type PlanningWithIngredients = Prisma.PlanningGetPayload<{
-  include: ReturnType<typeof shoppingListPlanningInclude>;
-}>;
-
-/** Accumulates a running sum per `(ingredientId, unitId)` pair while walking every planning item's ingredient lines — see {@link aggregateShoppingList}. `unit`/`quantity` are both `null` for a "selon le goût" seasoning line: nothing to sum, surfaced once. */
-interface RunningTotal {
-  ingredient: IngredientView;
-  unit: UnitView | null;
-  quantity: number | null;
-}
-
-/**
- * Sums every ingredient line across `items`, each scaled by that planning
- * item's own portion count relative to its recipe's as-written yield
- * (`RecipeIngredient.quantity × PlanningItem.portions / Recipe.portions`,
- * see `PlanningItem.portions`'s doc comment in schema.prisma for why the
- * two can differ). Grouped by `(ingredientId, unitId)` — **not** just
- * `ingredientId` — since summing across units isn't implemented yet (see
- * `ShoppingListItemView`'s doc comment): the same ingredient requested in
- * two different units stays two separate lines rather than silently
- * guessing a conversion. Pure/synchronous, factored out from
- * {@link getShoppingListForDate} so the aggregation itself is testable
- * without a database round-trip.
- */
-function aggregateShoppingList(items: PlanningWithIngredients["items"]): ShoppingListItemView[] {
-  const totals = new Map<string, RunningTotal>();
-
-  for (const item of items) {
-    const scale = item.portions / item.recipe.portions;
-    for (const recipeIngredient of item.recipe.ingredients) {
-      // A "selon le goût" seasoning line (no quantity/unit) — surfaced once
-      // per ingredient, never scaled or summed. Its key can't collide with a
-      // real `(ingredient, unit)` line for the same ingredient.
-      if (recipeIngredient.quantity === null) {
-        const seasoningKey = `${recipeIngredient.ingredientId}:toTaste`;
-        if (!totals.has(seasoningKey)) {
-          totals.set(seasoningKey, {
-            ingredient: toIngredientView(recipeIngredient.ingredient),
-            unit: null,
-            quantity: null,
-          });
-        }
-        continue;
-      }
-
-      const key = `${recipeIngredient.ingredientId}:${recipeIngredient.unitId}`;
-      const addedQuantity = Number(recipeIngredient.quantity) * scale;
-
-      const existing = totals.get(key);
-      if (existing && existing.quantity !== null) {
-        existing.quantity += addedQuantity;
-      } else {
-        totals.set(key, {
-          ingredient: toIngredientView(recipeIngredient.ingredient),
-          unit: recipeIngredient.unit === null ? null : toUnitView(recipeIngredient.unit),
-          quantity: addedQuantity,
-        });
-      }
-    }
-  }
-
-  // Deterministic order (by the ingredient's stable `key`, not its id —
-  // insertion order would otherwise depend on which recipe happened to be
-  // read first) — the frontend re-sorts by translated label/aisle for
-  // display, this is just so two identical plannings always produce the
-  // same JSON.
-  return [...totals.values()].sort((a, b) => a.ingredient.key.localeCompare(b.ingredient.key));
-}
-
-/**
- * Builds the household's shopping list for the week covering `date` —
- * every ingredient line of every recipe planned that week, aggregated (see
- * {@link aggregateShoppingList}). `date` is whatever the caller wants "that
- * week" to mean, same convention as `planning.service.ts`'s
- * `getPlanningForDate` (a caller-parsed `?date=`, not necessarily a
- * Monday).
- *
- * Unlike `getPlanningForDate`, this **never** returns `null` — no household
- * and "no planning covers this week yet" both degrade to an empty `items`
- * array on an otherwise normal `ShoppingListView` (the week's date range is
- * always computable from `date` alone, even with nothing planned in it),
- * rather than a separate "nothing to show" state the frontend would have to
- * branch on.
- */
-export async function getShoppingListForDate(
-  houseId: number | null,
-  date: DateTime,
-): Promise<ShoppingListView> {
-  try {
-    const weekStart = getWeekStart(toDateOnly(date));
-    const weekFinish = weekStart.plus({ days: 6 });
-    const emptyList: ShoppingListView = {
-      startDate: weekStart.toJSDate().toISOString(),
-      finishDate: weekFinish.toJSDate().toISOString(),
-      items: [],
-    };
-
-    if (houseId === null) {
-      return emptyList;
-    }
-
-    // Same "covering range" lookup as getPlanningForDate — see that
-    // function's doc comment for why this compares against a UTC-midnight
-    // JS Date rather than `weekStart`/`weekFinish` directly.
-    const dateOnly = toDateOnly(date).toJSDate();
-    const planning = await prisma.planning.findFirst({
-      where: {
-        houseId,
-        startDate: { lte: dateOnly },
-        finishDate: { gte: dateOnly },
-      },
-      orderBy: { startDate: "desc" },
-      include: shoppingListPlanningInclude(),
-    });
-
-    if (!planning) {
-      return emptyList;
-    }
-
-    return {
-      startDate: planning.startDate.toISOString(),
-      finishDate: planning.finishDate.toISOString(),
-      items: aggregateShoppingList(planning.items),
-    };
-  } catch (err) {
-    // Rethrown as-is — `wrapAsyncHandler`/the error middleware (which
-    // already logs it, see `error-logger.ts`) is what actually handles it,
-    // this service layer just isn't allowed a bare `await` per the repo's
-    // async/try-catch convention.
-    throw err;
-  }
-}

apps/api/src/modules/sources/sources.service.ts

@@ -11,8 +11,10 @@ import {
 import { prisma } from "../../db/prisma.js";
 import { findImportedRecipeIds } from "../../db/recipe-source-sync.js";
 import {
+  type IngredientMatchEntry,
   loadIngredientCatalog,
   loadUnitCatalog,
+  type UnitMatchEntry,
 } from "../../lib/recipe-matching/ingredient-matcher.js";
 import {
   mergeDuplicateIngredients,
@@ -27,7 +29,7 @@ import { RecipeSourceError } from "../../lib/recipe-sources/recipe-source-errors
 import { getRecipeSource } from "../../lib/recipe-sources/recipe-source-registry.js";
 import { getHouseSourceIds } from "../house/house.service.js";
 import { createImportedRecipe } from "../recipe/recipe.service.js";
-import { getIngredients, getUnits, getUtensils } from "../reference/reference.service.js";
+import { getIngredients, getUnits } from "../reference/reference.service.js";
 
 /**
  * Browsing, previewing, and importing a household's *enabled* external
@@ -139,13 +141,10 @@ export async function browseSource(
  * techniques with their exact matched span (`matchTechStepSpans`, the same
  * function `recipe.service.ts` uses at real save time — see its doc
  * comment), all against `adapter.locale`'s catalogs. Ingredient/unit
- * matching has data for `"en"`/`"fr"` today (see `ingredient-matcher.ts`);
- * `loadIngredientCatalog`/`loadUnitCatalog` are always called with
- * `adapter.locale` directly, never specially skipped for a particular
- * one — a source whose locale has no label table of its own just gets back
- * empty catalogs from those two loaders, so every line's `ingredient`/
- * `unit` end up `null` the same way, the same graceful "no
- * matching-language data" degradation `translateRecipe` already has.
+ * matching itself only has English data today (see `ingredient-matcher.ts`);
+ * a non-English-locale source simply gets `ingredient`/`unit: null` on
+ * every line, the same graceful "no matching-language data" degradation
+ * `translateRecipe` already has.
  *
  * @throws {HttpError} `404 HOUSE_NOT_FOUND` if the profile has no household yet.
  * @throws {HttpError} `404 SOURCE_NOT_FOUND` if `sourceKey` doesn't match a source enabled for this household.
@@ -178,37 +177,22 @@ export async function previewSourceItem(
             matches: await techStepClassifier.matchTechStepSpans(step.description, adapter.locale),
           })),
         ),
-        loadIngredientCatalog(adapter.locale),
-        loadUnitCatalog(adapter.locale),
-        // Real catalog techniques only — a draft preview is never a saved
-        // recipe, so it can't carry a user-proposed placeholder technique
-        // (issue #130); `isPlaceholder`/`displayName` are the neutral values.
-        prisma.techStep.findMany({
-          where: { isPlaceholder: false },
-          select: { id: true, key: true },
-        }),
+        adapter.locale === "en"
+          ? loadIngredientCatalog()
+          : Promise.resolve<IngredientMatchEntry[]>([]),
+        adapter.locale === "en" ? loadUnitCatalog() : Promise.resolve<UnitMatchEntry[]>([]),
+        prisma.techStep.findMany({ select: { id: true, key: true } }),
       ]);
-    const techStepById = new Map(
-      techStepsByKey.map((techStep) => [
-        techStep.id,
-        { ...techStep, isPlaceholder: false, displayName: null },
-      ]),
-    );
+    const techStepById = new Map(techStepsByKey.map((techStep) => [techStep.id, techStep]));
 
     const translatedIngredients = translateRecipeIngredients(
       parsed.ingredients,
       ingredientCatalog,
       unitCatalog,
-      adapter.locale,
     );
-    const [ingredientViews, unitViews, utensilViews] = await Promise.all([
-      getIngredients(),
-      getUnits(),
-      getUtensils(),
-    ]);
+    const [ingredientViews, unitViews] = await Promise.all([getIngredients(), getUnits()]);
     const ingredientById = new Map(ingredientViews.map((view) => [view.id, view]));
     const unitById = new Map(unitViews.map((view) => [view.id, view]));
-    const utensilById = new Map(utensilViews.map((view) => [view.id, view]));
 
     // A source's raw ingredient lines aren't deduplicated by the matcher —
     // two different lines (e.g. "Egg Yolks"/"Eggs") can resolve to the same
@@ -247,36 +231,6 @@ export async function previewSourceItem(
                 // comment) — always the classifier's own live match,
                 // never a correction, so always "auto".
                 source: "auto",
-                ingredients: match.ingredients.flatMap((mention) => {
-                  const ingredient = ingredientById.get(mention.ingredientId);
-                  // Same drift guard as `techStep` above — an ingredientId
-                  // the matcher resolved but that's since vanished from the
-                  // catalog is dropped rather than shown with a hole in it.
-                  if (!ingredient) return [];
-                  return [
-                    {
-                      ingredient,
-                      quantity: mention.quantity,
-                      unit: mention.unitId !== null ? (unitById.get(mention.unitId) ?? null) : null,
-                      start: mention.start,
-                      end: mention.end,
-                      // Same reasoning as this match's own `source` above — a draft preview only ever holds live classifier output.
-                      source: "auto" as const,
-                    },
-                  ];
-                }),
-                utensils: match.utensils.flatMap((mention) => {
-                  const utensil = utensilById.get(mention.utensilId);
-                  return utensil
-                    ? [{ utensil, start: mention.start, end: mention.end, source: "auto" as const }]
-                    : [];
-                }),
-                // Regex-extracted, no id to resolve — carried through as-is
-                // (same `source: "auto"` reasoning as this match above).
-                temperatures: match.temperatures.map((mention) => ({
-                  ...mention,
-                  source: "auto" as const,
-                })),
               },
             ]
           : [];

apps/api/src/scripts/backfill-runtime.ts

@@ -1,72 +0,0 @@
-import { prisma } from "../db/prisma.js";
-import { backfillTechSteps } from "./backfill-tech-steps.js";
-
-/**
- * `backfill_state.key` for the tech-step clause-metadata backfill. Opaque,
- * dated so a future metadata rework can add a second key rather than
- * re-using this one.
- *
- * Why it's needed: `updateRecipe` and `backfill-tech-steps.ts` used to
- * persist only a detected technique's span, never its ingredient / utensil /
- * temperature children (only `createRecipeInternal` did). So every recipe
- * ever edited through the UI, and every recipe imported before the create
- * path learned temperatures, is missing the clause metadata that
- * `cooking-optimizer.ts` needs to spot an oven-temperature conflict between
- * two `preheat` steps. {@link backfillTechSteps} recomputes the whole
- * `StepTechStep` sequence with the now-complete writer.
- */
-const TECH_STEP_METADATA_BACKFILL_KEY = "step_tech_step_metadata_20260904";
-
-/**
- * One-time data backfills for the production image — run via
- * `node dist/scripts/backfill-runtime.js` in apps/api/Dockerfile's CMD,
- * after `seed-runtime` and before the server starts.
- *
- * Unlike `seed-runtime` (idempotent by construction — it only upserts, so
- * repeating it every container start is free), a backfill here *rewrites*
- * existing rows and would be wasteful-to-harmful to repeat: the tech-step
- * one re-hits `services/tech-step-intent-service` once per `Step`. So each
- * backfill gates itself on a `backfill_state` row — present means "done,
- * skip"; absent means "run it, then record it".
- *
- * A backfill failing must **not** keep the API down: it's a data-quality
- * catch-up, not a correctness prerequisite (contrast `seed-runtime`, whose
- * failure genuinely means missing reference data). So a failure here is
- * logged, the marker is left unwritten (the next container start retries),
- * and the process still exits 0 so the CMD chain reaches `node dist/server.js`.
- * Only a failure to even read `backfill_state` propagates — at that point
- * the database is unreachable and the server wouldn't start anyway.
- */
-async function runOneTimeBackfills(): Promise<void> {
-  const alreadyDone = await prisma.backfillState.findUnique({
-    where: { key: TECH_STEP_METADATA_BACKFILL_KEY },
-  });
-  if (alreadyDone !== null) {
-    console.info(
-      `Backfill "${TECH_STEP_METADATA_BACKFILL_KEY}" already completed at ${alreadyDone.completedAt.toISOString()} — skipping.`,
-    );
-    return;
-  }
-
-  console.info(`Running one-time backfill "${TECH_STEP_METADATA_BACKFILL_KEY}"...`);
-  try {
-    const { total, changed } = await backfillTechSteps();
-    await prisma.backfillState.create({ data: { key: TECH_STEP_METADATA_BACKFILL_KEY } });
-    console.info(
-      `Backfill "${TECH_STEP_METADATA_BACKFILL_KEY}" done — ${changed}/${total} step(s) recomputed.`,
-    );
-  } catch (err) {
-    console.error(
-      `Backfill "${TECH_STEP_METADATA_BACKFILL_KEY}" failed — leaving it unrecorded so the next start retries. The API will still start.`,
-      err,
-    );
-  }
-}
-
-runOneTimeBackfills()
-  .then(() => prisma.$disconnect())
-  .catch(async (err) => {
-    console.error(err);
-    await prisma.$disconnect();
-    process.exit(1);
-  });

apps/api/src/scripts/backfill-tech-steps.ts

@@ -1,27 +1,23 @@
 import { pathToFileURL } from "node:url";
 import { prisma } from "../db/prisma.js";
 import { techStepClassifier } from "../lib/recipe-matching/tech-step-matcher.js";
-import { toStepTechStepCreateInputs } from "../lib/recipe-matching/tech-step-persistence.js";
 import { renumberStepTechSteps } from "../modules/recipe/recipe-tech-step-correction.service.js";
 
 /**
  * Recomputes every existing `Step`'s `"auto"`-sourced `StepTechStep`
- * entries — technique spans **and** their clause metadata (ingredients,
- * utensils, temperatures) — against the *current* classifier
- * (`tech-step-matcher.ts`, delegating to `services/tech-step-intent-service`),
- * the same way `updateRecipe` does when a user resaves a recipe through the
- * UI: both build the row payload from the shared
- * {@link toStepTechStepCreateInputs}. Always `"fr"`
- * (`DEFAULT_TECH_STEP_LOCALE` in `recipe.service.ts`; there's no persisted
- * per-recipe locale to recover for a step that already exists, so this
- * matches real resave behavior exactly rather than guessing).
+ * entries against the *current* classifier
+ * (`tech-step-matcher.ts`/`tech-step-training-data.ts`), the same way
+ * `updateRecipe` does when a user resaves a recipe through the UI —
+ * always `"fr"` (`DEFAULT_TECH_STEP_LOCALE` in `recipe.service.ts`; there's
+ * no persisted per-recipe locale to recover for a step that already
+ * exists, so this matches real resave behavior exactly rather than
+ * guessing).
  *
  * Needed because tech-step detection only ever runs at create/update time
  * (`recipe.service.ts`'s `matchStepsTechSteps`), never retroactively — a
  * step saved before a classifier/corpus change (new vocabulary, or the
- * `contextStart`/`contextEnd` columns a previous session added), or before
- * the clause-metadata writers were wired into the *update* path at all,
- * keeps whatever it was matched with at the time until it's next resaved.
+ * `contextStart`/`contextEnd` columns a previous session added) keeps
+ * whatever it was matched with at the time until it's next resaved.
  *
  * `"manual"`-sourced entries (a viewer's correction, applied immediately —
  * see `recipe-tech-step-correction.service.ts`'s `applyManualCorrection`)
@@ -76,20 +72,19 @@ export async function backfillTechSteps(): Promise<{ total: number; changed: num
         // into a clean 0..N-1 sequence right after — these just need to
         // not collide with `@@id([stepId, order])` for this insert).
         const startOrder = manualRows.reduce((max, row) => Math.max(max, row.order), -1) + 1;
-        // One `create` per row rather than a single `createMany`:
-        // `createMany` cannot write the nested `ingredients` / `utensils` /
-        // `temperatures` children, and silently dropping those is exactly
-        // the bug this script shared with the old `updateRecipe` — see
-        // `toStepTechStepCreateInputs`. A backfill that leaves recipes
-        // without their clause temperatures defeats the whole point of
-        // running it (`cooking-optimizer.ts` needs them).
-        const inputs = toStepTechStepCreateInputs(nonOverlappingMatches);
-        for (const [index, input] of inputs.entries()) {
-          await tx.stepTechStep.create({
-            data: { ...input, stepId: step.id, order: startOrder + index, source: "auto" },
+        await tx.stepTechStep.createMany({
+          data: nonOverlappingMatches.map((match, index) => ({
+            stepId: step.id,
+            techStepId: match.techStepId,
+            order: startOrder + index,
+            start: match.start,
+            end: match.end,
+            contextStart: match.contextStart,
+            contextEnd: match.contextEnd,
+            source: "auto",
+          })),
         });
       }
-      }
 
       await renumberStepTechSteps(tx, step.id);
     });

apps/api/src/scripts/calibrate-tech-step-threshold.ts

@@ -1,101 +0,0 @@
-import { prisma } from "../db/prisma.js";
-import { TECH_STEP_EVAL_DATASET } from "../lib/recipe-matching/tech-step-eval-dataset.js";
-import {
-  computeTechStepMetrics,
-  type TechStepEvalOutcome,
-} from "../lib/recipe-matching/tech-step-evaluator.js";
-import { techStepClassifier } from "../lib/recipe-matching/tech-step-matcher.js";
-
-/**
- * Candidate thresholds to sweep, `0.05` to `0.95` in `0.05` steps — fine
- * enough to find a good value without an unreasonable number of full
- * `TECH_STEP_EVAL_DATASET` passes (each threshold only needs one
- * {@link techStepClassifier.classifyClauses} call per eval case, not a
- * retrain — see this file's own doc comment for why).
- */
-const CANDIDATE_THRESHOLDS = Array.from({ length: 19 }, (_, i) => Math.round((i + 1) * 5) / 100);
-
-/**
- * One-off maintainer tool for recalibrating `CONFIDENCE_THRESHOLD`
- * (`tech-step-matcher.ts`) after a change to the underlying intent
- * classifier — most notably, the migration from `node-nlp` to
- * `services/tech-step-intent-service` (spaCy): a different model produces a
- * differently-shaped confidence score distribution, so a threshold tuned
- * against the old classifier has no reason to still be the right cutoff for
- * the new one.
- *
- * Reuses `techStepClassifier.classifyClauses` — already public, and
- * deliberately *not* threshold-applied (see that method's own doc comment)
- * — to get every eval case's raw `{anchorUid, intentUid, score}` per clause
- * exactly once, then replays `_classifyClause`'s own decision rule
- * (`intentUid` if confident enough, `anchorUid` otherwise) locally in this
- * script for every candidate threshold. This is what makes a full sweep
- * cheap: one classifier pass per eval case regardless of how many
- * thresholds are being compared, rather than one full pass *per threshold*.
- *
- * Prints a threshold -> precision/recall/F1 table and the threshold that
- * maximizes aggregate F1 — does **not** edit `tech-step-matcher.ts` itself.
- * A maintainer reads the table, updates `CONFIDENCE_THRESHOLD` by hand (with
- * an updated doc comment recording what run/F1 the new value was calibrated
- * against, same as the existing comment's own format), then re-runs
- * `retrain-tech-steps.ts` to confirm the change clears `MIN_OVERALL_F1`.
- *
- * Usage:
- *
- *   pnpm --filter api exec tsx src/scripts/calibrate-tech-step-threshold.ts
- */
-async function calibrateTechStepThreshold(): Promise<void> {
-  console.info(`Classifying ${TECH_STEP_EVAL_DATASET.length} eval case(s)...`);
-
-  // One classifier pass per eval case, all clauses' raw verdicts kept
-  // alongside the case's own `expectedKeys` — reused for every candidate
-  // threshold in the loop below.
-  const casesWithClauses = await Promise.all(
-    TECH_STEP_EVAL_DATASET.map(async (evalCase) => ({
-      expectedKeys: evalCase.expectedKeys,
-      clauses: await techStepClassifier.classifyClauses(evalCase.description, evalCase.locale),
-    })),
-  );
-
-  console.info("\nthreshold  precision  recall     f1");
-  let bestThreshold = CANDIDATE_THRESHOLDS[0] ?? 0;
-  let bestF1 = -1;
-
-  for (const threshold of CANDIDATE_THRESHOLDS) {
-    const outcomes: TechStepEvalOutcome[] = casesWithClauses.map(({ expectedKeys, clauses }) => {
-      const actualKeys = clauses
-        // Mirrors `_classifyClause`'s own decision rule exactly (see that
-        // method, `tech-step-matcher.ts`) — the classifier's own verdict
-        // when confident enough, otherwise its clause's NER anchor, `null`
-        // when neither applies (no keyword, no confident classification).
-        .map((clause) =>
-          clause.intentUid !== null && clause.score >= threshold
-            ? clause.intentUid
-            : clause.anchorUid,
-        )
-        .filter((key): key is string => key !== null);
-      return { expectedKeys, actualKeys };
-    });
-
-    const { overall } = computeTechStepMetrics(outcomes);
-    console.info(
-      `${threshold.toFixed(2)}       ${overall.precision.toFixed(3)}      ${overall.recall.toFixed(3)}      ${overall.f1.toFixed(3)}`,
-    );
-    if (overall.f1 > bestF1) {
-      bestF1 = overall.f1;
-      bestThreshold = threshold;
-    }
-  }
-
-  console.info(
-    `\nBest aggregate F1 ${bestF1.toFixed(3)} at threshold ${bestThreshold.toFixed(2)} — update CONFIDENCE_THRESHOLD in tech-step-matcher.ts by hand if this differs from the current value.`,
-  );
-}
-
-calibrateTechStepThreshold()
-  .then(() => prisma.$disconnect())
-  .catch(async (err) => {
-    console.error(err);
-    await prisma.$disconnect();
-    process.exit(1);
-  });

apps/api/src/scripts/create-admin.ts

@@ -1,56 +0,0 @@
-import { env } from "../config/env.js";
-import { prisma } from "../db/prisma.js";
-import { hashAdminPassword } from "../modules/admin/admin-auth.service.js";
-
-/**
- * Creates the first (or an additional) `AdminUser` for the admin
- * application — there is no self-service admin signup, on purpose (see the
- * `AdminUser` model doc comment in schema.prisma).
- *
- *   pnpm --filter api exec tsx src/scripts/create-admin.ts \
- *     --email=ops@example.com --password='...' --name='Ops'
- *
- * Each flag falls back to the matching `ADMIN_INITIAL_*` env var when
- * omitted, so a deployment can bake the first admin's credentials into its
- * environment and run this once from the container without passing args.
- * Refuses (exit 1) if an `AdminUser` with that email already exists —
- * changing an existing admin's password is a manual DB operation for now,
- * not something this script does.
- */
-function flag(name: string): string | undefined {
-  const prefix = `--${name}=`;
-  const arg = process.argv.find((value) => value.startsWith(prefix));
-  return arg === undefined ? undefined : arg.slice(prefix.length);
-}
-
-async function createAdmin(): Promise<void> {
-  const email = (flag("email") ?? env.ADMIN_INITIAL_EMAIL)?.trim().toLowerCase();
-  const password = flag("password") ?? env.ADMIN_INITIAL_PASSWORD;
-  const name = (flag("name") ?? env.ADMIN_INITIAL_NAME)?.trim();
-
-  if (!email || !password || !name) {
-    throw new Error(
-      "Missing required input. Provide --email, --password and --name (or set ADMIN_INITIAL_EMAIL / ADMIN_INITIAL_PASSWORD / ADMIN_INITIAL_NAME).",
-    );
-  }
-  if (password.length < 8) {
-    throw new Error("Password must be at least 8 characters.");
-  }
-
-  const existing = await prisma.adminUser.findUnique({ where: { email } });
-  if (existing) {
-    throw new Error(`An admin with email "${email}" already exists (id ${existing.id}).`);
-  }
-
-  const passwordHash = await hashAdminPassword(password);
-  const admin = await prisma.adminUser.create({ data: { email, name, passwordHash } });
-  console.info(`Created admin #${admin.id} <${admin.email}> ("${admin.name}").`);
-}
-
-createAdmin()
-  .then(() => prisma.$disconnect())
-  .catch(async (err) => {
-    console.error(err instanceof Error ? err.message : err);
-    await prisma.$disconnect();
-    process.exit(1);
-  });

apps/api/src/scripts/list-pending-training-suggestions.ts

@@ -6,15 +6,14 @@ import { prisma } from "../db/prisma.js";
  * comment) — generated by `services/tech-step-llm-worker`'s scheduled
  * jobs, from either a user correction or the worker's own low-confidence
  * audit (`sourceType`). What a maintainer reads *before* hand-editing
- * `services/tech-step-intent-service/intent_service/training_data.py` and
- * running `retrain-tech-steps.ts` — this script never writes anything,
- * purely a read-only report to stdout:
+ * `tech-step-training-data.ts` and running `retrain-tech-steps.ts` — this
+ * script never writes anything, purely a read-only report to stdout:
  *
  *   pnpm --filter api exec tsx src/scripts/list-pending-training-suggestions.ts
  *
  * Grouped by technique key so every suggestion for the same entry in
- * `training_data.py`'s `TECH_STEP_TRAINING_DATA` is read together, matching
- * how that file itself is organized (one block per technique).
+ * `TECH_STEP_TRAINING_DATA` is read together, matching how that file
+ * itself is organized (one block per technique).
  */
 async function listPendingTrainingSuggestions(): Promise<void> {
   const suggestions = await prisma.techStepTrainingSuggestion.findMany({

apps/api/src/scripts/prune-orphan-placeholders.ts

@@ -1,27 +0,0 @@
-import { prisma } from "../db/prisma.js";
-import { pruneOrphanPlaceholders } from "../modules/admin/admin-catalog.service.js";
-
-/**
- * Deletes every placeholder `Ingredient` row (`Ingredient.isPlaceholder`)
- * that no recipe references any more — the debris left behind when a recipe
- * edit drops a placeholder line (the `RecipeIngredient` row goes, the
- * `Ingredient` row stays). The admin catalog view has a button for this
- * too; this script is the same operation for a cron / one-off cleanup:
- *
- *   pnpm --filter api exec tsx src/scripts/prune-orphan-placeholders.ts
- *
- * Delegates to `admin-catalog.service.ts` so the "what counts as an orphan"
- * rule lives in exactly one place.
- */
-async function main(): Promise<void> {
-  const { deleted } = await pruneOrphanPlaceholders();
-  console.info(`Pruned ${deleted} orphan placeholder ingredient(s).`);
-}
-
-main()
-  .then(() => prisma.$disconnect())
-  .catch(async (err) => {
-    console.error(err);
-    await prisma.$disconnect();
-    process.exit(1);
-  });

apps/api/src/scripts/retrain-tech-steps.ts

@@ -28,15 +28,10 @@ function parseSuggestionIds(flag: "applied" | "rejected"): number[] {
  * Maintainer workflow closing the loop on a training-corpus change (see
  * this feature's plan document):
  *
- *   1. A maintainer has already hand-edited
- *      `services/tech-step-intent-service/intent_service/training_data.py`
- *      (informed by `list-pending-training-suggestions.ts`'s report),
+ *   1. A maintainer has already hand-edited `tech-step-training-data.ts`
+ *      (informed by `list-pending-training-suggestions.ts`'s report), and
  *      decided which `TechStepTrainingSuggestion` ids they incorporated
- *      (`--applied=`) or explicitly discarded (`--rejected=`), **and
- *      restarted `tech-step-intent-service`** so it retrains from the
- *      edited corpus — that service only ever trains once, at its own
- *      startup (see its README), so this script's eval gate below is
- *      meaningless against a service still running the old corpus.
+ *      (`--applied=`) or explicitly discarded (`--rejected=`).
  *   2. This script re-runs the F1 regression gate
  *      ({@link runTechStepEvalSuite} against {@link MIN_OVERALL_F1}) —
  *      refuses to backfill at all if the edited corpus scores worse than

apps/api/src/server.ts

@@ -1,8 +1,6 @@
-import { Server as SocketIoServer } from "socket.io";
 import { createServer } from "./app.js";
 import { env } from "./config/env.js";
 import { logger } from "./lib/logger.service.js";
-import { MonitoringBroadcastService } from "./lib/monitoring-broadcast.service.js";
 import { techStepClassifier } from "./lib/recipe-matching/tech-step-matcher.js";
 import { registerAllRecipeSources } from "./sources/index.js";
 
@@ -11,58 +9,24 @@ import { registerAllRecipeSources } from "./sources/index.js";
 // doesn't happen inside app.ts/createServer() itself.
 registerAllRecipeSources();
 
-/**
- * Trains the tech-step classifier (a `POST /v1/train` round-trip per locale
- * to `services/tech-step-intent-service` — see
- * `TechStepClassifierService.warmUp`) before accepting any traffic, so the
- * first real recipe save/preview isn't the one stuck waiting for it.
- *
- * Retried with exponential backoff: in Docker Compose, `app`'s own
- * `depends_on: tech-step-intent-service: condition: service_healthy`
- * (`docker-compose.yml`) already means that service is up by the time this
- * runs, but native dev (`pnpm dev:api`, no Compose ordering at all) can
- * easily start this before the intent service has finished loading its
- * spaCy models — a transient connection failure here shouldn't need a
- * manual restart. Still non-fatal after every attempt is exhausted: the
- * *next* real call retries training itself (see `_ensureTrained`'s own
- * retry-on-failure comment), same graceful-degrade posture as before this
- * retry loop existed.
- */
-async function warmUpTechStepClassifier(): Promise<void> {
-  const maxAttempts = 5;
-  for (let attempt = 1; attempt <= maxAttempts; attempt++) {
-    try {
+// Trains the tech-step classifier (and pays node-nlp's own one-time lazy
+// setup cost — see `TechStepClassifierService.warmUp`) before accepting
+// any traffic, so the first real recipe save/preview isn't the one stuck
+// waiting several seconds for it.
+try {
   await techStepClassifier.warmUp();
-      return;
-    } catch (err) {
-      if (attempt === maxAttempts) {
-        logger.error("Tech-step classifier warm-up failed after retries", {
+} catch (err) {
+  // Not fatal to startup — a failed warm-up just means the *next* call
+  // retries training itself (see `_ensureTrained`'s own retry-on-failure
+  // comment), same graceful-degrade posture as everywhere else training
+  // failures surface. Still worth a loud log: this shouldn't normally fail.
+  logger.error("Tech-step classifier warm-up failed", {
     error: err instanceof Error ? err.message : String(err),
-          attempts: attempt,
   });
-        return;
-      }
-      const delayMs = 1000 * 2 ** (attempt - 1);
-      await new Promise((resolve) => setTimeout(resolve, delayMs));
-    }
-  }
 }
 
-await warmUpTechStepClassifier();
-
 const server = createServer();
 
-// Attaches to the same underlying `http.Server` `server.listen()` below
-// will start — `socket.io` binds to the HTTP server itself, not to
-// Express or a port, hence `ExpressServer.httpServer` (packages/express-
-// tools) rather than going through `server.instance` (the Express app).
-// Own CORS config: the WebSocket handshake is a separate HTTP upgrade
-// request that never runs through `setupCore`'s `cors()` middleware.
-const io = new SocketIoServer(server.httpServer, {
-  cors: { origin: env.CORS_ORIGIN, credentials: true },
-});
-new MonitoringBroadcastService(io).start();
-
 server.listen(env.PORT, () => {
   logger.info("API listening", { port: env.PORT, nodeEnv: env.NODE_ENV });
 });

apps/api/src/sources/750g.ts

@@ -1,425 +0,0 @@
-import type {
-  ParsedRecipe,
-  RecipeSourceAdapter,
-  RecipeSourceListItem,
-  RecipeSourceListParams,
-  RecipeSourceListResult,
-} from "../lib/recipe-sources/recipe-source-adapter.js";
-import {
-  RecipeSourceFetchError,
-  RecipeSourceParseError,
-} from "../lib/recipe-sources/recipe-source-errors.js";
-import { jsonLdRecipeAdapter } from "./json-ld-recipe.js";
-
-const SOURCE_KEY = "750g";
-
-// 750g.com's own site search is a client-side widget (results are fetched
-// by the page's own JS after load, nothing server-rendered to scrape) — but
-// that JS itself calls this plain GET endpoint, an "AI answer engine" that
-// returns an HTML fragment of recipe cards for a free-text query. Verified
-// live: works with a bare `fetch`, no special headers/cookies/session
-// needed, same as every other adapter in this family. Only used for a
-// non-empty query — see `LATEST_RECIPES_URL` for why: this endpoint answers
-// a blank query with nothing at all.
-const SEARCH_URL = "https://www.750g.com/genius/query/";
-
-// What `list()` reads instead of `SEARCH_URL` for an empty/omitted `query`
-// ("browse everything", per `RecipeSourceListParams.query`'s own doc
-// comment) — verified live, `SEARCH_URL` responds to a blank query with a
-// zero-length body, so browsing this source with no filter typed would
-// otherwise always come back empty. `dernieres-recettes.htm` is 750g.com's
-// own "latest recipes" archive: real, server-rendered pagination via
-// `&page=N` (unlike `SEARCH_URL`, which doesn't paginate at all — see
-// `list()`'s own comment on `nextCursor`), same `card-recipe`/`card-link`
-// markup `extractRecipeCards` already reads elsewhere on the site. Checked
-// live up to `page=500` — genuinely different recipes every time, no
-// redirect/clamp once past whatever the real end is (unlike marmiton.ts's
-// search, which 404s past its last page), so `list()` treats a page with no
-// cards at all as the end-of-results signal instead.
-const LATEST_RECIPES_URL = "https://www.750g.com/dernieres-recettes.htm";
-
-/**
- * Matches every `<script type="application/ld+json">…</script>` block —
- * same shape as `JSON_LD_SCRIPT_PATTERN` in json-ld-recipe.ts, kept as its
- * own private copy here rather than sharing that module's export: this one
- * does textual surgery on the *raw HTML* before `jsonLdRecipeAdapter` ever
- * sees it (see {@link sanitizeJsonLdBlocks} below), a different concern
- * from extracting-and-parsing blocks into objects.
- */
-const JSON_LD_SCRIPT_PATTERN =
-  /(<script[^>]*type\s*=\s*["']application\/ld\+json["'][^>]*>)([\s\S]*?)(<\/script>)/gi;
-
-/**
- * Escapes any raw (unescaped) JSON control character — U+0000–U+001F —
- * found *inside* a string literal of `json`, leaving everything outside
- * string literals (structural whitespace, brackets, …) untouched. Fixes a
- * real bug in 750g.com's own JSON-LD generator: some `HowToStep.text`
- * values contain a literal, un-escaped `\r\n` where valid JSON requires
- * `\\r\\n` (verified live, e.g.
- * https://www.750g.com/poulet-au-vin-jaune-et-aux-morilles-r3844.htm — and
- * roughly a third of a random sample of recipe pages hit this) —
- * `JSON.parse` throws "Bad control character in string literal" on these
- * pages as-is, which would make `jsonLdRecipeAdapter.parse` wrongly report
- * "no JSON-LD Recipe found" on a page that has a perfectly good one.
- *
- * A blind find/replace across the whole block would be wrong: JSON also
- * uses real newlines as *structural* whitespace between tokens
- * (pretty-printing), where they're perfectly legal and must be left alone —
- * only walking the text with string-literal awareness (tracking `"…"`
- * boundaries and `\`-escapes) can tell the two apart.
- */
-function escapeRawControlCharactersInStrings(json: string): string {
-  const SHORT_ESCAPES: Record<string, string> = {
-    "\b": "\\b",
-    "\f": "\\f",
-    "\n": "\\n",
-    "\r": "\\r",
-    "\t": "\\t",
-  };
-
-  let result = "";
-  let inString = false;
-  let escapedNext = false;
-  for (const ch of json) {
-    if (!inString) {
-      if (ch === '"') inString = true;
-      result += ch;
-      continue;
-    }
-    if (escapedNext) {
-      result += ch;
-      escapedNext = false;
-      continue;
-    }
-    if (ch === "\\") {
-      result += ch;
-      escapedNext = true;
-      continue;
-    }
-    if (ch === '"') {
-      inString = false;
-      result += ch;
-      continue;
-    }
-    if (ch < " ") {
-      result += SHORT_ESCAPES[ch] ?? `\\u${ch.charCodeAt(0).toString(16).padStart(4, "0")}`;
-      continue;
-    }
-    result += ch;
-  }
-  return result;
-}
-
-/**
- * Runs {@link escapeRawControlCharactersInStrings} over every JSON-LD
- * `<script>` block's content in `html`, leaving the rest of the page
- * untouched — the repair step `fetchDetail`'s raw HTML needs before
- * `jsonLdRecipeAdapter.parse` (which does its own extraction/`JSON.parse`
- * internally) ever sees it.
- */
-function sanitizeJsonLdBlocks(html: string): string {
-  return html.replace(
-    JSON_LD_SCRIPT_PATTERN,
-    (_match, openTag: string, json: string, closeTag: string) =>
-      `${openTag}${escapeRawControlCharactersInStrings(json)}${closeTag}`,
-  );
-}
-
-/**
- * Numeric entities plus a hand-picked table of named ones — not a general
- * HTML5 entity decoder (400+ named entities exist in the spec), just what's
- * actually been observed necessary to clean up 750g.com's French recipe
- * text: the five basic XML entities, Latin-1 accented letters, and a
- * handful of common punctuation entities.
- */
-const NAMED_ENTITIES: Record<string, string> = {
-  amp: "&",
-  lt: "<",
-  gt: ">",
-  quot: '"',
-  apos: "'",
-  nbsp: " ",
-  eacute: "é",
-  egrave: "è",
-  ecirc: "ê",
-  euml: "ë",
-  agrave: "à",
-  acirc: "â",
-  auml: "ä",
-  icirc: "î",
-  iuml: "ï",
-  ocirc: "ô",
-  ouml: "ö",
-  ucirc: "û",
-  ugrave: "ù",
-  uuml: "ü",
-  ccedil: "ç",
-  oelig: "œ",
-  aelig: "æ",
-  laquo: "«",
-  raquo: "»",
-  lsquo: "‘",
-  rsquo: "’",
-  ldquo: "“",
-  rdquo: "”",
-  hellip: "…",
-  ndash: "–",
-  mdash: "—",
-  deg: "°",
-};
-
-/** One pass of numeric (`&#39;`/`&#x27;`) and {@link NAMED_ENTITIES} decoding — see {@link decodeHtmlEntities}, which is what actually runs against parsed text; this is split out only so that function can run it twice. */
-function decodeHtmlEntitiesOnce(text: string): string {
-  return text.replace(/&(#x?[0-9a-fA-F]+|[a-zA-Z]+);/g, (entity, body: string) => {
-    if (body[0] === "#") {
-      const isHex = body[1] === "x" || body[1] === "X";
-      const codePoint = isHex
-        ? Number.parseInt(body.slice(2), 16)
-        : Number.parseInt(body.slice(1), 10);
-      return Number.isFinite(codePoint) ? String.fromCodePoint(codePoint) : entity;
-    }
-    return NAMED_ENTITIES[body] ?? entity;
-  });
-}
-
-/**
- * Decodes HTML entities in free-text pulled from 750g.com, run **twice**:
- * its JSON-LD sometimes double-escapes text that already went through its
- * own HTML-entity encoder once — e.g. a real "é" ends up as `&amp;eacute;`
- * (the `&` of an already-produced `&eacute;` got re-escaped to `&amp;`)
- * rather than a plain `&eacute;` or a raw "é" (verified live, e.g.
- * "Pr&amp;eacute;parez" on
- * https://www.750g.com/poulet-au-vin-jaune-et-aux-morilles-r3844.htm). One
- * pass turns that into `&eacute;` — a *newly formed*, valid-looking entity
- * — so a second pass is needed to resolve it the rest of the way to "é". A
- * string with no entities at all (the common case) is unaffected by either
- * pass.
- */
-function decodeHtmlEntities(text: string): string {
-  return decodeHtmlEntitiesOnce(decodeHtmlEntitiesOnce(text));
-}
-
-/**
- * Runs {@link decodeHtmlEntities} over every free-text field of a
- * `ParsedRecipe` produced by `jsonLdRecipeAdapter.parse`. `picture`/
- * `sourceUrl` are deliberately left untouched — they're URLs, not prose,
- * and the entity-encoding bug this fixes has only ever been observed in
- * name/description/instruction/ingredient text, never in a URL field.
- */
-function decodeParsedRecipeText(recipe: ParsedRecipe): ParsedRecipe {
-  return {
-    ...recipe,
-    name: decodeHtmlEntities(recipe.name),
-    description: recipe.description === null ? null : decodeHtmlEntities(recipe.description),
-    ingredients: recipe.ingredients.map((ingredient) => ({
-      ...ingredient,
-      rawText: decodeHtmlEntities(ingredient.rawText),
-      name: decodeHtmlEntities(ingredient.name),
-    })),
-    steps: recipe.steps.map((step) => ({
-      ...step,
-      description: decodeHtmlEntities(step.description),
-    })),
-  };
-}
-
-/** One recipe card as scraped off a 750g.com results fragment (search or listing page) — see {@link extractRecipeCards}. */
-interface SevenFiftyGCard {
-  url: string;
-  title: string;
-  image: string | null;
-}
-
-/**
- * Scrapes every recipe card out of a 750g.com results HTML fragment —
- * there's no JSON-LD `ItemList` on this endpoint to lean on (unlike
- * marmiton.ts's search page), just the same server-rendered `card-recipe`
- * markup 750g.com uses everywhere. Each card's title/url comes from its
- * `<a class="card-link">`; its image is whichever `<img>` most recently
- * preceded that link, rather than a naive same-index zip of "every image on
- * the page" against "every link on the page" — a plain fragment like this
- * one carries a few extra decorative images with no card of their own
- * (verified live: 28 `<img>` tags against 23 real cards for one sample
- * query), which would silently shift every image after the first stray one
- * onto the wrong title. Each card's own `<img>` always sits immediately
- * before its title link in the markup, so "nearest preceding image" is
- * unambiguous and doesn't depend on the two counts matching.
- */
-function extractRecipeCards(html: string): SevenFiftyGCard[] {
-  const linkPattern =
-    /<a\s+href="(https:\/\/www\.750g\.com\/[^"]+)"\s+class="card-link[^"]*">([^<]+)<\/a>/g;
-  const imagePattern = /<img[^>]*\ssrc="(https:\/\/static\.750g\.com\/images\/[^"]+)"[^>]*>/g;
-  const images = [...html.matchAll(imagePattern)];
-
-  const cards: SevenFiftyGCard[] = [];
-  let searchFrom = 0;
-  for (const linkMatch of html.matchAll(linkPattern)) {
-    let image: string | null = null;
-    for (const imgMatch of images) {
-      if (imgMatch.index === undefined || imgMatch.index >= linkMatch.index) break;
-      if (imgMatch.index >= searchFrom) image = imgMatch[1] ?? null;
-    }
-    cards.push({
-      url: linkMatch[1] ?? "",
-      title: decodeHtmlEntities(linkMatch[2] ?? ""),
-      image,
-    });
-    searchFrom = linkMatch.index;
-  }
-  return cards;
-}
-
-/**
- * Re-labels a `RecipeSourceFetchError`/`RecipeSourceParseError` thrown by
- * the generic `jsonLdRecipeAdapter` (`sourceKey` `"jsonLdRecipe"`) as having
- * come from this adapter instead (`sourceKey` `"750g"`) — same reasoning as
- * marmiton.ts's identically-named helper: `fetchDetail`/`parse` below are
- * thin wrappers around the generic adapter's own methods, but a caller
- * catching `RecipeSourceError` and reading `.sourceKey` should see "750g",
- * the source it actually asked about.
- */
-function rekeySourceError(err: unknown): unknown {
-  if (err instanceof RecipeSourceFetchError) {
-    return new RecipeSourceFetchError(SOURCE_KEY, err.message, { cause: err.cause });
-  }
-  if (err instanceof RecipeSourceParseError) {
-    return new RecipeSourceParseError(SOURCE_KEY, err.message, { cause: err.cause });
-  }
-  return err;
-}
-
-/**
- * 750g.com — one of France's largest recipe sites. Unofficial (`official:
- * false`): no published API, this adapter fetches ordinary pages and reads
- * the schema.org structured data 750g.com embeds for search engines, built
- * on {@link jsonLdRecipeAdapter} the same way marmiton.ts is. Two real
- * 750g-specific problems separate this adapter from a pure thin wrapper
- * like marmiton.ts, though:
- *
- * - `list()` has no `ItemList` JSON-LD to read off its search results (see
- *   {@link extractRecipeCards}) — its site search is a client-side widget,
- *   so a non-empty query instead calls the plain GET endpoint that widget's
- *   own JS calls internally (`SEARCH_URL`), an "AI answer engine" that
- *   returns a curated batch of cards rather than an exhaustive, paginated
- *   catalog — verified live, requesting `page=2` of the same query always
- *   comes back empty, so `nextCursor` is always `null` in that case, same
- *   as `theMealDbAdapter`'s "one response holds every match". An empty
- *   query reads `LATEST_RECIPES_URL` instead, a real paginated catalog —
- *   `SEARCH_URL` itself answers a blank query with nothing at all, which
- *   would otherwise make browsing this source with no filter typed always
- *   come back empty.
- * - `parse()` doesn't delegate to `jsonLdRecipeAdapter.parse` as directly as
- *   marmiton.ts's does — 750g.com's own JSON-LD generator has two real bugs
- *   this adapter works around: some pages embed literal, unescaped control
- *   characters inside a JSON string (see {@link sanitizeJsonLdBlocks}), and
- *   its free text is sometimes double HTML-entity-encoded (see
- *   {@link decodeParsedRecipeText}). Both are pre/post-processing around the
- *   same underlying delegation, not a reimplementation of it.
- */
-export const sevenFiftyGAdapter: RecipeSourceAdapter<{ html: string; url: string }> = {
-  key: SOURCE_KEY,
-  name: "750g",
-  official: false,
-  // Un chemin stable, sans le paramètre `?v=…` de cache-busting que 750g.com
-  // ajoute à ses balises <link> (susceptible de changer à chaque
-  // déploiement) — cette adresse répond correctement sans lui.
-  iconUrl: "https://www.750g.com/img/750g/favicons/favicon.svg",
-  // Le contenu de 750g.com (noms, ingrédients, instructions) est en
-  // français — détermine contre quel modèle/locale d'étiquettes
-  // d'ingrédients translateRecipe (recipe-translation.ts) résout les
-  // recettes de cette source lors d'une prévisualisation/d'un import.
-  locale: "fr",
-
-  async list(params: RecipeSourceListParams): Promise<RecipeSourceListResult> {
-    try {
-      const query = params.query ?? "";
-      const page = params.cursor ? Number(params.cursor) : 1;
-      const hasQuery = query.length > 0;
-
-      // Deux endpoints distincts selon qu'il y a un texte de recherche ou
-      // non — voir les commentaires de `SEARCH_URL`/`LATEST_RECIPES_URL` :
-      // le premier ne répond rien du tout à une requête vide, le second est
-      // le vrai catalogue paginé "dernières recettes" de 750g.com. `page`
-      // n'a de sens que pour le second (le premier ne pagine pas — voir
-      // plus bas) mais est toujours passé, y compris `page=1`, par
-      // cohérence avec le reste de cette famille d'adaptateurs.
-      const listUrl = hasQuery
-        ? `${SEARCH_URL}?query=${encodeURIComponent(query)}&query_type=written_query&page=1`
-        : `${LATEST_RECIPES_URL}?page=${page}`;
-
-      let response: Response;
-      try {
-        response = await fetch(listUrl);
-      } catch (cause) {
-        throw new RecipeSourceFetchError(
-          SOURCE_KEY,
-          `Network error listing 750g recipes (${listUrl})`,
-          {
-            cause,
-          },
-        );
-      }
-      if (!response.ok) {
-        throw new RecipeSourceFetchError(
-          SOURCE_KEY,
-          `750g responded ${response.status} (${listUrl})`,
-        );
-      }
-      const html = await response.text();
-
-      // No filter for a missing title/url here (unlike marmiton.ts/
-      // the-meal-db.ts, which drop entries with a null field from a
-      // structured API response) — `extractRecipeCards`' own regex requires
-      // at least one character for both, so there's no "absent field" shape
-      // to guard against.
-      const items: RecipeSourceListItem[] = extractRecipeCards(html).map((card) => ({
-        externalId: card.url,
-        title: card.title,
-        picture: card.image,
-        url: card.url,
-      }));
-
-      // La recherche par texte libre ne pagine pas du tout (voir le
-      // commentaire de `SEARCH_URL`) — `nextCursor` y vaut toujours `null`,
-      // même logique que `theMealDbAdapter`. "Dernières recettes" pagine
-      // réellement (voir le commentaire de `LATEST_RECIPES_URL`) — une page
-      // sans aucune carte en est le signal de fin.
-      const nextCursor = hasQuery ? null : items.length > 0 ? String(page + 1) : null;
-
-      return { items, nextCursor };
-    } catch (err) {
-      // Rethrown as-is (already keyed "750g" by whichever branch above
-      // threw it) — this adapter's only caller (`sources.service.ts`)
-      // already handles/logs failures centrally; this method just isn't
-      // allowed a bare `async` body without a try/catch per the repo's
-      // convention. Same reasoning as `marmiton.ts`/`json-ld-recipe.ts`.
-      throw err;
-    }
-  },
-
-  // `externalId` est directement l'URL canonique de la recette sur
-  // 750g.com (renvoyée telle quelle par `list()` ci-dessus) — même
-  // convention que `jsonLdRecipeAdapter.fetchDetail`, à qui cette méthode
-  // délègue entièrement : la réparation du JSON-LD (voir
-  // `sanitizeJsonLdBlocks`) n'a lieu qu'à l'étape `parse()`, pas ici.
-  async fetchDetail(externalId: string): Promise<{ html: string; url: string }> {
-    try {
-      return await jsonLdRecipeAdapter.fetchDetail(externalId);
-    } catch (err) {
-      // Pas un simple re-throw : `rekeySourceError` est le traitement utile
-      // que ce point d'appel doit faire de l'erreur (relabelliser sa
-      // `sourceKey`), conformément à la convention await/try-catch du repo.
-      throw rekeySourceError(err);
-    }
-  },
-
-  parse(raw: { html: string; url: string }): ParsedRecipe {
-    try {
-      const sanitizedHtml = sanitizeJsonLdBlocks(raw.html);
-      const parsed = jsonLdRecipeAdapter.parse({ html: sanitizedHtml, url: raw.url });
-      return decodeParsedRecipeText(parsed);
-    } catch (err) {
-      throw rekeySourceError(err);
-    }
-  },
-};

apps/api/src/sources/index.ts

@@ -1,18 +1,12 @@
 import { registerRecipeSource } from "../lib/recipe-sources/recipe-source-registry.js";
-import { sevenFiftyGAdapter } from "./750g.js";
-import { mangerBougerAdapter } from "./manger-bouger.js";
-import { marmitonAdapter } from "./marmiton.js";
-import { ohMonBentoAdapter } from "./ohmonbento.js";
-import { quitoqueAdapter } from "./quitoque.js";
 import { theMealDbAdapter } from "./the-meal-db.js";
 
 /**
  * Registers every concrete, *browsable* `RecipeSourceAdapter` this app
- * ships with into the shared in-memory registry (`recipe-source-registry.ts`)
- * — `theMealDbAdapter`, `marmitonAdapter`, `sevenFiftyGAdapter`,
- * `mangerBougerAdapter`, `quitoqueAdapter` and `ohMonBentoAdapter`. Called
- * once, explicitly, by the two real entry points that need the registry
- * populated:
+ * ships with into the shared in-memory registry
+ * (`recipe-source-registry.ts`) — currently just `theMealDbAdapter`.
+ * Called once, explicitly, by the two real entry points that need the
+ * registry populated:
  *
  * - `server.ts` — the running API process, before it starts listening.
  * - `prisma/seed.ts` — so `syncRecipeSources` has something to mirror into
@@ -27,21 +21,15 @@ import { theMealDbAdapter } from "./the-meal-db.js";
  * explicit setup. Tests that need a source in the registry register their
  * own throwaway fake instead (see e.g. `test/recipe-source-sync.test.ts`).
  *
- * `jsonLdRecipeAdapter` (json-ld-recipe.ts) itself is deliberately **not**
+ * `jsonLdRecipeAdapter` (json-ld-recipe.ts) is deliberately **not**
  * registered here — it's a generic schema.org-JSON-LD parser meant to be
- * specialized per scraped website, not a household-toggleable `Source` in
- * its own right: nobody can meaningfully "trust" or "enable" a generic
- * parsing mechanism the way they can a named website. `marmitonAdapter`
- * (marmiton.ts), `sevenFiftyGAdapter` (750g.ts) and `mangerBougerAdapter`
- * (manger-bouger.ts) are exactly that specialization, one per site — the
- * concrete adapters its own doc comment anticipated ("a concrete adapter
- * for a specific site would use it internally").
+ * specialized per scraped website (a concrete adapter for a specific site
+ * would use it internally), not a household-toggleable `Source` in its own
+ * right: nobody can meaningfully "trust" or "enable" a generic parsing
+ * mechanism the way they can a named website. Until real per-site adapters
+ * exist, it's called directly (e.g. a future "import from a pasted URL"
+ * flow), never through this registry.
  */
 export function registerAllRecipeSources(): void {
   registerRecipeSource(theMealDbAdapter);
-  registerRecipeSource(marmitonAdapter);
-  registerRecipeSource(sevenFiftyGAdapter);
-  registerRecipeSource(mangerBougerAdapter);
-  registerRecipeSource(quitoqueAdapter);
-  registerRecipeSource(ohMonBentoAdapter);
 }

apps/api/src/sources/json-ld-recipe.ts

@@ -44,17 +44,8 @@ interface SchemaOrgRecipe {
   url?: string;
 }
 
-/**
- * Extracts and JSON-parses every JSON-LD block on the page — a block that
- * fails to parse is skipped rather than failing the whole page over one
- * malformed script tag (some sites ship more than one JSON-LD block, e.g.
- * `BreadcrumbList` alongside `Recipe`). Exported (not just consumed
- * internally by {@link findRecipeNode} below) so a concrete per-site adapter
- * built on top of this module — e.g. `marmiton.ts`, which needs the same
- * page's embedded `ItemList` rather than its `Recipe` — reuses this same
- * extraction step instead of re-implementing the `<script>`-block regex.
- */
-export function extractJsonLdBlocks(html: string): unknown[] {
+/** Extracts and JSON-parses every JSON-LD block on the page — a block that fails to parse is skipped rather than failing the whole page over one malformed script tag (some sites ship more than one JSON-LD block, e.g. `BreadcrumbList` alongside `Recipe`). */
+function extractJsonLdBlocks(html: string): unknown[] {
   const blocks: unknown[] = [];
   for (const match of html.matchAll(JSON_LD_SCRIPT_PATTERN)) {
     try {
@@ -176,17 +167,6 @@ function flattenInstructions(instructions: SchemaOrgRecipe["recipeInstructions"]
  * `fetchDetail`'s `externalId` is simply the target URL itself, not an id
  * from a prior `list()` call. A future "import from URL" flow would call
  * `fetchDetail(pastedUrl)` directly.
- *
- * `marmiton.ts`'s `marmitonAdapter` is the first concrete adapter built on
- * top of this one — its `fetchDetail`/`parse` delegate straight here (a
- * marmiton.org recipe page's JSON-LD is a plain schema.org `Recipe`, nothing
- * site-specific to handle), and it only adds the `list()` this adapter
- * itself can't offer, by reading the separate `ItemList` marmiton.org embeds
- * on its search-results pages. `750g.ts`'s `sevenFiftyGAdapter` and
- * `manger-bouger.ts`'s `mangerBougerAdapter` follow the same shape for their
- * own sites, but each wraps this adapter's own `parse()` (rather than
- * delegating untouched) to work around real bugs/gaps in that site's own
- * JSON-LD — see each module's doc comment.
  */
 export const jsonLdRecipeAdapter: RecipeSourceAdapter<{
   html: string;

apps/api/src/sources/manger-bouger.ts

@@ -1,367 +0,0 @@
-import type {
-  ParsedRecipe,
-  RecipeSourceAdapter,
-  RecipeSourceListItem,
-  RecipeSourceListParams,
-  RecipeSourceListResult,
-} from "../lib/recipe-sources/recipe-source-adapter.js";
-import {
-  RecipeSourceFetchError,
-  RecipeSourceParseError,
-} from "../lib/recipe-sources/recipe-source-errors.js";
-import { jsonLdRecipeAdapter } from "./json-ld-recipe.js";
-
-const SOURCE_KEY = "mangerBouger";
-
-// "La Fabrique à Menus" — mangerbouger.fr's recipe tool (Santé publique
-// France). Its listing page is a Next.js app with no JSON-LD `ItemList` at
-// all (unlike marmiton.ts's search page) — but it's server-rendered, and a
-// plain GET carries the exact same Redux state the client hydrates from as
-// a `__NEXT_DATA__` script tag (see `extractNextData` below), which already
-// has everything `list()` needs. Verified live for the *search* path
-// (`?diet=ALL&page=N&query=<free text>`): `query` really filters
-// server-side (not just a client-side URL update over an already-fetched
-// page), and `page`/`hasMorePages` behave as real, consistent pagination.
-// The *catalogue browse* path (no `query` term) must be the bare
-// `?diet=ALL&page=N` — a trailing empty `&query=` made the deployed server
-// repeat page 1 for every page (issue #78); `list()` below now omits it.
-const LIST_URL = "https://www.mangerbouger.fr/manger-mieux/la-fabrique-a-menus/recettes";
-const DETAIL_BASE_URL = "https://www.mangerbouger.fr/manger-mieux/la-fabrique-a-menus/recettes/";
-
-/** Matches the `<script id="__NEXT_DATA__">…</script>` block every Next.js page ships — the site's own server-rendered hydration data, read instead of scraping HTML for both `list()` (the listing's recipe cards) and `parse()` (backfilling a gap in the detail page's JSON-LD, see {@link extractPortionsFromNextData}). */
-const NEXT_DATA_PATTERN = /<script id="__NEXT_DATA__"[^>]*>([\s\S]*?)<\/script>/;
-
-/** The one field of one `list[]` entry `list()` actually reads off the listing page's `__NEXT_DATA__` — that state carries the site's full internal `Recipe` shape (60+ fields: nutriscore, seasons, macros, …), none of which this adapter's contract has anywhere to put. */
-interface MangerBougerListEntry {
-  slug?: string;
-  name?: string;
-  image?: string | null;
-}
-
-/** The slice of `__NEXT_DATA__` this module reads off the *listing* page. */
-interface MangerBougerListPageData {
-  props?: {
-    initialState?: {
-      recipes?: {
-        list?: MangerBougerListEntry[];
-        /** Whether a further page exists for the current `page`/`query`/`diet` combination — verified live on the `query`-term path: an out-of-range page comes back `false` with an empty `list` rather than repeating the last page or erroring, a cleaner end-of-results signal than either `marmiton.ts` (infers it from a 404) or `750g.ts` (this search has no real pagination at all). The catalogue-browse path (no `query`) only paginates when the request URL omits `&query=` entirely — see `LIST_URL` and issue #78. */
-        hasMorePages?: boolean;
-      };
-    };
-  };
-}
-
-/** The slice of `__NEXT_DATA__` this module reads off a recipe *detail* page — a different shape than the listing page's (`initialState.recipe.recipe`, not `initialState.recipes.list[]`) since it's a different Redux slice entirely. */
-interface MangerBougerDetailPageData {
-  props?: {
-    initialState?: {
-      recipe?: {
-        recipe?: {
-          portions?: unknown;
-        };
-      };
-    };
-  };
-}
-
-/** Parses the page's `__NEXT_DATA__` block into `T`, or `null` if the block is missing or isn't valid JSON — callers degrade gracefully rather than throw, same as `marmiton.ts`'s "page has no ItemList at all" handling. */
-function extractNextData<T>(html: string): T | null {
-  const match = html.match(NEXT_DATA_PATTERN);
-  if (!match) return null;
-  try {
-    return JSON.parse(match[1] ?? "") as T;
-  } catch {
-    return null;
-  }
-}
-
-function detailUrl(slug: string): string {
-  return `${DETAIL_BASE_URL}${slug}`;
-}
-
-/**
- * Matches the single `<script type="application/ld+json">…</script>` block
- * a mangerbouger.fr recipe *detail* page carries (verified live across a
- * sample of 9 recipes — always exactly one, always a bare `Recipe`, never
- * an `@graph`) — a much narrower pattern than `json-ld-recipe.ts`'s own
- * `JSON_LD_SCRIPT_PATTERN` (no `g` flag: this module only ever needs the
- * first/only block, to patch it — see {@link patchRecipeJsonLd}) or
- * `750g.ts`'s identically-named private copy (which does its own,
- * different, character-level repair over every block on the page).
- */
-const JSON_LD_SCRIPT_PATTERN =
-  /(<script[^>]*type\s*=\s*["']application\/ld\+json["'][^>]*>)([\s\S]*?)(<\/script>)/i;
-
-/** One node of a Slate.js rich-text document — see {@link flattenSlateDocument}. */
-interface SlateNode {
-  type?: string;
-  text?: string;
-  children?: SlateNode[];
-}
-
-/** Concatenates a run of inline Slate nodes (leaf text, or further-nested inline runs) with no separator — bold/italic/underline marks (the only ones observed) carry no plain-text equivalent and are simply dropped. */
-function flattenSlateInline(nodes: SlateNode[]): string {
-  return nodes
-    .map((node) =>
-      typeof node.text === "string"
-        ? node.text
-        : node.children
-          ? flattenSlateInline(node.children)
-          : "",
-    )
-    .join("");
-}
-
-/**
- * Flattens a Slate.js document's top-level blocks into one line of plain
- * text each — verified live across every recipe step sampled (72 recipes):
- * only `paragraph` and `bulleted-list` (of `list-item`s) ever appear as
- * block types, so that's all this handles; any other/unrecognized block
- * type still degrades reasonably (its own children read as one inline run)
- * rather than being dropped outright.
- */
-function flattenSlateBlocks(nodes: SlateNode[]): string[] {
-  const lines: string[] = [];
-  for (const node of nodes) {
-    if (node.type === "bulleted-list" && node.children) {
-      lines.push(...flattenSlateBlocks(node.children));
-      continue;
-    }
-    if (node.type === "list-item" && node.children) {
-      const text = flattenSlateInline(node.children);
-      if (text.trim().length > 0) lines.push(`- ${text}`);
-      continue;
-    }
-    if (node.children) {
-      const text = flattenSlateInline(node.children);
-      if (text.trim().length > 0) lines.push(text);
-      continue;
-    }
-    if (typeof node.text === "string" && node.text.trim().length > 0) lines.push(node.text);
-  }
-  return lines;
-}
-
-/**
- * Flattens one `HowToStep.text` value into plain text. mangerbouger.fr's
- * own JSON-LD embeds this field pre-formatted for its own web app instead
- * of as prose: `text` is itself a JSON-serialized Slate.js rich-text
- * document (verified live: every one of 72 sampled recipe steps parses as
- * one) — handing that straight to `jsonLdRecipeAdapter.parse` would surface
- * the raw `[{"type":"paragraph","children":[{"text":"…` blob as a step's
- * description, unusable as-is. `json` that doesn't parse as an array (a
- * genuinely plain-text step, or some future/different shape) is returned
- * unchanged rather than mangled.
- */
-function flattenSlateDocument(json: string): string {
-  let doc: unknown;
-  try {
-    doc = JSON.parse(json);
-  } catch {
-    return json;
-  }
-  if (!Array.isArray(doc)) return json;
-  return flattenSlateBlocks(doc as SlateNode[]).join("\n");
-}
-
-/** The two schema.org `Recipe` fields {@link patchRecipeJsonLd} patches, plus an index signature so every other field survives re-serialization untouched. */
-interface JsonLdRecipeLike {
-  recipeInstructions?: unknown;
-  recipeYield?: unknown;
-  [key: string]: unknown;
-}
-
-/** One `HowToStep`-shaped entry of `recipeInstructions`, as far as {@link patchRecipeJsonLd} needs to know. */
-interface JsonLdHowToStepLike {
-  text?: unknown;
-  [key: string]: unknown;
-}
-
-/**
- * `state.recipe.recipe.portions` from the same detail page's `__NEXT_DATA__`
- * — the number `recipeYield` should have been (see {@link patchRecipeJsonLd}),
- * read from the site's own internal state rather than left unstated.
- */
-function extractPortionsFromNextData(html: string): number | null {
-  const data = extractNextData<MangerBougerDetailPageData>(html);
-  const portions = data?.props?.initialState?.recipe?.recipe?.portions;
-  return typeof portions === "number" ? portions : null;
-}
-
-/**
- * Repairs the two real gaps verified live in mangerbouger.fr's own
- * recipe-detail JSON-LD, then hands the patched HTML to
- * `jsonLdRecipeAdapter.parse` unmodified otherwise — same "fix what's
- * actually broken, delegate the rest" shape as `750g.ts`'s
- * `sanitizeJsonLdBlocks`/`decodeParsedRecipeText`, just structural (parse →
- * mutate → re-serialize the one JSON-LD object) rather than textual, since
- * both gaps need real understanding of the document, not character-level
- * fixups:
- *
- * - `recipeInstructions[].text` is Slate.js rich text, not prose — flattened
- *   via {@link flattenSlateDocument}.
- * - `recipeYield` is absent on every one of 9 sampled recipes (schema.org
- *   allows omitting it, and mangerbouger.fr's generator apparently always
- *   does) even though the site's own internal data has the serving count
- *   right there — backfilled from `__NEXT_DATA__` via
- *   {@link extractPortionsFromNextData} rather than left as a needless
- *   `portions: null` on every single imported recipe.
- *
- * A missing or malformed JSON-LD block is left completely untouched —
- * `jsonLdRecipeAdapter`'s own "no JSON-LD Recipe found"/"malformed block,
- * skip it" handling is exactly the right behavior for that, no need to
- * duplicate it here.
- */
-function patchRecipeJsonLd(html: string): string {
-  const match = html.match(JSON_LD_SCRIPT_PATTERN);
-  if (!match) return html;
-
-  let recipe: JsonLdRecipeLike;
-  try {
-    recipe = JSON.parse(match[2] ?? "{}") as JsonLdRecipeLike;
-  } catch {
-    return html;
-  }
-
-  if (Array.isArray(recipe.recipeInstructions)) {
-    for (const step of recipe.recipeInstructions as JsonLdHowToStepLike[]) {
-      if (step && typeof step === "object" && typeof step.text === "string") {
-        step.text = flattenSlateDocument(step.text);
-      }
-    }
-  }
-
-  if (recipe.recipeYield === undefined) {
-    const portions = extractPortionsFromNextData(html);
-    if (portions !== null) recipe.recipeYield = portions;
-  }
-
-  const patchedJson = JSON.stringify(recipe);
-  return html.replace(
-    JSON_LD_SCRIPT_PATTERN,
-    (_full, openTag: string, _json: string, closeTag: string) =>
-      `${openTag}${patchedJson}${closeTag}`,
-  );
-}
-
-/**
- * Re-labels a `RecipeSourceFetchError`/`RecipeSourceParseError` thrown by
- * the generic `jsonLdRecipeAdapter` (`sourceKey` `"jsonLdRecipe"`) as having
- * come from this adapter instead (`sourceKey` `"mangerBouger"`) — same
- * reasoning as `marmiton.ts`/`750g.ts`'s identically-named helpers.
- */
-function rekeySourceError(err: unknown): unknown {
-  if (err instanceof RecipeSourceFetchError) {
-    return new RecipeSourceFetchError(SOURCE_KEY, err.message, { cause: err.cause });
-  }
-  if (err instanceof RecipeSourceParseError) {
-    return new RecipeSourceParseError(SOURCE_KEY, err.message, { cause: err.cause });
-  }
-  return err;
-}
-
-/**
- * mangerbouger.fr ("La Fabrique à Menus") — Santé publique France's public
- * nutrition site. Unofficial (`official: false`): no published API, same
- * reasoning as every other adapter in this family — fetching ordinary pages
- * and reading data the site never committed to a stable contract, not a
- * maintained endpoint. `fetchDetail` delegates straight to
- * `jsonLdRecipeAdapter`; `parse` wraps it with {@link patchRecipeJsonLd}
- * (see that function's doc comment for the two real gaps it fixes).
- * `list()` doesn't use JSON-LD at all — see `LIST_URL`'s doc comment.
- */
-export const mangerBougerAdapter: RecipeSourceAdapter<{ html: string; url: string }> = {
-  key: SOURCE_KEY,
-  name: "Manger Bouger",
-  official: false,
-  // Chemin fixe (pas d'icône versionnée/hashée comme sur d'autres sources
-  // de cette famille) — répond correctement sans paramètre supplémentaire.
-  iconUrl: "https://www.mangerbouger.fr/manger-mieux/la-fabrique-a-menus/favicon.ico",
-  // Le contenu de mangerbouger.fr (noms, ingrédients, instructions) est en
-  // français — détermine contre quel modèle/locale d'étiquettes
-  // d'ingrédients translateRecipe (recipe-translation.ts) résout les
-  // recettes de cette source lors d'une prévisualisation/d'un import.
-  locale: "fr",
-
-  async list(params: RecipeSourceListParams): Promise<RecipeSourceListResult> {
-    try {
-      const page = params.cursor ? Number(params.cursor) : 1;
-      // Only append `&query=` when there's an actual search term. A trailing
-      // empty `&query=` on the "browse everything" path (filter absent) made
-      // the *deployed* server serve page 1 for every `page=N` — the
-      // infinite scroll then stopped after 9 recipes (issue #38's
-      // "0 new externalIds ⇒ end of list" guard cutting in). The bare
-      // `?diet=ALL&page=N` catalogue request paginates correctly. The
-      // sibling adapters (marmiton/quitoque/ohmonbento) already make their
-      // search param conditional; this one didn't.
-      const query = (params.query ?? "").trim();
-      const listUrl = `${LIST_URL}?diet=ALL&page=${page}${
-        query ? `&query=${encodeURIComponent(query)}` : ""
-      }`;
-
-      let response: Response;
-      try {
-        response = await fetch(listUrl);
-      } catch (cause) {
-        throw new RecipeSourceFetchError(SOURCE_KEY, `Network error listing recipes (${listUrl})`, {
-          cause,
-        });
-      }
-      if (!response.ok) {
-        throw new RecipeSourceFetchError(
-          SOURCE_KEY,
-          `mangerbouger.fr responded ${response.status} (${listUrl})`,
-        );
-      }
-      const html = await response.text();
-
-      const data = extractNextData<MangerBougerListPageData>(html);
-      const state = data?.props?.initialState?.recipes;
-
-      const items: RecipeSourceListItem[] = (state?.list ?? [])
-        .filter((entry): entry is MangerBougerListEntry & { slug: string; name: string } =>
-          Boolean(entry.slug && entry.name),
-        )
-        .map((entry) => ({
-          externalId: detailUrl(entry.slug),
-          title: entry.name,
-          picture: entry.image ?? null,
-          url: detailUrl(entry.slug),
-        }));
-
-      return { items, nextCursor: state?.hasMorePages ? String(page + 1) : null };
-    } catch (err) {
-      // Rethrown as-is (already keyed "mangerBouger" by whichever branch
-      // above threw it) — this adapter's only caller (`sources.service.ts`)
-      // already handles/logs failures centrally; this method just isn't
-      // allowed a bare `async` body without a try/catch per the repo's
-      // convention. Same reasoning as `marmiton.ts`/`750g.ts`.
-      throw err;
-    }
-  },
-
-  // `externalId` est directement l'URL canonique de la recette sur
-  // mangerbouger.fr (renvoyée telle quelle par `list()` ci-dessus) — même
-  // convention que `jsonLdRecipeAdapter.fetchDetail`, à qui cette méthode
-  // délègue entièrement : la réparation du JSON-LD (voir
-  // `patchRecipeJsonLd`) n'a lieu qu'à l'étape `parse()`, pas ici.
-  async fetchDetail(externalId: string): Promise<{ html: string; url: string }> {
-    try {
-      return await jsonLdRecipeAdapter.fetchDetail(externalId);
-    } catch (err) {
-      // Pas un simple re-throw : `rekeySourceError` est le traitement utile
-      // que ce point d'appel doit faire de l'erreur (relabelliser sa
-      // `sourceKey`), conformément à la convention await/try-catch du repo.
-      throw rekeySourceError(err);
-    }
-  },
-
-  parse(raw: { html: string; url: string }): ParsedRecipe {
-    try {
-      const patchedHtml = patchRecipeJsonLd(raw.html);
-      return jsonLdRecipeAdapter.parse({ html: patchedHtml, url: raw.url });
-    } catch (err) {
-      throw rekeySourceError(err);
-    }
-  },
-};

apps/api/src/sources/marmiton.ts

@@ -1,206 +0,0 @@
-import type {
-  ParsedRecipe,
-  RecipeSourceAdapter,
-  RecipeSourceListItem,
-  RecipeSourceListParams,
-  RecipeSourceListResult,
-} from "../lib/recipe-sources/recipe-source-adapter.js";
-import {
-  RecipeSourceFetchError,
-  RecipeSourceParseError,
-} from "../lib/recipe-sources/recipe-source-errors.js";
-import { extractJsonLdBlocks, jsonLdRecipeAdapter } from "./json-ld-recipe.js";
-
-const SOURCE_KEY = "marmiton";
-const SEARCH_URL = "https://www.marmiton.org/recettes/recherche.aspx";
-
-/**
- * One `ListItem` inside the schema.org `ItemList` marmiton.org embeds as
- * JSON-LD on its search-results pages — the subset this adapter reads. Also
- * what a search whose term happens to match a known ingredient (e.g.
- * `aqt=poulet`) actually returns: marmiton.org silently serves its
- * ingredient-index page instead of a "search results" page for those terms,
- * but that page embeds the exact same `ItemList` shape, so `list()` doesn't
- * need to tell the two apart.
- */
-interface MarmitonListItem {
-  "@type"?: string;
-  url?: string;
-  name?: string;
-  image?: string;
-}
-
-/** The subset of a schema.org `ItemList` this adapter reads off marmiton.org's search-results page. */
-interface MarmitonItemList {
-  "@type"?: string;
-  "@graph"?: unknown[];
-  itemListElement?: MarmitonListItem[];
-}
-
-/**
- * Finds the first `ItemList` node within one parsed JSON-LD block — mirrors
- * `findRecipeNode`'s traversal in json-ld-recipe.ts (array of mixed-type
- * nodes, `@graph` wrapper) but looks for the results listing marmiton.org's
- * search page embeds instead of a `Recipe`.
- */
-function findItemListNode(node: unknown): MarmitonItemList | null {
-  if (node === null || typeof node !== "object") return null;
-  if (Array.isArray(node)) {
-    for (const item of node) {
-      const found = findItemListNode(item);
-      if (found) return found;
-    }
-    return null;
-  }
-  const obj = node as MarmitonItemList;
-  if (obj["@type"] === "ItemList") return obj;
-  if (Array.isArray(obj["@graph"])) return findItemListNode(obj["@graph"]);
-  return null;
-}
-
-/**
- * Re-labels a `RecipeSourceFetchError`/`RecipeSourceParseError` thrown by
- * the generic `jsonLdRecipeAdapter` (`sourceKey` `"jsonLdRecipe"`) as having
- * come from this adapter instead (`sourceKey` `"marmiton"`). `fetchDetail`/
- * `parse` below are thin wrappers around the generic adapter's own methods
- * (see this module's doc comment) — but a caller catching `RecipeSourceError`
- * and reading `.sourceKey` to attribute a failure to a specific `Source`
- * should see "marmiton", the source it actually asked about, not the
- * internal implementation detail this adapter happens to be built on.
- * Anything else (a bug, an unexpected throw) is passed through unchanged —
- * only the vocabulary this module documents gets relabeled.
- */
-function rekeySourceError(err: unknown): unknown {
-  if (err instanceof RecipeSourceFetchError) {
-    return new RecipeSourceFetchError(SOURCE_KEY, err.message, { cause: err.cause });
-  }
-  if (err instanceof RecipeSourceParseError) {
-    return new RecipeSourceParseError(SOURCE_KEY, err.message, { cause: err.cause });
-  }
-  return err;
-}
-
-/**
- * marmiton.org — France's largest recipe site. Unofficial (`official:
- * false`): there's no published API, this adapter fetches ordinary pages and
- * reads the schema.org structured data marmiton.org embeds for search
- * engines, same as {@link jsonLdRecipeAdapter} it's built on. It's the first
- * concrete, per-site adapter that generic adapter's own doc comment
- * anticipated ("a concrete adapter for a specific site would use it
- * internally") — `fetchDetail`/`parse` below just delegate straight to it,
- * since a marmiton.org recipe page's JSON-LD is a plain schema.org `Recipe`
- * with nothing site-specific to handle. The only real Marmiton-specific
- * logic is `list()`: `jsonLdRecipeAdapter` has no catalog of its own to
- * browse, but marmiton.org's search-results page embeds a browsable
- * `ItemList` this adapter reads directly (see {@link findItemListNode}).
- */
-export const marmitonAdapter: RecipeSourceAdapter<{ html: string; url: string }> = {
-  key: SOURCE_KEY,
-  name: "Marmiton",
-  official: false,
-  // Un chemin stable (jamais un nom de fichier avec un hash de build, comme
-  // les icônes servies depuis statics.marmiton.fr) — marmiton.org sert son
-  // favicon à cette adresse indépendamment de tout déploiement.
-  iconUrl: "https://www.marmiton.org/favicon.ico",
-  // Le contenu de Marmiton (noms, ingrédients, instructions) est en
-  // français — détermine contre quel modèle/locale d'étiquettes
-  // d'ingrédients translateRecipe (recipe-translation.ts) résout les
-  // recettes de cette source lors d'une prévisualisation/d'un import.
-  locale: "fr",
-
-  async list(params: RecipeSourceListParams): Promise<RecipeSourceListResult> {
-    try {
-      // Un curseur opaque qui encode simplement le numéro de page suivant —
-      // marmiton.org pagine sa recherche via `&page=N` (page 1 implicite
-      // quand le paramètre est absent), pas de token dédié à faire
-      // transiter.
-      const page = params.cursor ? Number(params.cursor) : 1;
-      const query = params.query ?? "";
-      const searchUrl = `${SEARCH_URL}?aqt=${encodeURIComponent(query)}${
-        page > 1 ? `&page=${page}` : ""
-      }`;
-
-      let response: Response;
-      try {
-        response = await fetch(searchUrl);
-      } catch (cause) {
-        throw new RecipeSourceFetchError(
-          SOURCE_KEY,
-          `Network error searching Marmiton (${searchUrl})`,
-          { cause },
-        );
-      }
-      // marmiton.org répond 404 dès que `page` dépasse la dernière page de
-      // résultats pour cette recherche — pas un vrai échec, juste "il n'y a
-      // plus rien" : son `ItemList` ne porte aucun total fiable (son
-      // `numberOfItems` vaut toujours la taille de la page courante, jamais
-      // le nombre total de résultats) pour le détecter à l'avance autrement
-      // qu'en demandant la page suivante et en constatant qu'elle est vide.
-      if (response.status === 404) {
-        return { items: [], nextCursor: null };
-      }
-      if (!response.ok) {
-        throw new RecipeSourceFetchError(
-          SOURCE_KEY,
-          `Marmiton search responded ${response.status} (${searchUrl})`,
-        );
-      }
-      const html = await response.text();
-
-      let itemList: MarmitonItemList | null = null;
-      for (const block of extractJsonLdBlocks(html)) {
-        itemList = findItemListNode(block);
-        if (itemList) break;
-      }
-
-      const items: RecipeSourceListItem[] = (itemList?.itemListElement ?? [])
-        .filter((entry): entry is MarmitonListItem & { url: string; name: string } =>
-          Boolean(entry.url && entry.name),
-        )
-        .map((entry) => ({
-          externalId: entry.url,
-          title: entry.name,
-          picture: entry.image ?? null,
-          url: entry.url,
-        }));
-
-      return {
-        items,
-        // Voir le commentaire ci-dessus sur la réponse 404 : une page vide
-        // est elle-même le signal de fin, donc on ne propose une page
-        // suivante que si celle-ci en a retourné au moins un résultat.
-        nextCursor: items.length > 0 ? String(page + 1) : null,
-      };
-    } catch (err) {
-      // Rethrown as-is (already keyed "marmiton" by whichever branch above
-      // threw it) — this adapter's only caller (`sources.service.ts`)
-      // already handles/logs failures centrally; this method just isn't
-      // allowed a bare `async` body without a try/catch per the repo's
-      // convention. Same reasoning as `json-ld-recipe.ts`/`the-meal-db.ts`.
-      throw err;
-    }
-  },
-
-  // `externalId` est directement l'URL canonique de la recette sur
-  // marmiton.org (renvoyée telle quelle par `list()` ci-dessus) — même
-  // convention que `jsonLdRecipeAdapter.fetchDetail`, à qui cette méthode
-  // délègue entièrement (voir le commentaire du module).
-  async fetchDetail(externalId: string): Promise<{ html: string; url: string }> {
-    try {
-      return await jsonLdRecipeAdapter.fetchDetail(externalId);
-    } catch (err) {
-      // Pas un simple re-throw : `rekeySourceError` est le traitement utile
-      // que ce point d'appel doit faire de l'erreur (relabelliser sa
-      // `sourceKey`), conformément à la convention await/try-catch du repo.
-      throw rekeySourceError(err);
-    }
-  },
-
-  parse(raw: { html: string; url: string }): ParsedRecipe {
-    try {
-      return jsonLdRecipeAdapter.parse(raw);
-    } catch (err) {
-      throw rekeySourceError(err);
-    }
-  },
-};

apps/api/src/sources/ohmonbento.ts

@@ -1,170 +0,0 @@
-import type {
-  ParsedRecipe,
-  RecipeSourceAdapter,
-  RecipeSourceListItem,
-  RecipeSourceListParams,
-  RecipeSourceListResult,
-} from "../lib/recipe-sources/recipe-source-adapter.js";
-import {
-  RecipeSourceFetchError,
-  RecipeSourceParseError,
-} from "../lib/recipe-sources/recipe-source-errors.js";
-import { jsonLdRecipeAdapter } from "./json-ld-recipe.js";
-
-const SOURCE_KEY = "ohMonBento";
-const SITE_ORIGIN = "https://ohmonbento.com";
-
-/** One recipe card scraped off an ohmonbento.com search page — see {@link extractRecipeCards}. */
-interface OhMonBentoCard {
-  url: string;
-  title: string;
-  image: string | null;
-}
-
-/**
- * Scrapes every recipe card out of an ohmonbento.com search results page.
- * Each card is a `<div class="entry-thumb">` wrapping a single
- * `<a href="/<slug>/">` with one `<img>` inside — no `ItemList` JSON-LD
- * (unlike marmiton.ts) and no lazy-load `data-src` dance (unlike
- * quitoque.ts): the real image is just the `<img>`'s `src`. `href` is a
- * root-relative path, resolved against {@link SITE_ORIGIN} here.
- * Attribute-order-agnostic.
- */
-function extractRecipeCards(html: string): OhMonBentoCard[] {
-  const cards: OhMonBentoCard[] = [];
-  const thumbPattern = /<div\s+[^>]*class="[^"]*\bentry-thumb\b[^"]*"[^>]*>([\s\S]*?)<\/div>/g;
-  for (const match of html.matchAll(thumbPattern)) {
-    const block = match[1] ?? "";
-    const href = /<a\s+[^>]*\bhref="([^"]+)"/.exec(block)?.[1];
-    if (href === undefined) continue;
-    const title = /\balt="([^"]*)"/.exec(block)?.[1] ?? "";
-    if (title.length === 0) continue;
-    const url = href.startsWith("http") ? href : `${SITE_ORIGIN}${href}`;
-    cards.push({ url, title, image: /\bsrc="([^"]+)"/.exec(block)?.[1] ?? null });
-  }
-  return cards;
-}
-
-/**
- * Re-labels a `RecipeSourceFetchError`/`RecipeSourceParseError` thrown by
- * the generic `jsonLdRecipeAdapter` (`sourceKey` `"jsonLdRecipe"`) as this
- * adapter's (`sourceKey` `"ohMonBento"`) — same reasoning as marmiton.ts's
- * identically-named helper. (Not factored out into a shared helper —
- * marmiton/750g/manger-bouger/quitoque each keep their own copy; the
- * near-identical five-liner isn't worth a module.)
- */
-function rekeySourceError(err: unknown): unknown {
-  if (err instanceof RecipeSourceFetchError) {
-    return new RecipeSourceFetchError(SOURCE_KEY, err.message, { cause: err.cause });
-  }
-  if (err instanceof RecipeSourceParseError) {
-    return new RecipeSourceParseError(SOURCE_KEY, err.message, { cause: err.cause });
-  }
-  return err;
-}
-
-/**
- * ohmonbento.com — a French Japanese-cuisine / bento cooking blog
- * (WordPress). Unofficial (`official: false`, same reasoning as every
- * other scraped adapter): no published API, this reads ordinary pages and
- * the schema.org JSON-LD they embed. `robots.txt` allows everything except
- * `/wp-admin/`.
- *
- * The simplest of the scraped adapters: like marmiton.ts, `fetchDetail`/
- * `parse` delegate straight to {@link jsonLdRecipeAdapter} — a recipe page
- * carries a WP Recipe Maker `Recipe` inside a Yoast `@graph`, which
- * `findRecipeNode` already handles (recurses into the array). Only `list()`
- * is site-specific: WordPress search at `/?s={query}&paged={page}` — the
- * **same URL whether `query` is empty (whole catalogue) or not** (no
- * branching, unlike 750g.ts) — with a `<div class="entry-thumb">` card
- * scrape (see {@link extractRecipeCards}). A page past the last one 404s,
- * the same clean end-of-list signal as marmiton.ts.
- */
-export const ohMonBentoAdapter: RecipeSourceAdapter<{ html: string; url: string }> = {
-  key: SOURCE_KEY,
-  name: "Oh mon Bento",
-  official: false,
-  iconUrl: `${SITE_ORIGIN}/favicon.ico`,
-  // Le contenu d'ohmonbento.com (noms, ingrédients, instructions) est en
-  // français — détermine contre quel modèle/locale d'étiquettes
-  // d'ingrédients translateRecipe (recipe-translation.ts) résout les
-  // recettes de cette source lors d'une prévisualisation/d'un import.
-  locale: "fr",
-
-  async list(params: RecipeSourceListParams): Promise<RecipeSourceListResult> {
-    try {
-      // Curseur opaque = numéro de page suivant ; WordPress pagine via
-      // `&paged=N` (page 1 implicite quand le paramètre est absent). Le
-      // paramètre `?s=` est toujours présent, même vide — c'est ce qui
-      // liste tout le catalogue (vérifié sur le ticket).
-      const page = params.cursor ? Number(params.cursor) : 1;
-      const query = params.query ?? "";
-      const listUrl = `${SITE_ORIGIN}/?s=${encodeURIComponent(query)}${
-        page > 1 ? `&paged=${page}` : ""
-      }`;
-
-      let response: Response;
-      try {
-        response = await fetch(listUrl);
-      } catch (cause) {
-        throw new RecipeSourceFetchError(
-          SOURCE_KEY,
-          `Network error listing Oh mon Bento recipes (${listUrl})`,
-          { cause },
-        );
-      }
-      // Une page au-delà de la dernière renvoie une vraie 404 — pas un
-      // échec, juste « il n'y a plus rien » (même signal que marmiton.ts).
-      if (response.status === 404) {
-        return { items: [], nextCursor: null };
-      }
-      if (!response.ok) {
-        throw new RecipeSourceFetchError(
-          SOURCE_KEY,
-          `Oh mon Bento responded ${response.status} (${listUrl})`,
-        );
-      }
-      const html = await response.text();
-
-      const items: RecipeSourceListItem[] = extractRecipeCards(html).map((card) => ({
-        externalId: card.url,
-        title: card.title,
-        picture: card.image,
-        url: card.url,
-      }));
-
-      // La 404 ci-dessus est le vrai signal de fin ; on ne propose une page
-      // suivante que si celle-ci a renvoyé au moins une carte (même logique
-      // que marmiton.ts).
-      const nextCursor = items.length > 0 ? String(page + 1) : null;
-
-      return { items, nextCursor };
-    } catch (err) {
-      // Rethrown as-is (already keyed "ohMonBento" by whichever branch
-      // above threw it) — same reasoning as `marmiton.ts`/`quitoque.ts`.
-      throw err;
-    }
-  },
-
-  // `externalId` est directement l'URL canonique de la recette sur
-  // ohmonbento.com (renvoyée telle quelle par `list()` ci-dessus) — même
-  // convention que `jsonLdRecipeAdapter.fetchDetail`, à qui cette méthode
-  // délègue entièrement.
-  async fetchDetail(externalId: string): Promise<{ html: string; url: string }> {
-    try {
-      return await jsonLdRecipeAdapter.fetchDetail(externalId);
-    } catch (err) {
-      // `rekeySourceError` est le traitement utile de l'erreur à ce point
-      // d'appel (relabelliser sa `sourceKey`), pas un simple re-throw.
-      throw rekeySourceError(err);
-    }
-  },
-
-  parse(raw: { html: string; url: string }): ParsedRecipe {
-    try {
-      return jsonLdRecipeAdapter.parse(raw);
-    } catch (err) {
-      throw rekeySourceError(err);
-    }
-  },
-};

apps/api/src/sources/quitoque.ts

@@ -1,188 +0,0 @@
-import type {
-  ParsedRecipe,
-  RecipeSourceAdapter,
-  RecipeSourceListItem,
-  RecipeSourceListParams,
-  RecipeSourceListResult,
-} from "../lib/recipe-sources/recipe-source-adapter.js";
-import {
-  RecipeSourceFetchError,
-  RecipeSourceParseError,
-} from "../lib/recipe-sources/recipe-source-errors.js";
-import { jsonLdRecipeAdapter } from "./json-ld-recipe.js";
-
-const SOURCE_KEY = "quitoque";
-const SITE_ORIGIN = "https://www.quitoque.fr";
-const LIST_URL = `${SITE_ORIGIN}/recettes`;
-
-/** One recipe card scraped off a quitoque.fr `/recettes` listing page — see {@link extractRecipeCards}. */
-interface QuitoqueCard {
-  url: string;
-  title: string;
-  image: string | null;
-}
-
-/**
- * Scrapes every recipe card out of a quitoque.fr `/recettes` listing page.
- * There's no `ItemList` JSON-LD to lean on (unlike marmiton.ts) — but each
- * card is a single `<a class="card__content_header" href="/recettes/…">`
- * wrapping its own `<img>`, so no "nearest preceding image" pairing is
- * needed (unlike 750g.ts). The real image URL is the `<img>`'s `data-src`
- * (a lazy-load attribute); its `src` is only a placeholder. `href` is a
- * root-relative path, resolved against {@link SITE_ORIGIN} here so callers
- * get a canonical absolute URL.
- *
- * Attribute-order-agnostic: matches every `<a>…</a>`, keeps the ones whose
- * `class` contains `card__content_header`, and reads `href`/`alt`/`data-src`
- * wherever they sit.
- */
-function extractRecipeCards(html: string): QuitoqueCard[] {
-  const cards: QuitoqueCard[] = [];
-  const anchorPattern = /<a\s+([^>]*?)>([\s\S]*?)<\/a>/g;
-  for (const match of html.matchAll(anchorPattern)) {
-    const attrs = match[1] ?? "";
-    if (!/class="[^"]*\bcard__content_header\b[^"]*"/.test(attrs)) continue;
-    const href = /\bhref="(\/recettes\/[^"]+)"/.exec(attrs)?.[1];
-    if (href === undefined) continue;
-    const inner = match[2] ?? "";
-    const title = /\balt="([^"]*)"/.exec(inner)?.[1] ?? "";
-    if (title.length === 0) continue;
-    cards.push({
-      url: `${SITE_ORIGIN}${href}`,
-      title,
-      image: /\bdata-src="([^"]+)"/.exec(inner)?.[1] ?? null,
-    });
-  }
-  return cards;
-}
-
-/**
- * Re-labels a `RecipeSourceFetchError`/`RecipeSourceParseError` thrown by
- * the generic `jsonLdRecipeAdapter` (`sourceKey` `"jsonLdRecipe"`) as having
- * come from this adapter (`sourceKey` `"quitoque"`) — same reasoning as
- * marmiton.ts's identically-named helper: `fetchDetail`/`parse` are thin
- * wrappers around the generic adapter, but a caller reading `.sourceKey`
- * off a caught `RecipeSourceError` should see the source it asked about.
- * (Not factored out into a shared helper — 750g/manger-bouger each keep
- * their own copy too; three near-identical five-liners aren't worth a
- * module.)
- */
-function rekeySourceError(err: unknown): unknown {
-  if (err instanceof RecipeSourceFetchError) {
-    return new RecipeSourceFetchError(SOURCE_KEY, err.message, { cause: err.cause });
-  }
-  if (err instanceof RecipeSourceParseError) {
-    return new RecipeSourceParseError(SOURCE_KEY, err.message, { cause: err.cause });
-  }
-  return err;
-}
-
-/**
- * quitoque.fr — a French meal-kit company whose site publishes a large
- * browsable recipe catalogue (`/recettes`, ~2700 recipes). Unofficial
- * (`official: false`, same reasoning as jsonLdRecipeAdapter/marmiton/750g/
- * mangerBouger): no published API, this reads ordinary pages and the
- * schema.org JSON-LD they embed for search engines. `robots.txt` allows
- * `/recettes` (and lists `ClaudeBot`/`GPTBot`/`Google-Extended` explicitly
- * under `allow: /`).
- *
- * The thinnest kind of wrapper — like marmiton.ts, `fetchDetail`/`parse`
- * delegate straight to {@link jsonLdRecipeAdapter} (a quitoque.fr recipe
- * page's JSON-LD is a plain schema.org `Recipe`, the sole element of a
- * top-level array, which `findRecipeNode` already handles). Only `list()`
- * is site-specific: `/recettes?page=N` with a card scrape (see
- * {@link extractRecipeCards}). The site has no real free-text search, so a
- * `query` is a best-effort substring filter over each page's card titles
- * (same accepted gap 750g.ts documents for its own search).
- */
-export const quitoqueAdapter: RecipeSourceAdapter<{ html: string; url: string }> = {
-  key: SOURCE_KEY,
-  name: "Quitoque",
-  official: false,
-  iconUrl: `${SITE_ORIGIN}/favicon.ico`,
-  // Le contenu de quitoque.fr (noms, ingrédients, instructions) est en
-  // français — détermine contre quel modèle/locale d'étiquettes
-  // d'ingrédients translateRecipe (recipe-translation.ts) résout les
-  // recettes de cette source lors d'une prévisualisation/d'un import.
-  locale: "fr",
-
-  async list(params: RecipeSourceListParams): Promise<RecipeSourceListResult> {
-    try {
-      // Curseur opaque = numéro de page suivant ; quitoque.fr pagine via
-      // `?page=N` (page 1 implicite quand le paramètre est absent), même
-      // esprit que marmiton.ts/750g.ts.
-      const page = params.cursor ? Number(params.cursor) : 1;
-      const query = (params.query ?? "").trim().toLowerCase();
-      const listUrl = `${LIST_URL}${page > 1 ? `?page=${page}` : ""}`;
-
-      let response: Response;
-      try {
-        response = await fetch(listUrl);
-      } catch (cause) {
-        throw new RecipeSourceFetchError(
-          SOURCE_KEY,
-          `Network error listing Quitoque recipes (${listUrl})`,
-          { cause },
-        );
-      }
-      if (!response.ok) {
-        throw new RecipeSourceFetchError(
-          SOURCE_KEY,
-          `Quitoque responded ${response.status} (${listUrl})`,
-        );
-      }
-      const html = await response.text();
-
-      const rawCards = extractRecipeCards(html);
-      const cards =
-        query.length > 0
-          ? rawCards.filter((card) => card.title.toLowerCase().includes(query))
-          : rawCards;
-
-      const items: RecipeSourceListItem[] = cards.map((card) => ({
-        externalId: card.url,
-        title: card.title,
-        picture: card.image,
-        url: card.url,
-      }));
-
-      // Une page qui ne renvoie **aucune** carte est le signal de fin
-      // (même logique que marmiton.ts). Basé sur le nombre de cartes
-      // brutes, pas filtrées : une page qui a des cartes mais dont aucune
-      // ne matche `query` peut quand même avoir une suite qui matche.
-      const nextCursor = rawCards.length > 0 ? String(page + 1) : null;
-
-      return { items, nextCursor };
-    } catch (err) {
-      // Rethrown as-is (already keyed "quitoque" by whichever branch above
-      // threw it) — this adapter's only caller (`sources.service.ts`)
-      // already handles/logs failures centrally; this method just isn't
-      // allowed a bare `async` body without a try/catch per the repo's
-      // convention. Same reasoning as `marmiton.ts`/`750g.ts`.
-      throw err;
-    }
-  },
-
-  // `externalId` est directement l'URL canonique de la recette sur
-  // quitoque.fr (renvoyée telle quelle par `list()` ci-dessus) — même
-  // convention que `jsonLdRecipeAdapter.fetchDetail`, à qui cette méthode
-  // délègue entièrement.
-  async fetchDetail(externalId: string): Promise<{ html: string; url: string }> {
-    try {
-      return await jsonLdRecipeAdapter.fetchDetail(externalId);
-    } catch (err) {
-      // Pas un simple re-throw : `rekeySourceError` est le traitement utile
-      // que ce point d'appel doit faire de l'erreur (relabelliser sa
-      // `sourceKey`), conformément à la convention await/try-catch du repo.
-      throw rekeySourceError(err);
-    }
-  },
-
-  parse(raw: { html: string; url: string }): ParsedRecipe {
-    try {
-      return jsonLdRecipeAdapter.parse(raw);
-    } catch (err) {
-      throw rekeySourceError(err);
-    }
-  },
-};

apps/api/src/sources/the-meal-db.ts

@@ -66,91 +66,20 @@ function detailUrl(idMeal: string): string {
   return `https://www.themealdb.com/meal/${idMeal}`;
 }
 
-/** Category-list response shape (`/list.php?c=list`) — same `meals` envelope as everything else, but each row only carries `strCategory`. */
-interface TheMealDbCategoryListResponse {
-  meals: { strCategory: string | null }[] | null;
-}
-
-/** Narrows to meals that actually carry a name — a titleless row isn't worth surfacing in a browse list. */
-function hasName(meal: TheMealDbMeal): meal is TheMealDbMeal & { strMeal: string } {
-  return Boolean(meal.strMeal);
-}
-
-/** Maps one raw meal (from `/search.php` or `/filter.php`) into the generic list-item shape. */
-function toListItem(meal: TheMealDbMeal & { strMeal: string }) {
-  return {
-    externalId: meal.idMeal,
-    title: meal.strMeal,
-    picture: meal.strMealThumb,
-    url: detailUrl(meal.idMeal),
-  };
-}
-
-/**
- * Name search (`/search.php?s=`) — the only mode TheMealDB's free tier
- * offers for a non-empty query. One response holds every match, so there's
- * never a next page.
- */
-async function searchByName(query: string): Promise<RecipeSourceListResult> {
-  try {
-    const data = await fetchTheMealDb<TheMealDbMealsResponse>(
-      `/search.php?s=${encodeURIComponent(query)}`,
-    );
-    return { items: (data.meals ?? []).filter(hasName).map(toListItem), nextCursor: null };
-  } catch (err) {
-    throw err; // see fetchTheMealDb()'s catch comment above
-  }
-}
-
-/**
- * "Browse everything" (an empty/omitted query). TheMealDB's free tier has
- * no catalog-wide listing endpoint — `/search.php?s=` only answers with a
- * fixed ~25-meal sample — so this walks the category list instead:
- * `/list.php?c=list` for the categories, then `/filter.php?c={category}`
- * for one category at a time, exposing **one category per cursor step** so
- * the infinite scroll keeps pulling real, distinct pages instead of
- * stalling on that sample (issue #38). The category list is re-fetched on
- * each step rather than cached in module state — it's a single small
- * request, it keeps this adapter stateless like the others, and the walk
- * is paced one step per scroll anyway.
- */
-async function listByCategory(cursor: string | null | undefined): Promise<RecipeSourceListResult> {
-  try {
-    const parsed = Number.parseInt(cursor ?? "0", 10);
-    const startAt = Number.isNaN(parsed) || parsed < 0 ? 0 : parsed;
-
-    const categoryList = await fetchTheMealDb<TheMealDbCategoryListResponse>("/list.php?c=list");
-    const categories = (categoryList.meals ?? [])
-      .map((row) => row.strCategory)
-      .filter((name): name is string => Boolean(name));
-
-    const category = categories[startAt];
-    if (category === undefined) {
-      // Cursor has walked past the last category — the clean end of the list.
-      return { items: [], nextCursor: null };
-    }
-
-    const data = await fetchTheMealDb<TheMealDbMealsResponse>(
-      `/filter.php?c=${encodeURIComponent(category)}`,
-    );
-    const nextCursor = startAt + 1 < categories.length ? String(startAt + 1) : null;
-    return { items: (data.meals ?? []).filter(hasName).map(toListItem), nextCursor };
-  } catch (err) {
-    throw err; // see fetchTheMealDb()'s catch comment above
-  }
-}
-
 /**
  * TheMealDB (themealdb.com) — a free, public recipe API (no scraping: the
  * publisher's own structured JSON, hence `official: true`). The first real
  * `RecipeSourceAdapter` implementation, proving the generic contract
  * (recipe-source-adapter.ts) end to end against a live source.
  *
- * `list()` has two modes (see the helpers above): a non-empty `query` is a
- * name search (`/search.php?s=`, single unpaginated response,
- * `nextCursor: null`); an empty/omitted `query` — this contract's "browse
- * everything" — walks the category list one category per cursor step,
- * since the free tier has no real catalog-wide endpoint.
+ * `list()` is search-only — TheMealDB has no dedicated "browse everything"
+ * endpoint on its free tier. An omitted `query` searches for an empty
+ * string, which TheMealDB happens to answer with a small default sample
+ * (~25 meals) rather than nothing — close enough to this contract's
+ * "omitted `query` means browse everything" convention
+ * (`RecipeSourceListParams.query`) to lean on as-is, though it's a fixed
+ * sample, not the whole catalog. Search isn't paginated either — one
+ * response holds every match, so `nextCursor` is always `null`.
  */
 export const theMealDbAdapter: RecipeSourceAdapter<TheMealDbMeal> = {
   key: SOURCE_KEY,
@@ -164,8 +93,22 @@ export const theMealDbAdapter: RecipeSourceAdapter<TheMealDbMeal> = {
 
   async list(params: RecipeSourceListParams): Promise<RecipeSourceListResult> {
     try {
-      const query = (params.query ?? "").trim();
-      return query.length > 0 ? await searchByName(query) : await listByCategory(params.cursor);
+      const query = params.query ?? "";
+      const data = await fetchTheMealDb<TheMealDbMealsResponse>(
+        `/search.php?s=${encodeURIComponent(query)}`,
+      );
+      const meals = data.meals ?? [];
+      return {
+        items: meals
+          .filter((meal): meal is TheMealDbMeal & { strMeal: string } => Boolean(meal.strMeal))
+          .map((meal) => ({
+            externalId: meal.idMeal,
+            title: meal.strMeal,
+            picture: meal.strMealThumb,
+            url: detailUrl(meal.idMeal),
+          })),
+        nextCursor: null,
+      };
     } catch (err) {
       throw err; // see fetchTheMealDb()'s catch comment above
     }

apps/api/src/types/node-nlp.d.ts

@@ -0,0 +1,50 @@
+/**
+ * Minimal ambient typing for `node-nlp` (no official/DefinitelyTyped types
+ * exist for it) — declares only the `NlpManager` surface
+ * `tech-step-matcher.ts` actually calls, verified against the real
+ * package (v4.27.0) rather than the library's full documented API, which
+ * this repo doesn't use the rest of.
+ */
+declare module "node-nlp" {
+  /** Constructor options this repo passes — `NlpManager` accepts more, only what's used here is typed. */
+  export interface NlpManagerOptions {
+    languages?: string[];
+    forceNER?: boolean;
+    nlu?: { log?: boolean };
+    ner?: { threshold?: number };
+    /** Defaults to `true` — persists the trained model to `modelFileName` (default `model.nlp`, in `process.cwd()`). See `tech-step-matcher.ts`'s own constructor comment for why this repo always sets it `false`. */
+    autoSave?: boolean;
+    /** Defaults to `true` — loads from `modelFileName` instead of training fresh if that file already exists. Always `false` here, same reasoning as `autoSave`. */
+    autoLoad?: boolean;
+  }
+
+  /** One entity `NlpManager.process`'s result reports — see `tech-step-matcher.ts`'s own `NerEntity` for the subset this repo reads. */
+  export interface NlpEntity {
+    entity: string;
+    start: number;
+    end: number;
+    type: string;
+    accuracy?: number;
+    sourceText?: string;
+  }
+
+  /** `NlpManager.process`'s result — trimmed to the fields this repo reads (the real object carries many more). */
+  export interface NlpProcessResult {
+    intent: string;
+    score: number;
+    entities: NlpEntity[];
+  }
+
+  export class NlpManager {
+    public constructor(options?: NlpManagerOptions);
+    public addNamedEntityText(
+      entityName: string,
+      optionName: string,
+      languages: string[],
+      texts: string[],
+    ): void;
+    public addDocument(locale: string, utterance: string, intent: string): void;
+    public train(): Promise<void>;
+    public process(locale: string, text: string): Promise<NlpProcessResult>;
+  }
+}