Import a BMAD sprint tracker into OrgGen

Ce que lit OrgGen : `sprint-status.yaml`

OrgGen lit le fichier `sprint-status.yaml` que le workflow de planification de sprint de BMAD génère et que les workflows de build et de rétrospective mettent à jour — BMAD v6.12.1 (dépôt bmad-code-org/BMAD-METHOD, lu le 2026-10-07). Il lit la clé `development_status` et, s'il existe, `action_items`.

development_status:
  epic-1: in-progress
  1-1-user-authentication: done
  2-6a-split-story: backlog
  epic-1-retrospective: optional

Les deux voies d’import

Les deux voies mènent au même plan, au même rejeu et à la même annulation. Elles diffèrent par ce qu'OrgGen lit, et par l'endroit où les tâches se rangent.

• ›Voie 1 — le fichier est lu tel quel. Pour : `sprint-status.yaml`. Ton agent appelle `import_tasks` avec `format: "bmad-sprint-status"` et le fichier dans `text`. Les tâches se rangent dans UN bloc d’accueil, désigné par `cellRef` ou `cellId` ; les épiques deviennent des tâches parentes, avec leur statut. Un fichier mal formé est refusé, nommé, et rien n'est écrit.
• ›Voie 2 — le format d'OrgGen. Pour : tout autre suivi, `stories.yaml` compris, ou un fichier que tu as converti. Ton agent extrait et mappe lui-même, puis appelle `import_tasks` avec `items` (ressource `orggen://import/pivot`). Un bloc par item : chaque item porte son propre `cellRef`. Un item invalide est refusé, nommé, avec ceux qui le référencent ; rien n'est écrit pour lui.

`stories.yaml` (l'étape optionnelle de BMAD, sans statut) et `tickets.toml` ne sont pas lus par OrgGen : ils passent par la seconde voie.

Ce que chaque clé devient

Les statuts hérités de la v6, que BMAD normalise lui-même à chaque lecture, sont normalisés de la même façon : `drafted` est lu comme `ready-for-dev` et `contexted` comme `in-progress`, pour les épiques comme pour les stories. La valeur lue est déclarée dans les notes du plan, jamais transformée en silence.

Le geste, dans l’ordre

1. Tu colles le `sprint-status.yaml` à ton agent — le chat d'OrgGen, ou un client MCP qui envoie une clé d'API — et tu désignes le bloc d'accueil.
2. Il appelle `import_tasks` avec `format: "bmad-sprint-status"`. Par défaut c'est un calcul : le plan est rendu (créées, mises à jour, ignorées, conflits, erreurs) sans rien écrire.
3. Ton agent a pour consigne de te montrer ce plan. Lis les notes : elles disent ce qui a été lu sans être importé.
4. Rien ne s'écrit sans un second appel explicite, avec `dryRun: false` et le même lot. L'agent garde l'`importId` rendu.
5. 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é d'une story EST son identifiant externe, stable tant que la story n'est pas renommée. Recoller le fichier après une session de travail ne crée que ce qui est neuf.
• ›Avec `onExisting: "update"`, les statuts qui ont avancé dans BMAD 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 — `sprint-status.yaml` n'en porte pas : la tâche faite prend la date de l'import.

Ce qui ne se transporte pas

• ›Les métadonnées du fichier (`project`, `story_location`…) et toute clé de premier niveau non reconnue.
• ›Le contenu des fichiers de story (`docs/stories/*.md`) : le titre d'une story vient de sa clé, jamais d'un fichier.
• ›Tout autre fichier de suivi BMAD que `sprint-status.yaml` : seul celui-ci est lu, le reste passe par le format d'OrgGen.