admin_ekaii/ekaii-mirror
1
0
Fork 0
Code Issues 2 Pull requests Projects Releases 8 Packages Wiki Activity Actions

Chat Discord → Minecraft absent : rien ne remplace DiscordSRV, implémenter l'inbound dans EkaiiMirrorVelocity #2

New issue
Closed
opened 2026-08-31 11:19:46 +00:00 by wait4mi · 3 comments
wait4mi commented 2026-08-31 11:19:46 +00:00
Copy link

Symptôme

Les messages écrits par les membres sur le salon Discord du serveur n'arrivent sur aucun des trois serveurs Minecraft (Survie / Créa / Plot). Attendu : la même topologie que le chat inter-serveurs, c'est-à-dire [Discord] <Utilisateur> message visible par tous les joueurs, sur les trois backends.

Lié à #1 (même pont, sens inverse).

Diagnostic (2026-08-31)

Aucun composant n'implémente le sens Discord → MC aujourd'hui. Ce n'est pas une panne mais une fonctionnalité absente depuis la disparition de DiscordSRV.

Composant Discord → MC
EkaiiMirrorVelocity (module velocity-plugin/ de ce repo, sur mc-velocity) ❌ DiscordPublisher est un webhook sortant uniquement (POST HTTP). Aucun listener gateway, aucune clé bot-token dans MirrorConfig, aucun code inbound.
exo/ekaii-bot (NAS) ❌ galerie 🖼️ + /whitelist + comptes Jellyfin. Aucun relais de chat.
EkaiiAPI ❌ endpoints ping/players/banned/whitelist seulement, pas de chat/broadcast.
DiscordSRV (creaclone) C'était lui qui le faisait (bot Discord « Ekaii »), mais il ne tourne plus.

Preuves que DiscordSRV est mort depuis longtemps :

  • aucun jar DiscordSRV* sur minis (ni .superseded, ni .old, ni plugins/.bak/) ; il n'a jamais été listé dans plugins/manifest.yml du GitOps ;
  • aucun log creaclone archivé ne le mentionne, depuis le plus ancien conservé (2026-05-09-1.log.gz) ;
  • ses fichiers de config sur disque ont été réécrits pour la dernière fois par le plugin lui-même le 2025-11-28 ;
  • pourtant sessions/2026-05-22.md du repo GitOps (« DSRV stays on creaclone only ») et les messages des commits v1.2.0 / v1.3.0 ici partent du principe qu'il tourne → perdu sans que personne ne s'en aperçoive, entre fin nov. 2025 et début mai 2026 (migration creaclone probable).
  • Le GitOps continue de rendre une config morte : services/creaclone/plugins-config/DiscordSRV/ + variable CREACLONE_DISCORDSRV_BOT_TOKEN dans ENVSUBST_VARS.

Le bot Discord « Ekaii » existe toujours et son token (dans secrets.env de minis, hors repo) est valide (vérifié via GET /users/@me) → réutilisable.

Pourquoi ne pas simplement réinstaller DiscordSRV

  • Il n'injecterait le message que sur creaclone : le chat partagé Velocity ne relaie que les PlayerChatEvent, pas les messages système → Survie et Plot ne verraient rien (c'est le problème inverse décrit dans le commit v1.3.0).
  • Compat Folia (Lophine 26.2) incertaine, et ça remettrait un second bridge à côté de DiscordPublisher.

Proposition : implémenter l'inbound dans EkaiiMirrorVelocity

Le proxy possède déjà le chat inter-serveurs (ChatBridge.java:43, format <Pseudo> message envoyé à tous les joueurs des autres backends). Même mécanique, source différente.

Côté code (velocity-plugin/)

  1. Nouvelle classe DiscordInbound : connexion gateway Discord avec le bot existant (JDA shadé, ou client WebSocket minimal : Identify avec intents GUILDS | GUILD_MESSAGES | MESSAGE_CONTENT, heartbeat, reconnect/resume). Tourne sur un thread dédié, jamais sur les threads du proxy.
  2. Sur MESSAGE_CREATE :
    • filtrer channel_id == discord.inbound.channel-id ;
    • ignorer author.bot == true et webhook_id != null — sinon boucle infinie avec le webhook EkaiiSRV qui republie le chat MC ;
    • ignorer les messages vides (embeds/pièces jointes seules) ;
    • résoudre author.global_name ou username (pas le pseudo de serveur, pas les mentions brutes ; remplacer <@id> par @Nom si simple, sinon laisser tel quel) ;
    • tronquer à ~256 caractères et retirer les codes de formatage §.
  3. Diffuser à tous les joueurs de tous les backends (server.getAllPlayers()), Component construit sans MiniMessage parsé depuis le texte utilisateur (anti-injection) : [Discord] <Nom> message, préfixe coloré (proposition : [Discord] en bleu, comme la couleur du webhook), texte en gris clair.
  4. Optionnel : les commandes ne sont pas relayées (/… ignoré), et rate-limit simple (ex. 5 msg/s max) pour éviter le spam depuis Discord.

Côté config (velocity-plugin/src/main/resources/config.yml)

discord:
  enabled: true
  webhook-url: "…"
  inbound:
    enabled: true
    bot-token: "${DISCORD_BOT_TOKEN}"     # rendu par le GitOps (envsubst), jamais en clair dans le repo
    channel-id: "…"                       # le salon chat déjà utilisé par le webhook
    format: "[Discord] <{name}> {message}"

Côté Discord (portail développeur, bot « Ekaii »)

  • activer l'intent Message Content (sans lui content arrive vide) ;
  • vérifier que le bot est bien membre du serveur et a la permission View Channel + Read Message History sur le salon.

Côté GitOps (exo/ekaii-mc-stack)

  • renommer CREACLONE_DISCORDSRV_BOT_TOKEN → DISCORD_BOT_TOKEN dans secrets.env (minis) et ENVSUBST_VARS (scripts/lib/common.sh) ; le rendre dans services/velocity/…/config.yml ;
  • supprimer services/creaclone/plugins-config/DiscordSRV/ (config morte) + le dossier orphelin creaclone/plugins/DiscordSRV/ sur minis ; mettre à jour docs/STACK.md et templates/CLAUDE.md ;
  • bump du manifest velocity → release contenant ce travail (peut être la même v1.4.2 que #1, ou une v1.5.0 dédiée) → restart Velocity (~35 s, chat/TAB coupés, à faire en heure creuse).

Test d'acceptation

  1. Un membre écrit sur le salon Discord → les joueurs connectés sur Survie, Créa et Plot voient [Discord] <Nom> message.
  2. Un joueur écrit en jeu → le message apparaît sur Discord via le webhook une seule fois (pas d'écho vers le jeu).
  3. Un message bot/webhook sur le salon n'apparaît pas en jeu.
  4. Un message avec §c ou une balise MiniMessage arrive en texte brut en jeu.

Statut

  • Feu vert d'exo sur le principe (inbound dans le proxy plutôt que DiscordSRV)
  • Intent Message Content activé sur le bot
  • Implémentation DiscordInbound + config
  • GitOps : secret renommé, config DSRV supprimée, manifest bumpé
  • Validation en prod (4 tests ci-dessus)
## Symptôme Les messages écrits par les membres sur le salon Discord du serveur n'arrivent sur **aucun** des trois serveurs Minecraft (Survie / Créa / Plot). Attendu : la même topologie que le chat inter-serveurs, c'est-à-dire `[Discord] <Utilisateur> message` visible par tous les joueurs, sur les trois backends. Lié à #1 (même pont, sens inverse). ## Diagnostic (2026-08-31) **Aucun composant n'implémente le sens Discord → MC aujourd'hui.** Ce n'est pas une panne mais une fonctionnalité absente depuis la disparition de DiscordSRV. | Composant | Discord → MC | |---|---| | `EkaiiMirrorVelocity` (module `velocity-plugin/` de ce repo, sur `mc-velocity`) | ❌ `DiscordPublisher` est un **webhook sortant** uniquement (POST HTTP). Aucun listener gateway, aucune clé `bot-token` dans `MirrorConfig`, aucun code inbound. | | `exo/ekaii-bot` (NAS) | ❌ galerie 🖼️ + `/whitelist` + comptes Jellyfin. Aucun relais de chat. | | `EkaiiAPI` | ❌ endpoints `ping/players/banned/whitelist` seulement, pas de `chat`/`broadcast`. | | DiscordSRV (creaclone) | C'était **lui** qui le faisait (bot Discord « Ekaii »), mais il **ne tourne plus**. | Preuves que DiscordSRV est mort depuis longtemps : - aucun jar `DiscordSRV*` sur minis (ni `.superseded`, ni `.old`, ni `plugins/.bak/`) ; il n'a jamais été listé dans `plugins/manifest.yml` du GitOps ; - aucun log creaclone archivé ne le mentionne, depuis le plus ancien conservé (`2026-05-09-1.log.gz`) ; - ses fichiers de config sur disque ont été réécrits pour la dernière fois par le plugin lui-même le **2025-11-28** ; - pourtant `sessions/2026-05-22.md` du repo GitOps (« DSRV stays on creaclone only ») et les messages des commits v1.2.0 / v1.3.0 ici partent du principe qu'il tourne → perdu sans que personne ne s'en aperçoive, entre fin nov. 2025 et début mai 2026 (migration creaclone probable). - Le GitOps continue de rendre une config morte : `services/creaclone/plugins-config/DiscordSRV/` + variable `CREACLONE_DISCORDSRV_BOT_TOKEN` dans `ENVSUBST_VARS`. Le bot Discord « Ekaii » existe toujours et son token (dans `secrets.env` de minis, hors repo) est **valide** (vérifié via `GET /users/@me`) → réutilisable. ## Pourquoi ne pas simplement réinstaller DiscordSRV - Il n'injecterait le message que sur **creaclone** : le chat partagé Velocity ne relaie que les `PlayerChatEvent`, pas les messages système → Survie et Plot ne verraient rien (c'est le problème inverse décrit dans le commit v1.3.0). - Compat Folia (Lophine 26.2) incertaine, et ça remettrait un second bridge à côté de `DiscordPublisher`. ## Proposition : implémenter l'inbound dans `EkaiiMirrorVelocity` Le proxy possède déjà le chat inter-serveurs (`ChatBridge.java:43`, format `<Pseudo> message` envoyé à tous les joueurs des autres backends). Même mécanique, source différente. **Côté code (`velocity-plugin/`)** 1. Nouvelle classe `DiscordInbound` : connexion **gateway Discord** avec le bot existant (JDA shadé, ou client WebSocket minimal : `Identify` avec intents `GUILDS | GUILD_MESSAGES | MESSAGE_CONTENT`, heartbeat, reconnect/resume). Tourne sur un thread dédié, jamais sur les threads du proxy. 2. Sur `MESSAGE_CREATE` : - filtrer `channel_id == discord.inbound.channel-id` ; - **ignorer `author.bot == true` et `webhook_id != null`** — sinon boucle infinie avec le webhook `EkaiiSRV` qui republie le chat MC ; - ignorer les messages vides (embeds/pièces jointes seules) ; - résoudre `author.global_name` ou `username` (pas le pseudo de serveur, pas les mentions brutes ; remplacer `<@id>` par `@Nom` si simple, sinon laisser tel quel) ; - tronquer à ~256 caractères et retirer les codes de formatage `§`. 3. Diffuser à **tous les joueurs de tous les backends** (`server.getAllPlayers()`), `Component` construit sans MiniMessage parsé depuis le texte utilisateur (anti-injection) : `[Discord] <Nom> message`, préfixe coloré (proposition : `[Discord]` en bleu, comme la couleur du webhook), texte en gris clair. 4. Optionnel : les commandes ne sont pas relayées (`/…` ignoré), et rate-limit simple (ex. 5 msg/s max) pour éviter le spam depuis Discord. **Côté config (`velocity-plugin/src/main/resources/config.yml`)** ```yaml discord: enabled: true webhook-url: "…" inbound: enabled: true bot-token: "${DISCORD_BOT_TOKEN}" # rendu par le GitOps (envsubst), jamais en clair dans le repo channel-id: "…" # le salon chat déjà utilisé par le webhook format: "[Discord] <{name}> {message}" ``` **Côté Discord (portail développeur, bot « Ekaii »)** - activer l'intent **Message Content** (sans lui `content` arrive vide) ; - vérifier que le bot est bien membre du serveur et a la permission *View Channel* + *Read Message History* sur le salon. **Côté GitOps (`exo/ekaii-mc-stack`)** - renommer `CREACLONE_DISCORDSRV_BOT_TOKEN` → `DISCORD_BOT_TOKEN` dans `secrets.env` (minis) et `ENVSUBST_VARS` (`scripts/lib/common.sh`) ; le rendre dans `services/velocity/…/config.yml` ; - supprimer `services/creaclone/plugins-config/DiscordSRV/` (config morte) + le dossier orphelin `creaclone/plugins/DiscordSRV/` sur minis ; mettre à jour `docs/STACK.md` et `templates/CLAUDE.md` ; - bump du manifest `velocity` → release contenant ce travail (peut être la même `v1.4.2` que #1, ou une `v1.5.0` dédiée) → restart Velocity (~35 s, chat/TAB coupés, à faire en heure creuse). ## Test d'acceptation 1. Un membre écrit sur le salon Discord → les joueurs connectés sur Survie, Créa **et** Plot voient `[Discord] <Nom> message`. 2. Un joueur écrit en jeu → le message apparaît sur Discord via le webhook **une seule fois** (pas d'écho vers le jeu). 3. Un message bot/webhook sur le salon n'apparaît pas en jeu. 4. Un message avec `§c` ou une balise MiniMessage arrive en texte brut en jeu. ## Statut - [x] Feu vert d'exo sur le principe (inbound dans le proxy plutôt que DiscordSRV) - [x] Intent Message Content activé sur le bot - [x] Implémentation `DiscordInbound` + config - [x] GitOps : secret renommé, config DSRV supprimée, manifest bumpé - [x] Validation en prod (4 tests ci-dessus)
admin_ekaii commented 2026-08-31 11:29:31 +00:00
Owner
Copy link

Investigation indépendante (2026-08-31) — diagnostic CONFIRMÉ, proposition viable, 2 corrections au plan

Tout re-vérifié depuis une session distincte :

Claim Vérif
Aucun inbound dans EkaiiMirrorVelocity ✅ confirmé sur le code v1.4.2 (relu intégralement pour #1) : DiscordPublisher = POST webhook sortant uniquement, aucun listener gateway, pas de bot-token dans MirrorConfig.
DiscordSRV mort ✅ aucun jar *discordsrv* sur minis (seulement 3 dossiers de config : gitops source, snapshot, et creaclone/plugins/DiscordSRV/ orphelin, dernier write par le plugin nov. 2025).
Token bot « Ekaii » valide ✅ GET /users/@me depuis minis → Ekaii (id 1194298459910570114), membre du seul guild Ekaii (1185979056626356265), voit le salon 📼︱serveur (1186576981156954122). Le token n'a pas quitté minis.
ENVSUBST_VARS contient CREACLONE_DISCORDSRV_BOT_TOKEN ✅ scripts/lib/common.sh:67, mécanisme allowlist opérationnel — le rendu du token dans la config velocity marchera tel que proposé.

Corrections au plan :

  1. L'intent Message Content est DÉJÀ activé — GET /applications/@me → flags 565248 : GATEWAY_MESSAGE_CONTENT_LIMITED (+ members/presence limited). C'est la variante « bot non vérifié <100 guilds », suffisante ici. La case « activer l'intent » du statut est donc déjà acquise, rien à faire côté portail.
  2. Ne pas réutiliser v1.4.2 : release déjà publiée et déployée (fix #1, avatars). L'inbound est une feature → v1.5.0.

Avis sur l'implémentation : l'approche (inbound dans le proxy, diffusion getAllPlayers()) est la bonne — c'est le seul composant qui voit les trois backends, et ça évite de ressusciter un second bridge. Sur le point « JDA shadé ou client WS minimal » : recommande JDA relocaté (intents GUILD_MESSAGES|MESSAGE_CONTENT seulement, caches désactivés, ChunkingFilter.NONE). Un client gateway artisanal doit gérer heartbeat/ACK, resume vs re-identify, invalid session, zombie connections — c'est exactement le genre de code qui marche en test et meurt silencieusement en prod un mois plus tard. Le poids du jar (~+12 Mo) est sans enjeu sur le proxy. Les filtres anti-boucle proposés (author.bot, webhook_id != null) sont corrects et indispensables avec le webhook EkaiiSRV sur le même salon ; garder aussi le strip § + pas de parse MiniMessage du texte utilisateur.

Point d'attention au moment du GitOps : le token rendu en clair dans /opt/mc-stack/velocity/plugins/ekaii-mirror-velocity/config.yml — vérifier les permissions du fichier rendu (même exposition que l'ancienne config DSRV, mais autant le noter).

Reste gated sur le feu vert d'exo (principe + go déploiement) — implémentation non lancée, conformément au statut de l'issue.

🤖 Investigation par Claude (session autonome, à la demande de Paul).

## Investigation indépendante (2026-08-31) — diagnostic CONFIRMÉ, proposition viable, 2 corrections au plan **Tout re-vérifié depuis une session distincte :** | Claim | Vérif | |---|---| | Aucun inbound dans `EkaiiMirrorVelocity` | ✅ confirmé sur le code v1.4.2 (relu intégralement pour #1) : `DiscordPublisher` = POST webhook sortant uniquement, aucun listener gateway, pas de `bot-token` dans `MirrorConfig`. | | DiscordSRV mort | ✅ aucun jar `*discordsrv*` sur minis (seulement 3 dossiers de config : gitops source, snapshot, et `creaclone/plugins/DiscordSRV/` orphelin, dernier write par le plugin nov. 2025). | | Token bot « Ekaii » valide | ✅ `GET /users/@me` depuis minis → `Ekaii` (id `1194298459910570114`), membre du seul guild `Ekaii` (`1185979056626356265`), voit le salon `📼︱serveur` (`1186576981156954122`). Le token n'a pas quitté minis. | | `ENVSUBST_VARS` contient `CREACLONE_DISCORDSRV_BOT_TOKEN` | ✅ `scripts/lib/common.sh:67`, mécanisme allowlist opérationnel — le rendu du token dans la config velocity marchera tel que proposé. | **Corrections au plan :** 1. **L'intent Message Content est DÉJÀ activé** — `GET /applications/@me` → flags `565248` : `GATEWAY_MESSAGE_CONTENT_LIMITED` (+ members/presence limited). C'est la variante « bot non vérifié <100 guilds », suffisante ici. La case « activer l'intent » du statut est donc déjà acquise, rien à faire côté portail. 2. **Ne pas réutiliser `v1.4.2`** : release déjà publiée et déployée (fix #1, avatars). L'inbound est une feature → `v1.5.0`. **Avis sur l'implémentation :** l'approche (inbound dans le proxy, diffusion `getAllPlayers()`) est la bonne — c'est le seul composant qui voit les trois backends, et ça évite de ressusciter un second bridge. Sur le point « JDA shadé ou client WS minimal » : **recommande JDA relocaté** (intents `GUILD_MESSAGES|MESSAGE_CONTENT` seulement, caches désactivés, `ChunkingFilter.NONE`). Un client gateway artisanal doit gérer heartbeat/ACK, resume vs re-identify, invalid session, zombie connections — c'est exactement le genre de code qui marche en test et meurt silencieusement en prod un mois plus tard. Le poids du jar (~+12 Mo) est sans enjeu sur le proxy. Les filtres anti-boucle proposés (`author.bot`, `webhook_id != null`) sont corrects et indispensables avec le webhook `EkaiiSRV` sur le même salon ; garder aussi le strip `§` + pas de parse MiniMessage du texte utilisateur. Point d'attention au moment du GitOps : le token rendu en clair dans `/opt/mc-stack/velocity/plugins/ekaii-mirror-velocity/config.yml` — vérifier les permissions du fichier rendu (même exposition que l'ancienne config DSRV, mais autant le noter). **Reste gated sur le feu vert d'exo** (principe + go déploiement) — implémentation non lancée, conformément au statut de l'issue. 🤖 Investigation par Claude (session autonome, à la demande de Paul).
admin_ekaii commented 2026-08-31 11:50:03 +00:00
Owner
Copy link

Implémenté et DÉPLOYÉ EN PROD (2026-08-31, v1.5.0) — go de Paul

Livré :

  • DiscordInbound (main 47fabeb, cherry-pick mc-26.2) : gateway avec le bot « Ekaii » existant, JDA 5.6.1 shadé (slf4j exclu → binding Velocity ; opus exclu ; pas de relocation, classloader plugin isolé ; jar 16,3 Mo), intents GUILD_MESSAGES|MESSAGE_CONTENT (GUILDS est implicite dans JDA, pas dans l'enum). Diffusion getAllPlayers() : [Discord] blurple + <Nom> + message gris. Anti-boucle author.bot || isWebhookMessage(), mentions résolues (getContentDisplay), § retirés, jamais parsé en MiniMessage, tronqué à 256, /… ignorés, rate-limit 5 msg/s, shutdownNow() sur ProxyShutdown. Config discord.inbound.{enabled, bot-token, channel-id}, off par défaut.
  • Écarts vs la proposition : pas de clé format (structure fixe, les couleurs n'y seraient pas exprimables — YAGNI) ; nom affiché = global_name/username comme spécifié.
  • Smoke test AVANT déploiement : jar shadé exécuté dans le conteneur mc-velocity (Java 25) avec le vrai token (jamais sorti de minis) → READY as Ekaii, salon 📼︱serveur visible.
  • GitOps : commit A (b10ee5b) CREACLONE_DISCORDSRV_BOT_TOKEN→DISCORD_BOT_TOKEN dans ENVSUBST_VARS+docs, config DSRV morte supprimée du repo, secrets.env renommé (0600 conservé), dossier live orphelin déplacé en .DiscordSRV.removed-20260831 (pas de hard-delete). Poussé en deux commits séparés à cause du gotcha « common.sh sourcé avant git reset ». Commit B (dcf0a04) : manifest 1.5.0 + bloc inbound rendu par envsubst.
  • Restart graceful velocity 11:48Z (broadcast 30 s, 2 joueurs).

Vérifications prod :

  • Loaded plugin ekaii-mirror-velocity 1.5.0 ; [DiscordInbound] gateway READY as Ekaii — listening on channel 1186576981156954122 dans le proxy → token envsubst OK.
  • Tests d'acceptation : T3 ✅ message bot ET message webhook postés dans le salon pendant l'écoute → aucun relais (logs vierges), supprimés après. T2 ✅ (anti-écho = même filtre webhook, vérifié ; l'outbound unique était déjà validé en 1.4.2). T4 garanti par construction (Component texte brut, § strippés). T1 (message d'un membre humain → visible en jeu) : en attente du premier message réel — je ne peux pas en fabriquer un (tout ce que je peux poster est bot/webhook, filtré par design). Un watch est armé sur les logs : le premier message d'un membre le confirmera. N'importe qui peut écrire une ligne dans 📼︱serveur pour clore.

Rollback : manifest → 1.4.2 (l'inbound disparaît, l'outbound 1.4.2 reste).

🤖 Implémenté, déployé et vérifié par Claude (session autonome, go explicite de Paul).

## Implémenté et DÉPLOYÉ EN PROD (2026-08-31, v1.5.0) — go de Paul **Livré :** - `DiscordInbound` (main 47fabeb, cherry-pick `mc-26.2`) : gateway avec le bot « Ekaii » existant, **JDA 5.6.1 shadé** (slf4j exclu → binding Velocity ; opus exclu ; pas de relocation, classloader plugin isolé ; jar 16,3 Mo), intents `GUILD_MESSAGES|MESSAGE_CONTENT` (GUILDS est implicite dans JDA, pas dans l'enum). Diffusion `getAllPlayers()` : `[Discord]` blurple + `<Nom>` + message gris. Anti-boucle `author.bot || isWebhookMessage()`, mentions résolues (`getContentDisplay`), `§` retirés, jamais parsé en MiniMessage, tronqué à 256, `/…` ignorés, rate-limit 5 msg/s, `shutdownNow()` sur ProxyShutdown. Config `discord.inbound.{enabled, bot-token, channel-id}`, off par défaut. - Écarts vs la proposition : pas de clé `format` (structure fixe, les couleurs n'y seraient pas exprimables — YAGNI) ; nom affiché = `global_name`/`username` comme spécifié. - **Smoke test AVANT déploiement** : jar shadé exécuté dans le conteneur mc-velocity (Java 25) avec le vrai token (jamais sorti de minis) → `READY as Ekaii`, salon `📼︱serveur` visible. - GitOps : commit A (b10ee5b) `CREACLONE_DISCORDSRV_BOT_TOKEN`→`DISCORD_BOT_TOKEN` dans `ENVSUBST_VARS`+docs, config DSRV morte supprimée du repo, `secrets.env` renommé (0600 conservé), dossier live orphelin déplacé en `.DiscordSRV.removed-20260831` (pas de hard-delete). Poussé en deux commits séparés à cause du gotcha « common.sh sourcé avant git reset ». Commit B (dcf0a04) : manifest 1.5.0 + bloc `inbound` rendu par envsubst. - Restart graceful velocity 11:48Z (broadcast 30 s, 2 joueurs). **Vérifications prod :** - `Loaded plugin ekaii-mirror-velocity 1.5.0` ; `[DiscordInbound] gateway READY as Ekaii — listening on channel 1186576981156954122` **dans le proxy** → token envsubst OK. - Tests d'acceptation : **T3 ✅** message bot ET message webhook postés dans le salon pendant l'écoute → aucun relais (logs vierges), supprimés après. **T2 ✅** (anti-écho = même filtre webhook, vérifié ; l'outbound unique était déjà validé en 1.4.2). **T4** garanti par construction (Component texte brut, `§` strippés). **T1 (message d'un membre humain → visible en jeu) : en attente du premier message réel** — je ne peux pas en fabriquer un (tout ce que je peux poster est bot/webhook, filtré par design). Un watch est armé sur les logs : le premier message d'un membre le confirmera. N'importe qui peut écrire une ligne dans `📼︱serveur` pour clore. Rollback : manifest → 1.4.2 (l'inbound disparaît, l'outbound 1.4.2 reste). 🤖 Implémenté, déployé et vérifié par Claude (session autonome, go explicite de Paul).
admin_ekaii commented 2026-08-31 11:51:06 +00:00
Owner
Copy link

T1 validé en live (11:49–11:50Z) : messages réels de Wait4Mi relayés en jeu (« Niquel on a bien dans les deux sens » … « Parfait 👍 »), symétrie confirmée par lui côté jeu. Les 4 tests d'acceptation sont verts → close.

🤖 Claude

**T1 validé en live (11:49–11:50Z)** : messages réels de Wait4Mi relayés en jeu (« Niquel on a bien dans les deux sens » … « Parfait 👍 »), symétrie confirmée par lui côté jeu. Les 4 tests d'acceptation sont verts → close. 🤖 Claude
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
mc-26.3
mc-26.2
v1.0.0-backend-mc26.3-pre2
v1.5.0-backend-mc26.2
v1.5.0
v1.4.2
v1.4.1
v1.4.0
v1.1.0
v1.0.0
Labels
Clear labels   
feature request
Amélioration / suggestion, pas un bug

No labels
feature request
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
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
admin_ekaii/ekaii-mirror#2
No description provided.