amberpixels/ship

f10 · ship

Exécuter cette compétence est l'autorisation explicite de l'utilisateur pour pousser et ouvrir ou actualiser la PR de cette tâche (l'étape pr), satisfaisant la règle globale "ne jamais pousser / ouvrir une PR sauf demande explicite" uniquement pour cette PR, et pour poster le +reply de resolve, pousser les correctifs de resolve vers cette PR, poster le f10 review ack de review, et pour une revue CI dans le flux son f10 review trigger (quand la section Review déclare un manuel comment il peut lire) et le f10 review settle de resolve, pour une entrée de juge après pr, pousser l'intégration du garde de rattrapage et ses propres modifications vers cette PR et poster son statut et commentaire, ainsi que poster le commentaire de rapport et le statut sur la tâche (Rapport). Le déploiement a sa propre confirmation (l'étape deploy).

Arguments

• --help : suivre ${CLAUDE_PLUGIN_ROOT}/modes/help.md et s'arrêter ; rien de ce qui suit ne s'applique.
• --dry-run : suivre ${CLAUDE_PLUGIN_ROOT}/modes/dry-run.md au lieu d'exécuter quoi que ce soit, et s'arrêter. Il indique quelles étapes le reste de l'argument exécuterait.
• --driven : suivre ${CLAUDE_PLUGIN_ROOT}/modes/driven.md ; tout ce qui suit est toujours exécuté.
• Un nom de flux sous forme de mot (/f10:ship direct: fix typo … ; f10 start --local envoie /f10:ship local: <id>, --flow <name> envoie <name>:) ou nommé dans les propres mots de l'utilisateur : exécuter ce flux. Sinon, le flux que le flow_by_area du frontmatter associe au domaine de la tâche (les domaines du brief de récupération, sinon la ligne Areas du plan), sinon default. Deux domaines qui pointent vers des flux différents : le domaine du livrable l'emporte, comme pour les Rôles, et le brief nomme l'autre. La carte de domaines est le choix du projet, pas le vôtre : ne jamais sélectionner vous-même un autre flux, bien que pour un petit travail vous puissiez en suggérer un. Nommer le flux qu'un domaine a choisi, et le domaine, sur une ligne avant la première étape.
• --pace <name> : exécuter le flux à ce rythme pour cette exécution seulement (Rythmes, ci-dessous) ; sans cela, le rythme enregistré par la branche, sinon celui du projet ou de l'utilisateur pace:.
• <plan.md> : un fichier de plan ; exécuter le flux avec lui.
• <task-id> (format d'ID de projet / id / url), ou un bundle joint par + (ABC-1+ABC-2, avec la clé sur le chef de file) : suivre d'abord ${CLAUDE_PLUGIN_ROOT}/modes/forward.md, avant de charger quoi que ce soit ; s'arrêter s'il transmet la tâche. Sinon, exécuter l'étape fetch, puis chercher <storage root>/plans/<TASK-ID>.md (le chef de file d'un bundle) (parcourir le dossier des plans si le nom exact manque). Trouvé : le réutiliser, sans jamais demander ; une tâche avec un fichier de plan ne planifie jamais à nouveau, et la replanification se fait manuellement avec /f10:plan <id>. Manquant : sous stale_after, fetch juge d'abord une tâche ancienne et peut mettre fin à l'exécution bloquée avant tout plan ou entrée de flux (anyway dans la direction le saute) ; puis exécuter l'étape plan lorsque le flux commence par plan (avec flow_by_area, start et drive laissent la planification à ship) ; un flux sans plan (ci-dessous) ne l'exécute jamais, et le brief de récupération devient le plan en ligne. Puis le flux.
• <description> : texte libre ; les étapes capture, fetch et plan, puis le flux.
• Aucun argument (les drapeaux ou un seul mot de flux comptent comme rien ; une description est du texte libre, ci-dessus) : une tâche déjà dans cette conversation (un plan vient d'être sauvegardé, une tâche récupérée), sinon la tâche de la branche, l'id que f10 task current affiche. Dire en une ligne quelle tâche vous avez prise et d'où, puis l'exécuter comme un <task-id>, mode de transmission inclus, donc un plan sauvegardé est réutilisé. f10 task current sortant avec un code non nul : demander une tâche en une ligne et attendre (driven : une demande, selon modes/driven.md).
• Texte supplémentaire à côté du sujet est une direction. resume at <entry> (envoyé par f10 drive une fois qu'un rattrapage a réglé l'arrêt) commence le flux à cette entrée et compte les précédentes comme faites ; (entry <n>) choisit la n-ième entrée du pipeline du badge là où le flux la nomme deux fois. Le badge se déplace jusqu'à cet endroit : après pipeline, un appel exécute set ship running sur chaque entrée avant elle, dans l'ordre, puis sur l'entrée elle-même.

Exécution

1. Exécuter f10-load-project.sh d'abord, à chaque appel de cette compétence, en nommant les étapes dont l'entrée a besoin : capture fetch plan pour une description, fetch plan pour un ID de tâche, rien pour un fichier de plan. Le flux est déclaré dans le project.md qu'il affiche ; un flux sans plan charge plan mais ne l'exécute jamais.
2. Suivre ces étapes dans l'ordre donné par l'élément Arguments.
3. Charger chaque entrée du flux juste avant qu'elle ne s'exécute, en un seul appel avec son badge : f10-state.sh set ship running <entry>; f10-load-project.sh <step>, et suivre l'étape à partir de ce chargement. Une entrée review charge review resolve, et une entrée pr charge pr handoff sauf si son réglage handoff off est activé, car l'étape pr exécute le handoff ; le garde de rattrapage (ci-dessous) ajoute catchup au chargement de chaque entrée qu'il garde.

Flux sont les flows: du frontmatter, un nom vers ses entrées ordonnées, une liste ou une seule chaîne séparée par des espaces ou des flèches (plan judge implement cleanup:comments,prose pr review:ci deploy:staging) ; aucun déclaré signifie default: plan implement pr. f10 flow les liste et ce qui sélectionne chacun.

Rythmes ajustent le flux choisi (docs/project-setup.md → Rythmes). Une fois le flux choisi, exécuter f10 flow <name> [--pace <name>], en passant --pace seulement quand l'argument en a donné un, et exécuter les entrées qu'il affiche dans son ordre, jamais la liste du frontmatter. Il affiche une entrée par ligne. Une entrée marquée skipped ne s'exécute pas : le dire en une ligne, et la laisser hors du pipeline du badge. Les réglages après une entrée vont à son étape avec l'entrée : rounds et depth pour review, marker et handoff pour pr ; le effort d'un juge s'applique seulement là où le juge engendre un agent (--blind), dont le profil vient alors de f10 agents judge, avec --pace <name> quand l'argument en a donné un ; un juge en ligne s'exécute sur le profil de l'agent de la tâche. Un plan en tête que le rythme saute rend l'exécution sans plan, comme un flux sans plan l'est. Une ligne finish signifie que l'exécution se termine sur une PR ouverte que le rythme aurait fusionnée : ship ne la fusionne jamais, et le Next: du rapport nomme /f10:finish <id> --merge, sauf si drive termine la tâche (modes/driven.md). Sans rythme, la liste est le flux déclaré, avec une éventuelle revue CI (ci?) déjà réglée. Un f10 flow trop vieux pour accepter un nom échoue dessus : exécuter le flux déclaré, et dire en une ligne que le rythme n'a pas été appliqué.

Une entrée est une étape, ou step:arg : une étape générique plus sa surcouche, ou une étape définie par le projet, l'argument qui lui est passé (review:local ou review:ci définit le by de la revue (qui révise), review:host exécute la revue locale sur la revue de code de l'hôte, review:local+ci exécute les deux en un seul tour et une seule résolution, review:local+ci? exécute la revue CI seulement là où elle peut s'exécuter, et f10 flow <name> règle le ? avant que ship ne voie l'entrée, cleanup:<targets> les cibles de nettoyage, qui reçoivent toujours le passage complet là où cleanup nu exécute un passage léger sur un diff de moins de 200 lignes ajoutées, deploy:<env> l'environnement). L'exécution commence à l'entrée après un plan en tête, qui ne s'exécute que pour une tâche sans fichier de plan. resolve n'est jamais nommé : une entrée review l'exécute. Une entrée judge juge par position : avant implement le juge de plan (sujet plan <id>), dont le verdict jaune révise le fichier de plan sur place et n'écrit pas de code ; après lui le juge de modification, qui construit lui-même les changements d'un verdict jaune, routé comme l'étape judge le dit avant et après pr. Une entrée pr ouvre la PR de la branche, ou l'actualise quand une est ouverte, donc un flux peut nommer pr à nouveau après une revue ou un juge pour mettre à jour la description. Un flux sans plan en tête est sans plan : il n'écrit pas de fichier de plan, et un bref plan en ligne dans le chat le remplace à moins qu'un plan sauvegardé n'existe. Les anciennes clés (pipelines, planless, drive_chain) sont encore lues, converties en flux avec un avertissement qui nomme f10 init --migrate, et il en va de même pour l'ancienne forme d'entrée review (local). L'entrée en texte libre saute aussi la capture et la récupération, donc l'exécution n'a pas d'ID de tâche. Un ID de tâche exécute la récupération et garde l'exécution liée à l'ID (badge, rapport, branche, dossier de revue), et marque f10-state.sh set plan skipped une fois récupéré, sauf s'il réutilise un plan sauvegardé (prior, ci-dessous). Son plan en ligne indique le genre que la récupération a réglé, avec la reproduction d'un bug et sa cause racine, l'invariant d'un refactoring ou la question d'une expérience sur une ligne chacun, et liste les lacunes éventuelles sur leurs valeurs par défaut. Avec un ID de tâche, le plan en ligne écrit aussi l'intention du changement comme le fait l'étape de plan (f10 lore add intent --change <change> -m <quoi et pourquoi>, docs/lore.md) ; une intention existante, ou un ajout échoué, est une ligne dans le rapport, jamais une étape échouée. Le shipment est la dernière entrée livrante (conventions/context.md → shipment) : ses lignes sont celles que cette étape déclare, celles d'une étape définie par le projet sur la ligne Shipment: de sa surcouche ; un judge, demo ou handoff après elle ajoute des lignes, ne les remplace jamais. Une entrée demo sans rien à montrer saute en une ligne (l'étape demo), une fin normale qui n'ajoute aucune ligne.

Une expérience se termine après implement, quel que soit le flux : un plan Kind: spike répond à une question, et son code ne quitte jamais la machine. Aucune étape après implement ne s'exécute (pas de nettoyage, commit, push, pr, revue, juge ou déploiement) ; le shipment est le rapport d'expérience. Le rapport final se termine par sa fermeture : f10 finish <id>, qui archive le plan et le rapport, jette le code d'expérience et supprime l'arbre de travail, la branche et l'espace de travail ; --keep garde l'expérience, commitée sur une branche kept/. Une expérience dirigée n'a pas besoin de fermeture dans le rapport : f10 drive la ferme après ship. Dans le checkout principal, jeter le code d'expérience par les chemins que le rapport nomme avant f10 finish, qui refuse un checkout principal sale. Son rapport de retour (ci-dessous) porte la question, la réponse et la recommandation ; il nomme le chemin du rapport d'expérience seulement sous visibility: public, car stealth garde les chemins .f10/ hors du tracker. Le genre est connu à partir du plan, ou du plan en ligne d'une exécution sans plan, avant le début du flux, donc le badge déclare f10-state.sh pipeline implement, et une exécution à sec imprime le chemin coupé à implement.

Le garde de rattrapage amène la base avant trois types d'entrées, comme l'étape catchup le dit dans En tant que garde ; sous catchup: off, il n'intègre jamais et son chargement laisse catchup de côté, mais la question ci-dessous pour une base sans code s'exécute toujours. Le rattrapage n'est jamais une entrée de flux.

• Avant implement, seulement là où f10 start --after ou f10 finish a enregistré une base sur la branche (f10-after-branch ou f10-landed) ; f10 pr catchup --guard implement affiche method: skip sinon. Une base sans code encore est la ligne code: none du garde, la règle par laquelle f10 drive libère les dépendants, pour une base conservée localement ou seulement sur origin. Avant d'intégrer, demander une fois (AskUserQuestion) attend, ou procède sur l'hypothèse du plan. Attendre termine l'exécution bloquée (f10-state.sh set ship blocked implement, une note nommant la tâche de base). Procéder construit contre le plan de la tâche de base tel que le fichier de plan l'enregistre, sans aucune solution de repli s'il est absent. Dirigé, rien n'est demandé et ship ne procède jamais : f10-state.sh set ship blocked implement; f10-state.sh wait <base-id>; f10-state.sh note "attente de <base-id> : sa branche n'a pas encore de code" "relancer ship une fois que <base-id> commite ; f10 drive le fait tout seul", puis le rapport. f10 drive retient la tâche comme waiting on <base-id> et renvoie ship, resume at implement, une fois que la base commite ; les autres tâches continuent.
• Avant chaque entrée pr, la première et chaque actualisation : f10 pr catchup --guard pr d'abord, qui récupère et vérifie l'ascendance ; seulement quand sa method est merge, rebase ou onto, commiter ce que l'arbre contient comme l'étape pr le ferait (conventions/context.md → Commits, --step implement) et intégrer, pour que le push le porte. skip ou none laisse le commit à pr et à son adaptateur.
• Avant un juge de modification (un judge après implement ; le juge de plan n'a pas de code) : avec du travail non commité dans l'arbre (implement laisse son travail non commité, donc implement judge pr en a toujours), le sauter en une ligne : ce juge voit la branche sur son ancienne base, et un garde d'entrée pr ultérieur, quand le flux en a un, amène la base avant que le code ne parte. Après une entrée pr, pousser l'intégration, sans jamais forcer, pour que la tête de PR soit le code jugé et que le statut du juge atterrisse dessus.

Le garde s'exécute sous l'entrée qu'il garde, dans le chargement de cette entrée (catchup pr) et son badge. Un échec est set ship failed <entry>, ou partial une fois que l'exécution a laissé quelque chose de durable, le propre commit du garde ou une PR ouverte (conventions/failure.md règle 7), sa ligne state nommant ce commit et sa note nommant catchup et /f10:catchup. Le garde marque la branche avant d'échouer (l'étape catchup), et f10 drive rattrape une branche marquée tout seul, à nouveau chaque fois que la base bouge, puis invite ship à nouveau à cette entrée ; il s'arrête, en nommant les fichiers, quand un rattrapage n'a rien changé, la base n'a pas bougé, ou les mêmes fichiers entrent en conflit deux fois de suite. Le next d'une exécution dirigée est run /f10:catchup --driven in the worktree, then rerun the drive : la réexécution invite ship à nouveau à cette entrée.

Exécuter les entrées du flux dans l'ordre déclaré, chacune à partir de son propre chargement. Un plan écrit lors de cette exécution n'a pas besoin d'être reconfirmé. Une entrée judge route l'exécution par son verdict : le juge de plan comme le dit la route avant pr de l'étape judge, ses changements intégrés dans le fichier de plan pour que implement les construise ; le juge de modification différemment avant et après une entrée pr (l'étape judge). Les changements d'un juge de modification, avant ou après pr, sont intégrés dans le plan et construits par la propre route de l'étape judge (Construire les changements), jamais par une réexécution de implement.

Badge (conventions/report.md) : f10-state.sh pipeline <entry>... une fois que le flux est sélectionné, chaque entrée après plan comme le flux la nomme, un argument chacun (pipeline judge implement cleanup pr review:local judge pr), ce qui déclare aussi le dernier comme final ; f10-state.sh set ship running <entry> avant chaque entrée, nommée comme le flux la nomme, dans l'appel qui la charge ; f10-state.sh set ship done après le dernier. Un plan d'une exécution antérieure (fichier de plan, ou réutilisation) est f10-state.sh set prior <plan-file> une fois chargé, pour que le badge sache qu'il ne vient pas de cette exécution. f10-state.sh branch <task-id> une fois qu'un ID de tâche charge le plan, en s'exécutant comme f10 branch <plan-file> ; l'avoir fait pour la tâche en fait une condition préalable pour f10-state.sh pipeline.

Rapport (conventions/report.md) : un rapport de progression après la dernière entrée exécutée. pr et handoff nécessitent un rapport avant leur entrée (f10-state.sh report). review et resolve nécessitent un rapport de revue (conventions/review.md → Rapport de revue, f10-state.sh report), que l'étape review exécute. Un rapport final après la dernière entrée (f10-state.sh final-report), avec des sections Steps (état de chaque entrée du pipeline, et report, final-report), Next: (la prochaine étape : quand le badge a done, run /f10:finish <id> ; une entrée de flux échouée (failed) nomme une commande de récupération et rerun /f10:ship <id>), et les lignes de shipment (ci-dessous) ; pr et handoff nécessitent le rapport surtout pour leur état de charge, car l'étape pr nécessite que le badge ait une entrée pipeline avec les précédentes marquées running. Pour une expérience, le rapport final est report au lieu de final-report, et f10 finish <id> ferme l'expérience (ci-dessous). Une revue locale qui échoue (review:local) mais que la résolution règle s'ouvrant en CI revoit la PR après son rapport (conventions/review.md). f10-state.sh set ship failed marque une entrée ; set ship partial pour une entrée qui a laissé quelque chose de durable, et le rapport pour cette entrée nomme ce qu'elle a laissé, sinon l'exécution est un échec simple. Les chemins propres au rapport sont : f10-state.sh note <text>, f10-state.sh flee <text> (une note qui nomme un problème à résoudre avant de continuer) ; ces notes deviennent des lignes dans le rapport. Un rapport final est écrit une fois, après la dernière entrée ; un rapport de progression est écrit à chaque entrée.

Exemples

• /f10:ship PROJ-123 : récupérer la tâche PROJ-123, planifier (si aucun plan n'existe), puis exécuter le flux par défaut (implement, pr).
• /f10:ship my-plan.md : exécuter le flux en utilisant le plan spécifié.
• /f10:ship --dry-run PROJ-123 : faire un essai à sec pour PROJ-123, en montrant quelles étapes seraient exécutées.
• `/f10:ship --pace fast