ProjectFGame/.claude/skills/maintain-architecture-doc/SKILL.md

---
name: maintain-architecture-doc
description: Maintient Architecture_Projet.md (documentation de référence de l'architecture du projet ProjectF) synchronisé avec la structure réelle du projet. À utiliser avant et après toute création, suppression, déplacement ou renommage de fichier/dossier, ou toute évolution significative d'un système de gameplay.
---

# Maintenir `Architecture_Projet.md`

## Rôle de ce document

`Architecture_Projet.md` (à la racine du projet) est la **documentation de référence de l'architecture complète du projet ProjectF**, écrite en priorité pour des modèles d'IA. Il décrit l'arborescence complète du projet, le rôle de chaque dossier/fichier important, les dépendances entre systèmes et les conventions à respecter.

**Ce document n'a de valeur que s'il reste synchronisé avec l'état réel du projet.** Un `Architecture_Projet.md` obsolète est pire qu'utile : il fait perdre du temps et induit en erreur les futures sessions d'IA qui lui font confiance.

## Quand utiliser ce skill

Utilise ce skill (consultation et/ou mise à jour) dans les cas suivants :

1. **Avant** de modifier la structure du projet de façon un peu conséquente (créer un nouveau système, réorganiser un dossier, migrer des assets) : lis `Architecture_Projet.md` pour comprendre où les choses vivent actuellement et où ton changement doit s'insérer, en cohérence avec les conventions déjà en place (voir §1.4/§1.5 du document).
2. **Après** toute action qui change la structure du projet, notamment :
   - création d'un fichier ou dossier important (Blueprint, Widget, DataAsset, Struct, Enum, Input Action, système de gameplay…) ;
   - suppression d'un fichier ou dossier documenté ;
   - déplacement d'un fichier ou dossier documenté ;
   - renommage d'un fichier ou dossier documenté ;
   - évolution suffisamment importante d'un système existant (nouvelle responsabilité, nouveau fichier central, changement de dépendances entre systèmes).
3. Quand tu n'es pas sûr de savoir où se trouve un système ou un type de fichier avant de commencer une tâche — consulte le document plutôt que d'explorer le projet à l'aveugle.

Pour une petite modification purement interne à un Blueprint déjà documenté (ajouter une fonction, une variable, corriger un bug de logique) qui ne change ni son rôle général ni l'arborescence, une mise à jour du document n'est en général PAS nécessaire — sauf si la description existante du fichier devient trompeuse.

## Comment mettre à jour le document

1. **Localise la bonne section.** Le document est organisé par grande zone (`§3 Content/Core/`, `§4 Content/Systems/`, `§5 Content/Data/`, `§6 Content/UI/`, `§7 Items/PCG/Maps/VFX/Prop`, `§8 assets tiers`). Trouve la section correspondant au dossier concerné avant d'éditer — ne duplique pas une entrée dans plusieurs sections.

2. **Fichier créé** → ajoute une ligne dans l'arborescence du dossier concerné, avec une description courte (une phrase, orientée "à quoi ça sert" / "quel rôle" — pas une paraphrase du nom de fichier). Suis le format déjà utilisé :
   ```text
   ├── NomDuFichier.uasset       → Rôle en une phrase.
   ```
   Si le fichier crée un nouveau sous-système notable, ajoute-le aussi à la vue de dépendances (§1.3) si pertinent.

3. **Fichier/dossier supprimé** → retire entièrement son entrée. Ne laisse jamais une ligne qui référence un chemin qui n'existe plus. Si sa suppression change une dépendance décrite en §1.3, corrige aussi cette section.

4. **Fichier/dossier déplacé ou renommé** → corrige le chemin (et le nom) à l'endroit où il apparaît. S'il change de section logique (ex. un Blueprint qui quitte `Systems/Inventory/` pour un nouveau dossier `Systems/Crafting/`), déplace aussi son entrée dans la bonne section du document, pas seulement son chemin.

5. **Nouveau système de gameplay** (nouveau dossier sous `Content/Systems/<Nom>/` ou équivalent) → crée une nouvelle sous-section dans `§4` (ou une nouvelle section de premier niveau si le système est majeur), avec :
   - la liste de ses fichiers importants et leur rôle ;
   - ses dépendances avec les autres systèmes, ajoutées à `§1.3` si le système interagit avec l'inventaire, les stats, ou le personnage.

6. **Évolution significative d'un système existant** → mets à jour sa description pour refléter son rôle actuel. Ne laisse pas une description qui décrit un comportement qui n'existe plus.

7. **Nouveau dossier d'assets tiers volumineux** (Marketplace, Fab, packs d'animation…) → ajoute-le en `§8` avec une description sommaire d'une ligne, SANS lister ses fichiers individuellement (voir règle de détail ci-dessous).

## Règle de niveau de détail

- Un fichier "important" à documenter individuellement = il porte de la **logique ou des données de gameplay** propres au projet (Blueprint, Widget, ActorComponent, DataAsset, Struct, Enum, Input Action, GameMode/PlayerController, système PCG…).
- Un fichier purement artistique (texture, mesh, clip d'animation individuel, matériau de variante, miniature) n'a **pas** besoin d'entrée dédiée : il suffit que son dossier parent soit listé et décrit brièvement. Ne gonfle pas le document en énumérant chaque texture d'un pack d'assets.
- Un dossier d'assets tiers volumineux (Marketplace, Megascans, packs de mocap) est décrit en une ligne (`§8`), pas détaillé fichier par fichier.

## Vérification de cohérence

Avant de terminer une tâche qui a touché à la structure du projet, vérifie que :

- chaque chemin mentionné dans `Architecture_Projet.md` correspondant à ta zone de travail existe toujours réellement (pas de faux positif après un déplacement/renommage que tu aurais oublié de répercuter) ;
- les nouveaux fichiers importants que tu as créés apparaissent bien dans le document, avec une description ;
- les fichiers que tu as supprimés n'apparaissent plus nulle part dans le document (y compris dans `§1.3` Dépendances et dans les tableaux de conventions si applicable) ;
- si tu as un doute sur l'exhaustivité, un simple `find <dossier> -type f` (ou `Glob`) suffit à comparer rapidement la réalité du dossier concerné avec ce que le document décrit — inutile de ré-auditer tout le projet à chaque fois, seulement la zone que tu viens de modifier.

## Ce qu'il ne faut jamais faire

- Ne jamais terminer une tâche qui a modifié la structure du projet (création/suppression/déplacement/renommage de fichier ou dossier important, nouveau système) sans avoir mis à jour `Architecture_Projet.md` en conséquence.
- Ne jamais laisser une description qui ne correspond plus à la réalité "parce que ce n'est pas grave" — un document d'architecture légèrement faux est plus dangereux qu'un document incomplet mais honnête.
- Ne jamais dupliquer une entrée dans deux sections différentes du document après un déplacement (supprime l'ancienne en ajoutant la nouvelle).