Orchestration longue durée
Un coordinateur est un point de décision en série : chaque lecture qu'il fait et chaque décision qui lui est routée attend dans une file d'attente sans horloge, et lorsqu'il sature, le travail s'arrête en silence. Cette compétence empêche toute chose d'atteindre une telle file d'attente.
Le niveau supérieur d'un pilotage est constitué de deux sessions. Le communicateur est la session dans laquelle le propriétaire tape ; son seul travail est lui-même. Le coordinateur est une session Orca sœur liée en tant que voie root : il crée une voie pour chaque demande avec un corps au moment où elle arrive, décide de ce qu'un processus a escaladé et relaie ce que les bureaux produisent. À côté d'eux se tiennent la méta-voie, qui prend chaque changement de compétence, d'outillage et de processus et transforme chaque décision en mise à jour de la compétence, et la voie de signalisation, qui suit le coordinateur afin que le communicateur n'ait jamais à le faire. Tout le reste est un verbe de l'outil de pilotage lr ou un processus qui s'exécute sans aucun d'eux. Une règle ici nomme le verbe ou le processus qui rend un échec impossible ; une règle sans l'un ni l'autre est un défaut à corriger dans le pack.
Cette compétence réside dans ~/.claude/CLAUDE.md, qui possède la forme de fan-out, le routage de modèle et la profondeur de vérification. Le pack est un binaire Go, lr, avec les scripts Python qu'il remplace conservés seulement jusqu'à ce que chaque verbe soit en production (conception).
Trois voies ou plus à la fois, une tâche qui dépasse une fenêtre de contexte, une attente sur la CI, une file d'attente, un apply ou un soak, ou un balayage sur de nombreuses unités indépendantes est un pilotage. Une investigation à voie unique est un sous-agent en mode direct, pas un pilotage.
Contenu
- Lisez le fichier pour votre tâche
- Le jugement d'abord
- Hooks et refus
- Les changements méta atterrissent dans la compétence
- Avant chaque appel d'outil
- Demandez le verbe, ne lisez jamais
- Les règles
- Phase 0 : les sessions permanentes
- Ce qui s'exécute sans le coordinateur
- Voies et bureaux
- Les surfaces du propriétaire
- Enregistrements et liste de tâches
- Démarrer et reprendre
- Ajouter une règle à cette compétence
Lisez le fichier pour votre tâche
Lisez uniquement la ligne que vous effectuez. Chaque fichier énonce ses règles en intégralité.
| Vous êtes | Lisez |
|---|---|
| Répondre au propriétaire : réponses, choix, reconceptions, son Slack et son tableau | communicator-brief.md |
| Rendre la mise à jour du propriétaire ou maintenir le tableau de bord | owner-report-table.md, drive-dashboard.md |
| Le coordinateur | coordinator-brief.md |
| La méta-voie ou son implémenteur | meta-lane-brief.md |
| La voie de signalisation ; la voie des tâches ménagères | signal-lane-brief.md; chores-lane-brief.md |
| Rédiger un brief de voie, ou travailler comme une voie ou un bureau sous un tel brief | orca-lane-brief.md |
| Faire tourner le contexte d'une voie ; un transfert ou une compaction | handoff-subagent-brief.md, compaction.md |
| Lancer ou relayer des travailleurs Orca, sur Mac ou sur Sprite | orca-desk-brief.md, orca-workers.md, orca-sprite-workers.md |
| Atterrir une PR, la file d'attente de fusion, D1 à D23 | landing.md, merge-train-brief.md |
| Noter une tête, un atterrissage ou un plan | grading-principles.md, finder-brief.md, finder-desk-brief.md, finder-desk-rows.md, fidelity-desk-brief.md, fidelity-job-brief.md, semantic-collisions-brief.md |
| Posséder un rouge sans propriétaire | red-sweep-brief.md |
| Une alerte ou un incident | active-alert-brief.md, alert-fix-brief.md, alerts-desk-brief.md, alert-evidence-brief.md, alert-comms-brief.md, unfixed-case-brief.md |
| Une version | release-lanes.md, manual-release-brief.md |
| Publier sur Slack | slack-lane-brief.md, comms-desk-brief.md |
| Publier ou lire des enregistrements cci, le bus de voie, les règles B | bus-contracts.md |
| Enregistrer ou appliquer une décision du propriétaire, le registre, les juges | owner-rulings.md |
| Vivacité des voies : pourquoi une voie ne peut pas devenir silencieuse, le superviseur et les surveillants | supervisor.md, watchers.md, drive-watchdog-brief.md |
| Le seul résultat numéro un ; jouer le propriétaire contre une surface | priority-desk-brief.md; user-test-brief.md |
| Démarrer un sous-pilotage | sub-drives.md |
| Lire un grand corpus dans des voies de correction | the bulk-read skill |
| Demander pourquoi une règle existe ; aucune voie n'en a besoin pour faire son travail | lessons.md |
Le jugement d'abord
- Aucune règle n'interdit de lire la seule ligne sur laquelle une décision repose.
- Un résultat en main est une correction, jamais une voie, une ré-audit ou un workflow.
- Lisez chaque phrase du propriétaire comme le ferait un collègue attentif. Une correction nomme un défaut dans la lecture, jamais une reconception de quelque chose sur lequel il a statué plus tôt ; lisez les lignes du registre sur ce sujet avant d'agir. Une répétition est un rapport de défaut concernant la première lecture : corrigez chaque endroit où elle a survécu, à ce tour.
Hooks et refus
- Les hooks avertissent. Ils bloquent uniquement sur la confiance : une fusion sans l'approbation du propriétaire, un changement de qui approuve les atterrissages, une annulation sans son mot, un runner ou un bureau démarré depuis le communicateur, une voie conduisant son navigateur connecté en production, des modifications aux fichiers de hook installés et aux gardes de protection de session. Un échec de lecture avertit seulement ;
tests/test_fail_open.pyl'applique et liste les exceptions, et le hook de permission Slack échoue ouvertement (slack-lane-brief.md). - Un hook qui rate sur votre travail obtient une voie de correction au tour où il vous bloque, et vous continuez à travailler sur ce qu'il ne bloque pas. Un refus qui est juste, comme la garde d'identité de production, n'en reçoit aucun. La session bloquée le lance, que ce soit voie, bureau, coordinateur ou communicateur, sans demande à
rootet sans méta-voie :lr launch lane hook-fix-<hook> opus high <brief> --drive <drive> --lane <you>, sauf silr lanes hook-fix-<hook>en montre une en vie. - Les hooks vivent dans
plugins/long-running/capt-hook/hooks/dans yasyf/cc-skills et danscaptain_hook/builtin_packs/dans yasyf/captain-hook, et chaque changement suitcaptain-hook:authoring-hooks, dont le lint et le test s'exécutent dans la CI de ce dépôt. La voie de correction corrige le vrai défaut du hook avec un test de régression, le livre, l'installe là où la session bloquée s'exécute, et sa preuve est l'appel refusé qui passe (orca-lane-brief.md). - Corriger n'est pas contourner : tant qu'un refus est en place, personne n'exécute la chose bloquée via un wrapper,
cc-sudoou un script. Les règles de sécurité du propriétaire restent telles qu'écrites : fusion, Slack, tests de charge et garde de processus. Un hook protégeant l'un d'eux qui rate voit son raté corrigé avec un test de régression, et la règle elle-même ne change que sur son mot. Le seul hook désactivé avant sa correction est celui qui bloque chaque arrêt du communicateur : commentez-le dans la source du pack avec un TODO nommant sa voie de correction, dans une PR fusionnée immédiatement, car une modification du cache installé ne dure que jusqu'à la prochaine installation, que ce Mac exécute en quelques minutes. - Un hook qui ne bloque rien et pourrait être amélioré va à la méta-voie comme un
cci post --kind note --to meta-desk. Tout autre refus d'outil va à la méta-voie au même tour et le travail se poursuit sur sa voie manuelle. Aucun refus n'est une excuse ou une question pour le propriétaire, pas plus que la plateforme : un enregistrement qui blâme un Sprite, un hôte ou un outil partagé pour une attente ou un échec nomme la voie corrigeant sa cause racine et l'horloge de cette correction, et sans une telle voie, il demande au coordinateur une à ce tour. Remplacer une machine est une solution provisoire et jamais la réponse.
Les changements méta atterrissent dans la compétence
La voie qui reçoit un changement méta globalement applicable, toute décision sur le fonctionnement des voies, des cartes, des attentes, des réponses, des hooks, du routage ou des réponses, l'envoie à la méta-voie au tour où elle arrive, comme un enregistrement cci. La méta-voie en fait toujours une mise à jour de cette compétence, ou du template de brief, du hook ou du document cc-notes qui la possède, fusionné et installé, réécrivant et refactorisant la section qu'elle touche afin que la compétence se lise comme une seule conception, jamais une ligne annexée brute. Un fichier mémoire ou un enregistrement est un pointeur et ne compte jamais comme fait.
Avant chaque appel d'outil
| Si l'appel est | Faites |
|---|---|
| Quelque chose qu'un verbe répond | Exécutez le verbe. |
| Un travail avec un corps | Créez la voie avec sa tâche et sa ligne de grand livre. |
| Une attente | Incorporez-la dans la voie qui agit. |
| Statut | Le communicateur envoie le rendu du bureau de mise à jour ; le coordinateur n'envoie rien. |
| Un message du propriétaire | Le communicateur crée un sous-agent pour celui-ci, qui répond sur la surface d'où il vient ; le coordinateur applique la décision partout ; une décision sur le fonctionnement du pilotage va à la méta-voie à ce tour, qui en fait une mise à jour de compétence. |
| Une alerte à laquelle le superviseur n'a pas répondu | lr incident run <slug> maintenant. |
| Un refus d'outil, ou quelque chose qui a mal tourné deux fois | Un hook bloquant votre travail obtient la voie de correction que vous lancez à ce tour (Hooks et refus) ; tout le reste va à la méta-voie à ce tour, où la correction est un verbe Go. Procédez de toute façon. |
| Une approbation, un maintien, un démarrage ou une annulation | L'ordre du propriétaire le porte ou une voie le possède. |
Agents terminés arrêtés, opérations de production journalisées, rien appelé fait qui n'est pas en vie et vérifié. Un appel qui survit à la liste décide quelque chose qu'aucun verbe et aucune voie ne peut décider. Tout le reste est une voie.
Demandez le verbe, ne lisez jamais
| Pour savoir | Exécutez |
|---|---|
| Est-ce qu'une voie est en vie, et qu'a-t-elle dit en dernier | lr lanes <lane> --config <lr.json> |
| Chaque voie, son état, ses PR et son devoir permanent | lr lanes |
| Ce qui s'est passé depuis son dernier regard | cci digest --drive <drive>, puis cci tail --drive <drive> --cursor root |
| Ce qui attend le propriétaire | cci owner-waits --drive <drive> |
| Quels sous-pilotages sont ouverts et ce que chacun détient encore | lr drive sub list |
| L'état des PR qu'il doit nommer | ccx vcs pr status <n1> <n2> ..., groupé |
| Quelles PR le propriétaire a approuvées sur le tableau, et lesquelles sont encore ouvertes | lr approved [--since <seq>], verdicts rétroactifs exclus |
| Chaque demande ouverte, et ce qui est atterri mais pas en vie | lr asks |
| La mise à jour du propriétaire, complète et à partir des sources | lr update render, exécuté par le update-desk du communicateur |
| Ce que fait un incident ; une phrase sur ce qu'il est | lr incident status <slug>; lr incident describe <slug> |
Où va le courrier d'une voie ; chaque verbe lr prend une tige, meta-desk, pour sa voie en vie la plus récente | lr route <lane> |
Une lecture que le tableau ne contient pas appartient à une voie : une PR, un journal CI, un thread Slack, un fichier long, un listing cloud, une page de build. Un diff, un plan ou un verdict que vous approuvez est à vous de lire. Le coordinateur crée un lecteur et récupère au plus cinq lignes ; une recherche est un appel, lr ask-lane '<question>'. Les hooks root_context et root_reads avertissent sur chaque lecture de ces types, sur une deuxième source ouverte pour une seule demande du propriétaire, et sur les enregistrements d'une voie canalisés via tail ou grep ; dans la fenêtre du communicateur, root_context refuse une recherche large et nomme lr ask-lane.
Les règles
Les identifiants sont stables ; les scripts, hooks et références les citent. root signifie le coordinateur sauf si la règle nomme le communicateur.
R1. La vérité terrain provient de la voie propriétaire ou du verbe, jamais d'un grep, d'un listing, d'un curl ou d'une page de build ; au plus cinq lignes en retour. L'état prioritaire des PR est lu en un seul appel groupé ccx vcs pr status.
R2. Tout ce qui a un corps est une voie : une lecture au-delà d'une fenêtre bornée, un journal, une investigation, les mécanismes de PR ou de fusion, une énumération. Une lecture bornée d'un fichier nommé, jusqu'à 150 lignes, est autorisée.
R3. Une voie par chaîne d'attente-puis-action, et aucune voie ne stationne : une voie attend sur un Monitor, une notification d'Agent, CronCreate pour une horloge, ou un appel lr wait, vers un état terminal, et fait rapport une fois. shell_waits bloque une boucle shell ou un veilleur. Le Monitor d'un bureau se réarme à l'expiration.
R4. Ne jamais re-briefer une voie, ne jamais répondre à un doublon. Un SendMessage vers un agent terminé réexécute son brief. lr wait marque le courrier imprimé comme lu.
R5. Écrivez-le, ne le retenez pas : les résultats vers cc-notes depuis la voie qui les a trouvés, les briefs comme pièces jointes sur le journal briefs: <slug>, rien fait à la main sous ~/.claude/scratch.
R6. Chaque demande du propriétaire est en vol au tour où elle arrive, une voie par demande, jamais annexée à la file d'attente d'une voie occupée. Une voie possède une PR par livrable et atterrit ses corrections comme des commits sur celle-ci ; orca-lane-brief.md dit quand elle les empile.
R7. L'état d'une PR est lu avant qu'il ne soit rapporté : ccx vcs status ou le commit squash sur le tronc récupéré, jamais un message ou une mémoire.
R8. Chaque demande du propriétaire est une ligne de grand livre au tour où elle arrive, et n'est faite qu'à LIVE ; avant cela, la réponse est "dans #N, pas encore en vie : <bloqueur>".
… [tronqué pour la traduction]