Journal

Progression

• Programme du cours : .NET 10, qui référence GA.Business.ML, FretboardVoicingsCLI et GaChatbot.Api à un commit épinglé
• CI : la sortie de chaque leçon comparée à son fichier attendu sur trois systèmes, sans modèle, sans clé d’API et sans GPU
• Leçon 1 : la carte
• Leçon 2 : les embeddings OPTIC-K
• Leçon 3 : l’index et la recherche
• Leçon 4 : le chatbot et ses agents
• Leçon 5 : le skill d’improvisation et la théorie accord–gamme
• Leçon 6 : la réponse du chatbot sur le fil
• Leçon 7 : les noms d’accords que le chatbot ne sait pas lire
• Leçon 8 : l’examen maison du chatbot
• Leçon 9 : tous les intervalles, toutes les tonalités
• Leçon 10 : ce à quoi le modèle doit se fier
• Leçon 11 : les accords que lit le skill des tonalités
• Leçon 12 : ce que répondent les skills de progression
• Leçon 13 : ce que répond l’analyse de progression
• Leçon 14 : ce que répond le skill de substitution
• Leçon 15 : les notes d’un accord
• Leçon 16 : les voicings d’un accord
• Leçon 17 : le capodastre et les accordages
• Leçon 18 : la conduite des voix
• Leçon 19 : les paires de voicings
• Leçon 20 : les progressions générées
• Leçon 21 : la recherche de voicings
• Leçon 22 : les accords semblables
• Leçon 23 : la distance et le chemin harmoniques
• Leçon 24 : les classes d’ensembles et l’analyseur Grothendieck
• Leçon 25 : ce qui atteint le skill de transposition
• Leçon 26 : le catalogue des modes
• Leçon 27 : les notes qui sonnent en dehors
• Exécuter le chatbot avec Ollama et capturer ce que répondent les agents (daté, hors CI)

QA

Les constats 1 à 22, des leçons 1 à 4, sont numérotés dans l’entrée du 2026-09-14, et leur état en amont dans celle du 2026-09-24. Ce tableau commence à la leçon 5. ImprovisationSkill.cs est identique à a826864 et sur le main de GA à 8cd5042 (2026-09-28) : les lignes 23 à 28 décrivent donc aussi le skill déployé. Les lignes 29 à 32, issues de la leçon 6, donnent leur état sur main dans la dernière colonne. Les lignes 33 à 38, issues de la leçon 7, valent aussi sur main à f4f4d30 : les fichiers qu’elles citent n’y ont pas changé depuis #749. Les lignes 39 à 45, issues de la leçon 8, citent des fichiers inchangés sur main à fc76ad6 (2026-09-29), sauf le corpus, passé de 68 prompts à 75 sans que changent les entrées qu’elles citent. Les lignes 46 à 53, issues de la leçon 9, citent des fichiers inchangés sur main à 53b7253, sauf ScaleInfoSkill.cs et RelativeKeySkill.cs, qui n’y ont changé que dans CanHandle et par un indicateur Declined posé sur un refus par lequel ne passe aucune des lignes. Les lignes 54 à 57, issues de la leçon 10, valent sur main à 53b7253 : les fichiers SKILL.md qu’elles citent y sont inchangés, tout comme les fonctions de DomainClosures.fs qu’elles citent. Les lignes 58 à 64, issues de la leçon 11, donnent le comportement de main avec le service à 6baf32e, inchangé sur main à 5c3a52a, où le SKILL.md est inchangé, et où l’outil et le skill ne diffèrent du commit épinglé que par une ligne using et un indicateur Declined. Les lignes 65 à 72, issues de la leçon 12, valent sur main à 5c3a52a, où ProgressionMoodSkill.cs, les deux fichiers SKILL.md et le brouillon sont inchangés, et où ProgressionCompletionSkill.cs ne diffère du commit épinglé que par une ligne using et un indicateur Declined ; les lignes 67 et 68 donnent le comportement de main avec le service à 6baf32e. Les lignes 73 à 78, issues de la leçon 13, donnent le comportement de main avec DomainClosures.fs et le service à 6baf32e, tous deux inchangés sur main à 5c3a52a ; les lignes 73 et 74 décrivent le commit épinglé, corrigé depuis. Les lignes 79 à 86, issues de la leçon 14, valent sur main à 5c3a52a, où le skill, ses outils MCP, son SKILL.md, GrothendieckDelta.cs, DslEvalMcpTools.cs et GaDslTool.cs sont inchangés et où FindNearby ne diffère que par le test qui écarte la source de sa liste ; la closure de la ligne 85 a tourné au commit épinglé et à 6baf32e, identique à main. Les lignes 87 à 95, issues de la leçon 15, valent sur main à 5c3a52a, où ChordInfoSkill.cs, ChordVocabulary.cs, ChordSpelling.cs, ChordMcpTools.cs et le SKILL.md sont inchangés. Les lignes 96 à 100, issues de la leçon 16, valent sur main à f4f5b4a : les lignes 96 à 98 viennent de TypedMusicalQueryExtractor.cs, de ChordPitchClasses et du CanHandle du skill, identiques au commit épinglé, et les lignes 99 et 100 ont été exécutées avec le pipeline de voicings de main, dans GaMain. Les lignes 101 à 107, issues de la leçon 17, valent sur main à f4f5b4a : sur main, CapoSkill ne fait que poser l’indicateur Declined sur son refus, et les lignes 106 et 107 ont aussi été exécutées sur main, dans GaMain. Les lignes 108 à 113, issues de la leçon 18, valent sur main à f4f5b4a, où VoiceLeadingSkill.cs est inchangé. Les lignes 114 à 117, issues de la leçon 19, valent sur main à f4f5b4a, où CompositionTools.cs et les brouillons de skills en attente sont inchangés ; les lignes 114 à 116 ont aussi été exécutées sur main, dans GaMain. Les lignes 118 à 122, issues de la leçon 20, valent sur main à f4f5b4a, où CompositionTools.cs, ChordPitchClasses, ChordProgressions.yaml et les brouillons de skills en attente sont inchangés ; la ligne 121 a aussi été exécutée sur main, dans GaMain. Les lignes 123 à 127, issues de la leçon 21, valent sur main à f4f5b4a, où VoicingSearchTool.cs et VoicingVocabularyTool.cs ne diffèrent que par un commentaire et une description, le skill de recherche de voicings que par une ligne sur un autre outil, et où le lecteur, le registre des tags et le brouillon en attente sont inchangés ; les lignes 123, 124 et 126 ont aussi été exécutées sur main, dans GaMain. Les lignes 128 à 131, issues de la leçon 22, valent sur main à f4f5b4a, où IcvNeighborsSkill et IntervalClassVectorSkill ne font que marquer leur refus Declined, où FindNearby compare l’ensemble de départ par valeur, et où DefaultRoutingHintProvider et le brouillon en attente sont inchangés ; les lignes 128 à 130 ont aussi été exécutées sur main, dans GaMain. Les lignes 132 à 135, issues de la leçon 23, valent sur main à f4f5b4a, où GrothendieckDeltaSkill et IcvShortestPathSkill ne font que marquer leur refus Declined, où FindNearby compare l’ensemble de départ par valeur, et où GrothendieckDelta et DefaultRoutingHintProvider sont inchangés ; les quatre lignes ont aussi été exécutées sur main, dans GaMain. Les lignes 136 à 140, issues de la leçon 24, valent sur main à f4f5b4a, où SetTheoryEquivalenceSkill et GrothendieckParseSkill ne font que marquer leur refus Declined et où l’analyseur Grothendieck est inchangé ; les cinq lignes ont aussi été exécutées sur main, dans GaMain. Les lignes 141 à 144, issues de la leçon 25, ont été exécutées au commit épinglé et sur main à f4f5b4a, dans GaMain, qui démarre désormais l’hôte du chatbot de main ; TransposeSkill, son SKILL.md, les règles d’indice et SkillMdPlugin y sont inchangés : les lignes 141 à 143 valent donc sur main telles qu’écrites, et la ligne 144 donne les réponses des deux commits. Les lignes 145 à 149, issues de la leçon 26, valent sur main à f4f5b4a, où ModesSkill.cs, Modes.yaml et ModesConfig.fs sont les mêmes fichiers ; elles n’ont été exécutées qu’au commit épinglé. Les lignes 150 à 154, issues de la leçon 27, valent sur main à f4f5b4a, où OutsideNotesSkill.cs ne fait que marquer son refus Declined et où ChordVocabulary.cs est le même fichier ; elles n’ont été exécutées qu’au commit épinglé.

Attendu	Ce qui se passe	Où	Mesure	État
23. Une suite de symboles d’accords est lue telle qu’elle est écrite	Cmaj7#5 est lu Cmaj7 ; C7sus4 et CmMaj7 disparaissent sans un mot, alors que mMaj7 est l’étiquette d’arpège du skill lui-même	ImprovisationSkill.cs lignes 453-462	l5 : 15 accords lus sur 17, dont 1 tronqué	Reproduit ; signalé dans #757
24. Cm7#5 est un accord mineur	Classé augmenté : arpège Caug, un E contre le E♭ de l’accord ; aucune des deux gammes proposées ne contient le E♭	ligne 343	l5, tableau accord par accord	Reproduit ; signalé dans #758
25. L’arpège de Cm6 épelle C E♭ G A	CmMaj7, qui joue B au lieu de A ; la gamme, le mineur mélodique, convient	ligne 346	l5, tableau accord par accord	Reproduit ; signalé dans #758
26. C7#11 commence par une gamme qui contient F♯	Le mixolydien, avec F bécarre ; le lydien dominant est le deuxième choix	lignes 360-436	l5, tableau accord par accord	Reproduit ; signalé dans #758
27. Les accords suspendus et les power chords gardent leurs propres notes	« unknown » : l’étiquette d’arpège est la fondamentale seule, une triade majeure, E contre le F du sus4 et le D du sus2	ligne 283	l5, tableau accord par accord	Reproduit ; signalé dans #758
28. Les gammes principales d’une progression restent dans sa tonalité, ou la réponse dit que la tonalité est ambiguë	L’ionien sur les triades majeures, l’éolien sur les triades mineures, quel que soit leur degré : B♭ sur F et F♯ sur G dans Am F C G, F♯ G♯ sur A dans C A Dm G, F♯ C♯ D♯ sur E dans Am Dm E ; C G n’est pas signalée comme ambiguë	lignes 212-261	l5 : sur 23 accords dans 7 progressions (l’accord d’emprunt mis à part), 11 identiques, 10 DIFF, 2 justes dans une seule des deux tonalités	Signalé dans #744
29. Un client distingue une requête qui échoue d’une réponse	Le flux répond HTTP 200 et envoie {"error": …} comme un événement ordinaire, sans [DONE]. La page de GaChatbot.Api affiche ce JSON comme la réponse de l’assistant et le range dans l’historique de la conversation, que la requête suivante renvoie	index.html lignes 740-809, ligne 984	l6, tableau des échecs, à travers le portage de la page que contient le cours	Reproduit dans le portage, pas dans un navigateur ; signalé dans #760
30. Les fragments diffusés se recollent en la réponse	SseChunker découpe sur (?<=[.!?])\s+, qui retire les blancs entre les phrases : la réponse d’improvisation perd 6 de ses 8 sauts de ligne, et sa liste s’affiche comme une seule puce	SseChunker.cs lignes 19-29	l6, phrases : 552 caractères sur 558	Corrigé en amont par #743, fusionnée le 2026-09-28 ; le cours exécute la version épinglée et une copie du correctif
31. Chaque ligne de texte survit au flux de GaApi	data: {chunk} sans préfixe sur les autres lignes du fragment : une ligne vide dans un fragment termine l’événement, et la ligne suivante est perdue pour tous les lecteurs	ChatbotController.cs de GaApi, lignes 318-322	l6, tableau des paires : 1 ligne sur 6 et 8 sauts de ligne manquants, avec les deux découpages	Signalé en amont : #746, ouvert ; inchangé sur main à 8621c3e. Latent : aucun composant de ga-client ne lit ce flux
32. Le client SSE de ga-client garde chaque ligne d’un événement	parseSseBuffer garde la première ligne data: de chaque événement et en retire les blancs aux deux bouts : il perd donc une ligne et tous les sauts de ligne, même avec l’émetteur de GaChatbot.Api	chatService.ts lignes 41-48	l6, tableau des paires	La moitié client des critères d’acceptation de #746 ; aucun appelant à a826864
L’oracle donne une gamme enseignée pour chaque accord	Pour un accord d’emprunt, F mineur en C, sa règle donne F G A♭ B C D E, qui n’est pas une gamme enseignée ; la réponse habituelle est F dorien	code/ga-ai/GaAi/Lesson5.cs, Textbook	l5, C Fm G C	Une limite de l’oracle du cours, pas de GA ; documentée dans la leçon 5
33. Une demande avec des noms d’accords en minuscules est refusée, ou la réponse dit qu’elle ne sait pas les lire	which arpeggio fits hm q7 passe la garde de #749, dont les fondamentales sont les majuscules de H à Z, et continue vers le modèle	InvalidChordNames.cs ligne 97	l7, ligne 5	Signalé dans #759
34. Une qualité inconnue sur une fondamentale valide est signalée	Cq7 passe la garde et continue vers le modèle	InvalidChordNames.cs lignes 41-59	l7, ligne 6	Hors périmètre selon la description de #749 ; signalé dans #759
35. Un accord invalide à côté d’accords valides est nommé dans la réponse	Am F Q7 G reçoit une réponse pour Am, F et G, et Q7 disparaît sans un mot ; C and Q7 continue vers le modèle	InvalidChordNames.cs lignes 41-59, ExtractChordRun	l7, lignes 13 et 14	Voulu par #749 (« keeps its route ») ; signalé dans #759, et l’abandon silencieux dans #757
36. Les signes bémol et dièse sont lus	B♭ E♭ F reçoit une réponse pour B, E et F : B ionien pour B♭. Les expressions du skill n’admettent que [#b] ; les skills de GA pour le capodastre et les accordages alternatifs prévoient ♭ et ♯, mais les laissent souvent tomber (lignes 103 et 106)	ImprovisationSkill.cs lignes 447-462	l7, ligne 9	Signalé dans #757
37. Un chiffrage qui se termine par #, + ou ° est lu en entier	F# est lu F et C+ est lu C. ChordTokenRegex se termine par \b, et aucune limite de mot ne suit ces caractères : la correspondance revient donc en arrière jusqu’à la fondamentale seule	ligne 461	l7, lignes 10 et 11	Signalé dans #757
38. Bø7 est lu	Laissé hors de la suite d’accords sans un mot : la liste a °7 mais pas ø7, et ø est une lettre, donc aucune limite ne le sépare du 7	ligne 461	l7, ligne 12	Signalé dans #757
Le reconnaisseur du cours lit correctement chaque mot d’un message	Il lit l’interjection qui ouvre « Hm, which mode is brightest? » comme un chiffrage mal formé ; la garde de GA l’ignore, ce qui est juste	code/ga-ai/GaAi/Lesson7.cs, Read	l7, ligne 15	Une limite du reconnaisseur du cours, pas de GA ; documentée dans la leçon 7
39. Une réponse fausse échoue à la vérification du corpus	#26, « modes of melodi minor », reçoit les modes de la gamme majeure et passe : son contains_any est satisfait par la ligne de suggestion qui termine chaque réponse sur une famille	prompts.yaml lignes 270-276, ModesSkill.cs ligne 449	l8, #26	Signalé dans #763
40. Une famille mal orthographiée reçoit sa réponse, ou la réponse dit qu’elle n’a pas été reconnue	« melodi minor » tombe dans la branche par défaut, qui liste les modes de la gamme majeure sans un mot	ModesSkill.cs lignes 202-207	l8, #26	Signalé dans #765
41. Un message d’erreur échoue à la vérification du corpus	#31 passe avec « I encountered an error processing your request. Please try again. » : son contains_any contient G, qui est dans « processing »	prompts.yaml lignes 316-322, PromptCorpusTests.cs lignes 367-379	l8, #31	Signalé dans #763
42. Un skill qui ne peut pas joindre son modèle est signalé comme backend dégradé	Sans modèle, un skill Path B répond avec le texte d’erreur de SkillMdDrivenSkill, qui ne fait pas partie de BackendDegradedMarkers : six échecs et une réussite au lieu de sept « no signal »	SkillMdDrivenSkill.cs lignes 204-226, PromptCorpusTests.cs lignes 54-75	l8, #10 et le premier tableau	Signalé dans #764 ; les exécutions quotidiennes de GA sont à vérifier
43. Le journal d’un skill dit ce qui s’est passé	DiatonicChordsSkill journalise que le modèle « produced an answer without invoking ga_dsl_eval », alors qu’aucun modèle n’a été atteint	SkillMdDrivenWrapperBase.cs lignes 107-136	l8, #10	Signalé dans #764
44. Les vérifications du corpus distinguent une réponse de la réponse à une autre question	Des sous-chaînes insensibles à la casse, dont 84 sur 224 ne font qu’un caractère : les prompts qui passent acceptent 169 des autres réponses, et 6 réponses sur 15 transposées d’un demi-ton, dont Drop C# pour drop C	PromptCorpusTests.cs lignes 367-379	l8, premier tableau du demi-ton	Signalé dans #763 ; la lecture plus stricte du cours en accepte 69 et 4
45. La formule d’une gamme correspond à l’orthographe de ses notes	Les formules sont calculées par position par rapport à C majeur : #6 pour le B♭ de la gamme par tons, et 1 b2 b3 b4 b5 bb6 bb7 bb8 pour C D♭ E♭ E F♯ G A B♭	ModesSkill.cs lignes 779-811	l8, #38 et #39	Signalé dans #765
Le test du demi-ton du cours rend chaque réponse fausse	Seulement pour un prompt qui nomme une hauteur ; pour les autres, la réponse transposée reste juste, et le tableau affiche n/a. Le cours ne reconnaît un nom de note dans la question que s’il porte une majuscule : #30, « notes in c major », affiche donc lui aussi n/a	code/ga-ai/GaAi/Lesson8.cs, Transpose	l8	Une limite du test du cours, pas de GA ; documentée dans la leçon 8
46. Le skill des intervalles lit un dièse sur la deuxième note	Le \b final de son expression fait abandonner le # : de E à G#, une tierce mineure, de C à F#, une quarte juste ; 147 questions sur 441	IntervalSkill.cs lignes 62-64	l9, les colonnes # de la grille	Signalé dans #767 ; la même cause que #757, dans une autre expression
47. Le skill des intervalles lit ♯ et ♭	De C à F♯, une quarte juste ; la question de B♭ à D n’est pas analysée	IntervalSkill.cs lignes 62-64	l9, « written another way »	Signalé dans #767
48. Un unisson abaissé est un unisson diminué	De C# à C, un unisson juste de 0 demi-ton : les demi-tons sont pris modulo 12, et une différence que le switch ne couvre pas tombe dans sa branche par défaut ; 21 unissons sur 441, et 5 autres intervalles avec Cb, Fb, E# ou B#. De même avec le domaine de main	NoteExtensions.cs ligne 110, lignes 13-56	l9, « the note names read right »	Signalé dans #768
49. Chaque qualité d’intervalle est écrite en toutes lettres	Doublement augmenté et doublement diminué s’affichent AA et dd : 27 réponses sur 441	IntervalNaming.cs lignes 56-64	l9, les cases a de la grille	Signalé dans #767
50. Deux skills donnent la même tonalité relative	ScaleInfoSkill prend la première tonalité qui a les mêmes classes de hauteurs : B majeur → A♭ mineur, G♯ mineur → C♭ majeur, 6 tonalités sur 30 ; RelativeKeySkill, corrigé sur ce point en mai, donne G♯ mineur et B majeur	KeyNaming.cs lignes 55-65, RelativeKeySkill.cs lignes 119-125	l9, le tableau des tonalités	Signalé dans #769
51. L’armure d’une tonalité est juste, ou la tonalité est refusée	D♯, G♯ et A♯ majeur, D♭ et G♭ mineur reçoivent « no sharps or flats » ; l’homonyme mineure de G♯ majeur reçoit « 3 flats »	RelativeKeySkill.cs lignes 208-212	l9, « keys past seven »	Signalé dans #769
52. Une tonalité lue dans une question l’est aussi dans les autres	C♭ majeur est lu pour sa relative mineure et refusé pour son armure, avec un message qui demande une lettre suivie de # ou de b	RelativeKeySkill.cs lignes 72-81, lignes 245-251	l9, après le tableau des tonalités	Signalé dans #769
53. Un skill répond à ses propres prompts d’exemple	IntervalSkill ne sait pas lire 8 de ses 13 exemples, cinq définitions et trois questions comme « Minor third up from D » ; ScaleInfoSkill, 3 de ses 24	IntervalSkill.cs lignes 27-52, ScaleInfoSkill.cs lignes 23-91	l9, dernière section	Ceux de IntervalSkill signalés dans #767, ceux de ScaleInfoSkill non signalés ; ce que le chatbot sert pour eux est à vérifier
54. Les accords diatoniques d’une tonalité s’écrivent avec une lettre par degré	domain.diatonicChords nomme chaque accord d’après un tableau de douze noms en dièses ou en bémols, choisi selon la tonique : D, G et C mineur reçoivent A♯, D♯ et G♯, et C♭, F♭, E♯ et B♯ deviennent B, E, F et C ; 11 tonalités sur 30	DomainClosures.fs lignes 22-36, ligne 187	l10, le tableau des tonalités	Signalé dans #770
55. Le SKILL.md de diatonic-chords décrit ce que renvoie la closure	Il promet une orthographe juste dans « Gb major, F# minor » et dit que G♭ majeur « returns Cm » ; la closure renvoie B pour le C♭ de G♭ majeur, et Bdim là où le SKILL.md montre B°	skills/diatonic-chords/SKILL.md ligne 26, DiatonicChordsSkill.cs lignes 27-32	l10, « Les exemples du SKILL.md »	Signalé dans #770
56. Un accord transposé s’écrit d’après l’intervalle	domain.transposeChord prend des demi-tons et nomme le résultat d’après le tableau de la fondamentale de départ : C une tierce mineure plus haut donne D♯, « Transpose G7 to Eb » donne D♯7, B♭ monté d’un ton puis redescendu donne A♯ ; 70 sur 252 sur une autre lettre, même C♭ déplacé de 0 demi-ton, et 30 d’entre elles où le manuel demande une double altération	DomainClosures.fs lignes 159-162, skills/transpose/SKILL.md ligne 42	l10, la grille des transpositions	Signalé dans #770
57. Les notes communes s’écrivent comme les accords les écrivent	domain.commonTones nomme chaque note commune d’après sa seule classe de hauteurs : A et C♯m partagent “Db” ; 144 des 630 paires de triades des 30 tonalités	DomainClosures.fs lignes 263-266, ligne 523	l10, le tableau des notes communes	Signalé dans #770
58. Le skill des tonalités lit chaque accord de la question	Au commit épinglé, ExtractChords ignore tout chiffrage où un chiffre suit directement une lettre, parce que son \b final échoue entre deux caractères de mot : les 30 questions de la leçon 11 qui ont des accords de septième les perdent tous. Sur main, CM7, CΔ7 et Cø7 sont toujours ignorés	KeyIdentificationService.cs ligne 211	l11, le tableau de lecture et la grille	Corrigé sur main par #625 pour les chiffrages qui comportent un chiffre ; CM7, CΔ7 et Cø7 signalés dans #771
59. Un dièse à la fin d’un chiffrage d’accord est conservé	Le \b final échoue entre # et une espace : F# et C# sont lus F et C dans les deux versions. Par ailleurs, B♭ et F♯ sont lus B et F, C° comme une triade de C majeur, et C/E comme deux accords	KeyIdentificationService.cs ligne 211, ligne 325 sur main	l11 : 16 questions sur 90 lisent d’autres accords sur main	Signalé dans #771 ; la même cause que #757 et #767, dans une autre expression
60. Des tonalités qui ont les mêmes classes de hauteurs se distinguent par l’orthographe de la question	Ces tonalités sont à égalité et le nom tranche : pour D♭ G♭ A♭ D♭, A♯ mineur vient en premier au commit épinglé et C♯ majeur sur main, où 13 questions sur 90 reçoivent d’abord la jumelle enharmonique de la tonalité	KeyIdentificationService.cs ligne 178, lignes 224-227 sur main	l11, les ~ de la grille de main	Signalé dans #772
61. Un accord répété garde sa place dans la progression	ExtractChords supprime les accords répétés, si bien que le poids de cadence de main ne voit jamais le retour sur I et entend D G comme le V–I de G majeur : C D G C est lu C D G et reçoit la réponse G majeur ; dans les 11 tonalités de I II V I dont les accords sont lus, la tonalité de la dominante, ou sa jumelle enharmonique, vient en premier	ligne 299 sur main, lignes 231-246	l11, les x de la grille	Signalé dans #771
62. Les tonalités de tête sont celles que le classement place en premier	L’outil et le skill gardent les tonalités dont le décompte égale celui de la première, alors que main classe par décompte plus cadence : C♯m7b5 F♯7 Bm reçoit un groupe de tête de six tonalités à 1/3, avec G♯ mineur à 2/3 parmi les correspondances partielles ; pour C D G C donné en liste, le groupe de tête laisse de côté G majeur (3/3), et les correspondances partielles répètent deux tonalités du groupe de tête	KeyIdentificationMcpTools.cs lignes 66-75, KeyIdentificationSkill.cs lignes 62-63	l11 : 2 questions sur 90 sur main, et C D G C en liste	Signalé dans #772
63. La tonalité relative d’une tonalité s’écrit à partir de cette tonalité	Le service prend la première tonalité de l’autre mode qui a les mêmes classes de hauteurs : B majeur → A♭ mineur, G♯ mineur → C♭ majeur ; 6 tonalités sur 30, dans les deux versions	KeyIdentificationService.cs lignes 93-101	l11, les tonalités relatives	Signalé dans #772 ; la même recherche que celle de ScaleInfoSkill dans #769
64. Les exemples du SKILL.md de key-identification décrivent ce que renvoie l’outil	Son exemple d’un seul candidat en tête est « The progression Dm G C is in C major (3/3 chords diatonic) » ; l’outil renvoie C majeur et A mineur, à égalité, dans les deux versions. Sa ligne 81 dit que l’outil « doesn’t distinguish a Cmaj7 from a C » ; au commit épinglé, il ne lit pas Cmaj7 du tout	skills/key-identification/SKILL.md ligne 60	l11, les prompts d’exemple	Signalé dans #772
65. Le skill d’ambiance répond à l’ambiance que demande le prompt	6 de ses 8 prompts d’exemple qui demandent d’éclaircir reçoivent les cinq façons d’assombrir : le test cherche « brighter », « uplift » et « happier », et manque « Brighten », « brightness » et « lift the mood ». Ce sont les six prompts d’éclaircissement ajoutés le 2026-05-12 pour corriger des erreurs de routage	ProgressionMoodSkill.cs ligne 61	l12, le tableau des ambiances	Signalé dans #773
66. Le texte du skill d’ambiance écrit des chiffrages d’accords, comme son SKILL.md	C bA G et C bB F : bA et bB ne sont ni des chiffrages d’accords ni des chiffres romains. Le SKILL.md écrit Ab et Bb, demande que sa liste de techniques soit reproduite mot pour mot, et diffère du texte C# par la deuxième technique de chaque branche	lignes 74 et 77, SKILL.md ligne 38	l12, les progressions des deux textes	Signalé dans #773
67. Les accords que propose le skill de complétion appartiennent à la tonalité de la question	La liste vient de la première tonalité, et au commit épinglé, les égalités sont tranchées par le nom : G Em C reçoit les accords de C majeur, sans D ; 6 des 15 tonalités majeures pour I vi IV	ProgressionCompletionSkill.cs lignes 93-107, KeyIdentificationService.cs ligne 178	l12, la grille : x 6 au commit épinglé, 0 sur main	Corrigé sur main par #729
68. La liste est écrite comme la question	D♭ B♭m G♭ reçoit A#m, B#dim, C#, D#m, E#m, F#, G# au commit épinglé et les accords de C♯ majeur sur main	ProgressionCompletionSkill.cs ligne 107	l12, la grille : e 4 au commit épinglé, 5 sur main	Signalé dans #774 ; la même cause que #772
69. La liste d’une tonalité mineure permet au modèle de construire une cadence parfaite	La liste est celle du mineur naturel : le V majeur ne figure dans aucune des listes des 15 tonalités mineures. Le prompt autorise V7 « even if only V appears », ce qui n’arrive jamais en mineur ; le SKILL.md autorise V7 et interdit tout accord hors de la liste	lignes 117-119, SKILL.md lignes 71 et 96	l12, le tableau des dominantes	Signalé dans #774
70. L’exemple du prompt suit les règles du prompt	Il propose E7 comme V7–i de A mineur, hors de la liste de A mineur, et G comme demi-cadence, « bVII-i », alors qu’une demi-cadence se termine sur V et que G est le septième degré	lignes 130-131	l12, le prompt et le tableau des dominantes	Signalé dans #774
71. L’exemple du SKILL.md de progression-completion décrit ce que renvoie l’outil	Il annonce C majeur en premier, « also tied with A minor », avec B° ; au commit épinglé, l’outil place A mineur en premier, met aussi G majeur et E mineur à égalité, et écrit Bdim. Sa réponse propose Dm → G7, contre sa propre contrainte stricte. Il dit rare une égalité avec une autre gamme : 13 des 25 questions lues telles qu’elles sont écrites en ont une	SKILL.md lignes 56, 86, 92 et 96	l12, les exemples et la grille	Signalé dans #774
72. Le test par mots-clés d’un skill accepte ses propres prompts d’exemple	ProgressionCompletionSkill.CanHandle rejette « What chord comes next after C G Am? » et « Help me end Am F G » ; ProgressionMoodSkill.CanHandle renvoie false. Sur main, le routeur se replie sur ces tests quand il ne peut pas calculer l’embedding d’une question ; au commit épinglé, rien ne les appelle	ProgressionCompletionSkill.cs lignes 35-45, SemanticIntentRouter.cs ligne 321 sur main	l12, le tableau des mots-clés	Signalé dans #773 et #774
73. La tonalité d’une progression dépend de la qualité de ses accords	Au commit épinglé, seules les fondamentales comptent : Am Dm E Am est en A majeur, Dm7 G7 Cmaj7 en D mineur, F G C en F majeur ; 90 des 120 questions de manuel reçoivent une autre tonalité, dont les 60 en tonalité mineure	DomainClosures.fs lignes 268-270, lignes 308-316	l13, la grille : x 90 au commit épinglé, 0 sur main	Corrigé sur main par #625
74. Un chiffre romain suit la qualité de l’accord	Au commit épinglé, le chiffre est celui du degré dans le tableau de la tonalité, quel que soit l’accord : D et Dm sont tous deux ii en C majeur, et Fm Bbm C7 Fm est I IV V I en F majeur	lignes 257-260, lignes 272-276	l13, les quatre exemples du brouillon : 2 justes au commit épinglé, 4 sur main	Corrigé sur main par 6baf32e
75. La tonalité est nommée comme l’écrit la question	Au commit épinglé, le nom vient de la classe de hauteurs : C♯, G♭ et C♭ majeur reviennent en D♭, F♯ et B majeur. Sur main, c’est le nom que Identify place en premier, les tonalités qui ont les mêmes classes de hauteurs étant rangées par nom : C♭, G♭ et D♭ majeur reviennent en B, F♯ et C♯ majeur, E♭, B♭ et G♯ mineur en D♯, A♯ et A♭ mineur	lignes 262-266, KeyIdentificationService.cs lignes 224-227 à 6baf32e	l13, la grille : e 6 au commit épinglé, 21 sur main	Non signalé ; la même cause que #772
76. Le vii° d’une tonalité mineure reçoit un chiffre romain	Sur main, romanFor cherche la fondamentale parmi les sept notes de la gamme naturelle : vii°7 reçoit ? dans les 15 tonalités mineures, comme bIII et bVI en C majeur	DomainClosures.fs lignes 353-374 à 6baf32e	l13, la grille : n 15 sur main ; les accords d’emprunt	Signalé dans #775
77. Des accords d’emprunt laissent la tonalité sur l’accord qui ouvre et ferme la progression	Sur main, Identify compte les accords diatoniques avant de regarder l’accord d’ouverture, puis préfère la tonalité majeure, puis le nom : C Bb F C est en F majeur, V IV I V, et C Ab Bb C en E♭ majeur, VI IV V VI, une tonalité où l’accord de C majeur n’est pas diatonique ; seule la confiance, 2/4, le laisse voir	KeyIdentificationService.cs lignes 224-227 à 6baf32e	l13, les accords d’emprunt	Signalé dans #775
78. La confiance compte le ii et le vii° d’une tonalité mineure comme les siens	Sur main, NormalizeChord réduit Bm7b5 à Bm, un accord mineur : Bm7b5 E7 Am est à 2/3, et iiø7 V7 i reste sous le nombre d’accords dans les 15 tonalités mineures. G♯dim7 n’est pas dans le mineur naturel, mais F##dim7 est lu comme F♯ majeur, le VII de G♯ mineur, et compte	KeyIdentificationService.cs ligne 319 à 6baf32e, ligne 132, lignes 145-150	l13, la grille : sous le nombre d’accords pour iiø7 V7 i dans 15 tonalités, pour i iv vii°7 i dans 12	Signalé dans #775
79. La liste de substituts dépend de l’accord	FindNearby place tous les accords de la classe d’ensembles de la source au même coût, le plus petit, et le skill garde les cinq dont le masque de bits est le plus petit : les listes des 12 accords majeurs nomment six accords, Cm C Ab Dbm Fm Db ; la liste de G7 n’a pas D♭7 ; les accords de septième majeure et de septième mineure ne reçoivent de substitut de manuel sur aucune des 12 fondamentales ; 29 des 60 accords proposés pour les accords majeurs n’ont aucune note commune avec leur source	ChordSubstitutionSkill.cs lignes 164-174, GrothendieckService.cs lignes 55-81	l14, un accord : 108 accords ; ga_chord_substitutions identique pour les 108	Signalé dans #777
80. Des vecteurs d’intervalles égaux sont à distance 0	GrothendieckDelta.FromIcVs écrit 1 à la place d’une différence nulle : C et C, C et Am, G7 et D♭7 sont à L1 1 ; chaque substitut proposé coûte 0.60, et chaque paire d’une même classe d’ensembles est « ICV Neighbor (L1 = 1) ». Les exemples du SKILL.md, des coûts de 0.50 et 0.83 et un L1 de 0, ne peuvent pas se produire	GrothendieckDelta.cs lignes 125-131, SKILL.md lignes 100-108	l14, les quatre lignes ComputeDelta	Signalé dans #776
81. La comparaison nomme ce que nomme un manuel	Un v mineur est « Secondary Dominant », d’après les seules fondamentales. Am et C, qui ont deux notes communes, F♯m et C, qui n’en ont aucune, et C avec lui-même reçoivent les mêmes étiquettes, « Set-Class Equivalent » et « ICV Neighbor (L1 = 1) » ; Em7b5 et C7, qui en partagent trois, aussi	ChordSubstitutionSkill.cs lignes 261-264, lignes 279-290	l14, deux accords, sur les 12 fondamentales ; ga_chord_compare identique	Signalé dans #777
82. La réponse suit la relation que nomme la question	Un seul accord reçoit la liste, quoi que demande la question : « Tritone substitution for G7 », « What’s the secondary dominant of Am? » et « Show me a backdoor dominant for C major » n’obtiennent ni D♭7, ni E7, ni B♭7. Un nom de tonalité et un article sont lus comme des accords : « Alternative chord for F major in C » compare F à C, « A substitute for G7? » A à G7	ChordSubstitutionSkill.cs lignes 146-160, lignes 69-71	l14, les prompts d’exemple ; ce que le skill lit	Signalé dans #777
83. Le skill lit les chiffrages que liste son SKILL.md	Ni le skill ni ga_chord_substitutions ne lisent Cmin7, alors que le SKILL.md liste min7 ; B♭7 est lu comme B majeur	ChordSubstitutionSkill.cs lignes 69-71, ChordSubstitutionMcpTools.cs lignes 230-232, SKILL.md ligne 92	l14, ce que le skill lit	Signalé dans #777 ; B♭ lu comme B, c’est la même lecture que #757
84. CanHandle accepte les prompts d’exemple de son skill	substitut\b et reharmoni\b ne reconnaissent aucun mot, et « secondary dominant », « backdoor », « replace » et « modal interchange » n’ont pas de déclencheur : 4 sur 12 acceptés. Sur main, le routeur se replie sur CanHandle quand il ne peut pas calculer l’embedding d’une question	ChordSubstitutionSkill.cs lignes 59-75, SemanticIntentRouter.cs ligne 321 sur main	l14, les prompts d’exemple : 4 sur 12	Signalé dans #777
85. ga_dsl_eval exécute une closure sans les entrées que son schéma dit optionnelles	domain.chordSubstitutions déclare key et scale en string?, avec des valeurs par défaut, mais ga_dsl_eval exige toutes les entrées : missing-required-arg. Cinq entrées de deux closures sont marquées optionnelles. Sans tonalité, la closure prend la fondamentale de l’accord en majeur : Am reçoit les accords de A majeur	DslEvalMcpTools.cs lignes 257-270, DomainClosures.fs lignes 557-559	l14, la closure	Signalé dans #778
86. La description d’un outil correspond à sa réponse	Le GaChordSubstitutions de GaMcpServer promet, pour Am en C majeur, « C (★★★, relative major), Em (★★, shared E/B), F (★, shared A) » ; la closure donne deux étoiles à C et à F, avec deux notes communes chacun, et une à Dm et à Em	GaDslTool.cs ligne 212, DomainClosures.fs ligne 614	l14, la closure	Signalé dans #778
87. Seul le nom d’un accord est lu comme sa fondamentale	L’article « a » devant « chord » devient la fondamentale A : « what makes a chord a major seventh », « what makes a chord diminished » et « what makes a chord a dominant seventh », trois prompts d’exemple, reçoivent « A major chord contains A, C#, and E ». L’expression des chiffrages ignore la casse : « am » y devient A mineur, dans « I am learning Cmaj7, what notes are in it? » et « Am I right that G7 has an F? » ; l’expression des notes lit l’article de « Which chord has a C, an E and a G? » : A mineur 7	ChordInfoSkill.cs lignes 302-303, ligne 315, ligne 325	l15, les prompts d’exemple : 3 sur 3 ; au-delà du vocabulaire ; les listes de notes	Signalé dans #782
88. Le skill lit ses propres prompts d’exemple	« anatomy of a D7sus4 chord », « what is a C add 9 chord » et « tones in a Bb diminished seventh » reçoivent « Could not parse a chord name from your question. » : l’expression des chiffrages n’a ni 7sus4 ni « add 9 » avec une espace, et le troisième prompt n’a ni « chord » ni chiffrage. CanHandle rejette aussi « Tell me the tones in F#m7b5 » et « break down Gmaj13 for me », auxquels le skill répond ; sur main, le routeur se replie sur CanHandle quand il ne peut pas calculer l’embedding d’une question	ChordInfoSkill.cs lignes 100-110, lignes 267-282, SemanticIntentRouter.cs ligne 321 sur main	l15, les prompts d’exemple : 26 justes sur 29, CanHandle 27 sur 32	Signalé dans #782
89. Le skill lit les suffixes que connaît son vocabulaire	22 sur 82 ne sont pas lus, ou sont lus comme une autre qualité : les chiffrages +, 5, no3, dom7, ma7, Δ7, -7, °7, min7b5, ø et ø7, 7+5 lu comme une septième de dominante, et dix mots, dont « power », « dominant » et « diminished 7 ». La formule de l’accord de puissance est hors d’atteinte. Le commentaire de l’expression des chiffrages range + et « power 5/no3 » parmi les formes qu’elle lit	ChordInfoSkill.cs lignes 302-316, ChordVocabulary.cs lignes 59-104	l15, chaque suffixe : 60 sur 82	Signalé dans #782
90. Le Δ7 du vocabulaire est une septième majeure	NormalizeQuality met le suffixe en minuscules avant son second switch, et ToLowerInvariant change Δ en δ : la branche "Δ7" ne peut pas correspondre, et δ7, que GetFormula ne connaît pas, reçoit un accord majeur, comme toute qualité inconnue. Aucune des deux expressions du skill ne lit Δ	ChordVocabulary.cs ligne 66, ligne 82, ligne 140	l15, chaque suffixe : NormalizeQuality("Δ7") renvoie δ7	Signalé dans #783
91. Un chiffrage lu en partie ne reçoit pas la réponse d’un accord plus petit	Après le suffixe, l’expression des chiffrages accepte #, (, / et + : Cmaj7#11 reçoit la réponse de Cmaj7, C7#11 et C7(b9) celle de C7, Cm(maj7) celle de Cm, C6/9 celle de C6, C7#5#9 celle de C7#5 et C7+5 celle de C7, sans que la réponse dise ce qu’elle a laissé de côté. Le skill d’improvisation de la leçon 5 fait de même, ligne 23	ChordInfoSkill.cs ligne 315	l15, au-delà du vocabulaire : 6 chiffrages ; chaque suffixe : 7+5	Signalé dans #782
92. Le skill nomme les accords qu’il épelle	Quand on lui rend ses propres orthographes, il nomme les 293 à altérations simples et aucune des 106 qui portent une altération double ou triple : l’expression des notes laisse tomber Bbb et lit C## comme C♯, si bien que C E♭ G♭ B♭♭, son Cdim7, devient C diminué, et F♯ A♯ C♯♯ F♯ majeur. ChordVocabulary.PitchClasses n’a d’ailleurs aucun nom à deux altérations. B♭ est lu comme B : C E G B♭ devient C majeur 7	ChordInfoSkill.cs lignes 325-326, ChordVocabulary.cs lignes 23-32	l15, l’aller-retour : 0 sur 106 renommés	Signalé dans #782 ; B♭ lu comme B, c’est la même lecture que #757
93. La lecture des notes connaît les accords que le skill épelle	7b9 et 7#9 ont cinq notes, dans la limite, mais ne figurent pas parmi ses 19 formules : « What chord is C E G Bb Db » est refusé, alors que « What is C7b9 » épelle ces notes et que le corpus de GA pose les deux questions. « What chord is C E G# B », l’exemple que donne le commentaire de la liste lui-même, est refusé : Cmaj7♯5 n’est pas dans la liste	ChordInfoSkill.cs lignes 236-265, lignes 261-262	l15, l’aller-retour : 0 sur 42 ; les listes de notes	Signalé dans #782
94. Une note s’écrit comme l’intervalle qui la nomme	La formule de l’accord de dominante altéré place sa « flat fifth » trois lettres au-dessus de la fondamentale : F♯ pour C et F♯♯ pour C♯, là où la quinte diminuée est G♭ et G	ChordVocabulary.cs ligne 130	l15, l’orthographe : les 21 accords qui diffèrent, tous 7alt	Signalé dans #783
95. ga_chord_info lit les chiffrages que liste son SKILL.md	L’expression propre à l’outil lit 14 des 51 chiffrages du vocabulaire et refuse Cdom7, que liste le tableau du SKILL.md. Le SKILL.md fait décliner au modèle les accords suspendus et à note ajoutée, les accords de neuvième, d’onzième et de treizième, les dominantes altérées et les listes de notes, auxquels le skill C# répond	ChordMcpTools.cs lignes 81-82, SKILL.md ligne 68, lignes 95-102	l15, l’outil : 15 sur 16 ; chaque suffixe : 14 sur 51	Signalé dans #783
96. Une qualité en toutes lettres est lue comme cette qualité	« minor » est lu comme un mode et l’accord comme une triade majeure : « voicings for A minor » est lu comme A majeur avec le mode « minor », et sur main, l’exemple « open chord shape for E minor » reçoit huit voicings de E majeur. Dans « voicings for C … », les 31 qualités en toutes lettres de la leçon 15 sont toutes lues comme C majeur, et seul « major » est juste. L’index laisse ensuite tomber le mode (ligne 100)	TypedMusicalQueryExtractor.cs lignes 90-102, lignes 104-111, lignes 217-226	l16, les mots : 1 sur 31 ; l16 (main), « open chord shape for E minor » : other 8	Signalé dans #785
97. CanHandle accepte les accords auxquels le skill répond	Il rejette son propre exemple « quartal voicings in C », tout accord majeur écrit sans suffixe (« voicings for C », « G chord shapes », « Bb voicings please »), l’accord à basse imposée « voicings for C/G » et, dans l’exercice 3, « voicings for C-7 » : une fondamentale seule, / et - ne correspondent à aucune de ses expressions. Il accepte 13 des 31 qualités en toutes lettres, celles qui commencent par « major » ou « minor » : dim et aug doivent terminer un mot. Sur main, le routeur se replie sur CanHandle quand il ne peut pas calculer l’embedding d’une question	ChordVoicingsSkill.cs lignes 57-73, lignes 178-185, SemanticIntentRouter.cs ligne 321 sur main	l16, les exemples : 11 sur 12 ; autres formulations : 4 sur 10 ; les mots : 13 sur 31	Signalé dans #785
98. Les deux lecteurs de chiffrages du chatbot s’accordent	ChordPitchClasses, qui lit l’accord d’une demande de voicings, lit 47 des 51 symboles de la leçon 15 comme un manuel les orthographie : Cdom7, Cma7 et C7+5 ne donnent aucun accord, et C-7 est lu comme C7, parce que le contrôle du reste prend - pour un séparateur. Il lit cinq symboles autrement que ChordVocabulary, qu’utilise ChordInfoSkill : dom7, ma7, Δ7, -7 et 7+5	MusicalQueryEncoder.cs lignes 240-336, ligne 335, ChordVocabulary.cs lignes 81-87	l16, les symboles : 47 sur 51 ; lus autrement : 5	Signalé dans #785
99. L’index nomme un accord de façon que le filtre sur le nom le trouve	Sur main, l’index stocke le nom que l’analyse de GA donne à chaque voicing, et le filtre compare sa fondamentale et sa qualité à celles de la demande. C E G A est nommé Am7, jamais C6 ; le 6/9 C D E G A est nommé C6 ; D G A est nommé Gsus2 ; une triade augmentée prend le nom de l’une de ses trois fondamentales, Faug pour D♭ F A. Le filtre coupe un nom stocké à sa première parenthèse : Dbaug(maj7)/C passe donc pour D♭ augmenté. Dans une grille de 144 accords, les 12 accords de sixte, 8 triades augmentées et 6 triades sus4 n’ont aucun voicing à eux, alors que le corpus de la leçon 3 les contient tous	OptickSearchStrategy.cs lignes 307-319 sur main, lignes 348-349	l16 (main), les noms de cinq accords ; la grille, fondamentales sans voicing exact : 12 sur 12 pour 6, 8 pour aug, 6 pour sus4	Signalé dans #784
100. Une technique que nomme le prompt est respectée, ou la réponse dit qu’elle ne l’est pas	Sur main, le chemin de l’index laisse tomber Tags et ModeName à dessein (ADR-0002), et VoicingAgent journalise les filtres abandonnés ; ChordVoicingsSkill ne journalise rien, et sa réponse n’en dit rien. Des 48 voicings renvoyés aux six prompts d’exemple qui nomment une technique, 5 relèvent de cette technique, 2 drop2 et 3 voicings barrés ; aucun n’est un shell, un A7 rootless, un voicing quartal ou un E mineur ouvert, alors que le corpus de la leçon 3 en contient respectivement 19, 45, 1 et 60	OptickSearchStrategy.cs lignes 101-130 sur main, VoicingAgent.cs lignes 110-126, 0002-voicing-filter-parity-cpu-gpu-only.md	l16 (main), les techniques : 5 sur 48	Signalé dans #784
101. Un skill qui n’a pas besoin de modèle répond quand le routeur ne peut pas calculer l’embedding de la question	CapoSkill et AlternateTuningsSkill répondent sans modèle, mais leur CanHandle renvoie false, « semantic-routing only », au commit épinglé comme sur main. Sur main, le repli du routeur par mots-clés, ajouté pour que les skills déterministes répondent quand les embeddings sont en panne, ne les atteint jamais : il ne leur confie aucun de leurs 22 prompts d’exemple. Avec les CanHandle du commit épinglé, deux d’entre eux vont à d’autres skills : celui qui nomme Em à skill.chordinfo, « What chord shape for B major with capo 4 » à skill.chordvoicings	CapoSkill.cs ligne 47, AlternateTuningsSkill.cs ligne 50, SemanticIntentRouter.cs ligne 321 sur main	l17, sans embeddings : 0 sur 22	Signalé dans #787 et #788
102. CapoSkill répond à la question posée	Le sens du calcul se lit dans la formulation : sauf si la question nomme une forme, une tonalité après « in » est la tonalité entendue, et la réponse est une forme. Son propre exemple « What’s the sounding key if I play in G with capo on 5 » reçoit la forme D au lieu de la tonalité entendue, C, et « Playing in D with capo 2, what key does it sound in? » la forme C. Les expressions ignorent la casse : dans « I’m in a band, capo 2, song is in G », l’article est donc lu comme la tonalité A. La ligne 82 lit de la même façon un article comme un accord	CapoSkill.cs lignes 52-64, lignes 89-104	l17, les exemples et les autres formulations : sens inversé 2 ; « in a band » : mauvais accord	Signalé dans #787
103. CapoSkill lit une tonalité avec son altération	L’expression de la tonalité se termine par \b, qui échoue après #, ♯ et ♭ : l’expression ne garde que la lettre. « Capo on 2, song in F# » reçoit la forme D♯ au lieu de E, « song in C#, capo 4 » G♯ au lieu de A, et « song in B♭, capo 1 » A♯ au lieu de A. Avec « major » ou « minor » après la tonalité, la lecture est juste. La ligne 106 est la même limite de mot dans le skill des accordages	CapoSkill.cs lignes 52-56	l17, autres formulations : mauvais accord pour F#, C# et B♭	Signalé dans #787
104. CapoSkill lit les tonalités et les formes qu’écrit un guitariste	Il refuse son propre exemple « What chord shape for B major with capo 4 » et « what shape for F with capo 3 » : une tonalité doit suivre « in » ou « key ». Il refuse « song in Em » : une tonalité mineure doit être écrite en toutes lettres. Il refuse C♭ majeur, absent de sa table des fondamentales, et les formes C7, Cmaj7 et Dsus4 : une forme, c’est une lettre, une altération et un m facultatif. Il refuse « Where should I put the capo to play in with open chords? » pour les 12 tonalités : ses deux expressions exigent un numéro de case	CapoSkill.cs lignes 52-64, lignes 67-76	l17, les exemples : 1 refusé ; la grille : 11 refusés (Cb) ; autres formulations : 5 refusés ; où placer le capodastre : 12 refusés	Signalé dans #787
105. CapoSkill écrit une tonalité comme l’écrit une armure	Il écrit des dièses, sauf si la tonalité ou la forme qu’il a lue porte un bémol, ou, pour une forme, si la question contient « flat ». 27 formes de la grille majeure, et 3 des 11 réponses pour chaque forme ouverte majeure, sont A♯, D♯ ou G♯ majeur : une forme de C avec le capodastre en case 3 sonne en D♯, là où le commentaire de la classe dit E♭. Les tonalités mineures écrites avec des bémols reçoivent des formes D♭m et G♭m. La ligne 56 est la même orthographe dans domain.transposeChord	CapoSkill.cs lignes 178-191, ligne 13	l17, la grille : orthographe théorique 27 en majeur, 6 en mineur ; les formes ouvertes : 3 sur 11 pour chaque forme majeure	Signalé dans #787
106. AlternateTuningsSkill lit un accordage donné par ses notes	L’expression des six notes se termine par \b : #, ♯ et ♭ tombent. Les notes de l’open D sont lues D A D F A D et ne reçoivent aucun nom, dans toutes les notations ; E♭ A♭ D♭ G♭ B♭ E♭ est lu E A D G B E ; l’accordage E♭ standard écrit en dièses, D♯ G♯ C♯ F♯ A♯ D♯, est nommé Whole-step down (D standard), plus bas d’un demi-ton sur chaque corde. NotesMatch compare des orthographes : G♭ pour F♯ ne reçoit pas de nom non plus (exercice 3). Inchangé sur main	AlternateTuningsSkill.cs lignes 203-211, lignes 228-238	l17 et l17 (main), par les notes : 35 sur 44, un autre accordage nommé 4	Signalé dans #788
107. AlternateTuningsSkill répond par l’accordage nommé, ou refuse	Au commit épinglé, « open D minor » reçoit l’open D et « open G minor » l’open G, une tierce majeure pour une tierce mineure ; « drop C♯ » reçoit le drop C et « drop D♭ » le drop D. Sur main, les deux questions de drop sont refusées, et les deux questions mineures reçoivent toujours les accordages majeurs. Le commentaire de la classe promet une mise en garde pour « What does an Em shape look like in drop-D » ; la réponse est la table du drop D, qui ne nomme pas Em	AlternateTuningsSkill.cs lignes 53-74, ligne 15, lignes 57-67 sur main	l17, hors de la table : un autre accordage 4 ; l17 (main) : un autre accordage 2 ; la réponse nomme Em : non	Signalé dans #788
108. Un skill qui n’a pas besoin de modèle répond quand le routeur ne peut pas calculer l’embedding de la question	VoiceLeadingSkill répond sans modèle, mais son CanHandle renvoie false, « semantic-routing only », au commit épinglé comme sur main. Sur main, le repli du routeur par mots-clés ne l’atteint jamais : il ne lui confie aucun de ses 10 prompts d’exemple. Avec les CanHandle du commit épinglé, les deux qui disent « voicing » vont à skill.chordvoicings, qui répond par des doigtés pour un seul accord. La ligne 101 fait le même constat pour les skills du capodastre et des accordages	VoiceLeadingSkill.cs ligne 49, SemanticIntentRouter.cs ligne 321 sur main	l18, sans embeddings : 0 sur 10	Signalé dans #789
109. Le total de VoiceLeadingSkill est le mouvement minimal, comme l’affirme sa réponse	Entre deux accords de même taille, il l’est toujours. Quand les tailles diffèrent, le skill double la fondamentale du plus petit accord, et 1186 réponses sur 3072 demandent plus de mouvement qu’avec une autre doublure, jusqu’à 7 demi-tons de plus : Csus2 vers Em9 reçoit 11 demi-tons là où 4 suffisent, et son propre exemple « smoothest voicing from Em to A7 » 5 là où 4 suffisent. Chaque réponse se conclut par « every other voicing of … requires more total semitone movement », ce qui est faux aussi dans les 607 réponses où un autre appariement demande tout aussi peu de mouvement	VoiceLeadingSkill.cs lignes 101-110, ligne 131, lignes 185-194	l18, la grille : plus que le minimum 1186 sur 3072, plusieurs meilleurs appariements 607 ; les exemples : Em → A7 5, minimum 4	Signalé dans #789
110. VoiceLeadingSkill lit les chiffrages que liste sa table	24 des 46 chiffrages sont lus correctement comme premier accord, et 24 comme dernier. Δ, ø, +, -, o, « major7 » et « dom7 » sont refusés, sauf + et - comme dernier accord, lus comme la lettre seule. CM7 est lu comme C mineur septième : la qualité est mise en minuscules avant la table, qui liste M7. Un ° final tombe, les mots qui suivent le dernier accord sont ignorés (« voice leading F to C minor » reçoit C majeur), et les accords écrits en toutes lettres avant « to » sont refusés, dont son propre exemple « voice leading C major to G major ». add9, 7sus4, 7♭9, 7♯9, mMaj7, 11 et 13 sont refusés à dessein	VoiceLeadingSkill.cs lignes 51-57, lignes 224-252	l18, les chiffrages : justes 24 sur 46 comme premier accord, 24 comme dernier ; les exemples : 1 refusé	Signalé dans #789
111. VoiceLeadingSkill lit une fondamentale avec son altération	L’expression se termine par \b, qui échoue après #, ♯ et ♭ : un dernier accord ne garde donc que sa lettre, et « voice leading from C to F# » reçoit C → F. Avec un m après l’altération, ou un b écrit en ASCII, la lecture est juste. Les lignes 103 et 106 sont la même limite de mot dans les skills du capodastre et des accordages	VoiceLeadingSkill.cs lignes 55-57	l18, altérations : justes comme dernier accord 0 sur 5 pour #, ♯ et ♭	Signalé dans #789
112. VoiceLeadingSkill écrit les notes comme les écrivent leurs accords	Il écrit des dièses, sauf si un chiffrage porte un bémol ou si la question contient « flat ». TokenHasFlats cherche b sans tenir compte de la casse : il trouve donc la fondamentale de « Bb » en position 0, et ne la compte pas. « F7 to Bbmaj7 » donne A♯ et D♯. Sans bémol dans la question, D7 vers Gm donne A♯ pour B♭. Avec un nom par classe de hauteurs, E♯, B♯ et le F double dièse s’écrivent F, C et G. La ligne 105 est la même orthographe dans le skill du capodastre	VoiceLeadingSkill.cs lignes 85-86, lignes 261-266	l18, orthographe : conforme à l’accord 22 sur 36 ; altérations : « Bb » en premier accord écrit A#	Signalé dans #789
113. VoiceLeadingSkill lit les accords de la question, ou refuse	L’expression ignore la casse : « how do I get from G7 to a C chord » lit donc l’article comme l’accord A. « voice leading Dm7 to G7 to Cmaj7 » ne reçoit que son premier mouvement, et la réponse ne le dit pas. « - » et « into » ne sont pas lus comme « to ». La ligne 102 lit de la même façon un article comme une tonalité	VoiceLeadingSkill.cs lignes 51-57	l18, autres formulations : mauvais accord 4, refusés 3, deux accords sur trois 1	Signalé dans #789
114. ga_voice_leading_pair vérifie les voicings qu’il apparie	L’outil classe les paires par le seul mouvement, et sa recherche ne nomme aucun accord : rien ne compare donc un voicing à l’accord demandé. Avec 50 candidats par accord, ce que sa description appelle « more exhaustive », les premières paires se dégradent : sur main, les premières paires de 8 des 10 exemples de la leçon 18 jouent les deux accords, contre 10 avec 15 candidats, et G7 → Cmaj7 et D → A sacrifient l’accord à 2 demi-tons au lieu de 3. Au commit épinglé, aucune ne les joue, et C → Am apparie trois E avec eux-mêmes, pour 0 demi-ton	CompositionTools.cs ligne 195, lignes 224-235, lignes 278-298	l19 (main), 50 candidats : justes des deux côtés 8 sur 10 ; l19, 50 candidats : 0	Signalé dans #791
115. VoiceLeadingDistance apparie un voicing plus petit à ses notes les plus proches, comme le dit son commentaire	La méthode apparie les notes les plus graves du plus grand voicing. Sur main, 340 des 1360 paires de tailles différentes que l’outil évalue pour les dix exemples obtiennent le mouvement minimal, et l’écart atteint 39 demi-tons : Em x-x-2-x-0-3 vers A7 0-0-2-x-2-3 est évalué à 47 là où 8 suffisent. Entre voicings de même taille, l’appariement trié est toujours minimal, bien que la description le dise « not a formal Hungarian-optimal assignment ». Pour ces dix exemples, la plus petite distance ne change pas	CompositionTools.cs lignes 180-185, lignes 312-336	l19 (main) : tailles différentes 340 sur 1360, plus grand écart 39 ; même taille 890 sur 890	Signalé dans #791
116. ga_voice_leading_pair renvoie ses diagrammes dans l’ordre des grilles d’accords	Il renvoie la chaîne de l’index, mi aigu en premier : sur main, la première paire de C → F revient sous la forme 0-1-0-x-x-x → 1-1-2-x-x-x, qu’une grille d’accords écrit x-x-x-0-1-0 → x-x-x-2-1-1. Sur main, ChordVoicingsSkill remet les mêmes chaînes dans l’ordre des grilles ; la réponse de l’outil ne dit pas quelle corde vient en premier	CompositionTools.cs lignes 239-254, ChordVoicingsSkill.cs ligne 136 sur main	l19 (main), la première paire de C → F telle que l’outil la renvoie	Signalé dans #791
117. Le skill de conduite des voix en attente décrit l’outil qu’il appellerait	skills-dev/_pending-tools/voice-leading/DRAFT.md attend un argument optimize et une réponse avec VoiceMovements, TotalSemitones et CommonTones ; ga_voice_leading_pair ne prend aucun argument optimize et renvoie des paires de voicings avec une distance. Le brouillon promet « a Plücker-line / minimum-displacement solution » et renvoie à HarmonyMcpTools.cs, que GA n’a pas, et son exemple de réponse annonce 2 demi-tons de Dm7 à G7 pour des mouvements de 0, 0, 2 et 1. Son README le laisse en attente parce que les outils propres au chatbot n’incluent pas ga_voice_leading_pair, que GaMcpServer possède	DRAFT.md lignes 29-44, lignes 54-60, ligne 74, README.md lignes 19-29	l19 (main), Dm7 → G7 : 3 demi-tons ; le brouillon, lu aux deux commits	Signalé dans #791
118. ga_generate_progression écrit chaque accord comme l’écrit sa tonalité	Chaque accord des neuf gabarits, dans les 15 tonalités de chaque mode, a les bonnes classes de hauteurs, et 712 des 750 sont écrits comme les écrit un manuel. PrefersFlats exige un b dans la tonique, ou la tonique F : D, G et C mineur reçoivent donc des dièses, et l’andalusian en C mineur reçoit A♯ et G♯ pour B♭ et A♭. Avec un nom par classe de hauteurs, le I et le IV de C♭ majeur s’écrivent B et E, le IV de G♭ majeur B, le iii de C♯ majeur Fm, le V de A♯ mineur F7, et le ♭VI de E♭ et de A♭ mineur B et E. Le ChordProgressions.yaml de GA écrit le même B pour le IV de G♭. La ligne 54 est le même choix dans domain.diatonicChords	CompositionTools.cs lignes 344-380, ChordProgressions.yaml ligne 685	l20, les gabarits : bien écrits 712 sur 750, classes de hauteurs justes 750 ; les tables du YAML : mêmes accords sur chaque ligne	Signalé dans #792
119. ga_generate_progression lit la tonalité qu’on lui donne	La tonique passe par ChordPitchClasses.TryParse, un lecteur de chiffrages. « D minor » et « Dm » sont lus comme D : I-V-vi-IV en « D minor » reçoit donc les accords de D majeur, sans avertissement. PrefersFlats compare la chaîne entière à « F », si bien que « F major » reçoit des dièses, F C Dm A#. « b » est lu comme B et fait passer B majeur aux bémols, B Gb Abm E, et n’importe quel b de la chaîne décide de l’orthographe : « C7b9 » écrit l’andalusian en C mineur en bémols, ce que « C » ne fait pas. ♭ est refusé	CompositionTools.cs ligne 139, ligne 379, MusicalQueryEncoder.cs lignes 166-171	l20, les toniques : « D minor » → D A Bm G, « b » → B Gb Abm E	Signalé dans #792
120. ga_generate_progression borne la longueur de sa réponse	length répète le gabarit sans limite, alors que limit et candidatesPerChord, dans le même fichier, sont bornés : une longueur de 100000 renvoie 100000 accords, soit 17 300 216 caractères de JSON. 0 et une longueur négative donnent la longueur du gabarit lui-même, sans avertissement	CompositionTools.cs lignes 148-151, lignes 202-203	l20, la longueur : 100000 accords, 17300216 caractères	Signalé dans #792
121. Raccorder une progression générée avec ga_voice_leading_pair donne un chemin de voicings, comme le suggère la remarque de l’outil	La remarque dit « stitch with ga_voice_leading_pair ». Une première paire par mouvement, en C majeur ou en A mineur : sur main, elles se rejoignent à 17 endroits sur 32, là où la paire suivante part du voicing où finit la précédente ; ailleurs, la main saute entre deux voicings d’un même accord. Dans 7 des 9 gabarits, un chemin continu à travers les mêmes candidats bouge aussi peu que les premières paires additionnées ; dans rhythm-changes-a et 12-bar-blues, tout chemin continu bouge davantage, 25 demi-tons pour 21 et 28 pour 24	CompositionTools.cs lignes 174-175, lignes 224-235	l20 (main) : les premières paires se rejoignent 17 fois sur 32 ; l20 : 6 sur 32	Signalé dans #792
122. Le skill de progression en attente décrit l’outil qu’il appellerait	skills-dev/_pending-tools/progression-generator/DRAFT.md attend mood, key, length avec une valeur par défaut de 4, style et complexity, et une réponse avec Chords, RomanNumerals, Style et Rationale ; l’outil prend root, template et length et renvoie chords. Ses tonalités « D minor » et « F major » sont mal lues comme toniques (ligne 119), son exemple Dm – B♭maj7 – Gm – A7 ne correspond à aucun gabarit, et il renvoie à ProgressionMcpTools.cs, que GA n’a pas. La ligne 117 est le même constat pour le brouillon de conduite des voix	DRAFT.md lignes 32-45, lignes 49-63, ligne 77	l20, les toniques ; le brouillon, lu aux deux commits	Signalé dans #792
123. ga_search_voicings cherche par mode	La description de l’outil promet « mode names (Lydian, Dorian) », et le skill appelle MODAL « mode flavor ». Le lecteur trouve les 23 modes, mais MusicalQueryEncoder.Encode ne lit jamais le mode : après C, Am et G7, 19 des 23 modes répondent comme l’accord seul, 18 après Dm7, et les autres lisent un tag. Un mode seul donne un score de 0 à chaque voicing et renvoie les dix premiers de l’index, car HasIntent compte le mode, et la réponse « No chord, mode, or known tag recognized » ne vient jamais. « lydian dominant » et « phrygian dominant » sont lus comme Lydian et Phrygian, plus le tag « dominant ». Dans « something jazzy in F minor », l’exemple du vocabulaire lui-même, le lecteur lit l’accord F, et la requête reçoit des voicings de F majeur	VoicingSearchTool.cs ligne 95, lignes 238-242, MusicalQueryEncoder.cs lignes 43-108, TypedMusicalQueryExtractor.cs lignes 104-121	l21, les modes : C, identique pour 19 sur 23 ; modes seuls, 18 sur 23 à 0.0000, les dix premiers de l’index ; l21 (main) : de même	Signalé dans #795
124. Un tag obtient les voicings qu’il nomme	Les 188 tags se partagent 12 bits de SYMBOLIC, qui pèse 0.10 du score, et les tags d’un même bit répondent de la même façon : jazz comme rock-guitar, shell-voicing comme rootless. Les 188 tags donnent à Cmaj7 7 réponses différentes au commit épinglé, 5 sur main, et les tags des bits 3, 4, 5 et 10 ne changent rien. Après dix accords de septième, « rootless » ne renvoie aucun voicing rootless sur 100, au commit épinglé comme sur main, alors que l’index en contient entre 5 et 63 pour chaque accord : la STRUCTURE de la requête contient l’accord entier, fondamentale comprise	SymbolicVectorService.cs lignes 13-32, SymbolicTagRegistry.cs lignes 46-111, SemanticNomenclature.yaml lignes 129-140	l21, les tags : Cmaj7, 7 réponses différentes, 12 bits sur 12 homogènes ; « rootless » : voicings renvoyés 100, rootless 0 ; l21 (main) : Cmaj7 5, rootless 0	Signalé dans #795
125. Le lecteur prend pour tags les mots du vocabulaire	GetBitIndex se replie sur une correspondance par sous-chaîne, dans les deux sens : « for » se lit normal-form, « the » pitch-axis-theory, « what » so-what-chord, « end » beginner-friendly. Le lecteur saute « chord », « voicing » et les mots de moins de trois lettres, pas ceux-là. Un second bit diminue le poids du premier : « G7 shell for » obtient 0.4932, « G7 shell » 0.5078. L’exemple du skill, « something jazzy in F minor for a ballad », et celui du vocabulaire, « shell voicing for G7 », lisent « for ». Deux tags listés ne peuvent pas être tapés : g5 a moins de trois lettres, et schoenberg-op.16-chord se coupe à son .	SymbolicTagRegistry.cs lignes 196-220, TypedMusicalQueryExtractor.cs lignes 132-147	l21, les requêtes d’exemple de GA : for → normal-form ; celles du cours : the → pitch-axis-theory, what → so-what-chord, end → beginner-friendly	Signalé dans #795
126. Le skill de recherche de voicings décrit les scores et les tags tels que l’outil les traite	Selon les poids du skill, les scores « approach 1.0 », et son exemple obtient 0.9831, mais une requête laisse MORPHOLOGY et CONTEXT à zéro : aucune requête ne peut dépasser 0.70, et les 828 requêtes d’accords plafonnent à 0.5250 au commit épinglé, à 0.6000 sur main. « drop2 does NOT match » : pourtant « drop2 » se lit drop2voicings, la copie sans traits d’union du registre. Un tag de style « currently lowers the score » : « Cmaj7 jazz » obtient 0.5085, « Cmaj7 » 0.4585, sur l’index qu’écrit le code du commit épinglé. Ses usages « Lydian on guitar », « jazz voicings » et « shell voicings » ne nomment aucun accord et obtiennent 0, 0.0577 et 0.0707 ; dans « something warm and dreamy », donnée comme une requête dont le lecteur ne tire rien, celui-ci lit dreamy	SKILL.md ligne 19, ligne 26, ligne 39, ligne 47, ligne 81, lignes 94-96	l21, les scores : le plus haut qu’une requête peut atteindre 0.70, requêtes d’accords 828, le plus haut score de tête 0.5250 ; l21 (main) : 0.6000	Signalé dans #795
127. Le skill de recherche de voicings en attente décrit l’outil qu’il appellerait	skills-dev/_pending-tools/voicing-search/DRAFT.md appelle ga_search_voicings_by_query, qui se trouve dans VoicingEmbeddingTool.cs et demande GaApi et Ollama ; le brouillon dit qu’il n’est pas implémenté et renvoie à VoicingMcpTools.cs, que GA n’a à aucun des deux commits. Il attend topK, instrument et une réponse faite de Results avec contextTags et sourceCorpus ; l’outil prend query et limit. Son « mellow Cm9 », x-3-5-3-3-3, n’a pas de tierce mineure, son diagramme appelle E♭ la troisième case de la corde de sol et D celle du mi aigu, là où elles jouent B♭ et G, et aucun de ses trois tags ne figure dans le vocabulaire. Les lignes 117 et 122 sont le même constat pour les deux autres brouillons	DRAFT.md lignes 22-26, lignes 35-44, lignes 57-68, ligne 83, VoicingEmbeddingTool.cs lignes 93-132	l21, le brouillon : x-3-5-3-3-3 joue C G A# D G, omet D# ; ses tags dans le vocabulaire : non	Signalé dans #795
128. IcvNeighborsSkill répond à ses prompts d’exemple	La révision du 2026-06-16 a reformulé les dix ancres de routage du skill avec « resemble », « similar » et « most like », et retiré « close », « nearby » et « ICV », mais les deux expressions régulières qui lisent la question exigent toujours « neighbors », « nearby », « close to », « near », « adjacent » ou « harmonically close » : le skill décline les dix ancres, les questions auxquelles le routeur compare celles qu’il reçoit, et sa règle d’indice n’en favorise aucune. Deux des quatre formulations de son commentaire de documentation, « Nearby pitch-class sets to C major » et « Closest chord to G7 in ICV space », sont déclinées elles aussi, et l’exemple que donne son propre refus, « ICV neighbors of Cmaj7 », favorise aussi skill.intervalclassvector. IntervalClassVectorSkill, revu en même temps, répond à 8 de ses 10 ancres. Sur main, le refus est seulement marqué Declined	IcvNeighborsSkill.cs lignes 51-89, lignes 254-260, DefaultRoutingHintProvider.cs lignes 124-139	l22, les formulations de GA : 10 ancres, 0 réponse, 10 refus, 0 favorisée vers skill.icvneighbors ; les ancres d’IntervalClassVectorSkill : 8 réponses ; l22 (main) : de même	Signalé dans #798
129. IcvNeighborsSkill construit l’accord sur lequel on l’interroge	Sur 27 accords courants placés après « ICV neighbors of », le skill en construit 10 correctement. Il met la qualité en minuscules avant de lire sa table : le "M7" de la ligne 221 ne correspond donc jamais, et CM7 est construit comme une septième mineure sur C. Une qualité qu’il ne connaît pas donne une triade majeure, sans avertissement : Cdom7, Cadd9, C7b9, C7#9, Cm11, C13 et C5 répondent comme C E G. ° et + ne sont pas des lettres : l’accord s’arrête donc avant eux. C° et C+ deviennent C, et C°7 la triade C° ; Cø7, C7sus4 et CmMaj7 sont déclinés. « C minor » et « A minor » sont lus comme des triades majeures, et l’expression ignore la casse : « a » est donc A majeur, et « What’s close to a half-diminished chord? », la formulation du brouillon en attente, reçoit les voisins de A	IcvNeighborsSkill.cs lignes 82-89, lignes 196-232	l22, les accords : 27, dont 10 bien construits ; CM7 construit en C D# G A# ; « a Cmaj7 » lu comme a, soit C# E A ; l22 (main) : de même	Signalé dans #798
130. IcvNeighborsSkill liste les ensembles les plus proches, « top 8 by harmonic cost »	Le skill garde les ensembles à L1 1 ou 2 et les trie par L1, mais un accord de trois notes ou plus n’en a aucun à 1 : chaque ligne est à L1 2, au coût de 1.20, et les huit lignes sont les huit premiers ensembles par masque de bits, dans l’ordre de FindNearby. Les lignes ne dépendent que du vecteur : les 192 accords formés de 12 fondamentales et de 16 qualités reçoivent 10 réponses différentes, et chaque triade majeure ou mineure reçoit les mêmes huit ensembles, dont cinq sont des intervalles de deux notes. Les lignes de Cdim et de Caug ne sont que des ensembles de deux notes. Cdim7 n’en reçoit aucun, avec « Try a wider radius », alors que le rayon est la constante DefaultMaxDistance. Les lignes sont des numéros de classes de hauteurs et des vecteurs, sans nom ni numéro de Forte, et contiennent plusieurs transpositions d’une même classe d’ensembles : les huit lignes de C contiennent cinq classes d’ensembles. Sur main, ga_icv_neighbors liste chaque classe d’ensembles une seule fois depuis 51ac3f68 ; le skill, non	IcvNeighborsSkill.cs lignes 76-77, lignes 130-175, GrothendieckService.cs lignes 45-90	l22, les voisins : chaque ligne à 2, 1.20, les premiers par id : oui ; 192 accords, 10 réponses différentes, 10 vecteurs différents ; Cdim7 : aucun ensemble à L1 = 2 ou moins ; l22 (main) : de même	Signalé dans #798
131. Le skill icv-neighbors en attente décrit l’outil qu’il appellerait	skills-dev/_pending-tools/icv-neighbors/DRAFT.md dit que ga_icv_neighbors n’est pas implémenté et renvoie à Common/GA.Business.ML/Agents/Mcp/AtonalMcpTools.cs, que GA n’a pas ; l’outil se trouve dans GaMcpServer/Tools/ChordAtonalTool.cs. Il attend chord, topK et metric, et une réponse faite de Neighbours ; l’outil prend symbol et maxDistance et renvoie du texte. Son exemple place Am7 à une distance de 0.0, avec le vecteur de Cmaj7, alors que Am7 est 4-26, à L1 4, et Cm9 sans sa fondamentale à 0.6, alors que c’est une septième majeure sur E♭, 4-20, à L1 0. Le skill du chatbot décline deux des trois formulations du brouillon et lit A majeur dans la troisième. Les lignes 117, 122 et 127 sont le même constat pour les trois autres brouillons	DRAFT.md ligne 18, lignes 31-58, ligne 72, ChordAtonalTool.cs lignes 220-254	l22, le brouillon : Am7 4-26, L1 4 ; Cm9 sans sa fondamentale 4-20, L1 0	Signalé dans #798
132. GrothendieckDeltaSkill et IcvShortestPathSkill répondent à leurs prompts d’exemple	Le skill du delta répond à 8 de ses 10 prompts d’exemple : « how harmonically far is Am from D7 », qui est aussi la première formulation de son commentaire de documentation, a « from » entre les accords, et « how different are C major and F major harmonically » un mot après le premier accord. Le skill du chemin répond à 7 de ses 10 : « shortest path from C major to F major », qui figure aussi dans son commentaire de documentation, « shortest chord path from Dm7 to Gmaj7 » et « harmonic stepping stones from Cmaj7 to Fmaj7 » sont déclinés. Le skill du delta répond à 9 des 10 prompts du skill du chemin : une question de chemin formulée comme eux et envoyée vers lui reçoit donc une distance, et non un refus ; « harmonic cost to move from C to G » favorise skill.transpose. Les deux construisent leurs accords avec une copie de la table de la leçon 22 : CM7 est une septième mineure sur C, « C to A minor », un prompt du skill du chemin, demande A majeur, et « a » est A majeur	GrothendieckDeltaSkill.cs lignes 46-67, lignes 153-173, IcvShortestPathSkill.cs lignes 55-93, DefaultRoutingHintProvider.cs lignes 257-259	l23, les formulations de GA : GrothendieckDeltaSkill : 10 ancres, 8 réponses ; IcvShortestPathSkill : 10 ancres, 7 réponses ; l’autre skill répond à 9 d’entre elles ; 36 chiffrages d’accords, 36 construits à l’identique ; l23 (main) : de même	Signalé dans #802
133. GrothendieckDeltaSkill donne la distance entre deux accords	GrothendieckDelta.FromIcVs change un delta nul en Ic1 = 1, et le skill l’affiche : C vers G, Am vers Em, Cmaj7 vers Fmaj7 et C vers C reçoivent [+1, 0, 0, 0, 0, 0], un L1 de 1, un coût de 0.60 et « more chromatic color », comme chacune des 4320 paires ordonnées des 192 accords qui partagent un vecteur. IcvNeighborsSkill recalcule le delta pour l’éviter ; l’heuristique est celle que signale le ticket de GA #776. L’interprétation est la première règle qui correspond : Cmaj7 vers G7 et G7 vers Cmaj7 reçoivent donc tous deux « more chromatic color », comme 1440 des 16272 paires de vecteurs différents. La flèche qui la précède s’affiche comme →, les octets de → lus comme du Windows-1252 et enregistrés en UTF-8, au commit épinglé et sur main	GrothendieckDelta.cs lignes 113-134, ligne 217, lignes 226-258, GrothendieckDeltaSkill.cs lignes 97-131	l23, les deltas : 4320 paires de même vecteur, 4320 avec un L1 de 1 dans la réponse ; 32544 de vecteurs différents, 32544 avec un L1 juste ; 1440 avec « more chromatic color » dans les deux sens ; l23 (main) : de même	Signalé dans #802
134. IcvShortestPathSkill trouve un chemin entre deux accords	La recherche ne passe qu’à des ensembles de même taille, si bien que des accords de tailles différentes ne sont jamais reliés : Am vers D7 et Gmaj7 vers Em, deux des prompts d’exemple du skill, et « How do I get from Am to D7 harmonically », tiré de son commentaire de documentation, reçoivent « No path found within 5 steps ». Avant de le dire, elle développe 168 des 220 ensembles de trois notes, ou 462 des 495 ensembles de quatre, chacun au prix d’un parcours des 4096 ensembles dont les vecteurs sont recalculés à chaque lecture, sauf si un cache de FindNearby de 256 entrées, qui écarte d’abord les plus anciennes, a gardé sa réponse. Cdim7 et Caug n’atteignent que leurs propres transpositions, 3 et 4 ensembles	GrothendieckService.cs lignes 117-163, ligne 21, PitchClassSet.cs ligne 104, IcvShortestPathSkill.cs ligne 137	l23, les chemins : Am → D7 et Gmaj7 → Em, aucun chemin ; ensembles développés : 168 des 220 de 3 notes, 462 des 495 de 4 notes ; l23 (main) : de même	Signalé dans #802
135. IcvShortestPathSkill décrit le chemin qu’il trouve	La réponse compte les ensembles comme des étapes : Cmaj7 vers G7 donne « 4 steps total (3 intermediate moves) » pour trois déplacements par deux ensembles, C vers G « 2 steps total (1 intermediate move) » pour un déplacement sans passer par aucun, C vers C « 1 step total ». Un déplacement entre deux ensembles d’un même vecteur, à un L1 de 0, compte comme une étape : C vers G, C vers F, C vers Cm et C vers A. La réponse donne les ensembles intermédiaires sous forme de nombres, sans nom, C D D# G et C C# E F# pour Cmaj7 vers G7, dont les déplacements gardent 2 notes, puis 1, puis aucune, là où la réponse promet des « common-tone bridges ». Le skill garde aussi deux commentaires de révision, le second écrit par-dessus le premier	IcvShortestPathSkill.cs lignes 55-66, lignes 127-162	l23, les chemins : Cmaj7 → G7, « 4 steps total (3 intermediate moves) », 3 déplacements, notes communes 2,1,0 ; C → C, « 1 step total » ; l23 (main) : de même	Signalé dans #802
136. SetTheoryEquivalenceSkill et GrothendieckParseSkill répondent à leurs prompts d’exemple	Le skill des ensembles répond à 4 de ses 5 prompts d’exemple : « Are pitch classes 0,2,4 and 1,3,5 transpositionally equivalent » a un mot entre le second ensemble et « equivalent ». Le skill d’analyse répond à 5 de ses 10 : « parse Cmaj7 + Gmaj7 + Fmaj7 », « explain power(Cmaj7) » et « parse Transpose(Cmaj7) », la forme que suggère son propre message d’échec, ne contiennent aucun des symboles que cherche son expression de surface, et « what is Hom(Cmaj7, Gmaj7) » n’a pas de mot d’ancrage ; l’analyseur rejette « Transpose(C ⊗ G) » et « equalizer Transpose Invert ». Aucune règle d’indice ne nomme le skill des ensembles, et deux de ses prompts favorisent skill.transpose	SetTheoryEquivalenceSkill.cs lignes 35-54, GrothendieckParseSkill.cs lignes 51-82, ligne 177, DefaultRoutingHintProvider.cs lignes 257-259	l24, les formulations de GA : SetTheoryEquivalenceSkill: anchors 5, answered 4 ; GrothendieckParseSkill: anchors 10, answered 5 ; l24 (main) : de même	Signalé dans #806
137. SetTheoryEquivalenceSkill lit la relation que nomme une question	Dans « equivalent under transposition » et « equivalent under inversion », la tournure de ses prompts d’exemple, \s* prend l’espace dont le groupe facultatif \s+under a besoin : le skill ne lit aucune relation et répond pour la classe d’ensembles. {0,1,3} et {0,2,3} « under transposition », son deuxième prompt d’exemple, reçoivent « Yes », alors que seule une inversion les relie. Cette tournure se trompe pour 2016 des 48400 paires ordonnées d’ensembles de trois notes et 4032 des 245025 d’ensembles de quatre notes. La relation n’est lue qu’après « set class », « set » ou « class », où chaque verdict est juste : aucun des prompts d’exemple ne reçoit donc le verdict de la transposition seule écrit après une revue du 2026-05-13. Une paire liée par transposition et posée « under inversion » est dite se ramener à la même forme première « via either operation », ce qui est faux pour 2016 des 2608 paires de trois notes et 4032 des 5841 de quatre dont c’est dit	SetTheoryEquivalenceSkill.cs ligne 48, lignes 69-80, lignes 97-107, lignes 137-148	l24, la relation : equivalent under transposition, 0,1,3 | 0,2,3: yes, TI, wrong ; toutes les paires : 3 notes wrong 2016, 4 notes wrong 4032 ; « via either operation » : 2016 sur 2608, 4032 sur 5841 ; l24 (main) : de même	Signalé dans #806
138. SetTheoryEquivalenceSkill lit les ensembles	Le premier ensemble doit être suivi de « and » : il commence donc après le dernier tiret. « 0-1-4 » est posé comme {4}, et le nom de Forte « 3-3 » comme {3}, et la réponse les compare sans avertissement. 10 et 11 écrits « t », « T », « A » ou « 0te » sont déclinés, comme les parenthèses et les chevrons. Les formes premières tiennent : 224, identiques pour les 24 transpositions et inversions de chaque ensemble, chacune égale à l’ensemble que la table du catalogue de Forte de GA donne pour son étiquette, avec 23 paires qui partagent un vecteur, et les réponses sur les ensembles en relation Z sont justes	SetTheoryEquivalenceSkill.cs lignes 47-54, lignes 218-241, PitchClassSetId.cs lignes 123-156	l24, les ensembles : 0-1-4, answered, 4 {0} ; 3-3, answered, 3 {0} ; formes premières 224, stables 4096, différentes de la table 0, absentes de la table 0, paires Z 23 ; paires en relation Z dites 1152 sur 1152 ; l24 (main) : de même	Signalé dans #806
139. L’analyseur Grothendieck de GA lit les formes que nomment ses commentaires	25 des 50 formes sont analysées, 21 dans le cas que promet leur commentaire. str lit les espaces qui suivent son mot, si bien que chaque forme qui exige ensuite ws1 échoue : « limit of », « lim », « colimit of », « colim », « define functor », « natural transformation », « define nat_trans », « define sheaf », « truth_value of », « subobjects of », « glue », et « transpose » suivi d’un nombre ; « restrict S to U » échoue plus tôt, puisque l’analyseur veut d’abord le nom du faisceau. Une première alternative qui lit un objet cache les formes à mot, comme « C tensor G ». « P(C) », « power(C) », « Ω(C) » et « eta(C) » sont des applications de foncteur. Aucune des 50 formes n’atteint 9 des 22 cas, dont trois sont atteints par une forme écrite autrement : « equalizer » demande deux parenthèses, et aucune espace ne peut suivre leur virgule ou leur « | » ; deux opérateurs à la suite échouent. Seuls les noms de qualité de sa liste, comme min et dom7, sont lus : Am, Cm, G7, C7, Dm7, CM7, C°, C+ et Cm7b5 échouent	GrothendieckOperationsParser.fs ligne 18, lignes 53-85, lignes 406-431, lignes 625-633	l24, les expressions : forms 50, parsed 25, as their comment says 21 ; cas qu’aucune forme n’atteint 9 ; sans espaces, eq(invert,reflect) Equalizer ; les accords : Am, G7, Dm7 échouent ; l24 (main) : de même	Signalé dans #806
140. GrothendieckParseSkill répond à une question	Son expression de surface laisse passer ⊗, ⊕, ×, ∘ et quelques mots, mais pas « + », « ^ » suivi d’une espace, Ω, « => » ni un appel comme « Invert(C) » : il répond donc pour 12 des 50 formes. Il ne retire qu’un mot d’ancrage initial suivi d’une espace et un « mean » ou un « do » final : « Parse: », « please parse », « can you parse » et un « please » final arrivent à l’analyseur et échouent, et « explain the tensor product » est analysé comme une expression. La réponse nomme le cas et donne une glose écrite pour ce cas : « parse C ⊗ G » et « parse F# ⊗ Bb » reçoivent la même réponse, à l’expression près	GrothendieckParseSkill.cs lignes 74-109, lignes 146-163, lignes 244-276	l24, les expressions : « parse » answered for 12 ; les questions : Parse: C ⊗ G, can’t parse ; explain the tensor product, can’t parse ; même réponse à l’expression près : yes ; l24 (main) : de même	Signalé dans #806
141. L’indice de transposition se déclenche sur les questions de transposition	Il se déclenche sur 16 des 26 formulations. Il manque 3 des 13 prompts d’exemple de TransposeSkill, « What’s Dm7 up a whole step? », « raise the key by two semitones » et « lower the key by a half step », le « Cmaj7 in the key of G » du SKILL.md, et « Shift the song to the key of E » : il lui faut un mot qui commence par « transpos », ou « shift », « bring » ou « move » suivi de « up », « down », ou de « to » et d’une majuscule. Deux prompts d’exemple qui nomment un intervalle favorisent autant skill.interval ; « Raise Bb7 by a minor third » et « Lower G by a tritone » ne favorisent que skill.interval, et « Play this song a whole step down » ne favorise que skill.alternatetunings	DefaultRoutingHintProvider.cs lignes 257-259, lignes 74-76, lignes 159-161, TransposeSkill.cs lignes 41-60	l25, les formulations de transposition : l’indice de transposition 16 sur 26, celui d’une autre intention 6, dont 3 sans l’indice de transposition, aucun indice 7 ; l25 (main) : de même	Signalé dans #809
142. L’indice de transposition et les déclencheurs du SKILL.md de transposition s’en tiennent aux transpositions	L’indice se déclenche sur 10 des 407 prompts d’exemple des autres intentions : « transposition » et « transpositionally » dans deux prompts de théorie des ensembles et dans « What are modes of limited transposition », le foncteur « Transpose » dans cinq prompts d’analyse, et « move from G7 to C » et « move from C to G ». Les déclencheurs, lus comme des sous-chaînes, sont dans 8 : « up a » dans « what notes make up a G7 chord » et « Brighten up a minor key tune », « in the key of » dans « All chords in the key of D », et « transpose » dans les cinq prompts d’analyse	DefaultRoutingHintProvider.cs lignes 257-259, skills/transpose/SKILL.md lignes 4-11, SkillMdDrivenSkill.cs lignes 54-65	l25, les autres intentions : 407 prompts d’exemple de 34 intentions, l’indice de transposition 10, un déclencheur 8 ; l25 (main) : 412 de 35, les mêmes 13 lignes	Signalé dans #809
143. Le skill dont les déclencheurs lisent les transpositions peut être choisi par le routeur	Deux skills s’appellent Transpose : TransposeSkill, derrière skill.transpose, dont le CanHandle n’accepte aucune des 26 formulations, et le SkillMdDrivenSkill construit à partir de son SKILL.md, dont les déclencheurs en acceptent 18 mais qui n’est derrière aucune intention, comme les 18 skills que construit SkillMdPlugin	SkillMdDrivenWrapperBase.cs ligne 85, SkillMdPlugin.cs lignes 83-92	l25, les skills : TransposeSkill 0 sur 26, SkillMdDrivenSkill 18 sur 26, construits à partir d’un SKILL.md 18, derrière une intention 0 ; l25 (main) : de même	Signalé dans #809
144. Sans embeddings, une transposition reçoit une transposition ou un message disant qu’on ne peut pas y répondre	Au commit épinglé, le routeur d’intentions ne route aucune des 26 formulations et le point de chat répond HTTP 500 à toutes. Sur main, le repli par mots-clés du routeur d’intentions ne peut pas choisir skill.transpose, dont le CanHandle dit non : il en envoie 2 à ChordInfoSkill, qui donne les notes de l’accord avant la transposition, et « Lower G by a tritone » à ChordSubstitutionSkill, toutes trois étiquetées orchestrator-skill-semantic. Les mots-clés du routeur d’agents en envoient 16 à l’agent des voicings, qui n’a pas de liste de mots-clés et reçoit 0,1 : « Shift Am7 up a fifth » reçoit des voicings d’Am7. 7 reçoivent « Our reasoning service is currently unavailable »	SemanticIntentRouter.cs lignes 115-127, SemanticRouter.cs lignes 70-73 ; sur main, SemanticIntentRouter.cs lignes 313-335, OrchestratorSkillIntent.cs ligne 29, ligne 54, SemanticRouter.cs lignes 341-365	l25, sans embeddings : le routeur ne choisit rien 26 fois, HTTP 500 26 ; l25 (main) : le routeur ne choisit rien 23 fois, skill.chordinfo 2, skill.chordsubstitution 1 ; le point de chat répond par voicing (keyword) 16, fallback-direct 7	Signalé dans #809
145. Chaque mode du catalogue de ModesSkill est le premier mode de sa famille joué depuis le degré du mode	Le mode 1 est la gamme d’un manuel dans les 26 familles. Sur les 129 modes, 93 sont le mode 1 depuis leur degré, 2 depuis un autre degré, le « Blues Minor » et le « Minor Pentatonic » de la pentatonique majeure, et 34 depuis aucun degré : l’Ultralocrien a les notes de la gamme altérée, trois septièmes modes commencent par C Dbb, et les modes 4 à 7 de la napolitaine majeure, 8 modes bebop, 3 de Prométhée, 5 de l’énigmatique, 6 de la hongroise majeure et 4 de l’In Sen sont d’autres gammes	Modes.yaml lignes 242-243, lignes 659-674	l26, les familles : modes 129, depuis leur propre degré 93, depuis un autre degré 2, depuis aucun degré 34, notes dans le désordre 3	Signalé dans #813
146. ModesSkill n’écarte que les familles d’accords et de triades de Modes.yaml	Il écarte aussi « All Interval Tetrachord Family », dont le nom contient « chord Family » quand on ignore la casse ; son commentaire compte quatre familles	ModesSkill.cs lignes 515-516, lignes 530-532	l26 : familles 26, écartées 5	Signalé dans #813
147. Les formules de ModesSkill donnent à chaque note son degré	Ce sont celles d’un manuel pour 65 des 129 modes : 60 des 63 modes de sept notes, les trois autres ayant leurs notes dans le désordre, 3 des 14 modes de six notes et 2 des 10 de deux notes, et aucun des 15 modes de cinq notes, des 26 de huit notes ni de l’unique mode de douze notes. Une gamme de deux notes peut recevoir la mauvaise note : 1 2 pour C F. Lire chaque chiffre sur la lettre donnerait les degrés de 52 des 63 modes de sept notes	ModesSkill.cs lignes 779-811	l26, les formules : celles du skill 65 sur 129 ; celles des lettres 52 des 63 modes de sept notes	Signalé dans #765, avec les comptes de la leçon 26 dans un commentaire
148. What is <mode name>? reçoit ce mode	119 des 129 noms de modes reçoivent leur mode, et les 68 noms alternatifs aussi. Huit noms ne sont pas entre guillemets et perdent tout à partir de « # », « Lydian #6 » devenant « Lydian », puis reprennent un nom qui vient avant eux dans le catalogue ; « Minor Pentatonic » et « Whole-Half Diminished » figurent deux fois dans le catalogue. CanHandle accepte tous les noms de modes, mais 7 des 68 noms alternatifs	Modes.yaml lignes 631-681, ModesSkill.cs lignes 244-255, lignes 137-144	l26, les noms : écrits 165, lus autrement 8 ; noms de modes avec leur mode 119 sur 129, noms alternatifs 68 sur 68 ; CanHandle 129 et 7	Signalé dans #813
149. Les prompts d’exemple de ModesSkill reçoivent la réponse qu’ils demandent	« List unnamed modal families » reçoit les modes de la gamme majeure, la réponse par défaut, parce que la branche atonale cherche « unnamed famil » ; « What modes have a major 7th » les reçoit aussi, et « Mixolydian versus Ionian differences » reçoit le seul mixolydien. CanHandle en accepte 11 sur 37	ModesSkill.cs ligne 606, lignes 202-207	l26, les prompts d’exemple : 37, CanHandle 11	Signalé dans #813
150. OutsideNotesSkill classe une note comme le fait un manuel	Sur cinq accords de septième, 42 des 60 notes reçoivent le verdict du manuel, et 12 autres le même conseil. La #9 et la b7 sur Cmaj7, la #11 sur Cm7 et la 13 sur Cm7b5, qu’aucune gamme d’accord usuelle ne contient, sont « an available tension », « Safe to sustain as an extension ». La b9 et la b13 de C7 sont des notes à éviter : le titre de la b9 le dit, et son explication le contraire	OutsideNotesSkill.cs, lignes 141-189	l27, la règle : cases 60, identiques 42, notes à éviter qu’aucune gamme usuelle ne contient 12, tensions qu’aucune gamme usuelle ne contient 4, notes à éviter dont le manuel fait des tensions 2	Signalé dans #814
151. La 11 sur un accord étendu reçoit le verdict qu’elle reçoit sur l’accord de septième	F sur C11, C13, Cmaj11 et Cmaj13 est « a chord tone — the perfect eleventh », alors que sur C7, C9, Cmaj7 et Cmaj9 c’est une note à éviter, un demi-ton au-dessus de E, que les accords plus grands contiennent toujours : ChordVocabulary empile les tierces jusqu’à la 11	ChordVocabulary.cs, lignes 134-138	l27, F sur C et ses accords étendus	Signalé dans #814
152. OutsideNotesSkill lit la note et l’accord que nomme une question	Les 14 notes écrites avec # ou b sont bien lues, les 14 écrites avec ♯ ou ♭ sont lues comme des notes naturelles, et les 7 notes en minuscule reçoivent le refus. 27 des 40 accords que connaît ChordVocabulary sont bien lus : la suite de l’accord s’arrête à « - », « o », « ( », ♭, ♯ et à la deuxième lettre de ma7 et mi7, si bien que Cma7 devient Cm ; °, Δ et Δ7 (comme dans #783) deviennent C E G, comme 7sus4, mMaj7, 7#11 et maj7#11, absents du vocabulaire. « over a minor chord » devient A majeur, « over a dominant chord » D majeur	OutsideNotesSkill.cs, lignes 289-299, ChordVocabulary.cs, lignes 81-84, ligne 140	l27, les notes : naturelles, # et b 7 sur 7 chacune, ♯, ♭ et minuscules 0 ; les accords : 27 sur 40, et 0 des 5 absents du vocabulaire	Signalé dans #814
153. Les preuves du skill écrivent les notes de l’accord	Il les nomme à partir de deux tableaux de douze noms : justes sur 12 fondamentales pour 11 accords majeurs, 8 mineurs, 9 de septième de dominante, 11 de septième majeure, 8 de septième mineure, 6 demi-diminués, 3 de septième diminuée et 6 augmentés. C7 s’écrit C E G A#, F# majeur Gb Bb Db, Cdim7 C Eb Gb A	OutsideNotesSkill.cs, lignes 226-241	l27, les notes de l’accord	Signalé dans #814
154. Les prompts d’exemple d’OutsideNotesSkill reçoivent une réponse	« why does that note clash over the chord », « why does the note clash over this chord » et « why does the b9 sound so tense over C7 » reçoivent le refus. CanHandle en accepte 8 sur 10, pas « what is F over G7 », auquel le skill répond	OutsideNotesSkill.cs, lignes 31-34, lignes 48-86	l27, les prompts d’exemple : 10, CanHandle 8, refusés 3	Signalé dans #814

2026-09-14 — Pourquoi ce cours

La demande, le 2026-09-14 : un cours sur l’index OPTIC-K, sur tout le code d’apprentissage automatique et d’agents de GA, et sur ce que le chatbot cherche à accomplir. Le cours se range sous Apprentissage automatique, à côté d’IX : il porte sur la construction et l’usage d’embeddings, d’un index vectoriel et d’un routeur de type classifieur à l’intérieur d’un produit, pas sur l’usage d’agents de programmation, qui relève du Développement assisté par IA.

2026-09-14 — Épingler GA et compiler contre l’hôte du chatbot

• GA est épinglé sur a826864, le commit qu’utilise le cours de théorie musicale. Le clone local de l’auteur n’est jamais utilisé : fetch-ga.sh fait un clone sans blobs et clairsemé dans code/ga-ai/.ga, ignoré par Git, avec 17 dossiers de projets, et sans les PDF de recherche de GA.
• Sous Windows, le premier checkout a échoué sur des chemins de plus de 260 caractères ; git config core.longpaths true avant le checkout règle le problème. Comme dans le cours de théorie musicale, MSYS_NO_PATHCONV=1 empêche Git Bash de réécrire les motifs du clone clairsemé.
• Le projet du cours référence directement GaChatbot.Api et le démarre avec WebApplicationFactory<Program>. Deux détails ont été nécessaires : un attribut d’assembly, WebApplicationFactoryContentRootAttribute, qui pointe vers le dossier de l’hôte dans le clone (GaAi.csproj) ; et pas d’instructions de niveau supérieur dans le programme du cours, dont la classe Program générée entrerait en conflit avec celle de l’hôte.
• La machine de l’auteur fait tourner Ollama. Sans intervention, l’hôte l’aurait utilisé, et les sorties auraient différé de celles de la CI. Le cours règle l’adresse d’Ollama sur http://127.0.0.1:9, fermé sur la machine de l’auteur comme sur les runners.
• La mémoire du chat de GA est par défaut rangée dans des fichiers sous ~/.ga. Le cours enregistre ses propres MemoryStore et ChatTranscriptStore sur un dossier neuf à côté du programme ; on a vérifié que ~/.ga était inchangé après une exécution.
• Le premier corpus, 5 cases et une fenêtre de 4, avait 77 140 voicings, et le calcul des embeddings prenait 33 secondes. 3 cases et une fenêtre de 3 donnent 15 360 voicings en environ 8 secondes, assez pour chaque point de la leçon 3.
• Les messages d’exception diffèrent d’un système à l’autre (erreurs de socket). La leçon 4 n’affiche que le type d’exception et la frame de GA la plus profonde, file:line, dédupliqués et triés.
• Compilation locale des projets de GA et du cours : environ 23 secondes après la première restauration ; une vérification complète des quatre leçons, 40 secondes.

2026-09-14 — La CI

• Exécution 34917150100, pour le commit 43f009d : les leçons 1 à 3 ont réussi partout, la leçon 4 a réussi sous Windows et échoué sous Linux et macOS. Sur ces deux systèmes, les avertissements du routeur sémantique d’intentions apparaissaient aussi sous la première requête.
• Cause : IntentEmbeddingWarmupService lance en arrière-plan le calcul des embeddings des intentions au démarrage de l’hôte, et ses avertissements atterrissent dans la requête en cours à ce moment-là. Correction dans le commit 8e335d7 : le cours attend la dernière ligne de journal du préchauffage avant d’envoyer des requêtes. La leçon 4 raconte l’histoire.
• Exécution 34917602262, pour 8e335d7 : vert sur les trois systèmes, 1 min 34 s sous Linux, 1 min 50 s sous macOS, 3 min 2 s sous Windows, clone et compilation compris.

2026-09-14 — Différences trouvées dans le code de GA (commit a826864)

Chaque point dit où le programme du cours le montre. Aucun n’a été signalé en amont.

Embeddings (leçon 2) :

1. VoicingDocumentFactory fixe RootPitchClass et MidiBassNote à partir de MidiNotes[0] (lignes 37-38). GA construit les voicings en commençant par la corde 1 (mi aigu) : cette note est donc la note la plus aiguë. ROOT, MODAL, la basse de MORPHOLOGY et le renversement sont calculés à partir d’elle ; le filtre de recherche utilise MidiNotes.Min(), la vraie basse. Montré par l2, « From a chord shape to GA’s voicing document » (C ouvert : fondamentale E, renversement 1), et par la recherche de Cmaj7 de l3.
2. Le renversement compare cette note au nom de la fondamentale de l’accord, lu par PitchClass.Parse (lignes 43-44), qui lit les noms de notes comme des chiffres : "A" vaut 10 et "E" vaut 11. Un Em à l’état fondamental, 022000, reçoit Inversion = -1. Reproduit avec un programme séparé qui référence GA.Business.ML, hors de la CI du cours : PitchClass.Parse("E") = 11, et 022000 Em ChordId.RootPitchClass="E" doc.RootPitchClass=4 inversion=-1. Le cours de théorie musicale a trouvé le même comportement du parseur.
3. VoicingHarmonicAnalyzer passe intervalSpread > 12 dans IsRootless et false dans IsOpenVoicing du record positionnel VoicingCharacteristics (lignes 31-43). Tout voicing qui couvre plus d’une octave est « sans fondamentale ». Montré par l2, « VoicingCharacteristics and PerceptualQualities ».
4. VoicingAnalyzer construit new PerceptualQualities(curVoiceChars.Consonance, 0, 0, "Neutral", "Medium") pour un record déclaré (Brightness, ConsonanceScore, Roughness, ...) (ligne 164). ConsonanceScore vaut toujours 0, la Consonance du document aussi, et la tension de CONTEXT, 1.0 - doc.Consonance, vaut toujours 1. C’est la dimension constante du ticket #616, dont l’analyse n’accuse que les littéraux voisins. Même section de l2, et la ligne CONTEXT de « Dimensions that never vary » dans l3.
5. EmbeddingSchema.AtonalModalDim vaut 17 alors que le registre donne 64 emplacements à ATONAL_MODAL ; ModalVectorService en alloue 17 (ligne 116) et WriteInto ne vérifie pas les longueurs : 47 emplacements sont toujours nuls (l3). HierarchyDim vaut 8 contre 15 (l2, « Loose constants »). Les deux partitions ont un poids de 0 : la recherche n’est pas affectée.
6. STRUCTURE n’est pas invariante par transposition (221 classes d’ensembles sur 222, l2), comme le disent le propre balayage de GA et le commentaire de TheoryVectorService ; le résumé de RootVectorService affirme encore « genuinely O+P+T+I-invariant » (lignes 3-7).
7. Les poids de similarité font 1.15 au total ; un vecteur obtient 1.15 contre lui-même (l2). Ce n’est pas un bug, mais « cosinus » est trompeur dans les journaux et les seuils.
8. Versions dans les commentaires et les documents : le document de schéma le plus récent est v1.4.1, OPTIC-K_Embedding_Schema.md décrit v1.3.1 (109 dimensions), MusicalEmbeddingGenerator dit 228 (ligne 13) et 216 (ligne 55), le commentaire de CompactDimension dit 112, OptickIndexWriter et MusicalQueryEncoder disent 112, le commentaire de ExtensionsEnd dit qu’elle vaut TotalDimension. Le code calcule 240 et 124.

Index et recherche (leçon 3) :

9. Neuf des 33 emplacements nommés de MODAL ne sont jamais remplis sur le corpus de 15 360 voicings : LocrianNatural6, DorianSharp4, LydianSharp2, AlteredDoubleFlat7, DorianFlat2, LydianAugmented, MixolydianFlat6, LocrianNatural2, Diminished. ModalVectorService cherche les modes par des noms d’affichage comme "Locrian ♮6" et repart en silence quand il ne trouve rien ; un nom qui ne correspond pas est la cause probable (à vérifier).
10. 37 des 124 dimensions de recherche sont toujours nulles et 4 constantes sur ce corpus (l3) ; #616 rapporte 40 dimensions mortes sur l’index en production.
11. ApplyFilters compare la qualité comme une sous-chaîne du nom stocké : le filtre Am7 accepte Gbm7(shell)/A, et la qualité vide de C accepte tout nom avec C à la basse, y compris C + E (Major 3rd) et Am/C (lignes 296-329).
12. OptickSearchStrategy.FindSimilarVoicingsAsync renvoie toujours une liste vide (connu, commenté aux lignes 75-92). MusicalQueryEncoder laisse le vecteur d’intervalles hors des requêtes (connu, commenté).

Diagrammes et outils MCP :

13. Deux ordres pour la même chaîne de diagramme : VoicingGenerator, l’index et l’analyseur de l’outil MCP lisent la corde 1 (mi aigu) en premier ; PlayableNotationFormatter lit le mi grave en premier (lignes 31-53). La tablature du chatbot pour 3-0-x-2-3-x (Cmaj7) est 6/3 5/0 3/2 2/3, les notes G A A D (l4).
14. La description de ga_generate_voicing_embedding dit « 228-dim » et donne 'x-3-2-0-1-0' for Cmaj7 (lignes 42-44) ; l’analyseur de l’outil le lit comme Dsus2/E (l2), et lu mi grave en premier, ce serait C, pas Cmaj7.
15. ga_get_embedding_schema liste dix partitions, sans ROOT, avec les constantes isolées HierarchyDim et AtonalModalDim (lignes 69-91). Lu dans le code, pas exécuté par le cours.

Chatbot (leçons 1 et 4) :

16. Sans serveur d’embeddings, chaque message qu’aucune garde n’attrape finit en HTTP 500. SemanticRouter.RouteAsync n’intercepte pas l’exception de EnsureEmbeddingsInitializedAsync (lignes 68-104) : son repli par mots-clés est donc inatteignable ; le repli de l’hôte sur un appel direct au modèle lève aussi une exception. « What is the relative minor of C major? » échoue alors que skill.relativekey y répond avec une confiance de 1.00 (l4).
17. L’ancien chemin CanHandle envoie cette même question à ScaleInfo, pas au skill des tonalités relatives (l4).
18. skill.fretspan n’a aucun prompt d’exemple, et SemanticIntentRouter ignore les intentions sans exemples : on ne peut jamais y être routé (l1).
19. ProductionOrchestrator.AnswerStreamingAsync (à partir de la ligne 154) a la garde voicing, mais pas le chemin rapide d’algèbre de AnswerAsync. Lu dans le code, pas exécuté.
20. IntentEmbeddingWarmupService lance son travail sans l’attendre ; c’est bien pour un serveur, mais les journaux d’un hôte dépendent alors du timing (l’échec de CI ci-dessus).

Documents :

21. docs/architecture/chat-surfaces.md dit, dans son statut du 2026-05-13, que GaChatbot.Api est canonique et sert la démo publique (lignes 16-21), alors que des sections plus loin disent que la page déployée appelle SignalR sur GaApi, et traitent les deux comme parallèles à la version canonique (lignes 215-223 et 262).
22. Le CLAUDE.md de GA dit qu’ix produit optick.index ; dans le code de GA et dans son skill optic-k-rebuild, c’est FretboardVoicingsCLI qui l’écrit. CLAUDE.md nomme GA.Business.Core.Harmony et GA.Business.Core.Fretboard comme couche 3 ; le générateur et l’analyseur de voicings vivent dans GA.Domain.Services.

Pistes non vérifiées par le cours, notées plus tôt en lisant les documents de GA (à vérifier) : GaChatbotCli n’arrive peut-être pas à résoudre ses services ; le backlog et la feuille de route divergent sur certains statuts ; les documents de GA donnent plusieurs tailles pour l’index en production (161, 168, 175, 176 et 660 Mo).

2026-09-24 — Correctifs en amont

La plupart des 22 différences du 2026-09-14 ont été corrigées en amont par #689, fusionnée le 2026-09-23, qui porte aussi les commits fusionnés à nouveau par #686 et #688 le 2026-09-24. Les correctifs de code viennent avec des tests dans GA. Ce cours ne les a pas relancés : il reste épinglé à a826864 (à vérifier).

• Corrigées : 1 et 4 (documents de voicing construits à partir de la fondamentale de l’accord, de la note la plus grave et des champs nommés de l’analyseur), 2 (fondamentales lues comme des noms de notes), 3 (arguments nommés), 5 (constantes HIERARCHY et ATONAL_MODAL alignées sur les partitions), 6 (le résumé de RootVectorService), 8 (les commentaires 112/216/228 et v1.3.1), 9 (cases MODAL cherchées sous les noms du catalogue des modes), 11 (le filtre d’accord compare fondamentale, qualité et basse éventuelle), la moitié « requête » de 12 (le vecteur d’intervalles de la requête est encodé), 13 (l’ordre des cordes des diagrammes est explicite), 14 et 15 (l’outil de schéma lit EmbeddingSchema), 16 (repli sur les mots-clés, et une réponse « indisponible » au lieu d’un HTTP 500), 17, 18, 19, 21 et 22.
• Inchangées : 7, qui n’est pas un bogue ; l’autre moitié de 12, FindSimilarVoicingsAsync, rend toujours une liste vide, comme le dit son commentaire ; 20, listée par #688 comme trouvée et non modifiée. 10 n’a pas été remesurée, et les correctifs 5 et 9 touchent des dimensions qu’elle comptait.

2026-09-28 — Leçon 5 : le skill d’improvisation

• La demande, le 2026-09-28 : d’autres leçons qui aident le chatbot de GA. Le même jour, un tracer lancé contre le chatbot public avait trouvé que « which arpeggio fits Am F C G » reçoit F ionien et G ionien, ce qui a donné le ticket de GA #744. La leçon 5 reproduit ce constat hors ligne, dans la CI du cours, et l’étend aux accords isolés.
• ImprovisationSkill.cs est identique à a826864 et sur le main de GA au commit 8cd5042 (git diff --stat entre les deux est vide) : le skill épinglé est donc toujours celui qu’exécute le chatbot. Que le routeur déployé envoie chaque prompt de la leçon à ce skill, le cours ne le vérifie pas (à vérifier) ; le tracer l’a vu le faire pour Am F C G.
• Le chemin des progressions n’appelle jamais l’IMusicalQueryExtractor du skill, la seule dépendance qui a besoin d’un modèle. Le cours passe un extracteur qui lève une exception : une modification de GA qui ferait appeler un modèle par ce chemin ferait échouer l’exécution.
• Les tables de l’oracle doivent couvrir chaque nom de gamme que le skill peut renvoyer ; un nom manquant lève une exception. Une progression a été exécutée une fois sans être gardée dans le programme : Bb Gm Cm F, pour la solution du premier exercice.
• Exécution de CI 36425151971, pour le commit c2ab348 : verte sur les trois systèmes, 1 min 42 s sous Linux, 2 min 4 s sous macOS, 2 min 59 s sous Windows, clone et compilation compris.

2026-09-28 — Leçon 6 : la réponse sur le fil

• Le tracer du 2026-09-28 a vu la page publique afficher la liste de la réponse d’improvisation comme une seule puce. #743 en a corrigé la cause, SseChunker, le jour même, et #746 a consigné un second défaut, dans l’émetteur de GaApi. La leçon 6 vérifie tout le fil hors ligne, dans la CI du cours : le flux du vrai hôte, lu par un lecteur écrit d’après le standard HTML, puis deux émetteurs et trois lecteurs sur le découpage épinglé et sur le découpage corrigé.
• Le programme contient des copies des deux émetteurs et des portages de deux lecteurs JavaScript, le consumeSseStream de la page et le parseSseBuffer de ga-client. La copie de l’émetteur de GaChatbot.Api est comparée aux octets de l’hôte à chaque exécution ; l’émetteur de GaApi et les deux lecteurs ne tournent pas dans leur propre environnement d’exécution : un portage qui s’écarterait de sa source passerait donc inaperçu.
• GA construit ses réponses avec StringBuilder.AppendLine : sous Windows, /chat renvoie donc des sauts de ligne CRLF. La première exécution de l6 affichait « no » là où les événements de texte et /chat ne différaient que par des CR, avec des décomptes qui changeaient d’un système à l’autre. Le programme compare maintenant avec des sauts de ligne LF. Le flux de l’hôte est le même sur tous les systèmes : son émetteur retire les CR.
• La trace de l’événement de routage contient des durées qui changent à chaque exécution ; le programme affiche l’événement coupé à une virgule.
• ChatStreamAsync attend la réponse entière avant le premier événement : le flux s’affiche phrase par phrase, mais la première phrase ne part que lorsque la dernière est connue.
• L’émetteur de GaApi (#746) est latent à a826864 : git grep ne trouve aucun appelant de sendChatMessageStream ni de streamChat dans Apps/ga-client/src, et le chat React parle AG-UI, dont les événements JSON échappent les sauts de ligne.
• Exécution de CI 36509333842, pour le commit ed723b9 : verte sur les trois systèmes, 1 min 47 s sous Linux, 1 min 13 s sous macOS, 3 min 6 s sous Windows, clone et compilation compris.

2026-09-28 — Leçon 7 : les noms d’accords que le chatbot ne sait pas lire

• La demande : la leçon suivante, sur #745. Au moment où elle a été préparée, la pull request #749 avait été fusionnée (le 2026-09-28, à 23 h 32 UTC) et avait fermé #745. Déplacer l’épinglage du cours changerait la sortie de chaque leçon : la leçon 7 compile donc plutôt les trois fichiers de GA.Business.ML de #749 à côté de l’assembly épinglé, dans le projet GaFix749, et atteint leur ImprovisationSkill par l’alias extern fix749. fetch-ga.sh extrait les fichiers du clone sans blobs avec git show, et récupère le commit quand un clone plus ancien ne l’a pas.
• #749 a modifié deux fichiers de GA.Business.ML, InvalidChordNames.cs, nouveau, et ImprovisationSkill.cs ; le troisième fichier que compile la leçon, ChordIntentMatching.cs, est identique aux deux commits. Les autres changements de #749 sont dans ProductionOrchestrator.cs et dans des tests : le skill et la garde tournent donc comme sur main ; l’appel de l’orchestrateur à la garde est lu, pas exécuté.
• Le premier corpus n’avait qu’un cas Unicode, B♭ E♭ F. Lors de la vérification d’un exercice, normaliser ♭ et ♯ laissait encore F# lu comme F : la fondamentale diésée en simple ASCII est mal lue elle aussi, à cause du \b final de l’expression du skill. Le corpus a gagné les lignes 10 à 12, avec C+ et Bø7, les autres chiffrages qui se terminent là où \b ne peut pas suivre.
• Les solutions des exercices 1 et 2 ont été vérifiées en modifiant le programme du cours et le fichier de #749 le temps d’une exécution ; fetch-ga.sh restaure le fichier une fois .ga-fix/SHA supprimé.
• Exécution de CI 36518749257, pour le commit 226fbb0 : verte sur les trois systèmes, 1 min 28 s sous Linux, 1 min 36 s sous macOS, 3 min 20 s sous Windows, clone, récupération des fichiers de #749 et compilation compris.

2026-09-29 — Signalé en amont

• Quatre tickets de GA, ouverts à partir des lignes des leçons 5 à 7, chacun avec l’exécution du cours pour preuve :
  • #757 : le skill lit des symboles d’accords comme d’autres accords, ou les abandonne sans un mot (lignes 23 et 35 à 38) ;
  • #758 : des qualités mal classées, et des arpèges qui ajoutent une note (lignes 24 à 27) ;
  • #759 : les demandes que la garde de #749 laisse passer (lignes 33 à 35) ;
  • #760 : la page de GaChatbot.Api affiche l’événement d’erreur du flux comme la réponse, et le garde dans l’historique (ligne 29).
• Le code qu’ils citent est inchangé sur main à fc76ad6 (2026-09-29), sauf les séparateurs d’interjections de la garde de #749 (2d9c5e3), qui ne changent pas ses lignes.

2026-09-29 — Leçon 8 : l’examen maison du chatbot

• La demande : d’autres leçons qui aident le chatbot de GA. Le propre oracle de GA, le corpus de prompts, n’avait pas encore été exécuté par le cours. Il est hors du clone clairsemé : fetch-ga.sh le copie donc avec git show dans .ga-files/.
• L’hôte du cours tournait sans le dossier skills/ de GA depuis la leçon 4. SkillMdPlugin le cherche à la racine du dépôt git qui contient le programme en cours d’exécution, ici le dépôt du cours. fetch-ga.sh l’extrait maintenant, et l’hôte définit SKILLMD_SKILLS_PATH ; les sorties des leçons 1 à 7 sont les mêmes. Avant ce changement, le texte de l’enveloppe faisait signaler les sept prompts d’accords diatoniques comme backend dégradé ; depuis, ils échouent comme des réponses ordinaires : c’est la ligne 42.
• Une clé présente dans l’environnement aurait atteint Anthropic : lancé avec une fausse ANTHROPIC_API_KEY, l’hôte a reçu AnthropicUnauthorizedException. L’hôte fixe maintenant Anthropic:ApiKey à une chaîne vide, et la sortie avec la fausse clé est la même que sans elle.
• Les solutions des exercices 1 et 2 ont été vérifiées en modifiant le programme du cours le temps d’une exécution ; celles des exercices 3 et 4 ont été résolues à la main.
• Exécution de CI 36584340462, pour le commit a305edf : verte sur les trois systèmes, 1 min 58 s sous Linux, 2 min 24 s sous macOS, 6 min 41 s sous Windows, clone, extraction de skills/, récupération du corpus et compilation compris.
• Signalé en amont le même jour : #763 pour les lignes 39, 41 et 44, #764 pour les lignes 42 et 43, #765 pour les lignes 40 et 45.

2026-09-29 — Leçon 9 : tous les intervalles, toutes les tonalités

• La demande : d’autres leçons qui aident le chatbot de GA. Après le corpus de prompts, les trois skills qui répondent sans modèle à des questions qui n’ont qu’une bonne réponse : les intervalles, les gammes et les tonalités relatives. L’oracle du cours est le calcul par lettres d’un manuel, dans Lesson9.cs.
• Les intervalles du domaine ont été vérifiés une fois contre le main de GA à 53b7253, hors du cours : GA.Core, GA.Domain.Core, GA.Business.Config et IntervalNaming.cs, pris avec git archive dans un dossier de travail, puis exécutés sur les 441 paires avec des notes correctement lues. Les 21 unissons et les 5 autres intervalles faux donnent le même résultat, de même que l’intervalle de C à B#, une septième augmentée qu’il donne comme majeure.
• La solution de l’exercice 1 a été vérifiée avec le moteur d’expressions régulières de .NET, et celle de l’exercice 4 en posant ses deux questions le temps d’une exécution ; celles des exercices 2 et 3 ont été résolues à la main.
• Exécution de CI 36666224042, pour le commit 73fd84d : verte sur les trois systèmes, 1 min 52 s sous Linux, 1 min 48 s sous macOS, 6 min 38 s sous Windows, clone et compilation compris.
• Signalé en amont le lendemain : #767 pour les lignes 46, 47, 49 et 53, #768 pour la ligne 48, #769 pour les lignes 50 à 52.

2026-09-30 — Leçon 10 : ce à quoi le modèle doit se fier

• La demande : d’autres leçons qui aident le chatbot de GA. Après les skills qui orthographient sans modèle, les trois qui confient la question à un modèle et lui demandent d’appeler une closure par ga_dsl_eval : la transposition, les accords diatoniques et les notes communes. Le cours appelle lui-même l’outil, DslEvalMcpTools.EvalClosure, avec les arguments de chaque SKILL.md ; le modèle n’est pas exécuté.
• DomainClosures.fs a changé sur le main de GA à 53b7253 : le code qu’appelle la leçon a donc été comparé fonction par fonction entre a826864 et main, et les deux tableaux de noms, preferFlat, transposeChord, diatonicChords, conventionalKeyName et la ligne où commonTones nomme une note sont identiques. ChordParser.fs y a changé pour des formes que la leçon n’envoie pas.
• Les fonctions utilitaires du manuel, dans Lesson9.cs, sont passées en internal pour que la leçon 10 les réutilise ; la sortie de l9 est inchangée.
• Les solutions des exercices ont été résolues à la main à partir du code.
• Exécution de CI 36668901083, pour le commit 6f91f88 : verte sur les trois systèmes, 2 min 01 s sous Linux, 2 min 19 s sous macOS, 6 min 29 s sous Windows, clone et compilation compris.
• Signalé en amont le même jour : #770 pour les lignes 54 à 57.

2026-09-30 — Leçon 11 : les accords que lit le skill des tonalités

• La demande : d’autres leçons qui aident le chatbot de GA. Après les skills qui appellent une closure, celui dont la réponse est calculée avant que le modèle voie la question : l’identification de la tonalité. Les deux points d’entrée du chatbot, KeyIdentificationSkill et le SKILL.md par ga_key_identify, exécutent KeyIdentificationService ; le cours appelle directement ses étapes, et le modèle n’est pas exécuté.
• La détection de la tonalité a changé sur le main de GA depuis le commit épinglé (#625, #729), après que le cours de théorie musicale a testé les outils du serveur MCP de GA, qui ne prennent que les accords. La leçon compile le service de main à 6baf32e contre le domaine épinglé (projet GaKeysMain, alias extern keysmain) et pose la question du chatbot, une phrase. Sur main à 5c3a52a, le service n’a pas changé depuis 6baf32e.
• Les réponses épinglées sont vérifiées contre ga_key_identify lui-même, sur les 99 questions. Le parseur du service et le BuildPrompt du skill sont privés ; le programme les appelle par réflexion.
• La solution de l’exercice 1 a été vérifiée avec le moteur d’expressions régulières de .NET sur les 90 questions de la leçon ; les autres ont été résolues à la main à partir du code.
• Exécution de CI 36758614173, pour le commit 8c2221d : verte sur les trois systèmes, 1 min 54 s sous Linux, 2 min 24 s sous macOS, 6 min 41 s sous Windows, clone et compilation compris.
• Signalé en amont le même jour : #771 pour les lignes 58, 59 et 61, #772 pour les lignes 60, 62, 63 et 64.

2026-09-30 — Leçon 12 : ce que répondent les skills de progression

• La demande : d’autres leçons qui aident le chatbot de GA, sur l’analyse de progressions. Le chatbot n’a pas de skill d’analyse : skills-dev/_pending-tools/progression-analysis/DRAFT.md est bloqué sur un outil, au commit épinglé comme sur main. La leçon porte sur les deux skills qui prennent une progression, ProgressionMoodSkill et ProgressionCompletionSkill. La closure domain.analyzeProgression du DSL, qu’appelle GaMcpServer et qu’aucun skill du chatbot n’appelle, est laissée à une leçon ultérieure.
• Le skill d’ambiance est exécuté par son intention dans GaChatbot.Api, sans modèle. Le prompt du skill de complétion est lu en appelant par réflexion sa méthode privée BuildPrompt ; pour main, ses lignes sont appliquées au service à 6baf32e (projet GaKeysMain de la leçon 11), et pour le commit épinglé, elles sont confrontées à BuildPrompt sur les 36 questions.
• Les solutions des exercices ont été résolues à la main à partir du code et de la sortie.
• Exécution de CI 36777958134, pour le commit e002d6d : verte sur les trois systèmes, 2 min 05 s sous Linux, 2 min 16 s sous macOS, 7 min 24 s sous Windows, clone et compilation compris.
• Signalé en amont le même jour : #773 pour les lignes 65, 66 et 72, #774 pour les lignes 68 à 72.

2026-09-30 — Leçon 13 : ce que répond l’analyse de progression

• La demande : d’autres leçons qui aident le chatbot de GA. La leçon 12 avait laissé de côté la closure domain.analyzeProgression du DSL : le skill d’analyse de progression du chatbot est un brouillon bloqué sur un outil, alors que la closure dont il aurait besoin répond déjà par ga_dsl_eval.
• La closure du commit épinglé est appelée par DslEvalMcpTools.EvalClosure, comme l’appellerait un skill. Celle de main est compilée à partir de DomainClosures.fs à 6baf32e, sans modification, dans un projet F#, GaDslMain, contre le GA.Business.DSL épinglé et le service de GaKeysMain ; fetch-ga.sh place le fichier dans .ga-dsl/, et le programme atteint l’assembly par l’alias externe dslmain.
• L’analyseur d’accords de main a changé après le commit épinglé, dans #686 et 3707b72, pour des chiffrages que la leçon n’emploie pas ; cela vient de la lecture du diff, pas d’une exécution.
• Les solutions des exercices ont été résolues à la main à partir du code et de la sortie.
• Exécution de CI 36784699663, pour le commit 0ace36e : verte sur les trois systèmes, 1 min 40 s sous Linux, 1 min 25 s sous macOS, 7 min 15 s sous Windows, clone et compilation compris.
• Signalé en amont le même jour : #775 pour les lignes 76 à 78.

2026-09-30 — Leçon 14 : ce que répond le skill de substitution

• La demande : d’autres leçons qui aident le chatbot de GA. skill.chordsubstitution répond sans modèle, si bien que chacune de ses réponses se vérifie contre un manuel ; ses deux outils MCP et la closure domain.chordSubstitutions du DSL répondent à la même question pour la voie SKILL.md et pour GaMcpServer.
• Le programme atteint le skill comme à la leçon 12, par les intents de l’hôte du chatbot, et construit les outils avec l’IGrothendieckService de l’hôte. La closure est appelée au commit épinglé par DslEvalMcpTools.EvalClosure et sur main par GaDslMain, comme à la leçon 13. Les projets du cours et fetch-ga.sh sont inchangés.
• Le programme relit les réponses du skill dans leur Markdown avec des expressions régulières : un changement de format l’arrêterait au lieu de changer un décompte. Les substituts de manuel, deux par qualité, sont un choix du cours, écrit dans Lesson14.cs.
• Les solutions des exercices 1, 2 et 4 ont été résolues à la main ; le décompte de l’exercice 3 a été vérifié avec les expressions régulières de .NET, hors du programme du cours.
• Exécution de CI 36788871032, pour le commit b9aec40 : verte sur les trois systèmes, 2 min 11 s sous Linux, 1 min 24 s sous macOS, 7 min 16 s sous Windows, clone et compilation compris.
• Signalé en amont le même jour : #777 pour les lignes 79 et 81 à 84, #776 pour la ligne 80, #778 pour les lignes 85 et 86.

2026-09-30 — Leçon 15 : les notes d’un accord

• La demande : d’autres leçons qui aident le chatbot de GA. skill.chordinfo répond sans modèle à la question la plus simple que lui pose un guitariste, si bien que chaque réponse se vérifie contre un manuel ; ga_chord_info y répond pour la voie SKILL.md, à partir du même vocabulaire.
• Le programme atteint le skill comme aux leçons 12 et 14, par les intents de l’hôte du chatbot. Il lit ce que le skill a compris dans ses lignes de preuve, Root:, Quality: et Notes:, et lit par réflexion ses 19 formules pour les listes de notes : un changement de l’une ou de l’autre se verrait dans la sortie. Les projets du cours et fetch-ga.sh sont inchangés.
• Les orthographes du manuel viennent de degrés écrits dans Lesson15.cs. L’aller-retour rend au skill ses propres orthographes et n’a besoin d’aucun oracle.
• Les solutions des quatre exercices ont été vérifiées en appelant depuis PowerShell le skill, le vocabulaire et les expressions régulières compilés de GA, hors du programme du cours.
• Exécution de CI 36793871229, pour le commit 829eaea : verte sur les trois systèmes, 2 min 19 s sous Linux, 2 min 42 s sous macOS, 7 min 12 s sous Windows, clone et compilation compris.
• Signalé en amont le lendemain : #782 pour les lignes 87 à 89 et 91 à 93, #783 pour les lignes 90, 94 et 95.

2026-10-01 — Leçon 16 : les voicings d’un accord

• La demande, le 2026-10-01 : d’autres leçons qui aident le chatbot de GA. Un commentaire de GA présente ChordVoicingsSkill comme le skill le plus utilisé du chatbot. Il répond sans modèle, et chaque voicing qu’il renvoie se vérifie en jouant son diagramme.
• L’essentiel du pipeline de voicings a changé sur le main de GA après le commit épinglé ; la lecture de la question, non. La leçon exécute donc le skill deux fois : au commit épinglé, par l’hôte du chatbot comme à la leçon 15, et dans un nouveau programme, GaMain, compilé à partir d’un second clone de GA sans blobs, à f4f5b4a, que récupère fetch-ga.sh. check.sh le compile et l’exécute après les autres leçons : la CI clone et compile donc GA deux fois. Les deux programmes compilent les mêmes questions, tirées de code/ga-ai/Shared/ChordVoicingsProbe.cs.
• GaMain construit le skill et l’index de la leçon 3 avec les classes de main, comme le fait le câblage de l’hôte ; l’hôte lui-même n’est pas exécuté sur main.
• Les voicings faux du commit épinglé, dus au filtre par sous-chaîne de la différence 11 et à l’ordre des diagrammes de la différence 13, sont corrigés sur main : chaque voicing que renvoie le skill de main joue l’accord qu’il a lu.
• Les solutions des quatre exercices ont été vérifiées en exécutant le skill de GaMain et le CanHandle du commit épinglé, hors de la sortie attendue du cours.
• Exécution de CI 36870600319, pour le commit 6d647b1 : verte sur les trois systèmes, 3 min 14 s sous Linux, 2 min 56 s sous macOS, 8 min 40 s sous Windows, clone et compilation compris.
• Signalé en amont le jour même : #785 pour les lignes 96 à 98, #784 pour les lignes 99 et 100.

2026-10-01 — Leçon 17 : le capodastre et les accordages

• La demande, le 2026-10-01 : d’autres leçons qui aident le chatbot de GA. CapoSkill et AlternateTuningsSkill ont été écrits pour lever deux « dealbreakers » du backlog de GA. Ils répondent sans modèle, et chaque réponse se vérifie contre un manuel : celles du capodastre par l’arithmétique des demi-tons et les armures, celles des accordages par les notes de chaque corde.
• Sur main, CapoSkill ne fait que poser l’indicateur Declined sur son refus : la leçon ne l’interroge donc qu’au commit épinglé. Les expressions qui lisent les noms dans AlternateTuningsSkill ont changé : GaMain gagne donc un mode l17, qui pose les questions d’accordage sur main. Les deux programmes les compilent à partir de code/ga-ai/Shared/TuningsProbe.cs, et check.sh exécute GaMain l17 après GaMain l16.
• GaMain construit le skill des accordages avec un simple logger, puisque son constructeur ne prend rien d’autre.
• Une « orthographe théorique » est le critère du cours : une tonalité ou un accord, majeur ou mineur, dont aucune armure n’écrit la fondamentale avec cette qualité.
• La leçon 7 et la ligne 36 disaient que les skills du capodastre et des accordages acceptent ♭ et ♯. Leurs expressions prévoient les deux signes, mais les laissent souvent tomber (lignes 103 et 106) ; la phrase de la leçon 7 et la ligne 36 le disent désormais.
• Les solutions des quatre exercices ont été vérifiées en exécutant les skills du commit épinglé, hors de la sortie attendue du cours.
• Exécution de CI 36944575536, pour le commit 5bbae97 : verte sur les trois systèmes, 2 min 45 s sous Linux, 3 min 49 s sous macOS, 8 min 34 s sous Windows, clone et compilation compris.
• Signalé en amont après l’exécution de CI : #787 pour les lignes 101 à 105, #788 pour les lignes 101, 106 et 107.

2026-10-01 — Leçon 18 : la conduite des voix

• La demande, le 2026-10-01 : d’autres leçons qui aident le chatbot de GA. VoiceLeadingSkill a été écrit le 2026-05-14, comme les skills du capodastre et des accordages, pour lever un « dealbreaker » du backlog de GA. Il répond sans modèle, et chaque réponse se dit optimale, ce qu’une recherche exhaustive plus lente peut vérifier.
• VoiceLeadingSkill.cs est identique sur main : la leçon ne l’interroge donc qu’au commit épinglé, et GaMain ne gagne aucun mode.
• Le « mouvement minimal » est le critère du cours : autant de voix que le plus grand des deux accords, toutes les notes des deux accords jouées, et n’importe quelle note du plus petit doublée.
• Lesson17.SkillOf est désormais internal, pour que Lesson18 lise de la même façon le skill d’une intention.
• Les solutions des quatre exercices ont été vérifiées en exécutant le skill du commit épinglé, hors de la sortie attendue du cours.
• Exécution de CI 36957355913, pour le commit eadae1f : verte sur les trois systèmes, 2 min 11 s sous Linux, 4 min 43 s sous macOS, 8 min 32 s sous Windows, clone et compilation compris.
• Signalé en amont dans le ticket de GA #789, pour les lignes 108 à 113.

2026-10-02 — Leçon 19 : les paires de voicings

• La demande, le 2026-10-01 : une leçon sur ga_voice_leading_pair, le chemin que la leçon 18 avait laissé de côté. L’outil se trouve dans GaMcpServer, qu’appellent les agents ; le chatbot ne l’appelle pas, mais son skill de conduite des voix en attente l’appellerait.
• GaMcpServer ne fait pas partie des projets que compile le cours. fetch-ga.sh ajoute GaMcpServer/Tools/CompositionTools.cs aux deux clones clairsemés, les deux programmes le compilent, et Shared/VoicingSearchTool.cs remplace la classe dont l’outil lit par réflexion le champ privé Strategy.
• CompositionTools.cs est identique sur main, mais pas la recherche qu’il appelle. GaMain gagne donc un mode, l19, qui écrit l’index de la leçon 3 avec le code de main et pose les mêmes questions.
• Au commit épinglé, 80 des 210 candidats sont exacts et 3 des 10 premières paires jouent les deux accords ; sur main, 210 et 10. Ce constat n’a pas de ligne : sur main, la recherche ne renvoie que des voicings de l’accord demandé, pour ces 14 accords.
• « no fifth » est le verdict du cours pour un accord de septième auquel ne manque que sa quinte juste ; il compte comme juste, au même titre que « exact ».
• Lesson16.Corpus est désormais internal, pour que Lesson19 compte les voicings exacts de chaque accord dans le corpus.
• La solution du quatrième exercice a été vérifiée en exécutant l’outil du commit épinglé, hors de la sortie attendue du cours ; les trois autres se lisent dans la sortie attendue.
• Exécution de CI 36964238674, pour le commit e8394cd : verte sur les trois systèmes, 3 min 17 s sous Linux, 2 min 29 s sous macOS, 8 min 42 s sous Windows, clone et compilation compris.
• Signalé en amont dans le ticket de GA #791, pour les lignes 114 à 117.

2026-10-02 — Leçon 20 : les progressions générées

• La demande, le 2026-10-02 : ga_generate_progression pour la leçon 20, le compagnon de l’outil de la leçon 19 dans CompositionTools.cs, que les deux programmes compilent déjà.
• L’orthographe du manuel est le critère du cours : la lettre de la fondamentale suit le degré du chiffre romain dans la tonalité, pour les 15 armures de chaque mode.
• Le programme lit ligne à ligne les tables de transposition de ChordProgressions.yaml, dans le clone du commit épinglé.
• GaMain gagne un mode, l20, qui ne fait que le raccord : l’outil et son lecteur sont inchangés sur main, mais pas la recherche.
• Le chemin continu est une recherche du cours sur les mêmes 15 candidats par accord, avec la distance de l’outil : un voicing par accord, choisi par programmation dynamique.
• La solution du quatrième exercice a été vérifiée en exécutant l’outil du commit épinglé, hors de la sortie attendue du cours ; les trois autres se lisent dans la sortie attendue et dans le code de l’outil.
• Exécution de CI 37045152172, pour le commit 2db1270 : verte sur les trois systèmes, 3 min 14 s sous Linux, 4 min 23 s sous macOS, 9 min 46 s sous Windows, clone et compilation compris.
• Signalé en amont dans le ticket de GA #792, pour les lignes 118 à 122.

2026-10-02 — Leçon 21 : la recherche de voicings

• La demande, le 2026-10-02 : ga_search_voicings pour la leçon 21, l’outil que la remarque de ga_generate_progression nomme pour chaque accord.
• Les programmes des leçons 19 et 20 compilent désormais le VoicingSearchTool.cs de GA à la place de la classe de substitution du cours, avec la même sortie. Shared/SearchIndex.cs le fait pointer sur l’index du cours par GA_OPTICK_INDEX_PATH et coupe sa télémétrie par GA_VOICING_NO_TELEMETRY : le cours n’écrit donc rien sous le state/ de GA.
• Un voicing rootless est le critère du cours : au moins trois notes, toutes de l’accord, sans sa fondamentale.
• « La même réponse » compare les dix voicings et leurs scores ; le tableau des modes ne compare que les voicings.
• La solution du deuxième exercice est un calcul sur les scores affichés ; les trois autres se lisent dans la sortie attendue et dans le code des outils.
• Exécution de CI 37070292367, pour le commit 92e8d13 : verte sur les trois systèmes, 3 min 51 s sous Linux, 4 min 23 s sous macOS, 9 min 3 s sous Windows, clone et compilation compris.
• Signalé en amont dans le ticket de GA #795, pour les lignes 123 à 127.

2026-10-03 — Leçon 22 : les accords semblables

• La demande, le 2026-10-03 : IcvNeighborsSkill pour la leçon 22, le skill des accords semblables du chatbot, avec le skill en attente pour ga_icv_neighbors.
• Le programme appelle ExecuteAsync et lit l’en-tête de la réponse, sa ligne de vecteur et ses lignes ; le tableau des accords appelle par réflexion TryBuildPcSet, une méthode privée.
• Dans ce tableau, les notes de chaque accord sont celles du cours, celles d’un manuel pour chaque chiffrage, écrites avec des dièses comme GA les affiche.
• Les indices de routage viennent de DefaultRoutingHintProvider.GetDeltas ; le routeur lui-même n’est pas exécuté, car il a besoin des embeddings.
• Les solutions se lisent dans la sortie attendue et dans le code du skill ; la deuxième est un calcul sur deux vecteurs affichés.
• Exécution de CI 37143011796, pour le commit 627a3ca : verte sur les trois systèmes, 3 min 56 s sous Linux, 3 min 59 s sous macOS, 8 min 54 s sous Windows, clone et compilation compris.
• Signalé en amont dans le ticket de GA #798, pour les lignes 128 à 131.

2026-10-03 — Leçon 23 : la distance et le chemin harmoniques

• La demande, le 2026-10-03 : GrothendieckDeltaSkill et IcvShortestPathSkill pour la leçon 23, les deux skills voisins de celui de la leçon 22 qui prennent une paire d’accords.
• Le programme pose chaque question une seule fois et garde la réponse, puisqu’une question qui ne trouve aucun chemin coûte au skill du chemin une recherche parmi des centaines d’ensembles.
• Le nombre d’ensembles développés avant « No path » vient de la propre recherche du cours, qui suit la règle de FindShortestPath ; le skill ne l’affiche pas, et le programme ne chronomètre pas les skills.
• Une seconde lecture du code au commit épinglé par un autre modèle, la CLI auggie d’Augment avec gpt-6-sol et des outils en lecture seule, a estimé les mêmes 168 et 462 ensembles développés et a lu le nombre d’étapes de la même façon.
• Les solutions se lisent dans la sortie attendue et dans le code des skills.
• Exécution de CI 37147833299, pour le commit 12b105a : verte sur les trois systèmes, 4 min 14 s sous Linux, 6 min 9 s sous macOS, 12 min 28 s sous Windows, clone et compilation compris.
• Signalé en amont dans le ticket de GA #802, pour les lignes 132 à 135.

2026-10-03 — Leçon 24 : les classes d’ensembles et l’analyseur Grothendieck

• La demande, le 2026-10-03 : SetTheoryEquivalenceSkill et GrothendieckParseSkill pour la leçon 24, deux des skills du chatbot qu’aucune leçon n’avait encore interrogés.
• Le programme compare chaque verdict à ses propres tests de la transposition et de l’inversion, sur des masques de 12 bits, pour chaque paire ordonnée d’ensembles de trois et de quatre notes.
• Les formes premières sont comparées à la table du catalogue de Forte que tient GA, et non au livre de Forte.
• Une seconde lecture du code au commit épinglé par un autre modèle, la CLI auggie d’Augment avec gpt-6-sol et des outils en lecture seule, a lu de la même façon l’expression de la relation, les formes ws1 de l’analyseur, le groupement de la ligne 426, l’ordre qui fait de P(C) une application de foncteur et les qualités d’accord.
• Les solutions se lisent dans la sortie attendue et dans le code.
• Exécution de CI 37166154652, pour le commit 922ae7e : verte sur les trois systèmes, 7 min 39 s sous Linux, 6 min 7 s sous macOS, 14 min 9 s sous Windows, clone et compilation compris.
• Signalé en amont dans le ticket de GA #806, pour les lignes 136 à 140.

2026-10-04 — Leçon 25 : ce qui atteint le skill de transposition

• La demande, le 2026-10-04 : TransposeSkill pour la leçon 25. La leçon 10 avait appelé sa closure ; cette leçon cherche donc quelles questions l’atteignent.
• GaMain construit et démarre désormais l’hôte du chatbot de main : fetch-ga.sh ajoute au second clone les projets de l’hôte et skills/, et MainChatHost configure l’hôte comme le fait ChatHost, avec l’index de la leçon 3 construit par le code de main.
• Les formulations sont les 13 prompts d’exemple du skill, une formulation de son SKILL.md, les quatre prompts du corpus de GA et huit formulations du cours.
• Appelé directement, TransposeSkill répond par le message d’erreur de SkillMdDrivenSkill, et ses preuves disent la réponse produite par le seul LLM : le comportement des lignes 42 et 43, signalé dans le ticket #764.
• Les solutions se lisent dans la sortie attendue et dans le code.
• Signalé en amont dans le ticket de GA #809, pour les lignes 141 à 144.
• Exécution de CI 37182332132, pour le commit 33daa24 : verte sur les trois systèmes, 8 min 22 s sous Linux, 8 min 7 s sous macOS, 24 min 49 s sous Windows, clone et compilation compris.

2026-10-04 — Leçon 26 : le catalogue des modes

• La demande, le 2026-10-04 : ModesSkill pour la leçon 26. La leçon 8 avait croisé ses formules sur deux gammes, signalées dans le ticket #765.
• Le skill n’a besoin ni de modèle ni d’hôte : le programme le construit avec un logger nul, l’appelle directement et lit le catalogue par le GetTonalModalFamilies du skill lui-même.
• Le premier mode d’un manuel pour chaque famille est celui du cours, dans Lesson26.cs ; chaque autre mode est comparé au premier mode de sa propre famille.
• Les solutions se lisent dans la sortie attendue et dans le code.
• Exécution de CI 37215721850, pour le commit 16dbeff : verte sur les trois systèmes, 6 min 4 s sous Linux, 8 min 18 s sous macOS, 25 min 3 s sous Windows, clone et compilation compris.
• Signalé en amont dans le ticket de GA #813, pour les lignes 145, 146, 148 et 149 ; les comptes de la ligne 147 ont été ajoutés à #765 dans un commentaire.

2026-10-04 — Leçon 27 : les notes qui sonnent en dehors

• La demande, le 2026-10-04 : OutsideNotesSkill pour la leçon 27.
• Le skill n’a besoin ni de modèle ni d’hôte : le programme le construit avec un logger nul, l’appelle directement, et appelle son Classify privé par réflexion pour la règle.
• Les gammes d’accord usuelles des cinq accords de septième sont celles du cours, dans Lesson27.cs.
• Les solutions se lisent dans la sortie attendue et dans le code.
• Signalé en amont dans le ticket de GA #814, pour les lignes 150 à 154.
• Exécution de CI 37221169417, pour le commit 49e7e1a : verte sur les trois systèmes, 8 min 3 s sous Linux, 10 min 6 s sous macOS, 23 min 49 s sous Windows, clone et compilation compris.

À vérifier

• Si le chatbot déployé envoie chaque prompt de la leçon 5 à ImprovisationSkill ; le tracer du 2026-09-28 l’a vu le faire pour Am F C G.
• Les noms de Berklee de la leçon 5, mixolydien ♭13 pour V7/II et mixolydien ♭9 ♭13 pour une dominante en mineur, et F dorien pour un iv d’emprunt, à confronter à Nettles et Graf, The Chord Scale Theory & Jazz Harmony, que le cours n’a pas lu.
• Les solutions des exercices 2 et 3 de la leçon 5, non compilées contre GA.
• Si le chatbot public exécute une version qui inclut #749, et ce qu’un modèle répond aux lignes 5, 6, 13 et 14 de la leçon 7.
• La solution de l’exercice 4 de la leçon 7, non compilée contre GA.
• Si les exécutions quotidiennes du corpus de GA, qui ont un point d’accès Ollama et aucune clé Anthropic, comptent les sept prompts d’accords diatoniques comme six échecs et une réussite ; les instantanés du 2026-09-25 au 2026-09-29 sont marqués dégradés et ne détaillent pas les échecs prompt par prompt.
• La solution de l’exercice 4 de la leçon 8, une formule dérivée de la lettre de chaque note, non compilée contre GA.
• Ce que sert le chatbot pour les huit prompts d’exemple que IntervalSkill ne sait pas lire, ce qui demande le routeur d’intentions et son modèle d’embeddings.
• Les solutions des exercices 1 et 3 de la leçon 9, non compilées contre GA, et ce qu’afficherait la modification de l’exercice 2 pour un unisson diminué.
• Ce que le modèle envoie et répond aux questions de la leçon 10, et s’il change l’orthographe de la réponse d’une closure malgré son SKILL.md.
• Les solutions des exercices 1 et 2 de la leçon 10, non compilées contre GA.
• Ce que dit le modèle aux questions de la leçon 11 quand quatre tonalités sont « all tied », ou quand un dièse a été perdu.
• Ce que répond Identify aux 16 questions de la leçon 11 une fois leurs dièses lus, comme dans la solution de l’exercice 1.
• Ce que le modèle propose à partir des listes de la leçon 12, et s’il suit la règle du V7 du prompt ou la liste ; ce qu’un modèle fait de la règle du SKILL.md de progression-mood pour éclaircir.
• Les solutions des exercices de la leçon 12, non compilées contre GA.
• Ce qu’un modèle écrit à partir des trois lignes de domain.analyzeProgression, et s’il appelle la closure par ga_dsl_eval pour une question qu’aucun skill ne prend.
• Les solutions des exercices de la leçon 13, non compilées contre GA.
• L’intent que choisit le routeur sémantique pour chacun des prompts d’exemple de la leçon 14, et ce qu’un modèle écrit à partir de ga_chord_substitutions et de ga_chord_compare.
• Les solutions des exercices de la leçon 14, non compilées contre GA.
• L’intent que choisit le routeur sémantique pour les questions de la leçon 15, dont « I am learning Cmaj7 », et ce qu’un modèle écrit à partir de ga_chord_info.
• Les voicings que renvoie l’index de production pour les prompts de la leçon 16, l’intention que leur choisit le routeur, et ce qu’un modèle lit dans « voicings for am ».
• L’intention que choisit le routeur, avec les embeddings, pour les questions de capodastre et d’accordage de la leçon 17, y compris les formulations que les skills lisent mal.
• L’intention que choisit le routeur, avec les embeddings, pour les questions de conduite des voix de la leçon 18, y compris les deux prompts d’exemple qui disent « voicing ».
• Les candidats et les paires que renvoie ga_voice_leading_pair sur l’index de production, qui contient plus de voicings que le corpus de la leçon 3.
• Les gabarits et les toniques que les agents passent en pratique à ga_generate_progression : le cours essaie les toniques qu’un guitariste pourrait écrire, pas des appels journalisés.
• Ce que répond ga_search_voicings sur l’index de production de GA : l’index du cours est celui de la leçon 3, et l’avertissement du skill sur les tags de style y vaut peut-être.
• Quelles questions le routeur envoie à IcvNeighborsSkill avec les embeddings, et à quelle fréquence les utilisateurs les formulent comme ses prompts d’exemple plutôt que comme ses expressions régulières l’attendent.
• Le temps que met le skill du chemin dans le chatbot déployé pour deux accords de tailles différentes : le cours compte les ensembles que développe la recherche, pas le temps.
• Si le routeur du chatbot déployé envoie une question d’équivalence d’ensembles au skill des ensembles ou au skill de transposition, que favorisent deux de ses prompts d’exemple : le cours n’exécute pas le routeur.
• Quel skill choisit le routeur du chatbot déployé, avec ses embeddings, pour les transpositions qui ne reçoivent pas l’indice de transposition ou qui reçoivent celui d’une autre intention : le cours ne calcule pas les embeddings.
• Si le routeur du chatbot déployé envoie « Tell me about Hijaz » ou « List unnamed modal families » à ModesSkill : le cours n’exécute pas le routeur.
• Si le routeur du chatbot déployé envoie « why does F sound outside over a minor chord » ou « what is F over G7 » à OutsideNotesSkill : le cours n’exécute pas le routeur.
• Comment la page de GaChatbot.Api affiche un événement d’erreur dans un navigateur : la leçon 6 exécute un portage C# de son lecteur, pas la page. De même pour la solution de l’exercice 3 de la leçon 6.

Questions ouvertes

• Quelle règle d’inférence de la tonalité le skill d’improvisation de GA devrait-il suivre ? #744 laisse la question ouverte : le décompte des notes d’accord hors de chaque gamme majeure, utilisé par la leçon 5, ou les services d’identification de tonalité qui existent déjà dans GA.
• Les flux de GA devraient-ils signaler une erreur comme telle, par un champ event: error ou un type dans le JSON, et se terminer par [DONE] ou par leur propre événement final ? À a826864, chaque client doit deviner d’après la forme du JSON.
• La garde de GA devrait-elle aussi refuser les noms en minuscules et les qualités inconnues, au prix des faux positifs de l’exercice 3 de la leçon 7, ou une demande qui mêle accords valides et invalides devrait-elle recevoir une réponse qui nomme les accords invalides ?
• Le corpus devrait-il vérifier les notes d’un accord ou d’une gamme comme un ensemble, avec un invariant structuré, plutôt que comme des chaînes ? La lecture plus stricte des mêmes chaînes, dans la leçon 8, accepte encore 69 réponses étrangères.
• Les prompts d’exemple de chaque skill devraient-ils être exécutés comme un test contre le skill lui-même ? Les trois skills de la leçon 9 ne savent pas répondre à 11 de leurs 49.
• Les closures de GA devraient-elles orthographier les notes avec le Key du domaine, comme le fait ScaleInfoSkill, plutôt qu’avec des tableaux de douze noms ? Et transposeChord devrait-elle prendre un intervalle ou une tonalité cible plutôt qu’un nombre de demi-tons ?
• L’outil des tonalités devrait-il donner au modèle le classement de Identify avec son score, plutôt que les tonalités regroupées par décompte ? Et les tonalités qui ont les mêmes classes de hauteurs devraient-elles se distinguer par l’orthographe de la question ?
• La liste d’une tonalité mineure devrait-elle contenir le V et le V7 du mineur harmonique, pour que le catalogue de cadences du skill de complétion puisse s’y construire ? Et le texte fixe d’un skill devrait-il être généré à partir de son SKILL.md, pour que les deux ne puissent pas diverger ?
• L’identification des tonalités de GA devrait-elle peser l’accord qui ouvre et ferme une progression avant le décompte des accords diatoniques, et ses chiffres romains devraient-ils marquer une fondamentale chromatique, bVI, bVII ou le vii° d’une tonalité mineure, plutôt que ? ?
• Le skill de substitution de GA devrait-il classer les substituts d’un accord par notes communes et par fonction, comme domain.chordSubstitutions le fait dans une tonalité, et garder la distance ICV pour les questions de classes d’ensembles ? Et GrothendieckDelta devrait-il renvoyer 0 pour des vecteurs égaux, en laissant les appelants qui doivent distinguer deux ensembles comparer les ensembles eux-mêmes ?
• Les skills d’accords de GA devraient-ils partager un seul lecteur de chiffrages, bâti sur ChordVocabulary, qui lit un chiffrage en entier ou le décline ? Au commit a826864, les skills d’improvisation, de substitution et d’information sur les accords, ainsi que ga_chord_info, ont chacun leur propre expression, et chacun lit une partie de ce que lisent les autres.
• L’index de voicings de GA devrait-il stocker un nom que le filtre puisse trouver, un seul par ensemble de notes et par fondamentale, ou le filtre devrait-il comparer les classes de hauteurs, comme le fait la vérification du cours ? Et ChordVoicingsSkill devrait-il dire dans sa réponse quels filtres l’index a abandonnés, ou lire les techniques sur le diagramme, comme c’est le cas des filtres de confort ?
• Les skills de GA pour le capodastre et les accordages devraient-ils lire une tonalité ou une note avec un seul lecteur, qui prend l’altération avec la lettre, plutôt que chacun avec sa propre expression ? CapoSkill devrait-il écrire ses réponses comme le font les armures, et dire où placer le capodastre ? Et les deux skills devraient-ils accepter dans CanHandle les questions qu’ils savent lire, pour que le repli hors ligne les atteigne ?
• Le VoiceLeadingSkill de GA devrait-il choisir la doublure en plus de l’appariement, ou dire qu’il double la fondamentale, plutôt que d’affirmer que tout autre voicing demande plus de mouvement ? Devrait-il lire les chiffrages avec un seul lecteur, qui prenne M7, Δ, ø et une altération finale, écrire les notes à partir de la fondamentale de l’accord, et accepter dans CanHandle les questions qu’il sait lire ?
• Le ga_voice_leading_pair de GA devrait-il vérifier que chaque voicing joue l’accord demandé, apparier les notes les plus proches quand les tailles diffèrent, et renvoyer ses diagrammes dans l’ordre des grilles d’accords ? Le skill de conduite des voix en attente devrait-il être réécrit pour l’outil qui existe, ou l’outil recevoir le contrat qu’attend le brouillon ?
• Le ga_generate_progression de GA devrait-il écrire les accords d’après l’armure, avec sept lettres, prendre une tonalité avec son mode, borner length, et répondre par une progression de voicings plutôt que suggérer de raccorder des paires ? Le skill de progression en attente devrait-il être réécrit pour les gabarits qu’a l’outil ?
• Le ga_search_voicings de GA devrait-il encoder le mode ou cesser de le promettre, tenir un mode seul pour une requête vide, filtrer sur un tag plutôt qu’ajouter un bit, et comparer des mots entiers ? Les scores, les pièges et les exemples du skill de recherche de voicings devraient-ils être réécrits à partir de la sortie de l’outil, et le skill de recherche de voicings en attente, pour ga_search_voicings ?
• L’IcvNeighborsSkill de GA devrait-il lire les mots de ses propres prompts d’exemple, construire ses accords avec l’analyseur de chiffrages de GA plutôt qu’avec une table qui se rabat sur une triade majeure, lister chaque classe d’ensembles une seule fois avec un nom, et classer ses voisins selon un critère qui les distingue les uns des autres ? Le skill icv-neighbors en attente devrait-il être réécrit pour ga_icv_neighbors tel qu’il est ?
• Faudrait-il que le GrothendieckDeltaSkill de GA affiche un delta nul comme nul, que GrothendieckDelta.Explain perde sa flèche mal encodée, et que IcvShortestPathSkill refuse les accords de tailles différentes avant de chercher, compte les déplacements plutôt que les ensembles, et nomme les ensembles par lesquels il passe ? Les deux skills devraient-ils lire les mots de leurs propres prompts d’exemple et partager un même analyseur de chiffrages ?
• Faudrait-il que le SetTheoryEquivalenceSkill de GA lise la relation dans la tournure de ses propres prompts d’exemple, refuse un ensemble qu’il ne peut pas lire en entier, et ne dise « via either operation » que des ensembles symétriques par inversion ? Faudrait-il que GrothendieckOperationsParser abandonne le ws1 qui suit str, essaie ses alternatives avec attempt et lise les chiffrages d’accords usuels, et que GrothendieckParseSkill dise quelque chose des accords qu’il analyse ?
• GA doit-il garder un indice de transposition qui manque 3 des propres prompts d’exemple du skill et se déclenche sur la théorie des ensembles, les foncteurs et « move from X to Y » ? Sans embeddings, une transposition devrait-elle recevoir un message disant qu’on ne peut pas y répondre plutôt que l’agent des voicings, qui l’emporte par défaut dans les mots-clés du routeur d’agents ?
• GA doit-il vérifier Modes.yaml mode par mode face aux gammes qu’il nomme, mettre ses noms entre guillemets, donner à chaque mode un seul nom, et calculer une formule par degré pour sept notes et par lettre sinon ? ModesSkill devrait-il dire qu’il ne reconnaît pas une question plutôt que lister les modes de la gamme majeure ?
• OutsideNotesSkill devrait-il classer une note face aux gammes usuelles de l’accord plutôt que face à ses seules notes, donner à la b9 et à la b13 d’un accord de dominante un titre de tension, retirer la 11 des accords de treizième, lire l’accord avec le vocabulaire même de NormalizeQuality, et écrire les notes de l’accord d’après leurs lettres ?