deep-update

name	deep-update
description	Mise à jour profonde d’une lib, framework ou API : recherche changelog officiel, breaking changes, puis migration clean — pas un simple npm update.
argument-hint	[cible : ex. next@15, stripe SDK, API interne v2]
disable-model-invocation	true

Deep update — mise à jour profonde

Idée

Tu veux savoir ce qui a changé depuis ta version actuelle et adapter le code proprement, pas seulement monter un numéro de version.

Document maître

Suivre docs/processus-mise-a-jour-profonde.md étape par étape.

Déroulé agent (obligatoire)

A. Cadrage

• Identifier une cible principale (X) et la version actuelle dans le repo (fichiers de config, lockfile, imports).
• Si plusieurs sujets → proposer de découper en plusieurs sessions.

B. Baseline

• Noter versions, chemins des fichiers sensibles, tests existants sur la zone.

C. Recherche profonde

• WebSearch + WebFetch sur les pages officielles : release notes, migration guide, dépréciations.
• Synthèse structurée :
  • Breaking changes pertinents pour ce repo (pas tout le changelog).
  • Fichiers à modifier (liste).
  • Ordre des opérations (types → runtime → config).

D. Plan court

• 3–10 puces : QUOI changer, POURQUOI (réf. doc), COMMENT (fichiers).

E. Exécution clean

• Modifications minimales mais complètes (pas de TODO laissés sans issue).
• Pas de contournement type any massif sans plan de retypage.

F. Examine

• tsc, tests ciblés, lint. Fail-stop : 2 échecs sur le même point → réanalyser la doc.

G. Mémoire

• Mettre à jour .claude/memory/stack.md (versions). Décision notable → decisions.md ou ADR.

Différence avec /deps

• /deps = inventaire, vulnérabilités, outdated en masse.
• /deep-update = un sujet, veille changelog approfondie, migration raisonnée.

Liens

• /apex pour structurer la session si le chantier est large.
• /scope-task si tu hésites sur les fichiers à ouvrir en premier.