Le comptage brut de decisions actives est un signal grossier : un projet
actif a legitimement 12-15 decisions actives. La vraie dette v1/v2 a ete
traitee manuellement (8 decisions Sliding revisees + relations ~revise
vers la refonte v2). Le seuil a 20 garde un garde-fou contre une accumulation
anormale sans crier au loup sur des projets sains. La detection fine de dette
relevera de l'agent reviseur (etage 2).
Affinage revele par le traitement des anomalies : un historiqueItem (ex: la
panne du 12/07) ou une decision documente par un skill est une relation
legitime, pas un mesusage. La regle etait trop stricte. A terme, ces regles
domaine-portee doivent vivre dans un skill canonique lu par les agents avant
de tisser (backlog VPBRcJmPxkUC), pas seulement dans le Lint.
Durcit la convention de nommage des projets (dérive constatée : 'Sliding
Automation', 'code_versioning'... au lieu des formes canoniques).
- trilium_api.py : projets_canoniques() lit le référentiel = valeurs du label
projet sur les notes de type=projet (source unique, pas de constante en dur).
Note-projet CodeVersioning créée (manquait).
- mcp_server.py : _valider_projet() branché dans les 6 tools de création
(add_decision/history/backlog, new_conversation, create_entite, add_skill).
Refuse un projet non canonique (suggestion si faute) ou inconnu (renvoi au
processus de création de projet). Ne verrouille pas si référentiel illisible.
- lint_audit.py : VAL-nommage aligné sur le référentiel (attrape casse, espace
ET snake_case ; l'ancien 'contient un espace' ratait code_versioning).
- Données : 79 notes ré-étiquetées vers les 3 formes canoniques.
Quality by design : l'erreur de nommage devient impossible à l'écriture, le
Lint n'est plus que le filet de sécurité.
Master