Tâches

Décrivez un travail, et Spunto lui donne une machine, une branche et un agent — puis vous rend quelque chose à relire.

Une tâche est un travail que vous confiez : « le bouton Ship déborde de sa carte sur mobile — corrige-le. »

Vous écrivez le prompt. Spunto trouve une machine, crée une branche, y lance un agent, et vous montre ce qui se passe au moment où ça se passe. Quand l’agent s’arrête, la tâche vous attend.

Merger une pull request ailleurs ne clôt pas une tâche. Accept, si.

Note

Les tâches tournent dans des sandboxes — les mêmes machines isolées, les mêmes dépôts clonés, les mêmes secrets. La différence, c’est que vous n’avez jamais à penser à la machine. Une est démarrée pour chaque tâche, mise de côté pendant la relecture si vous le souhaitez, et supprimée dès que vous acceptez.

Ouvrez un projet et cliquez sur New task — ou ouvrez Agents, où la partie droite est une nouvelle conversation tant qu’aucune n’est sélectionnée. Seul le prompt est obligatoire.

Une nouvelle tâche : une conversation vide qui demande ce que l’agent doit faire et, en bas, une zone de prompt avec un bouton de pièce jointe, des puces pour la branche de base, le modèle et la machine, et un bouton Delegate — Vous l’écrivez là où sera la conversation. Les puces sous le prompt montrent ce qui sera utilisé si vous n’y touchez pas.

Donnez autant de détails qu’à un collègue — le fichier que vous soupçonnez, à quoi ressemble « terminé », ce qu’il ne faut pas casser — et appuyez sur Entrée pour déléguer (Maj+Entrée pour un retour à la ligne). Vous pouvez coller ou déposer une capture d’écran directement dans le prompt ; le fichier arrive dans la sandbox et l’agent est informé de son emplacement.

Dès que la tâche est déléguée, la zone de saisie reste où elle est et la conversation commence au-dessus — c’est la même zone qui vous servira à répondre à l’agent.

Il n’y a pas de titre à remplir : la tâche démarre sous la première ligne de votre prompt, puis prend le nom que l’agent donne à la conversation dans les premières secondes. Vous pouvez la renommer à tout moment depuis le haut de la conversation.

Les puces sous le prompt sont des échappatoires : le harnais — Claude Code ou Codex, parmi ceux que le projet autorise —, le modèle et ses réglages si ce travail précis mérite plus gros que le modèle par défaut du projet, la branche de base si vous ne partez pas de la branche par défaut du dépôt, et la taille de sa sandbox. Sans taille choisie, c’est le réglage de l’organisation qui s’applique (Settings → Agents & tasks).

La tâche apparaît en Queued et avance d’elle-même. Tant qu’il n’y a pas encore de machine, la page vous montre le démarrage lui-même — la création de la sandbox, l’image, le clonage de chaque dépôt, vos commandes de setup. Puis la session démarre et la page se remplit.

Une page de tâche : la conversation avec la capture d’écran jointe par l’utilisateur, l’en-tête de session, la réflexion de l’agent, son plan en trois étapes terminées et un appel d’outil — avec la branche, le contexte, le coût et le prompt dans la barre latérale droite — Votre prompt, le raisonnement de l’agent, son plan, chaque appel d’outil — en direct.

Tout ce qui est à gauche, c’est la session pendant qu’elle tourne : ce que l’agent a dit, ce qu’il pensait, le plan qu’il suit, chaque outil appelé et ce qui en est revenu. À droite, ce qu’il vous faut pour en juger : quelle branche, combien de contexte il a consommé, ce qu’il a coûté jusqu’ici, quelle machine il a obtenue.

Une longue session est repliée plutôt que déversée. Douze lectures, six modifications et un lancement de tests se résument en une seule ligne qui dit ce qu’ils représentent — et laisse tout échec visible.

La même page pour une tâche plus longue : quarante-neuf événements présentés comme un plan, une ligne repliée indiquant 16 steps, read 6 files, edited 6 files, 2 searches, 1 failed, puis la conclusion de l’agent — Quarante-neuf événements, quatre lignes. « 1 failed » reste à l’extérieur pour que vous ne puissiez pas le manquer.

Dépliez n’importe quelle ligne pour retrouver les appels un par un, ou ouvrez la pile d’outils (tool stack) depuis l’en-tête de la session pour parcourir tous les appels de la session d’un coup — entrée et sortie complètes, filtrées par outil ou par sujet, avec un interrupteur pour ne garder que ceux qui ont échoué.

Le panneau de la pile d’outils : une liste de vingt appels à gauche dont un appel Bash marqué en échec en rouge, l’entrée et la sortie JSON de l’appel sélectionné à droite — « Qu’a vraiment fait cet agent ? » — vingt appels, dont un en rouge.

Quand la session se termine, la tâche passe en In review et s’arrête. L’onglet Diff, à côté de Session, répond à la seule question qui décide d’un Accept : qu’est-ce qui a changé ?

L’onglet Diff : trois fichiers modifiés avec leurs proportions d’ajouts et de suppressions, l’un d’eux déplié en un patch unifié dont les mots changés sont surlignés, et un panneau Machine à droite montrant la machine de la tâche — Lu depuis la base de fusion jusqu’à l’arbre de travail — y compris les fichiers que l’agent n’a jamais commités.

Trois choses à savoir sur ce que vous regardez :

Il est lu depuis l’endroit où votre branche a divergé, pas depuis la pointe de main. Les douze commits que quelqu’un d’autre a poussés pendant que l’agent travaillait ne font pas partie du diff de cette tâche.
Il va jusqu’à l’arbre de travail. Un agent qui a modifié dix fichiers sans commiter a modifié dix fichiers, et vous les voyez. Les fichiers nouveaux qu’il n’a jamais ajoutés apparaissent en untracked.
Spunto interroge la machine qu’il a démarrée, avec git — pas votre forge. Un projet dont le remote est un Gitea sur le portable de quelqu’un se relit exactement de la même façon, et aucune pull request n’est nécessaire pour lire une branche.

Si votre projet met la machine de côté pendant la relecture, le diff l’indique et le panneau Machine est juste là pour la redémarrer.

Le diff vous dit ce qui a changé. Il ne vous dit pas si la CI est verte ni si quelqu’un a déjà laissé un commentaire — ça, c’est sur votre forge. Si votre projet est relié à une forge qui l’expose, un panneau à côté du diff montre la pull request ouverte pour cette branche : son état, ses checks, sa revue, son nombre de commentaires.

Il est en lecture seule, volontairement. Une pull request mergée ne passe pas la tâche en done, et une pull request fermée ne la fait pas échouer. Quelqu’un qui merge depuis son téléphone ne doit pas mettre de côté un conteneur que vous êtes en train de lire.

Deux boutons, et ce sont les seuls à faire passer une tâche au-delà de la relecture.

Accept clôt la tâche en done, en lançant d’abord la commande d’acceptation du projet s’il en a une — gh pr merge, un déploiement, ce que « terminer » veut dire chez vous.
Drop tue la session, lance votre commande de nettoyage et passe la tâche en failed avec la raison.

Note

Rien d’autre ne fait avancer une tâche. Merger la pull request sur votre forge, non ; la fermer non plus. La tâche attend en relecture, en gardant sa machine, jusqu’à ce que vous décidiez. C’est voulu — le raisonnement complet est dans Tâches avancées.

done ou failed n’est pas une impasse. Tant que la sandbox de la tâche existe encore, la zone de réponse reste ouverte : écrivez-y et la tâche repasse en relecture, sur la même machine, et l’agent reprend la même conversation. La timeline marque l’endroit où elle a été reprise. Quand la sandbox n’existe plus, la zone dit pourquoi.

Une tâche qui a échoué avant même que son agent ait démarré — la sandbox ne s’est pas construite, la branche n’a pas pu être créée — n’a pas de conversation à reprendre. Elle a à la place un bouton Retry, qui la relance depuis le début : même prompt, même branche.

En bas d’une tâche se trouve une zone de réponse. Écrivez « en fait, fais plutôt X » et le message part à l’agent — même conversation, même branche, même sandbox, redémarrée d’abord si le mode de relecture l’avait mise de côté. Ses événements prolongent la même timeline.

Avec la configuration par défaut, la session reste vivante entre deux tours : vous pouvez donc le dire pendant qu’il travaille encore, et vous pouvez interrompre le tour en cours sans tuer la session — il finit ce qu’il est en train de dire et vous attend, et c’est ce qui le distingue de Drop. Avec un harnais qui ne sait pas garder un stdin ouvert, la zone ne s’active qu’une fois la tâche en relecture ; quand elle est désactivée, elle indique pour quelle raison.

Vous pouvez joindre des fichiers à une réponse comme au prompt — coller, déposer, ou le trombone. L’agent renvoie aussi des fichiers : une capture d’écran qu’il a prise, un rapport qu’il a généré, affichés directement dans la timeline.

En bref : votre prompt, plus deux lignes, et rien d’autre. Pas de prompt système caché, pas de règles de style maison que vous n’avez pas écrites — et aucun skill que votre organisation n’a pas mis dans son propre catalogue de skills.

<your prompt>
 
---
Spunto context: you are running in a disposable worker, on branch
`task/fix-the-ship-button-a1b2c3` (created from `main`), already checked out.
When the work is done: commit on this branch and push it.

Ces deux lignes ne sont pas de la même nature, et une seule vous appartient :

La première, ce sont des faits — quelle branche, d’où elle vient, qu’elle est déjà extraite. Un agent ne peut pas les deviner depuis l’intérieur de son conteneur, donc ils sont toujours envoyés.
La seconde est une consigne — ce que « terminé » veut dire. C’est un parti pris, et c’est à votre organisation de l’écrire.

Si vous avez joint des fichiers, une ligne de plus donne leurs chemins dans la sandbox : n’importe quel agent capable d’ouvrir un fichier peut s’en servir, quel que soit le protocole qu’il parle.

C’est tout. En particulier, Spunto ne demande pas à l’agent d’ouvrir une pull request : il ne lit aucune forge, donc l’exiger serait faire une hypothèse sur un outil dont il ne sait rien. Vous voulez une PR ? Demandez-la — c’est exactement à ça que sert le réglage ci-dessous.

Note

Le préambule va à l’agent, pas à la timeline que vous lisez. Une conversation qui s’ouvrirait sur l’agent répondant à une question que vous ne voyez pas se lirait comme une moitié de transcription.

Settings → Agents & tasks → Agent instructions, une zone de texte, réservée aux owners et aux admins. Ce que vous y écrivez remplace la ligne par défaut sur toutes les tâches que cette organisation délègue.

La carte Agent instructions dans les réglages de l’organisation : une zone de texte vide affichant la consigne par défaut de la plateforme en placeholder, un compteur de caractères et un panneau listant les faits sur la branche que chaque agent reçoit quoi qu’il arrive — Vide, elle montre la consigne par défaut qu’elle remplacerait. Le bloc en dessous est ce que vous ne pouvez pas retirer.

Par exemple :

When you are done: run `npm test`, commit on this branch, push it,
and open a pull request with `gh pr create --fill`.

Écrivez-la dans la langue de travail de votre équipe — l’agent la suivra, et répondra, dans cette langue. Elle est limitée à 4 000 caractères, parce qu’elle se paie à chaque session ; au-delà, c’est un document, pas une consigne, et sa place est dans un CLAUDE.md que l’agent lit dans le checkout.

La ligne de faits est envoyée quoi que vous écriviez. Elle n’est pas à vous de la supprimer — un agent qui ne sait pas nommer sa propre branche ne l’apprendra pas d’un réglage.

Note

Lue au démarrage d’une tâche. Une tâche déjà en cours garde la consigne avec laquelle elle a démarré, parce que ce texte est entré dans une conversation qui continue.

Certaines choses ne valent que pour un dépôt — quelle suite de tests lancer, quel dossier ne jamais toucher. Mettez-les dans le champ Edit → Agent instructions du projet (avec les autres réglages des tâches). Elle est ajoutée après la consigne de l’organisation, jamais à sa place : l’organisation dit toujours ce que « terminé » veut dire partout, le projet ajoute seulement ce que ça veut dire ici. Mêmes règles par ailleurs — jusqu’à 4 000 caractères, lue au démarrage d’une tâche, vide veut dire que rien n’est ajouté.

Before pushing, run `npm test --workspace apps/api`. Never edit files under `vendor/`.

La consigne d’organisation ci-dessus est un bloc de texte, pas des fichiers. Les fichiers arrivent jusqu’à l’agent parce que Spunto lui donne une machine qui ressemble à la vôtre — tout ce que vous gardez déjà sous gestion de versions vient avec le clone —, plus les skills que votre organisation partage :

Quoi	D’où ça vient
`CLAUDE.md`, `AGENTS.md`	votre dépôt — cloné dans la sandbox comme n’importe quel autre fichier
`.claude/skills/`, `.claude/agents/`, `.claude/settings.json`	votre dépôt, de la même façon
Skills partagés entre projets	les sources de skills de votre organisation — des dépôts git clonés dans chaque sandbox, chaque projet choisissant les skills qu’il utilise, rafraîchis avant chaque tâche
Skills personnels, alias, configuration `~/.claude/`	votre dépôt de dotfiles (Account settings → Dotfiles), cloné et lié dans `$HOME` à la mise en place de la sandbox — et il l’emporte sur un skill d’organisation du même nom
`ANTHROPIC_API_KEY` et compagnie	les secrets de votre projet ou de votre organisation

Toujours pas injectés : les définitions de sous-agents et settings.json — ils viennent de votre dépôt ou de vos dotfiles.

Il y a donc deux endroits où mettre des consignes permanentes, et ils répondent à des questions différentes. Agent instructions, c’est à quoi ressemble un travail fini dans cette organisation (plus, par projet, une ligne ou deux sur ce dépôt) — pour les tâches déléguées seulement. Un CLAUDE.md commité, c’est comment fonctionne ce code — aussi long que vous voulez, et il sert à quiconque travaille dans le dépôt, vous compris dans votre propre éditeur.

Toutes les tâches de l’organisation sont sur une seule page — Agents dans la barre latérale —, regroupées par état et, dans un groupe, de la plus récemment active à la plus ancienne. La dernière session à vous avoir rendu la main est la première ligne sous In review, quelle que soit l’ancienneté de la délégation.

La page Agents : une colonne de gauche listant sept conversations regroupées sous Queued, Running, In review, Failed et Done, chacune avec le nom de son projet et son ancienneté — Sept conversations dans toute l’organisation, regroupées selon ce qu’elles attendent de vous.

La page d’un projet montre la même liste limitée à ce projet, et sur un téléphone l’ensemble devient une messagerie — conversations en plein écran, zone de réponse au-dessus du clavier, machine et prompt à un toucher.

Une tâche possède sa sandbox jusqu’à ce qu’elle soit done ou failed — y compris pendant que vous la relisez. Confier la machine à quoi que ce soit d’autre écraserait les données de test, les artefacts et l’arbre de travail que vous avez ouvert la relecture pour regarder.

Ce qu’elle devient pendant la relecture est un réglage du projet :

Keep it running (par défaut) — reprise instantanée, au prix d’une machine allumée.
Stop it — la sandbox s’arrête, son /workspace reste, un clic la redémarre.

Une fois une tâche acceptée, sa sandbox est détruite ; celle d’une tâche en échec est arrêtée et conservée, et c’est pourquoi vous pouvez encore reprendre la tâche. Chaque tâche démarre depuis le build du projet, ou depuis un de vos snapshots — déjà prête, en quelques secondes.

Tout ce qui relève d’un parti pris dans une tâche est un réglage du projet, sous Edit → Agents → Delegated work. Sans y toucher, vous avez Claude Code, lu en direct pendant qu’il travaille.

Réglage	Sans y toucher…	Valeurs possibles
Harnais	Claude Code	Claude Code, Codex, ou les deux — le premier est celui par défaut, chaque tâche peut en choisir un autre
Modèle par défaut	l’app choisit le sien	un modèle de chaque harnais, par ex. `claude-opus-5-5`
Commande d’acceptation	Accept clôt simplement la tâche	`gh pr merge`, `glab mr merge`, un déploiement
Commande d’abandon	la session est simplement tuée	le nettoyage dont vous avez besoin
Machine pendant la relecture	laissée allumée	arrêtée

Une nouvelle organisation arrive avec Claude Code installé ; Codex est à un clic dans Settings → Integrations. Chacun lit sa propre clé dans vos secrets : ANTHROPIC_API_KEY pour Claude Code, OPENAI_API_KEY pour Codex.

Choisir entre les agents, leurs modèles et leurs réglages, piloter les tâches par l’API, essayer tout le cycle sans forge ni identifiants — tout cela est dans Tâches avancées.

curl -X POST \
  -H "Authorization: Bearer spk_..." \
  -H "Content-Type: application/json" \
  -d '{"prompt":"The invite email says “You has been invited”. Fix the verb form."}' \
  https://spunto.net/api/orgs/{orgId}/projects/{projectId}/tasks

L’appel répond tout de suite — allouer une machine et lancer un agent prend des minutes, et tourne comme un job de fond durable. Interrogez GET .../tasks/{taskId}, ou regardez simplement la page.

Les clés d’API ont besoin des scopes tasks:read / tasks:write. tasks:write lance une session d’agent dans une sandbox, donc donne un accès équivalent à un shell — c’est pour ça qu’il n’est volontairement pas inclus dans projects:write.

Pas de permissions interactives. C’est pourquoi les agents tournent sans elles — un « puis-je lancer ceci ? » n’a encore nulle part où recevoir de réponse.
Pas de sortie token par token. Les événements arrivent tour par tour, pas mot par mot.
Pas de notifications. C’est vous qui venez à la page ; la page ne vient pas à vous.

PrécédentDémarrage rapide SuivantSandboxes