Workflow agent autonome Linear → Code → GitHub¶

Définition¶

Pipeline mis en place côté Data Bricks Prod (repo AI Bricks Analyst) où Linear pilote tout le cycle de dev : Romain rédige des issues métier, un agent Claude Code les traite automatiquement toutes les 15 min (cron launchd), implémente le code, ouvre les PR, merge sur preprod, et rend compte dans Linear. Aucune interaction avec GitHub n'est nécessaire pour les issues éligibles.

Doc source de référence (autoritaire, hors second cerveau) : ~/Documents/Data Bricks Prod/docs/workflow-agent-linear.md.

Pourquoi on en parle¶

Posé en place par Romain le 15/05/2026. Conséquence directe pour le second cerveau : les specs rédigées ici à destination de Linear doivent désormais être pensées pour être consommables par un agent autonome, pas seulement par un humain dev. Pas de discovery en cours de ticket, pas d'ambiguïté à arbitrer en chemin, contraintes techniques explicites.

État actuel (auto)¶

Dernière mise à jour : 2026-05-15

Architecture (résumé)¶

Trigger : statut projet Linear Ready for Agent (ou ticket isolé via /ticket BRI-XXX).
Filtre : seules les issues portant le label agent sont traitées. Les autres sont ignorées (= tâches humaines, design, etc.).
Tri : dépendances d'abord, puis priorité (Urgent → Low).
Pipeline 3 agents dans un worktree git isolé par ticket :
Planificateur (plan + auto-critique du plan)
Implémenteur (suit le plan, code sans committer)
Critique + Livraison (relit, corrige, lance tsc + test:api, commit, push, PR vers preprod, merge)
Sortie : branche feat/BRI-XXX-slug mergée sur preprod, commentaire de test posté sur l'issue, label review posé si l'issue touche UI / logique métier.
Promotion prod : Romain passe le projet en Approved → cron suivant crée les PR vers main via merge queue (squash), passe les issues en Done, nettoie les branches.

Doctrine de garde-fous (mise à jour 2026-05-15)¶

Posée après l'échange sur BRI-213 (mémo comité automatisé).

Principe : l'humain ne touche jamais au code. Toutes les actions passent par l'agent. La sécurité repose sur (a) la spec en amont, (b) la review humaine de la PR sur preprod, outillée par des checklists de review dans le ticket.

Toujours interdit (immuable)¶

Push direct sur main ou preprod (tout passe par PR).
Modifications hors du worktree isolé du ticket.
Modifications de fichiers sensibles non mentionnés dans le ticket (private/, .env*, secrets, clés API).

Interdit par défaut, autorisable sous condition dans le ticket¶

Action à risque	Condition d'autorisation ad hoc	Outil de vérification humaine
Migration DB (`drizzle:generate/push`)	Schéma cible 100% spécifié dans `Contraintes techniques` du ticket + mention explicite `Migration DB autorisée pour ce ticket`	Diff du fichier `*.sql` + diff schéma drizzle TS (revue ciblée 5 min) + test manuel des branches du status sur preprod
Ajout de dépendance npm	Lib + version + justification (vs lib déjà installée) dans le ticket	Vérif taille / dernière maj / alternatives non choisies
Refacto large (>10 fichiers hors scope direct du ticket)	Liste explicite des fichiers cible + raison dans le ticket	Diff PR section par section

Propagation côté repo cible¶

Cette doctrine n'a d'effet que si le CLAUDE.md et .claude/settings.json du repo AI Bricks Analyst reflètent les mêmes principes. À chaque évolution ici, vérifier que le repo cible est aligné — sinon l'agent va refuser des actions qu'on a autorisées (ou autoriser des actions qu'on a interdites).

Configuration Linear (référence — team Engineering Bricks)¶

Élément	Valeur
Label éligibilité	`éligible agent` (avec espace, accent, minuscules — ne pas confondre avec le label `agent` du workspace qui désigne les agents IA du pipeline d'analyse)
Label posé auto par l'agent	`review humaine` (issues UI / métier)
Statut projet "lancer"	`Ready for Agent`
Statut projet "déployer en prod"	`Approved`
Statut projet final	`Completed`
Statuts issues	`Ready for Agent` → `In Progress` → `In Review` → `Done`

Implications pour la rédaction de specs depuis le second cerveau¶

C'est l'angle qui nous intéresse ici. Quand Romain rédige depuis Bricks OS un ticket destiné à entrer dans ce pipeline, la spec doit être :

Orientée métier, pas technique — l'agent fait la traduction technique (fichiers, endpoints, etc.). Pas besoin de pré-mâcher le code.
Avec critères d'acceptation cochables (- [ ]) — c'est ce que l'agent et Romain utilisent pour valider.
Avec priorité explicite (Urgent / High / Medium / Low).
Avec dépendances explicitées (blockedBy, relatedTo) — c'est le tri de la queue de l'agent.
Avec garde-fous explicites si applicables : si la story nécessite une migration de schéma ou une nouvelle dépendance npm, c'est marqué noir sur blanc dans le ticket (sinon l'agent skip ou échoue silencieusement).
Sans ambiguïté laissée à l'agent : pas de "à discuter avec X", pas de "voir ce qui est mieux". L'arbitrage doit être fait en amont (par Romain, par une ADR, par une synchro). Le ticket reflète une décision, pas une question.

Le format de rédaction attendu est défini dans la règle .cursor/rules/specs-pour-agent.mdc.

Différence vs un ticket "humain"¶

Aspect	Ticket humain classique	Ticket éligible agent
Ambiguïté	OK, le dev pose les questions	À zéro — sinon ticket bloqué
Discovery technique	Le dev fait l'exploration	Spec déjà arbitrée
Garde-fous (schéma DB, deps)	Le dev jugera	Doivent être explicites
Critères d'acceptation	Souhaitables	Obligatoires et cochables
Label `agent`	Non	Oui (sinon ignoré)

Décisions liées¶

Aucune ADR formalisée à date dans ce repo. Le workflow est documenté hors second cerveau (doc Data Bricks Prod/docs/workflow-agent-linear.md).

Projets et areas impactés¶

areas/tech — pipeline de dev appliqué au repo AI Bricks Analyst.
areas/produit — impacte la manière dont les specs sont rédigées par le PM.

Ressources externes¶

~/Documents/Data Bricks Prod/docs/workflow-agent-linear.md — doc source autoritaire (hors second cerveau).
Règle de rédaction associée : .cursor/rules/specs-pour-agent.mdc.

Sources¶

Doc source Data Bricks Prod/docs/workflow-agent-linear.md (mise en place 15/05/2026 par Romain).