Deux hypothèses du code ne tiennent plus dès qu'on l'installe ailleurs que
dans son dépôt :
- la racine était déduite de l'emplacement du module. Une installation non
éditable la fait pointer vers site-packages, et le corpus de data/input/ est
alors cherché à côté du venv, où il n'est pas. VEILLE_RACINE lève
l'ambiguïté ; sans elle, le comportement d'avant est conservé.
- l'export JSON était figé sous data/, donc dans le répertoire d'installation.
Sur YunoHost celui-ci est effacé à chaque mise à jour. VEILLE_DUMP_JSON le
déplace avec la base et le cache.
Constaté en simulant l'installation, pas en relisant le code : VEILLE_DB était
honorée et VEILLE_DUMP_JSON ignorée, le dump repartant dans l'arbre des
sources.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- pyproject/uv sur Python 3.12, dépendances épinglées
- migrations versionnées (PRAGMA user_version) ; 001_initial pose textes,
sources, evenements, decisions_cc, insights, veille_log, veille_changements
- index FTS5 à contenu externe, tokenizer unicode61 remove_diacritics 2 :
« chlordecone » retrouve « chlordécone », highlight() disponible
- vue v_textes : devant_cc combine le statut et les affaires CC en instance,
ce qui réconcilie le §7 (Riposte reste adoptee_non_promulguee) et le §8.7
(la facette saisie_cc doit remonter ≥ 7 textes)
- modèles pydantic refusant les incohérences de statut : promulguée sans
numéro, navette avec numéro officiel, slug malformé
- Makefile, .env.example, journalisation structlog
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Cyber MawonajandClaude Opus 5