Importar un backlog de Spec Kit en OrgGen

Ce que lit OrgGen : le `tasks.md` d’une fonctionnalité

OrgGen lit le fichier `tasks.md` que Spec Kit génère pour une fonctionnalité, tel quel — Spec Kit v1.1.0 (dépôt github/spec-kit, révision e1fa857, lue le 2026-10-03). Une ligne de tâche a la forme que Spec Kit documente : une case, un identifiant, des marqueurs facultatifs, une description.

- [ ] T006 [P] [US1] Create Album model in src/models/album.ts

Ton agent appelle `import_tasks` avec `format: "speckit-tasks"` et le contenu du fichier dans `text`. Pour plusieurs fonctionnalités, ou si le fichier ne porte pas la ligne « Design documents from /specs/<NNN-fonctionnalité>/ », précède chaque fichier de `=== FILE: specs/<NNN-fonctionnalité>/tasks.md ===`.

Ce que chaque élément devient

L’identité : `T001` n’est unique que par fonctionnalité

Spec Kit régénère son fichier : le numéro `T001` d'une fonctionnalité n'est pas celui d'une autre, et il peut changer quand le fichier est refait. L'identité d'une tâche importée est donc `<fonctionnalité>:T001`. Le dossier de la fonctionnalité vient du chemin que tu fournis, sinon de la ligne « Design documents from … » ; ni l'un ni l'autre, et le fichier est refusé plutôt que deviné.

• ›Un numéro qui revient avec un AUTRE titre n'écrase rien : il sort en conflit (`title-changed`) et la tâche existante reste telle quelle.
• ›Une tâche insérée au milieu décale tout ce qui suit : un numéro neuf dont le titre est celui d'une tâche existante sous un autre numéro sort en conflit (`renumbered`) au lieu d'être créé en double.
• ›Après une renumérotation, rien de ce qui est décalé n'est écrit : annule le lot (`rollback_import`, à blanc d'abord) puis réimporte le fichier, ou importe-le sous une autre `source`.

Le geste, dans l’ordre

1. Tu colles le `tasks.md` à ton agent — le chat d'OrgGen, ou un client MCP qui envoie une clé d'API.
2. Il appelle `import_tasks` avec `format: "speckit-tasks"`. 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 surtout les conflits et les erreurs.
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é de rejeu est `(source, identité)`. Recoller le même fichier ne crée rien.
• ›Avec `onExisting: "update"`, l'import réécrit les champs fournis d'une tâche déjà importée — seulement si personne ne l'a modifiée depuis ; sinon elle sort en conflit, jamais écrasée. C'est ainsi que la progression (les cases cochées) se propage, user stories comprises.
• ›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 — `tasks.md` n'en porte pas : la tâche cochée prend la date de l'import.

Ce qui ne se transporte pas

• ›Les sections hors tâches du fichier : « Dependencies & Execution Order », « Notes », les exemples de lancement en parallèle.
• ›Les dépendances écrites en prose dans la description d'une tâche : seules les phases et les user stories structurent.
• ›La fonctionnalité elle-même : ce n'est pas une tâche, elle se range dans un bloc (`cellRef` ou `cellId`).