eqs-satellite-template

Le dépôt cloné pour chaque satellite neuf. Aucune logique métier : la structure, la configuration, le câblage des agents, et rien qui ne soit importé.

Pour l'utiliser, dérouler eqs-platform/docs/initialiser-un-satellite.md — quatorze étapes, chacune avec son critère de vérification. La commande /eqs-init le déroule ; elle vit dans eqs-platform (.claude/commands/), pas ici.

Où ce dépôt et le guide divergent (au 2026-10-15)

Le guide vit dans un autre dépôt et prend du retard sur celui-ci. Là où ils se contredisent, ce qui suit est vrai pour ce gabarit :

• Étape 5 — le lockfile. Le guide dit que le gabarit n'en a pas : il en a un, committé (voir « État » plus bas). pnpm install le reprend ; il ne se committe que s'il a changé.
• Étape 6 — le refus sans DATABASE_URL. env -u DATABASE_URL pnpm --filter api start ne prouve rien : start recharge ../../.env, qui remet la variable, et l'application démarre sans jamais rendre la main. La commande qui prouve le refus est DATABASE_URL= pnpm --filter api start (après pnpm --filter api build) : une valeur posée gagne sur le fichier, une valeur vide compte comme absente, et la sortie est 1 en nommant DATABASE_URL. Vérifié dans les deux sens.
• Étapes 2 et 11 — les hooks. Ils sont committés exécutables (100755), et pnpm check le vérifie (tâche hooks). Un git init + git add -A fait sous Windows peut les réenregistrer en 100644 : la tâche le dit, avec la commande qui répare.
• Étape 13 — une ou deux adresses. Le guide décrit deux domaines (le défaut). variantes/une-adresse en donne un seul, sur un proxy ; elle se choisit à l'étape 2, comme next-fullstack.

Ce qu'un clone contient

apps/api	NestJS. main.ts tient en trois lignes : createEqsApp(optionsApp()). Une route ping d'exemple, qui se supprime
apps/web	Next, profil front : session, frontière d'erreur, CSP par nonce, télémétrie navigateur
apps/api/test/integration/conformite.test.ts	Le fichier de test unique : les contrôles de tous les @eqs/* installés, contre l'application démarrée sur une base jetable
apps/api/prisma/migrations/0_initial	Les cinq tables de @eqs/auth et la table d'exemple. Générée, mais committée : une migration est un historique
.githooks	pre-commit (gitleaks, mise en forme, eqs audit) et pre-push (pnpm check + gitleaks). La porte bloquante, en 100755 : la tâche hooks de pnpm check refuse un hook que git ignorerait
.forgejo/workflows	Trente lignes qui appellent eqs-workflows@v1. La CI constate ; elle ne bloque pas (D-013)
.claude	Deux garde-fous exécutables : refus d'écrire un fichier généré, tsc après chaque écriture. Et trois commandes
eqs-baseline.json	Les dispenses livrées avec le template. Un clone en a besoin dès son premier commit ; l'audit s'y ajoute à l'étape 10
docker-compose.yml	La pile de développement. Coolify lit docker-compose.coolify.yml, jamais celle-ci
Dockerfile	Gabarit à deux cibles, api et web. Node épinglé sur une version exacte
.npmrc	Dit où est le scope @eqs. Aucun secret : le jeton de lecture est dans le ~/.npmrc de la personne (D-033)
openapi.json	Le contrat, dérivé du code par eqs openapi export. Committé : --check compare, et le Dockerfile le copie dans l'image
orval.config.mjs, apps/web/generated/	Le client typé de notre API, produit par pnpm client depuis le contrat. Committé : un clone compile sans rien générer
variantes/next-fullstack	Ce qu'on pose à la place d'apps/api pour le profil next-fullstack. Hors du workspace : voir son README.md
variantes/une-adresse	Facultatif : l'API et le front derrière une seule adresse (proxy Caddy par chemin, front en même origine). Le défaut reste deux domaines : voir son README.md

Ce qui n'est pas dedans, et pourquoi

• Des scripts copiés : eqs check, eqs doctor, eqs audit, eqs e2e remplacent les scripts locaux que six dépôts avaient copiés. scripts/ ne porte que ce qui est propre au gabarit : le lanceur e2e, et verifier-hooks.mjs, que pnpm check joue en tâche déclarée (eqs.check.taches du package.json).
• Pas de packages/, et ce n'est pas une étape à franchir : un satellite ne produit pas de package publiable. S'il faut en produire un, il vit dans son PROPRE dépôt, versionné et publié pour lui-même (D-041). Enfoui ici, il n'aurait ni cible de construction, ni étape de publication, ni version qui lui soit propre.
• Le cadre de tests et la doctrine ne sont pas copiés : ils ont un seul exemplaire, dans eqs-platform (D-021).
• Un tsconfig.json à la racine : il n'y a rien à y compiler. Chaque application a le sien, et eqs check produit une tâche de types par projet.

État — ce qui a été joué, et ce qui ne l'a pas été

Ce template a été monté et exécuté le 2026-09-07, hors dépôt, branché sur les packages du socle. La chaîne complète a tourné :

Étape	Résultat
pnpm install, pnpm --filter api build	vert
pnpm check	3,9 s pour un critère à 30 s
eqs openapi export	5 opérations, toutes en ressource.action
eqs openapi export --check	code 0
eqs doctor	zéro écart, code 0
eqs audit	1 avis, couvert par sa dispense datée, code 0
suite de conformité, vraie base, vraies migrations	12 cas verts, aucun conteneur survivant
git commit par le vrai hook	passe, sans --no-verify

Vingt et un défauts en sont sortis — dix ici, onze dans les packages. Deux ont été trouvés par le socle lui-même : la règle « horloge injectée » et le contrôle testing.unit-sans-io.

Puis construit pour de vrai le même jour, sur un registre npm local (verdaccio en conteneur, les dix packages publiés dedans en vrais tarballs) : les liens locaux résolvaient tout depuis le node_modules du socle et masquaient, par construction, tout ce qui suit.

Étape	Résultat
pnpm install depuis un registre	vert, 10 s, sortie 0
pnpm check	10,5 s pour un budget de 60 s
next build	vert
docker build, cibles api et web	verts
image api sur un vrai PostgreSQL	migrations appliquées, /health 200 avec latence, /version avec SHA, 401 et 404 enveloppés
image web	200, CSP à nonce, X-Frame-Options, Referrer-Policy, Permissions-Policy
suite de conformité, depuis le registre	12 cas verts

Onze défauts de plus, dont sept ici : le .npmrc absent (404 sur npmjs.org), protobufjs sans décision écrite (pnpm install sortait en 1), middleware.ts que Next 16 ne sait plus lire, apiBaseUrl appelé depuis un composant serveur, apps/web/public absent du dépôt mais copié par le Dockerfile, prisma.config.ts absent de l'image — l'api démarrait sur une base vide sans le dire, puis mourait sur public.user does not exist — et l'estampille absente des étages finaux : /version rendait commit: "inconnu", ce que le contrôle platform.version refuse contre un service déployé.

Ce qui a été joué depuis, et ce qui ne l'a pas été.

Vérifié le 2026-10-15 contre @eqs/* 0.23.0 — les lignes qui disent « joué le … » gardent leur date : elles n'ont pas été rejouées. Une section « état » sans date ni version se périme en silence, et un avertissement faux coûte plus cher qu'aucun avertissement : on finit par re-vérifier les vingt affirmations justes à cause des trois qui ne le sont plus (ticket #9).

pnpm install depuis le vrai registre	joué. Les dix packages sont publiés, latest en 0.23.0.
Le pnpm-lock.yaml	il est ici, committé. Il fige des empreintes de tarballs, donc une version précise du socle ; c'est voulu, et la CI comme le Dockerfile l'exigent (--frozen-lockfile). Un clone part donc sur la version que ce gabarit a éprouvée, pas sur celle du jour.
Un déploiement Coolify réel	joué le 2026-09-09, 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é.
Le service visible dans SigNoz	non. Le bac à sable collecte dans un fichier, parce qu’un fichier se sonde et qu’un tableau de bord ne se sonde pas.
La variante next-fullstack	docker build et déploiement Coolify joués — par eqs-demo, qui EST un satellite de ce profil. La variante de ce dépôt, elle, n’a pas été redéployée depuis ; posée sur un clone en 0.23.0, pnpm check et l’intégration sont verts.
La tâche knip de pnpm check	jouée : knip est une dépendance de développement, la tâche tourne avec les autres.

Ce que le profil nest n’a pas encore montré : une image d’API raisonnable. Elle pèse 1,4 Go, la cause est nommée dans le Dockerfile — un pair facultatif de better-auth tire Next dans la clôture de l’API — et elle n’est pas corrigée.