Importer un epic CCPM dans OrgGen
Chez CCPM, le chemin d'un fichier porte l'identité de la tâche : on colle chaque fichier sous son chemin, et c'est le chemin qu'OrgGen lit. Ce guide dit comment coller un epic, ce que chaque champ devient, et ce qui change d'identité quand CCPM renomme ses fichiers à la synchronisation.
Ce que lit OrgGen : les fichiers d’un epic
OrgGen lit le dossier d'un epic CCPM (`.claude/epics/<epic>/`) : `epic.md`, puis un fichier numéroté par tâche (`001.md`, `002.md`…). Révision lue : dépôt automazeio/ccpm, révision 7d7e462 (sans version publiée), lue le 2026-10-07 — d'après les schémas de frontmatter que ce dépôt publie, qui ne contient lui-même aucun epic réel.
Un epic tient en PLUSIEURS fichiers, et le chemin porte l'identité : tu colles chaque fichier précédé de son chemin, sur une ligne seule. Sans chemin, le lot est refusé.
=== FILE: .claude/epics/user-auth/epic.md ===
---
name: user-auth
status: in-progress
---
=== FILE: .claude/epics/user-auth/001.md ===
---
name: Create user table
status: closed
depends_on: []
parallel: true
---Ce que chaque champ devient
| Dans l’epic | Dans OrgGen |
|---|---|
| `epic.md` | une tâche PARENTE `<epic>/epic` — titre = `name`, statut (backlog → à faire, in-progress → en cours, completed → fait), corps = le Markdown |
| `001.md` | une sous-tâche `<epic>/1` — `name` en titre, statut (open → à faire, in-progress → en cours, closed → fait) |
| `depends_on: [001, 2]` | les dépendances de la tâche : `001`, `1` et `"001"` désignent la même tâche `<epic>/1` |
| `parallel: true` | l’étiquette `parallel` |
| `github` | le lien de la tâche, si c’est une URL (`(will be set on sync)` n’en est pas une) |
| `conflicts_with` | écrit en tête du corps (« Conflits avec : … ») — il n’a pas de logement propre |
| `## Effort Estimate` → `- Size: M` | la complexité de la tâche (XS à XL, en temps humain relatif) ; `- Hours: N` reste dans le corps |
L’identité suit le nom du fichier
L'identité d'une tâche est `<epic>/<numéro>`, lue dans le chemin. CCPM renomme `001.md` en `<numéro d'issue>.md` à la synchronisation GitHub, et réécrit `depends_on` en conséquence : un epic collé avant puis après la synchronisation est donc un AUTRE jeu d'identifiants.
Le geste, dans l’ordre
- Tu colles les fichiers de l'epic à ton agent, chacun sous son chemin — le chat d'OrgGen, ou un client MCP qui envoie une clé d'API.
- Il appelle `import_tasks` avec `format: "ccpm-epic"`. Par défaut c'est un calcul : le plan est rendu (créées, mises à jour, ignorées, conflits, erreurs) sans rien écrire.
- Ton agent a pour consigne de te montrer ce plan. Lis les notes : elles listent les fichiers ignorés et les tailles non reconnues.
- Rien ne s'écrit sans un second appel explicite, avec `dryRun: false` et le même lot. L'agent garde l'`importId` rendu.
- Un doute après coup : `list_imports` retrouve le lot, `rollback_import` l'annule — d'abord à blanc.
Rejouer, mettre à jour, annuler
- Rejouer ne duplique jamais : la clé de rejeu est `(source, <epic>/<numéro>)`. Recoller les mêmes fichiers ne crée rien.
- Avec `onExisting: "update"`, les statuts qui ont avancé sont réécrits — seulement si personne n'a modifié la tâche dans OrgGen depuis ; sinon elle sort en conflit, jamais écrasée.
- Annuler un lot supprime ce qu'il a créé et garde ce qu'un humain a modifié. Les mises à jour qu'il a faites ne sont pas restaurées.
- Une tâche terminée garde sa date d'achèvement quand l'export la porte — les fichiers d'un epic n'en portent pas : la tâche fermée prend la date de l'import.
Ce qui ne se transporte pas
- Les fichiers `…-analysis.md`, `github-mapping.md` et le dossier `updates/` : ignorés, et nommés dans les notes de la lecture.
- L'estimation en heures (`Hours`) : sans logement numérique, elle reste dans le corps de la tâche ; seule la taille (`Size`) devient une complexité.
- `conflicts_with` : écrit en tête du corps de la tâche, il n'est pas une relation entre tâches.
Essaie sur ton propre cas
Décris ta situation en une phrase — OrgGen construit le schéma et fait le calcul.
Essaie sur ton propre cas