Infrastructure/eqs-satellite-template
Template
4
0
Fork 0
Code Issues 1 Pull requests Projects Releases Packages Wiki Activity Actions

La section « État » du README décrit une version antérieure du socle : trois affirmations fausses sur un clone neuf #9

New issue
Closed
opened 2026-09-09 15:25:01 +00:00 by nicolas-fryder · 1 comment
nicolas-fryder commented 2026-09-09 15:25:01 +00:00
Owner
Copy link

Constaté le 2026-09-09 sur le premier satellite réel monté depuis le template (commit initial du clone a8a7917). @eqs/* 0.7.0, eqs --version 0.7.0, pnpm 11.8.0.

Le README du template est le premier document qu'on lit en montant un satellite. Sa section « État — ce qui a été joué, et ce qui ne l'a pas été » est en retard sur la réalité, sur trois points. Chacun pris isolément est mineur ; ensemble, ils font douter du reste du document, qui est par ailleurs excellent.

1. Le lockfile

Le README affirme :

Le pnpm-lock.yaml n'est donc pas ici, et n'a pas à y être — il fige des empreintes de tarballs. Il se crée au premier pnpm install d'un vrai clone

Or pnpm-lock.yaml est présent dans le template, au commit initial. Vérifié dans le clone :

git log --oneline --all -- pnpm-lock.yaml
# a8a7917 Initial commit

Et pnpm install sur un clone neuf ne l'a pas modifié (git diff vide).

2. La version du socle

Le même paragraphe donne comme non joué :

Un pnpm install depuis le vrai registre de l'organisation : la 0.3.0 n'y est pas encore publiée.

Les packages installés sont en 0.7.0, et l'installation depuis le vrai registre fonctionne :

pnpm install
# Progress: resolved 477, reused 471, downloaded 0, added 477, done
# Done in 16.2s using pnpm v11.8.0 — sortie 0

eqs --version rend 0.7.0. Le point 1 de « ce qui n'a toujours pas été joué » est donc joué, et le numéro de version cité n'existe plus.

3. packages/

packages/ est vide et le reste tant qu'un même code ne sert pas aux deux applications.

Cette phrase raisonne à deux applications et à du code partagé en interne. Elle ne dit rien du cas où un satellite produit un package destiné à sortir, ni du cas d'une troisième application — les deux se présentent dès le premier projet réel. Voir le ticket sur le Dockerfile, dont c'est la cause profonde.

Ce que ça coûte

Désagréable, non bloquant — mais coûteux en confiance. On monte un satellite en suivant ce document ; découvrir qu'il décrit un état antérieur amène à re-vérifier chacune de ses affirmations, y compris les vingt qui sont justes.

Ce que je proposerais

Dater la section « État » et la rattacher à une version du socle (« vérifié le AAAA-MM-JJ contre @eqs/* 0.7.0 »), pour qu'un lecteur sache tout de suite si elle est fraîche. Et retirer les points désormais joués plutôt que de les laisser en avertissement : un avertissement faux est pire qu'aucun.

Constaté le 2026-09-09 sur le premier satellite réel monté depuis le template (commit initial du clone `a8a7917`). `@eqs/*` 0.7.0, `eqs --version` 0.7.0, pnpm 11.8.0. Le `README` du template est le premier document qu'on lit en montant un satellite. Sa section « État — ce qui a été joué, et ce qui ne l'a pas été » est en retard sur la réalité, sur trois points. Chacun pris isolément est mineur ; ensemble, ils font douter du reste du document, qui est par ailleurs excellent. ## 1. Le lockfile Le `README` affirme : > Le `pnpm-lock.yaml` n'est donc pas ici, et n'a pas à y être — il fige des empreintes de tarballs. Il se crée au premier `pnpm install` d'un vrai clone Or `pnpm-lock.yaml` **est présent dans le template**, au commit initial. Vérifié dans le clone : ```bash git log --oneline --all -- pnpm-lock.yaml # a8a7917 Initial commit ``` Et `pnpm install` sur un clone neuf ne l'a pas modifié (`git diff` vide). ## 2. La version du socle Le même paragraphe donne comme non joué : > Un `pnpm install` depuis le **vrai** registre de l'organisation : la 0.3.0 n'y est pas encore publiée. Les packages installés sont en **0.7.0**, et l'installation depuis le vrai registre fonctionne : ``` pnpm install # Progress: resolved 477, reused 471, downloaded 0, added 477, done # Done in 16.2s using pnpm v11.8.0 — sortie 0 ``` `eqs --version` rend `0.7.0`. Le point 1 de « ce qui n'a toujours pas été joué » est donc joué, et le numéro de version cité n'existe plus. ## 3. `packages/` > `packages/` est vide et le reste tant qu'un même code ne sert pas aux deux applications. Cette phrase raisonne à **deux** applications et à du code partagé en interne. Elle ne dit rien du cas où un satellite **produit** un package destiné à sortir, ni du cas d'une troisième application — les deux se présentent dès le premier projet réel. Voir le ticket sur le `Dockerfile`, dont c'est la cause profonde. ## Ce que ça coûte Désagréable, non bloquant — mais **coûteux en confiance**. On monte un satellite en suivant ce document ; découvrir qu'il décrit un état antérieur amène à re-vérifier chacune de ses affirmations, y compris les vingt qui sont justes. ## Ce que je proposerais Dater la section « État » et la rattacher à une version du socle (« vérifié le AAAA-MM-JJ contre `@eqs/*` 0.7.0 »), pour qu'un lecteur sache tout de suite si elle est fraîche. Et retirer les points désormais joués plutôt que de les laisser en avertissement : un avertissement faux est pire qu'aucun.
nicolas-fryder commented 2026-09-09 16:06:32 +00:00
Author
Owner
Copy link

Confirmé sur les trois points, et il y en avait deux de plus.

Vérifications :

  1. Le lockfile. git ls-files pnpm-lock.yaml le rend : il est bien suivi. Le paragraphe qui affirme le contraire est faux depuis qu'il a été committé.
  2. La version. latest du registre est en 0.7.0, et pnpm install depuis le vrai registre fonctionne. La 0.3.0 citée n'existe plus.
  3. packages/. Traité séparément — voir #7 et la réponse ci-dessous.

Les deux que vous n'aviez pas relevés, dans la même liste de « ce qui n'a pas été joué » :

  • « Un déploiement Coolify réel » — joué le 2026-09-09, en profil nest, sur le bac à sable de eqs-demo : les deux services construits par Coolify, sains, chacun sur son domaine, base gérée par Coolify, HTTPS, télémétrie reçue, /version au commit déployé.
  • « docker build sur la variante next-fullstack et son déploiement » — joués aussi, par eqs-demo, qui est un satellite de ce profil.

La section est réécrite, datée et rattachée à une version comme vous le proposiez : « Vérifié le 2026-09-09 contre @eqs/* 0.7.0 ». C'était le bon geste — sans date ni version, une section « état » se périme en silence, et personne ne sait si elle est fraîche.

Votre argument sur le coût est celui qui a emporté la décision de tout reprendre plutôt que de rectifier les trois lignes : « on finit par re-vérifier chacune de ses affirmations, y compris les vingt qui sont justes ». Un avertissement faux coûte effectivement plus cher qu'aucun avertissement.

Une précision au passage, parce que le README l'expliquait mal : le lockfile doit être là, et c'est voulu. Il fige des empreintes de tarballs, donc une version précise du socle — un clone part sur la version que ce gabarit a éprouvée, pas sur celle du jour. Le texte disait l'inverse et il avait tort.

Corrigé dans fix/tickets-du-premier-satellite, fusionné.

Confirmé sur les trois points, et il y en avait deux de plus. Vérifications : 1. **Le lockfile.** `git ls-files pnpm-lock.yaml` le rend : il est bien suivi. Le paragraphe qui affirme le contraire est faux depuis qu'il a été committé. 2. **La version.** `latest` du registre est en **0.7.0**, et `pnpm install` depuis le vrai registre fonctionne. La 0.3.0 citée n'existe plus. 3. **`packages/`.** Traité séparément — voir #7 et la réponse ci-dessous. Les deux que vous n'aviez pas relevés, dans la même liste de « ce qui n'a pas été joué » : - **« Un déploiement Coolify réel »** — joué le 2026-09-09, en profil `nest`, sur le bac à sable de `eqs-demo` : les deux services construits par Coolify, sains, chacun sur son domaine, base gérée par Coolify, HTTPS, télémétrie reçue, `/version` au commit déployé. - **« `docker build` sur la variante `next-fullstack` et son déploiement »** — joués aussi, par `eqs-demo`, qui *est* un satellite de ce profil. La section est réécrite, **datée et rattachée à une version** comme vous le proposiez : « Vérifié le 2026-09-09 contre `@eqs/*` 0.7.0 ». C'était le bon geste — sans date ni version, une section « état » se périme en silence, et personne ne sait si elle est fraîche. Votre argument sur le coût est celui qui a emporté la décision de tout reprendre plutôt que de rectifier les trois lignes : *« on finit par re-vérifier chacune de ses affirmations, y compris les vingt qui sont justes »*. Un avertissement faux coûte effectivement plus cher qu'aucun avertissement. Une précision au passage, parce que le README l'expliquait mal : le lockfile **doit** être là, et c'est voulu. Il fige des empreintes de tarballs, donc une version précise du socle — un clone part sur la version que ce gabarit a éprouvée, pas sur celle du jour. Le texte disait l'inverse et il avait tort. Corrigé dans `fix/tickets-du-premier-satellite`, fusionné.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
dev
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Infrastructure/eqs-satellite-template#9
No description provided.