Le tout premier run réel du job build-android (après le merge de #64)
échouait avec './gradlew: Permission denied' — gradlew était suivi par
git en 100644 (non exécutable) au lieu de 100755, probablement perdu au
commit initial du projet Android natif (#63) sur cette machine Windows.
Corrige le mode suivi par git (git update-index --chmod=+x) et ajoute un
chmod +x défensif juste avant l'exécution dans ci.yml, puisque ce bit
n'a aucun sens sous Windows et peut être reperdu silencieusement par un
futur commit sur cette machine.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Le job `test` de la run précédente a échoué sur une saturation du runner
(P1002 Prisma + timeout Docker), pas sur le code — le même job échouait
au même moment sur toutes les branches, `main` compris. Diff 100 % frontend.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Réutilise l'API Releases de Forgejo (publique, sans authentification) comme
source de vérité pour "quelle est la dernière version" — zéro nouvel
endpoint backend : useAppUpdateCheck compare App.getInfo().version
(@capacitor/app, nouvelle dépendance) au tag_name de
GET .../releases/latest, et pointe "Mettre à jour" vers l'URL stable de
téléchargement (issue #65).
Comparaison de version en logique pure (version-compare.ts), séparée du
hook effectful — testée isolément via un test de composant Cypress
(version-compare.cy.tsx, même patron que highlight-tech-steps.cy.tsx :
aucun montage, juste describe/it/expect sur des fonctions pures).
Natif uniquement (Capacitor.isNativePlatform()) : @capacitor/app et
@capacitor/preferences restent en import dynamique dans le hook, jamais
dans le bundle web (même patron que capacitor-token-store.ts) — vérifié
dans le build (deux petits chunks séparés, pas dans le bundle principal).
Vérification au démarrage à froid + à la reprise depuis l'arrière-plan
(appStateChange), avec un throttle de 6h et une mémorisation de la version
déjà rejetée dans @capacitor/preferences pour ne jamais re-harceler sur la
même version. Bannière discrète (pas une Dialog modale), bouton "Mettre à
jour" ouvrant le lien de téléchargement dans le navigateur système plutôt
qu'un flux PackageInstaller in-app.
Vérifié : pnpm lint, pnpm --filter web build, le test de composant (9/9),
et layout/smoke/planning-page e2e (18/18, la bannière étant un no-op sur
le web ne devait rien casser — confirmé).
Closes#66
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
18 échecs éparpillés (timeouts 10s sur des suites sans rapport entre elles,
PrismaClientKnownRequestError, un mismatch d'ID façon ré-seed concurrent) sur
373 passing — signature exacte de la course documentée dans
ci-forgejo-runner-constraints (postgres partagé + contention RAM/CPU du
runner), pas un vrai échec de code : ce PR ne touche que ci.yml/le projet
Android/le README, rien que la suite Mocha exerce différemment.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nouveau job build-android dans ci.yml, gardé par needs: sur les 5 jobs
existants (lint/test/intent-service-test/build/e2e) et limité à main via
if: github.ref == 'refs/heads/main' — c'est ce qui garantit que l'APK n'est
empaqueté qu'une fois la suite de tests existante verte, pas juste construit
en parallèle d'elle.
APK signé avec un vrai keystore de release (jamais généré par la CI —
Android refuse une mise à jour signée par une clé différente de celle déjà
installée) : ajoute signingConfigs.release à build.gradle, lu depuis
l'environnement (ANDROID_KEYSTORE_PATH/_PASSWORD, ANDROID_KEY_ALIAS/_PASSWORD),
jamais codé en dur. *.jks/*.keystore désormais réellement ignorés par git
(étaient commentés dans le .gitignore généré par Capacitor).
README : documente les 5 secrets Forgejo requis et la génération du
keystore. Aucune suite de tests instrumentés Android n'existe (zéro code
natif au-delà de la coquille Capacitor) — "testée" est satisfait par le
gate sur la suite existante, pas par une suite native à inventer.
Risque documenté, pas résolu par avance : aucun build Android n'a jamais
tourné sur ce runner Forgejo auto-hébergé, contrairement aux 4 autres jobs.
Closes#64
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Sur la page vitrine `/`, sous la rangée de CTA du hero (pas un 3e bouton :
un compte reste nécessaire quelle que soit la plateforme), un lien discret
vers l'APK Android + une ligne d'aide.
- Cible : l'asset `batchcooking.apk` de la dernière release taguée Forgejo
(`/releases/latest/download/…`, nom de fichier stable) — pas un artefact
de CI. 404 tant que #64 + la correction de release.yml ne sont pas faits :
état transitoire assumé, ce ticket n'ajoute que le lien.
- `mobileHint` : rappel honnête que c'est un .apk à sideloader, pas une
distribution Play Store.
- i18n `landing.hero.mobileDownload` / `mobileHint` ; style discret dans
landing-page.scss ; scénario Cypress de plus (présence + href du lien).
Vérifs : `pnpm build` + `pnpm lint` OK. `landing.feature` non lancé en
local (le hoist `tslib` de `@cypress/vite-dev-server` dans ce node_modules
est cassé par un `pnpm install --force` interrompu + un verrou concurrent
sur `@esbuild/win32-x64` ; `pnpm-lock.yaml` inchangé, la CI n'est pas
affectée) → couvert par le job `e2e` de la CI.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Dernière étape du portage mobile #39 : génère et versionne le projet natif
Android (`npx cap add android`) que les phases 1 à 3 (jeton Bearer, passe
responsive, plomberie web) préparaient déjà.
- `apps/web/android/` — projet natif Capacitor 8.5. Permission `INTERNET`
présente par défaut, `applicationId` = `fr.kyuno.batchcooking`.
- Thème natif aligné sur la palette « Mise en Place » (`_theme.scss`) :
`colors.xml` redéfinit `colorPrimary`/`Dark`/`Accent` (basilic/vermillon)
par-dessus les défauts Material de la lib capacitor-android ; barre de
statut basilic foncé, fond de fenêtre « porcelaine » pour ne pas flasher
blanc au démarrage à froid ; `postSplashScreenTheme` pour la transition.
- Icône adaptative + splash (clair et sombre, toutes densités) générés
depuis `apps/web/assets/logo.svg` (monogramme « bC », géométrie seule, pas
de `<text>`) via `@capacitor/assets` ; sources et commande de régénération
documentées dans `apps/web/assets/README.md`. `@capacitor/assets` n'est pas
ajouté aux dépendances (il tire `sharp`, hors `onlyBuiltDependencies`) —
lancé via `npx`.
- `.gitignore` racine : ignore `/.idea/` (Android Studio ouvre désormais le
dépôt comme projet). `biome.json` : exclut `apps/web/android` du lint.
- README : section « Application mobile (Android) » (prérequis + flux de
build `build:capacitor` → `cap sync` → Android Studio).
Le bundle web copié sous `android/app/src/main/assets/public/` reste
git-ignoré (régénéré par `pnpm build:capacitor && npx cap sync android`).
Build de l'APK + test sur appareil : à finir dans Android Studio — la CI
self-hosted ne build pas Android.
Vérifs : `pnpm build` + `pnpm lint` OK ; `npx cap sync android` OK ; tous
les XML natifs bien formés.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
StepDescription faisait `useState(techSteps)` puis `liveTechSteps.flatMap(...)` :
quand la prop `techSteps` arrivait `undefined`, `.flatMap` levait
`TypeError: Cannot read properties of undefined (reading 'flatMap')`, remontée
par Cypress comme une erreur applicative non capturée. Observé de façon
intermittente sur le parcours « modifier une recette » : après enregistrement,
`RecipeFormPage` navigue vers `/recettes/:id`, dont le détail se rendait parfois
avant que `techSteps` ne soit peuplé.
- `StepDescription` : `techSteps` devient optionnel et `liveTechSteps` retombe
sur `[]` (dans le `useState` et le `useEffect` de resync), pour que tous les
consommateurs (`.flatMap`, `splitDescriptionSegments`,
`findTechStepForTemperature`, lookup `activeStepTechStep`) aient toujours un
vrai tableau — même posture « tolérer la donnée manquante, ne pas planter »
que le reste du composant.
- `recipe-form.ts` : le mock de la recette 7 envoyait une étape sans `techSteps`,
contrairement au vrai `StepView` et à tous les autres mocks de la suite —
corrigé en `techSteps: []`.
- `recipes.cy.ts` : nouveau test de non-régression déterministe — un payload
d'étape sans `techSteps` doit rendre la description en texte brut. Vérifié
qu'il échoue bien (`flatMap` undefined) sans le correctif du composant.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
L'UI par-dessus l'API `/admin/api/tours*`. Nouvelle entrée
`/admin/didacticiels` dans `AdminLayout` (i18n `admin.nav.tours`), route
sous `RequireAdmin`+`AdminLayout` dans `App.tsx`.
`ToursPage.tsx` : liste des scénarios à gauche (nom, état activé/désactivé,
nombre d'étapes) ; à droite l'éditeur du scénario sélectionné —
- renommer, activer/désactiver ;
- éditer la liste d'étapes (route, cible via `<select>` alimenté par
`GET /tours/targets`, titre, contenu), réordonner (↑/↓), ajouter,
retirer ;
- « Enregistrer » → un seul `PATCH /:id` qui remplace tout (name/enabled +
étapes rénumérotées `order` = index), erreurs API affichées telles quelles ;
- « Supprimer le scénario » (confirmation `window.confirm`) ;
- « Nouveau scénario » → formulaire clé + nom → `POST /`.
`admin-client.ts` gagne `getTourScenarios` / `getTourTargets` /
`createTourScenario` / `updateTourScenario` / `deleteTourScenario`.
Tests Cypress (`admin-tours.cy.ts`, 4) : liste (activés + désactivés,
nombre d'étapes) ; édition nom + réordonnancement d'étapes → un seul PATCH
avec la liste complète réordonnée ; création → POST `{key,name}` ;
suppression après confirmation → DELETE. 4/4 en local ; `pnpm build` +
`pnpm lint` verts.
Closes#44
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Consomme le socle backend de #42/#44 (`GET /reference/tours`,
`GET/POST /profile/tours`). Deux tours : orientation générale (auto sur
`/`) et correction des métadonnées de recette (auto à l'ouverture du
premier popover de correction).
- Dépendance `driver.js` (~5 ko, MIT, zéro dépendance).
- `features/tour/tour-engine.ts` : wrapper vanilla autour de `driver.js` —
gère ce que la lib ne fait pas seule : la navigation React Router entre
étapes situées sur des routes différentes, et un `onFinish` unique
(`"completed"` seulement si on atteint la fin, `"skipped"` pour la croix
/ Échap / clic sur l'overlay).
- `features/tour/TourContext.tsx` : `TourProvider` (charge scénarios +
progression, keyed sur `user?.id` comme `ThemeContext`) et `useTour()`
(`startTour(key)` / `isTourCompleted(key)` / `tours` / `isReady`).
`isReady` est **calculé au render** contre l'id utilisateur chargé — pas
stocké — pour qu'un changement de `user` le repasse à `false`
immédiatement, avant qu'un effet enfant (l'auto-déclenchement) ne tourne
sur des données de complétion périmées.
- `main.tsx` : `<TourProvider>` sous `ThemeProvider`.
- Attributs `data-tour-*` : liens de nav (`AppLayout`), grille / bouton `+`
du 1er créneau / bouton Cuisiner (`PlanningPage`), page liste de courses
(`ShoppingListPage`), description d'étape + section technique du popover
(`StepDescription` / `TechStepCorrectionPopover`).
- Déclenchement auto : tour `general` sur `/` (`PlanningPage`, ref-gardé),
tour `techStepMetadata` à `activeCorrection` non-null (`StepDescription`).
- Section « Revoir un tutoriel » dans `/parametres/preferences-utilisateur`
— un `map` sur `tours`, un bouton « Revoir » par scénario.
- `tour.scss` re-skinne le popover `driver.js` sur les tokens du thème.
- i18n `tour.*` (chrome uniquement : boutons du popover, section « Revoir » ;
le contenu des étapes vient de la base).
Tests Cypress (`tour.feature`, 5 scénarios) : auto-démarrage + élément
surligné pour un nouveau venu ; « Terminé » → complétion enregistrée
`skipped:false` ; croix → `skipped:true` ; un tour déjà vu ne se relance
pas ; « Revoir » le relance depuis les paramètres. Vérifié 5/5 en local.
`pnpm build` + `pnpm lint` verts.
Refs #42
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Deuxième volet backend du tutoriel guidé, sur le socle de #42/#44 : permet
à un admin de créer/éditer/supprimer les scénarios que
`GET /reference/tours` sert au moteur front.
`/admin/api/tours` (agrégateur `admin.routes.ts`, tout derrière
`requireAdmin`) :
- `GET /` — tous les scénarios (activés **et** désactivés) + étapes
ordonnées.
- `GET /targets` — le catalogue `TourTarget` pour le sélecteur de cible de
l'éditeur.
- `POST /` — crée un scénario vide (`key` + `name`) ; 409
`TOUR_KEY_ALREADY_IN_USE` (nouveau code 4025) sur une clé prise.
- `PATCH /:id` — édite `name`/`enabled` **et remplace toute la liste
d'étapes en bloc** (delete-all puis recreate avec `order` = index), même
convention que `updateRecipe` pour les étapes d'une recette. `key`
immuable. 404 `TOUR_NOT_FOUND` (id inconnu), 404 `TOUR_TARGET_NOT_FOUND`
(nouveau code 4054, `targetKey` d'une étape hors catalogue — vérifié
avant d'écrire, les étapes réelles restent intactes si la requête est
rejetée).
- `DELETE /:id` — 204 ; les étapes et les `TourProgress` des utilisateurs
cascadent.
Tests Mocha (`admin-tours.test.ts`) : 401 sans session admin sur chaque
route ; list (activés+désactivés) ; targets ; create→patch pour remplir
les étapes ; remplacement en bloc ; 409 clé dupliquée ; 404 cible
inconnue (sans toucher aux étapes existantes) ; 404 id inconnu ; delete +
cascade vérifiée ; un scénario désactivé disparaît de `/reference/tours`
mais reste dans la liste admin.
Refs #44
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Socle backend, entièrement testable en CI, pour le tutoriel guidé. Le
moteur front (driver.js), l'instrumentation `data-tour-*` et le CRUD admin
viendront ensuite.
Schéma (`schema.prisma` + migration `20260906120000_tour_scenarios`) — les
4 modèles de #44, qui révisent le registre statique prévu par #42 :
- `TourTarget` (`key` PK + `description`) : catalogue des cibles de
surlignage valides, seedé, comme `TechStep`/`Unit`.
- `TourScenario` (`key` stable, `name`, `enabled`) : un scénario rejouable.
- `TourScenarioStep` (`order`, `route?`, `targetKey`, `title`, `content`) :
`title`/`content` sont du **texte libre**, pas des clés i18n (#44 :
contenu administrable → texte, comme le nom d'une recette).
- `TourProgress` (`userProfileId` + `scenarioId`, PK composite) : présence
d'une ligne = scénario vu (terminé *ou* passé).
Seed (`reference-seed-data.ts`) : les 9 `TourTarget` correspondant aux
`data-tour-*` à poser côté front, + les 2 scénarios de #42 (`general`,
`techStepMetadata`) **créés seulement s'ils sont absents** (un admin en
devient propriétaire ensuite). `techStepMetadata` reste court pour
l'instant — #36 (popover qui se ferme en pleine sélection) est ouvert, v1
ne couvre que les gestes qui marchent déjà.
API :
- `GET /reference/tours` (public) → scénarios **activés** + étapes
ordonnées, forme consommée directement par le futur `useTour()`.
- `GET /profile/tours` → `{ completedTourKeys: string[] }`.
- `POST /profile/tours/:tourKey/complete` → upsert idempotent ; corps vide
= terminé, `{ skipped: true }` = passé. Émet `analytics.recordEvent`
`tour.completed` / `tour.skipped` (le dashboard admin agrège déjà tout
type d'`AnalyticsEvent` génériquement — analytics de #44 quasi gratuites).
404 `TOUR_NOT_FOUND` (nouveau code 4053) sur une clé inconnue/désactivée.
`reset-db.ts` truncate les 4 nouvelles tables (reseedées juste après).
Tests Mocha : `GET /reference/tours` (scénarios + étapes ordonnées,
exclusion d'un scénario désactivé) ; `/profile/tours` GET+POST (upsert
idempotent, `skipped`, 404 clé inconnue, 404 tour désactivé, isolation
par profil). Pas de base Postgres locale → exécutés en CI.
Refs #42, #44
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Un visiteur déconnecté sur `/` voit désormais une vraie page de
présentation avant qu'on lui demande de se connecter, au lieu d'être
renvoyé directement vers `/login`.
- `RequireAuth.tsx` devient sensible au chemin : dans sa branche `!user`,
`pathname === "/"` rend `<LandingPage />` ; toutes les autres routes
protégées redirigent vers `/login` exactement comme avant. Aucun
changement de la table de routes — `/` reste `<PlanningPage>` niché sous
`RequireAuth`+`AppLayout`, et `AppLayout` (donc la sidebar) ne monte
jamais pour la vitrine.
- `pages/landing/LandingPage.tsx` + `landing-page.scss` : hero (accroche +
illustration SVG dessinée à la main dans le langage de `lucide-react`,
zéro dépendance ni asset externe) + deux CTA, grille de 4
fonctionnalités (icônes lucide), section « aperçu », CTA final. Copie
entièrement sous le namespace i18n `landing.*`.
- `index.html` : favicon SVG (monogramme « bC ») + `<meta description>` —
`/` est maintenant une page publique partageable.
- Les 3 captures d'écran réelles de la section « aperçu » sont servies
statiquement depuis `public/landing/` (un fichier manquant retombe sur
son `alt`, ne casse pas le build) ; elles restent à produire par un
humain avec l'app lancée sur des données réelles — cf.
`public/landing/README.md`.
- Tests Cypress `landing.feature` : vitrine visible déconnecté sur `/`,
CTA vers `/login` et `/signup`, autre route protégée toujours redirigée,
visiteur connecté voit bien le planning. `smoke.cy.ts` mis à jour pour
tester la redirection depuis `/recettes` (puisque `/` ne redirige plus).
Closes#41
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Les 5 jobs de la run 109 ont échoué tôt sur « git clone: some refs were not
updated » pendant l'étape de checkout, avant même `pnpm install`/`pnpm lint`.
Rien à voir avec cette branche : `pnpm install --frozen-lockfile`, `pnpm lint`
et `pnpm build` sont verts en local.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Tout ce qui est vérifiable en CI de la phase 2 du portage mobile. La
génération du projet natif (`npx cap add android`), le build de l'APK et
le test sur appareil restent une étape manuelle (pas d'Android Studio ici)
— cf. le corps de l'issue #39.
- Dépendances : `@capacitor/core`, `@capacitor/android`,
`@capacitor/preferences` (+ `@capacitor/cli` en dev), toutes en 8.5.x.
- `capacitor.config.ts` : `appId` `fr.kyuno.batchcooking`, `webDir: "dist"`.
- `apps/web/src/api/capacitor-token-store.ts` : implémentation `TokenStore`
adossée à `@capacitor/preferences`, branchée via `setTokenStore()` (le
point d'injection posé en phase 1). Importée dynamiquement dans
`main.tsx` uniquement quand `Capacitor.isNativePlatform()` — le bundle
web ne charge jamais `@capacitor/preferences` (vérifié : chunk séparé de
0,5 ko jamais requis côté navigateur).
- `main.tsx` : `HashRouter` en natif (le bundle packagé sert `dist/`
depuis l'origine locale de la WebView, sans réécriture des liens
profonds vers `index.html`), `BrowserRouter` inchangé sur le web ;
bootstrap async pour poser le token store avant le premier rendu.
- `build:capacitor` (`vite build --mode capacitor`) + `.env.capacitor.example` :
le build packagé a besoin de l'URL absolue de l'API en dur (pas de
"même origine que la page" possible).
Vérifié : `pnpm build` + `pnpm lint` verts ; Cypress smoke/layout/sidebar
14/14 en local (le refactor du bootstrap et le choix de routeur ne
cassent rien côté web).
Refs #39
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Réutilise la philosophie déjà en place pour la sidebar (défilement
horizontal plutôt que compression illisible) au lieu d'un nouveau patron
par page. Tout est strictement additif sous 640px — le rendu desktop est
inchangé.
- `AppLayout.scss` : `.app-content` passe de `--space-xl` (32px) à
`--space-md` (16px) sous 640px — 64px de largeur utile récupérés sur un
écran de ~375px.
- `planning-page.scss` : la grille 7 jours défile déjà horizontalement
(`overflow: auto` + `min-width: 62rem`) ; ce qui casse au tactile, c'est
le `✕` de suppression d'une recette (`opacity: 0` hors survol) — épinglé
visible + cible tactile agrandie sous 640px, idem le bouton « + ».
- `dialog.scss` : `.dialog-panel` garde une gouttière latérale et gagne en
hauteur utile sous 640px (le `--space-2xl` vertical est trop cher sur un
écran court).
- `recipe-picker-dialog.scss` : le split 2 colonnes forcé du catalogue
(plus spécifique que le `@media` de recipes.scss) repasse à une colonne
sous 640px.
Tests : `layout.cy.ts` gagne un bloc « page content under 640px » —
padding de `.app-content`, grille sur son propre scroll sans déborder la
page, `✕` visible au tactile. 10/10 en local.
Refs #39
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
La run #104 a échoué au `beforeAll` racine (`seedReferenceData`, P2002 sur
`key`) parce que la run `main` #103 exécutait son propre job `test` au même
moment sur le conteneur Postgres `--name postgres` partagé. Runner idle,
aucune run concurrente cette fois. Code inchangé — build+lint verts en
local.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Phase 1 du portage mobile (#39) : purement additif côté navigateur, qui
continue d'utiliser le cookie `session` httpOnly inchangé.
- `POST /auth/login` et `POST /auth/signup` renvoient aussi le JWT dans le
corps de la réponse (`AuthResponse` = `SafeUserProfile` + `token`), en
plus de poser le cookie. Un client dont l'origine ne peut pas recevoir
un cookie `SameSite=Lax` (WebView Capacitor) le stocke et le renvoie.
- `requireAuth` lit le cookie en priorité, puis se rabat sur un en-tête
`Authorization: Bearer <jwt>` quand le cookie est absent. Les deux
mécanismes coexistent, aucun n'est retiré.
- `apps/web` : `ApiClient` gagne une abstraction `TokenStore`
(`get`/`set`/`clear`) ; l'implémentation par défaut est un no-op
navigateur (le cookie fait tout). `_request` ajoute l'en-tête
`Authorization` quand un jeton existe ; `login`/`signup` le stockent,
`logout`/`deleteAccount` l'effacent. `setTokenStore` est le point
d'injection de la version Capacitor (`@capacitor/preferences`), branchée
en phase 2 quand la dépendance sera ajoutée.
Tests Mocha : `requireAuth` authentifie via l'en-tête `Authorization` sans
cookie, rejette un jeton Bearer invalide ou un schéma non-Bearer ;
`login`/`signup` exposent bien le jeton dans le corps.
Refs #39
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Le job `test` de la run #101 a lu un état de base incohérent pendant que
le `seedReferenceData` d'une run `main` concurrente (run #100, restée
bloquée) tournait encore — décalage de +5 sur les ids `tech_step`. Le code
de cette branche est inchangé et vérifié localement (9/9 Mocha, sans DB).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
6e adaptateur, le plus simple des scrapés : `fetchDetail`/`parse`
délèguent tels quels à `jsonLdRecipeAdapter` — une page recette porte un
`Recipe` WP Recipe Maker dans un `@graph` Yoast, déjà géré nativement par
`findRecipeNode`. `list()` : recherche WordPress `GET /?s={query}&paged={N}`
— **même URL que la requête soit vide (tout le catalogue) ou non**, aucun
branchement (contrairement à `750g.ts`). Scrape de cartes
`<div class="entry-thumb"><a href="/<slug>/"><img alt src>` — image dans
`src` (pas de lazy-load `data-src` ici), `href` relatif résolu contre
l'origine. Une page au-delà de la dernière renvoie une vraie 404 → fin de
liste propre (comme `marmiton.ts`). `rekeySourceError` dupliqué localement.
Enregistré dans `registerAllRecipeSources()`.
Tests : `ohmonbento.test.ts` (`stubFetchHtml`, pas de base) — scrape des
cartes, 404 = fin de liste, URL `/?s=` identique pour requête vide, query
+ page dans `/?s={q}&paged={n}`, erreurs re-labellisées `ohMonBento`,
`parse` sur un `@graph` Yoast + WPRM (`recipeYield` en tableau géré).
Vérifié localement, 9/9. + `sources-index.test.ts` couvre
l'enregistrement.
Docs : section `ohmonbento.ts` dans `backend-architecture.md`.
Closes#40
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
5e adaptateur, calqué sur `marmiton.ts` (le plus fin des wrappers
scrapés) : `fetchDetail`/`parse` délèguent tels quels à
`jsonLdRecipeAdapter` — une page recette quitoque.fr porte un `Recipe`
schema.org, seul élément d'un tableau JSON-LD de premier niveau, déjà géré
nativement par `findRecipeNode`. Seul `list()` est spécifique :
`GET /recettes?page=N` (page 1 implicite si curseur absent), scrape des
cartes `<a class="card__content_header" href="/recettes/…">` (image réelle
dans `data-src`, `src` n'étant qu'un placeholder lazy-load ; `href`
relatif résolu contre l'origine). Extraction agnostique à l'ordre des
attributs.
Pas de vraie recherche serveur sur le site → `query` est un filtre
sous-chaîne « best effort » sur les titres de la page courante (même
lacune assumée que `750g.ts`). Fin de liste = page sans aucune carte
(comme `marmiton.ts`). `rekeySourceError` dupliqué localement (750g /
manger-bouger en ont chacun une copie).
Enregistré dans `registerAllRecipeSources()`.
Tests : `quitoque.test.ts` (`stubFetchHtml`, pas de base) — scrape des
cartes, pagination `?page=N`, filtre par query, fin de liste, erreurs
re-labellisées `quitoque`, `parse` sur un JSON-LD tableau-de-premier-
niveau. Vérifié localement, 9/9. + `sources-index.test.ts` couvre
l'enregistrement.
Docs : section `quitoque.ts` dans `backend-architecture.md` (+ correction
de la ligne « n'enregistre que TheMealDB », devenue fausse).
Closes#37
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
