Aide

Pour faire tourner Messier sur votre poste et travailler sur son code.

Prérequis : Node.js 24 ou plus, pnpm (la version 10 du packageManager du dépôt), Docker avec Compose, et git.

1. Cloner le dépôt

2. Le fichier .env

Toutes les variables commencent par MESSIER_ : .env.example les liste, avec les valeurs par défaut des ports (web 3300, API 4300, Postgres 5452, Redis 6399).

3. Les deux applications OAuth GitLab

À déclarer sur https://git.makethings.cloud (Paramètres utilisateur › Applications), puis à reporter dans le .env, avec MESSIER_GITLAB_URL=https://git.makethings.cloud :

• L’application web : confidentielle, scopes api et read_user, URI de redirection http://localhost:4300/auth/gitlab/callback en local (elle se déduit du port de l’API) ; sur une instance déployée, https://<hôte du web>/api/auth/gitlab/callback, reportée aussi dans MESSIER_GITLAB_REDIRECT_URI. Son identifiant et son secret vont dans MESSIER_GITLAB_CLIENT_ID et MESSIER_GITLAB_CLIENT_SECRET.
• L’application du CLI : publique (non confidentielle), le grant type device_code coché, scope read_user ; le formulaire demande une URI de redirection, que le device flow n’utilise pas. Son identifiant va dans MESSIER_GITLAB_CLI_CLIENT_ID, sans secret : messier login s’en sert.

4. La clé de chiffrement

MESSIER_ENCRYPTION_KEY chiffre les tokens GitLab gardés par Messier : 32 octets en hexadécimal. L’API refuse de démarrer sans elle ; la changer oblige chacun à se reconnecter.

5. Les comptes autorisés

MESSIER_ALLOWED_USERS liste les noms d’utilisateur GitLab qui peuvent se connecter, séparés par des virgules (alice,bob) ; tout autre compte est refusé.

6. Lancer la stack

Postgres et Redis tournent dans Docker, puis les dépendances, puis Messier :

pnpm dev applique les migrations, puis lance le web sur le port 3300 (http://localhost:3300), l’API sur le port 4300 (sa documentation sur http://localhost:4300/docs) et le worker de synchronisation avec GitLab.

En option

Le CLI depuis le monorepo, pour l’essayer avant sa publication : construire le paquet, puis le lier dans le dossier global des binaires de pnpm (pnpm setup une fois avant).

Chromium, une fois, pour les tests e2e du navigateur (pnpm test:e2e) :

Pour se servir de Messier depuis son poste, sans travailler sur son code : la commande messier connecte le poste, installe les skills et le serveur MCP de Messier dans Claude Code, et prépare les sessions de travail. Elle demande Node.js 24 ou plus.

1. Un token GitLab

Le paquet est publié dans le registre npm du projet GitLab rnd/messier (id 75), qui est privé : créez un token d’accès personnel avec le scope read_api (ou un deploy token du projet avec le scope read_package_registry).

2. Le registre dans ~/.npmrc

Ajoutez ces deux lignes à votre ~/.npmrc ; sans la seconde, npm reçoit une 404 :

@laboitetech:registry=https://git.makethings.cloud/api/v4/projects/75/packages/npm/
//git.makethings.cloud/api/v4/projects/75/packages/npm/:_authToken=<votre token>

npm remplace ${VARIABLE} par la variable d’environnement : _authToken=${GITLAB_NPM_TOKEN} évite d’écrire le token dans le fichier.

3. Installer

Pour mettre à jour, la même commande ; messier --version affiche la version installée.

4. Connecter le poste

messier login vous connecte à cette instance de Messier par le device flow de GitLab, une fois votre compte connecté au moins une fois sur le web. Le token obtenu va dans le trousseau du système, ou faute de trousseau (sous WSL2) dans ~/.config/messier/credentials.

5. Préparer Claude Code

messier setup vérifie d’abord les prérequis et s’arrête en listant ce qui manque : git, node, pnpm, docker, claude, glab et jq (le hook de guardrails git en a besoin). Puis il installe les skills de Messier dans ~/.claude/skills et le hook dans ~/.claude/hooks, enregistre le serveur MCP de Messier dans Claude Code et vérifie que glab est connecté au GitLab de Messier. Il se relance sans risque.

messier doctor vérifie tout ce que setup installe, et donne pour chaque échec la commande qui corrige :

Quand Messier publie une nouvelle version de ses skills, messier update les réinstalle (le CLI lui-même se met à jour par npm i -g) :

Le plus simple : lancez /messier-init dans Claude Code, à la racine d’un clone du projet. Le skill est installé par messier setup (section « Installer le binaire »).

Il vérifie d’abord le poste (messier doctor), puis diagnostique le projet en lecture seule, sans rien écrire : rattachement, manifeste, develop et ses protections, labels, CI, runners et suite de tests, rangés en trois niveaux, « Bloquant », « À adapter » et « Prêt », chaque point avec ce qui a été constaté, pourquoi Messier en a besoin et comment le corriger. Il propose ensuite ses actions une à une, chacune faite seulement après votre « oui » : rattacher le projet, créer les labels manquants, écrire le manifeste, compléter la CI, lancer les tests une fois. Il ne committe, ne pousse et ne change aucun réglage de GitLab : il finit par la liste de ce qui vous reste, les fichiers à committer sur develop et les réglages à faire dans GitLab. Relancé sur un projet installé, tout est « Prêt » et rien n’est réécrit.

Le détail, pour le faire à la main ou savoir ce que /messier-init vérifie : mener un projet GitLab avec Messier, des demandes à la recette, demande ces cinq étapes.

1. Rattacher le projet

Dans Messier, « Projets », puis « Rattacher » : cherchez le projet parmi ceux dont votre compte GitLab est membre, et rattachez-le.

2. Le manifeste .messier.yml

À la racine de la branche par défaut, il décrit le projet : name, stack, urls (les adresses à ouvrir pour vérifier), ports et commands (install, dev, test, e2e). Messier le lit dans GitLab ; messier work lance son install dans le worktree d’une session. Il est versionné : jamais de secret dedans. Celui de Messier :

name: messier
stack: [nestjs, nuxt, drizzle, postgres, redis, turborepo]
urls:
  front: http://localhost:3300
  api-doc: http://localhost:4300/docs
ports:
  web: 3300
  api: 4300
  postgres: 5452
  redis: 6399
commands:
  install: pnpm install
  dev: pnpm dev
  test: pnpm test
  e2e: pnpm test:e2e

3. Gitflow

develop est la branche par défaut du projet, main porte les versions (tags vX.Y.Z). Les agents poussent leurs branches, feature/<iid>-<slug> pour une feature et lot/<slug> pour un lot d’issues autonomes, et ouvrent leurs MR vers develop ; ils ne mergent jamais. Protégez main et develop.

4. Les labels

• feature : l’issue parente d’une feature, qui regroupe ses issues ;
• HITL (l’humain intervient) ou AFK (l’agent la mène seul) : le mode de chaque issue ;
• bug, chore et one-shot : une issue autonome, hors feature ;
• in-progress : posé sur une issue prise en charge, créé par Messier lui-même.

Le skill to-issues crée les autres quand ils manquent, au découpage d’une demande.

5. Une CI déclenchée sur les MR

La porte de test lit les pipelines des MR : une issue est « Implémentée » quand un pipeline passe sur son dernier commit, une feature « En recette » quand sa MR est prête sur un pipeline vert. La CI doit donc tourner sur les événements de MR, comme celle de Messier :

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
    - if: $CI_COMMIT_BRANCH == 'develop'
    - if: $CI_COMMIT_BRANCH == 'main'
    - if: $CI_COMMIT_TAG