# Cpn Async

> À utiliser quand vous répartissez un travail multi-unités en parallèle sur workspaces jj isolés et PR en stack pour console cloud-pi-native.

- Skill: `shikanime-labs/cpn-async` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add shikanime-labs/cpn-async`
- Raw SKILL.md: https://api.skillmd.com/api/skills/shikanime-labs/cpn-async/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- License: Apache-2.0
- Author: shikanime-labs (https://skillmd.com/u/shikanime-labs)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/shikanime-labs/cpn-async

---


# CPN Org — Flux parallèles

Fan-out parallèle sur workspaces jj isolés + PR indépendantes (`gh pr`). Base
`cpn-dev-workflow`.

## When to Use

- Modif décomposable en units indépendants.
- Agents parallèles (`delegate_task`) sans copie partagée.
- Dépendances : B←A → depth (stack) ; C←A+B → join (multi-parents).

## Modèle : DAG, jj exécuteur

- **Fan-out** : enfants d'un commit trunk = units indépendants.
- **Depth** : enfant d'un enfant = unit dépendante ; chaîne racine→feuille =
  CHAÎNE, 1 PR par lien (land en ordre de dépendance).
- **Join** : enfant de plusieurs parents (`jj new <a> <b>`) = dépend de
  plusieurs flux ; land après.
- **Isolation** : chaque flux dans son PROPRE workspace jj (copie + commit
  séparés, même dépôt/graphe) ; conflit évité par construction.
- **Test d'indépendance** : indépendant ssi fichiers disjoints des siblings ET
  n'importe aucun de leur NOUVEAU code ; sinon depth ou join (merge).

## Procedure

1. **Arbre avant le travail** : décompose contre le ledger de l'issue ; écris
   l'arbre (trunk, units, arêtes) dans plan/`todo` avec les gates par feuille
   AVANT tout fan-out.
2. **Fan-out** : TOUJOURS nouveau workspace jj nommé `<repo-name>.<unit>` :

   ```bash
   jj workspace add ../<repo-name>.<unit> --name <repo-name>.<unit>
   ```

   Commit de copie = enfant du `@` courant ; depth > 1 → `jj new <parent>`.
3. **Travaille chaque flux** dans son workspace ; commit via `cpn-commit`
   (conventionnel, signé SSH). Trailer
   `Co-authored-by: Automata <automata@shikanime.studio>` si applicable.
4. **Land** — push `origin`, PRs draft avec `--head cloud-pi-native:<branch>` ;
   voir `cpn-dev-workflow` / `cpn-pr`) : exécuter d'abord la vérification
   doublon / pile de `cpn-pr` (étape 1b) — PR existante couvrant l'unité =
   pousser dessus ou empiler, jamais une seconde PR pour le même changement.
   - Unit indépendant → bookmark propre + PR standalone (ou stack mono-membre).
   - Chaîne dépendante → un bookmark par lien, puis :

     ```bash
     jj bookmark set <next> -r <next>
     gh pr create --repo cloud-pi-native/console --base main \
       --head "cloud-pi-native:<next>"
     ```

   - Liaison PR↔issue via `cpn-pr` : `Refs #N` par défaut.
5. **Vérifie bottom-up** : chaque feuille lance ses checks DANS son workspace ;
   le dispatcher re-vérifie via `terminal` (un sous-agent qui dit « done » n'est
   pas une preuve). Fin : `jj workspace forget <name>` ; à la traîne :
   `jj workspace update-stale`.

## Fan-out via delegate_task

Chaque enfant reçoit : chemin du workspace, gates de l'unit, forme du commit
(conventionnel + trailer Automata). Le parent re-vérifie chaque gate via
`terminal` dans chaque workspace avant de déclarer terminé. Un task par feuille
; le `goal` porte le contrat. **NE VER fusionner deux feuilles dans un seul
`goal`.** Exemple : `references/delegate_task.md`.

## Pitfalls

- **Units pseudo-indépendants** (fichiers qui se chevauchent) → conflits au join
  ; corrige la décomposition, pas le conflit.
- **Workspaces partagent le dépôt** — bookmarks/graphe GLOBAUX : 1 bookmark par
  unit, jamais 2 flux sur 1 bookmark.
- **Fan-out avant les contrats** — enfants sans gates reproduit la défaillance
  d'enforcement que les gates empêchent.

## Verification

```bash
jj workspace list && jj log -r 'all()' --limit 20
gh pr list --state open          # une PR par feuille
```

DAG = arbre planifié ; chaque feuille a une PR liée ; chaque gate a une preuve
in-workspace.

## See also

- `cpn-dev-workflow` — parent ; gate de validation d'hypothèses AVANT le
  fan-out.
- `cpn-commit` / `cpn-pr` — forme du commit (trailer Automata) et liaison PR.
- `sks-async` — jumeau shikanime (plain-English).