Slipdock — Travail depuis le tableau

Travailler depuis slipdock

Le tableau est le plan de référence : quoi faire ensuite, et où va l'historique de ce qui s'est passé. Le serveur documente ses propres conventions — lisez-les d'abord, une fois par session, avant de choisir ou de mettre à jour quoi que ce soit :

slipdock guide                    # markdown, depuis GET /api/guide

Sans la CLI sur cette machine — ce qui est le cas habituel, car la CLI nécessite Elixir :

B="${SLIPDOCK_URL:-$(cat ~/.config/slipdock/url 2>/dev/null)}"   # demandez à l'utilisateur si aucun n'est défini
curl -s -H "Authorization: Bearer $SLIPDOCK_TOKEN" "$B/api/guide"

L'adresse du serveur provient de $SLIPDOCK_URL, sinon de ~/.config/slipdock/url (écrit par slipdock url ou par /install.sh du serveur). Si vous n'avez ni l'un ni l'autre, demandez à l'utilisateur l'adresse de son Slipdock plutôt que de deviner — un tableau hébergé est quelque chose comme https://app.slipdock.us, un auto-hébergé quel que soit le nom par lequel l'utilisateur y accède.

Passez le jeton s'il existe ($SLIPDOCK_TOKEN, sinon ~/.config/slipdock/token). Le guide n'a besoin d'aucun jeton, mais avec un, il se termine par les tableaux réels de l'utilisateur, chaque liste sur ceux-ci, et quelle liste est la liste prête, le backlog, celle pour le travail en cours et celle pour le travail terminé — exactement ce dont vous avez besoin pour choisir quelque chose.

Le guide prime sur ce fichier. Il provient du serveur en cours d'exécution, il est donc actuel : les points d'accès, les vocabulaires et la disposition du tableau qu'il contient sont générés au moment de la requête. Ce fichier vous dit seulement d'aller le chercher, et quoi faire tant que vous ne l'avez pas.

Trouver quelque chose que personne ne peut nommer

slipdock cards <board> --search Q filtre un tableau par sous-chaîne. Ses autres filtres interrogent l'état au lieu des mots, et ce sont ceux qui répondent à "que dois-je prendre ?" : --deps ready exclut tout ce qui attend une carte non terminée, --no-assignee exclut le travail des autres, --due overdue montre ce qui a glissé. La liste éligible est donc un seul appel :

slipdock cards <board> --column "To Do" --open --deps ready --no-assignee

slipdock search <words...> est différent : il correspond par sens, sur tous les tableaux que l'utilisateur peut voir, et couvre les commentaires et les mises à jour de statut ainsi que les cartes. Utilisez-le lorsque l'utilisateur décrit une chose plutôt que de la nommer ("la carte sur le problème d'arrondi de remboursement"), lorsque ce que vous cherchez a probablement été dit dans un commentaire plutôt qu'un titre, ou lorsque vous ne savez pas sur quel tableau chercher. Lisez le morceau correspondant qu'il imprime, puis slipdock card <id> pour la carte entière avant de la toucher.

La version courte qu'il développera

• Epics et sous-cartes. Une carte de premier niveau est un epic : un résultat, contenant la priorité, les dates et la discussion. Le travail vit dans ses sous-cartes, une par tâche. Les éléments de checklist sont les étapes à l'intérieur d'une tâche. Les nouvelles tâches que vous découvrez vont sous l'epic qu'elles servent, en tant que sous-carte — pas en tant que nouvelle carte de premier niveau.
• Sélection. Terminez ce qui est déjà en cours ; ensuite la liste prête (To Do), et le backlog seulement quand rien n'y est éligible. Priorité la plus élevée d'abord, position dans la liste pour départager. Ignorez tout ce qui est terminé, archivé, bloqué, en attente, reporté ou attribué à quelqu'un d'autre — --open --deps ready --no-assignee fait la plupart de ces exclusions pour vous (les cartes reportées sont déjà exclues de slipdock cards) — et tout remplaçant (↪stand-in-for:#N) : il marque seulement où une carte est allée dans un sprint. Si le tableau répond PAUSED (paused dans le JSON), une personne a mis en pause le travail : ne prenez rien et arrêtez. Lorsque la carte sur laquelle vous atterrissez a des sous-cartes, descendez dedans et travaillez-les jusqu'à terminaison avant de remonter pour la prochaine carte de premier niveau.
• Mise à jour au fur et à mesure. Déplacez la carte en cours et attribuez-la vous-même lorsque vous commencez ; commentez à chaque décision, surprise ou impasse ; marquez-la (blocked, review) avec un commentaire disant ce que vous attendez ; quand seule une personne peut donner ce dont vous avez besoin, ouvrez une attente et arrêtez (slipdock wait <id> "ce dont vous avez besoin" [--on EMAIL] [--choice X]..., ou update_card wait ; plusieurs questions vont comme --question Q --question Q / questions, une chacune, jamais un bloc) : cela marque la carte waiting, et y répondre (slipdock answer) relance le travail — ou, quand ce qui est attendu a une date, reportez-la plutôt (slipdock snooze <id> <date> --note "…") : cela laisse les listes et revient le jour dit, en haut de sa liste ; à la fin, définissez completed: true et déplacez-la dans la liste terminée. Ne terminez un epic que lorsque son récapitulatif montre chaque sous-carte terminée.
• Travail vérifié, là où le tableau l'a (sa ligne dans le guide dit verified work: …). Écrivez la barre de la carte avant de commencer (slipdock edit <id> --bar "…"), et n'essayez jamais de la changer une fois le travail commencé. Terminez-la avec ce que vous avez vérifié (slipdock done <id> --evidence-commit <sha> --tests a,b --suite passed:38:0 --evidence "…"). Sur un tableau où un deuxième agent vérifie, done soumet la carte et la laisse en attente : ne la déplacez pas vous-même dans Terminé. Une carte rejetée revient avec sa raison dans le commentaire, le prompt de la tâche et get_card's rejection (la passation dit Rework: …) : lisez d'abord cette raison, car c'est le prochain brief. Vérifier la carte de quelqu'un d'autre (jamais la vôtre) signifie extraire le commit de la preuve dans une arborescence propre, exécuter la suite (sur un tableau de pull request, vérifier que sa CI a passé à ce commit), juger par rapport à la barre, puis slipdock accept <id> ou slipdock reject <id> --reason "…". Sur un tableau qui livre par pull request (la ligne du tableau le dit, tout comme le prompt de la tâche revendiquée et slipdock card), ne poussez jamais la branche par défaut : commitez sur card-<id>, poussez-la, ouvrez la pull request une fois (gh pr create --head card-<id> --title "<titre> (#<id>)" --fill ; la tentative suivante d'une carte rejetée pousse la même branche), surveillez ses vérifications (l'exécution complète des tests : avant de pousser, exécutez seulement les tests que vous avez ajoutés ou modifiés), et terminez avec slipdock done <id> --pr <url>. Accepter la carte la fusionne ; ne la fusionnez pas vous-même. Une fusion échouée renvoie la carte rejetée avec la raison : rebasez la branche et soumettez à nouveau.
• Voies (Lanes), là où elles sont activées (la ligne du tableau dans le guide dit lanes: on). Avant de commencer une carte, écrivez les chemins que son travail touchera : slipdock edit <id> --paths "lib/foo/**,docs/manual.md", aussi étroits que le brief le permet. Un déplacement refusé pour chevauchement avec une carte en cours nomme cette carte : rétrécissez les chemins, ou laissez la carte bloquée par celle-ci ; seule une personne peut remplacer une voie. Sur un tableau push, une carte en attente de vérification libère sa voie et ses dépendants ; sur un tableau de pull request, elle la retient jusqu'à la fusion. Que le tableau ait des voies ou non, sur une carte avec des chemins, n'indexez que les fichiers sous ceux-ci, par nom, et avec une autre session active dans le même dépôt, travaillez dans un worktree git qui vous est propre (git worktree add ../<repo>-lanes/card-<id> -b card-<id>), sauf si un runner vous a déjà placé dans un ($SLIPDOCK_WORKTREE).
• Lisez d'abord la passation, laissez-en une quand vous vous arrêtez. La passation d'une carte (Left off: en haut de slipdock card <id> ; handoff dans son JSON) est l'endroit où le dernier détenteur l'a laissée : la prochaine étape unique et une courte note. Lisez-la avant les commentaires lorsque vous reprenez une carte. Chaque fois que vous vous arrêtez avec une carte non terminée — fin de session, rendue, bloquée, manque de temps — laissez-en une : slipdock handoff <id> --next "<la prochaine étape unique>" --body "État : … Pièges : … Ouvert : … Pointeurs : …" (via MCP, leave_handoff). Elle remplace la dernière ; l'historique est conservé. Les commentaires restent le journal courant ; la passation est le présent. Sur une carte terminée, la passation est pour la personne : ce qu'elle doit faire, vérifier ou savoir (un déploiement, une réinstallation, une question, une mise en garde) comme --next, avec où en sont les choses en quelques puces. Rien à lui laisser : laissez-le vide, et slipdock handoff <id> --clear une laissée plus tôt.
• Relisez la carte avant de pousser, et ses commentaires après. Une fois le travail vérifié, slipdock card <id> à nouveau : une description modifiée ou un commentaire plus récent que votre revendication est toujours cette carte — faites-le avant de commiter. Une fois la construction démarrée, lisez les commentaires une fois de plus pour tout ce qui a été ajouté entre-temps.
• Incidents et déploiements. Lorsque le tableau enregistre les déploiements (slipdock dora <board> répond plutôt que de dire que les métriques de livraison sont désactivées), une panne ou une version cassée est une carte ordinaire taguée incident ; si vous connaissez le déploiement qui l'a causée, slipdock incident-of <card> <deploy-id>. Nommez la carte dans le commit de correction (#57), comme pour toute carte : c'est ainsi que son déploiement est compté comme une correction et que la carte obtient sa ligne Expédié. N'enregistrez ni ne terminez jamais les déploiements à la main — c'est le travail de CI, avec son propre jeton.
• Les suggestions de rangement sont à la personne de décider. slipdock garden <board> (via MCP, garden) liste ce que le jardinier du tableau a trouvé : epics terminés mais ouverts, cartes bloquées en cours, doublons, pages orphelines. Montrez-les lorsque vous êtes invité à ranger, et appliquez (slipdock garden apply <id>, garden_decide) seulement ce que la personne approuve ; en travaillant sans surveillance, n'appliquez ni ne rejetez jamais une suggestion — un rejet est mémorisé.
• Les travaux de longue durée obtiennent des mises à jour intermédiaires. Si la tâche prendra plus qu'une courte session, commentez à chaque étape pendant qu'elle est encore en cours — ce qui a été livré, ce qui reste, tout ce qui a changé le plan — et déplacez percent_complete en conséquence. Un seul compte-rendu à la fin est trop tard pour être utile : une carte en cours sans rien de plus récent que le déplacement se lit comme abandonnée. Un epic qui s'étend sur plusieurs sessions reçoit le même traitement, une ligne à chaque fermeture de sous-carte.
• Les commentaires sont en Markdown, et parcourus. Commencez par une ligne en gras disant ce que c'est (**Pris.**, **Construit.**, **Décision :** …), puis de courtes puces, un fait chacune, avec les chemins, commandes et ids de commit entre backticks ; jamais un paragraphe dense de clauses. Envoyez tout ce qui dépasse une ligne avec slipdock comment <id> --body - <<'EOF' … EOF (entre guillemets, pour que les backticks survivent) ; les mots sur la ligne de commande perdent leurs sauts de ligne.
• Commitez, et liez-le. Lorsque le projet est un dépôt git, commitez le travail de la carte une fois qu'il est complet — avant de fermer la carte — avec l'id de la carte (#42) dans le message de commit. Le commentaire de clôture lie au commit, ou à la PR si une a été ouverte (Commit : https://github.com/…/commit/abc1234). Sans remote à lier, donnez le hash court et la branche à la place.
• Coût en tokens dans le compte-rendu. Le commentaire de clôture d'une carte se termine par une ligne donnant les tokens que le travail a utilisés, par ex. Coût en tokens : ~135k tokens (budget de contexte 15,00M → 14,86M, revendication à fermeture). Prenez une lecture du compteur de tokens restants (total_tokens left dans les messages système) lorsque vous revendiquez la carte et à nouveau lorsque vous la fermez, et donnez la différence. Si plusieurs cartes ont été travaillées d'une traite, mesurez chacune depuis sa propre revendication. Si aucun compteur n'est visible, dites "Coût en tokens : non mesuré" plutôt que d'estimer. Ajoutez le même chiffre au commentaire de progression de l'epic.
• Lisez d'abord leurs favoris. slipdock favourites liste les tableaux, listes, cartes et vues sauvegardées que cette personne a marqués — là où elle travaille réellement, ce qu'une liste de tableaux ne vous dit pas. Lorsque la question "sur quoi dois-je travailler ensuite ?" est posée sans nommer de tableau, un favori est l'indice le plus fort que vous ayez. Ils sont personnels : n'en ajoutez ni n'en supprimez jamais sauf demande explicite.
• Les tableaux archivés sont des travaux mis de côté. slipdock boards les exclut intentionnellement ; --all les montre avec un état archived. Tout sur l'un d'eux reste en lecture et écriture, mais ne prenez jamais de travail sur un tableau archivé sans demander, et n'y mettez jamais de nouveau travail.
• Écrivez ce que la carte ne peut pas contenir. Un tableau dit ce qui est fait ; c'est un mauvais endroit pour comment quelque chose fonctionne, ce qui a été décidé et pourquoi, ou la forme d'une chose. Cela va sur le wiki du tableau — slipdock page ls <board>, slipdock page read <page>, slipdock page new <board> <title...>. Le test est de savoir si cela sera relu après la fermeture de cette carte : une décision, un runbook, une spécification ou les conclusions d'une enquête le seront, et doivent aller sur une page (liée depuis le commentaire de clôture de la carte par son code, W-31) ; la progression, les bloqueurs et ce qui s'est passé maintenant doivent aller dans un commentaire sur la carte. Jamais les deux — une page qui répète les commentaires est une page à laquelle personne ne fait confiance. Cherchez avant d'en écrire une (slipdock page ls <board> --q <la chose>) : étendre la page qui existe bat une quatrième page sur le déploiement. Passez --message sur chaque édition, et --base-hash sur toute édition d'une page que vous n'avez pas écrite vous-même, afin qu'une sauvegarde ne puisse jamais atterrir silencieusement sur celle de quelqu'un d'autre.
• Gardez les titres courts. Un titre de carte fait environ 60 caractères au maximum, une série comme <Série> <n> : <quoi> (Supervision d'agent 5 : Tâches en attente), les détails dans la description. Le titre d'une carte devient un dossier et apparaît dans des listes serrées, et une séquence de cartes qui partagent leurs 40 premiers caractères ne peut pas être distinguée là.
• Ne supprimez pas les cartes (archivez plutôt), ne réécrivez pas un titre pour correspondre à ce que vous avez réellement fait, ne rangez pas les cartes des autres, et ne laissez pas une carte en cours sans commentaire plus récent que le déplacement. Archiver ou réorganiser tout un tableau est encore plus éloigné de votre mission : seulement sur une demande explicite, nommant ce tableau.

Quand cela s'applique

• "Sur quoi dois-je travailler ensuite ?", "poursuivre le plan", "parcourir le backlog", "tâche suivante" → récupérez le guide, puis choisissez selon ses règles et dites quelle carte vous avez prise et pourquoi.
• "Mettre ce plan sur le tableau", "découper cela en tâches" → epics avec sous-cartes, selon la forme du guide.
• Vous êtes déjà en cours de tâche sur quelque chose issu du tableau → la carte est l'endroit où la progression, les décisions et les bloqueurs sont écrits, au fur et à mesure plutôt qu'en un seul dump à la fin.
• Vous avez terminé quelque chose issu du tableau → fermez-le sur le tableau avant de le signaler comme terminé.
• "Quel est l'état de mon travail ?", "qu'est-ce qui est en cours ?", "montre-moi le tableau" → résumez ce que la carte pertinente montre, en donnant les ids (pas besoin de guide).
• Rien de tout cela → ce fichier ne s'applique pas : ignorez-le.