fix(recipes): corrige la numérotation des étapes faussée par le popover de correction #31
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/step-counter-scoped-to-direct-children"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Contexte
Bug rapporté : "les étapes affichées sont numérotées n'importe comment".
Cause
.recipe-detail-panel__stepsnumérote ses étapes via un compteur CSS (counter-reset/counter-increment: step) appliqué à un sélecteurli— un descendant, pas seulement les enfants directs. Depuis la refonte du popover de correction (#30), celui-ci imbrique ses propres<li>plusieurs niveaux plus bas dans le DOM d'une étape :.tech-step-correction-popover__row).catalog-search-picker__list, jusqu'à ~74 entrées)Chacun de ces
<li>incrémentait le même compteurstep, faussant le numéro affiché de toutes les étapes suivantes dès qu'une correction avec métadonnées attachées (ou son picker de technique) était ouverte.Correctif
li/img/p→> li/> img/> p(enfants directs uniquement) dans cette règle. Même raisonnement pourimg/p: leurs styles (image en bloc, paragraphe inline sans marge) ne doivent s'appliquer qu'au propre<p>/<img>de l'étape, pas à ceux imbriqués plus loin dans le popover.Tests
Nouveau test de non-régression dans
recipes.cy.ts: ouvre une correction avec ingrédient + ustensile attachés puis le picker de technique, vérifie viagetComputedStyleque ces<li>imbriqués n'ont pas rejoint la chaîne du compteur (counter-increment: none) alors que les<li>des étapes elles-mêmes l'ont toujours (counter-increment: step 1). Confirmé que ce test échoue bien sans le correctif (step 1au lieu denone) avant de le restaurer — pas un test qui passerait de toute façon.pnpm lint+pnpm --filter web buildclean.recipes.cy.ts9/9 (dont le nouveau test),recipes.feature5/5,recipe-sources.feature6/6.🤖 Generated with Claude Code
Le step Gherkin partagé « the recipe should include the ingredient » utilisait un `.should("be.visible")` nu sur `.ingredient-row__name`. Sur le formulaire d'édition de recette, la liste d'ingrédients peut se trouver sous le pli du scroll propre à `.app-content` (Nom/Description/ Photo/Portions/Visibilité/Régimes viennent avant) — un `.should` seul ne scrolle pas automatiquement, contrairement aux commandes d'interaction (`.click()`/`.check()`). Repéré comme bug pré-existant et hors périmètre lors de la vérification de #29/#30 (voir la note dans tech-step-metadata-editor-redesign.md). Même correctif que « I should see the highlighted technique » (common.steps.ts) et « I should see the highlighted temperature » (recipes.ts) : `.scrollIntoView()` avant l'assertion. Reproduit avant correctif (recipe-form.feature, scénario « Preloads an existing recipe's ingredients when editing »: 4/5 puis 5/5 après le correctif). Suite e2e complète: 27/28 fichiers verts (la seule exception, admin-monitoring.cy.ts, est un flake distinct et sans rapport, signalé séparément). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>`admin-monitoring.cy.ts` échouait de façon reproductible ("renders one card per service": cy.wait timeout, "No request ever occurred"). Diagnostiqué par isolation : le matcher déclaratif `resourceType: "fetch"` de Cypress 13.17.0 ne capte plus du tout la requête réelle de AdminApiClient.getMonitoring() sur le Chrome 152 de cette machine — un intercept `{resourceType: "fetch"}` sans filtre d'URL ne voit passer que /admin/auth/me, jamais /admin/monitoring, alors que le `req.resourceType` de cette même requête, lu depuis un handler matché par url/method seuls, vaut bien "fetch" de façon fiable et reproductible. Le filtrage déclaratif est cassé, pas la requête elle-même. Remplace le matcher par un handler de fonction qui laisse passer la requête de document (`cy.visit()` lui-même, sur la même URL que l'API en same-origin/CI) via `req.continue()` et ne stub que le reste — vérifié stable sur 3 runs consécutifs. Corrige au passage le test "shows an error state" qui passait pour la mauvaise raison : sans serveur API réel, une requête non interceptée échoue aussi au niveau réseau, ce que MonitoringPage.catch() ne distingue pas d'un vrai 500 — désormais aliasé et attendu comme le premier test, pour prouver qu'il dépend bien du mock. Suite e2e complète: 28/28 fichiers, 116/116 tests verts. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>