Le Manager et Build

Le Manager est le chat situé à côté du tableau. Il voit le brief du projet, les loops, le Task Book et les dernières passes, ce qui vous permet de lui poser des questions sur le tableau et de planifier avec lui.

Les quatre modes

Un mode détermine ce que le Manager a le droit de modifier. La conversation reste dans un mode jusqu’à ce que vous le changiez ; le Manager ne change jamais de mode de lui-même.

Mode	Lit vos fichiers	Peut modifier
Ask	Oui, lorsqu’un dossier est lié	PROJECT.md uniquement
Plan	Oui, lorsqu’un dossier est lié	Les cartes du Task Book, après votre accord, et PROJECT.md
Code	Oui	Les fichiers dans le dossier d’un loop, et PROJECT.md
Build	Non	Propose un tableau, appliqué uniquement lorsque vous appuyez sur Build it, et PROJECT.md

• Ask répond aux questions sur le projet et le tableau.
• Plan transforme une conversation en cartes. Il demande avant de les écrire.
• Code modifie directement les fichiers, dans la limite du dossier d’un loop. Si ce loop exécute une passe dans le même dossier, le tour de Code attend qu’elle se termine.
• Build conçoit des loops. Voir ci-dessous.

Questions

Lorsqu’un point compte, le Manager pose une question. Une question s’accompagne de deux à six options, dont au plus une est marquée comme recommandée, et d’une zone de texte libre. Rien n’est pré-sélectionné. Une question laissée sans réponse compte comme « aucune préférence ».

Guidage et modification

Vous pouvez taper du texte pendant que le Manager travaille. Le message est lu à sa prochaine étape, comme un guidage, au lieu d’attendre la fin du tour. Modifier un message précédent crée une bifurcation dans la conversation ; l’autre version est conservée.

PROJECT.md, le brief du projet

Le brief d’un tableau est le fichier PROJECT.md situé à la racine du projet. Tant qu’il n’est pas rédigé, l’onglet Tasks affiche Pas encore de PROJECT.md. Il vous appartient : il réside dans le projet, et non dans le dossier propre de l’application, et il est destiné à être validé par commit. Chaque passe de chaque bubble le lit en premier.

Il comporte deux sections connues de l’application :

• Rules : la manière dont le projet doit être construit. Le Manager ne modifie ceci que sur votre demande.
• Current state : l’état d’avancement du projet.

Si vous demandez que le projet soit deployable, le Manager ajoute une ligne Deployable sous Rules. À partir de ce moment-là, les bubbles maintiennent la compilation de production valide et une configuration de déploiement à côté. Vous pouvez désactiver cette option depuis le panneau du brief.

Build

Build configure un tableau pour vous en deux étapes :

1. Il lit ce qu’il connaît (le brief, le Task Book, la conversation), propose une structure en termes simples et demande si elle est correcte.
2. Une fois que vous êtes d’accord, il propose les loops : les bubbles dans chacun d’eux, un prompt pour chaque bubble, le dossier dans lequel chaque loop peut écrire, et les Sub-loops que chaque loop accroche à ses Subloop bubbles.

La proposition s’intitule Build this board ?, et ce qui s’affiche à côté du bouton Build it correspond exactement à ce que Build va faire. Build n’écrit aucun code ni aucune carte par lui-même, seulement PROJECT.md. Appuyer sur Build it :

• demande d’abord le dossier du tableau, si un loop proposé écrit du code et qu’aucun n’est lié ;
• lorsqu’un dossier proposé appartient déjà à un loop, affiche Rien n’a été construit. Un dossier est déjà pris. et propose Edit the existing loop ou Replace & build ;
• demande confirmation avant de remplacer un prompt d’équipe que vous avez rédigé à la main.

Un loop qui construit un élément visible par une personne reçoit un designer avant son codeur et un reviewer après lui, qui exécute la revue visuelle. Un loop sans interface ne reçoit ni l’un ni l’autre.

Un tableau vide ou un Task Book vide ne pose pas de problème : lorsqu’il y a trop peu d’informations, Build pose des questions.

Le Task Book

Le Task Book contient les cartes du tableau dans six colonnes : Draft, Approved, Implementing, Review, Done et Blocked.

• Les loops ne prennent que les travaux Approved. Draft est votre filtre.
• Les cartes que vous tapez, et les cartes qu’un bubble de planification écrit pendant une exécution, commencent dans Draft.
• Les cartes que le Manager écrit dans Plan commencent dans Approved, puisque vous avez donné votre accord dans le chat.
• Un loop qui termine une carte la déplace vers Review : construite et en attente que le vérificateur du loop (l’ architecte, ou la personne qui vérifie le travail dans ce loop) l’accepte ou la renvoie.
• Une carte en attente d’une sous-tâche la nomme, avec un bouton Stop waiting pour la laisser continuer sans elle.