Aussi en: English, Español, Português, 日本語, Deutsch, 한국어, 简体中文, Italiano, हिन्दी · Tous les guides en français
Transparence : nous développons Carbon Forge, et AEGIS à côté, chez 100monkeys.ai ; lisez donc ceci comme le récit du fabricant. Ce guide a été rédigé par l'un de nos agents d'IA à partir de la documentation publique (en anglais), principalement l'étape 8 de Working in lanes, Source control settings, MCP tools catalog: Lanes, continued et Source control: how it is built and why, et relu par l'entreprise ; cette version française est une traduction du guide original en anglais. Le tableau, les appels et le refus sont ceux de la documentation. Là où la documentation laisse une question ouverte, la dernière section le dit.
Pourquoi garder la règle dans le registre
La documentation donne la raison en deux phrases : "Landing rules are the code-owners rule kept in the record. The approvers a path needs are named on a page of the workspace, and each approval binds to the lane's composition hash, so review is the record's and not a forge's." (Les règles d'intégration sont la règle des code owners gardée dans le registre. Les approbateurs dont un chemin a besoin sont nommés sur une page de l'espace de travail, et chaque approbation se lie au hash de composition de la lane : la relecture appartient au registre, pas à une forge.) Sans cela, "a landing can carry code no approver saw." (une intégration peut apporter du code qu'aucun approbateur n'a vu.) Une limite d'emblée : "Carbon runs no review itself." (Carbon ne fait lui-même aucune relecture.) Il enregistre qui a approuvé quoi ; la relecture est faite par des personnes et par les workflows que vous nommez.
Étape 1. Protéger le trunk
Les règles ne sont lues que sur un trunk protégé. Un administrateur de l'espace de travail coche Protect the trunk sous Settings, Workspace, Source control, et en option Protect pages and atoms too. Un agent vérifie le réglage avec :
workspaces.get_settings {}
→ { "workspaceId": "…", "trunkProtected": true, "trunkProtectedEntities": false }Dès lors "the trunk moves only by a lane's landing" (le trunk ne bouge que par l'intégration d'une lane), et une écriture directe est refusée avec workspace <slug> protects its trunk: the trunk lands by lanes.land only; write on a lane.
Étape 2. Écrire la page .landing-rules
Créez une page au chemin réservé .landing-rules dont le premier tableau Markdown a pour en-tête glob | approvers | gate. L'exemple de la documentation :
| glob | approvers | gate |
| --- | --- | --- |
| app/src/billing/** | <user id>, <user id> | |
| docs/** | <user id> | docs-review |glob: une règle dans la syntaxe des règles d'exclusion d'import, ne commençant pas par!.approvers: des identifiants d'utilisateur séparés par des virgules, chacun membre de l'espace de travail. Le champ peut être vide sur une ligne qui nomme une porte.gate: facultatif, le nom d'un workflow AEGIS, 128 caractères au plus. "Carbon never runs it." (Carbon ne l'exécute jamais.)
Seul un administrateur de l'espace de travail écrit cette page, sur le trunk ou sur une lane ; toute autre personne est refusée avec The landing rules page .landing-rules is reserved: only a workspace admin writes it.
Étape 3. Vérifier que le serveur la lit comme valide
La section Landing rules de la boîte de dialogue des réglages affiche <n> rules, valid., ou nomme une ligne mal formée avec Every landing is refused until it is fixed. Une ligne qui nomme un non-membre, ou qui ne nomme ni approbateur ni porte, est mal formée. Une page cassée arrête toute intégration : vérifiez donc ceci avant de vous y fier.
Étape 4. Faire le travail sur une lane
Ouvrez une lane et écrivez dessus comme le montre Working in lanes. À l'intégration, chaque chemin que la lane touche est confronté à chaque ligne : une page par son chemin, une page déplacée par ses deux chemins, un fichier d'arbre sous la forme <tree path>/<entry path>.
Étape 5. Lire ce qui manque encore à la lane
lanes.create { "label": "agent/7/fix-login" }
lanes.get { "label": "agent/7/fix-login" }
lanes.export { "lane": "agent/7/fix-login" } // header line: # composition: <hash>
lanes.approve { "lane": "agent/7/fix-login" }lanes.get liste qui a approuvé, qui manque, et si chaque porte est pending ou satisfied. Dans l'application, la vue d'ensemble d'une lane montre la même chose : les règles qu'elle touche, n approbations sur m, et une approbation venue d'une porte marquée "via gate <workflow>".
Étape 6. Approuver le changement exact
Un relecteur lit lanes.export, un unique diff unifié dont l'en-tête est # composition: <hash>, puis appelle lanes.approve. L'approbation se lie à ce hash, si bien que "a reviewer who reads the export and approves at its # composition: value has approved exactly that change." (un relecteur qui lit l'export et approuve à sa valeur # composition: a approuvé exactement ce changement.) Tout patch, résolution ou mouvement du trunk ultérieur qui change ce qui serait intégré change le hash, et les approbations antérieures ne comptent alors plus. Approuvez après le dernier changement, pas avant.
Étape 7. Laisser le workflow AEGIS approuver comme porte
Une porte n'est satisfaite que par le workflow lui-même. Le token de l'exécution est émis par tokens.mint_execution avec l'argument facultatif workflow réglé sur le nom de la porte, de 1 à 128 caractères ; l'exécution appelle ensuite lanes.approve avec ce token. La correspondance est exacte, "case included" (casse comprise). "A person's approval, and one given through a token minted without workflow, satisfies no gate." (L'approbation d'une personne, et celle donnée par un token émis sans workflow, ne satisfont aucune porte.) Le token d'exécution est un enfant du token de l'appelant, limité à un espace de travail, un chemin d'arbre, une lane, une liste d'outils et une journée au plus. Avec AEGIS by 100monkeys.ai, in beta, la porte est un workflow que vous écrivez vous-même : la ligne le nomme, et Carbon Forge vérifie seulement qu'une de ses exécutions a approuvé.
Étape 8. Intégrer
lanes.land { "label": "agent/7/fix-login", "intent": "fix: accept magic links", "dry_run": true }
lanes.land { "label": "agent/7/fix-login", "intent": "fix: accept magic links" }Une intégration à qui il manque des approbations est refusée en bloc, en nommant ce qui manque :
Lane <label> touches <path> under landing rule <glob> (line <n>), which needs approval from <user ids> and gate <name> at the lane's current composition. Approve with lanes.approve; nothing was written.Quand elle s'intègre, les approbations consommées, y compris celle de la porte, "follow its intent as Approved-by: lines" (suivent son intention sous forme de lignes Approved-by:), et le changeset est scellé comme n'importe quel autre. Notez qu'une intégration en dry_run ne vérifie pas les règles ; lisez lanes.get pour cela.
Ce que la documentation laisse sans réponse
- Le côté AEGIS. La documentation dit que "the execution service" (le service d'exécution) émet le token de l'exécution avec
workflow, mais ne montre pas de workflow AEGIS qui détienne un tel token et appellelanes.approve. - Les approbateurs sont uniquement des identifiants d'utilisateur. Il n'y a ni groupes ni équipes, et la conception indique "No per-directory permissions" (pas de permissions par répertoire).
- Si une approbation donnée par un token d'exécution compte aussi pour l'utilisateur du token quand celui-ci figure parmi les approbateurs.