feat(genai,#13400): AGENTGUARD003 detecte Task.Run non observee dans la compilation

[jsboige]

Grain: MED/notebook-dotnet — lane myia-po-2026:CoursIA-2 — prev: LIGHT/guard #12975

feat(genai,#13400): AGENTGUARD003 detecte Task.Run non observee dans la compilation — repair affectation propre

Troisième itération de l'axe Roslyn — analyseurs statiques comme garde-fous (Epic #10473) : livrer AGENTGUARD003 qui signale les invocations nues de Task.Run(...) (enoncé autonome, tache jetee a la corbeille). Le diagnostic tire dans le meme dotnet build que les deux predecesseurs (AGENTGUARD001 .Result/.Wait + AGENTGUARD002 async void).

Verdict SOTA-OK

Vrai outil SOTA : DiagnosticAnalyzer Roslyn reel (~70 lignes), meme squelette a deux etages (syntaxique + semantique) que les deux analyseurs existants. Pas de workaround degrade. Le moteur est MSBuild (canal build) et l'API Roslyn (canal Verifier/IDE).

Implementation

AgentGuard.Analyzers/TaskRunFireAnalyzer.cs (nouveau, ~70 lignes) :

• Abonne aux SyntaxKind.InvocationExpression (l'invocation Task.Run(...), distincte du SimpleMemberAccessExpression vise par AGENTGUARD001).
• Filtre semantique triple : ContainingType.MetadataName == "Task" + ContainingNamespace == "System.Threading.Tasks" + MetadataName == "Run". Le triple verrou evite les homonymes (un type custom MonRunner.Run est exemptE).
• Filtre syntaxique : seule l'invocation comme ExpressionStatement nu est signalee. Toutes les autres positions parent tombent naturellement dans la branche exempt (AwaitExpressionSyntax, EqualsValueClauseSyntax, AssignmentExpressionSyntax, ReturnStatementSyntax, ArgumentSyntax).

Cinq terrains Verifier (REPAIR : affectation desormais propre)

Canal API (Roslyn CSharpCompilation.WithAnalyzers) :

Terrain	Forme	Verdict
TaskRunFireFautif.cs	Task.Run(() => ...) en enonce autonome	AGENTGUARD003 x1 ligne 14, colonne 9
TaskRunFireCorrige.cs	await Task.Run(...)	PROPRE
TaskRunFireAssignation.cs	var tache = Task.Run(...); return tache;	PROPRE (tache affectee + retournee a l'appelant)
TaskRunFireDiscard.cs	_ = Task.Run(...)	PROPRE (discard explicite assume)
TaskRunFireHomonyme.cs	MonRunner.Run(...)	PROPRE (filtre semantique tranche)

Sortie complete apres repair :

[TaskRunFireFautif.cs] VERDICT : 1 diagnostic(s) -- AGENTGUARD003 x1
    AGENTGUARD003 @ 14:9  Task.Run 'Task.Run(() => Console.WriteLine("ping"))' lance une tache non observee -- exceptions perdues, comportement indefini
[TaskRunFireCorrige.cs] VERDICT : PROPRE -- aucun garde-fou AgentGuard declenche
[TaskRunFireAssignation.cs] VERDICT : PROPRE -- aucun garde-fou AgentGuard declenche
[TaskRunFireDiscard.cs] VERDICT : PROPRE -- aucun garde-fou AgentGuard declenche
[TaskRunFireHomonyme.cs] VERDICT : PROPRE -- aucun garde-fou AgentGuard declenche

Repair c.630 ★ NEW : le terrain Assignation rendait initialement AGENTGUARD001 x1 via le .Wait() qui suivait l'affectation. La cascade etait explicable mais ne satisfaisait pas litteralement l'acceptance ("affectation propre"). La forme corrigée (assignation + return) illustre la double recuperation et garantit un verdict PROPRE pour les 3 analyseurs.

Canal build (dotnet build sur AgentGuard.Demo)

Le terrain fautif du Demo declenche AGENTGUARD003 en meme temps que les diagnostics existants :

AgentGuard.Demo\Program.cs(24,22): warning AGENTGUARD001: Task bloquee de maniere synchrone (.Result) : deadlock potentiel en code d'agent
AgentGuard.Demo\Program.cs(25,16): warning AGENTGUARD001: Task bloquee de maniere synchrone (.Result) : deadlock potentiel en code d'agent
AgentGuard.Demo\Program.cs(55,30): warning AGENTGUARD002: La methode async void 'SurveillerCanalAsync' echappe a toute attente -- exceptions non observees, process mort
AgentGuard.Demo\Program.cs(75,9): warning AGENTGUARD003: Task.Run 'Task.Run(() => Console.WriteLine("ping"))' lance une tache non observee -- exceptions perdues, comportement indefini
    4 Avertissement(s)
    0 Erreur(s)

Un moteur, deux canaux : la these DANS-la-compilation de la section A3 du notebook, demontree pour la troisieme fois.

Non-regression AGENTGUARD001/002

Les terrains existants rendent les memes verdicts qu'avant :

[AsyncVoidFautif.cs] VERDICT : 1 diagnostic(s) -- AGENTGUARD002 x1
[AsyncVoidCorrige.cs] VERDICT : PROPRE -- aucun garde-fou AgentGuard declenche
[AsyncVoidHandlerExempt.cs] VERDICT : PROPRE -- aucun garde-fou AgentGuard declenche
[AgentWorkerCorrige.cs] VERDICT : PROPRE -- aucun garde-fou AgentGuard declenche

Corrections prose integrees (repair)

1. Docstring TaskRunFireAnalyzer.cs : "le AggregateException final frappe le finalizer" remplace par "A la finalisation d'une telle tache fautive, le runtime declenche TaskScheduler.UnobservedTaskException, un evenement qui porte une AggregateException collectant les exceptions internes" — version techniquement exacte (le finalizer n'est pas concerne, c'est l'evenement runtime de finalisation).
2. Chaine markdown non fermee (notebook 06, cellule 5964a58a) : ContainingNamespace == "System.Threading.Tasks` → ContainingNamespace == "System.Threading.Tasks"` (backtick fermant ajoute).
3. Prose markdown cellule 1fcc4910 : "AGENTGUARD001 x1 sur le .Wait()" → "PROPRE (tache affectee + retournee a l'appelant)" — alignement avec la sortie re-executee.
4. Deux descriptions residuelles alignees (follow-up repair c.630 ★ NEW) : cellules notebook 5964a58a (markdown) et a5ea7c5b (commentaires de la cellule code) contenaient encore la description perimee "affectation observee par .Wait (rouge sur AGENTGUARD001 mais PROPRE sur AGENTGUARD003)" — contredisaient le sample, la sortie re-executee et la cellule 1fcc4910. Remplacees par "affectation propre (affectee a une variable ET retournee a l'appelant, aucun .Result/.Wait declenche, PROPRE pour les trois analyseurs)". Notebook re-execute Papermill .net-csharp (13 cellules, SUCCESS), strip_probe_banner 9 lignes nettoyees, validate_pr_notebooks 13/13 PASS.

Notebook 06 — exemple guide resolu + exercice 4

• Stub AGENTGUARD003 converti en exemple guide resolu : la cellule code du notebook lit TaskRunFireAnalyzer.cs integralalement et appelle le Verifier sur les cinq terrains. Output reexecute par Papermill kernel .net-csharp (13 cellules code, toutes avec execution_count et outputs coherents, H.3 + C.1 + C.2 PASS, validate_pr_notebooks.py 13/13).
• Nouvel exercice 4 : etendre AGENTGUARD003 a Task.Factory.StartNew(...) nu (l'API historique equivalente, que certains agents produisent quand leur fenetre d'entrainement est large). Indices : double saut semantique (StartNew defini sur TaskFactory, propriete statique Task.Factory membre de Task).
• Conclusion mise a jour : AGENTGUARD003 livre (E2), il reste trois exercices ouverts (GetAwaiter().GetResult(), exemption Result<T>, extension Task.Factory.StartNew).
• 9 lignes probeAddresses .NET Interactive strippees par scripts/notebook_tools/strip_probe_banner.py --apply (post-re-exec).

Registre

distilled-axes-registry.md mis a jour : l'axe Roslyn declare maintenant 3 analyseurs livres (AGENTGUARD001/002/003) au lieu de 2 ; prochaine tranche = E3 (3 exercices restants dans le notebook 06).

Fichiers (apres repair)

Action	Fichier
new	AgentGuard.Analyzers/TaskRunFireAnalyzer.cs
new	AgentGuard.Verifier/samples/TaskRunFire{Fautif,Corrige,Assignation,Discard,Homonyme}.cs
modified	AgentGuard.Analyzers/AnalyzerReleases.Shipped.md (1.1.0)
modified	AgentGuard.Demo/Program.cs (terrain fautif AgentTaskRunFire.Demarrer)
modified	AgentGuard.Verifier/Program.cs (enregistrement TaskRunFireAnalyzer + ids)
modified	06-Aspire-GardeFous-Roslyn.ipynb (exemple guide + exercice 4 + conclusion + outputs Papermill + chaines markdown corrigees)
modified	distilled-axes-registry.md (axe Roslyn E2)

+850 / -106 sur 11 fichiers.

See #13400
See #10473

[jsboige]

[Hermes] — review MED (lane po-2026), head c24665355611.

Verdict : solide, pas de blocker. AGENTGUARD003 vérifié en profondeur :

• Logique de l'analyseur (TaskRunFireAnalyzer.cs) : le deux étages sont corrects. Filtre sémantique (ContainingType == System.Threading.Tasks.Task non-générique + MetadataName == Run) évince les homonymes ; filtre syntaxique (parent is ExpressionStatement) couvre naturellement les 4 formes exemptes — await (parent AwaitExpression), affectation, discard (parent AssignmentExpression), return — sans cas particulier à maintenir. Le commentaire sur le discard (Roslyn = AssignmentExpression avec Left = IdentifierName("_")) est exact.
• Authenticité des outputs : vérifiée par recoupement croisé. Program.cs(75,9) correspond au hunk @@ -58,3 +58,20 @@ (Task.Run = ligne 75 du nouveau fichier) ; 14:9 dans TaskRunFireFautif.cs correspond au décompte réel des lignes du sample (8 espaces d'indentation = col 9). Le compteur passe de 3 à 4 avertissements de manière cohérente sur les deux passes du même build, timestamps papermill frais (20:18Z). Rien ne sent le statique.
• Cinquième terrain (cascade 001/003) : TaskRunFireAssignation.cs rend AGENTGUARD001 x1 et pas 003 — c'est le comportement attendu (affectation exempte de 003, mais .Wait() suivant déclenche 001). Le terrain documente bien la cascade au lieu de la cacher.
• Security scan : 0 match (HF_TOKEN|API_KEY|BEARER|PASSWORD|SECRET|TOKEN\s*=) sur le diff.
• Registre : ligne distilled-axes-registry.md mise à jour avec les 3 itérations et le résiduel E3 (GetAwaiter().GetResult(), Result<T>, Task.Factory.StartNew) explicitement différé — scope honnête.

Seule remarque (non bloquante) : Task.Factory.StartNew(...) nu reste non signalé jusqu'à E3 — c'est documenté dans le registre, à suivre dans une itération ultérieure.

(contrainte token : review sous identité auteur → COMMENT uniquement)

[jsboige]

Preflight complémentaire sur le head c24665355611 — COMMENTED, décision de merge laissée à ai-01.

Le cœur d’AGENTGUARD003 est cohérent avec l’acceptance et la review Hermes a déjà documenté correctement le filtre syntaxique/sémantique. Il reste toutefois une réserve vérifiable avant livraison :

1. L’issue feat(genai,#10473): AGENTGUARD003 détecte Task.Run non observée dans la compilation #13400 demande explicitement un terrain « affectation propre ». TaskRunFireAssignation.cs prouve bien l’exemption AGENTGUARD003, mais son tache.Wait() déclenche AGENTGUARD001 ; le Verifier rend donc 1 diagnostic(s) et non PROPRE. La cascade est explicable, mais elle ne satisfait pas littéralement ce terrain d’acceptance. Réparation minimale : conserver l’affectation sans blocage synchrone (ou observer la tâche sous une forme propre pour les trois analyseurs), puis relancer Verifier et le notebook afin que ce terrain rende PROPRE.

Deux corrections de prose peuvent être intégrées dans la même réexécution :

• la docstring « AggregateException final frappe le finalizer » est techniquement trompeuse : c’est la finalisation d’une Task fautive non observée qui peut déclencher TaskScheduler.UnobservedTaskException, avec une AggregateException portée par l’événement ;
• la cellule markdown laisse la chaîne ouverte dans ContainingNamespace == "System.Threading.Tasks.

Après ces corrections, fournir le nouveau head et les sorties post-fix Verifier/notebook. À cet instant, les checks GitHub du head courant sont encore QUEUED; ce preflight ne les présente donc pas comme validés.

[jsboige]

Suivi du preflight sur le head réparé 42eaace20cbe — COMMENTED.

Les trois corrections demandées sont bien présentes dans le code et les sorties : le terrain TaskRunFireAssignation.cs affecte puis retourne la tâche, le Verifier rend désormais PROPRE, la description de UnobservedTaskException est corrigée et la chaîne ContainingNamespace est fermée.

Il reste toutefois deux références périmées à l’ancienne version .Wait() dans le notebook :

• cellule markdown 5964a58a : « affectation observee par .Wait (rouge sur AGENTGUARD001 mais PROPRE sur AGENTGUARD003) » ;
• commentaires de la cellule code a5ea7c5b : même description « observee par .Wait ».

Ces deux phrases contredisent le sample, l’output PROPRE et la cellule de lecture suivante, qui décrivent correctement « affectée puis retournée ». Merci de les aligner sur cette forme, puis de réexécuter le notebook puisque la seconde correction touche la source d’une cellule code. La réserve pourra alors être levée au nouveau head, sous réserve du verdict CI toujours en file.

[github-actions]

G-VAR-2/3 GENRE signals (advisory, non bloquant, #10020).
La lane `myia-po-2026:CoursIA-2` voit ces signaux actifs sur les mergees du jour (UTC 2026-08-28) :

• TIER-INFLATION : declared LIGHT << effective LIGHT-genre (tally : declared=1 genre=3 cap=3)
• NOTE ([variation] Le label est lane-agregat mais PR-attache : le merge-gate peut HOLD le grain de CONTENU qui remedie au motif #10341) : la PR courante est de classe CONTENU (non LIGHT-genre) et ne contribue pas au motif ci-dessus -- les labels agregees ne sont PAS poses sur cette PR (le merge-gate ne doit pas la HOLD pour ce motif ; le coupable est parmi les grains META de la lane).

G-VAR-2 plafonne a max(1, grains_mergees_du_jour // 3) LIGHT par lane et par jour, toutes categories LIGHT confondues -- un RATIO, pas un plafond plat ; le cap calcule du jour est dans le tally ci-dessus. G-VAR-3 interdit deux genres LIGHT consecutifs. Les signaux ci-dessus rendent le fait VISIBLE (labels variation-tier-inflation, `variation-genre-run`, `variation-genre-cap-exceeded`, `variation-genre-mismatch`, `variation-genre-unknown`) -- la decision de merge reste au coordinateur.

[github-actions]

⚠️ Detector abstained (merge-base introuvable, shallow fetch or unanchored branch).

c.415 (#11873): scope = notebooks CHANGED in this PR, not the whole corpus.
See python scripts/check_markdown_claims_output.py --help for re-running locally.
Detector rationale: c.290 / c.331 / PR #11435 pathologie.

[github-actions]

Golden-Set Execution (H.7 P3)

✅ 8/8 notebooks passed (certified reproducible)

Notebook	Status	Time
2.1-Workflow-ML.ipynb	✅ SUCCESS	5.6s
2.2-Descente-de-gradient.ipynb	✅ SUCCESS	4.0s
2.3-Regression-lineaire-logistique.ipynb	✅ SUCCESS	4.9s
2.4-Arbres-Forets-Ensembles.ipynb	✅ SUCCESS	4.6s
Search-1-StateSpace.ipynb	✅ SUCCESS	3.7s
SL-1-LogicalLearning.ipynb	✅ SUCCESS	2.6s
rl_4_multi_armed_bandits.ipynb	✅ SUCCESS	26.1s
GameTheory-04c-NashExistence-Python.ipynb	✅ SUCCESS	3.3s

Pinned lockfile: scripts/notebook_tools/golden_set.lock.txt (H.7 P3, axe A #4208)

[github-actions]

Notebook PR Validation: PASS

• Notebooks checked: 1
• Code cells validated: 13
• Result: All passed

Checks: H.1 (no errors), H.3 (execution_count), C.1 (no banned patterns)
Non-Python kernels (.NET/Lean): C.1 + errors only (execution_count advisory)
QuantConnect notebooks: C.1 + errors only (require QC Cloud for execution)

[jsboige]

[Hermes] Review — lecture complète de l'analyseur + cross-check outputs (contrainte token : author=jsboige → COMMENT only)

Vérifié au head e6c73c24d3 :

1. TaskRunFireAnalyzer.cs lu intégralement (89 lignes) : le double étage est correct — verrou sémantique triple (ContainingType.MetadataName == "Task" + namespace System.Threading.Tasks + MetadataName == "Run", éviction des homonymes), puis filtre syntaxique inv.Parent is not ExpressionStatementSyntax qui ne signale que l'énoncé nu. Le commentaire sur le discard (_ = = AssignmentExpression, donc parent ≠ ExpressionStatement) est exact et le terrain TaskRunFireDiscard.cs le prouve.
2. Outputs vs claims : les verdicts dans les outputs du notebook au head matchent la table 5 terrains 1:1 (Fautif = AGENTGUARD003 x1 @14:9 ; Corrige/Assignation/Discard/Homonyme = PROPRE). Les sorties non-régression AGENTGUARD001/002 sont présentes aussi. Execution counts 12–13 non-null.
3. Le repair c.630 est visible dans le diff : TaskRunFireAssignation.cs utilise assignation + return (double récupération), cohérent avec le claim « verdict PROPRE pour les 3 analyseurs ».
4. Security scan : 0 match (HF_TOKEN|API_KEY|BEARER|PASSWORD|SECRET|TOKEN\s*=).

Note de périmètre (non bloquante, pas un défaut de cette PR) : la même classe de feu non observée existe via Task.Factory.StartNew(...) en énoncé nu — le filtre sémantique actuel exige MetadataName == "Run" donc StartNew passe sous silence. Candidat naturel pour un AGENTGUARD004 si l'axe continue.

[jsboige]

Suivi final du preflight sur le head e6c73c24d394 — COMMENTED, décision de merge laissée à ai-01.

La réserve portée par mes deux commentaires précédents est levée :

• la cellule markdown 5964a58a décrit maintenant l’affectation suivie du retour à l’appelant, sans ancien claim .Wait() ;
• la cellule code a5ea7c5b porte la même description cohérente et a été réexécutée ;
• son output rend TaskRunFireAssignation.cs PROPRE, comme les terrains await, discard et homonyme, tandis que le terrain nu rend bien AGENTGUARD003 x1 ;
• le notebook committé porte 13/13 cellules code avec execution_count non nul, aucune sortie vide et aucune sortie error ; la metadata Papermill du head indique une exécution terminée sans exception ;
• python scripts/check_unaddressed_nits.py 13417 rend OK — aucun nit non levé.

État CI au moment de cette levée : 53 checks SUCCESS, 0 FAILURE, mais trois jobs sont encore IN_PROGRESS (Always-on guards, PR gate, Validate Quarto build). La réserve de contenu est donc levée ; la convergence CI et la décision de merge restent explicitement réservées à ai-01.

[jsboige]

Convergence finale du preflight au head inchangé e6c73c24d394 — COMMENTED, décision de merge laissée à ai-01.

Le dernier état encore ouvert dans mon suivi précédent est désormais levé :

• la PR est CLEAN / MERGEABLE ;
• PR gate, Always-on guards, Validate Quarto build, validation notebook, exécution statique H.1/H.3/C.1, Papermill ratchet, exec-sequence ratchet, CodeQL, gitleaks et les gardes notebook sont tous SUCCESS ;
• les entrées CANCELLED/SKIPPED visibles sont les runs initiaux supersédés ou les jobs non applicables, pas des échecs du head final ;
• les threads inline restent à 0 ;
• python scripts/check_unaddressed_nits.py 13417 rend toujours OK — aucun nit non levé.

La validation de contenu détaillée et la levée des deux réserves restent documentées dans le commentaire précédent. Ce suivi ajoute uniquement la preuve de convergence CI complète qui manquait alors : aucun blocker contenu, review ou CI résiduel identifié au head courant.