blog.vfg.lol

STATUS — VFGate — 2026-10-08

STATUS — VFGate

Article généré automatiquement depuis le STATUS.md de VFGate — 2026-10-08. Les chemins locaux, les hôtes internes et les noms de variables ont été neutralisés.

STATUS — VFGate (BDDBridgePOC)

SSOT vivant du présent · mis à jour à chaque session significative. Nom canonique : VFGate. « BDDBridgePOC » est l'alias historique (voir § Dépôt et chemins ci-dessous).

Dernière mise à jour : mercredi 7 octobre 2026 — ✉️ relais Telegram → Bionic + dispatcher (options A/B/C → agent de code). Commits a57e20a (relais) + ff8d174 (auto-connaissance injectée) sur main.

MesureCommandeRésultat
Suite complètenpm test218/218 PASS
Smoke relais (Bionic réel, dry-run)node scripts/telegram-bionic-relay.mjs --test --dry-run« Bonjour FG. » ~4 s, aucun envoi Telegram
Dispatcher (autre dépôt)test/dispatcher-core.test.mjs (vfg-dispatcher)9/9

Pourquoi un worker : RuleEngine/_executeRuleAction (packages/core/src/index.js) ne supportent que action.type ∈ {route, brain} — aucune action HTTP. Le relais chat.inbound → Bionic(:1234) → POST /adapters/:id/send est donc hors moteur : packages/api/src/lib/bionicRelay.js (pur) + scripts/telegram-bionic-relay.mjs (SSE, reconnexion). Clés env : TELEGRAM_BIONIC_RELAY, BIONIC_CHAT_URL/MODEL/[variable d'environnement]/SYSTEM_PROMPT. Le dispatcher (vfg-dispatcher) ajoute la boucle complète : réponse + options A/B/C, puis sur choix → bin/delegate.ps1 (agent de code). Fiches : docs/AGENT-SELF.md, docs/handoffs/2026-10-07-0355-….

Dernière mise à jour (précédente) : mardi 6 octobre 2026 — commande Telegram /statut (réponse locale, sans LLM).

Le bot @didoumaloubot répond dans le chat allowlisté à /statut, statut, /status, status, et /aide liste les commandes. Jah (https://jah.vfg.lol/readyz), MSN, le blog et l'agrégat pont (Hero, Matrice, Lucien) sont sondés en parallèle (4 s). Heure Europe/Paris, lien VFG_STATUS_COCKPIT_URL (défaut http://[hôte interne]:5288/cockpit-statut-pc-2026-10-06.html). VFG_TELEGRAM_STATUS_CMD=1 par défaut ; 0 ou false rend le texte à nouveau relayable vers Jah. Un chat hors chatIds est ignoré. npm test : 223/223 PASS (2026-10-06).

Quel processus redémarrer : le long-polling mesuré le 2026-10-01 (polling: true, adaptateur telegram-muojbpi6) est celui du conteneur Docker vfgate-api (vfg-fleet-vfgate-api-1). L'image lance npm run start -w @vfgate/api, donc node src/server.js dans le conteneur, pas un process Windows à part. Déployer l'image puis recréer vfgate-api (le workflow docker-publish le fait si VPS_DEPLOY_ENABLED=true, puis rattache jah-ingress). Ne pas lancer un second poller en local.

Dernière mise à jour (antérieure) : jeudi 2 octobre 2026 — ✅ FIN DU GEL VFGate : le journal d'audit est borné et tourne tout seul. Commit 11f7056 (main).

MesureCommandeRésultat
Tests corenode --test packages/core/test/core.test.js12/12 PASS
Suite complètenpm test205/205 PASS, 0 fail
tail(200) sur le journal réel de 175 Mobenchmark AuditLog4,39 ms (avant : 3–6 s)
Santé serviceGET /api/vfgate/v1/health200, 0 ms
Chaîne de présencesmoke-agent-workflow.mjsPASS ×2
Chaîne complètedoctor-agent-presence.ps1tout OK

Cause racine : AuditLog.tail() (packages/core/src/audit.js) relisait tout vfgate-audit.jsonl à chaque appel ; le relais de présence l'interroge toutes les 500 ms, et le journal avait atteint 174,76 Mo → 3–6 s par lecture → empilement → VFGate figé depuis le 2026-10-01 ~22:06 UTC. Correctif : tail() lit une fenêtre de fin (64 Ko min, 512 o/événement) ; rotation auto avant écriture (8 Mo, 3 archives), fail-open. 2 tests ajoutés. Fiche : docs/handoffs/2026-10-02-0145-gel-vfgate-tail-audit-borne.md.

Prochaine action : décider du push de 11f7056 (déclenche code-deploy en production — décision humaine).

Dernière mise à jour (précédente) : jeudi 1er octobre 2026 (nuit) — ✅ LE PONT TELEGRAM ↔ JAH FONCTIONNE DANS LES DEUX SENS (mesuré en production).

SensPreuve
A — Telegram → Jahmessage.received réel de didoufg (chat:638877009) · ingress_sources.telegram count=3
B — Jah → Telegramingress → 200 {"ok":true,"routed_to":"fg@jah"} · bridge_outbox total=1, envoyés=1, attempts=1, last_error=null, payload=2 o ({} = purgé après envoi, conforme)

attempts=1 + err=null = VFGate a accepté au premier essai : la boucle complète ville → outbox → VFGate → Telegram est vérifiée, jeton et idempotence compris.

Configuration mesurée : bot @didoumaloubot en polling: true · conteneur VFGate sur jah-ingress + vfgnet · store : VFJAH_INGRESS_URL=http://jah-hub:5231, VFJAH_TELEGRAM_RELAY=true · JAH_BRIDGES_ENABLED=1, JAH_VFGATE_URL → 200 · bridges : fg@jah → telegram / 638877009 · fg@jah.settings_json.telegram = true.

⚠️ Cause racine du sens retour (trouvée et corrigée). Le blocage n'était ni le lien ni l'opt-in : didou.say() (src/bots/didou.mjs:97) rend null si !canInteract(db, didou, accountId), et canInteract (src/social/contacts.mjs:68) exige une acceptation mutuelle. Mesure avant correction : didou@jah ↔ fg@jah était en pending_out / pending_in — la demande de didou n'avait jamais été acceptée, et didou ne peut pas accepter lui-même. L'ingress répondait alors 409 didou_unavailable : message trompeur (didou était joignable, c'est le contact qui manquait).

⚠️ Correction de diagnostic (mesurée). L'env du conteneur porte encore VFJAH_INGRESS_URL=http://vfjah-bot:5211 (le legacy) — mais le store porte http://jah-hub:5231. Le store prime sur process.env (env-manager.js:50-51). Lire l'env du conteneur seul produit un faux diagnostic : il faut lire GET /settings/env.

⚠️ Piège d'accès. L'ingress écoute sur JAH_INGRESS_HOST = 172.30.230.10, pas sur 127.0.0.1 : depuis le conteneur Jah, http://[hôte interne]/ingress → ECONNREFUSED.

Ménage de branches : #17 et #19 mergées sur main (elles apportent jah-relay.js et sendGuard.js — le défaut 5.2 est corrigé) · #15 fermée (supplantée par #17 : deux mécanismes d'idempotence concurrents auraient coexisté) · #16 rebasée sur main (9621828, 214/214 PASS), base repointée, porte les 5 défauts restants (5.1/5.3/5.5/5.6/5.7) · #18 ouverte (rattache durablement vfgate-api à jah-ingress après le up -d) · #14 ouverte (erratum de topologie). Preuves : docs/handoffs/2026-10-01-2400-etat-reel-pont-telegram-jah.md · audits/ (26 fichiers, scripts rejouables).

Dernière mise à jour : jeudi 1er octobre 2026 — clôture du palier delta 7, aucun code applicatif modifié. HEAD mesuré 678ee3a (tag annoté v0.1.0-delta7), origin/main = 27f677d → 1 commit d'avance, pas de divergence, pas de push effectué (décision distincte). Mesures rejouables du 2026-09-30 : npm test 195/195 PASS · prod gate.vfg.lol 401 sur /health, /adapters et /bridge/v1/health (donc mesurée, plus « non mesurée ») · journal d'audit 174 Mo (182 740 270 octets, et non « > 50 Mo ») · store packages/api/data/ = 6 adaptateurs / 8 routes (et non 6 routes) vs data/ = 0. Livrables : commit 678ee3a (5 fichiers, +346/−4) → docs/RELEASE-delta7.md (242 lignes), CHANGELOG.md (créé), README.md, docs/INDEX.md, CLAUDE.md ; handoff docs/handoffs/2026-10-01-vfgate-delta7-release.md.

Dernière mise à jour (précédente) : mercredi 30 septembre 2026 — session d'audit ; son bloc d'en-tête citait HEAD afe6577, qui était l'état d'entrée de cette session, pas le HEAD courant (celui-ci est 678ee3a). Fiche : docs/2026-09-30-audit-etat-refresh.md.

Dernière mise à jour (antérieure) : jeudi 16 juillet 2026 ~18h — Track A orchestrateur : A1 (npm audit) 0 CVE, ws unique 8.21.0 ; log sécurité reconstruit. Restes humains : WA-QR, ROUTES-CLEAN, GATE-05, P4 deploy/secrets.


Session 30 septembre → 1er octobre 2026 — Palier delta 7 (documentation seule)

Palier delta 7 — 2026-09-30 (mesures) / 2026-10-01 (clôture). Tag v0.1.0-delta7 sur 678ee3a. Aucun code applicatif modifié : ce palier consigne un état mesuré et nomme sa dette.

MesureCommandeRésultatCorrige
Testsnpm test195/195 PASS, 0 fail—
VFGate prodcurl.exe -s -o NUL -w "%{http_code}" …/api/vfgate/v1/health401« prod non mesurée » → mesurée
Adaptateurs prod… /api/vfgate/v1/adapters401—
Bridge prod… /api/bridge/v1/health401—
Jah Messengercurl.exe -s https://jah.vfg.lol/readyz{"status":"ready","version":"4.0.0-alpha.13"}—
Journal d'audit(Get-Item …/vfgate-audit.jsonl).Length174 Mo (182 740 270 o)« > 50 Mo » → 174 Mo
Store peuplépackages/api/data/vfgate-store.json6 adaptateurs / 8 routes« 6 routes » → 8 routes
Store racinedata/vfgate-store.json0 adaptateur—
Rotation auditSelect-String packages/core/src/audit.js -Pattern rotate0 occurrence—
Git localrefs main / origin/main678ee3a / 27f677d → ahead 1, sans divergenceHEAD afe6577 → 678ee3a

Les 7 défauts mesurés — aucun corrigé (détail fichier:ligne : docs/RELEASE-delta7.md §5) : 404 latent (hero-bridge.js:146) · auth + idempotence absentes (vfgate.js:109-127, le plus coûteux) · journal sans rotation · deux dataDir (config.js:12) · code mort (hero-bridge.js:66-81) · boucle-guard muette (hero-bridge.js:156) · un poller par adaptateur → 409 (adapterRegistry.js:104-108).

Relais : (1) mesurer le store depuis le VPS (SSH, absent en session) ; (2) décision FG sur le défaut n°2 (auth + idempotence) ; (3) correctif n°4 (dataDir, risque nul).


Session 30 septembre 2026 — Audit d'état + plan de refresh (lecture seule)

Dépôt et chemins (mesuré)

FaitCommandeRésultat
Nom canoniqueworkspace.manifest.json → projects.VFGatetier=live, path=_live/VFGate, lifecycle=active, expected_present=true
Alias historiqueidemaliases=["BDDBridgePOC"], « alias conservé pendant la migration »
Chemin canonique(Get-Item _live\VFGate).LinkTypeJunction → [chemin local]
Chemin physique(Get-Item BDDBridgePOC).AttributesDirectory (pas de ReparsePoint) → dépôt réel
Remotegit -C BDDBridgePOC remote -vhttps://github.com/FGDidou/VFGate.git
BDDBridgePOC archivé ?Get-ChildItem ____Currently_Archived,_archivednon — aucune copie, ____Currently_Archived/ contient 9 autres dossiers

Conclusions : un seul dépôt, deux chemins. BDDBridgePOC n'est pas un projet archivé, c'est l'emplacement physique du dépôt vivant, atteint via la junction canonique. Ne pas réactiver une seconde entrée de projet. Après le reboot d'inversion prévu par la migration de tiers, BDDBridgePOC deviendra la junction et _live/VFGate le dossier physique — sans changement de dépôt.

Ce que l'audit a mesuré (détail et commandes : fiche d'audit)

  • Vivant : télémétrie des agents — le journal reçoit des écritures vfg-agent-presence le matin même du 30/09 ; branchent dessus FG_Chronos (émetteur + relais) et VFG_Cockpit (upstream SSE).
  • Sain : npm test 195/195 PASS au 30/09 ; npm audit 0 vulnérabilité au 16/07 (cf. § Correction ci-dessous).
  • Peu utilisé pour sa fonction première : 0 règle, 0 abonné, workflows de juin ; 6 types d'adaptateurs implantés mais non configurés.
  • Footgun config : deux stores coexistent — data/ (vide) vs packages/api/data/ (6 adaptateurs, 6 routes) selon le répertoire de lancement.
  • À corriger : journal packages/api/data/vfgate-audit.jsonl > 50 Mo sans rotation, contenant des messages réels de juin.
  • À trancher : .env local en TELEGRAM_ENABLED=true avec un bot partagé, alors que le runbook exige un bot dédié.
  • Non mesuré : production (gate.vfg.lol) — le réseau sortant était indisponible ; prod attestée (image du 21/06, API :8083), deploy auto désactivé par défaut.

Correction — information périmée

La section « Points restants » plus bas annonce « 16 CVE high severity persistent » (constat du 29 juin). C'est périmé : la passe du 2026-07-16 (cf. SECURITY-UPGRADE-LOG.md) donne npm audit = 0 vulnérabilité, ws unique en 8.21.0, après migration electron 43 / electron-builder 26 (03/07) et packaging NSIS vérifié.

Relais — prochaine session

  1. Mesurer la prod (2 commandes, 30 s) : curl.exe -s https://gate.vfg.lol/api/vfgate/v1/health et …/api/bridge/v1/health → consigner ici.
  2. Décision FG sur Telegram (bot dédié ou mode simulé) — bloquant pour le Lot 1.
  3. Lot 0 de l'audit : dataDir absolu, purge des restes de test + 4 routes UUID, rangement racine, réparation de docs/INDEX.md.

Livrables de la session

  • HANDOFF_Audit_29juin2026.md — plan d’action détaillé (tâches A à F) pour l’agent suivant.
  • ARTICLE_Cloture_Audit_29juin2026.md — synthèse executive à destination des parties prenantes.
  • Article devblog publié dans RAPPORT-EXPERIENTIEL : 2026-06-29-0215_vfgate-migration-mcp-zed-tests-et-publication-devblog.md (statut pub après correction du frontmatter).

Clôture — Session 29 juin 2026 (Audit repo VFGate A-F)

Commentaires de fin de session

L'agent de clôture a exécuté le plan HANDOFF_Audit_29juin2026.md (tâches A à F) et a poussé les correctifs en commits atomiques.

Validation

  • npm test : 195/195 PASS.
  • node --test packages/api/test/api.test.js : 18/18 PASS (< 2 s).
  • npm run smoke:all contre API locale :5191 : PASS (bridge feed SKIPPÉ faute de [variable d'environnement]).

Tâches A-F — état

IDTâcheCommitÉtat
ACorriger le hang SSE (/events/subscribe + test)2bfe9c1✅
BMasquer les secrets dans GET/PUT/PATCH /settings/env2bfe9c1✅
CRetirer packages/api/.wwebjs_cache/ de git + .gitignore85996e8✅
DPatcher ws à la version la plus récente disponible (8.21.0 — 8.22.0 n'est pas publiée)63c83a0✅
EAligner docs/02-architecture-v0.md sur le store JSONbd4130b✅
Fnpm test + npm run smoke:all verts—✅

Points restants / non couverts

  • Vulnérabilités npm : 16 CVE high severity persistent (electron, node-tar, tar-fs, ws via puppeteer-core embarqué dans whatsapp-web.js). Uniquement ws direct a été mis à jour. Une passe npm audit fix ou mise à jour de whatsapp-web.js/puppeteer-core reste à évaluer avec précaution (risque de break Puppeteer + Electron builder).
  • Hygiène processus : à surveiller sous Windows — npm test laisse parfois des processus node.exe sur les ports 519x. Vérifier avec netstat -ano \| findstr 519 si besoin.

Plan post-audit — Session 29 juin 2026

Tâches en cours

IDTâcheÉtat
P4Docker build → push → deploy VPS⚠️ Bloqué — voir § Docker Deploy Fix
P-env.env.example aligné prod/dev + token pattern✅ Fait
P-docNoter BOT_DEDIQUE_STARTED dans STATUS.md✅ Fait
CVENotes persistantes dans STATUS.md § Points restants✅ Fait
CI/CDWorkflow GitHub Actions corrigé✅ Fait (nécessite activation manuelle)

Variable BOT_DEDIQUE_STARTED

  • Fichier : .env
  • Type : booléen (true/false)
  • Usage : active le polling real data sur le bot dédié (distinct de VFG_Hero, pas de conflit 409 Telegram).
  • Decision FG : bot dédié prêt et testé séparément. Devblog à mettre de côté (FG est encore dessus).

Docker Deploy Fix (29 juin 23h30)

Problème : commandes HANDOFF échouaient (auth GHCR manquante, fichier compose introuvable, placeholders non remplacés).

Diagnostic complet : DIAGNOSTIC_CI_CD_29juin2026.md (4 erreurs identifiées + 3 options de fix).

Correctifs appliqués :

  • Workflow .github/workflows/docker-publish.yml : chemin [chemin serveur] + fichier compose/t1-core.yml + commandes docker compose directes (fini deploy.sh fantomatique).
  • Guide manuel : HOWTO_Deploy_Docker_VPS.md (commandes exactes + prérequis docker login ghcr.io).

Action manuelle requise (FG) :

  1. Vérifier structure VPS réelle :

    ssh vps-vfg "ls -la [chemin serveur]"
    ssh vps-vfg "grep -A5 vfgate-api [chemin serveur]"

    Confirmer que t1-core.yml existe et contient bien vfgate-api.

  2. Push manuel test (une fois) :

    # Auth GHCR (générer PAT sur github.com/settings/tokens)
    echo $GITHUB_PAT | docker login ghcr.io -u fgdidou --password-stdin
    
    # Push + deploy (depuis VFGate/)
    docker push ghcr.io/fgdidou/vfgate-api:latest
    ssh vps-vfg "cd [chemin serveur] && \
      docker compose -f compose/t1-core.yml pull vfgate-api && \
      docker compose -f compose/t1-core.yml up -d --no-deps vfgate-api"
    
    # Test
    curl -s https://gate.vfg.lol/api/vfgate/v1/health | jq .
  3. Activer CI/CD (si push manuel OK) :

    • Settings → Secrets and variables → Actions :
      • VPS_HOST=51.77.244.222
      • VPS_USER=deploy
      • [variable d'environnement]=<clé privée SSH>
    • Settings → Variables → Actions : VPS_DEPLOY_ENABLED=true

État : workflow corrigé, désactivé par défaut (opt-in), nécessite validation structure VPS + secrets GitHub.


HANDOFF — Session 29→30 juin 2026 (Stabilisation + rapatriement RAPPORT)

Ce qui a été fait

  • Docs externes mis de côté : les 4 fichiers docs/llm-pricing-*.md sont déplacés dans NE_DOIS_PAS_RESTER_LA/ (dossier ignoré). Un d'eux reste candidat article. docs/INDEX.md mis à jour.
  • tmp-start-session.json conservé et ignoré : utilisé comme payload de test de l'audit session token.
  • RAPPORT-EXPERIENTIEL rapatrié : copié dans [chemin local], réinitialisé en repo Git autonome (git init + commit initial 834b742). Le .git worktree lié au monorepo VFVFGPT a été supprimé.
  • MCP vfg-commands enrichi :
    • VFG_RAPPORT_ROOT configuré dans src/config.js et scripts/start-zed-mcp-servers.ps1.
    • Nouvel outil vfg_commands_md_collect : collecte / copie / déplace récursivement les .md depuis plusieurs répertoires racines, avec préservation optionnelle de la structure.
    • Testé en local : 251 .md collectés sur VFGate + RAPPORT, 77 .md copiés depuis devblog/posts en préservant la structure.

Serveurs MCP actifs (au prochain start-zed-mcp-servers.ps1)

ServeurPortÉtat
neuralwatts-monitor5194✅
vfg-markdown5197✅
vfg-gate4342✅
vfg-feed4341✅
vfg-docs4340✅
agent-telemetry5198✅
vfg-commands5199✅ (+ md_collect)

Notes / décisions

  • Les serveurs MCP source vivent encore dans [chemin local] (clone du monorepo VFVFGPT, branche feat/vfg-commands-mcp). Le patch MCP est commité sous d3495a0.
  • Le repo RAPPORT-EXPERIENTIEL rapatrié est actuellement sur la branche master (commit initial 834b742). Il faudra rebaser/renommer en main ou configurer le remote cible avant push.

TODO

  • Rendre configurable le repo RAPPORT-EXPERIENTIEL dans vfg-commands-mcp via VFG_RAPPORT_ROOT.
  • Diagnostiquer/corriger ADMIN_BACKEND_URL pour vfg_commands_devblog_publish(auto_publish=true) : endpoint corrigé (/admin/api/articles/:id/publish), backend admin :5220 démarré.
  • Rapatrier RAPPORT-EXPERIENTIEL à côté de VFGate dans le nouveau workspace et pointer VFG_RAPPORT_ROOT dessus.
  • Committer les modifications de vfg-commands-mcp (config + devblog + mcp-core).
  • Pousser le repo RAPPORT-EXPERIENTIEL sur main pour déclencher le workflow de déploiement VPS.
  • Valider le tool MCP vfg_commands_md_collect via une session Zed + tmp-start-session.json.

HANDOFF — Session 26 juin 2026 (Swarm boot)


HANDOFF — Session 26 juin 2026 (Swarm boot)

Ce qui a été fait

  • GATE-06 smoke test : ✅ PASS — 13/13 tests smoke OSC routing (/matrice/* → port 8000, /default/* → 8011)
  • Tests : npm test en cours (186 attendus, 185 pré-existants PASS)
  • Plans swarm vague1 : commités dans plans/ (IMPLEMENTATION-SWARM-DECOMPOSITION-FINAL.md, meta/*, recon/s1-gate.md)
  • Worktree isolé : ella sur branche swarm/boot-ella-2026-06-26

État VPS (26 juin 2026)

⚠️ Deploy en attente — Docker non démarré localement. À exécuter :

cd VFGate && docker build -t ghcr.io/fgdidou/vfgate-api:latest .
docker push ghcr.io/fgdidou/vfgate-api:latest
ssh vps-vfg "cd [chemin serveur] && sudo docker compose -f compose/t1-core.yml pull vfgate-api vfgate-admin && sudo docker compose -f compose/t1-core.yml up -d --no-deps vfgate-api vfgate-admin"

HANDOFF — Session 21 juin 2026

Ce qui a été fait

  • Admin UI Routes refonte complète : section "Flux rapides" (Telegram→WA, MSN→WA, WA→TG), labels lisibles, Activer/Désactiver/Supprimer par route, formulaire manuel avec sourceAdapter + targetChannel
  • Router : filtre sourceAdapter optionnel — évite les boucles (ex. msg WA ne reboucle pas sur WA)
  • Schema route : champs label + sourceAdapter ajoutés, rétro-compatibles
  • Image Docker ghcr.io/fgdidou/vfgate-api:latest rebuildée et déployée sur VPS
  • Skill vps-vfgate + rule .cursor/rules/vps-fleet.mdc créés
  • WhatsApp VPS : adapter whatsapp-mqnjl9qh actif, qr_pending — scanner sur gate.vfg.lol → Connexions

État VPS (21 juin 2026)

ContainerPortÉtat
vfg-fleet-vfgate-api-18083✅ nouvelle image
vfg-fleet-vfgate-admin-18084✅ nouveau build UI

Adapters actifs sur VPS :

IDTypeÉtat
stack-telegramtelegram✅
stack-oscosc✅
stack-vfg-herovfg-hero✅
whatsapp-mqnjl9qhwhatsapp🟡 qr_pending — scanner

Routes dupliquées (UUID sans label) encore présentes dans le store — les supprimer via gate.vfg.lol → Routes → Supprimer.

Prochaines actions

IDSujetOwner
WA-QRScanner QR WhatsApp sur gate.vfg.lol → ConnexionsFG
ROUTES-CLEANSupprimer les 4 routes UUID dupliquées chat.* → whatsappFG
GATE-05R2 preuve bot dédié BotFather → Hero event logFG

Cap général du projet

PhaseÉtat
V1 data-hub✅ bridge health/feed/rules
S2 write pipeline✅ forward Hero ingest + hero_quest_id
GATE-03✅ smoke bridge — health agrégé hero+matrice+vfgate
GATE-04✅ TELEGRAM_ENABLED=true · envoi réel
GATE-05🟡 bot dédié BotFather · chat.inbound → Hero ingest
GATE-06🟡 OSC /matrice/* → :8000
Bedtime Call✅ session.end → forward Hero
WhatsApp VPS🟡 adapter déployé · QR à scanner
Routes Flux rapides✅ UI + sourceAdapter filter + label
Multi-plateforme✅ PWA + Electron thin client

Tokens alignés

Clé VFGateAlignement Hero
[variable d'environnement][variable d'environnement] (ingest source:vfgate)
[variable d'environnement]VFG_Hero [variable d'environnement]
[variable d'environnement]Matrice [variable d'environnement]
BRIDGE_WRITE_ENABLED=trueactive le forward ingest

Accès prod

  • Admin : https://gate.vfg.lol (Basic Auth — credentials dans /root/vfg-admin-credentials.txt VPS)
  • API interne VPS : http://[hôte interne]/api/vfgate/v1/health

Tests (2026-06-21)

  • npm test : 185/186 pass (1 failing pré-existant : admin PWA SW check dans admin-dist)
  • npm run smoke:poc : PASS

source markdown

Concepts de cet article

VFGateVPSVFG HerohandoffMCPgateworktreeVFVFGPTMatriceSSOT

Partage le plus de concepts avec