andrea-steva/personal-agents-skills

Récapitulatif de tâche

Chaque tâche terminée se termine par un récapitulatif : le dernier élément de la réponse, après tous les appels d'outils. Il indique au lecteur en dix secondes ce qui est maintenant vrai, comment nous le savons, et ce qui reste à faire. C'est un résumé, pas un journal de session.

Si le projet actuel possède sa propre compétence task-recap, suivez celle-ci à la place : elle reprend les noms de vérifications et les conventions du projet.

Modèle

### <status> <Titre : ce qui est maintenant vrai, ≤ 8 mots>

<Une ou deux phrases : le résultat et pourquoi il est important. Pas de narration du processus.>

**Modifications**
- [`Fichier.ext`](chemin/vers/Fichier.ext) — ce qui a changé, en quelques mots
- [`Autre.ext`](chemin/vers/Autre.ext:42) — …

**Vérifications** · `build ✓` · `tests 14/14 ✓` · `lint ✓`

**Suite** — <l'élément ouvert, la décision ou le suivi>

Glyphe de statut

Un seul glyphe, dans le titre uniquement :

Glyphe	Signification
✅	Fait et vérifié
⚠️	Fait, mais quelque chose n'est pas vérifié ou une vérification a échoué
⛔	Bloqué : impossible de terminer (indiquez pourquoi dans le résumé)
🔎	Investigation ou question répondue, aucun code modifié

Sections

• Titre — le résultat, pas l'activité : "Les résultats de recherche conservent leur ordre", pas "Correction du bug dans SearchService".
• Résumé — une ou deux phrases. Nommez d'abord l'effet visible par l'utilisateur, puis la cause ou l'approche si elle n'est pas évidente.
• Modifications — une puce par fichier ou groupe logique, au maximum 6 ; regroupez les autres ("+ 4 traductions dans Localizable.xcstrings"). Les fichiers sont des liens Markdown relatifs au répertoire de travail, avec :ligne lorsqu'un emplacement précis est important. Omettez la section quand rien n'a changé.
• Vérifications — une ligne de badges en code en ligne, uniquement pour ce qui a été réellement exécuté dans cette tâche, nommés d'après les outils du projet :
  • build ✓ / build ✗, tests N/M ✓, ui ✓ (tests UI ou de bout en bout), lint ✓, types ✓ (vérificateur de types), changelog ✓, plus toute vérification que les instructions du projet exigent (par exemple une vérification de traduction).
  • Une vérification qui s'applique mais n'a pas été exécutée est écrite build – et mentionnée dans Suite ou le résumé. Ne marquez jamais ✓ ce qui n'a pas été exécuté.
  • Omettez la ligne pour les tâches uniquement de documentation ou d'investigation.
• Suite — une ligne : la décision en attente de l'utilisateur, le suivi, ou l'état de git (non commité sur main, PR ouverte). Omettez quand rien n'est en attente.

Règles

• Concis : 4 à 12 lignes au total. Si plus est nécessaire, la liste des modifications est trop détaillée ; regroupez-la.
• Honnête : un test qui échoue ou une étape ignorée est indiqué clairement avec ⚠️, jamais caché.
• Pas de narration : pas de "J'ai d'abord regardé…, puis…". Pas de reformulation de la demande. Pas de formules de politesse de conclusion ou de "dites-moi si…".
• Pas de blocs de code sauf si l'utilisateur doit exécuter une commande ; dans ce cas, un bloc bash avec une commande, placé après Suite.
• Markdown simple uniquement : un titre ###, des étiquettes en gras, des puces, du code en ligne. Pas de tableaux, pas d'emoji supplémentaires, pas de règles horizontales.
• Rédigez dans la langue utilisée par l'utilisateur ; conservez les noms de fichiers, le code et les étiquettes de badges en anglais.
• Référencez les PRs et issues sous forme de liens complets ([owner/repo#94](https://github.com/owner/repo/pull/94)), jamais un simple #94.
• Dans l'application de bureau Claude, le récapitulatif est le message de clôture écrit après l'appel wrap_up ; il ne répète pas la question affichée dans la boîte de l'étape suivante.

Exemples

Une fonctionnalité :

### ✅ L'écran de profil affiche la date d'inscription

Chaque profil montre désormais quand l'utilisateur a rejoint, sous le nom, formaté selon la locale de l'utilisateur.

**Modifications**
- [`ProfileHeader.swift`](Sources/Profile/ProfileHeader.swift) — étiquette de date d'inscription
- [`Localizable.xcstrings`](Sources/Profile/Resources/Localizable.xcstrings) — chaîne `Joined %@`
- [`CHANGELOG.md`](CHANGELOG.md) — entrée sous Unreleased

**Vérifications** · `build ✓` · `tests 32/32 ✓` · `lint ✓`

**Suite** — non commité sur `feature/profile-join-date` ; prêt à ouvrir la PR.

Un résultat partiel :

### ⚠️ La progression de téléversement survit à la mise en arrière-plan

La progression est désormais dérivée des octets que le serveur a accusés réception plutôt que d'un compteur local, donc elle reste correcte après la suspension de l'application.

**Modifications**
- [`UploadViewModel.swift`](Sources/Upload/UploadViewModel.swift:58) — progression lue depuis `acknowledgedBytes`

**Vérifications** · `build ✓` · `tests 11/12 ✗` · `lint ✓`

**Suite** — `testPauseResume` attend toujours l'ancien compteur ; le mettre à jour ou conserver l'ancien comportement de pause ?

Une investigation :

### 🔎 Le tableau de bord rame car le cache sauvegarde tard

Le tableau de bord lit le cache avant que la sauvegarde en arrière-plan ne se termine, donc il affiche les données précédentes jusqu'au prochain rafraîchissement.

**Suite** — corriger en rafraîchissant après la fin de la sauvegarde dans `SyncService` ; le faire ici ?