fix(audiobook,#1028): suspension auto du monitor d'idle pendant une chaine LLM->TTS

[jsboige]

Grain: MED/genai -- lane myia-po-2023:CoursIA -- prev: LIGHT/docs #14403

Resume

Suspension automatique du sidecar tts-fishaudio-idle-monitor pendant une chaine LLM->TTS du pipeline v4 audiobook — residu 2 de l'EPIC #1028 (le « geste manuel a ne pas oublier »).

Contexte du defaut (#14059) : sur le livre complet, les phases LLM amont p3+p4 durent ~36 min sans aucun appel TTS. Le monitor (IDLE_TIMEOUT=1200 s, economie GPU legitime) tuait tts-fishaudio avant que p5 n'arrive — 385/385 echecs de chaine au premier run du livre entier.

Implementation

• v4/idle_monitor.py (nouveau) : chain_needs_suspension(phases) (True si p5 precede d'au moins une phase LLM) + suspended_idle_monitor(phases) context manager : docker stop au debut, docker start garanti en finally — meme si une phase echoue (sys.exit(1) de run_pipeline traverse le context manager, le redemarrage a quand meme lieu).
• v4/run_pipeline.py : la boucle de phases est enveloppee dans with suspended_idle_monitor(phases):.
• Fail-safe par construction : docker absent (OSError), daemon muet (TimeoutExpired), monitor inexistant/arrete (inspect != true), stop en echec — la chaine continue TOUJOURS, au pire avec un WARN. L'etat d'avant ce module etait l'echec silencieux de la chaine longue ; on ne trade jamais un echec de chaine contre un echec de suspension.
• Le monitor n'est redemarre que si CETTE fenetre l'a arrete (jamais au hasard d'un etat anterieur).

Verification

• Tests hermetiques CPU-only (_docker monkeypatche) : v4/tests/test_idle_monitor.py — 6/6 nouveaux, 120/120 au total sur 04-Applications/v4/tests (pattern d'import de test_canonical.py, aucun docker reel) :
  • matrice chain_needs_suspension (p5 seul / LLM avant p5 / p5 avant LLM / sans p5 / chaine complete)
  • stop au debut + start a la fin (monitor actif)
  • redemarrage garanti sur exception dans la fenetre
  • noop monitor absent, stop en echec ne bloque pas, docker absent tolere
• Preuve end-to-end sur le conteneur REEL po-2023 (pas un fake) : monitor detecte Up 13 hours -> [monitor] tts-fishaudio-idle-monitor suspendu pour la fenetre de chaine -> dans la fenetre docker inspect = running=false -> [monitor] tts-fishaudio-idle-monitor redemarre -> docker ps final = Up Less than a second.
• python -m py_compile run_pipeline.py idle_monitor.py OK.

Note de traçabilite (pour ai-01)

L'issue #14188 (les 2 residus de l'EPIC) a ete fermee en citant la PR #14197, qui est un test fixture pick_idle_grain_cache sans rapport avec le monitor — la moitie « monitor suspension » restait non livree de fait. Ce PR livre cette moitie. L'autre moitie (m4b) etait deja livree par #14224 (84994c9).

See #1028 (contribution partielle — l'arbitrage de fermeture de l'EPIC revient au coordinateur : les 2 residus sont desormais livres).

🤖 Generated with Claude Code

[github-actions]

G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
La lane `myia-po-2023:CoursIA` voit ces signaux actifs sur les mergees du jour (UTC 2026-09-03) :

• CAP-EXCEEDED-BY-GENRE : light_genre > cap partage G-VAR-2 (tally : declared=3 genre=2 cap=1)
• NOTE ([variation] Le label est lane-agregat mais PR-attache : le merge-gate peut HOLD le grain de CONTENU qui remedie au motif #10341) : la PR courante est de classe CONTENU (non LIGHT-genre) et ne contribue pas au motif ci-dessus -- les labels agregees ne sont PAS poses sur cette PR (le merge-gate ne doit pas la HOLD pour ce motif ; le coupable est parmi les grains META de la lane).

G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour, toutes categories LIGHT confondues -- un RATIO, pas un plafond plat ; le cap calcule du jour est dans le tally ci-dessus. G-VAR-3 interdit deux genres LIGHT consecutifs. Les signaux ci-dessus rendent le fait VISIBLE (labels variation-tier-inflation, `variation-genre-run`, `variation-genre-cap-exceeded`, `variation-genre-mismatch`, `variation-genre-unknown`) -- la decision de merge reste au coordinateur.