fix/eprouve-sur-un-clone #1

Merged
nicolas-fryder merged 2 commits from fix/eprouve-sur-un-clone into main 2026-09-07 12:28:25 +00:00
No description provided.
Le template a été cloné hors dépôt, branché sur les packages du socle, et la
chaîne complète jouée : installation, construction, porte, contrat, audit,
doctor, suite de conformité contre une vraie base, commit par le vrai hook.
Rien de tout cela n'avait tourné.

Ce que ça a trouvé, ici :

- `prepare` sortait en 128 hors d'un dépôt git. `.dockerignore` exclut `.git` :
  le `pnpm install` du Dockerfile aurait échoué à chaque construction d'image.
- `@prisma/client` n'était pas dans `allowBuilds` : pnpm 11 refusait son script
  d'installation, et le client n'était jamais généré.
- Prisma ne trouve pas un schéma en DOSSIER sans `--schema` : trois scripts et
  le `CMD` du Dockerfile visaient un `prisma/schema.prisma` qui n'existe pas.
- `eslint.config.mjs` écrasait les `files` des profils au lieu de les préfixer.
  La règle « horloge injectée », prévue pour `**/domain/**`, s'appliquait à
  toute l'API — et refusait la route d'exemple. Une règle qu'on élargit par
  accident finit désactivée pour de mauvaises raisons.
- Prettier vérifiait `pnpm-lock.yaml`, que pnpm réécrit à sa façon : le hook le
  reformatait, pnpm le défaisait, le fichier changeait à chaque aller-retour.
- Aucun fichier de préparation n'installait `noSocketInUnit()` : l'étage
  unitaire pouvait sortir sur le réseau. C'est le contrôle du socle qui l'a vu.
- `plateforme.ts` construisait le client Prisma À L'IMPORT. Il se figeait donc
  sur l'adresse du poste, et la suite de conformité ne pouvait pas l'envoyer
  sur sa base jetable : `/health` répondait 503 pendant que tout le reste
  disait que tout allait bien. Les options deviennent une fonction — rien ne se
  construit à l'import.
- Aucune migration : `prisma migrate deploy` n'avait rien à appliquer, et les
  tables n'existaient pas au démarrage. `0_initial` est livrée, générée mais
  committée : une migration est un historique, pas un dérivé.
- Le hook pre-commit conseillait `git commit --no-verify` devant un avis de
  sécurité sans correctif. Un clone neuf ne pouvait PAS committer : Prisma tire
  `deepmerge-ts`, avis HIGH sans correctif en 6.x. Il appelle désormais
  `eqs audit`, et la dispense datée est livrée avec le template.

Mesures : `pnpm check` 3,9 s pour un critère à 30 s ; `eqs doctor` zéro écart ;
suite de conformité 12 cas verts, aucun conteneur survivant ; commit accepté.

Ce qui n'a toujours pas été joué est écrit dans le README, en tête : install
depuis le registre, `docker build`, déploiement, SigNoz, variante
next-fullstack.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Deuxième passe sur le laboratoire, avec les gestes d'un développeur qui
découvre le socle : remplir un .env, lancer l'app, appliquer les migrations,
appeler --help.

AGENTS.md dit maintenant que les packages sont NEUFS et que l'agent en est le
premier banc d'essai : tout ce qui surprend se remonte à l'utilisateur, dans la
réponse, AU MOMENT où on contourne — pas à la fin. Un --no-verify, un
eslint-disable, un `as any` sont des signalements qu'on n'a pas écrits. La
commande /eqs-signaler met le rapport en forme : commande jouée, sortie telle
quelle, ce qu'on attendait, versions, plus petit chemin de reproduction.

Les pièges trouvés en jouant ces gestes :

- PERSONNE ne chargeait `.env`. Un développeur remplissait le sien et voyait
  l'application réclamer DATABASE_URL. `dev` et `start` le chargent depuis la
  racine ET depuis l'application (`--env-file-if-exists`, natif Node 22), et
  l'étage d'intégration a sa préparation qui fait de même.
- Le CLI Prisma ne le voyait pas non plus, et exigeait `--schema` sur chaque
  commande. `prisma.config.ts` dit les deux une fois : où est le schéma
  (un DOSSIER, que Prisma ne devine pas) et où est le `.env`.
- Les migrations n'étaient JAMAIS appliquées : sans `migration_lock.toml` et
  sans `migrations.path` déclaré, Prisma répondait « No migration found » et
  sortait en succès. L'application démarrait sur une base sans tables, et
  `/health` répondait 200 — un `select 1` n'a pas besoin de tables.
- Une variable manquante sortait en trace de pile pointant dans le `dist/` du
  socle. `main.ts` attrape : le message est celui de l'application, il renvoie
  à `.env.example`, et sort en 1. La pile reste derrière DEBUG.
- `next.config.mjs` calculait la racine du workspace avec `URL.pathname`, qui
  rend `/C:/chemin` sous Windows. `fileURLToPath` — le build aurait échoué pour
  une raison qui ne parle pas de Windows.
- `prisma.config.ts` n'était pas dans le projet TypeScript : ESLint, type-aware,
  refusait de l'analyser et la porte devenait rouge pour une raison sans rapport
  avec le code.
- @eqs/http était installé et jamais montré. `main.ts` déclare l'identité du
  client — c'est toujours juste, et ça porte X-Client-Name sur chaque appel
  sortant — avec l'exemple de `defineTarget` juste à côté. Un dev qui doit
  appeler un autre service a enfin quelque chose à copier.

Vérifié après coup : `pnpm check` vert en 7,2 s ; l'application démarre sur une
vraie base, `/health` rend la latence, `/version` le SHA ; `GET /api/ping` 200,
`POST` 401 enveloppé avec requestId, route inconnue 404 enveloppée ; suite de
conformité 12 cas verts ; `eqs doctor`, `eqs audit`, `openapi --check` en 0.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
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!1
No description provided.