qbarev/para-plugin

Projets

Les projets sont des efforts avec un objectif défini et un état final — contrairement aux Domaines, qui sont continus. Un projet est un dossier dans le vault associé à un projet dans le backend de tâches : le dossier contient ce que le projet signifie, le backend contient ses tâches (tasks.md). Chaque appel de tâche est une opération depuis tasks.md, exécutée selon l'adaptateur pour TASKS.

Couche de base

À lire avant d'agir, chacun comme ../../para/<fichier>.md relatif au répertoire de base de cette compétence — ils contiennent les règles partagées, ne les répétez pas de mémoire :

• ../../para/paths.md — toujours, y compris « Langue » : les chaînes ci-dessous proviennent de lang/<LANGUE>.md
• ../../para/tasks.md — toujours : les opérations, l'appariement, ce qu'est une tâche
• ../../para/find-target.md — pour overview et task
• ../../para/note-format.md — pour create ; pour chaque sous-commande, « Champs hérités »
• ../../para/project-id.md — pour create
• ../../para/dod.md — pour create (rédaction de la section project.dod) et overview
• ../../para/thresholds.md — pour list et overview : ordre des projets, obsolescence, horizons, compteurs de tâches, taille de la sortie
• ../../para/confirm.md — create et task écrivent (Niveau 1) ; list et overview n'écrivent rien
• ../../para/move.md — pour create, avant d'écrire un dossier qui pourrait entrer en collision

Sous-commandes

Le premier mot de $ARGUMENTS choisit la sous-commande : list, create, overview, task. S'il n'en fait pas partie, déduisez laquelle est voulue d'après la formulation et dites laquelle vous avez choisie. $ARGUMENTS vide → exécutez list, puis demandez quoi faire.

Chaque sous-commande rencontre des projets qui précèdent le backend de tâches : status, Tasks/ (note-format.md précise quand c'est hérité), pas de champ tasks_ref. Lisez-les comme le dit note-format.md « Champs hérités » — signalez, ne réécrivez jamais.

---\n

create <description> — démarrer un projet

Entrée : ce qu'est le projet, son objectif, sa date limite, les premières étapes. Vide → demandez ce qu'est le projet et son objectif.

1. Lisez Templates/Project.md depuis le disque, textuellement.

2. Dérivez un titre selon note-format.md. Il est utilisé de trois façons : comme title et le H1 sans le préfixe d'identifiant, et — avec le préfixe — comme nom du dossier et nom du fichier d'aperçu. Proposez short selon note-format.md.

3. Émettez l'identifiant selon project-id.md.

4. Créez la structure de dossiers sous Projects/ :

   PROJ-xxxx <titre>/
   ├── PROJ-xxxx <titre>.md      ← aperçu, depuis Templates/Project.md
   ├── Notes/
   ├── Resources/
   └── Results/
   

   Les trois sous-dossiers, même vides. Pas de Tasks/ (sous TASKS = files, l'adaptateur le crée avec la première tâche).

5. Remplissez le frontmatter selon la ligne Projet dans note-format.md. created est aujourd'hui. deadline seulement si la description en donne une. tasks_ref reste vide jusqu'à l'étape 7 (sous pairing: none, le champ est omis).

6. Remplissez le corps :

   • la section project.goal — l'objectif / l'état final souhaité. Obligatoire.
   • la section project.value — ce que l'utilisateur gagne, mesurable ou non ambigu (note-format.md, « Trois sections sur le résultat »). Obligatoire. Si l'une ou l'autre de project.goal n'est pas claire d'après l'entrée, demandez les deux en une question (confirm.md, Niveau 1.5) avant d'écrire.
   • la section project.problem — ce qui a motivé le projet.
   • la section project.expected_result — les artefacts concrets et où ils se trouvent.
   • la section project.scope — uniquement les éléments nommés par l'utilisateur. Généralement vide : la tâche de recherche la remplit (tasks.md « La tâche de recherche »).
   • la section project.dod — cases à cocher selon dod.md. Si la description ne permet pas d'en déduire de vraies vérifications, demandez — comme pour un project.goal manquant.
   • la section common.links — wikiliens vers des notes clairement liées, sinon le - du modèle.

7. Créez la paire selon tasks.md « Appariement » : project.create avec le titre et l'identifiant. Sous pairing: separate, écrivez le ref retourné dans tasks_ref: ; si l'appel échoue, dites-le : le dossier reste, non apparié, et /projects task proposera de l'apparier plus tard. Sous pairing: none, il n'y a pas de paire et pas de tasks_ref : sautez l'écriture.

8. Premières tâches dans le nouveau projet, sans dates :

   • la tâche de recherche selon tasks.md « La tâche de recherche », toujours, sauf si l'utilisateur a déjà nommé le périmètre complet — alors écrivez-la dans la section project.scope à la place ;
   • les étapes nommées explicitement par l'utilisateur, ajoutées avec task.add et formulées selon « Ce qu'est une tâche ». Une étape qui ne peut pas être formulée comme une action est une question pour la recherche, pas une tâche.

   N'inventez jamais d'étapes que l'utilisateur n'a pas nommées.

9. Signalez le chemin du dossier, l'identifiant, le titre, short (en proposant de le modifier), la date limite, l'objectif, la ligne de valeur, le nom du projet backend et les tâches créées.

Si l'entrée décrit une responsabilité continue sans fin, ce n'est pas un projet — dites-le et proposez /areas create à la place. S'il s'agit d'une idée que l'utilisateur n'a pas décidé de prendre en charge, dites que ce n'est pas encore un projet (tasks.md « Appariement ») et proposez de le laisser dans la boîte de réception (inbox.name).

---

task <projet> <tâche> — ajouter une tâche

1. Trouvez le projet selon find-target.md, opération « Ajouter une tâche à un projet ». La cible peut également être un projet de domaine depuis AREA_TASK_PROJECTS dans areas.md — faites correspondre par nom.
2. Résolvez où elle va : un projet de domaine → area ; sinon le tasks_ref de l'aperçu → project_ref (sous pairing: none, le dossier du projet est le ref et cette étape est simplement le projet).
   • pairing: separate et pas de tasks_ref sur l'aperçu → dites la chaîne task.unpaired et proposez de la créer (étape 7 de create). Si oui, créez la paire, puis continuez. N'écrivez jamais la tâche dans le vault à la place.
3. Formulez la tâche selon tasks.md « Ce qu'est une tâche ». Si la formulation de l'utilisateur convient déjà, gardez-la ; sinon proposez la version reformulée dans l'annonce. Si elle ne peut pas être une action, demandez l'étape suivante (Niveau 1.5).
4. task.add avec project_ref ou area (sous TASKS = files, un nom de base pris est une collision : note-format.md « Collisions de noms », demandez, pas de suffixe silencieux) : le texte, une description pour tout ce qui est plus long, duration seulement si donné. La règle de date est tasks.md « Champs ».
5. Signalez la tâche et le projet.

---

overview <projet> — où en est le projet

Lecture seule. N'écrit rien — ni dans le vault, ni dans le backend. Si le résumé révèle quelque chose qui mérite d'être corrigé, dites-le et laissez l'utilisateur décider.

1. Trouvez le projet selon find-target.md, opération « Faire un rapport sur ». Sans argument, listez les projets et demandez.

2. Lisez la note d'aperçu : le frontmatter et les sections project.goal, project.value, project.expected_result, project.dod, common.links. Un champ vide est signalé comme vide, jamais rempli par inférence.

3. Lisez les tâches (task.list, ouvertes) : leurs dates et durées. Calculez les comptes selon thresholds.md « Comptes de tâches ». Sous pairing: separate, pas de paire → sautez, et dites la chaîne task.unpaired.

4. Lisez Notes/ (et Results/, s'il contient quelque chose) en entier, jusqu'à la limite dans thresholds.md — c'est là que se trouvent réellement les décisions et les risques.

5. Héritage. Si l'aperçu porte status / priority / value / estimate, ou le dossier a un Tasks/ hérité (note-format.md), ajoutez une ligne, la chaîne overview.legacy avec {fields} comme status, Tasks/ (3 fichiers) (le compte du dossier est la chaîne overview.legacy_tasks), en nommant uniquement ce qui est présent. Ne lisez pas les notes de tâches pour la progression ; la migration décide ce qui survit.

6. Signaux — ne signalez que ceux qui se déclenchent :

   • la deadline du projet passée, ou à l'intérieur de l'horizon dans thresholds.md ;
   • les tâches en retard — dites de combien de jours ;
   • rien de planifié alors que la date limite est dans l'horizon ;
   • les tâches datées sans durée ;
   • silence plus long que le seuil du projet dans thresholds.md, mesuré comme il le dit (project.activity quand apparié, mtime sinon, selon thresholds.md) ;
   • les wikiliens pendants dans la section common.links ;
   • chaque critère d'acceptation coché alors que le projet est encore dans Projects/ — terminé et non clos.

7. Rendez dans le chat, dans LANGUE. Les étiquettes sont les chaînes de lang/<LANGUE>.md, nommées dans le modèle ci-dessous par clé entre accolades ; affichées ici avec les chaînes anglaises :

   ## PROJ-0001 · Projet A
   
   **{overview.area}** Domaine A · **{overview.deadline}** 2026-10-31 — 14 jours
   **{overview.tasks}** {count.scheduled} 3 · {count.overdue} 1 · {count.backlog} 6
   **{overview.acceptance}** ☑☐☐ 1/3
   
   ### {overview.essence}
   <L'objectif, 1–2 phrases.>
   <Le résultat attendu — une ligne.>
   <La valeur — une ligne.>
   
   ### {overview.scheduled}
   - **Écrire un email au fournisseur** — mar 21-10, 30 min
   - **Remplir le formulaire** — en retard de 2 jours, 1 h
   
   ### {overview.backlog}
   - Prendre rendez-vous
   - …et 3 de plus
   
   ### {overview.digest}
   - <Une décision ou conclusion clé de Notes/ — dans vos propres mots.>
   
   ### {overview.signals}
   - Date limite dans 14 jours, rien de planifié
   

   Les accolades sont des clés, pas du texte littéral : imprimez la chaîne que chaque clé représente. Les dates sont au format common.date (2026-10-31 ; 10-31 dans la forme courte common.date_short, utilisée avec un jour de semaine de common.weekdays sur une ligne de tâche) ; les jours jusqu'à la date limite sont common.days ; les abréviations d'unité sont common.unit.* ; une tâche en retard porte la chaîne task.overdue_by ; la queue du backlog est la chaîne overview.backlog_more ({n} = tâches non affichées). La section overview.backlog montre les tâches les plus anciennes sans date jusqu'à la limite dans thresholds.md. Supprimez toute section ou champ qui serait vide. Un Results/ vide est un état normal.

---

list — les projets

Lecture seule. Une ligne par projet — l'index, pas un résumé : n'ouvre jamais Notes/.

1. Énumérez les dossiers directement sous Projects/. Les projets archivés ne sont pas listés — c'est /archive list.

2. Lisez le frontmatter de l'aperçu : id, title, area, deadline, et sous pairing: separate tasks_ref. Un dossier sans frontmatter est pré-convention — imprimez-le par nom de dossier avec la chaîne common.no_metadata.

3. Lisez les tâches de chaque projet qui a un ref (task.list avec project_ref, ouvertes), comptées selon thresholds.md « Comptes de tâches ».

4. Ordonnez selon thresholds.md « Ordre des projets ».

5. Rendez, dans LANGUE, avec les chaînes list.*, count.* et task.unpaired — la ligne est serrée, donc le nombre de backlog est count.backlog_short (en-tête list.header, date limite list.until avec la date en common.date_short et, à l'intérieur de l'horizon de thresholds.md, (14 j) après : les jours restants et common.unit.day) ; affiché ici avec les chaînes anglaises :

   **Projets (4)**
   1. PROJ-0008 Projet A — Domaine A · until 10-31 (14 j) · planifié 2 · backlog 3
   2. PROJ-0020 Projet B — until 10-31 (14 j) · planifié 0 · backlog 3
   3. PROJ-0009 Projet C — Domaine B · until 02-28 · pas de paire dans le gestionnaire de tâches · ancien format
   4. PROJ-0027 Projet D — backlog vide
   Pas de paire dans le vault : « Projet E »
   

   • Une date limite passée : la chaîne list.deadline_passed.
   • La chaîne list.legacy lorsque des champs hérités sont présents, ou un Tasks/ hérité existe.
   • Un projet dont le backlog est vide : la chaîne list.backlog_empty.
   • La dernière ligne (list.orphans) nomme les projets backend qu'aucun aperçu ne pointe, trouvés comme tasks.md « Notes sur la table », project.list, dit. Supprimez-la quand elle est vide ou lorsque l'adaptateur ne supporte pas project.list.
   • Supprimez tout champ vide plutôt que d'imprimer un espace réservé. Un Projects/ vide est une réponse valide : dites-le clairement.

Projets archivés et pré-convention

Les projets dans Archive/ peuvent précéder les conventions : pas de frontmatter, pas de préfixe PROJ-xxxx, pas de sous-dossiers. Lisez la section project.goal de la note, sautez la section des tâches et overview.acceptance, et indiquez clairement qu'il est archivé et dans l'ancien format.

Notes

• Calculez, n'estimez pas : les comptes de jours, de tâches et les retards proviennent du backend, des fichiers et de la date système d'aujourd'hui. Si quelque chose ne peut pas être calculé parce qu'un champ est vide, dites qu'il est vide plutôt que de deviner.
• Un résumé fait état de la situation ; il ne juge pas l'utilisateur. « en retard de 5 jours », pas « vous avez abandonné le projet ».
• Tout dans LANGUE, tâches comprises.