instagram-file.json — la file Instagram passe dans la base du service d'état #1685

Merged

hermes-fusion merged 5 commits from hermes/migration-instagram-sqlite into main 2026-10-15 21:05:04 +02:00

Conversation 10 Commits 5 Files changed 15 +470 -15

hermes-bot commented 2026-10-15 00:16:47 +02:00

Collaborator

• Copy link
• Copy Markdown

Goal — migrer /opt/studio/instagram-file.json vers SQLite, avec bascule et retour arrière (carte t_23952e31, recette de STUD-1107).

Ce qui change

• etat_partage.sql : table instagram_file — une ligne par Reel, rang pour garder l'ordre de la LISTE, un champ par colonne (chaine, compte, n, etat, quand, titre), pas de colonne fourre-tout JSON. quand est NULL ou vérifié deux fois (motif + strftime('%Y-%m-%d %H:%M', quand) IS quand) ; bascules.nom n'est plus une liste fermée mais un motif.
• etat_partage.py : instagram_lire, instagram_remplacer (tout ou rien ; maj gardée si rien ne change), entree_instagram (champ inconnu REFUSÉ, n entier exigé), _reparer_bascules.
• _infra/etat-service.py : GET /instagram, POST /instagram/remplacer.
• etat_client.py : instagram(), instagram_remplacer(), en_service(nom), basculer instagram-file [--essai], revenir instagram-file, instagram <fichier> ; chemin réglé par $INSTAGRAM_FILE (défaut /opt/studio/instagram-file.json). Pas de verrou de montage : ce fichier n'a rien à voir avec le montage, et les montages tournent en continu.
• _tableau/socle.py : la famille d'accès au service d'état — ETAT_URL, ETAT_DELAI, _reponse_etat, en_service(nom), lire_instagram(chemin, defaut) (base dès que la bascule est posée, sinon le fichier par lire_json ; un objet là où la file est une LISTE rend le défaut). Elle vit dans le socle et pas dans tb_commun.py : celui-ci porte le rendu et ne lit aucun fichier (son en-tête et celui du socle, mergés ce soir par #1611/#1617). Les trois lecteurs de la page (onglet_reseaux.py, tableau-bord.py, accueil_donnees.py) passent par socle.lire_instagram ; tb_commun.FILE_INSTAGRAM ne bouge pas.
• _reseaux/pousser-tableau.sh : la file entre dans la base à chaque passage quand la bascule est posée (rien d'autre n'est touché : le fichier reseaux-file et son push restent ceux de main).
• Bancs : controle/test_etat_partage.py (ok 9a/9b) et _tableau/test_onglet_reseaux.py (cas 10 : la base sert, le fichier ne sert plus ; service injoignable + fichier absent → vide ET c'est dit ; hors /opt/studio et sans STUDIO_ETAT_URL, le service de production n'est jamais appelé).

Ce que je n'ai pas fait

• Aucun déploiement, aucune bascule posée : basculer/revenir restent des gestes de l'opérateur.
• _reseaux/instagram-file.py n'est pas modifié : il écrit toujours _tableau/instagram-file.json, et c'est pousser-tableau.sh qui verse la file dans la base (c'est la recette de la carte reseaux-file, t_b914b746).
• instagram-file.json continue d'être poussé au 132 même basculé : le service Rust y lit file_ig pour /api/accueil (rust/service/src/main.rs, entree_accueil). Supprimer la copie demande de porter ce lecteur — hors de cette carte.
• Aucune route /api/... touchée : rien à changer côté front Svelte.

hotspot: etat_partage.sql / etat_partage.py / etat_client.py — les douze cartes de migration écrivent dans ces trois fichiers (dont hermes/migration-reseaux-sqlite, PR #1682, ouverte). La seconde fusion aura à rebaser sur bascules.nom, NOMS et les routes du service.

---

Bancs (python3 _tableau/lancer-tests.py --tout, tête 1c9eb948) : 168 ok, 1 rouge, cliquet de couverture rouge. Mesurés identiques sur main (e7886778, copie de travail intacte) : 165 ok, _tableau/test_accueil_parite.py rouge (« le JSON doré n'est plus la sortie de Python », clés courbes, fin_seuil, seuil_heures_apres, monetisation — donc venu de #1680/#1636, pas d'ici), et le même cliquet (cœur 99.1 % < 99.4 %, ensemble 96.5 % < 99.0 % sur main contre 96.6 % sur cette branche, qui ajoute donc des lignes couvertes). Ni l'un ni l'autre ne fait partie de la CI.

Preuve de bout en bout (vrai service HTTP sur une base jetable, vraie base SQLite, vrais lecteurs, sans doublure) : bascule --essai → « 1 entrées, IDENTIQUES dans la base du service », bascule posée, ancien gardé en .bak-sqlite-2026-10-15 ; le fichier renommé, lire_instagram rend le Reel de la base ; l'onglet Instagram rendu porte le titre de la base ; une écriture dans la base puis revenir rend un fichier identique octet pour octet à celui du producteur et retire la bascule.

CI — tête 1c9eb948 (voir la section suivante) : la tâche Rust est verte (cargo test --release --locked + cargo build --release --locked, aucun avertissement) ; la tâche Front est rouge pour une panne de main — reproduction sur main intacte : npx vitest run → 1 failed | 195 passed, tests/stockage.test.js (« attendu : 4 volumes suivis, 2 en alerte, relevé à / reçu : … relevé hier à 22 h 44 », le banc dépend du jour où il tourne). La même tâche échoue sur main (run 281) et sur deux autres branches dans la même heure (runs 288, 289) ; elle est verte sur hermes/banc-stockage-date (runs 290, 291), dont le correctif est en revue : PR #1688 (t_d6daf667), ouverte, en attente de relu. Cette branche ne touche à aucun fichier de _tableau/front/ : dès que #1688 est fusionnée, un rebasage sur main suffit à faire passer la tâche Front.

**Goal** — migrer `/opt/studio/instagram-file.json` vers SQLite, avec bascule et retour arrière (carte `t_23952e31`, recette de STUD-1107). **Ce qui change** - `etat_partage.sql` : table `instagram_file` — une ligne par Reel, `rang` pour garder l'ordre de la LISTE, un champ par colonne (`chaine`, `compte`, `n`, `etat`, `quand`, `titre`), pas de colonne fourre-tout JSON. `quand` est NULL ou vérifié deux fois (motif + `strftime('%Y-%m-%d %H:%M', quand) IS quand`) ; `bascules.nom` n'est plus une liste fermée mais un motif. - `etat_partage.py` : `instagram_lire`, `instagram_remplacer` (tout ou rien ; `maj` gardée si rien ne change), `entree_instagram` (champ inconnu REFUSÉ, `n` entier exigé), `_reparer_bascules`. - `_infra/etat-service.py` : `GET /instagram`, `POST /instagram/remplacer`. - `etat_client.py` : `instagram()`, `instagram_remplacer()`, `en_service(nom)`, `basculer instagram-file [--essai]`, `revenir instagram-file`, `instagram <fichier>` ; chemin réglé par `$INSTAGRAM_FILE` (défaut `/opt/studio/instagram-file.json`). Pas de verrou de montage : ce fichier n'a rien à voir avec le montage, et les montages tournent en continu. - `_tableau/socle.py` : la famille d'**accès au service d'état** — `ETAT_URL`, `ETAT_DELAI`, `_reponse_etat`, `en_service(nom)`, `lire_instagram(chemin, defaut)` (base dès que la bascule est posée, sinon le fichier par `lire_json` ; un objet là où la file est une LISTE rend le défaut). Elle vit dans le socle et **pas dans `tb_commun.py`** : celui-ci porte le rendu et ne lit aucun fichier (son en-tête et celui du socle, mergés ce soir par #1611/#1617). Les trois lecteurs de la page (`onglet_reseaux.py`, `tableau-bord.py`, `accueil_donnees.py`) passent par `socle.lire_instagram` ; `tb_commun.FILE_INSTAGRAM` ne bouge pas. - `_reseaux/pousser-tableau.sh` : la file entre dans la base à chaque passage quand la bascule est posée (rien d'autre n'est touché : le fichier `reseaux-file` et son push restent ceux de `main`). - Bancs : `controle/test_etat_partage.py` (ok 9a/9b) et `_tableau/test_onglet_reseaux.py` (cas 10 : la base sert, le fichier ne sert plus ; service injoignable + fichier absent → vide ET c'est dit ; hors `/opt/studio` et sans `STUDIO_ETAT_URL`, le service de production n'est jamais appelé). **Ce que je n'ai pas fait** - Aucun déploiement, aucune bascule posée : `basculer`/`revenir` restent des gestes de l'opérateur. - `_reseaux/instagram-file.py` n'est pas modifié : il écrit toujours `_tableau/instagram-file.json`, et c'est `pousser-tableau.sh` qui verse la file dans la base (c'est la recette de la carte `reseaux-file`, `t_b914b746`). - `instagram-file.json` continue d'être poussé au 132 même basculé : le service Rust y lit `file_ig` pour `/api/accueil` (`rust/service/src/main.rs`, `entree_accueil`). Supprimer la copie demande de porter ce lecteur — hors de cette carte. - Aucune route `/api/...` touchée : rien à changer côté front Svelte. **hotspot: `etat_partage.sql` / `etat_partage.py` / `etat_client.py`** — les douze cartes de migration écrivent dans ces trois fichiers (dont `hermes/migration-reseaux-sqlite`, PR #1682, ouverte). La seconde fusion aura à rebaser sur `bascules.nom`, `NOMS` et les routes du service. --- **Bancs** (`python3 _tableau/lancer-tests.py --tout`, tête `1c9eb948`) : **168 ok, 1 rouge, cliquet de couverture rouge**. Mesurés **identiques sur `main`** (`e7886778`, copie de travail intacte) : 165 ok, `_tableau/test_accueil_parite.py` rouge (« le JSON doré n'est plus la sortie de Python », clés `courbes`, `fin_seuil`, `seuil_heures_apres`, `monetisation` — donc venu de #1680/#1636, pas d'ici), et le même cliquet (`cœur 99.1 % < 99.4 %`, `ensemble 96.5 % < 99.0 %` sur `main` contre `96.6 %` sur cette branche, qui ajoute donc des lignes couvertes). Ni l'un ni l'autre ne fait partie de la CI. **Preuve de bout en bout** (vrai service HTTP sur une base jetable, vraie base SQLite, vrais lecteurs, sans doublure) : bascule `--essai` → « 1 entrées, IDENTIQUES dans la base du service », bascule posée, ancien gardé en `.bak-sqlite-2026-10-15` ; le fichier renommé, `lire_instagram` rend le Reel de la base ; l'onglet Instagram rendu porte le titre de la base ; une écriture dans la base puis `revenir` rend un fichier identique octet pour octet à celui du producteur et retire la bascule. **CI** — tête `1c9eb948` (voir la section suivante) : la tâche **Rust est verte** (`cargo test --release --locked` + `cargo build --release --locked`, aucun avertissement) ; la tâche **Front est rouge pour une panne de `main`** — reproduction sur `main` intacte : `npx vitest run` → `1 failed | 195 passed`, `tests/stockage.test.js` (« attendu : `4 volumes suivis, 2 en alerte, relevé à ` / reçu : `… relevé hier à 22 h 44` », le banc dépend du jour où il tourne). La même tâche échoue sur `main` (run 281) et sur deux autres branches dans la même heure (runs 288, 289) ; elle est verte sur `hermes/banc-stockage-date` (runs 290, 291), dont le correctif est en revue : PR #1688 (`t_d6daf667`), ouverte, en attente de `relu`. Cette branche ne touche à aucun fichier de `_tableau/front/` : dès que #1688 est fusionnée, un rebasage sur `main` suffit à faire passer la tâche Front.

hermes-bot added 1 commit 2026-10-15 00:16:47 +02:00

La file Instagram passe dans la base du service d'état (migration instagram-file) ... ed2ca385a8

Cause : `/opt/studio/instagram-file.json` était un fichier d'état de plus, réécrit en
entier par `_reseaux/instagram-file.py` et recopié au 132 par `pousser-tableau.sh` : un
écrivain et trois lecteurs qui se partagent un fichier sans transaction.

Remède : une table `instagram_file` dans `etat_partage.sql` (une ligne par Reel, `rang`
pour l'ordre du fichier, un champ par colonne, `quand` NULL ou AAAA-MM-JJ HH:MM vérifié
deux fois), `instagram_lire`/`instagram_remplacer` dans `etat_partage.py`, les routes
`GET /instagram` et `POST /instagram/remplacer` du service, `instagram()`/
`instagram_remplacer()` et la bascule `instagram-file` (`--essai`, `.bak-sqlite-<date>`,
`revenir` en une commande) dans `etat_client.py`. Les lecteurs de la page du tableau
(`onglet_reseaux.py`, `tableau-bord.py`, `accueil_donnees.py`) passent par
`tb_commun.lire_instagram`, qui lit la base dès que la bascule est posée et le fichier
sinon ; `pousser-tableau.sh` verse la file dans la base à chaque passage.

`bascules.nom` n'est plus une liste fermée de noms mais un motif : SQLite ne modifie pas
un CHECK, et une base ouverte avant ce changement refusait le nouveau nom. La bascule ne
prend pas le verrou de montage (les montages tournent en continu), et le JSON continue
d'être poussé au 132 : le service Rust y lit `file_ig` pour `/api/accueil`.

hermes-fusion added the

ci-rouge

label 2026-10-15 00:20:03 +02:00

hermes-fusion commented 2026-10-15 00:20:03 +02:00

Collaborator

• Copy link
• Copy Markdown

fusion-auto : pas de fusion, la CI est rouge (Front Svelte). Le chef de l'atelier renvoie la carte à l'agent ; l'étiquette tombera d'elle-même une fois corrigé.

`fusion-auto` : pas de fusion, la CI est rouge (Front Svelte). Le chef de l'atelier renvoie la carte à l'agent ; l'étiquette tombera d'elle-même une fois corrigé.

hermes-bot force-pushed hermes/migration-instagram-sqlite from ed2ca385a8 to 6086157479 2026-10-15 00:32:44 +02:00 Compare

hermes-fusion added

conflit

and removed

ci-rouge

labels 2026-10-15 00:35:02 +02:00

hermes-fusion commented 2026-10-15 00:40:03 +02:00

Collaborator

• Copy link
• Copy Markdown

fusion-auto : pas de fusion, la PR est en conflit avec main : à rebaser. Le chef de l'atelier renvoie la carte à l'agent ; l'étiquette tombera d'elle-même une fois corrigé.

`fusion-auto` : pas de fusion, la PR est en conflit avec main : à rebaser. Le chef de l'atelier renvoie la carte à l'agent ; l'étiquette tombera d'elle-même une fois corrigé.

hermes-fusion added the

ci-rouge

label 2026-10-15 00:45:03 +02:00

hermes-fusion commented 2026-10-15 00:45:03 +02:00

Collaborator

• Copy link
• Copy Markdown

fusion-auto : pas de fusion, la CI est rouge (Front Svelte). Le chef de l'atelier renvoie la carte à l'agent ; l'étiquette tombera d'elle-même une fois corrigé.

`fusion-auto` : pas de fusion, la CI est rouge (Front Svelte). Le chef de l'atelier renvoie la carte à l'agent ; l'étiquette tombera d'elle-même une fois corrigé.

hermes-bot force-pushed hermes/migration-instagram-sqlite from 6086157479 to 5b7a0c6801 2026-10-15 00:45:51 +02:00 Compare

hermes-bot force-pushed hermes/migration-instagram-sqlite from 5b7a0c6801 to 4099bfabcc 2026-10-15 00:49:37 +02:00 Compare

hermes-fusion removed the

ci-rouge

conflit

labels 2026-10-15 00:50:03 +02:00

hermes-bot force-pushed hermes/migration-instagram-sqlite from 4099bfabcc to 1c9eb948ff 2026-10-15 00:50:40 +02:00 Compare

hermes-fusion added the

ci-rouge

label 2026-10-15 00:55:03 +02:00

hermes-fusion commented 2026-10-15 00:55:03 +02:00

Collaborator

• Copy link
• Copy Markdown

fusion-auto : pas de fusion, la CI est rouge (Front Svelte). Le chef de l'atelier renvoie la carte à l'agent ; l'étiquette tombera d'elle-même une fois corrigé.

`fusion-auto` : pas de fusion, la CI est rouge (Front Svelte). Le chef de l'atelier renvoie la carte à l'agent ; l'étiquette tombera d'elle-même une fois corrigé.

hermes-bot commented 2026-10-15 01:22:57 +02:00

Author

Collaborator

• Copy link
• Copy Markdown

Relecture — t_27c861ed, carte du relecteur.

Verdict : RELU, CONFORME. Étiquette relu posée.

Mesures (toutes rejouées par moi, sur la tête 1c9eb948, base main ae760c38) :

• Périmètre. git diff --stat origin/main...HEAD : 14 fichiers, 544 insertions, 15 suppressions,
  aucun fichier de _tableau/front/, rien de 01-textes/ à 07-publication/, aucun binaire,
  aucun secret, aucun emoji dans les lignes ajoutées. La branche contient origin/main.

• Bout en bout, service d'état HTTP RÉEL + base SQLite RÉELLE (jetables) sur la VRAIE file
  _tableau/instagram-file.json (33 entrées) : essai → « 33 entrées dans le JSON, 33 dans une base
  jetable, IDENTIQUES » (code 0) ; bascule → base identique, .bak-sqlite-2026-10-15 gardé, fichier
  renommé ; socle.lire_instagram rend les 33 entrées alors que le fichier est absent (la page lit
  la base) ; revenir instagram-file → fichier rendu IDENTIQUE octet pour octet à l'original
  (7 018 octets, sha256 c7d36713…), ligne de bascule retirée.

• Onglet Instagram, même code de rendu, 33 entrées réelles servies du fichier puis de la base :
  HTML IDENTIQUE (4 281 octets des deux côtés). Aucune fonction visible retirée, aucun onglet écrasé.

• Contrainte bascules refaite : sans _reparer_bascules, l'insertion de « instagram-file » dans une
  base d'avant le 2026-10-14 sort en CHECK constraint failed: nom IN ('sorties','file_montage') ;
  avec, elle passe. Le banc 9b garde donc bien ce qu'il annonce.

• Bornes du schéma mesurées : titre de 501 refusé, 500 accepté ; etat vide ou de 201 refusé ;
  n = 0 refusé ; « 2026-10-20 25:00 » refusé ; quand NULL accepté.

• controle/test_etat_partage.py : TOUT PASSE (ok 1 à ok 9b, dont 9a et 9b) ;
  _tableau/test_onglet_reseaux.py : OK (cas 10 inclus).

• Bancs officiels (python3 _tableau/lancer-tests.py --tout) : 168 ok, 1 rouge
  (_tableau/test_accueil_parite.py, JSON doré de l'Accueil), cliquet baissé (cœur 99,1 % < 99,4 %,
  ensemble 96,6 % < 99,0 %). Témoin sur origin/main ae760c38 SANS la branche : 168 ok, le MÊME
  rouge, cliquet baissé (cœur 99,1 % < 99,4 %, ensemble 96,7 % < 99,0 %). Les deux sont antérieurs à
  cette branche.

• Rust : cargo test --release --locked = 77 essais dans 13 binaires, 0 échec ;
  cargo build --release --locked après recompilation réelle : aucune sortie d'avertissement.
  npx vite build : code 0.

• CI : Rust verte (push 35 s, PR 33 s). Front rouge en 11 s — c'est le banc de main, pas de cette
  branche : npx vitest run sur origin/main donne le même unique échec
  (tests/stockage.test.js, « relevé à » attendu contre « relevé hier à 22 h 44 »), et avec le diff
  de cette branche appliqué sur main à jour (ae760c38, qui porte le correctif #1688 fusionné à
  01 h 10) npx vitest run rend 27 fichiers / 200 essais TOUS VERTS. Il faut donc rebaser la branche
  (ou relancer la CI) pour que la tâche Front repasse au vert ; sans cela fusion-auto la refusera
  sur ce seul motif.

Deux points à savoir, qui ne s'opposent pas à la fusion :

1. Chemin de pousse. _reseaux/pousser-tableau.sh (set -euo pipefail) écrit la file dans la base
   dès que la bascule est posée, avant de pousser au 132 : une entrée refusée par le schéma (titre
   au-delà de 500, etat vide, heure impossible) fait sortir etat_client.py instagram en 1 et
   arrête le script avant la pousse des deux JSON et la régénération de la page. L'échec est dit
   (message + code 1), mais une seule entrée hors bornes prive le 132 de la mise à jour. La file
   réelle est aujourd'hui dans les bornes (titre le plus long 93, etat 9, n de 1 à 19, aucun
   quand nul). Je n'ai pas lancé pousser-tableau.sh (il déploie) : ce point est lu, pas mesuré de
   bout en bout.

2. Production. Le service d'état (192.168.1.142:8799) est injoignable depuis le PC en ce moment
   (No route to host, mesuré) : la bascule de production n'est donc pas faite et la page du 132 lit
   encore le JSON — rien à moitié appliqué. La suite : fusion, réinstallation du service (la route
   GET /instagram n'existe pas encore sur le service en place), puis basculer instagram-file.
   À l'ouverture suivante, _reparer_bascules refait la table bascules de la base de production
   (main() du service appelle ouvrir() avant d'écouter).

Relecture — t_27c861ed, carte du relecteur. Verdict : RELU, CONFORME. Étiquette `relu` posée. Mesures (toutes rejouées par moi, sur la tête 1c9eb948, base main `ae760c38`) : - Périmètre. `git diff --stat origin/main...HEAD` : 14 fichiers, 544 insertions, 15 suppressions, aucun fichier de `_tableau/front/`, rien de `01-textes/` à `07-publication/`, aucun binaire, aucun secret, aucun emoji dans les lignes ajoutées. La branche contient `origin/main`. - Bout en bout, service d'état HTTP RÉEL + base SQLite RÉELLE (jetables) sur la VRAIE file `_tableau/instagram-file.json` (33 entrées) : essai → « 33 entrées dans le JSON, 33 dans une base jetable, IDENTIQUES » (code 0) ; bascule → base identique, `.bak-sqlite-2026-10-15` gardé, fichier renommé ; `socle.lire_instagram` rend les 33 entrées alors que le fichier est absent (la page lit la base) ; `revenir instagram-file` → fichier rendu IDENTIQUE octet pour octet à l'original (7 018 octets, sha256 c7d36713…), ligne de bascule retirée. - Onglet Instagram, même code de rendu, 33 entrées réelles servies du fichier puis de la base : HTML IDENTIQUE (4 281 octets des deux côtés). Aucune fonction visible retirée, aucun onglet écrasé. - Contrainte `bascules` refaite : sans `_reparer_bascules`, l'insertion de « instagram-file » dans une base d'avant le 2026-10-14 sort en `CHECK constraint failed: nom IN ('sorties','file_montage')` ; avec, elle passe. Le banc 9b garde donc bien ce qu'il annonce. - Bornes du schéma mesurées : titre de 501 refusé, 500 accepté ; `etat` vide ou de 201 refusé ; `n = 0` refusé ; « 2026-10-20 25:00 » refusé ; `quand` NULL accepté. - `controle/test_etat_partage.py` : TOUT PASSE (ok 1 à ok 9b, dont 9a et 9b) ; `_tableau/test_onglet_reseaux.py` : OK (cas 10 inclus). - Bancs officiels (`python3 _tableau/lancer-tests.py --tout`) : 168 ok, 1 rouge (`_tableau/test_accueil_parite.py`, JSON doré de l'Accueil), cliquet baissé (cœur 99,1 % < 99,4 %, ensemble 96,6 % < 99,0 %). Témoin sur `origin/main` `ae760c38` SANS la branche : 168 ok, le MÊME rouge, cliquet baissé (cœur 99,1 % < 99,4 %, ensemble 96,7 % < 99,0 %). Les deux sont antérieurs à cette branche. - Rust : `cargo test --release --locked` = 77 essais dans 13 binaires, 0 échec ; `cargo build --release --locked` après recompilation réelle : aucune sortie d'avertissement. `npx vite build` : code 0. - CI : Rust verte (push 35 s, PR 33 s). Front rouge en 11 s — c'est le banc de `main`, pas de cette branche : `npx vitest run` sur `origin/main` donne le même unique échec (`tests/stockage.test.js`, « relevé à » attendu contre « relevé hier à 22 h 44 »), et avec le diff de cette branche appliqué sur main à jour (`ae760c38`, qui porte le correctif #1688 fusionné à 01 h 10) `npx vitest run` rend 27 fichiers / 200 essais TOUS VERTS. Il faut donc rebaser la branche (ou relancer la CI) pour que la tâche Front repasse au vert ; sans cela `fusion-auto` la refusera sur ce seul motif. Deux points à savoir, qui ne s'opposent pas à la fusion : 1. Chemin de pousse. `_reseaux/pousser-tableau.sh` (`set -euo pipefail`) écrit la file dans la base dès que la bascule est posée, avant de pousser au 132 : une entrée refusée par le schéma (titre au-delà de 500, `etat` vide, heure impossible) fait sortir `etat_client.py instagram` en 1 et arrête le script avant la pousse des deux JSON et la régénération de la page. L'échec est dit (message + code 1), mais une seule entrée hors bornes prive le 132 de la mise à jour. La file réelle est aujourd'hui dans les bornes (titre le plus long 93, `etat` 9, `n` de 1 à 19, aucun `quand` nul). Je n'ai pas lancé `pousser-tableau.sh` (il déploie) : ce point est lu, pas mesuré de bout en bout. 2. Production. Le service d'état (`192.168.1.142:8799`) est injoignable depuis le PC en ce moment (`No route to host`, mesuré) : la bascule de production n'est donc pas faite et la page du 132 lit encore le JSON — rien à moitié appliqué. La suite : fusion, réinstallation du service (la route `GET /instagram` n'existe pas encore sur le service en place), puis `basculer instagram-file`. À l'ouverture suivante, `_reparer_bascules` refait la table `bascules` de la base de production (`main()` du service appelle `ouvrir()` avant d'écouter).

hermes-bot added the

relu

label 2026-10-15 01:23:01 +02:00

hermes-fusion added the

conflit

label 2026-10-15 01:55:03 +02:00

hermes-fusion commented 2026-10-15 01:55:03 +02:00

Collaborator

• Copy link
• Copy Markdown

fusion-auto : pas de fusion, la PR est en conflit avec main : à rebaser. Le chef de l'atelier renvoie la carte à l'agent ; l'étiquette tombera d'elle-même une fois corrigé.

`fusion-auto` : pas de fusion, la PR est en conflit avec main : à rebaser. Le chef de l'atelier renvoie la carte à l'agent ; l'étiquette tombera d'elle-même une fois corrigé.

hermes-bot force-pushed hermes/migration-instagram-sqlite from 1c9eb948ff to 5099021ea0 2026-10-15 20:05:24 +02:00 Compare

hermes-fusion removed the

ci-rouge

conflit

labels 2026-10-15 20:10:05 +02:00

hermes-bot added 1 commit 2026-10-15 20:24:47 +02:00

Le banc du partage d'état attend aussi la table atelier ... fd63c1d6f6

Cause : la liste attendue (les tables de `sqlite_master`, triées par nom) oubliait `atelier`, que
le schéma du dépôt crée (`etat_partage.sql`, STUD-1110). `controle/test_etat_partage.py` sortait 1
sur main comme dans l'arbre — « la table de travail `bascules_avant` est restée derrière (ou une
table du schéma manque) », alors que la table en trop était `atelier`.

Remède : `atelier` ajoutée en tête de liste, commentaire complété ; le banc dit « TOUT PASSE ».

hermes-bot force-pushed hermes/migration-instagram-sqlite from fd63c1d6f6 to 69a8391f3d 2026-10-15 20:31:13 +02:00 Compare

hermes-bot commented 2026-10-15 20:31:46 +02:00

Author

Collaborator

• Copy link
• Copy Markdown

Rebasage sur main (tete 69a8391f) : conflits resolus, gardes vertes.

Conflits (les deux cotes gardes, main + branche) : etat_partage.py, etat_partage.sql, etat_client.py,
_infra/etat-service.py, _tableau/socle.py, _tableau/accueil_donnees.py, _tableau/tb_commun.py,
_tableau/LXC-132.md, OUTILS.md, controle/test_etat_partage.py.

Les gardes rouges du rebasage, corrigees (deux commits) :

• doublons : socle.py redéclarait en_service / _reponse_etat, que main porte deja -> copies retirees ;
• plafond : socle.py a 629 lignes (plafond de 600, sans derogation) -> lire_instagram sort dans le module
  _tableau/instagram_donnees.py (le socle garde la famille d'ACCES bascule_au_service /
  service_etat_appeler) ; les trois lecteurs, son banc et la doc suivent, socle.py redescend a 599 ;
• test_garde_couches.py et toute la suite : verts.

Bench rouge sur main, hors CI : controle/test_etat_partage.py attendait une liste de tables sans
atelier (table du schema, STUD-1110) -> ajoutee ; le banc dit TOUT PASSE.

Mesures (arbre du rebasage) :

• python3 _tableau/lancer-tests.py --tout -> 204 banc(s) verts. (code 0) ;
• python3 controle/test_etat_partage.py -> code 0, TOUT PASSE ;
• python3 _tableau/test_deploy_132.py -> code 0 ;
• cargo test --release --locked -> tous les bancs verts ; cargo build --release --locked -> code 0.

Rebasage sur `main` (tete 69a8391f) : conflits resolus, gardes vertes. **Conflits** (les deux cotes gardes, main + branche) : `etat_partage.py`, `etat_partage.sql`, `etat_client.py`, `_infra/etat-service.py`, `_tableau/socle.py`, `_tableau/accueil_donnees.py`, `_tableau/tb_commun.py`, `_tableau/LXC-132.md`, `OUTILS.md`, `controle/test_etat_partage.py`. **Les gardes rouges du rebasage, corrigees** (deux commits) : - doublons : `socle.py` redéclarait `en_service` / `_reponse_etat`, que `main` porte deja -> copies retirees ; - plafond : `socle.py` a 629 lignes (plafond de 600, sans derogation) -> `lire_instagram` sort dans le module `_tableau/instagram_donnees.py` (le socle garde la famille d'ACCES `bascule_au_service` / `service_etat_appeler`) ; les trois lecteurs, son banc et la doc suivent, `socle.py` redescend a 599 ; - `test_garde_couches.py` et toute la suite : verts. **Bench rouge sur `main`, hors CI** : `controle/test_etat_partage.py` attendait une liste de tables sans `atelier` (table du schema, STUD-1110) -> ajoutee ; le banc dit `TOUT PASSE`. **Mesures** (arbre du rebasage) : - `python3 _tableau/lancer-tests.py --tout` -> `204 banc(s) verts.` (code 0) ; - `python3 controle/test_etat_partage.py` -> code 0, `TOUT PASSE` ; - `python3 _tableau/test_deploy_132.py` -> code 0 ; - `cargo test --release --locked` -> tous les bancs verts ; `cargo build --release --locked` -> code 0.

hermes-fusion added the

ci-rouge

label 2026-10-15 20:45:03 +02:00

hermes-fusion commented 2026-10-15 20:45:03 +02:00

Collaborator

• Copy link
• Copy Markdown

fusion-auto : pas de fusion, la CI est rouge (Rust). Le chef de l'atelier renvoie la carte à l'agent ; l'étiquette tombera d'elle-même une fois corrigé.

`fusion-auto` : pas de fusion, la CI est rouge (Rust). Le chef de l'atelier renvoie la carte à l'agent ; l'étiquette tombera d'elle-même une fois corrigé.

hermes-bot force-pushed hermes/migration-instagram-sqlite from 69a8391f3d to 7127cc30b0 2026-10-15 20:54:29 +02:00 Compare

hermes-bot commented 2026-10-15 20:54:44 +02:00

Author

Collaborator

• Copy link
• Copy Markdown

Rebasage sur le main a jour (3d0c924a, « le statut public par video passe dans etat »). Tete : 7127cc30.

Cause du rouge precedent : mon arbre etait reste un cran derriere main — la fusion 8b16815b a retire la
derniere derogation de couches et deplace revue.statut_youtube ; les trois gardes ne pouvaient que refuser
(derogation nouvelle « revue.statut_youtube » de atelier/at_onglet.py sans « accord »). Rebase sans conflit
sur le main a jour, les trois gardes repassent.

Mesures (arbre rebase) : python3 _tableau/lancer-tests.py --tout -> 206 banc(s) verts. (code 0) ;
test_garde_couches, test_garde_doublons, test_garde_plafond -> ok (code 0) ; controle/test_etat_partage.py
-> TOUT PASSE (code 0). CI en cours sur 7127cc30.

Rebasage sur le `main` a jour (3d0c924a, « le statut public par video passe dans etat »). Tete : 7127cc30. **Cause du rouge precedent** : mon arbre etait reste un cran derriere `main` — la fusion 8b16815b a retire la derniere derogation de couches et deplace `revue.statut_youtube` ; les trois gardes ne pouvaient que refuser (`derogation nouvelle « revue.statut_youtube » de atelier/at_onglet.py sans « accord »`). Rebase sans conflit sur le `main` a jour, les trois gardes repassent. **Mesures** (arbre rebase) : `python3 _tableau/lancer-tests.py --tout` -> `206 banc(s) verts.` (code 0) ; `test_garde_couches`, `test_garde_doublons`, `test_garde_plafond` -> `ok` (code 0) ; `controle/test_etat_partage.py` -> `TOUT PASSE` (code 0). CI en cours sur 7127cc30.

hermes-fusion removed the

ci-rouge

label 2026-10-15 20:55:03 +02:00

hermes-fusion merged commit 3a985afb4c into main 2026-10-15 21:05:04 +02:00

hermes-fusion deleted branch hermes/migration-instagram-sqlite 2026-10-15 21:05:04 +02:00

hermes-fusion commented 2026-10-15 21:05:04 +02:00

Collaborator

• Copy link
• Copy Markdown

Fusionnée automatiquement par fusion-auto (forge) : CI verte, sans conflit.

Fusionnée automatiquement par `fusion-auto` (forge) : CI verte, sans conflit.

hermes-fusion referenced this pull request from a commit 2026-10-15 21:05:06 +02:00

Merge pull request 'instagram-file.json — la file Instagram passe dans la base du service d'état' (#1685) from hermes/migration-instagram-sqlite into main

foXaCe referenced this pull request 2026-10-16 17:53:23 +02:00

État partagé : le relevé de rythme passe dans la base SQLite (rythme.json) [t_af5f04d2] #1695

hermes-bot referenced this pull request from a commit 2026-10-16 18:07:41 +02:00

feat(gateway): add DingTalk platform adapter (#1685)

hermes-bot referenced this pull request from a commit 2026-10-17 04:24:51 +02:00

fix(docker): egress-off reuse probe uses a label filter, not the Docker-only {{.Label}} template (#99213)

hermes-bot referenced this pull request from a commit 2026-10-17 13:20:03 +02:00

fix(security): corrupt-token and docker_env warnings stop logging credential material (#102308)

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

ci-rouge

La CI de la PR est rouge : pas de fusion automatique

  

conflit

La PR est en conflit avec main : à rebaser

  

operateur

Cas sensible : seul l operateur fusionne

  

relu

Relue et validée par le relecteur de l atelier Hermes : la fusion automatique peut la prendre

No labels

ci-rouge

conflit

operateur

relu

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

foXaCe/studio!1685

No description provided.