Ingénierie

---

title: Ingénierie description: Comment le code de BoostEcom change : dépôts, flotte d’agents, branches, gardes et CI.

Vue d’ensemble ; la flotte, la série d’ADR et la migration ont leurs propres pages dans cet onglet.

Deux dépôts

La flotte : plusieurs agents, un dépôt

L’app est travaillée par une flotte d’agents, chacun propriétaire d’un pilier (par exemple ai-platform, billing, platform-ops, growth-web, data-platform, security-identity). La frontière est écrite pour la machine dans .claude/fleet/ownership.json (vérifiée par pnpm fleet:scope et pnpm fleet:boundaries), avec un prompt par rôle dans .claude/agents/.

Trois règles :

1. Une PR = un item = un pilier. L’item est un fichier de backlog/<pilier>/ ; la PR le met à jour, avec la documentation de son pilier.
2. Le verrou d’un item est sa branche fleet/<pilier>/<id>-<slug> sur origin.
3. Traverser un pilier demande un trailer Cross-pillar: <raison> ; toucher un fichier chaud (schéma Prisma, lockfile, configuration, src/types/**, src/config/**, AGENTS.md) demande Hot-file: <raison>.

Le Dev Studio (/ops/dev, dans l’Admin) dérive le backlog, lance une tâche par PR en brouillon et suit les coûts.

Git

• Le tronc est main ; le travail arrive par une PR en brouillon ; on ne pousse jamais sur main et on ne force jamais la branche d’un autre.
• L’IA ne fusionne pas, n’approuve pas, ne ferme pas d’issue et ne publie pas de release.
• Commits en anglais (conventional commits), code en anglais, documentation en français ; fichiers en kebab-case ; pnpm seul.

Gardes

Avant chaque push, le crochet pre-push (simple-git-hooks dans package.json) enchaîne 21 gardes rapides :

pnpm lockfile:check, pnpm db:guard:check, pnpm docs:claims, pnpm docs:links, pnpm app:links, pnpm backlog:ids, pnpm log:derive:check, pnpm fleet:derive:check, pnpm brand:derive:check, pnpm copy:dashes, pnpm copy:case, pnpm copy:cta, pnpm pages:audit, pnpm copyright:check, pnpm i18n:parity, pnpm atlas:version, pnpm shopify:version, pnpm models:check, pnpm fleet:boundaries, pnpm intel:coverage:check, pnpm db:indexes.

Les gardes lourdes (pnpm lint, pnpm typecheck, pnpm test) tournent en CI. pnpm evals appelle un vrai modèle et reste hors CI.

CI

Un workflow qui échoue en une à quatre secondes, sans runner ni étape, n’a pas démarré : lire l’annotation du check-run avant de conclure. Depuis le 2 octobre 2026, l’annotation dit que la facturation GitHub bloque les runners (platform-ops/2950) ; tant que c’est le cas, aucune PR n’a de CI, et chaque PR lance localement lint, typecheck et les tests de ce qu’elle touche, et le dit. Le build de production Vercel reste la seule porte automatique ; vercel.json décide de construire ou non par scripts/vercel-ignore-build.mjs.

Dans ce dépôt de documentation, les workflows sont épinglés sur ubuntu-24.04 et Node 22, et se mettent en pause quand la variable de dépôt CI_PAUSED vaut true.

Sources dans l’app : AGENTS.md, package.json, .claude/fleet/ownership.json, vercel.json.