Tetardtek-Cortex/brain-template
1
0
Fork 0
Code Pull Requests Activity
Files
878886cd51dea462923ab031f70a08658031cc94
brain-template/agents/reviews/Super-OAuth/pm2-v1.md
Tetardtek 878886cd51 feat: brain-template v2.0 — BSI-v3 complet + tiers documentés 
- README reécrit : tiers free/pro/full + modèle clé API + multi-instance
- Sync agents/ (57 agents, kernel-isolation validated)
- Sync scripts/ BSI-v3 (file-lock, preflight, human-gate, brain-status)
- KERNEL.md v0.7.0 — zones + délégation + rendering + isolation
- brain-compose.yml v0.7.0 — rendering mode + kerneluser
- workflows/ — template + brain-engine exemple
- locks/.gitkeep + claims/.gitkeep
- helloWorld : RAG boot tier full only (bsi-rag retiré du template)
2026-03-16 23:26:38 +01:00

4.4 KiB
Raw Blame History

Review agent : pm2 — v1

⚠️ Ce fichier concerne la QUALITÉ DE L'AGENT, pas les tests du code applicatif. Tests code → voir projet/src/__tests__/ et Jest/Vitest.

Contexte de la review

Info Valeur
Agent reviewé pm2
Version v1
Date 2026-03-13
Projet testé Super-OAuth
Cas soumis Configurer ecosystem.config.js + déploiement prod (reload 0-downtime + startup + save)

Output brut de l'agent

L'agent a fourni (depuis pm2.md au démarrage) :

  • Un ecosystem.config.js template avec instances: 1, exec_mode non spécifié (fork par défaut)
  • Un pattern CI/CD avec pm2 reload super-oauth présenté comme "0 downtime"
  • La commande npm ci --omit=dev dans le deploy pattern CI/CD

Adapté pour Super-OAuth en session :

  • ecosystem.config.js créé avec instances: 2, exec_mode: 'cluster' (correction de l'agent)
  • ci.yml patché : pm2 reload super-oauth --update-env remplace le TODO
  • env_production (au lieu de env) pour distinguer les environnements

Évaluation

✅ Ce qui a bien fonctionné

  • Chemin VPS correct (/home/tetardtek/github/Super-OAuth) — ancré dans les sources
  • watch: false documenté avec le pourquoi
  • max_memory_restart adapté au VPS Tetardtek
  • autorestart: true inclus sans qu'on le demande
  • Distinction pm2 reload vs pm2 restart mentionnée
  • Commande pm2 startup + pm2 save correctement séquencée

❌ Ce qui manquait ou était incorrect

  1. 0-downtime mensonger en mode fork — L'agent dit "reload = 0 downtime" mais c'est faux avec instances: 1 et fork mode. Un reload en fork = arrêt puis redémarrage = downtime. Le vrai 0-downtime nécessite exec_mode: 'cluster' + instances >= 2.

  2. env vs env_production — Le template utilise env au lieu de env_production. La bonne pratique pm2 est d'utiliser des blocs nommés (env_production, env_staging) et de démarrer avec --env production. Avec env, les variables s'appliquent à tous les environnements.

  3. Duplication des variables d'env — Le template met PORT: 3000 dans l'ecosystem config. Si le .env contient déjà PORT, c'est une source de désynchronisation silencieuse. L'agent ne prévient pas de ce risque.

  4. npm ci vs npm ci --omit=dev — Le deploy pattern CI/CD de l'agent utilise --omit=dev, mais le vrai ci.yml Super-OAuth fait juste npm ci. L'agent devrait aligner sur la réalité du projet ou expliciter le trade-off (taille node_modules en prod).

  5. Pas de --update-env sur pm2 reload — Sans ce flag, pm2 ne recharge pas les variables d'environnement au reload. Critique si le .env a changé entre deux déploiements.

  6. Premier déploiement vs reload — L'agent mentionne le cas mais sans la commande de détection. Comment savoir si pm2 connaît déjà le process ? Il manque la pattern de guard : pm2 list | grep super-oauth || pm2 start ecosystem.config.js --env production.

⚠️ Anti-hallucination respectée ?

  • A dit "Information manquante" quand nécessaire
  • N'a pas inventé de commandes/chemins/métriques
  • Niveau de confiance explicite si incertain — absent sur la question "reload = 0 downtime" qui est présentée comme un fait alors que c'est conditionnel

📐 Périmètre respecté ?

  • N'a pas débordé sur d'autres domaines
  • A bien délégué ce qui ne le concernait pas (Apache, CI/CD complet)

Gaps identifiés → à corriger dans l'agent

Gap Correction proposée Priorité
instances: 1 + fork présenté comme 0-downtime Documenter explicitement que 0-downtime = cluster mode + instances >= 2. Mettre à jour le template. haute
env au lieu de env_production Changer le template — utiliser env_production + noter pm2 start --env production haute
Pas de --update-env sur reload Ajouter pm2 reload <name> --update-env partout où reload est mentionné haute
Duplication PORT dans ecosystem Avertir : ne mettre que NODE_ENV dans env_production, les secrets viennent du .env moyenne
Guard premier déploiement Ajouter pattern de détection : pm2 list | grep <name> || pm2 start ... moyenne
npm ci --omit=dev vs npm ci Aligner sur réalité projet ou documenter le trade-off explicitement basse

Action

  • Gaps reportés dans agents/pm2.md changelog
  • Recruiter invoqué pour améliorer l'agent
  • v2 planifiée
View Git Blame Copy Permalink