feat(recipes): ajoute un adaptateur RecipeSourceAdapter pour Manger Bouger

Suit le même schéma que marmitonAdapter/sevenFiftyGAdapter (construit sur
jsonLdRecipeAdapter), avec des différences propres à mangerbouger.fr
(« La Fabrique à Menus », Santé publique France) :

- list() n'utilise pas de JSON-LD du tout — la page de résultats (une app
  Next.js) n'embarque aucun ItemList. Elle est cependant rendue
  côté serveur et expose le même state Redux que le client hydrate, via un
  <script id="__NEXT_DATA__">, qui contient déjà tout ce dont list() a
  besoin (slug/nom/image, pagination). Vérifié en direct : ?query=<texte
  libre> filtre bien côté serveur, et hasMorePages donne un signal de fin
  de pagination plus propre que le 404 de Marmiton ou l'absence de vraie
  pagination de 750g.
- parse() délègue à jsonLdRecipeAdapter mais corrige deux lacunes réelles
  et systématiques de son propre JSON-LD (vérifiées sur 9 recettes,
  72 étapes) : recipeInstructions[].text est un document Slate.js
  sérialisé en JSON (pas du texte) plutôt qu'être aplati ; recipeYield est
  absent partout alors que le nombre de portions existe bien côté site
  (__NEXT_DATA__) — les deux sont corrigés par un patch structuré (parse →
  mutation → réécriture) avant délégation, pas une réimplémentation.

Enregistre mangerBougerAdapter dans registerAllRecipeSources
(sources/index.ts) et complète sources-index.test.ts.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

.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
+  DATABASE_URL: "postgresql://ci:ci@localhost:5432/batchcooking_ci?schema=public"
-  # 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"
   # 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
+    services:
-    # spent queued in "Wait for any earlier test job" below. Also a runaway
+      postgres:
-    # ceiling — Mocha has no `--exit` (`apps/api/.mocharc.json`), so one
+        image: postgres:16-alpine
-    # leaked handle would otherwise hang the job until the runner's global
+        env:
-    # timeout (a `test` job zombied ~1h once). If a hung job hits this
+          POSTGRES_USER: ci
-    # ceiling the runner removes its container, which unblocks the queue.
+          POSTGRES_PASSWORD: ci
-    timeout-minutes: 45
+          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
+      - uses: actions/checkout@v4
-        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: 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
+      - uses: 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: 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
+      - run: pnpm --filter web e2e
-        env:
-          HOST: "0.0.0.0"
-        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
+# No image registry involved: Portainer is wired to this repo's Git remote
-# Forgejo instance's built-in container registry (git.dev.kyuno.fr/<owner>/
+# and builds/redeploys apps/api/Dockerfile itself. This workflow sanity-checks
-# batchcooking-{app,intent-service,llm-worker}, tagged with the release tag
+# that the image actually builds at the tagged commit, publishes a GitHub
-# and `latest`), build+attach a signed Android APK, publish a Forgejo
+# Release, then (best-effort) pings Portainer's deploy webhook so it doesn't
-# Release, then (best-effort) ping Portainer's deploy webhook. Portainer can
+# have to wait for its own polling interval.
-# 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:`.
 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
+  sanity-build:
-  # 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:
     runs-on: ubuntu-latest
     steps:
-      # This runner's job containers don't come with docker preinstalled —
+      - uses: actions/checkout@v4
-      # 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: 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
+  github-release:
-        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:
     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: softprops/action-gh-release@v2
-
-      - uses: https://github.com/actions/setup-node@v4
         with:
-          node-version: 22
+          # Auto-generated from merged PRs since the previous tag — no
-          cache: pnpm
+          # changelog tooling to maintain, consistent with there being no
-
+          # versioning tooling elsewhere in the repo yet.
-      - uses: https://github.com/actions/setup-java@v4
+          generate_release_notes: true
-        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"
 
   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
+# node-nlp's default auto-save file (apps/api/src/lib/recipe-matching/
-# is otherwise all-Node — see that service's own .gitignore for the rest;
+# tech-step-matcher.ts explicitly disables autoSave/autoLoad, but this is a
-# duplicated here too since some tooling only honors the repo-root file).
+# belt-and-suspenders guard against it ever reappearing — a stale trained
-services/tech-step-intent-service/.venv/
+# model on disk must never silently shadow TECH_STEP_TRAINING_DATA).
-services/tech-step-intent-service/__pycache__/
+model.nlp
-services/tech-step-intent-service/.pytest_cache/
 
 # 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
+`docker-compose.yml` ne définit donc que deux services : `postgres` et `app` (un
-applicatif, `APP_PORT` (défaut `3000`) — plus de `WEB_PORT`/`CORS_ORIGIN` à
+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
+coordonner entre deux origines, le frontend et l'API sont désormais servis depuis
-depuis la même origine. Les deux autres services du fichier
+la même origine).
-(`tech-step-intent-service`, `tech-step-llm-worker`) n'exposent eux aucun port
-au host — voir leurs propres README pour leur rôle.
 
-**Registre d'image** : la CI de release (voir plus bas) construit et pousse les
+**Pas de registre d'image** dans cette configuration : l'instance **Portainer** de
-trois images de service — `batchcooking-app`, `batchcooking-intent-service`,
+production est reliée directement au dépôt Git et reconstruit elle-même
-`batchcooking-llm-worker` — sur le **registre de conteneurs intégré à Forgejo**
+`docker-compose.yml`/`apps/api/Dockerfile` à chaque déploiement — la CI ne pousse
-(`git.dev.kyuno.fr/kyuno/…`), taguées à la fois avec le tag de release (`vX.Y.Z`)
+donc aucune image nulle part.
-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`.
 
 ### 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 à
+Le pipeline enchaîne trois jobs : `sanity-build` (build de l'image Docker sans
-ce tag + push sur le registre Forgejo sous `vX.Y.Z` et `latest` — un push
+push, juste pour vérifier qu'elle build encore à ce tag avant de laisser Portainer
-réussi vaut aussi vérification que tout build encore à ce commit),
+redéployer dessus), `github-release` (crée une Release GitHub avec changelog
-`build-android-apk` (APK signé, `versionName` dérivé du tag), `forgejo-release`
+auto-généré à partir des PRs mergées), puis `notify-portainer` — envoie une requête
-(crée la Release Forgejo `vX.Y.Z` et y attache `batchcooking.apk`), puis
+au webhook de redeploy de Portainer si le secret de dépôt `PORTAINER_WEBHOOK_URL`
-`notify-portainer` — envoie une requête au webhook de redeploy de Portainer si
+est configuré (sinon Portainer se resynchronise simplement à son prochain
-le secret de dépôt `PORTAINER_WEBHOOK_URL` est configuré (sinon Portainer se
+polling Git). Pour l'activer : récupérer l'URL du webhook depuis les réglages du
-resynchronise à son prochain polling). Pour l'activer : récupérer l'URL du
+stack Portainer, puis l'ajouter comme secret GitHub `PORTAINER_WEBHOOK_URL`.
-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.
 
 ## 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
+# CORS_ORIGIN=http://localhost:5173
-# 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
 
 # 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,
+  "timeout": 10000
-  "require": ["test-support/mocha-root-hooks.ts"]
 }

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/
+# Applies pending migrations, then seeds the reference data (Diet/Category/
-# Allergy — see src/scripts/seed-runtime.ts), then runs any pending one-time
+# Allergy — see src/scripts/seed-runtime.ts) before starting. Both steps are
-# data backfill (src/scripts/backfill-runtime.ts) before starting. migrate
+# safe to repeat on every container start: migrate deploy only applies
-# deploy only applies pending migrations and the seed upserts by unique
+# pending migrations, and the seed upserts by unique name.
-# name, so both are safe to repeat every start; the backfill step gates
+CMD ["sh", "-c", "node_modules/.bin/prisma migrate deploy && node dist/scripts/seed-runtime.js && node dist/server.js"]
-# 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"]

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")
@@ -99,13 +100,9 @@ model UserProfile {
   passwordHash String @map("password_hash")
   /// Bumped to invalidate previously-issued JWTs (e.g. on password change).
   /// Not in the original spec doc — required for stateless JWT auth.
-  tokenVersion Int      @default(0) @map("token_version")
+  tokenVersion Int    @default(0) @map("token_version")
-  houseId      Int?     @map("house_id")
+  houseId      Int?   @map("house_id")
-  dietId       Int?     @map("diet_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)
+  planning Planning @relation(fields: [planningId], references: [id], onDelete: Cascade)
-  recipe             Recipe         @relation(fields: [recipeId], references: [id])
+  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,52 +514,14 @@ 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[]
+  recipes    RecipeIngredient[]
-  allergies     IngredientAllergy[]
+  allergies  IngredientAllergy[]
   /// Profiles that personally dislike this ingredient — see {@link UserProfileDislikedIngredient}.
-  dislikedBy    UserProfileDislikedIngredient[]
+  dislikedBy UserProfileDislikedIngredient[]
   /// Diet regimes this ingredient is compatible with — see {@link IngredientDiet}.
-  diets         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")
 }
 
@@ -668,13 +596,7 @@ model Unit {
   type         UnitType
   toBaseFactor Decimal  @default(1) @map("to_base_factor") @db.Decimal(12, 4)
 
-  recipeIngredients       RecipeIngredient[]
+  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")
 }
@@ -684,19 +606,14 @@ model Unit {
 /// quantity per recipe, so this join table carries quantity + unit
 /// (project decision, not in the original spec doc).
 model RecipeIngredient {
-  recipeId     Int      @map("recipe_id")
+  recipeId     Int     @map("recipe_id")
-  ingredientId Int      @map("ingredient_id")
+  ingredientId Int     @map("ingredient_id")
-  /// `null` (with `unitId` also `null`) = a "selon le goût" seasoning line —
+  quantity     Decimal @db.Decimal(10, 2)
-  /// salt, pepper… added to taste, with nothing to scale by portions or to
+  unitId       Int     @map("unit_id")
-  /// 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")
 
   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
+/// a node-nlp model trained from in-code data
-/// in-code data (`tech-step-training-data.ts`) once regexes turned out
+/// (`tech-step-training-data.ts`) once regexes turned out unable to
-/// unable to generalize past their own literal vocabulary. Nothing
+/// generalize past their own literal vocabulary. Nothing queries/edits
-/// queries/edits that matching data at runtime anymore (it only ever feeds
+/// that matching data at runtime anymore (it only ever feeds the
-/// that service's one-time training pass), so it no longer needs a table
+/// classifier's one-time training pass), so it no longer needs a table of
-/// of its own — this row now only exists to be a stable id/key other
+/// its own — this row now only exists to be a stable id/key other tables
-/// tables (`StepTechStep`) reference.
+/// (`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
@@ -852,107 +720,13 @@ model StepTechStep {
   contextEnd   Int?   @map("context_end")
   source       String @default("auto")
 
-  step        Step                     @relation(fields: [stepId], references: [id], onDelete: Cascade)
+  step     Step     @relation(fields: [stepId], references: [id], onDelete: Cascade)
-  techStep    TechStep                 @relation(fields: [techStepId], 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
+ * of surfacing as a confusing runtime error later.
- * rules (e.g. `blankAsUnset` on the `FORGEJO_*` trio) can be unit-tested
- * without the process-wide `process.env` the singleton below parses.
  */
-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 allowed by CORS — must match wherever apps/web is served from. */
-   * Origin(s) allowed by CORS, comma-separated — parsed below into a
+  CORS_ORIGIN: z.string().default("http://localhost:5173"),
-   * `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),
-    ),
   /**
    * 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
+// in `lib/recipe-matching/tech-step-training-data.ts`'s
-// `TECH_STEP_TRAINING_DATA`, not here: it's owned and trained entirely by
+// `TECH_STEP_TRAINING_DATA`, not here: unlike this list, it's read by
-// that separate Python service (see its own README), not read by this
+// `TechStepClassifierService`'s training pass, not the seed script, so it
-// seed script at all, so it doesn't belong alongside the rest of this
+// doesn't belong alongside the rest of this file's DB-seeded reference
-// file's DB-seeded reference data. Every entry here must have a matching
+// data. Every entry here must have a matching entry there.
-// 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
+ * lifts from an English-language source (`ParsedRecipeIngredient`) against
- * `Ingredient`/`Unit` reference catalogs — the ingredient-side counterpart
+ * our own `Ingredient`/`Unit` reference catalogs — the ingredient-side
- * to `tech-step-matcher.ts`'s technique detection, built for the same
+ * counterpart to `tech-step-matcher.ts`'s technique detection, built for
- * reason: a source's raw text has no idea our catalogs even exist.
+ * 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
+ * ingredient/unit labels are plain hand-written English text
- * supported `locale` (`INGREDIENT_LABELS_EN`/`INGREDIENT_LABELS_FR`/
+ * (`INGREDIENT_LABELS_EN`/`UNIT_LABELS_EN`, `packages/shared`) — matching
- * `UNIT_LABELS_EN`/`UNIT_LABELS_FR`, `packages/shared`) — matching them
+ * them against arbitrary free text (extra adjectives, plurals, "large diced
- * 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;
 }
 
-/**
+/** Lowercases, strips diacritics (via `normalizeText`) and splits `text` into stemmed word tokens — empty/non-letter runs are dropped, not kept as empty tokens. */
- * Naive French stemmer — French regular plurals are overwhelmingly just
+function tokenize(text: string): string[] {
- * "+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[] {
   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
+ * all appear as a contiguous run in `name`, the one with the most words
- * with the most words wins (most specific — "chicken breast" over bare
+ * wins (most specific — "chicken breast" over bare "chicken"); ties break
- * "chicken"); ties break on the lowest `ingredientId`, for a deterministic
+ * on the lowest `ingredientId`, for a deterministic result independent of
- * result independent of catalog order. `locale` must match whatever
+ * catalog order.
- * `catalog`'s labels were loaded in (see {@link loadIngredientCatalog}) —
- * defaults to `"en"`.
  */
-export function matchIngredientName(
+export function matchIngredientName(name: string, catalog: IngredientMatchEntry[]): number | null {
-  name: string,
+  const nameTokens = tokenize(name);
-  catalog: IngredientMatchEntry[],
-  locale = "en",
-): number | null {
-  const nameTokens = tokenize(name, locale);
   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 à
+ * Resolves free-text `unitText` (e.g. `"tbsp"`, `"Cups"`) to the matching
- * soupe de farine"`) to the best-matching `Unit` in `catalog`, or `null` if
+ * `Unit` in `catalog`, or `null` if nothing matches. A unit is a single
- * nothing matches. Same ordered-contiguous-run search as
+ * word by convention (see `UNIT_LABELS_EN`), so this is a whole-token
- * {@link matchIngredientName}, longest match wins — **not** the
+ * equality check (after stemming/normalizing), not the substring search
- * single-first-word equality check this function used before French
+ * `matchIngredientName` does — `"cup"` shouldn't match inside an unrelated
- * support existed: every English unit synonym happens to be one word, so
+ * longer word.
- * 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"`.
  */
-export function matchUnit(
+export function matchUnit(unitText: string, catalog: UnitMatchEntry[]): number | null {
-  unitText: string,
+  const tokens = tokenize(unitText);
-  catalog: UnitMatchEntry[],
+  if (tokens.length === 0) return null;
-  locale = "en",
+  const firstToken = tokens[0];
-): number | null {
-  const textTokens = tokenize(unitText, locale);
-  if (textTokens.length === 0) return null;
 
-  let best: { unitId: number; tokenCount: number } | null = null;
   for (const entry of catalog) {
-    for (const synonym of entry.synonyms) {
+    if (entry.synonyms.some((synonym) => stemWord(normalizeText(synonym)) === firstToken)) {
-      const synonymTokens = tokenize(synonym, locale);
+      return entry.unitId;
-      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 };
-      }
     }
   }
-  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
+// good enough for a best-effort quantity, not meant to model ranges.
-// `[.,]` 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.
 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() };
 }
 
-/**
+/** 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. */
- * Per-locale matching label tables {@link loadIngredientCatalog}/
+export async function loadIngredientCatalog(): Promise<IngredientMatchEntry[]> {
- * {@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[]> {
   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}. */
+/** 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(locale = "en"): Promise<UnitMatchEntry[]> {
+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
+ * English label {@link matchUnit} is fed when a quantity was found but no
- * but no unit word was — see the `unitId` fallback below. Each is the
+ * unit word was — see the `unitId` fallback below. `"piece"` (`UNIT_LABELS_EN`,
- * catalog's generic "counted, no further unit" entry (`Unit.key` `"piece"`)
+ * `packages/shared`) is the catalog's generic "counted, no further unit"
- * in that locale's own label table (`UNIT_LABELS_EN`/`UNIT_LABELS_FR`,
+ * entry (French "unité").
- * `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.
  */
-const FALLBACK_COUNT_UNIT_LABEL_BY_LOCALE: Record<string, string> = {
+const FALLBACK_COUNT_UNIT_LABEL = "piece";
-  en: "piece",
-  fr: "unité",
-};
 
 /**
  * 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) ??
+      matchUnit(unitText, unitCatalog) ??
-      (quantity !== null ? matchUnit(fallbackCountUnitLabel, unitCatalog, locale) : null);
+      (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/unit matching only has English data today
- * (`INGREDIENT_LABELS_EN`/`_FR`, `UNIT_LABELS_EN`/`_FR`, `packages/shared`)
+ * (`INGREDIENT_LABELS_EN`/`UNIT_LABELS_EN`, `packages/shared`) — for any
- * — `loadIngredientCatalog(locale)`/`loadUnitCatalog(locale)` are always
+ * `locale` other than `"en"` this skips `loadIngredientCatalog`/
- * called, never specially skipped for a particular locale: a locale with no
+ * `loadUnitCatalog` entirely and leaves every ingredient's `ingredientId`/
- * label table of its own (anything but `"en"`/`"fr"`) just gets back empty
+ * `unitId` at the neutral `null` `translateRecipeSteps` already stubs in,
- * catalogs from those two loaders, and `translateRecipeIngredients` over an
+ * the same "no matching-language data" degradation tech-step matching
- * empty catalog naturally leaves every ingredient's `ingredientId`/`unitId`
+ * already has for a locale with no mappings.
- * 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).
  */
 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),
+      loadIngredientCatalog(),
-      loadUnitCatalog(locale),
+      loadUnitCatalog(),
     ]);
     return {
       ...translated,
-      ingredients: translateRecipeIngredients(
+      ingredients: translateRecipeIngredients(recipe.ingredients, ingredientCatalog, unitCatalog),
-        recipe.ingredients,
-        ingredientCatalog,
-        unitCatalog,
-        locale,
-      ),
     };
   } 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`
+ * future change to `tech-step-training-data.ts` must clear (see that
- * must clear (see that module's own doc comment).
+ * 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
+ * `tech-step-training-data.ts` (including the LLM-assisted suggestions the
- * LLM-assisted suggestions the worker in `services/tech-step-llm-worker`
+ * worker in `services/tech-step-llm-worker` proposes) is expected to run
- * 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 {
+import { TECH_STEP_TRAINING_DATA } from "./tech-step-training-data.js";
-  findIngredientMentions,
-  type IngredientMention,
-  loadIngredientCatalog,
-  loadUnitCatalog,
-} from "./ingredient-matcher.js";
-import { type IntentServiceTemperature, intentServiceClient } from "./intent-service-client.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
+ * small hybrid pipeline built on `node-nlp` ({@link TechStepClassifierService}):
- * delegated to `services/tech-step-intent-service` — a spaCy-based
- * microservice, see {@link IntentServiceClient} and that service's own
- * README):
  *
- * 1. **NER** (the intent service's `PhraseMatcher`, built from its own
+ * 1. **NER** (node-nlp enum entities, `synonyms` in `TECH_STEP_TRAINING_DATA`)
- *    `training_data.py`'s `synonyms`) finds every *candidate* technique
+ *    finds every *candidate* technique mention in the whole
- *    mention in the whole description, each with its exact character span —
+ *    description, each with its exact character span — mechanically the
- *    mechanically the same job the old regexes did, just as flat synonym
+ *    same job the old regexes did, just as flat synonym lists instead of
- *    lists instead of hand-written patterns. This step alone is *not* the
+ *    hand-written patterns (node-nlp's own stemmer/fuzzy matching already
- *    final answer — see step 3.
+ *    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
+ * 3. **NLP intent classification** (node-nlp's `NlpManager`, trained on
- *    on its own `training_data.py`'s `utterances`) then classifies each
+ *    `TECH_STEP_TRAINING_DATA`'s `utterances`) then classifies each clause
- *    clause on its own — this is what actually delivers "meaning, not
+ *    on its own — this is what actually delivers "meaning, not keywords":
- *    keywords": the classifier was deliberately trained on paraphrases that
+ *    the classifier was deliberately trained on paraphrases that never use
- *    never use the technique's own verb (e.g. "jusqu'à ce que le beurre ait
+ *    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
+ * `test/tech-step-matcher.test.ts`); the classifier itself needs a one-time
- * `TechStep.key -> id` lookup from the DB, memoized on the shared
+ * training pass (`_ensureTrained`, node-nlp's `NlpManager.train()`) plus a
- * {@link techStepClassifier} singleton rather than repeated per call — the
+ * `TechStep.key -> id` lookup from the DB, both memoized on the shared
- * NLP model itself trains once, inside `services/tech-step-intent-service`'s
+ * {@link techStepClassifier} singleton rather than repeated per call —
- * own startup, entirely independently of this class (see that service's
+ * training is the expensive part (a few hundred ms for this corpus), never
- * README — this repo no longer pushes any corpus to it over HTTP).
+ * 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
+ * Raised from `0.65` after finding real (non-adversarial) misclassified
- * `services/tech-step-intent-service` (spaCy `textcat`, exclusive classes)
+ * clauses that scored just above the old threshold — e.g. English recipe
- * — its score distribution is meaningfully different from node-nlp's own
+ * text run through the French classifier (which must find *nothing*,
- * classifier, and shifts again every time the corpus' technique count
+ * confirmed by `recipe-translation.test.ts`'s own locale-isolation test)
- * changes (more exclusive classes generally means a *lower* natural
+ * scored `0.69` for `boil`, essentially classifier noise on
- * confidence ceiling, softmax mass spread thinner).
+ * out-of-vocabulary input rather than a real, confident verdict. The
- *
+ * clauses this threshold exists to actually trust score far higher in
- * Currently `0.25`, set against the corpus as expanded to ~74 techniques
+ * practice (`0.91`–`1.0` for the real corrected cases found this session)
- * (`services/tech-step-intent-service/intent_service/training_data.py`,
+ * — `0.75` sits comfortably above the noise floor and below every genuine
- * `_TRAINING_ITERATIONS = 25`, `textcat` trained on each technique's own
+ * match seen so far.
- * `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.
  */
-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.
+ * state (the trained model, the memoized training/lookup promises), not
- * The actual NER/intent-classification model lives entirely in
+ * just grouped stateless helpers.
- * `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.
  */
 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. */
+  /** node-nlp's manager — both NER (enum entities) and NLP (intent classification) live on the same instance, trained together. */
-  private _techStepIdsLoaded: Promise<void> | undefined;
+  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`. */
+  public constructor() {
-  private _utensilIdsLoaded: Promise<void> | undefined;
+    this._manager = new NlpManager({
-  private _utensilIdByUid: Map<string, number> | undefined;
+      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
+   * Forces training plus node-nlp's own one-time lazy setup (loading its
-   * server startup (see `server.ts`, which also retries this against a
+   * bundled per-language stemmers/tokenizers on the *first* real
-   * not-yet-reachable intent service), rather than stalling whichever
+   * `NlpManager.process()` call takes a few seconds by itself, separate
-   * request happens to be first to save/preview a recipe. Doesn't wait on
+   * from and much slower than the ~40ms `train()` pass — measured against
-   * `services/tech-step-intent-service` finishing its own training — that
+   * this corpus while tuning the pipeline) to happen now, synchronously
-   * service is only ever considered "up" by Docker Compose/CI once it
+   * with server startup (see `server.ts`), rather than stalling whichever
-   * already is (see that service's `GET /health`), so by the time this
+   * request happens to be first to save/preview a recipe.
-   * 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.
    */
   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
+      const nerResult = await this._manager.process(locale, description);
-      // `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 candidates: TechniqueCandidate[] = nerResult.entities
-        .filter((entity) => entity.kind === "technique")
+        // node-nlp's language plugins also auto-extract their own built-in
-        .map((entity) => ({ uid: entity.uid, start: entity.start, end: entity.end }));
+        // entities (numbers, durations, dates…) alongside the enum
-      const utensilEntities = nerResult.entities.filter((entity) => entity.kind === "utensil");
+        // entities `_train` registered from `TECH_STEP_TRAINING_DATA` —
-      const temperatureMentions = nerResult.temperatures;
+        // `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")
+        .filter((entity) => entity.type === "enum")
-        .map((entity) => ({ uid: entity.uid, start: entity.start, end: entity.end }));
+        .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,
+          intentUid,
-          score: result.intent === null ? 0 : result.score,
+          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);
+      const result = await this._manager.process(locale, clauseText);
-      if (result.intent !== null && result.score >= CONFIDENCE_THRESHOLD) {
+      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
+   * Trains `_manager` from {@link TECH_STEP_TRAINING_DATA} and resolves the
-   * `_techStepIdsLoaded` so a burst of concurrent calls (several steps of
+   * `uid -> TechStep.id` lookup, both exactly once — memoized on
-   * the same recipe save, awaited via the same event loop tick) all await
+   * `_trained` so a burst of concurrent calls (several steps of the same
-   * the one in-flight DB query rather than each firing their own.
+   * 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> {
+  private async _ensureTrained(): Promise<void> {
-    if (this._techStepIdsLoaded === undefined) {
+    if (this._trained === undefined) {
-      this._techStepIdsLoaded = this._loadTechStepIds();
+      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
+      // A failed training pass must be retried by the *next* call, not
-      // future call permanently rejecting against a stale failed promise.
+      // leave every future call permanently rejecting against a stale
-      this._techStepIdsLoaded = undefined;
+      // 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
-    }
-  }
 
-  /** `Utensil.key -> id` counterpart of {@link _ensureTechStepIdsLoaded} — same memoize-once-retry-on-failure shape. */
+      for (const entry of TECH_STEP_TRAINING_DATA) {
-  private async _ensureUtensilIdsLoaded(): Promise<void> {
+        for (const [locale, data] of [
-    if (this._utensilIdsLoaded === undefined) {
+          ["fr", entry.fr],
-      this._utensilIdsLoaded = this._loadUtensilIds();
+          ["en", entry.en],
-    }
+        ] as const) {
-    try {
+          if (data.synonyms.length > 0) {
-      await this._utensilIdsLoaded;
+            this._manager.addNamedEntityText(entry.uid, entry.uid, [locale], data.synonyms);
-    } catch (err) {
+          }
-      this._utensilIdsLoaded = undefined;
+          for (const utterance of data.utterances) {
-      throw err;
+            this._manager.addDocument(locale, utterance, entry.uid);
-    }
+          }
-  }
+        }
+      }
 
-  private async _loadUtensilIds(): Promise<void> {
+      await this._manager.train();
-    try {
-      const utensils = await prisma.utensil.findMany({ select: { id: true, key: true } });
-      this._utensilIdByUid = new Map(utensils.map((utensil) => [utensil.key, utensil.id]));
     } 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:
+ * profile. Reads the session cookie, verifies the JWT, and re-checks
- * Bearer <jwt>` header when there's no cookie — see {@link readBearerToken}),
+ * `tokenVersion` against the database — so a stateless JWT can still be
- * verifies the JWT, and re-checks `tokenVersion` against the database — so a
+ * invalidated server-side (e.g. on password change / logout-everywhere,
- * stateless JWT can still be invalidated server-side (e.g. on password
+ * once that feature exists) despite carrying no server-side session.
- * 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
+ * @throws {HttpError} `401 NOT_AUTHENTICATED` for any failure — missing
- *   and no usable Bearer header, malformed/expired JWT, unknown profile, or
+ *   cookie, malformed/expired JWT, unknown profile, or stale tokenVersion.
- *   stale tokenVersion. Never distinguishes the reason to the client.
+ *   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];
+    const token = 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);
     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 {
+import { deleteAccountSchema, loginSchema, signupSchema } from "@batch-cooking/shared";
-  type AuthResponse,
-  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
+    res.status(201).json(profile);
-    // `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);
   }),
 );
 
@@ -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 {
+import { addPlanningItemSchema, ErrorCode, getPlanningByDateSchema } from "@batch-cooking/shared";
-  addPlanningItemSchema,
-  assignLeftoverSchema,
-  ErrorCode,
-  getPlanningByDateSchema,
-} from "@batch-cooking/shared";
 import { Router } from "express";
 import { type AuthLocals, requireAuth } from "../../middlewares/require-auth.js";
-import {
+import { addPlanningItem, getPlanningForDate, removePlanningItem } from "./planning.service.js";
-  addPlanningItem,
-  assignLeftoverPlanningItem,
-  discardLeftover,
-  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,
+        portions: input.portions,
-        portionsRequested: input.portionsRequested,
       },
       include: { recipe: { select: { id: true, name: true } } },
     });
 
-    analytics.recordEvent("planning.item_added", {
+    return {
-      actorId: viewerId,
+      id: item.id,
-      context: {
+      weekDay: item.weekDay,
-        recipeId: input.recipeId,
+      meal: item.meal,
-        portions,
+      portions: item.portions,
-        portionsRequested: input.portionsRequested,
+      recipe: item.recipe,
-      },
+    };
-    });
-
-    return toPlanningItemView(item);
   } 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
+ * Loads `stepId`'s current `description` length (the only thing a
- * now, not just its length — see {@link submitTechStepCorrection}'s
+ * correction needs from the step itself), or throws — `404 STEP_NOT_FOUND`
- * `raw` derivation for a manual temperature mention), or throws —
+ * if no such step exists, or if it exists but doesn't belong to `recipeId`
- * `404 STEP_NOT_FOUND` if no such step exists, or if it exists but doesn't
+ * (the route's own `:id`/`:stepId` nesting is meaningless otherwise — a
- * belong to `recipeId` (the route's own `:id`/`:stepId` nesting is
+ * request naming a real step under the wrong recipe should look identical
- * meaningless otherwise — a request naming a real step under the wrong
+ * to naming one that doesn't exist, same "don't leak which part was wrong"
- * recipe should look identical to naming one that doesn't exist, same
+ * posture `assertRecipeVisible` already has for visibility). Otherwise
- * "don't leak which part was wrong" posture `assertRecipeVisible` already
+ * whatever {@link assertRecipeVisible} throws (`404 RECIPE_NOT_FOUND`,
- * has for visibility). Otherwise whatever {@link assertRecipeVisible}
+ * never `403`) if the recipe exists but isn't visible to the viewer.
- * 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
+ *   matching existing entry is deleted outright. A no-op if none matches
- *   ingredient/utensil metadata attached to it, auto or manual — nothing
+ *   (nothing to remove).
- *   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).
  *
  * Runs inside the same transaction {@link submitTechStepCorrection} uses
- * for the audit-trail insert, so a request never leaves any of these
+ * for the audit-trail insert, so a request never leaves the two effects
- * effects (the permanent correction record, the live sequence change, the
+ * (the permanent correction record, the live sequence change) only
- * metadata replacement) only partially applied.
+ * 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 }
-          id: correction.previousTechStep.id,
-          key: correction.previousTechStep.key,
-          isPlaceholder: correction.previousTechStep.isPlaceholder,
-          displayName: correction.previousTechStep.displayName,
-        }
       : null,
     correctedTechStep: correction.correctedTechStep
-      ? {
+      ? { id: correction.correctedTechStep.id, key: correction.correctedTechStep.key }
-          id: correction.correctedTechStep.id,
-          key: correction.correctedTechStep.key,
-          isPlaceholder: correction.correctedTechStep.isPlaceholder,
-          displayName: correction.correctedTechStep.displayName,
-        }
       : 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
+ *   `start`/`end` fall outside the step's current `description` (it may
- *   `input.ingredients`/`input.utensils`/`input.temperatures`' own spans)
+ *   have been edited since the user last saw it). `404 TECH_STEP_NOT_FOUND`
- *   fall outside the step's current `description` (it may have been
+ *   if either tech-step id doesn't exist.
- *   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.
  */
 export async function submitTechStepCorrection(
   recipeId: number,
@@ -430,160 +245,49 @@ export async function submitTechStepCorrection(
 ): Promise<SubmitTechStepCorrectionResult> {
   try {
     const step = await loadVisibleStepOrThrow(recipeId, stepId, correctorId, viewerHouseId);
-    const descriptionLength = step.description.length;
 
-    const spans = [
+    if (input.start >= step.descriptionLength || input.end > step.descriptionLength) {
-      { start: input.start, end: input.end },
+      throw new HttpError(
-      ...(input.ingredients ?? []),
+        400,
-      ...(input.utensils ?? []),
+        ErrorCode.INVALID_CORRECTION_SPAN,
-      ...(input.temperatures ?? []),
+        `Span [${input.start}, ${input.end}) falls outside step ${stepId}'s description (length ${step.descriptionLength})`,
-    ];
+      );
-    for (const span of spans) {
-      if (span.start >= descriptionLength || span.end > descriptionLength) {
-        throw new HttpError(
-          400,
-          ErrorCode.INVALID_CORRECTION_SPAN,
-          `Span [${span.start}, ${span.end}) falls outside step ${stepId}'s description (length ${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(
+    const { correction, techSteps } = await prisma.$transaction(async (tx) => {
-      async (tx) => {
+      const createdCorrection = await tx.stepTechStepCorrection.create({
-        // A technique the catalog doesn't have (issue #130) — mint a
+        data: {
-        // placeholder `TechStep` for it, in the same transaction as the
+          stepId: step.id,
-        // correction that references it, then proceed exactly as if its id had
+          correctorId,
-        // been sent as `correctedTechStepId`. Same shape as
+          start: input.start,
-        // `recipe.service.ts`'s `resolveIngredientLines` does for a
+          end: input.end,
-        // free-text ingredient.
+          previousTechStepId: input.previousTechStepId ?? null,
-        const placeholderTechStepId =
+          correctedTechStepId: input.correctedTechStepId ?? null,
-          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 createdCorrection = await tx.stepTechStepCorrection.create({
-          data: {
-            stepId: step.id,
-            correctorId,
-            start: input.start,
-            end: input.end,
-            previousTechStepId: input.previousTechStepId ?? null,
-            correctedTechStepId: effectiveCorrectedTechStepId,
-          },
-          include: correctionInclude,
-        });
-
-        await applyManualCorrection(
-          tx,
-          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,
-                })),
-              },
-        );
-
-        // 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,
-          },
-        });
-
-        return { correction: createdCorrection, techSteps: freshTechSteps, placeholderTechStepId };
-      },
-    );
-
-    analytics.recordEvent("tech_step.correction_submitted", {
-      actorId: correctorId,
-      context: {
-        recipeId,
-        stepId,
-        previousTechStepId: input.previousTechStepId ?? null,
-        correctedTechStepId: correction.correctedTechStepId,
-      },
-    });
-    if (placeholderTechStepId !== null) {
-      analytics.recordEvent("tech_step.placeholder_proposed", {
-        actorId: correctorId,
-        context: {
-          recipeId,
-          stepId,
-          techStepId: placeholderTechStepId,
-          name: input.correctedTechStepName ?? "",
         },
+        include: correctionInclude,
       });
-    }
+
+      await applyManualCorrection(
+        tx,
+        step.id,
+        { start: input.start, end: input.end },
+        input.previousTechStepId ?? null,
+        input.correctedTechStepId ?? null,
+      );
+
+      const freshTechSteps = await tx.stepTechStep.findMany({
+        where: { stepId: step.id },
+        orderBy: { order: "asc" },
+        include: { techStep: true },
+      });
+
+      return { correction: createdCorrection, techSteps: freshTechSteps };
+    });
 
     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: {
+        techSteps: { orderBy: { order: "asc" }, include: { techStep: true } },
-          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 } } } },
-                    diets: { include: { diet: true } },
-                  },
-                },
-                unit: true,
-              },
-            },
-            utensils: { include: { utensil: true } },
-            temperatures: true,
-          },
-        },
       },
     },
+    diets: { include: { diet: 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. */
+type IngredientWithDetails = RecipeWithDetails["ingredients"][number]["ingredient"];
-export type IngredientWithDetails = RecipeWithDetails["ingredients"][number]["ingredient"];
+type UnitWithDetails = RecipeWithDetails["ingredients"][number]["unit"];
-/** 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"]>;
 
-/** 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). */
+/** Shapes a Prisma `Unit` row into the public {@link UnitView} — same "Decimal → number" conversion `reference.service.ts`'s `getUnits` does. */
-export function toUnitView(unit: UnitWithDetails): UnitView {
+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`. */
+/** Shapes a Prisma `Ingredient` (with its `allergies`/`diets` relations included) into the public {@link IngredientView} — same aplattening as `reference.service.ts`'s `getIngredients`. */
-export function toIngredientView(ingredient: IngredientWithDetails): IngredientView {
+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. */
+/** 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(
+function toRecipeSummaryView(recipe: RecipeWithDetails): RecipeSummaryView {
-  recipe: RecipeWithDetails,
+  const allergens = aggregateAllergens(
-  glutenFreeDiet: DietView | undefined,
+    recipe.ingredients.map((recipeIngredient) => toIngredientView(recipeIngredient.ingredient)),
-): RecipeSummaryView {
-  const ingredientViews = 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),
+    allergens,
-    // Computed from the ingredients, not stored — see `RecipeSummaryView.diets`.
+    diets: recipe.diets.map((recipeDiet) => toDietView(recipeDiet.diet)),
-    diets: computeRecipeDietViews(ingredientViews, glutenFreeDiet),
     isFavorite: recipe.favoritedBy.length > 0,
   };
 }
@@ -198,25 +143,10 @@ export function toStepTechStepViews(
 ): StepTechStepView[] {
   const views: StepTechStepView[] = [];
   for (const stepTechStep of techSteps) {
-    const {
+    const { start, end, contextStart, contextEnd, techStep, source } = stepTechStep;
-      start,
-      end,
-      contextStart,
-      contextEnd,
-      techStep,
-      source,
-      ingredients,
-      utensils,
-      temperatures,
-    } = stepTechStep;
     if (start === null || end === null) continue;
     views.push({
-      techStep: {
+      techStep: { id: techStep.id, key: techStep.key },
-        id: techStep.id,
-        key: techStep.key,
-        isPlaceholder: techStep.isPlaceholder,
-        displayName: techStep.displayName,
-      },
       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}. */
+/** Shapes a Prisma `Recipe` (with {@link recipeInclude} included) into the public {@link RecipeView}. */
-function toRecipeView(recipe: RecipeWithDetails, glutenFreeDiet: DietView | undefined): 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: Number(recipeIngredient.quantity),
-    quantity: recipeIngredient.quantity === null ? null : Number(recipeIngredient.quantity),
+    unit: toUnitView(recipeIngredient.unit),
-    unit: recipeIngredient.unit === null ? null : 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"
+ * `Recipe` rows that avoid every member of `houseId`'s declared allergens
- * toggle (`suitableForHousehold` on `listRecipes`):
+ * and, for every member with a declared regime, are tagged with that
- *  - `allergenWhere` — a `Prisma.RecipeWhereInput` excluding any recipe that
+ * regime — the planning recipe picker's "convient à tout le foyer" toggle
- *    contains an allergen declared by a member (still expressible in SQL).
+ * (`suitableForHousehold` on `listRecipes`). Computed server-side (a small
- *  - `requiredDietKeys` — every regime declared by a member (`omnivore`
+ * extra query to gather the household's members' allergy/regime ids)
- *    dropped: it constrains nothing). A recipe must satisfy *all* of them —
+ * rather than exposed to the client as raw per-member data: a member's
- *    a recipe suiting a vegetarian member doesn't automatically suit a
+ * allergies/regime are private the same way visibility already keeps a
- *    gluten-free one. Applied as a post-filter in {@link listRecipes} on the
+ * recipe's existence private (404, never 403) — nothing here should let
- *    *computed* `RecipeSummaryView.diets`, since regimes are no longer a
+ * one member infer another's medical/dietary info from the shape of a
- *    stored column to query (issue #131).
+ * filtered list. Deliberately excludes `UserProfileDislikedIngredient` —
- *
+ * the schema already treats disliked ingredients as a taste preference,
- * Computed server-side (a small extra query for the members' allergy/regime
+ * not a safety constraint (see that model's doc comment), so it doesn't
- * data) rather than exposed to the client as raw per-member data: a
+ * belong in a filter framed around what's safe/appropriate to serve.
- * 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).
  */
-async function suitableForHousehold(
+async function suitableForHouseholdWhere(houseId: number): Promise<Prisma.RecipeWhereInput> {
-  houseId: number,
-): Promise<{ allergenWhere: Prisma.RecipeWhereInput; requiredDietKeys: string[] }> {
   try {
     const members = await prisma.userProfile.findMany({
       where: { houseId },
-      select: {
+      select: { dietId: true, allergies: { select: { allergyId: true } } },
-        diet: { select: { key: true } },
-        allergies: { select: { allergyId: true } },
-      },
     });
-    const requiredDietKeys = [
+    const requiredDietIds = [
-      ...new Set(
+      ...new Set(members.map((m) => m.dietId).filter((id): id is number => id !== null)),
-        members
-          .map((member) => member.diet?.key)
-          .filter((key): key is string => key !== undefined && key !== "omnivore"),
-      ),
     ];
     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 =
+    const conditions: Prisma.RecipeWhereInput[] = [];
-      excludedAllergyIds.length > 0
+    if (requiredDietIds.length > 0) {
-        ? {
+      // Every diet declared by a member must be among this recipe's tags —
-            ingredients: {
+      // not "at least one", since a recipe suiting a vegetarian member
-              none: {
+      // doesn't automatically suit a gluten-free one too.
-                ingredient: { allergies: { some: { allergyId: { in: excludedAllergyIds } } } },
+      conditions.push({
-              },
+        AND: requiredDietIds.map((dietId) => ({ diets: { some: { dietId } } })),
+      });
+    }
+    if (excludedAllergyIds.length > 0) {
+      conditions.push({
+        ingredients: {
+          none: {
+            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) {
+    if (suitableForHousehold && viewerHouseId !== null) {
-      const household = await suitableForHousehold(viewerHouseId);
+      conditions.push(await suitableForHouseholdWhere(viewerHouseId));
-      conditions.push(household.allergenWhere);
-      requiredDietKeys = household.requiredDietKeys;
     }
     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([
+    const recipes = await prisma.recipe.findMany({
-      prisma.recipe.findMany({
+      where: { AND: conditions },
-        where: { AND: conditions },
+      include: recipeInclude(viewerId),
-        include: recipeInclude(viewerId),
+      orderBy: { name: "asc" },
-        orderBy: { name: "asc" },
+    });
-      }),
+    return recipes.map(toRecipeSummaryView);
-      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;
   } 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 —
+ * Creates a recipe with its ingredients, ordered steps and diet tags in one
- * steps' `order` is derived from their position in `input.steps`,
+ * 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
+ * `GET /reference/ingredients`; there's no way to create one here).
- * regimes aren't stored — they're computed from the ingredients on read
+ * `authorId`/`authorHouseId` are fixed at creation and never change on
- * (issue #131). `authorId`/`authorHouseId` are fixed at creation and never
+ * later edits (see {@link updateRecipe}).
- * 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(
+    await assertIngredientsExist(input.ingredients.map((i) => i.ingredientId));
-      input.ingredients.map((i) => i.ingredientId).filter((id): id is number => id !== undefined),
+    await assertUnitsExist(input.ingredients.map((i) => i.unitId));
-    );
+    await assertDietsExist(input.dietIds);
-    await assertUnitsExist(
-      input.ingredients.flatMap((i) => (i.unitId === undefined ? [] : [i.unitId])),
-    );
     // 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,81 +520,63 @@ async function createRecipeInternal(
       source?.locale ?? DEFAULT_TECH_STEP_LOCALE,
     );
 
-    // One transaction so the free-text placeholder `Ingredient` rows and the
+    const created = await prisma.recipe.create({
-    // recipe that references them commit together — a failed recipe create
+      data: {
-    // must never leave orphan placeholders behind.
+        name: input.name,
-    const { created, createdPlaceholders } = await prisma.$transaction(async (tx) => {
+        description: input.description ?? null,
-      const { resolved, createdPlaceholders } = await resolveIngredientLines(
+        picture: input.picture ?? null,
-        input.ingredients,
+        portions: input.portions,
         authorId,
-        tx,
+        authorHouseId,
-      );
+        visibility: input.visibility,
-      const created = await tx.recipe.create({
+        sourceId: source?.sourceId ?? null,
-        data: {
+        externalId: source?.externalId ?? null,
-          name: input.name,
+        ingredients: {
-          description: input.description ?? null,
+          create: input.ingredients.map((ingredient) => ({
-          picture: input.picture ?? null,
+            ingredientId: ingredient.ingredientId,
-          portions: input.portions,
+            quantity: ingredient.quantity,
-          authorId,
+            unitId: ingredient.unitId,
-          authorHouseId,
+          })),
-          visibility: input.visibility,
-          sourceId: source?.sourceId ?? null,
-          externalId: source?.externalId ?? null,
-          ingredients: {
-            create: resolved.map((line) => ({
-              ingredientId: line.ingredientId,
-              quantity: line.quantity,
-              unitId: line.unitId,
-            })),
-          },
-          steps: {
-            create: stepsWithTechSteps.map(({ step, matches }, index) => ({
-              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) },
-            })),
-          },
         },
-        include: recipeInclude(authorId),
+        steps: {
-      });
+          create: stepsWithTechSteps.map(({ step, matches }, index) => ({
-      return { created, createdPlaceholders };
+            description: step.description,
+            picture: step.picture ?? null,
+            order: index,
+            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 toRecipeView(created);
-    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());
   } 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
+ * /profile/allergies`). `authorId`/`authorHouseId` are untouched — editing
- * recomputed from the ingredients on the next read (issue #131).
+ * never transfers ownership.
- * `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(
+    await assertIngredientsExist(input.ingredients.map((i) => i.ingredientId));
-      input.ingredients
+    await assertUnitsExist(input.ingredients.map((i) => i.unitId));
-        .map((i) => i.ingredientId)
+    await assertDietsExist(input.dietIds);
-        .filter((ingredientId): ingredientId is number => ingredientId !== undefined),
-    );
-    await assertUnitsExist(
-      input.ingredients.flatMap((i) => (i.unitId === undefined ? [] : [i.unitId])),
-    );
     const stepsWithTechSteps = await matchStepsTechSteps(input.steps, DEFAULT_TECH_STEP_LOCALE);
 
-    // Interactive transaction (not the array form) so any new free-text
+    await prisma.$transaction([
-    // placeholder rows are created in the same atomic unit as the
+      prisma.recipeIngredient.deleteMany({ where: { recipeId: id } }),
-    // delete+recreate of the recipe's content. An *existing* placeholder
+      prisma.step.deleteMany({ where: { recipeId: id } }),
-    // line round-trips by its real `ingredientId` and is left untouched;
+      prisma.recipeDiet.deleteMany({ where: { recipeId: id } }),
-    // only a brand-new `placeholderName` line creates a row here.
+      prisma.recipe.update({
-    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({
         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) => ({
+            create: input.ingredients.map((ingredient) => ({
-              ingredientId: line.ingredientId,
+              ingredientId: ingredient.ingredientId,
-              quantity: line.quantity,
+              quantity: ingredient.quantity,
-              unitId: line.unitId,
+              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
+              techSteps: {
-              // persist the clause metadata (ingredients / utensils /
+                create: matches.map((match, order) => ({
-              // temperatures), not just the technique span. Omitting it
+                  techStepId: match.techStepId,
-              // here is what left every edited recipe with temperature-less
+                  start: match.start,
-              // `preheat` steps, so `cooking-optimizer.ts` could never spot
+                  end: match.end,
-              // an oven-temperature conflict between two of them.
+                  contextStart: match.contextStart,
-              techSteps: { create: toStepTechStepCreateInputs(matches) },
+                  contextEnd: match.contextEnd,
+                  order,
+                })),
+              },
             })),
           },
+          diets: { create: input.dietIds.map((dietId) => ({ dietId })) },
         },
-      });
+      }),
-      return createdPlaceholders;
+    ]);
-    });
 
-    for (const placeholder of createdPlaceholders) {
+    return toRecipeView(await findRecipeOrThrow(id, viewerId));
-      analytics.recordEvent("ingredient.placeholder_created", {
-        actorId: viewerId,
-        context: { name: placeholder.name, ingredientId: placeholder.id, recipeId: id },
-      });
-    }
-
-    return toRecipeView(await findRecipeOrThrow(id, viewerId), await loadGlutenFreeDiet());
   } 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`).
+ * `TECH_STEPS`). Not consumed by the recipe UI yet — see {@link TechStepView}.
- *
- * 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.
  */
 export async function getTechSteps(): Promise<TechStepView[]> {
   try {
-    const techSteps = await prisma.techStep.findMany({
+    return await prisma.techStep.findMany({ orderBy: { key: "asc" } });
-      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" } });
   } 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`);
+ * matching itself only has English data today (see `ingredient-matcher.ts`);
- * `loadIngredientCatalog`/`loadUnitCatalog` are always called with
+ * a non-English-locale source simply gets `ingredient`/`unit: null` on
- * `adapter.locale` directly, never specially skipped for a particular
+ * every line, the same graceful "no matching-language data" degradation
- * one — a source whose locale has no label table of its own just gets back
+ * `translateRecipe` already has.
- * 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.
  *
  * @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),
+        adapter.locale === "en"
-        loadUnitCatalog(adapter.locale),
+          ? loadIngredientCatalog()
-        // Real catalog techniques only — a draft preview is never a saved
+          : Promise.resolve<IngredientMatchEntry[]>([]),
-        // recipe, so it can't carry a user-proposed placeholder technique
+        adapter.locale === "en" ? loadUnitCatalog() : Promise.resolve<UnitMatchEntry[]>([]),
-        // (issue #130); `isPlaceholder`/`displayName` are the neutral values.
+        prisma.techStep.findMany({ select: { id: true, key: true } }),
-        prisma.techStep.findMany({
-          where: { isPlaceholder: false },
-          select: { id: true, key: true },
-        }),
       ]);
-    const techStepById = new Map(
+    const techStepById = new Map(techStepsByKey.map((techStep) => [techStep.id, techStep]));
-      techStepsByKey.map((techStep) => [
-        techStep.id,
-        { ...techStep, isPlaceholder: false, displayName: null },
-      ]),
-    );
 
     const translatedIngredients = translateRecipeIngredients(
       parsed.ingredients,
       ingredientCatalog,
       unitCatalog,
-      adapter.locale,
     );
-    const [ingredientViews, unitViews, utensilViews] = await Promise.all([
+    const [ingredientViews, unitViews] = await Promise.all([getIngredients(), getUnits()]);
-      getIngredients(),
-      getUnits(),
-      getUtensils(),
-    ]);
     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,
+ * entries against the *current* classifier
- * utensils, temperatures) — against the *current* classifier
+ * (`tech-step-matcher.ts`/`tech-step-training-data.ts`), the same way
- * (`tech-step-matcher.ts`, delegating to `services/tech-step-intent-service`),
+ * `updateRecipe` does when a user resaves a recipe through the UI —
- * the same way `updateRecipe` does when a user resaves a recipe through the
+ * always `"fr"` (`DEFAULT_TECH_STEP_LOCALE` in `recipe.service.ts`; there's
- * UI: both build the row payload from the shared
+ * no persisted per-recipe locale to recover for a step that already
- * {@link toStepTechStepCreateInputs}. Always `"fr"`
+ * exists, so this matches real resave behavior exactly rather than
- * (`DEFAULT_TECH_STEP_LOCALE` in `recipe.service.ts`; there's no persisted
+ * guessing).
- * 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
+ * `contextStart`/`contextEnd` columns a previous session added) keeps
- * the clause-metadata writers were wired into the *update* path at all,
+ * whatever it was matched with at the time until it's next resaved.
- * 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,19 +72,18 @@ 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`:
+        await tx.stepTechStep.createMany({
-        // `createMany` cannot write the nested `ingredients` / `utensils` /
+          data: nonOverlappingMatches.map((match, index) => ({
-        // `temperatures` children, and silently dropping those is exactly
+            stepId: step.id,
-        // the bug this script shared with the old `updateRecipe` — see
+            techStepId: match.techStepId,
-        // `toStepTechStepCreateInputs`. A backfill that leaves recipes
+            order: startOrder + index,
-        // without their clause temperatures defeats the whole point of
+            start: match.start,
-        // running it (`cooking-optimizer.ts` needs them).
+            end: match.end,
-        const inputs = toStepTechStepCreateInputs(nonOverlappingMatches);
+            contextStart: match.contextStart,
-        for (const [index, input] of inputs.entries()) {
+            contextEnd: match.contextEnd,
-          await tx.stepTechStep.create({
+            source: "auto",
-            data: { ...input, stepId: step.id, order: startOrder + index, 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
+ * `tech-step-training-data.ts` and running `retrain-tech-steps.ts` — this
- * running `retrain-tech-steps.ts` — this script never writes anything,
+ * script never writes anything, purely a read-only report to stdout:
- * 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
+ * `TECH_STEP_TRAINING_DATA` is read together, matching how that file
- * how that file itself is organized (one block per technique).
+ * 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
+ *   1. A maintainer has already hand-edited `tech-step-training-data.ts`
- *      `services/tech-step-intent-service/intent_service/training_data.py`
+ *      (informed by `list-pending-training-suggestions.ts`'s report), and
- *      (informed by `list-pending-training-suggestions.ts`'s report),
  *      decided which `TechStepTrainingSuggestion` ids they incorporated
- *      (`--applied=`) or explicitly discarded (`--rejected=`), **and
+ *      (`--applied=`) or explicitly discarded (`--rejected=`).
- *      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.
  *   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 (and pays node-nlp's own one-time lazy
- * Trains the tech-step classifier (a `POST /v1/train` round-trip per locale
+// setup cost — see `TechStepClassifierService.warmUp`) before accepting
- * to `services/tech-step-intent-service` — see
+// any traffic, so the first real recipe save/preview isn't the one stuck
- * `TechStepClassifierService.warmUp`) before accepting any traffic, so the
+// waiting several seconds for it.
- * first real recipe save/preview isn't the one stuck waiting for it.
+try {
- *
+  await techStepClassifier.warmUp();
- * Retried with exponential backoff: in Docker Compose, `app`'s own
+} catch (err) {
- * `depends_on: tech-step-intent-service: condition: service_healthy`
+  // Not fatal to startup — a failed warm-up just means the *next* call
- * (`docker-compose.yml`) already means that service is up by the time this
+  // retries training itself (see `_ensureTrained`'s own retry-on-failure
- * runs, but native dev (`pnpm dev:api`, no Compose ordering at all) can
+  // comment), same graceful-degrade posture as everywhere else training
- * easily start this before the intent service has finished loading its
+  // failures surface. Still worth a loud log: this shouldn't normally fail.
- * spaCy models — a transient connection failure here shouldn't need a
+  logger.error("Tech-step classifier warm-up failed", {
- * manual restart. Still non-fatal after every attempt is exhausted: the
+    error: err instanceof Error ? err.message : String(err),
- * *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 {
-      await techStepClassifier.warmUp();
-      return;
-    } catch (err) {
-      if (attempt === maxAttempts) {
-        logger.error("Tech-step classifier warm-up failed after retries", {
-          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

@@ -18,26 +18,9 @@ const SOURCE_KEY = "750g";
 // 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
+// needed, same as every other adapter in this family.
-// 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
@@ -298,16 +281,12 @@ function rekeySourceError(err: unknown): unknown {
  *
  * - `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
+ *   so this instead calls the plain GET endpoint that widget's own JS calls
- *   own JS calls internally (`SEARCH_URL`), an "AI answer engine" that
+ *   internally (`SEARCH_URL`), an "AI answer engine" that returns a curated
- *   returns a curated batch of cards rather than an exhaustive, paginated
+ *   batch of cards for a free-text query rather than an exhaustive,
- *   catalog — verified live, requesting `page=2` of the same query always
+ *   paginated catalog — verified live, requesting `page=2` of the same
- *   comes back empty, so `nextCursor` is always `null` in that case, same
+ *   query always comes back empty, so `nextCursor` is always `null` here,
- *   as `theMealDbAdapter`'s "one response holds every match". An empty
+ *   same as `theMealDbAdapter`'s "one response holds every match".
- *   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
@@ -333,27 +312,19 @@ export const sevenFiftyGAdapter: RecipeSourceAdapter<{ html: string; url: string
   async list(params: RecipeSourceListParams): Promise<RecipeSourceListResult> {
     try {
       const query = params.query ?? "";
-      const page = params.cursor ? Number(params.cursor) : 1;
+      // `params.cursor` est ignoré : voir le commentaire du module — cette
-      const hasQuery = query.length > 0;
+      // recherche ne pagine pas réellement, il n'existe donc jamais de
-
+      // curseur légitime à faire transiter (`nextCursor` vaut toujours
-      // Deux endpoints distincts selon qu'il y a un texte de recherche ou
+      // `null` ci-dessous).
-      // non — voir les commentaires de `SEARCH_URL`/`LATEST_RECIPES_URL` :
+      const searchUrl = `${SEARCH_URL}?query=${encodeURIComponent(query)}&query_type=written_query&page=1`;
-      // 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);
+        response = await fetch(searchUrl);
       } catch (cause) {
         throw new RecipeSourceFetchError(
           SOURCE_KEY,
-          `Network error listing 750g recipes (${listUrl})`,
+          `Network error searching 750g (${searchUrl})`,
           {
             cause,
           },
@@ -362,7 +333,7 @@ export const sevenFiftyGAdapter: RecipeSourceAdapter<{ html: string; url: string
       if (!response.ok) {
         throw new RecipeSourceFetchError(
           SOURCE_KEY,
-          `750g responded ${response.status} (${listUrl})`,
+          `750g search responded ${response.status} (${searchUrl})`,
         );
       }
       const html = await response.text();
@@ -379,14 +350,7 @@ export const sevenFiftyGAdapter: RecipeSourceAdapter<{ html: string; url: string
         url: card.url,
       }));
 
-      // La recherche par texte libre ne pagine pas du tout (voir le
+      return { items, nextCursor: null };
-      // 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`)

apps/api/src/sources/index.ts

@@ -2,17 +2,14 @@ import { registerRecipeSource } from "../lib/recipe-sources/recipe-source-regist
 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`,
+ * — `theMealDbAdapter`, `marmitonAdapter`, `sevenFiftyGAdapter` and
- * `mangerBougerAdapter`, `quitoqueAdapter` and `ohMonBentoAdapter`. Called
+ * `mangerBougerAdapter`. Called once, explicitly, by the two real entry
- * once, explicitly, by the two real entry points that need the registry
+ * points that need the registry populated:
- * populated:
  *
  * - `server.ts` — the running API process, before it starts listening.
  * - `prisma/seed.ts` — so `syncRecipeSources` has something to mirror into
@@ -42,6 +39,4 @@ export function registerAllRecipeSources(): void {
   registerRecipeSource(marmitonAdapter);
   registerRecipeSource(sevenFiftyGAdapter);
   registerRecipeSource(mangerBougerAdapter);
-  registerRecipeSource(quitoqueAdapter);
-  registerRecipeSource(ohMonBentoAdapter);
 }

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

@@ -18,13 +18,11 @@ const SOURCE_KEY = "mangerBouger";
 // 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
+// has everything `list()` needs. Verified live: `?query=<free text>` really
-// (`?diet=ALL&page=N&query=<free text>`): `query` really filters
+// filters server-side (not just a client-side URL update over an
-// server-side (not just a client-side URL update over an already-fetched
+// already-fetched page), and `page`/`hasMorePages` behave as real,
-// page), and `page`/`hasMorePages` behave as real, consistent pagination.
+// consistent pagination — the best-behaved of this adapter family's three
-// The *catalogue browse* path (no `query` term) must be the bare
+// sources on that front.
-// `?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/";
 
@@ -44,7 +42,7 @@ interface MangerBougerListPageData {
     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. */
+        /** Whether a further page exists for the current `page`/`query`/`diet` combination — verified live: 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). */
         hasMorePages?: boolean;
       };
     };
@@ -286,18 +284,8 @@ export const mangerBougerAdapter: RecipeSourceAdapter<{ html: string; url: strin
   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
+      const query = params.query ?? "";
-      // empty `&query=` on the "browse everything" path (filter absent) made
+      const listUrl = `${LIST_URL}?diet=ALL&page=${page}&query=${encodeURIComponent(query)}`;
-      // 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 {

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
+ * `list()` is search-only — TheMealDB has no dedicated "browse everything"
- * name search (`/search.php?s=`, single unpaginated response,
+ * endpoint on its free tier. An omitted `query` searches for an empty
- * `nextCursor: null`); an empty/omitted `query` — this contract's "browse
+ * string, which TheMealDB happens to answer with a small default sample
- * everything" — walks the category list one category per cursor step,
+ * (~25 meals) rather than nothing — close enough to this contract's
- * since the free tier has no real catalog-wide endpoint.
+ * "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();
+      const query = params.query ?? "";
-      return query.length > 0 ? await searchByName(query) : await listByCategory(params.cursor);
+      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>;
+  }
+}

apps/api/test-support/mocha-root-hooks.ts

@@ -1,40 +0,0 @@
-import { techStepClassifier } from "../src/lib/recipe-matching/tech-step-matcher.js";
-import { resetDatabase } from "./reset-db.js";
-
-/**
- * Mocha root hook plugin (see `.mocharc.json`'s `require`) — runs once
- * before every test file's own suites, regardless of load order.
- *
- * Warms up `techStepClassifier` here — resolving the `TechStep.key -> id`
- * lookup from the DB (see `TechStepClassifierService._loadTechStepIds`) —
- * instead of leaving it to happen lazily on whichever test file Mocha
- * happens to load first, same as `server.ts` does before the real server
- * ever accepts traffic. Fast by itself (one DB query, one HTTP call to
- * `services/tech-step-intent-service`): that service now trains itself
- * entirely at its own process startup (see its own README), so unlike
- * before this migration, nothing here waits on a slow training pass — CI's
- * own "wait for `/health`" step (`.github/workflows/ci.yml`) is what
- * ensures that service is already fully trained before `pnpm --filter api
- * test` even starts.
- *
- * `resetDatabase()` runs first, deliberately: id resolution needs
- * `TechStep` rows, and a freshly-migrated (never-seeded) test database has
- * none yet. Every per-test `beforeEach` in this suite already calls
- * `resetDatabase()` again before its own test, which is a no-op
- * duplication of effort but not a correctness problem: `TRUNCATE ...
- * RESTART IDENTITY` plus deterministic re-seeding (`seedReferenceData`)
- * assigns the exact same ids every time, so the `uid -> id` map memoized
- * here from this first reset stays valid for every reset after it.
- */
-export const mochaHooks = {
-  // biome-ignore lint/suspicious/noExplicitAny: Mocha's root hook `this` (a Context with `.timeout()`) isn't typed without @types/mocha (not a dependency here) — same untyped-`this` shape already used in tech-step-worker.routes.test.ts.
-  async beforeAll(this: any): Promise<void> {
-    // A little more generous than Mocha's normal 10s per-test default
-    // (`.mocharc.json`) purely for a slower/contended CI runner's first
-    // network round-trip to `services/tech-step-intent-service` — not
-    // because anything here waits on training anymore.
-    this.timeout(30000);
-    await resetDatabase();
-    await techStepClassifier.warmUp();
-  },
-};

apps/api/test-support/reset-db.ts

@@ -47,10 +47,7 @@ export async function resetDatabase() {
       "planning_item", "planning",
       "recipe_ingredient", "step_tech_step", "step", "tech_step",
       "recipe", "ingredients", "sources", "unit",
-      "user_profiles", "diet", "house",
+      "user_profiles", "diet", "house"
-      "tour_progress", "tour_scenario_step", "tour_scenario", "tour_target",
-      "contact_message",
-      "admin_users", "analytics_events", "worker_heartbeats", "backfill_state"
     RESTART IDENTITY CASCADE;
   `);
   await seedReferenceData(prisma);