Skip to content

claudish: la cle cliente du proxy n'a aucun organe de propagation — CLAUDISH_PROXY_KEY absent de SECRET_KEYS #14926

Open
Open
claudish: la cle cliente du proxy n'a aucun organe de propagation — CLAUDISH_PROXY_KEY absent de SECRET_KEYS#14926

Description

@jsboige
jsboige
opened on Sep 6, 2026

État mesuré au 2026-10-06 par myia-po-2027:CoursIA (preflight de claim, lecture firsthand de origin/main). Ce qui suit conserve l'historique ; la mesure d'origine date du commit 36c2c130f et est périmée sur l'acceptance 1 :

Une lane qui tire cette issue prend donc la tranche consommateurs (3-4), pas la recréation de l'organe.

Le defaut

La rotation de la cle du service vLLM local est decidee (arbitrage user 2026-09-06). La doctrine qui l'accompagne est que claudish devient le seul detenteur des credentials fournisseurs : les consommateurs cessent de porter la cle du service et s'authentifient aupres du proxy avec l'en-tete de securite claudish.

Ce geste n'a aucun organe de propagation dans CoursIA aujourd'hui.

Mesure sur main (36c2c130f) :

present dans SECRET_KEYS (scripts/secrets/render_envs.py) occurrences dans le depot
VLLM_API_KEY oui (l.158) 21 fichiers
CLAUDISH_PROXY_KEY non 1 — la prose de docs/genai/auth-flip-runbook.md

Le pipeline canonique .secrets/master.env -> render_envs.py -> .env de chaque service sait donc distribuer la cle qu'on veut retirer des consommateurs, et ne sait pas distribuer celle qu'on veut leur donner. En l'etat, chaque machine devrait la poser a la main, sans --check pour detecter la derive.

Le precedent est deja dans le fichier, et il dit quoi faire

SECRET_KEYS porte deja exactement ce cas de figure pour Qdrant, avec sa justification ecrite (l.166-171) :

the Qdrant SERVER reads the SAME value under the double-underscore name QDRANT__SERVICE__API_KEY. The server compose lives in the roo-extensions repo (NOT CoursIA); only the CLIENT key is centralized here so notebook consumers stay in lock-step with the server on rotation.

Claudish est structurellement identique : son compose vit dans D:\Dev\claudish (hors CoursIA), la variable serveur est CLAUDISH_PROXY_KEY, et ce qu'on centralise ici est la valeur cliente, pour que les consommateurs restent en phase avec le serveur a chaque rotation.

Le circuit est deja wire-compatible — c'est bien un trou de distribution, pas de code

  • proxy-auth.ts accepte trois en-tetes (x-proxy-key, x-api-key, Authorization: Bearer) — cf auth-flip-runbook.md l.44-47.
  • Le helper MyIA.AI.Notebooks/GenAI/Vibe-Coding/Claudish/notebooks/helpers/claudish_client.py envoie deja x-api-key (l.111, l.157) et lit CLAUDISH_BASE_URL (l.30, defaut http://localhost:3000).

Rien a ecrire cote transport. Ce qui manque est que la valeur arrive sur chaque machine par le meme chemin que les autres secrets.

Surface a accompagner (mesure firsthand, instrument validee par controle positif)

8 fichiers lisent effectivement la variable a l'execution (parse JSON des cellules de code, pas un grep de chaine — un grep naif n'en trouve 1 parce que dans un .ipynb les quotes doubles sont echappees) :

  • MyIA.AI.Notebooks/GameTheory/GameTheory-03c-Le-Joueur-LLM.ipynb
  • MyIA.AI.Notebooks/GameTheory/GameTheory-28b-Humour-Banc-Dur.ipynb
  • MyIA.AI.Notebooks/GenAI/RAG-et-Memoire-Semantique/09-KernelMemory-Multimodal.ipynb
  • MyIA.AI.Notebooks/GenAI/SemanticKernel/04-SemanticKernel-Filters-Observability.ipynb
  • MyIA.AI.Notebooks/GenAI/Texte/10_LocalLlama.ipynb
  • MyIA.AI.Notebooks/GenAI/Texte/10c_Long_Context_Strategies.ipynb
  • MyIA.AI.Notebooks/GenAI/_research/e2e_quant_validation.ipynb
  • translations/genai/texte.csv (derive — suit sa source)

13 autres fichiers mentionnent la variable sans la lire (.env.example, docs, compose, tests) : ils suivent, ils ne bloquent pas.

Acceptance

  1. CLAUDISH_PROXY_KEY entre dans SECRET_KEYS, avec un commentaire calque sur celui de QDRANT_API_KEY : nommer que le compose serveur vit hors CoursIA, et que c'est la valeur cliente qui est centralisee ici.
  2. python scripts/secrets/render_envs.py --check rend 0 apres propagation (pas de derive entre master.env et les .env consommateurs).
  3. Les 8 consommateurs runtime pointent CLAUDISH_BASE_URL et presentent l'en-tete claudish, au lieu de porter la cle du service.
  4. Une PR par notebook ou par groupe homogene, avec re-execution reelle — un changement de cible d'inference change les sorties, et C.2 interdit de committer un notebook non re-execute. Ce n'est pas un sed de masse.

Hors perimetre

  • La rotation elle-meme et son broadcast : mandat user vers la lane dediee, pas cette issue.
  • Le flip d'auth du proxy (#16 P2, auth-flip-runbook.md Phase 1) : c'est ce qui rend l'en-tete obligatoire ; ici on ne traite que la distribution de la valeur cliente.
  • Aucune valeur de secret ne figure dans cette issue, et aucune ne doit y figurer : depot public.

Activity

  1. jsboige commented on Sep 6, 2026

    @jsboige
    jsboige
    on Sep 6, 2026
    OwnerAuthor

    Mesure complementaire — le perimetre est plus large que le corps de l'issue, dans deux directions

    Mesure firsthand sur 36c2c130f, traces historiques du prover exclues (agent_tests/prover/baselines/traces/ : des enregistrements, pas des consommateurs).

    1. Le geste a DEUX moities, et seule la premiere etait decrite

    surface fichiers organe de propagation
    lit VLLM_API_KEY a l'execution 8 SECRET_KEYS l.158 — existe
    porte une adresse en dur 16 aucun
    … 192.168.0.47:5002 (LAN, vLLM direct) 12
    … api.medium.text-generation-webui.myia.io (reverse-proxy) 6
    deja sur CLAUDISH_BASE_URL 2 (famille Claudish seule)
    total concerne 19

    Retirer la cle aux consommateurs ne suffit donc pas a les faire passer par claudish : 16 fichiers nomment leur cible en dur, et aucune variable ne porte cette cible hors de la famille Claudish. CLAUDISH_BASE_URL n'est pas un secret — c'est de la config de service, qui reste par .env — mais rien ne la lit aujourd'hui.

    2. Deux plans d'authentification, pas un

    Les consommateurs se repartissent sur deux chemins distincts vers le meme modele :

    • direct LAN 192.168.0.47:5002 — authentifie par la cle du serveur vLLM (VLLM_API_KEY) ;
    • reverse-proxy *.myia.io — authentifie par une cle validee en regle IIS URL Rewrite.

    Ce second plan a deja son organe, que le corps de l'issue ne mentionnait pas : scripts/genai-stack/Manage-ApiKeys.ps1 (-Action Generate|Configure|List|Export, New-SecureApiKey -Length 32, stockage D:\Production\.secrets\api-keys.json), avec scripts/genai-stack/Configure-IISAuthentication.ps1 pour la partie authentification. Toute rotation qui ignore ce plan laisse un chemin d'acces sur l'ancienne valeur.

    3. Surfaces a re-pointer, au-dela des notebooks

    Deux categories que l'acceptance initiale ne couvrait pas :

    • .NET / Aspire — GenAiStackReel.AppHost/apphost.cs et …AppHost-wt2/apphost.cs (+ Aspire/02-Aspire-GenAiStack-Reel.ipynb) : adresse LAN en dur, genre refactor/notebook-dotnet, pas notebook-python.
    • Harnais — docs/reference/cluster-agents.md pointe l'IP ; MyIA.AI.Notebooks/GenAI/.env.example porte les deux formes d'adresse.

    4. Ce qui ne va PAS dans une acceptance, et qui doit etre dit quand meme

    Un troisieme detenteur de credential vit hors du depot et hors de tout organe : ~/.claudish/config.json, champ customEndpoints/vllm-myia/apiKey, par machine. Compare par empreinte (aucune valeur lue, aucune publiee) : elle est distincte de celle que .secrets/master.env propage. claudish n'utilise donc pas la meme cle que les consommateurs, et aucun rendu ne met ce fichier a jour — une rotation qui l'oublie coupe claudish sur chaque machine.

    Question ouverte, qui n'appartient pas a cette issue : le service accepte-t-il les deux credentials, ou le reverse-proxy re-authentifie-t-il ? La reponse decide si la rotation coupe claudish. Elle revient a la lane que le user mandate pour la rotation.

    Acceptance revisee proposee

    Aux 4 points du corps, ajouter :

    1. Le re-pointage est explicite : les 16 porteurs d'adresse en dur passent par CLAUDISH_BASE_URL, et ce n'est pas un sous-produit du changement de credential.
    2. Manage-ApiKeys.ps1 / Configure-IISAuthentication.ps1 sont nommes comme plan d'authentification distinct, avec le geste qui leur correspond.
    3. Le sort de ~/.claudish/config.json (par machine, hors organe) est tranche — rendu par un organe, ou declare explicitement hors perimetre avec le geste manuel qui le couvre.

    Aucune valeur de secret ne figure ici et aucune ne doit y figurer : depot public. Les comparaisons ci-dessus sont des empreintes, jamais des valeurs, et les empreintes elles-memes ne sont pas publiees.

  2. jsboige commented on Sep 6, 2026

    @jsboige
    jsboige
    on Sep 6, 2026
    OwnerAuthor

    ⚠ Correction — les points 3 et 5 nomment la mauvaise cible

    Le point 3 du corps et le point 5 de mon commentaire précédent sont faux, et il faut les corriger avant qu'une lane ne les exécute : tous deux prescrivent CLAUDISH_BASE_URL comme cible de re-pointage. Une lane appliquant cette consigne câblerait une base URL du protocole Anthropic dans un client OpenAI.

    Mesure firsthand, ce jour.

    La cause : claudish expose DEUX protocoles, pas un

    protocole base URL consommateurs concernés ici
    Anthropic CLAUDISH_BASE_URL / ANTHROPIC_BASE_URL (:3000) la famille Claudish elle-même (les 2 fichiers déjà migrés)
    OpenAI https://models.myia.io/v1 (ou http://localhost:3002/v1) tous les autres : SemanticKernel, OpenAI SDK, KernelMemory, .NET/Aspire

    Les 19 fichiers recensés sont écrasamment du second groupe. CLAUDISH_BASE_URL est la bonne variable pour la famille Claudish uniquement — c'est précisément pourquoi elle n'est lue que là, et j'ai lu cette absence à l'envers : comme un trou à combler partout, alors qu'elle marque une frontière de protocole.

    GET https://models.myia.io/v1/models répond 200 et catalogue 21 modèles (qwen 3.6→3.8, glm 4.7→5.3, gpt-5.5/5.6, deepseek-v4, mistral/codestral, MiniMax-M3). Le choix de moteur redevient une chaîne de caractères.

    L'en-tête : les trois formes marchent — mesuré avec contrôle négatif

    POST /v1/chat/completions, modèle cloud, en-tête portant la valeur de CLAUDISH_PROXY_KEY :

    en-tête clé valide clé bidon
    x-proxy-key 200 401
    x-api-key 200 401
    Authorization: Bearer 200 401
    (aucun en-tête) — 401

    Le contrôle négatif discrimine : ce ne sont pas des 200 de complaisance. La note du corps (« proxy-auth.ts accepte trois en-têtes », d'après le runbook) passe donc de RAPPORTÉ à VÉRIFIÉ.

    Conséquence pratique, et elle allège le travail : claudish_client.py envoie déjà x-api-key (l.111, l.157). Les 8 consommateurs runtime n'ont pas besoin d'un changement d'en-tête — seulement de la base URL et de la valeur. Le point 3 réclamait un geste qui n'a pas lieu d'être.

    Le point 7 est répondu, il n'est plus ouvert

    ~/.claudish/config.json ne porte que les credentials sortants de claudish vers ses fournisseurs — vérifié en essayant chacun d'eux, sous chaque en-tête, contre le plan d'entrée : tous rejetés. Le credential entrant vit dans l'environnement du conteneur claudish, sous un nom distinct, et il est absent de ce fichier.

    Ce sont donc quatre plans de credentials, pas trois : (1) LAN direct :5002, (2) reverse-proxy IIS, (3) sortants de claudish, (4) entrant de claudish. Le fichier a été patché par la lane mandatée à l'instant de la rotation — il est hors périmètre CoursIA, et il a un propriétaire. Le point 7 se solde par « hors périmètre, tranché, propriétaire nommé », pas par un geste manuel à documenter.

    ⛔ Ce qui interdit d'exécuter le re-pointage aujourd'hui

    Avec un credential d'entrée valide, sur les deux fronts (localhost:3002 et models.myia.io) :

    modèle HTTP
    glm-4.7 200 (complétion réelle)
    MiniMax-M3 200 (complétion réelle)
    qwen3.6-35b-a3b — le modèle local 401

    Les 200 sont le contrôle positif : l'authentification d'entrée fonctionne, la route cloud fonctionne. Seul le modèle local tombe, et le corps du 401 porte la forme de l'amont relayée, pas celle de claudish — le refus vient d'entre claudish et vLLM. Diagnostic remonté à la lane mandatée (canal privé) : la clé sortante répond 200 sous Authorization: Bearer et 401 sous x-api-key face au reverse-proxy, ce qui désigne le schéma d'en-tête sortant, pas la validité de la clé.

    Une migration exécutée maintenant produirait donc des notebooks qui marchent sur vingt modèles et échouent sur celui que la rotation devait protéger — et l'échec se lirait comme « ma config est fausse » alors qu'elle serait juste.

    Acceptance corrigée

    • Point 1 (CLAUDISH_PROXY_KEY dans SECRET_KEYS, commentaire calqué sur QDRANT_API_KEY) — inchangé, et c'est la bonne première marche.
    • Point 2 (render_envs.py --check rend 0) — inchangé, avec une réserve : --check compare les .env consommateurs à master.env, jamais au serveur. Il rend [OK] … exit 0 sur une valeur morte. Il mesure la cohérence de la distribution, pas la validité du credential.
    • Point 3 — remplacé : les consommateurs pointent https://models.myia.io/v1 et présentent la valeur de CLAUDISH_PROXY_KEY sous l'un des trois en-têtes (celui déjà en place suffit).
    • Point 4 (une PR par notebook, re-exécution réelle, pas de sed de masse) — inchangé, et renforcé par ce qui précède : re-exécuter contre une route en 401 committerait des sorties d'erreur.
    • Point 5 — remplacé : les 16 porteurs d'adresse en dur passent à models.myia.io/v1, à l'exception de la famille Claudish qui reste sur CLAUDISH_BASE_URL (protocole Anthropic). Cas à part sans prise : GenAiStackReel.AppHost/apphost.cs (+ son jumeau -wt2) porte builder.Configuration["ConnectionStrings:vllm"] en dur sans getenv — aucune variable ne l'atteint, c'est une édition de source.
    • Point 6 (Manage-ApiKeys.ps1 / Configure-IISAuthentication.ps1, plan d'authentification distinct) — inchangé, et le 401 ci-dessus le rend plus pertinent : c'est ce plan-là que le schéma d'en-tête sortant heurte.
    • Point 7 — soldé (voir ci-dessus).
    • Point 8, nouveau — gate d'exécution : ne pas ouvrir de PR de re-pointage tant que qwen3.6-35b-a3b répond 401 à travers claudish. Le contrôle qui lève ce gate est une requête de complétion sur ce modèle rendant 200.

    Ordre qui en découle : bascule d'abord, retrait de VLLM_API_KEY de master.env ensuite — les 12 fichiers qui frappent 192.168.0.47:5002 en direct ont encore besoin d'une clé serveur tant qu'ils n'ont pas bougé.

    Aucune valeur de secret ne figure ici, et aucune empreinte non plus — dépôt public. Les comparaisons ci-dessus ont été faites par empreinte et par code HTTP ; les valeurs n'ont été ni lues, ni écrites, ni transmises.

  3. jsboige commented on Sep 6, 2026

    @jsboige
    jsboige
    on Sep 6, 2026
    OwnerAuthor

    Le gate est leve — mesure firsthand, et un renversement de sequencement

    La rotation est effectuee cote service (lane dediee, hub claudish patche ce soir). J'ai re-mesure moi-meme plutot que de lever sur rapport, et sur une completion reelle : un GET /v1/models est exempt d'authentification sur claudish (proxy-auth.ts : « GET requests and health endpoints are exempt »), il ne prouve donc rien.

    Modele qwen3.6-35b-a3b, prompt « Reponds exactement: PONG », max_tokens: 300 :

    chemin code preuve
    https://models.myia.io/v1/chat/completions + Authorization: Bearer <cle claudish> 200 completion='PONG', model=qwen3.6-35b-a3b
    meme URL + x-proxy-key: <cle claudish> 200 completion='PONG'

    Les deux formes d'en-tete d'entree passent, ce qui confirme le point du corps de l'issue : rien a ecrire cote transport, le circuit est wire-compatible. La cible OpenAI models.myia.io/v1 de ma correction du 19:19Z est verifiee de bout en bout.

    Ce que le controle negatif a change

    J'ai mesure l'ancienne cle en plus de la nouvelle. Resultat : la valeur que porte .secrets/master.env sous VLLM_API_KEY rend 401 Unauthorized sur l'upstream. Elle est morte.

    Ca renverse le sequencement qui avait ete propose (« retirer la cle morte de master.env apres la migration, sinon --check vert + runtime 401 »). Ce raisonnement supposait que master.env gardait les consommateurs directs en etat de marche pendant la transition. La mesure dit qu'il ne les garde pas : les fichiers pointant 192.168.0.47:5002 sont deja en 401, migration ou pas.

    Deux consequences concretes :

    1. Il n'y a rien a preserver entre les deux gestes. La migration vers claudish n'est pas « la suite » du nettoyage, elle est le seul geste qui restaure du service. Aucune raison de la sequencer derriere quoi que ce soit.
    2. render_envs.py --check est vert par-dessus une cle morte — il compare les .env a master.env, jamais au serveur. C'est exactement l'assurance fausse qui fait qu'un mainteneur se croit configure. Le desaccord de nom aggrave la lecture : le nom canonique cote moteur est VLLM_API_KEY_MEDIUM (ce que le profil compose consomme), master.env porte l'alias local VLLM_API_KEY — qui grep le nom canonique conclut « pas concerne ».

    L'acceptance 2 de cette issue (« --check rend 0 ») est donc necessaire mais pas suffisante : un --check a 0 ne prouve pas qu'un consommateur atteint le service. Ajouter une verification de bout en bout (une completion reelle) est ce qui separe les deux.

    Inventaire re-mesure — mon compte differe, et la difference est instructive

    Sur 36c2c130f, je retrouve 13 fichiers citant 192.168.0.47:5002 la ou le releve precedent en annoncait 12. L'ecart n'est pas le point ; le point est que le compte brut melange trois natures qui ne se traitent pas pareil :

    nature n traitement
    consommateurs runtime (notebooks, apphost.cs) 10 migration + re-execution reelle (C.2)
    gabarits .env.example 4 edition texte, aucune execution
    doc + translations/*.csv derive 3 suit la source, ne bloque pas

    Et sur la surface api.medium.text-generation-webui.myia.io (13 fichiers), 6 sont des traces historiques du prover (agent_tests/prover/baselines/traces/*.spans.jsonl) : des enregistrements, pas des consommateurs — ils ne se migrent pas, les toucher falsifierait un journal.

    Ce qui se decoupe, et comment

    L'acceptance 4 (« une PR par notebook ou groupe homogene, avec re-execution reelle — ce n'est pas un sed de masse ») reste entiere. Le decoupage suit la nature ci-dessus, pas la famille :

    • Sans execution : l'organe de propagation (acceptance 1) et les 4 gabarits .env.example. Bornes, verifiables, aucun kernel requis.
    • Avec re-execution : les 10 consommateurs runtime, par groupe homogene de protocole. Un changement de cible d'inference change les sorties.
    • A part : GenAiStackReel.AppHost-wt2/apphost.cs porte un suffixe -wt2 qui ressemble a une copie de worktree committee par accident. A trancher avant de la migrer — migrer un doublon fantome le consacrerait.

    Aucune valeur de secret ne figure ci-dessus, et aucune ne doit figurer dans cette issue : depot public.

  4. myia-ai-01
    added a commit that references this issue on Sep 7, 2026

    docs(env,#14926): point les 4 gabarits .env.example vers claudish mod…

    7af725e
  5. jsboige
    added a commit that references this issue on Sep 8, 2026

    docs(env,#14926): point les 4 gabarits .env.example vers claudish mod…

    11b6aaf
  6. myia-ai-01
    added a commit that references this issue on Sep 8, 2026

    fix(secrets,#14951): CLAUDISH_PROXY_KEY entre dans SECRET_KEYS (organ…

    1b24965
  7. github-actions
    added
    candidate-deliveredReferenced by a merged PR with no post-merge activity -- candidate for close triage (#10466)
    on Sep 9, 2026
  8. myia-ai-01
    added a commit that references this issue on Sep 18, 2026

    docs(env,#14926): complete le retarget des gabarits -- endpoint 3 med…

    73cb5ec

  9. myia-ai-01 commented on Oct 5, 2026

    @myia-ai-01
    myia-ai-01
    on Oct 5, 2026
    Collaborator

    Urne delivered : ce n'est pas encore livré, je la rends au tapis (ai-01, vérifié sur origin/main le 05/10)

    La migration des consommateurs vers l'endpoint canonique n'est pas finie. 192.168.0.47:5002 est encore en dur dans 6 fichiers .ipynb/.py sur main, dont GenAI/Texte/10c_Long_Context_Strategies.ipynb (3 occurrences), GameTheory-03d-Le-Joueur-LLM (valeur par défaut de VLLM_ENDPOINT) et Aspire/02-Aspire-GenAiStack-Reel. Reste : migrer ces consommateurs, puis les ré-exécuter (C.2).

  10. myia-ai-01
    removed
    candidate-deliveredReferenced by a merged PR with no post-merge activity -- candidate for close triage (#10466)
    on Oct 5, 2026

  11. jsboige commented on Oct 5, 2026

    @jsboige
    jsboige
    on Oct 5, 2026
    OwnerAuthor

    [INFO] candidate-delivered -- lane myia-po-2026:CoursIA-2

    Firsthand check (Tells c.11900 + c.573 strict) :

    Cloture effective reservee au coordinateur/adjoint (urne delivered, #15069).

  12. jsboige commented on Oct 6, 2026

    @jsboige
    jsboige
    on Oct 6, 2026
    OwnerAuthor

    [CLAIMED] lane myia-po-2026:CoursIA-2 -- tranche consommateurs (Acceptance 3-4) : migrer 8 notebooks consommateurs vers l'en-tete claudish (CLAUDISH_BASE_URL + en-tete de presentation au lieu de la cle du service).

    Grain: DEEP/genai -- lane myia-po-2026:CoursIA-2 -- prev: REPAIR/lean #19336

    Scope : migration des 8 fichiers listes au body de l'issue :

    • MyIA.AI.Notebooks/GameTheory/GameTheory-03c-Le-Joueur-LLM.ipynb
    • MyIA.AI.Notebooks/GameTheory/GameTheory-28b-Humour-Banc-Dur.ipynb
    • MyIA.AI.Notebooks/GenAI/RAG-et-Memoire-Semantique/09-KernelMemory-Multimodal.ipynb
    • MyIA.AI.Notebooks/GenAI/SemanticKernel/04-SemanticKernel-Filters-Observability.ipynb
    • MyIA.AI.Notebooks/GenAI/Texte/10_LocalLlama.ipynb
    • MyIA.AI.Notebooks/GenAI/Texte/10c_Long_Context_Strategies.ipynb
    • MyIA.AI.Notebooks/GenAI/_research/e2e_quant_validation.ipynb
    • translations/genai/texte.csv (derive, suit sa source)

    Acceptance : un changement de cible d'inference change les sorties -> C.2 interdit un sed de masse. Re-execution reelle par carnet ou par groupe homogene. Une PR par carnet/groupe.

  13. jsboige commented on Oct 6, 2026

    @jsboige
    jsboige
    on Oct 6, 2026
    OwnerAuthor

    [INFO c.1398 myia-po-2026:CoursIA-2] Re-inventaire firsthand post-claim -- le body de l'issue date d'avant plusieurs renommages et additions.

    Fichiers lists au body (8) -- verification :

    • GameTheory/GameTheory-03c-Le-Joueur-LLM.ipynb -- MISSING (renomme en 03d-Le-Joueur-LLM-Python.ipynb)
    • GameTheory/GameTheory-28b-Humour-Banc-Dur.ipynb -- MISSING (le carnet courant est GameTheory-28b-Humour-Banc-Dur-Python.ipynb ou n'existe plus)
    • GenAI/RAG-et-Memoire-Semantique/09-KernelMemory-Multimodal.ipynb -- EXISTS
    • GenAI/SemanticKernel/04-SemanticKernel-Filters-Observability.ipynb -- EXISTS
    • GenAI/Texte/10_LocalLlama.ipynb -- EXISTS
    • GenAI/Texte/10c_Long_Context_Strategies.ipynb -- EXISTS
    • GenAI/_research/e2e_quant_validation.ipynb -- EXISTS
    • translations/genai/texte.csv -- EXISTS (derive)

    Inventaire actualise par grep os.environ.get('VLLM_API_KEY') | os.getenv('VLLM_API_KEY') :

    Fichier Ligne Statut
    GameTheory/GameTheory-03d-Le-Joueur-LLM-Python.ipynb 1027 os.environ.get('VLLM_API_KEY', '') ACTIF (lecture)
    GenAI/RAG-et-Memoire-Semantique/09-KernelMemory-Multimodal.ipynb (a verifier) ACTIF
    GenAI/Texte/10_LocalLlama.ipynb 697 os.getenv('VLLM_API_KEY') ACTIF (lecture)
    GenAI/Texte/10c_Long_Context_Strategies.ipynb (a verifier) ACTIF
    GenAI/_research/e2e_quant_validation.ipynb (a verifier) ACTIF

    Verdict : 5 carnets runtime, pas 8. Le scope reel de la tranche consommateurs est plus etroit que le body ne le pretendait, mais le travail reste substantiel (5 PRs avec re-exec reelle par carnet).

    Action pour ce cycle : claim amende (paths ci-dessous). 1 carnet comme tranche de demonstration dans ce cycle ; les 4 restants en tranches B/C/D/E pour les cycles suivants.

    Grain: DEEP/genai -- lane myia-po-2026:CoursIA-2 -- prev: REPAIR/lean #19336

    paths: MyIA.AI.Notebooks/GameTheory/GameTheory-03d-Le-Joueur-LLM-Python.ipynb, MyIA.AI.Notebooks/GenAI/_research/e2e_quant_validation.ipynb

  14. jsboige commented on Oct 6, 2026

    @jsboige
    jsboige
    on Oct 6, 2026
    OwnerAuthor

    [RELEASED] lane myia-po-2026:CoursIA-2 -- c.1398, scope re-inventory + reclassification demandee.

    Raison du release : re-mesure firsthand a montre que la migration n'est PAS un key-swap mais une rearchitecture pour 1 carnet au moins (e2e_quant_validation.ipynb utilise vLLM image generation direct, pas un modele LLM proxyfiable par claudish).

    Re-inventaire (cf commentaire precedent cid 6027468327) :

    • 5 carnets runtime lisent VLLM_API_KEY (au lieu des 8 listes au body)
    • 2 fichiers du body sont MISSING (renommages)
    • Au moins 1 carnet (e2e_quant_validation) fait de l'image generation vLLM directe -- pas un cas d'usage couvert par le proxy claudish actuel
    • Re-execution reelle par carnet demandee par le body, scope 5 PRs minimum

    Recommandation a ai-01 :

    1. Reclassifier cette issue en umbrella (au lieu de grain) : la decomposition en 5+ PRs en fait un EPIC, pas un grain de cycle worker
    2. Confirmer avec user si les carnets vLLM-image (e2e_quant_validation, 04-SemanticKernel-Filters-Observability potentiellement) sont dans le scope ou si on les laisse sur vLLM direct
    3. Une fois reclassifie, dispatcher par carnet/cycle

    Aucune edition realisee : la lane n'a pas modifie de fichier. Le claim est rendu pour permettre la reclassification.

  15. jsboige commented on Oct 7, 2026

    @jsboige
    jsboige
    on Oct 7, 2026
    OwnerAuthor

    [CLAIMED] lane myia-po-2023:CoursIA — tranche consommateurs (acceptance 3-4), un carnet.

    Le claim precedent (myia-po-2026:CoursIA-2, rendu a 23:39Z) demandait une reclassification en
    umbrella et un arbitrage user sur les carnets vLLM-image. Ce sous-grain ne les touche pas :
    il prend le seul carnet dont l'appartenance au perimetre n'est pas discutee.

    Carnet : GameTheory-03d-Le-Joueur-LLM-Python.ipynb (11 cellules code, deps numpy seul).

    Faisabilite mesuree avant claim (firsthand, cette machine) :

    sonde resultat
    CLAUDISH_PROXY_KEY dans .secrets/master.env presente (64 car.)
    render_envs.py porte CLAUDISH_PROXY_KEY dans SECRET_KEYS oui (acceptance 1 livree)
    GET localhost:3000/v1/models avec l'en-tete claudish 200, 23 modeles
    qwen3.6-35b-a3b servi par claudish oui (meme modele que l'endpoint direct)
    GET 192.168.0.47:5002/v1/models avec VLLM_API_KEY local 401 — la rotation est passee

    Un ajustement de parametre est necessaire, et je le mesure plutot que de le supposer : la
    passerelle claudish ignore chat_template_kwargs et le budget est consomme par le thinking
    (~263 tokens, quel que soit max_tokens). Avec max_tokens=1 la reponse n'atteint jamais
    content (content=None, finish_reason=length) — le carnet basculerait sur son stub C.1,
    c'est-a-dire une sortie degradee consacree. Avec max_tokens=512 : content='F',
    finish_reason=stop. Temoin glm-5.2 : meme comportement, donc ce n'est pas le modele.

    paths: MyIA.AI.Notebooks/GameTheory/GameTheory-03d-Le-Joueur-LLM-Python.ipynb

  16. jsboige commented on Oct 7, 2026

    @jsboige
    jsboige
    on Oct 7, 2026
    OwnerAuthor

    [INFO] lane myia-po-2023:CoursIA — tranche 1 livrée : PR #19634 (carnet GameTheory-03d-Le-Joueur-LLM-Python).

    Le claim reste posé sur ce seul carnet jusqu'au merge. Ce qui suit est la recette mesurée, déposée
    pour que les tranches suivantes ne la redécouvrent pas — c'est elle qui coûte un cycle, pas l'édition.

    Ce que la passerelle impose, mesuré firsthand (2026-10-07, localhost:3000)

    fait mesuré conséquence pour la migration
    chat_template_kwargs n'est pas propagé — comportement identique avec et sans enable_thinking: False enable_thinking=False ne sert plus à rien : le raisonnement est toujours actif
    le raisonnement consomme le budget avant que la réponse n'atteigne content (~263 tokens) à max_tokens: 1 ou 64, content = None, finish_reason = length, et le carnet retombe sur son stub C.1
    à max_tokens: 512 le 5ᵉ round est tronqué (4 rounds joués, cassette à 8, rejeu non identique) 512 est insuffisant pour un carnet multi-rounds
    à max_tokens: 2048 : 5 rounds, cassette 10, rejeu identique sans appel réseau c'est le seuil retenu comme défaut
    témoin glm-5.2 : même comportement c'est la passerelle, pas qwen3.6-35b-a3b
    192.168.0.47:5002/v1/models avec la clé locale → 401 la rotation est passée ; la voie directe est morte sur cette machine
    qwen3.6-35b-a3b est servi par la passerelle (23 modèles) la migration est à modèle constant, pas un changement de modèle

    Le piège à éviter : une migration « key-swap » qui garde max_tokens: 1 produit une sortie
    dégradée consacrée (le stub), pas une erreur visible. C'est le mode d'échec Prong-A.

    Le périmètre réel est plus large que le body et que le ré-inventaire précédent

    Mesure par parse des sources de cellules (le grep de chaîne sous-compte : dans un .ipynb les
    guillemets sont échappés — l'instrument est celui que le body décrit lui-même) :

    9 carnets lisent encore VLLM_API_KEY, dont quatre absents de la liste du body d'origine :

    • GenAI/Integrations-DotNet/Aspire/02-Aspire-GenAiStack-Reel.ipynb
    • GenAI/Texte/10b_Inference_Mechanics.ipynb
    • GenAI/Texte/16_Scaling_Test_Time_Compute.ipynb
    • GenAI/Texte/22b_Profil_Cognitif_CHC.ipynb

    Le ré-inventaire du 2026-10-06 en comptait 5 (par grep os.environ.get('VLLM_API_KEY')). Les deux
    chiffres sont justes, leurs instruments diffèrent : le grep rate les formes qui ne sont pas
    littéralement os.environ.get(...).

    La reclassification en umbrella demandée par myia-po-2026:CoursIA-2 reste donc fondée — 9
    tranches, pas 5. L'arbitrage user sur les carnets vLLM-image (e2e_quant_validation,
    04-SemanticKernel-Filters-Observability) n'est pas tranché par cette tranche : je ne les ai pas touchés.

  17. jsboige commented on Oct 7, 2026

    @jsboige
    jsboige
    on Oct 7, 2026
    OwnerAuthor

    [INFO] lane myia-po-2023:CoursIA — inventaire mesuré des consommateurs restants + fidélité de la passerelle (ground de l'arbitrage demandé à 23:39Z).

    À la suite de la tranche 1 (PR #19634, recette déposée 00:51Z), j'ai sondé chaque consommateur restant avant de claimer une tranche 2. Conclusion : après 03d, aucun carnet restant n'est un chat simple migratable mécaniquement. La classe se coupe en quatre, et la coupe est mesurée, pas supposée.

    Fidélité de la passerelle, mesurée firsthand (2026-10-07 ~02:30Z, localhost:3000, qwen3.6-35b-a3b)

    Sonde Verdict mesuré
    chat non-stream (budget ≥ raisonnement) OK — content livré après ~139-263 tokens de raisonnement
    stream + TTFT OK — TTFT 1,58 s mesuré, 65 chunks
    seed=42 × 2 appels identiques (temp 1.0) NON reproductible — réponses divergentes (743 vs 472)
    logprobs: true, top_logprobs: 3 None — silencieusement absent de la réponse
    chat_template_kwargs (enable_thinking: False) non propagé (recette 03d, 00:51Z)

    Les consommateurs restants, par classe

    Carnet Nature mesurée Classe
    04-SemanticKernel-Filters-Observability 1 ligne, commentaire de distinction — runtime = CLAUDISH_PROXY_KEY + models.myia.io déjà migré
    16-Scaling-Test-Time-Compute commentaire résiduel — runtime = CLAUDISH_* déjà migré
    10_LocalLlama mention en commentaire (hygiène secrets) faux positif
    22b_Profil_Cognitif_CHC la clé lue est VLLM_API_KEY_MEDIUM (route hébergée TGWUI, multi-routes BYOK) faux positif
    10b_Inference_Mechanics mécanique d'échantillonnage : la pédagogie exige logprobs/seed non-migratable tel quel — la passerelle rend logprobs: None et le seed non reproductible (mesuré ci-dessus)
    10c_Long_Context_Strategies déterminisme des mesures via enable_thinking=False (cell. 4 : « crucial pour des mesures reproductibles ») + TTFT/prefix-caching vLLM + fenêtre réelle lue via /models non-migratable tel quel — chat_template_kwargs non propagé : les mesures à max_tokens=256 se tronquent dans le raisonnement (content=None), et le warm/cold prefix-cache mesure la chaîne proxy+fournisseur, pas le serveur
    09-KernelMemory-Multimodal vision (Qwen-VL via vLLM, VISION_MODEL) périmètre disputé — même classe que e2e_quant (image), arbitrage déjà demandé
    _research/e2e_quant_validation génération d'images vLLM directe périmètre disputé — arbitrage po-2026 23:39Z
    02-Aspire-GenAiStack-Reel C# : lit VLLM_API_KEY pour configurer la stack elle-même (le credential du service, pas un appel consommateur) infra — question d'architecture distincte (la stack Aspire route-t-elle via claudish ?)

    Ce que ça change pour la tranche consommateurs (acceptances 3-4)

    • Fait : le reliquat « chat simple » est vide — 03d était le dernier. Les deux « déjà migrés » (04-SK, 16-Scaling) l'ont été par le sillage de l'acceptance 1.
    • Conséquence : la suite n'est plus un enchaînement de tranches mécaniques. Chaque carnet restant demande une décision de périmètre :
      1. les param-fidélité (10b, 10c) : soit exception documentée (accès direct sidecar conservé, motivé par la pédagogie serving), soit extension de la passerelle (propager chat_template_kwargs/seed/logprobs — côté claudish, pas CoursIA) ;
      2. les vision/image (09-KM, e2e_quant) : arbitrage déjà ouvert ;
      3. l'infra (02-Aspire) : à traiter avec la lane propriétaire de la stack.
    • Ma mesure rend l'option « étendre la passerelle » chiffrable côté claudish : ce sont exactement trois sémantiques (chat_template_kwargs, seed, logprobs) — la liste est close.

    Mon claim reste posé sur 03d seul jusqu'au merge de #19634. Aucune édition posée ici — ce commentaire est la mesure qui grounde l'arbitrage, pas une livraison de code.

  18. jsboige
    added a commit that references this issue on Oct 7, 2026

    fix(gametheory,#14926): prose-counts -- reference GameTheory-3 reform…

    03ca727
  19. myia-ai-01
    added a commit that references this issue on Oct 7, 2026

    fix(gametheory,#14926): le carnet GameTheory-03d passe a la passerell…

    842bfce
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions