Infrastructure/eqs-platform

Fork 0

Le rétrofit n'a pas de guide : le clone neuf a 405 lignes et 14 étapes vérifiables, l'existant a une commande et deux décisions #93

New issue

Closed

opened 2026-09-30 15:13:20 +00:00 by nicolas-fryder · 3 comments

nicolas-fryder commented

2026-09-30 15:13:20 +00:00

Owner

L'asymétrie

Deux chemins mènent au socle. Un seul est écrit.

	clone neuf	rétrofit d'un existant
Guide	`docs/initialiser-un-satellite.md` — 405 lignes, 14 étapes, chacune avec son critère de vérification	—
Commande	`/eqs-init`	`eqs migrate inspect` / `eqs migrate plan`
Où se trouve le retour d'expérience	`ETAT.md`, `reference/chasses.md`	dans le dépôt rétrofitté : `EQS/ATLAS`, `docs/retrofit-eqs.md`

D-003 pose pourtant les deux chemins à égalité — « le template est pour les dépôts neufs, les packages sont pour tout le monde » — et la ROADMAP #15 fait du rétrofit d'ATLAS un objectif de premier rang. D-048 va jusqu'à nommer « docs/ du rétrofit » dans sa colonne de conséquences (reference/decisions.md). Ce docs/ n'existe pas.

Ce que ça coûte, mesuré

Le rétrofit de nuage commence aujourd'hui. C'est le second après ATLAS, et il a dû reconstituer à la main :

l'ordre des étages, en relisant la ROADMAP et les dépendances entre packages ;
le mécanisme des baselines, en lisant D-048 dans reference/decisions.md — pas dans un guide ;
la façon de déclarer les tâches de porte supplémentaires, en lisant D-049 ;
les peerDependencies de chaque package, en ouvrant les dix package.json, pour découvrir que l'adoption exige Node ≥ 22.18, vitest ≥ 3, TypeScript ≥ 5.9, knip ≥ 6, class-validator ^0.15.1 et @nestjs/swagger ^12 — c'est-à-dire un étage 0 entier qui n'est annoncé nulle part ;
et le fait même que eqs migrate existe, découvert dans le cahier de @eqs/cli et dans #79.

Chacun de ces points a été trouvé. Aucun ne l'a été là où on le cherchait.

Le retour d'expérience d'ATLAS est réel et détaillé, mais il vit dans ATLAS. C'est contraire à D-021 (« le cadre de tests et la doctrine ne sont pas copiés : ils ont un seul exemplaire, dans eqs-platform ») appliqué au rétrofit : la procédure d'adoption est une propriété du socle, pas de chaque dépôt qui l'adopte. Le troisième rétrofit (photofront, metalfrom) repartira de zéro une troisième fois.

Ce que je proposerais

Un docs/retrofitter-un-existant.md, symétrique d'initialiser-un-satellite.md — même forme, une étape, un critère de vérification — qui dise au minimum :

L'étage 0 qu'on ne voit pas venir : le tableau des peerDependencies du socle, versus ce qu'un dépôt de deux ans porte. C'est la marche la plus haute et elle est avant la première.
L'ordre des étages et pourquoi : la porte et la mesure avant le code applicatif, pour que chaque étage suivant se juge sur un contrôle qui change de couleur.
Les deux baselines de D-048, avec le geste exact (--suppress-all, le second tsconfig.json, l'interdiction de --pass-on-unpruned-suppressions).
eqs.check.taches de D-049 : ce qu'un existant fait de ses gates maison — ils s'ajoutent.
Ce qu'on garde parce que c'est au-dessus du standard (doctrine §3) : un rétrofit n'est pas un nivellement.
Le point d'entrée : eqs migrate inspect d'abord, toujours.

Et, si la commande /eqs-migrate évoquée dans #79 existe quelque part, la référencer — elle n'est pas dans .claude/commands/ de ce dépôt, qui ne porte que eqs-init.md.

Lien avec #85

#85 demandait le mécanisme de baseline, et D-048 l'a tranché. Ce ticket demande autre chose : que la procédure soit écrite quelque part où on la cherche. Les deux sont voisins et ne se remplacent pas — D-048 existe et reste introuvable pour qui ne lit pas reference/decisions.md ligne à ligne.

Contexte

Rétrofit de nuage (EQS-Sandbox/NUAGE, branche retrofit-socle-eqs), profil nest, @eqs/* 0.13.0. Conception dans docs/superpowers/specs/2026-09-30-retrofit-socle-eqs-design.md. Je tiendrai le journal de ce rétrofit dans le dépôt, comme ATLAS — et c'est précisément ce qui fait le doublon que ce ticket voudrait éviter au suivant.

## L'asymétrie Deux chemins mènent au socle. Un seul est écrit. | | clone neuf | rétrofit d'un existant | | --- | --- | --- | | Guide | `docs/initialiser-un-satellite.md` — **405 lignes, 14 étapes, chacune avec son critère de vérification** | — | | Commande | `/eqs-init` | `eqs migrate inspect` / `eqs migrate plan` | | Où se trouve le retour d'expérience | `ETAT.md`, `reference/chasses.md` | dans le dépôt rétrofitté : `EQS/ATLAS`, `docs/retrofit-eqs.md` | D-003 pose pourtant les deux chemins à égalité — « le template est pour les dépôts neufs, **les packages sont pour tout le monde** » — et la ROADMAP #15 fait du rétrofit d'ATLAS un objectif de premier rang. D-048 va jusqu'à nommer « `docs/` du rétrofit » dans sa colonne de conséquences (`reference/decisions.md`). Ce `docs/` n'existe pas. ## Ce que ça coûte, mesuré Le rétrofit de `nuage` commence aujourd'hui. C'est le **second** après ATLAS, et il a dû reconstituer à la main : - l'ordre des étages, en relisant la ROADMAP et les dépendances entre packages ; - le mécanisme des baselines, en lisant D-048 dans `reference/decisions.md` — pas dans un guide ; - la façon de déclarer les tâches de porte supplémentaires, en lisant D-049 ; - les `peerDependencies` de chaque package, en ouvrant les dix `package.json`, pour découvrir que l'adoption exige Node ≥ 22.18, vitest ≥ 3, TypeScript ≥ 5.9, knip ≥ 6, `class-validator` ^0.15.1 et `@nestjs/swagger` ^12 — c'est-à-dire un étage 0 entier qui n'est annoncé nulle part ; - et le fait même que `eqs migrate` existe, découvert dans le cahier de `@eqs/cli` et dans #79. Chacun de ces points a été trouvé. Aucun ne l'a été là où on le cherchait. Le retour d'expérience d'ATLAS est réel et détaillé, mais il vit **dans ATLAS**. C'est contraire à D-021 (« le cadre de tests et la doctrine ne sont pas copiés : ils ont un seul exemplaire, dans `eqs-platform` ») appliqué au rétrofit : la procédure d'adoption est une propriété du socle, pas de chaque dépôt qui l'adopte. Le troisième rétrofit (photofront, metalfrom) repartira de zéro une troisième fois. ## Ce que je proposerais Un `docs/retrofitter-un-existant.md`, symétrique d'`initialiser-un-satellite.md` — même forme, une étape, un critère de vérification — qui dise au minimum : 1. **L'étage 0 qu'on ne voit pas venir** : le tableau des `peerDependencies` du socle, versus ce qu'un dépôt de deux ans porte. C'est la marche la plus haute et elle est avant la première. 2. **L'ordre des étages et pourquoi** : la porte et la mesure avant le code applicatif, pour que chaque étage suivant se juge sur un contrôle qui change de couleur. 3. **Les deux baselines de D-048**, avec le geste exact (`--suppress-all`, le second `tsconfig.json`, l'interdiction de `--pass-on-unpruned-suppressions`). 4. **`eqs.check.taches` de D-049** : ce qu'un existant fait de ses gates maison — ils s'ajoutent. 5. **Ce qu'on garde parce que c'est au-dessus du standard** (doctrine §3) : un rétrofit n'est pas un nivellement. 6. **Le point d'entrée** : `eqs migrate inspect` d'abord, toujours. Et, si la commande `/eqs-migrate` évoquée dans #79 existe quelque part, la référencer — elle n'est pas dans `.claude/commands/` de ce dépôt, qui ne porte que `eqs-init.md`. ## Lien avec #85 #85 demandait le **mécanisme** de baseline, et D-048 l'a tranché. Ce ticket demande autre chose : que la procédure soit **écrite quelque part où on la cherche**. Les deux sont voisins et ne se remplacent pas — D-048 existe et reste introuvable pour qui ne lit pas `reference/decisions.md` ligne à ligne. ## Contexte Rétrofit de `nuage` (`EQS-Sandbox/NUAGE`, branche `retrofit-socle-eqs`), profil `nest`, `@eqs/*` 0.13.0. Conception dans `docs/superpowers/specs/2026-09-30-retrofit-socle-eqs-design.md`. Je tiendrai le journal de ce rétrofit dans le dépôt, comme ATLAS — et c'est précisément ce qui fait le doublon que ce ticket voudrait éviter au suivant.

nicolas-fryder added the

enhancement

label

2026-09-30 15:13:20 +00:00

nicolas-fryder commented

2026-09-30 15:15:08 +00:00

Author

Owner

Correction : j'ai écrit « le troisième rétrofit (photofront, metalfrom) ». metalfrom n'est pas un dépôt de la flotte — son origine est git.nicolasfryder.ovh/nico/metalfrom.eu, une autre forge, un compte personnel. Je l'avais repris de la liste de docs/profils.md, qui est justement fausse sur ce point (#92).

Lire donc : le troisième rétrofit — EQS/LUMIX, et ce qui suivra dans l'organisation — repartira de zéro une troisième fois.

La règle qui m'a manqué et qui vaut d'être écrite quelque part : l'origine git dit si un dépôt est de la flotte. Un nom dans une liste ne le dit pas.

Correction : j'ai écrit « le troisième rétrofit (photofront, metalfrom) ». `metalfrom` n'est **pas** un dépôt de la flotte — son origine est `git.nicolasfryder.ovh/nico/metalfrom.eu`, une autre forge, un compte personnel. Je l'avais repris de la liste de `docs/profils.md`, qui est justement fausse sur ce point (#92). Lire donc : le troisième rétrofit — `EQS/LUMIX`, et ce qui suivra dans l'organisation — repartira de zéro une troisième fois. La règle qui m'a manqué et qui vaut d'être écrite quelque part : **l'origine git dit si un dépôt est de la flotte.** Un nom dans une liste ne le dit pas.

nicolas-fryder referenced this issue

2026-09-30 15:23:50 +00:00

0.13.0 est taguée mais pas publiée : les mécanismes de rétrofit sont injoignables par les dépôts pour qui ils ont été écrits #94

nicolas-fryder referenced this issue from a commit

2026-09-30 16:00:43 +00:00

Quatre registres mentaient sur les mêmes dépôts, et le rétrofit n'avait pas de guide

nicolas-fryder referenced this issue

2026-09-30 16:03:59 +00:00

Trois tickets du retrofit de nuage, et une porte d'audit qui dormait #95

nicolas-fryder referenced this issue

2026-09-30 16:04:52 +00:00

0.13.0 est taguée mais pas publiée : les mécanismes de rétrofit sont injoignables par les dépôts pour qui ils ont été écrits #94

nicolas-fryder referenced this issue

2026-09-30 16:05:17 +00:00

docs/profils.md : la liste des dépôts du profil next-fullstack a trois entrées fausses sur quatre #92

nicolas-fryder commented

2026-09-30 16:05:48 +00:00

Author

Owner

Écrit : docs/retrofitter-un-existant.md, par 84d4dcc (PR #95). Fermeture à la fusion.

Le symétrique d'initialiser-un-satellite.md — même forme, une étape, un critère de vérification. Les six points demandés y sont, et voici ce qu'ils ont donné en les mesurant plutôt qu'en les recopiant.

1. L'étage 0, relevé sur les dix `package.json`

Le tableau complet des peerDependencies du socle, avec ce qui l'exige et quand. Deux pièges que la lecture rapide manque :

@nestjs/swagger a deux planchers. @eqs/errors accepte >=11, @eqs/platform-nest exige ^12.0.1. Un profil nest est donc en ^12 — lire la ligne d'errors seule fait croire à 11.
zod est en ^4.5.4, pas ^3. C'est la migration la plus coûteuse de l'étage 0 pour un dépôt qui valide beaucoup, et la seule qui n'a rien à voir avec le socle : elle se fait avant.

Le guide donne aussi la commande pour re-mesurer le tableau à chaque version, plutôt que de le laisser se périmer — c'est exactement la faute de #92, et il aurait été malvenu de la refaire dans le document qui la raconte.

2 à 6

L'ordre des étages et son inflexion propre au rétrofit : la porte et la mesure avant le code applicatif, pour que chaque étage suivant se juge sur un contrôle qui change de couleur.
Les deux baselines de D-048, avec le geste exact : le second tsconfig.json daté et chiffré (exemple complet dans le guide), --suppress-all une seule fois, --prune-suppressions après correction, et l'interdiction de --pass-on-unpruned-suppressions — avec la raison, qui est que le cliquet devient un seuil.
eqs.check.taches de D-049, et ses deux silences par dessein : une tâche dont l'outil manque se retire en le disant (requiert), un manifeste mal déclaré ne lève pas. Conséquence que le guide écrit noir sur blanc : il faut vérifier que ses tâches tournent, parce que « ma tâche passe » et « ma tâche n'a pas tourné » affichent le même vert.
Ce qu'on garde (doctrine §3), et le cas limite : un mécanisme meilleur que celui du socle se garde avec une dispense datée, pas un contournement silencieux. L'exemple est fetchAmont d'ATLAS contre D-025.
eqs migrate inspect d'abord, toujours — et le critère qui tranche le profil : les route handlers, pas la présence de Next.

Sur la commande /eqs-migrate : elle n'existe pas. .claude/commands/ ne porte que eqs-init.md, votre constat est exact. Le guide s'appuie sur eqs migrate inspect et eqs migrate plan, qui existent bien (packages/cli/src/bin/eqs.ts).

Trouvé en l'écrivant, et qui aggrave le ticket

Le retour d'expérience d'ATLAS existe — docs/retrofit-eqs.md, 583 lignes : l'ordre des étages, six arbitrages tranchés et datés, et six risques du socle repérés avant d'écrire une ligne. Mais il est sur une branche locale epic/retrofit qui n'est pas poussée (26 commits d'avance, 144 de retard sur main) :

$ git ls-remote --heads origin
…/heads/feat/compagnon-ia
…/heads/main

Ce n'est donc pas seulement « le retour d'expérience vit dans ATLAS » : seul le poste qui l'a écrit peut le lire. Le guide en reprend ce qui est vrai de tout rétrofit, et le dit dans un encadré — ce qui est propre au dépôt reste chez lui, ce qui est vrai de tout rétrofit remonte dans eqs-platform (D-021).

Rien n'a été touché dans ATLAS : le dépôt est un autre chantier. Sortir cette branche mérite son propre passage.

Ce que je n'ai pas vérifié

Le guide n'a pas été déroulé de bout en bout par quelqu'un qui le suit. Il est tiré d'un rétrofit fait, pas d'un rétrofit refait en le lisant. Le rétrofit de nuage est le premier à pouvoir le démentir — et c'est ce qu'on lui demande : ce qui manque, ce qui est faux, ce qui est dans le mauvais ordre revient ici en ticket.

Référencé depuis AGENTS.md, à côté du chemin du clone neuf, avec la mention que les deux sont à égalité (D-003).

Écrit : `docs/retrofitter-un-existant.md`, par `84d4dcc` (PR #95). Fermeture à la fusion. Le symétrique d'`initialiser-un-satellite.md` — même forme, une étape, un critère de vérification. Les six points demandés y sont, et voici ce qu'ils ont donné en les mesurant plutôt qu'en les recopiant. ## 1. L'étage 0, relevé sur les dix `package.json` Le tableau complet des `peerDependencies` du socle, avec ce qui l'exige et quand. Deux pièges que la lecture rapide manque : - **`@nestjs/swagger` a deux planchers.** `@eqs/errors` accepte `>=11`, `@eqs/platform-nest` exige `^12.0.1`. Un profil `nest` est donc en `^12` — lire la ligne d'`errors` seule fait croire à 11. - **`zod` est en `^4.5.4`, pas `^3`.** C'est la migration la plus coûteuse de l'étage 0 pour un dépôt qui valide beaucoup, et la seule qui n'a rien à voir avec le socle : elle se fait avant. Le guide donne aussi la commande pour re-mesurer le tableau à chaque version, plutôt que de le laisser se périmer — c'est exactement la faute de #92, et il aurait été malvenu de la refaire dans le document qui la raconte. ## 2 à 6 - **L'ordre des étages** et son inflexion propre au rétrofit : la porte et la mesure avant le code applicatif, pour que chaque étage suivant se juge sur un contrôle qui change de couleur. - **Les deux baselines de D-048**, avec le geste exact : le second `tsconfig.json` daté et chiffré (exemple complet dans le guide), `--suppress-all` une seule fois, `--prune-suppressions` après correction, et l'interdiction de `--pass-on-unpruned-suppressions` — avec la raison, qui est que le cliquet devient un seuil. - **`eqs.check.taches` de D-049**, et ses **deux silences par dessein** : une tâche dont l'outil manque se retire en le disant (`requiert`), un manifeste mal déclaré ne lève pas. Conséquence que le guide écrit noir sur blanc : il faut **vérifier** que ses tâches tournent, parce que « ma tâche passe » et « ma tâche n'a pas tourné » affichent le même vert. - **Ce qu'on garde** (doctrine §3), et le cas limite : un mécanisme **meilleur** que celui du socle se garde avec une **dispense datée**, pas un contournement silencieux. L'exemple est `fetchAmont` d'ATLAS contre D-025. - **`eqs migrate inspect` d'abord, toujours** — et le critère qui tranche le profil : les route handlers, pas la présence de Next. Sur la commande `/eqs-migrate` : elle n'existe pas. `.claude/commands/` ne porte que `eqs-init.md`, votre constat est exact. Le guide s'appuie sur `eqs migrate inspect` et `eqs migrate plan`, qui existent bien (`packages/cli/src/bin/eqs.ts`). ## Trouvé en l'écrivant, et qui aggrave le ticket Le retour d'expérience d'ATLAS **existe** — `docs/retrofit-eqs.md`, 583 lignes : l'ordre des étages, six arbitrages tranchés et datés, et six risques du socle repérés *avant* d'écrire une ligne. Mais il est sur une branche locale **`epic/retrofit` qui n'est pas poussée** (26 commits d'avance, 144 de retard sur `main`) : ``` $ git ls-remote --heads origin …/heads/feat/compagnon-ia …/heads/main ``` Ce n'est donc pas seulement « le retour d'expérience vit dans ATLAS » : **seul le poste qui l'a écrit peut le lire.** Le guide en reprend ce qui est vrai de tout rétrofit, et le dit dans un encadré — ce qui est propre au dépôt reste chez lui, ce qui est vrai de tout rétrofit remonte dans `eqs-platform` (D-021). Rien n'a été touché dans ATLAS : le dépôt est un autre chantier. Sortir cette branche mérite son propre passage. ## Ce que je n'ai pas vérifié **Le guide n'a pas été déroulé de bout en bout par quelqu'un qui le suit.** Il est tiré d'un rétrofit fait, pas d'un rétrofit refait en le lisant. Le rétrofit de `nuage` est le premier à pouvoir le démentir — et c'est ce qu'on lui demande : ce qui manque, ce qui est faux, ce qui est dans le mauvais ordre revient ici en ticket. Référencé depuis `AGENTS.md`, à côté du chemin du clone neuf, avec la mention que les deux sont à égalité (D-003).

nicolas-fryder closed this issue

2026-09-30 16:08:21 +00:00

nicolas-fryder commented

2026-09-30 19:35:54 +00:00

Author

Owner

Deux pièges de plus pour le guide, trouvés en finissant les étages 0 à 2 de nuage. Les deux coûtent une demi-heure à qui ne les connaît pas, et cinq lignes à qui les a écrites.

1. `ERR_PNPM_TARBALL_URL_MISMATCH` au `docker build` — et le message accuse le verrou

[ERR_PNPM_TARBALL_URL_MISMATCH] 7 lockfile entries failed verification:
  @eqs/auth@0.14.0 could not be verified against the registry's published metadata
  …
The lockfile contains entries that the active policies reject. This can mean the
lockfile is stale, or that someone committed a lockfile that bypassed the policy
locally — inspect recent changes to pnpm-lock.yaml before trusting it.

On va donc inspecter pnpm-lock.yaml. Les URL y sont identiques au caractère près à ce que le registre annonce :

$ grep -A1 "'@eqs/tooling@0.14.0'" pnpm-lock.yaml
  tarball: https://git.equilibre-structures.fr/api/packages/Infrastructure/npm/%40eqs%2Ftooling/-/0.14.0/tooling-0.14.0.tgz
$ pnpm view @eqs/tooling@0.14.0 dist.tarball
https://git.equilibre-structures.fr/api/packages/Infrastructure/npm/%40eqs%2Ftooling/-/0.14.0/tooling-0.14.0.tgz

La vraie cause tient en une mesure :

$ curl -s -o /dev/null -w '%{http_code}\n' \
    'https://git.equilibre-structures.fr/api/packages/Infrastructure/npm/@eqs%2Ftooling'
401

Le registre exige une authentification même pour lire les métadonnées. Sans jeton, pnpm ne peut pas vérifier le verrou — et c'est CE refus qu'il rapporte comme une incohérence de verrou. Le message envoie chercher au mauvais endroit, et il y envoie avec insistance.

Il fallait deux choses, et n'en faire qu'une ne change rien au message :

copier .npmrc dans l'image (sans quoi le conteneur cherche @eqs/* sur npmjs.org) ;
monter le jeton en secret le temps du pnpm install.

Le gabarit fait bien les deux — COPY … .npmrc ./ puis --mount=type=secret,id=npmrc — mais nulle part il n'est dit que l'un sans l'autre produit ce message-là. Un rétrofit ne copie pas le Dockerfile du gabarit : il modifie le sien, et il ajoute ce qu'il croit manquer, un morceau à la fois.

Ce que le guide gagnerait à dire, à l'étape des images : « le registre répond 401 même sur les métadonnées ; si docker build parle d'un verrou incohérent, c'est le jeton qui manque, pas le verrou ». Et, pour la pile de développement, que le secret se déclare dans le compose (secrets: npmrc: file: ${HOME}/.npmrc) pour que stack:up continue de marcher sans commande à retenir.

2. `protobufjs` — le gabarit l'a écrit, un rétrofit ne le lit pas

pnpm install sort en 1 et écrit littéralement protobufjs: set this to true or false dans le pnpm-workspace.yaml du dépôt. La décision de la flotte existe, commentée en quinze lignes dans le gabarit et dans eqs-demo — mais un rétrofit n'ouvre pas le pnpm-workspace.yaml du gabarit, il ouvre le sien.

C'est exactement le cas que ce ticket décrit : la connaissance existe, elle est même bien écrite, et elle est là où seul un clone la trouve. Une ligne dans le guide (« les scripts d'installation à approuver, et la décision de la flotte pour chacun ») éviterait de la retrancher à chaque fois.

Contexte : EQS-Sandbox/NUAGE, branche retrofit-socle-eqs, étages 0 à 2 terminés, @eqs/* 0.14.0. Le journal est dans docs/RETROFIT.md — et je le tiens là faute d'un endroit commun, ce qui est le doublon même que ce ticket voudrait éviter au suivant.

Deux pièges de plus pour le guide, trouvés en finissant les étages 0 à 2 de `nuage`. Les deux coûtent une demi-heure à qui ne les connaît pas, et cinq lignes à qui les a écrites. ## 1. `ERR_PNPM_TARBALL_URL_MISMATCH` au `docker build` — et le message accuse le verrou ``` [ERR_PNPM_TARBALL_URL_MISMATCH] 7 lockfile entries failed verification: @eqs/auth@0.14.0 could not be verified against the registry's published metadata … The lockfile contains entries that the active policies reject. This can mean the lockfile is stale, or that someone committed a lockfile that bypassed the policy locally — inspect recent changes to pnpm-lock.yaml before trusting it. ``` On va donc inspecter `pnpm-lock.yaml`. Les URL y sont **identiques au caractère près** à ce que le registre annonce : ``` $ grep -A1 "'@eqs/tooling@0.14.0'" pnpm-lock.yaml tarball: https://git.equilibre-structures.fr/api/packages/Infrastructure/npm/%40eqs%2Ftooling/-/0.14.0/tooling-0.14.0.tgz $ pnpm view @eqs/tooling@0.14.0 dist.tarball https://git.equilibre-structures.fr/api/packages/Infrastructure/npm/%40eqs%2Ftooling/-/0.14.0/tooling-0.14.0.tgz ``` La vraie cause tient en une mesure : ``` $ curl -s -o /dev/null -w '%{http_code}\n' \ 'https://git.equilibre-structures.fr/api/packages/Infrastructure/npm/@eqs%2Ftooling' 401 ``` **Le registre exige une authentification même pour lire les métadonnées.** Sans jeton, pnpm ne peut pas vérifier le verrou — et c'est CE refus qu'il rapporte comme une incohérence de verrou. Le message envoie chercher au mauvais endroit, et il y envoie avec insistance. Il fallait **deux** choses, et n'en faire qu'une ne change rien au message : - **copier `.npmrc` dans l'image** (sans quoi le conteneur cherche `@eqs/*` sur npmjs.org) ; - **monter le jeton en secret** le temps du `pnpm install`. Le gabarit fait bien les deux — `COPY … .npmrc ./` puis `--mount=type=secret,id=npmrc` — mais **nulle part il n'est dit que l'un sans l'autre produit ce message-là**. Un rétrofit ne copie pas le Dockerfile du gabarit : il modifie le sien, et il ajoute ce qu'il croit manquer, un morceau à la fois. Ce que le guide gagnerait à dire, à l'étape des images : « le registre répond 401 même sur les métadonnées ; si `docker build` parle d'un verrou incohérent, c'est le jeton qui manque, pas le verrou ». Et, pour la pile de développement, que le secret se déclare dans le compose (`secrets: npmrc: file: ${HOME}/.npmrc`) pour que `stack:up` continue de marcher sans commande à retenir. ## 2. `protobufjs` — le gabarit l'a écrit, un rétrofit ne le lit pas `pnpm install` sort en 1 et écrit **littéralement** `protobufjs: set this to true or false` dans le `pnpm-workspace.yaml` du dépôt. La décision de la flotte existe, commentée en quinze lignes dans le gabarit et dans `eqs-demo` — mais un rétrofit n'ouvre pas le `pnpm-workspace.yaml` du gabarit, il ouvre le sien. C'est exactement le cas que ce ticket décrit : la connaissance existe, elle est même bien écrite, et elle est **là où seul un clone la trouve**. Une ligne dans le guide (« les scripts d'installation à approuver, et la décision de la flotte pour chacun ») éviterait de la retrancher à chaque fois. --- Contexte : `EQS-Sandbox/NUAGE`, branche `retrofit-socle-eqs`, étages 0 à 2 terminés, `@eqs/*` 0.14.0. Le journal est dans `docs/RETROFIT.md` — et je le tiens là faute d'un endroit commun, ce qui est le doublon même que ce ticket voudrait éviter au suivant.