Etage 1 de l'automatisation du Lint (backlog 8ETP6OyqToMR).
- wrapper d'exploitation, lint_audit.py reste un moteur pur en lecture seule
- tache DSM dimanche 21h00, utilisateur Master (pas root : moindre privilege,
le Lint lit Trilium via ETAPI localhost)
- sortie d'UNE ligne pour le mail DSM (total, bacs, dimensions, chemin rapport)
- mail a chaque run (pas seulement si anomalie) : le silence serait ambigu
entre 'rien a signaler' et 'la tache est morte' — anti confident-but-stale
- rotation 12 rapports (~3 mois), erreur explicite si venv absent, si le Lint
plante, ou si la synthese est illisible
Etage 2 de la strategie de backup : 3-2-1 complet.
- rclone v1.74.4 (ARM64) + remote 'proton' sur compte DEDIE bertha.cloud@proton.me
(cloisonnement : une fuite n expose pas le compte Proton principal)
- push apres verification d integrite, rotation distante alignee (30)
- l echec du push n echoue PAS le backup local : sortie offsite:OK(n)/KO,
visible dans l alerte mail DSM
- config rclone en 600 chez root (la tache DSM tourne en root)
Etage 1 de la strategie de backup (reco n1 de l audit). Copie coherente via
ETAPI (jamais de SQLite a chaud - le WAL faisait 4 Mo), sortie du dossier
Docker, verification d integrite avec suppression si KO, rotation 30, chmod 600.
Tache DSM quotidienne 03h00 en root (dossier backup en 700).
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.
Le commit precedent a embarque par accident venv.old-py38/ (ancien virtualenv
Python 3.8, vestige de la panne DSM du 12/07) et trilium_api.py.bak-attrid.
Un venv ne se versionne jamais. .gitignore durci : venv.old-py38/, venv*/,
*.bak-*. Fichiers desindexes (restent sur disque).
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é.
- trilium_api.py : remove_relation_safe (retrait via attributeId, idempotent),
move_relation_safe (reconnexion = add nouvelle puis remove ancienne, ordre sur)
- mcp_server.py : 2 tools MCP exposes (22 tools au total)
Comble le manque revele par la fusion render_engine.py : le systeme savait
creer une relation mais pas la retirer ni la reconnecter. Rend triviales les
corrections de mesusage et les fusions de hub. Teste de bout en bout.
Les rapports de Lint sont des artefacts de run (comme entites_*.json), pas du
code. Ils s'accumulent a chaque execution (surtout une fois le nocturne en
place). Ajoutes au .gitignore et desindexes (restent sur disque).
Comble le manque revele par le test Phase 3 : creation autonome d'entites de la
couche connaissance/technique, la ou seul le pilotage etait creable via MCP.
Tool generique cadre : type valide contre liste blanche, dossier resolu via
trilium_ids.json (pas d'ID en dur), garde-fou anti-doublon, definition posee
seulement pour les concepts. Passe le serveur a 20 tools. Teste de bout en bout.
get_note/update_note/delete_note/get_children : suppression du vocabulaire
'type systeme' perime. get_children liste tout (filtre retire), get_note lit
tout (garde-fou lecture retire), update/delete refusent les notes structurelles
sans label projet. Ferme la derniere trace de l ancien garde-fou dans le code.
limit passe a None par defaut (ETAPI renvoie tout ; un limit explicite plafonne
volontairement). Corrige un bug critique : tous les briefings (contexte, backlog,
decisions, historique, concepts) sous-estimaient le contenu des qu'une categorie
depassait 50 notes. 96 backlogItems reels contre 50 remontes. Cause-racine du
confident-but-stale. Revele en verifiant le backlog avant reprise.
Coherence avec entites_ids.json et entites_sliding.json (artefacts runtime
d'IDs, specifiques a l'instance, non versionnes). Ajoute au .gitignore et
desindexe (reste sur disque).
- api_context.py : ConceptCreate/Patch, routes /api/concepts, briefing 'Concepts'
- mcp_server.py : get_concepts (ex get_glossaire), tool_get_note garde-fou lecture retire
- redirige type=termeGlossaire vers type=concept partout (lecture, creation, briefing)
- section briefing filtree sur concepts ayant une definition (role lexical)
Corrige le 'glossaire vide' vu au test Phase 3 (code cherchait un type mort).
- _est_editable() dans trilium_api.py : editable si label projet ou type=projet
- tool_update_note + delete_note_safe utilisent ce critere
- tool_get_children : filtre TYPES_SYSTEME retire (transparence)
Corrige : composants techniques editables, get_children ne les masque plus.
Revele par le test Phase 3 (agent bloque sur edition de composant).
Master