consolidation: fusion doublons (mcp-nas, opencode, bifrost-vk, doc-api rebuild), purge obsoletes (gotenberg, ports-registry racine), re-spherage runbooks metier (perso/tt/nyora), refonte _INDEX.md — 09/07/2026
This commit is contained in:
@@ -1 +0,0 @@
|
||||
|
||||
@@ -1 +0,0 @@
|
||||
- vps-contabo-reinstall-tailscale-07-07.md — Réinstallation VPS + bascule wg-admin custom → Tailscale, pièges mcp-nas/tailnet et tailscale up non-interactif
|
||||
@@ -0,0 +1,34 @@
|
||||
# Cron Hermes ne se relit pas au vol + publish n8n casse : veille Dr Nexum non recue
|
||||
|
||||
**Date** : 2026-07-07
|
||||
**Tags** : infra, cron, hermes, n8n, publish, timezone, veille, nyora
|
||||
|
||||
## Symptome
|
||||
Veille Dr Nexum (Hermes 3x/jour + workflow n8n) non recue le 06/07 20h ni le 07/07 7h, sur les deux pipelines simultanement.
|
||||
|
||||
## Cause 1 -- Cron Hermes fige en memoire (jobs.json)
|
||||
Le service cron de chaque agent Hermes charge `jobs.json` uniquement au demarrage du container. Une edition directe du fichier (passage de 1x a 3x/jour le 06/07) s'est bien ecrite sur disque, mais le processus tournait toujours avec l'ancien horaire quotidien (11h30 UTC) en memoire -- `next_run_at` restait fige sur l'ancienne valeur meme un jour apres l'edit.
|
||||
|
||||
**Fix** :
|
||||
1. Editer `jobs.json` (cron expr).
|
||||
2. Recalculer et ecrire manuellement `next_run_at` a la bonne valeur (le daemon ne le fait pas toujours correctement au premier boot suivant).
|
||||
3. Redemarrer le container **agent** correspondant -- nom reel `hermes-agent-tt` / `hermes-agent-nyora` / `hermes-agent-perso` (piege : ne pas confondre avec `hermes-workspace-*`, qui sont d'autres containers).
|
||||
4. Restart via API Portainer : `POST /api/endpoints/2/docker/containers/{id}/restart` timeout systematiquement sur cette instance -- utiliser `stop` puis `start` explicites (2 appels separes).
|
||||
5. Verifier apres coup que `next_run_at` a la bonne valeur.
|
||||
|
||||
Portainer : endpoint local = id `2`. Auth via `172.17.0.1:9000/api/auth` depuis un container (jamais l'IP LAN). Credentials dans `hermes-platform/.env`.
|
||||
|
||||
## Cause 2 -- Fuseau horaire (NAS + n8n en UTC, pas Tunis)
|
||||
Le NAS et n8n tournent en UTC. Tunis = UTC+1 toute l'annee (pas de changement d'heure). Un cron `0 7,12,20 * * *` tire a 8h/13h/21h Tunis, pas 7h/12h/20h.
|
||||
|
||||
**Fix** : toujours retirer 1h a l'expression cron pour un horaire "heure de Tunis" -- `0 6,11,19 * * *` en UTC pour obtenir 7h/12h/20h Tunis. Applique sur jobs.json (Hermes) et sur le node Schedule Trigger n8n.
|
||||
|
||||
## Cause 3 -- publish_workflow n8n casse sur un workflow specifique (non systemique)
|
||||
Un workflow deja actif, modifie via l'outil `update_workflow`, ne bascule pas automatiquement en production -- `update_workflow` cree un nouveau `versionId` (brouillon) mais le workflow continue de servir son `activeVersionId` existant. Sur ce workflow precis, `publish_workflow` echouait de facon persistante avec `"Version not found"`, y compris en reessayant **depuis l'UI n8n elle-meme** (capture d'ecran a l'appui) et apres un `unpublish_workflow` prealable -- confirme comme un etat corrompu propre a ce workflow (chaine de versions cassee en base), pas un bug de l'outil MCP.
|
||||
|
||||
**Fix qui a marche** : dupliquer le workflow (bouton **Duplicate** dans l'UI n8n). La copie repart avec une chaine de versions saine et se publie normalement des le premier essai. Renommer la copie pour retirer le suffixe " copy", puis `unpublish_workflow` + `archive_workflow` sur l'original casse une fois la copie confirmee active.
|
||||
|
||||
**Verification obligatoire apres toute modif d'un workflow n8n deja actif** : `get_workflow_details` -> comparer `versionId` et `activeVersionId`. S'ils different, le changement n'est PAS en production, meme si l'outil de modification a repondu succes.
|
||||
|
||||
## Lecon generale
|
||||
Une reponse "success" d'un outil de modification (`update_workflow`, edition de `jobs.json`) ne garantit jamais que le changement est en production. Toujours verifier l'etat reel apres coup : `next_run_at` recalcule pour un cron Hermes redemarre, `activeVersion == draft` pour un workflow n8n.
|
||||
@@ -0,0 +1,44 @@
|
||||
# Runbook - Veille Hebdo Dr. Nexum (Kanban Fan-Out)
|
||||
|
||||
Date : 2026-06-18 | Instance : hermes-nyora | Statut : Deploye
|
||||
|
||||
## Architecture
|
||||
|
||||
Cron lundi 07h00 -> default (orchestrateur) -> 6 workers veilleur paralleles -> synthese brief Telegram
|
||||
|
||||
## Profile veilleur
|
||||
|
||||
Path : /opt/data/profiles/veilleur/
|
||||
SOUL.md : scoring /10, angle video, signal fort OUI/NON
|
||||
Config : deepseek-v4-flash/openrouter, max_turns 25
|
||||
|
||||
## Sources (6)
|
||||
|
||||
youtube-fr-ia : videos IA/automatisation FR semaine
|
||||
huggingface-blog : nouveaux modeles open-source
|
||||
reddit-ia : r/LocalLLaMA + r/MachineLearning
|
||||
producthunt-ia : nouveaux outils IA lances
|
||||
labs-ia : Anthropic + OpenAI + DeepMind annonces
|
||||
automatisation : n8n + Make + Zapier blog workflows
|
||||
|
||||
## Sortie
|
||||
|
||||
Fiches sources : /opt/data/workspace/veille/YYYY-WNN/<source>.md
|
||||
Brief final : /opt/data/workspace/veille/YYYY-WNN/brief-nexum.md
|
||||
Livraison : Telegram Nabil (2084513684)
|
||||
|
||||
## Cron jobs.json
|
||||
|
||||
Fichier : /volume1/docker/hermes-platform/hermes-nyora/data/cron/jobs.json
|
||||
Job ID : veille-hebdo-nexum-kanban-a1b2c3d4
|
||||
Expr : 0 7 * * 1 (lundi 07h00 UTC = 08h00 Tunisie ete)
|
||||
|
||||
## Declencher manuellement
|
||||
|
||||
Depuis Telegram hermes-nyora :
|
||||
Lance la veille hebdo Nyora maintenant
|
||||
|
||||
## Deux crons hermes-nyora actifs
|
||||
|
||||
1. Veille IA Matin (11h30 UTC quotidien) - opportunites Dr. Nexum via veille_ia_matin.py
|
||||
2. Veille Hebdo Fan-Out (07h00 lundi) - analyse profonde 6 sources, brief structure
|
||||
@@ -0,0 +1,94 @@
|
||||
# Workflow Claude-GLM -- Nyora API Builder
|
||||
|
||||
**Date** : 2026-06-17 (rev 2)
|
||||
**Scope** : hermes-nyora (GLM-5.1 via opencode-go) + Telegram bot
|
||||
**Objectif** : Economiser les tokens Claude -- garder Claude pour le strategique
|
||||
|
||||
---
|
||||
|
||||
## Architecture
|
||||
|
||||
PLANNER -> Claude (discussion + accord + generation plan)
|
||||
EXECUTOR -> hermes-nyora / GLM-5.1 via Telegram (implementation)
|
||||
REVIEWER -> Claude (validation finale, problemes critiques uniquement)
|
||||
|
||||
Ratio economies tokens : ~7x (Claude = 20-30k, GLM = 150k+)
|
||||
|
||||
---
|
||||
|
||||
## Workflow complet (4 etapes)
|
||||
|
||||
### Etape 1 -- Discussion et accord (session Claude)
|
||||
|
||||
Nabil decrit son projet librement a Claude.
|
||||
Claude pose les questions necessaires :
|
||||
- Stack existante et contraintes
|
||||
- Perimetre exact de l API / feature
|
||||
- Integrations (Bifrost, Baserow, n8n, etc.)
|
||||
- Chemin du repo Gitea
|
||||
|
||||
Pas de template a remplir avant -- la discussion IS le template.
|
||||
Accord explicite avant de passer a l etape 2.
|
||||
|
||||
### Etape 2 -- Generation du plan (Claude)
|
||||
|
||||
Claude genere un PLAN.md complet et structure.
|
||||
Format : PROJECT / CONTEXT / TECH STACK / PHASES / REVIEW CRITERIA
|
||||
Maximum 5 phases. Chaque phase : GOAL + TASKS + FILES + VALIDATION.
|
||||
Claude inclut les criteres de review qu il utilisera a l etape 4.
|
||||
|
||||
### Etape 3 -- Execution (Telegram -> hermes-nyora)
|
||||
|
||||
Nabil copie-colle le PLAN.md dans le Telegram bot hermes-nyora.
|
||||
hermes-nyora active automatiquement le skill claude-glm-workflow.
|
||||
Execution phase par phase avec rapport standardise.
|
||||
hermes-nyora genere HANDOFF.md a la fin.
|
||||
|
||||
Bot Telegram hermes-nyora : token 8914117708:AAHNysUFMy8eFRagLmcNMvCkiCuArf0aZMs
|
||||
allowed_chats : '' (tous les chats autorises par defaut)
|
||||
|
||||
### Etape 4 -- Review finale (session Claude)
|
||||
|
||||
Nabil copie HANDOFF.md + prompt review dans Claude.
|
||||
Prompt review disponible dans : workspace/templates/claude-plan-template.md
|
||||
Claude identifie uniquement les problemes critiques et majeurs.
|
||||
Verdict : Ready to deploy | Needs fixes.
|
||||
|
||||
---
|
||||
|
||||
## Fichiers deployes
|
||||
|
||||
hermes-nyora/data/skills/nyora/claude-glm-workflow/SKILL.md
|
||||
hermes-nyora/data/workspace/templates/claude-plan-template.md
|
||||
hermes-nyora/data/SOUL.md (section WORKFLOW CLAUDE-GLM)
|
||||
|
||||
---
|
||||
|
||||
## Modele et couts
|
||||
|
||||
Modele actuel : glm-5.1 (opencode-go, $10/mois = $60 valeur)
|
||||
Fallback : qwen3.7-plus (opencode-go)
|
||||
GLM-5.2 : disponible semaine 22 juin -- changer config.yaml model.default
|
||||
|
||||
---
|
||||
|
||||
## Pieges connus
|
||||
|
||||
- SOUL.md et config.yaml : 100% ASCII obligatoire
|
||||
- hermes-nyora voit /opt/data/workspace/ (pas /workspace/)
|
||||
- Bifrost requis pour tout LLM depuis n8n (opencode.ai inaccessible)
|
||||
---
|
||||
|
||||
## Bonne pratique -- Plans longs (> limite Telegram)
|
||||
|
||||
Pour tout plan depasse quelques centaines de caracteres :
|
||||
|
||||
1. Claude depose le PLAN.md dans /opt/data/workspace/plans/<projet>.md via MCP
|
||||
2. Nabil envoie UNE LIGNE dans Telegram :
|
||||
Execute le plan : /opt/data/workspace/plans/<projet>.md
|
||||
3. hermes-nyora lit le fichier et execute normalement
|
||||
|
||||
Avantages : plans illimites en taille, historique des plans conserve sur le NAS,
|
||||
relance facile sans re-coller le prompt, traçabilite Gitea possible.
|
||||
|
||||
Convention nommage : <slug-projet>-YYYYMMDD.md (ex: panda-theme-switcher.md)
|
||||
Reference in New Issue
Block a user