docs(vigie): dedicated Gitea account for the vigie token
Evals au push — seules celles dont un fichier sensible est touché / tri (push) Successful in 14s
Evals au push — seules celles dont un fichier sensible est touché / evals (push) Skipped
CI / ci (push) Skipped
Revue — preuve d'approbation / revue-ok (pull_request_review) Successful in 9s
Gate — evals et acceptance réelles / revue (push) Successful in 8s
Gate — evals et acceptance réelles / evaluation (push) Successful in 4m54s
CD — Staging / build (push) Successful in 32s
CD — Staging / deploy (push) Successful in 34s
Evals au push — seules celles dont un fichier sensible est touché / tri (push) Successful in 14s
Evals au push — seules celles dont un fichier sensible est touché / evals (push) Skipped
CI / ci (push) Skipped
Revue — preuve d'approbation / revue-ok (pull_request_review) Successful in 9s
Gate — evals et acceptance réelles / revue (push) Successful in 8s
Gate — evals et acceptance réelles / evaluation (push) Successful in 4m54s
CD — Staging / build (push) Successful in 32s
CD — Staging / deploy (push) Successful in 34s
Mise en service de la vigie faite le 23/10 côté Gitea et serveur : compte dédié `vigie` (restreint, Écriture sur le seul dépôt qualicheck), jeton à la seule portée « tickets », secrets du dépôt, étiquette `simulation`, entrée DNS et bloc Caddy du sous-domaine. La procédure de mise en service le dit désormais.
This commit was merged in pull request #113.
This commit is contained in:
@@ -11,6 +11,7 @@ Format d'entrée, une ligne par réalisation :
|
||||
|
||||
## 2026-10-23 — Claude Code
|
||||
|
||||
- **Vigie mise en service côté Gitea et serveur** (carte #61, 23/10) : compte Gitea dédié `vigie` (restreint, collaborateur du seul dépôt `qualicheck` en Écriture, vérifié par l'API), son jeton à la seule portée « tickets » et les secrets du dépôt `VIGIE_GITEA_TOKEN` et `VIGIE_DESTINATAIRE` (choix du 23/10 entre ce compte, le compte principal et celui du relecteur : moindre privilège, la portée d'un jeton Gitea vaut pour tous les dépôts de son propriétaire) ; étiquette `simulation` créée (`incident` existait) ; entrée DNS `vigie.qualicheck.koabana.fr` et bloc Caddy posé par `maj_caddy_vigie.sh` (validation puis rechargement, certificat Let's Encrypt obtenu ; la page répond 502 tant que la vigie n'est pas déployée) ; l'override du serveur est identique à celui du dépôt au dernier déploiement, qui n'a gagné depuis que le service `vigie`. Restent le déploiement (gate), l'essai réel des alertes et la démo — voir `docs/exploitation.md` section 2, `docs/developpement/deploiement_staging.md`
|
||||
- **Vigie : une infobulle par signal sur la page « Santé du service »** (carte #61, demande du 23/10 après sa clôture, branche `feature/61-vigie-infobulles`) : pastille « i » après le nom de chaque signal des trois tableaux (19 lignes), dont l'infobulle dit en une phrase ce que mesure le signal ; textes dans la clé `description` de chaque signal de `app/observability/config.yml`, sans chiffre de seuil (la colonne Seuil les donne). Choix du 23/10 entre trois formes (attribut `title`, dépliant au clic, infobulle CSS) : infobulle en CSS seul (la page n'a pas de JavaScript, CSP), ouverte au survol de la cellule et au focus clavier de la pastille (cible de 24 px), lue par les lecteurs d'écran au focus (`aria-describedby`), ouverte au-dessus de la ligne pour ne pas être coupée par le défilement horizontal du tableau. Écart assumé : la touche Échap ne la ferme pas (RGAA 10.13, faute de JavaScript). L'état « Mesure » passe de l'icône `ℹ` à `–` pour ne pas répéter le « i ». Page élargie de 60 à 80 rem (demande du 23/10) : les cellules ne passent plus à la ligne sur un écran large. TDD (34 échecs initiaux constatés : champ `description` absent) ; 118 tests de la vigie verts ; vérifié dans Chromium par le protocole de débogage : bulle cachée au repos, ouverte au focus par Tab et au survol, gardée quand le pointeur passe dessus, fermée ailleurs ; captures à 1 100 et 375 px ; validateur W3C sans message (HTML et CSS) — voir `app/observability/vigie/page.py`, `app/observability/vigie/sante.css`, `conception/5_exploitation/vigie.md` section 6
|
||||
- **Vigie close après sa PR** (carte #61, brief 5) : PR #112 fusionnée sur `dev` le 23/10 en avance rapide (`cd73c556`, `revue-ok/cd73c55`), 27 commits ; au push, le tri n'a lancé que l'eval payante `reponse_juge_fidelite` (accord du 23/10), touchée par la fidélité posée sur le span du juge ; sans gate ni staging pour l'instant. Contrôle de la page avant la clôture (fiche, section 6) : validateur W3C sans message (HTML et CSS), langue, titre, titres hiérarchisés, tableaux légendés avec en-têtes de portée, état en icône et en mot, contrastes AA, ni script ni rafraîchissement ; la relecture humaine de la page en ligne reste à faire (section 10). Carte en Done (à relire), 3,7 h reconstituées depuis les commits en borne basse (conception du 22/10 non comptée, faute de trace), critères cochés sauf « alertes en état de marche », attendu de l'essai réel en staging (ticket et e-mail reçus, démo) ; C20 et C11 complétées sans changement d'état ; décisions ajoutées aux notes de l'oral (vigie dans le compose, moindre privilège, Langfuse en panne) — voir `jury/avancees_competences/C20.md`, `C11.md`, `jury/david.md`, `conception/agenda_actualise.md`
|
||||
- **Vigie de la carte #61 reprise en service du docker-compose** (même branche, 23/10) : la vigie passe du workflow planifié au service `vigie` du docker-compose (conteneur `qualicheck-vigie`, page « Santé du service » sur le port 8884, même en local qu'en staging), le déploiement lit l'override du dépôt (la copie du serveur reste pour les retours arrière), la démo devient le workflow manuel `vigie-demo.yml`, plus d'e-mail de secours de Gitea. Revue finale : le service ne reçoit que les variables qu'il lit (plus de `env_file`, moindre privilège), fichier provisoire de la page nommé d'après le processus (démo et boucle en parallèle), textes périmés corrigés. Limite écrite : si Langfuse est injoignable, le passage échoue sans alerte et la page vieillit — voir `docker-compose.yml`, `conception/5_exploitation/vigie.md` section 14, `docs/exploitation.md`
|
||||
|
||||
@@ -187,7 +187,7 @@ Le job `deploy` lit ceux-ci. Aucune valeur n'est écrite dans le dépôt.
|
||||
| `AZURE_AI_ENDPOINT`, `AZURE_AI_API_KEY` | accès au service de modèles |
|
||||
| `AZURE_MODEL_TEXT_EMBEDDING_SMALL`, `AZURE_MODEL_GPT_MINI`, `AZURE_MODEL_GPT`, `AZURE_MODEL_KIMI` | noms des déploiements de modèles |
|
||||
| `LANGFUSE_PUBLIC_KEY`, `LANGFUSE_SECRET_KEY`, `LANGFUSE_BASE_URL` | envoi des traces, recopiés du `.env` local |
|
||||
| `VIGIE_GITEA_TOKEN`, `VIGIE_DESTINATAIRE` | la vigie (carte #61) : jeton Gitea à portée « tickets » pour ouvrir les tickets d'incident, adresse qui reçoit les e-mails d'alerte. Absents : la vigie tourne à blanc, sans alerte |
|
||||
| `VIGIE_GITEA_TOKEN`, `VIGIE_DESTINATAIRE` | la vigie (carte #61) : jeton du compte Gitea dédié `vigie` (restreint, droit Écriture sur ce seul dépôt), à la seule portée « tickets », pour ouvrir les tickets d'incident (voir `docs/exploitation.md`, section 2), adresse qui reçoit les e-mails d'alerte. Absents : la vigie tourne à blanc, sans alerte |
|
||||
| `SMTP_HOTE`, `SMTP_PORT`, `SMTP_SECURITE`, `SMTP_UTILISATEUR`, `SMTP_MOT_DE_PASSE`, `SMTP_EXPEDITEUR` | relais des e-mails de fin d'analyse (D2, carte #107) : la messagerie du domaine, l'expéditeur étant l'adresse de contact ; jamais dans le `.env` d'un poste de développement (Mailpit y suffit). Sans eux, l'API vise Mailpit, absent du staging : l'envoi échoue, tracé, sans bloquer l'audit |
|
||||
|
||||
### 2. Préparer cloclo : sauvegarde, renommage, override, Caddy
|
||||
|
||||
+10
-3
@@ -29,9 +29,16 @@ la vigie : `conception/5_exploitation/vigie.md`.
|
||||
La vigie est un service du docker-compose : elle démarre avec le premier
|
||||
déploiement qui la contient. À faire **avant ce déploiement** :
|
||||
|
||||
1. Créer un jeton Gitea à portée « tickets » (`write:issue`) et les secrets
|
||||
du dépôt `VIGIE_GITEA_TOKEN` et `VIGIE_DESTINATAIRE` (les secrets
|
||||
`LANGFUSE_*`, `SMTP_*` et `DEPLOY_*` existent déjà).
|
||||
1. Créer le compte Gitea dédié `vigie`, **restreint** (il ne voit que les
|
||||
dépôts où on l'ajoute) et collaborateur du seul dépôt `qualicheck` avec
|
||||
le droit **Écriture** (la Lecture ouvre un ticket mais n'y pose pas
|
||||
d'étiquette). Connecté en `vigie`, créer son jeton à la seule portée
|
||||
« tickets » (`write:issue`) : il ne peut pas pousser de code, et la
|
||||
portée d'un jeton Gitea valant pour tous les dépôts de son propriétaire,
|
||||
un jeton du compte principal aurait pu écrire partout. Puis, connecté en
|
||||
administrateur du dépôt, les secrets du dépôt `VIGIE_GITEA_TOKEN` (ce
|
||||
jeton) et `VIGIE_DESTINATAIRE` (les secrets `LANGFUSE_*`, `SMTP_*` et
|
||||
`DEPLOY_*` existent déjà). Les tickets apparaissent signés `vigie`.
|
||||
2. Vérifier que les étiquettes `incident` et `simulation` existent dans le
|
||||
dépôt.
|
||||
3. Sur le serveur, deux gestes : l'entrée DNS `vigie.qualicheck.koabana.fr`
|
||||
|
||||
Reference in New Issue
Block a user