--- name: "traitement-taches" description: "Protocole de traitement des tâches d'une note de réunion ou d'une revue de projet : extraction ACTION/RAPPEL/DÉCISION, rapprochement avec l'existant (verbe+objet+cible+responsable), verdicts IDENTIQUE/TERMINÉE/NOUVELLE/À CONFIRMER, rapport avant écriture obligatoire, anti-doublons." --- # Protocole : traitement des tâches d'une note Ce protocole régit toute création, mise à jour ou signalement de tâche issu d'une note de réunion (skill `synthese-reunion`) ou d'une revue de projet. Il s'applique **avant** de rédiger les sections « 4. Mes actions » et « 5. Suivi & autres actions ». ## Format canonical d'une tâche **Dans la note source** (formulation brute de GRK) : `GRK : Action à réaliser - A FAIRE` Le projet est déduit du contexte (note de réunion spécifique, ou titre de section pour les revues de projets). **Après traitement (sortie)** : ``` * [ ] [[03_PROJETS/CODE]] - @grk - Verbe + objet précis (cible/occurrence/source) [date: "AAAA-MM-DD"] # ``` * `[[03_PROJETS/CODE]]` : chemin complet du projet. **Le lien est le rattachement à privilégier** : c'est lui que lit `sb-tasks-open.sh` (nom de page ou lien `03_PROJETS/

`). L'attribut `[project:]` existe et serait indexé (cf. skill `silverbullet-conventions`) mais n'est utilisé par aucune tâche actuellement.
* `[date: "AAAA-MM-DD"]` : date de la tâche (“échéance” si à faire et date de réalisation, d'abandon, rappel, etc. selon le status de la tache).
* `#` : `#URGENT`, `#waiting`, `#aborted`, `#duplicate`, `#delegated`… 
* `* [ ]` = à faire, urgent ou waiting, `* [x]` = fait ou duplicate ou aborted. Les tâches des tiers (section 5 de la synthèse) restent **sans case à cocher**.
* **Un seul format** : aucune variante (`:` vs `-`, attributs supplémentaires) — toute variante crée des doublons à la requête.

### État déduit de la date (modèle unique, validé 2026-11-02)

Un seul attribut temporel : **`[date:]`**. L'état d'une tâche se déduit de `date × fait` :

| État | Condition | Où elle remonte |
|---|---|---|
| Non planifiée | `* [ ]` sans `[date:]` | backlog (dashboard ménage, `not t.date`) |
| Programmée | `[date:] > aujourd'hui` | page du jour concernée |
| Du jour | `[date:] == aujourd'hui` | pages jour (bloc à faire) |
| **Retard** | `[date:] < aujourd'hui` + non faite | widget rétroviseur (`hub.overdue()`) |
| Réalisée | `* [x]` + `[date:]` | bloc COMPLETED de la page jour |

* `[due:]` est **abandonné** : ne jamais l'utiliser (0 tâche dans l'espace, aucune requête ne le consomme depuis le 2026-11-02).
* Limite connue et acceptée : cocher ne met pas à jour la date — au report, **décaler `[date:]`**. C'est aussi ce qui fait remonter la tâche dans le bloc « du jour ».

## Étape 0 — cadrage

1. Identifier le ou les projets concernés. Chercher d'abord s'ils existent (requête SLIQ ou lien `[[03_PROJETS/...]]`), **y compris sous un éventuel doublon archivé** (`90_ARCHIVES/CLOS/` et `90_ARCHIVES/ABSORBES/`) ; si un projet clôturé porte le même code/domaine, **réhabiliter la page archivée** (la déplacer vers `03_PROJETS/` et passer `status: active`) **plutôt que d'en créer une nouvelle** ; **ne jamais créer de projet sans l'avis explicite de GRK**.
2. Lire la note en entier.

## Étape 1 — charger l'existant

Avant toute création, pour chaque projet identifié :

* **Tâches ouvertes** : script `sb-tasks-open.sh  [PAGE_SYNTHESE_EN_COURS]` (sortie JSON `[{page, name}]`), ou requête Lua équivalente (cf. skill `synthese-reunion` + `silverbullet-mcp`). **Toujours exclure la page en cours** pour ne pas se dédupliquer soi-même.
* **Tâches closes** : **rapprochement paresseux** — ne pas les précharger. Une requête ciblée sera lancée à l'étape 3, uniquement si un verdict penche vers NOUVELLE. *Motif : l'index n'expose aucune date de clôture (constaté le 2026-11-02) ; une fenêtre « 30 jours » sur `pageLastModified` (niveau page) donnerait un surcompte inutilisable.*

**Interdit de créer quoi que ce soit avant d'avoir exécuté cette étape.**

## Étape 2 — extraire les éléments de la note

Classer chaque élément :

* **ACTION** : quelqu'un doit faire quelque chose.
* **RAPPEL** : mention d'une tâche déjà connue (« on relance », « toujours en attente », « cf. réunion précédente », « comme convenu »…).
* **DÉCISION / INFO** : ne devient **jamais** une tâche (va dans la section « Décisions » / le corps de la synthèse).

Pour chaque ACTION ou RAPPEL, normaliser : **verbe / objet précis / cible ou occurrence / responsable / date éventuelle**, et **citer la phrase source**.

## Étape 3 — rapprochement avec l'existant

Comparer sur **verbe + objet + cible + responsable**. L'échéance/date n'est **pas** un critère d'identité.

| Verdict | Condition | Action |
|---|---|---|
| IDENTIQUE | Même verbe, objet, cible, responsable | Mettre à jour l'existant (date `[date:]`, statut) ; si l'échéance est repoussée, décaler `[date:]` |
| TERMINÉE | La note indique que c'est fait | Proposer de cocher la tâche existante (`* [x]`) |
| NOUVELLE | Aucune tâche existante ne correspond sur l'objet ou la cible | Créer avec tous les attributs |
| À CONFIRMER | Similarité partielle, cible ou responsable flou, RAPPEL non rattachable | **Ne rien faire**, poser la question à GRK |

**Requête paresseuse sur les closes** (uniquement si le verdict initial est NOUVELLE) :

```lua
local res = query[[
  from t = index.tasks()
  where t.done == true
  select { ref = t.ref, page = t.page, text = t.text }
]]
-- filtrer en Lua sur verbe + objet : t.text:find(objet, 1, true)
```

Si une close correspond → proposer **TERMINÉE** ou réouverture, jamais une création.

Règles de doute :

* Doute entre IDENTIQUE et NOUVELLE → **À CONFIRMER**.
* **Ne jamais fusionner** deux tâches existantes entre elles ; les signaler.
* Même cible mais responsable différent → **À CONFIRMER** (délégation ou doublon).
* Tâche liée à une occurrence passée (réunion tenue) dont l'objet n'a plus de sens → **proposer de l'annuler** avec motif, ne pas la reporter.

## Étape 4 — rapport avant écriture (obligatoire)

Produire systématiquement le tableau suivant, puis **s'arrêter là** : **aucune écriture sans validation explicite de GRK** — jamais de « applique » anticipé, y compris en confiance haute.

| Élément de la note (citation) | Verdict | Tâche concernée (`ref` = page@pos) | Modification proposée | Confiance |
|---|---|---|---|---|

* **Confiance haute** = citation exacte **et** correspondance littérale de verbe, objet, cible et responsable. Tout écart → confiance moyenne → À CONFIRMER.
* L'`id` de tâche est le champ `ref` de l'index (format `page@pos`) ou le lien `[[page]]` — le champ `taskID` n'est quasi jamais rempli (1 tâche sur 931, page démo).
* N'appliquer ensuite **que** les verdicts validés par GRK.

## Formats de sortie

* **Nouvelle action GRK** → case à cocher au format canonical (ci-dessus), dans « 4. Mes actions ».
* **Nouvelle action d'un tiers** → sans case à cocher, format « 5. Suivi & autres actions » du skill `synthese-reunion`.
* **RAPPEL / tâche existante** → **jamais** de case à cocher, puce au format :
  `* Suivi : [[03_PROJETS/CODE]] - @grk - Tâche - En cours (cf. [[PAGE]])`
  (`[[PAGE]]` = page issue du champ `page` de la requête).

## Garde-fous d'écriture

* Modifier une tâche existante = **uniquement sa ligne**, via l'API `/.fs` + `If-Match`, jamais réécrire la page entière.
* Toute réécriture du libellé d'une tâche existante doit être **signalée** dans le rapport d'étape 4.
* Exclure la page de synthèse en cours des requêtes (étape 1).
* L'index SilverBullet met quelques secondes à se rafraîchir après une écriture.

## Interdits

* Créer une tâche sans avoir exécuté l'étape 1.
* Supprimer une tâche (seulement la clore ou l'annuler, avec motif).
* Utiliser l'échéance comme seul critère de rapprochement.
* Réécrire le libellé d'une tâche existante sans le signaler.
* Écrire dans SilverBullet avant la validation du rapport d'étape 4.
* Créer un projet sans l'avis explicite de GRK.