Repository navigation
FR completion roadmap
Accueil du dépôt | English | Registre de validation | Dernier rapport d'exécution
Le livrable de planification est terminé. L'exécution complète de l'atelier ne l'est pas. Les tâches non cochées représentent des travaux à effectuer, et non des résultats déjà observés ou promis.
La passe de complétion documentaire bilingue couvre l'accueil du dépôt, l'index anglais, l'index français, les huit unités (0, 1, 2, 3, 4, 5.1, 5, 6) et les deux feuilles de route. Chaque lab possède son équivalent, ses critères d'acceptation et ses liens de preuve. Consultez la couverture et les tâches de reprise pour les travaux restants, sans reprendre un lab entier.
La livraison documentaire ne clôt pas T001/T002/T005/T006/T007/T009/T010/T011/T012/ T014/T015/T016/T017. La matrice F6 distincte compte 8 PASS, 2 PARTIAL, 0 FAIL et 2 NOT_RUN ; la matrice d'origine à onze scénarios reste à 10/11, avec deux échecs du cas 9 et aucun troisième rejeu. F6-09 et les deux réponses statiques françaises réussissent sous sélection explicite de langue, sans prouver la réparation du sélecteur natif, la détection automatique ou la localisation statique complète. Les échecs historiques ci-dessous restent conservés.
Le wiki reflète ces guides de référence : English | Français. Suivez les contrôles de publication partagés après modification des sources ; cette livraison documentaire ne publie pas un nouvel instantané wiki.
La correspondance publique F6 et les guide lab 6/registre synchronisés livrent réconciliation et publication, pas l'acceptation d'exécution du lab entier. T017 reste non cochée. F6-01/02/03 sont PASS historiques hors ligne; F6-04 est PASS; F6-05 est PASS au niveau du document avec la limite d'extrait ci-dessous. F6-07 est PASS et F6-08 est PASS pour la réponse uniquement; F6-06/12 restent PARTIAL. F6-09 est PASS sous sélection explicite de langue; F6-10/11 restent NOT_RUN. Au point de contrôle hors ligne initial du 2026-10-26, F6-04/05 étaient NOT_RUN et F6-08 était PARTIAL; cette réconciliation avait soumis zéro question.
Le contrôle multisource exact réussit F6-07 : une question, un appel MCP natif terminé, deux enregistrements vérifiés dans le corpus figé et deux groupes applicables, procédures d'enquête et conformité réglementaire. Comparaison attribuée, aucune règle inventée et plan terminé non annulé sont prouvés. Cette preuve MCP prospective ne joint pas les résultats d'outil du spécialiste original historique.
Le reçu de réparation du routage
conserve F6-06 FAIL initial : l'accueil non ancré correspondait à hi dans Which.
Seule cette condition a changé, avec ^...$ et reviewing a case; le contrôle du
sujet natif sauvegardé réussit. Une cohorte distincte comprend quatre questions,
quatre conversations et aucune relance interne. F6-06 réussit désormais la recherche
MCP étayée, avec deux enregistrements vérifiés et un plan terminé, mais reste PARTIAL :
l'appel de l'agent enfant Foundry original est non prouvé. Les régressions F6-04/05
réussissent dans leurs limites existantes. F6-09 FAIL est conservé : ancrage et
traçabilité centrale réussis, mais prose finale anglaise. La version du composant
du sujet reste NOT_ESTABLISHED; aucune publication d'agent n'a eu lieu.
La tentative avec langue configurée
ajoute fr-FR secondaire, sans changer en-US primaire. Le nouvel envoi anglais
affiche Cannot send empty message : une intention/un clic, zéro question acceptée
observée en 240 secondes, acceptation serveur NOT_ESTABLISHED. Le français n'est
ni sélectionné ni envoyé; cette tentative est NOT_RUN et ne remplace pas le FAIL
terminé. Langue de session et restauration anglaise restent non vérifiées.
Détection automatique et localisation complète des sujets statiques ne sont pas
prouvées. La publication ne soumet aucune question.
Le contrôle ultérieur en texte français
prouve la livraison, pas l'acceptation française : une question acceptée après
vérification du vrai champ et du compteur 60/2000, mais activité et réponse ont
la locale en-US et la prose reste anglaise. Un appel MCP terminé retourne trois
enregistrements vérifiés, dont les deux entrées centrales de la base anglaise
antérieure. Corpus, instructions et modèle sont inchangés, mais le français
secondaire a été ajouté après cette base. Le plan non annulé termine en
71,232 secondes de réception serveur à réponse (76,134 secondes depuis Send).
Aucune nouvelle question anglaise ni relance. Les deux boutons de langue
exposent encore aria-checked=false après un contrôle clavier natif sans question.
Ce F6-09 historique reste FAIL, sans cause de sélection prouvée. L'échec de livraison précédent
et le NOT_RUN conditionnel restent conservés.
La réparation prise en charge des traductions
utilise PAC officiel 2.14.1 via le proxy NuGet d'entreprise existant, sans modifier
l'authentification ni TLS. L'import français natif réussit; des exports indépendants
prouvent les 155 valeurs anglaises inchangées et 97 valeurs d'exécution traduites
persistantes après normalisation des libellés/déclencheurs. L'énumération Windows
à chemins étendus vérifie les 39 fichiers principaux identiques et 22 traductions
ajoutées; le sous-ensemble précédent de 35 fichiers à chemins courts était incomplet.
Après rechargement complet,
les deux langues restent aria-checked=false et une nouvelle session sans question
accueille en anglais. À ce point de contrôle, la question française reste NOT_RUN;
le dernier F6-09 terminé à ce point de contrôle était FAIL. Traduction statique complète et cause de sélection
restent non prouvées; voir #5.
La cohorte ultérieure de sélection explicite
réussit F6-09 : System.User.Language exécuté et relu vaut French; la question
inchangée reçoit une prose française et un plan ancré terminé, tandis que les
Activity.Locale envoyée/répondue restent en-US. La régression anglaise réussit;
F6-06 global reste PARTIAL, car la route d'enfant Foundry original n'est pas prouvée.
Deux conversations neuves contiennent cinq messages acceptés : deux questions de
domaine et trois contrôles déterministes, sans relance. Chaque question termine un
appel MCP; l'anglais retrouve une entrée et le français deux, dont une entrée ATO
centrale commune. Le retour à l'anglais est prouvé dans la seconde conversation.
Les 1 288 fichiers historiques gardent leurs empreintes/dates; un clone complet neuf
vérifie 63 fichiers hors jeton et 22 traductions inchangés. Réparation du sélecteur,
détection automatique et preuve continue des versions restent non prouvées.
Les anciens FAIL/NOT_RUN et l'attente échouée d'écho du collecteur sont conservés;
aucun message n'est rejoué.
Les deux textes statiques français ultérieurs
réussissent leurs contrôles natifs ciblés : une conversation neuve, quatre messages
acceptés (deux consultations et deux contrôles de langue), quatre clics Send et zéro
relance. Les réponses CTR/SAR correspondent exactement aux ressources françaises
corrigées, avec les 12 citations littérales et références individuelles inchangées.
Ces instantanés ne sont pas une recherche en direct; zéro invocation native de
recherche/MCP/Foundry. System.User.Language français et retour à l'anglais sont
prouvés; les Activity.Locale envoyées/répondues restent en-US. La valeur persistante
est remise à l'anglais, pas effacée. Un téléversement conserve les deux corrections.
Les contrôles stricts d'égalité et de modification de deux seuls fichiers échouent
et restent des échecs : l'audit en lecture seule explique 41 positions réordonnées
avec les 42 phrases Escalate conservées, un composant français matérialisant un repli
existant et les métadonnées administratives. Le clone passe de 64 à 65 fichiers;
le contrôle après exécution préserve 64 fichiers hors jeton, 23 traductions françaises
et 50 composants. Les 158 ressources anglaises/153 françaises et 1 814 fichiers
historiques restent exacts à ce contrôle. L'échec UTF-8 strict sur BOM est conservé;
la validation compatible BOM relit les mêmes fichiers, sans export ni message
supplémentaire. Cette cohorte distincte ne prouve ni localisation statique complète,
ni réparation du sélecteur, ni détection automatique, ni achèvement de T017.
Le contrôle exact d'historique privé
est F6-08 PASS pour la réponse uniquement : une question, sans relance ni Hello
supplémentaire, sur la même configuration prospective figée que F6-04/05. La réponse
finale complète reconnaît que les preuves configurées n'établissent pas l'historique
du client privé et refuse toute inférence, sans événement inventé ni substitution
par le corpus fictif. Message final natif et repli terminal EndDialog/état sans
réponse terminé sont prouvés, mais la clôture du plan reste non prouvée :
aucun DynamicPlanFinished en 240 secondes. Une recherche locale terminée retourne
trois enregistrements. Le libellé MCP n'a pas d'invocation/sortie corrélée; les nombres
réels d'appels MCP et Foundry sous-jacents sont NOT_ESTABLISHED, pas zéro.
Ce cas est distinct du cas 9 de la matrice originale, sans équivalence d'architecture
ni achèvement T017/atelier. La publication ne soumet aucune question.
Les deux contrôles natifs exacts
consignent la cohorte antérieure : deux questions, une par conversation neuve, sans
question préliminaire ni relance. F6-04 a terminé la clarification avec
activityProcessed=true, sans recherche ni appel de preuve Foundry/MCP
(0,118 seconde entre réception serveur et réponse finale). F6-05 a terminé un
SearchAndSummarizeContent local et un DynamicPlanFinished non annulé, sans
appel de preuve Foundry/MCP (70,618 secondes). Account Takeover est étayé au niveau
du document par un autre fragment réellement récupéré de la même source;
l'extrait de citation affiché ne contient pas la ligne ATO. Le support du fragment
cité exact, la fidélité de l'extrait et la qualité globale des citations ne sont
pas prouvés. Cette configuration prospective figée du spécialiste original
existant, adaptée à MCP, utilise le Markdown éditeur MIT réellement Ready,
sans équivalence avec la configuration historique; l'ingestion DOCX reste Error.
Après contrôle, racine/paramètres, empreinte des instructions, versions des
sources, empreintes éditeur et archives sont inchangés, sans second export complet.
Ces tests n'ont rien modifié/publié ni créé de ressource. La publication ne soumet
aucune question. Aucun nouvel export ou secret n'est requis pour ces deux contrôles.
Accueil/connaissances locales/expertise étayée/multisource, trois jeux de données et nettoyage fondés sur les sources sont distingués des contrôles et variantes du guide. F6-05 figurait dans les instructions, sans prouver son exécution au point initial hors ligne; le nouveau reçu ne ferme que ces deux contrôles. Un libellé différent ne crée pas une obligation originale universelle ni une consigne de recommencer le travail vérifié. Les exigences supplémentaires du document principal protégé restent UNKNOWN, sans contournement ni reconstruction. Annotations natives, URL éditeur et citations verbatim restent exclues des obligations originales universelles; échecs et citations réussies sont conservés.
Le spécialiste original natif 4/4 ne certifie pas l'extension diagnostique ni la jointure indépendante de ses résultats MCP natifs. Le candidat distinct avait atteint 11/11 avec relance; le résultat actuel après contrôle est 10/11, avec deux échecs du cas 9, cause non prouvée et aucun troisième essai. T003/T004 hébergé v3 réussit 3/3, mais la v5 conservée n'est ni certifiée native ni supprimée par les anciens reçus. Refus Search du lab 5 et HTTP 400 de blueprint ne ferment ni refus Foundry F6 ni test sans Activity/réparation. Reprenez uniquement un critère non résolu et justifié après son propre prérequis pris en charge et périmètre autorisé; l'atelier reste incomplet.
La référence de planification est le commit 94ebcd3 et les preuves conservées.
Le 22 octobre, 47 tests documentaires, 33 tests
de l'extension, les vérifications de dépendances et de syntaxe Python ont réussi.
Ces résultats ne certifient pas l'acceptation en environnement réel.
La poursuite du 23 octobre ci-dessous ajoute un inventaire actuel en lecture
seule, sans déploiement ni nouvelle réussite d'acceptation réelle.
Les huit unités, y compris le complément 5.1, possèdent des preuves d'exécution. Aucun lab n'est entièrement intact. Le lab 6 a déjà été commencé. Un lab essayé n'est pas forcément validé; une tâche d'exécution terminée comme T008 ne signifie pas que chaque assertion de cette exécution a réussi.
Le registre par lab conserve les premières exécutions. Les continuations datées ci-dessous et le rapport backend ajoutent les résultats ultérieurs. La table indique les critères restants, pas une consigne de recommencer chaque lab.
| Lab | Travaux déjà exercés | Critère restant | Tâches de reprise |
|---|---|---|---|
| 0 | Identité, rôles, quota, outils et précontrôle des essais payants | Préparation complète, budget chiffré et revue des ressources | T001,T002,T009 |
| 1 | PDF, refus, annuaire, envoi de courriel et empreinte du PDF | Réponse historique complète, citation originale et erreurs aval | T009 |
| 2 | Ingestion privée du PDF de licences et premiers essais connectés | Navigation de citation PDF et preuve de source connectée actuelle | T010 |
| 3 | Topic natif et événement authentique corrélé dans KQL | Canal publié et limite de confidentialité requise | T010 |
| 4 | Appel direct du modèle et inspection du dialogue BYOM Standard | Conflit clé API/politique sans clé, puis acceptation du prompt | T011,T012 |
| 5.1 | Déploiement payant corrigé, pipeline privé et nettoyage contrôlé | Conserver les écarts; aucune application de source inchangée | T013 terminé; T014,T015 |
| 5 | Récupération, filtres, hôtels et cohortes Search natives fictives | URL/corpus des hôtels et refus natif apparié | T014 |
| 6 | Notebook, embeddings, trois sources, MCP, essais hébergés et natifs | Route native vérifiée, assertions restantes et ressources conservées | T005,T006,T007,T017 |
La réparation hébergée du lab 6 correspond à T003/T004, sa livraison native à
T005/T006 et sa continuation de onze scénarios à T007/T008. T017 réconcilie la
matrice distincte F6-01 à F6-12 avec les exécutions conservées. Cette
correspondance est livrée; le guide distingue preuves exactes et voisines.
Les échecs antérieurs restent conservés, sans promotion implicite en réussites.
Les numéros d'étape ne sont pas ceux des labs : l'étape 6.1 concerne le
BYOM du lab 4, pas le lab 6.
- Choisir un critère ou une tâche non résolu et ses preuves conservées. Préserver les travaux déjà vérifiés; ne pas recréer l'infrastructure ni recommencer tout un lab parce qu'un autre critère est bloqué.
- Avant un nouvel essai réel, consigner le blocage exact et un changement pris en charge ou un prérequis devenu disponible. Figer le résultat attendu et l'intention de soumission unique. Une nouvelle cohorte constitue une tentative distincte, pas une réparation de l'historique.
- Si le même échec persiste, arrêter ce critère, conserver l'échec et vérifier le nettoyage. Sans nouveau diagnostic ou changement pris en charge, ne pas créer une cohorte équivalente ni redemander la même saisie manuelle de secret.
- Avancer sur les critères indépendants. Une nouvelle réponse ne remplace pas l'historique; un contrôle direct/backend ne remplace pas l'acceptation native; les faits de gouvernance et de source ne s'inventent pas.
- Après réconciliation, actualiser les lignes exactes et les preuves bilingues. Déclarer l'atelier terminé uniquement selon la liste finale, pas parce que chaque lab a été essayé.
Une sonde distincte par utilisateur intégré
emploie le choix natif Microsoft Entra ID Integrated et l'espace de noms ai://
documenté dans la référence du connecteur Search.
Un seul Create s'arrête sur l'erreur explicite de popup de consentement bloquée.
OAuth ne se termine pas; Next reste désactivé et le sélecteur ne s'exécute jamais.
Aucun statut HTTP, corps ni corrélation du sélecteur n'est donc disponible.
La documentation du navigateur VS Code
indique que les popups sont bloquées. Effectuer l'OAuth normal dans un navigateur
externe pris en charge avant un nouveau diagnostic borné du sélecteur; ne pas
contourner popups/jetons, répéter les questions ni élargir les permissions.
Le nettoyage vérifie exactement les sept connexions initiales, sans connexion de sonde persistante ni suppression devinée. La comparaison PAC complète à chemins longs conserve 63 fichiers hors jeton, 22 traductions françaises et 49 composants sur deux instantanés de 64 fichiers. Zéro question, source ajoutée, enregistrement, publication ou écriture Azure. Aucun audit continu de l'état externe revendiqué. Ni rejeu ni correction du HTTP 400 antérieur par principal de service. S5-10/T014/T016, principal natif et acceptation de recherche restent ouverts.
Les deux cohortes OAuth isolées
enregistrent chacune une connexion Connected après saisie manuelle du secret et
un seul Create natif. Les deux sélecteurs affichent Something went wrong.,
un HTTP 400 dans la console et Add to agent désactivé. Le corps HTTP est
indisponible; ni cause précise ni principal natif effectif ne sont établis.
Le premier principal possède seulement Search Index Data Reader sur son index
jetable : lacune documentée de lecture des métadonnées, pas cause prouvée du 400.
Le second possède exactement deux attributions vérifiées : Reader sur son seul
index et rôle personnalisé séparé au niveau du service Search existant, avec
uniquement Microsoft.Search/searchServices/indexes/read dans Actions, sans
DataActions, écriture ni operations/read. Ce rôle expose les métadonnées de tous
les index, pas leurs documents. Liste directe et requête de son propre témoin
synthétique réussissent, mais le sélecteur natif échoue encore. L'ajout des
métadonnées n'est pas une correction démontrée.
Aucune source ajoutée, liaison d'index, correspondance de champs ni disponibilité Ready; zéro question native positive, native négative ou de modèle. Ni 403 direct après révocation ni acceptation sans fuite exécutés/prouvés. Connected et contrôles directs ne valent ni acceptation native ni réussite appariée partielle. Le ticket de diagnostic dédié demande un diagnostic pris en charge du sélecteur/GetIndexesSchema et le contrat minimal de permissions, sans affirmer un défaut du service. S5-10, T014 et T016 restent ouverts.
Les deux nettoyages indépendants vérifient zéro ressource possédée restante, révocation/suppression des secrets et suppression des fichiers secrets protégés. Le premier conserve une erreur PAC de filtre d'environnement et une erreur DNS de vérification, récupérées séparément sans répéter la suppression; le second nettoyage contrôlé et sa vérification distincte n'ont aucune erreur. Cinq agents, sept connexions, trois schémas, configuration Search complète, rôles/définitions non possédés, rôles d'embedding, hébergement v5 et 181 fichiers historiques restent exacts. Aucun original, authentification/réseau, mode par clé ou stockage public modifié, aucune publication M365 ni importation ZIP.
L'investigation en lecture seule
suit le nouveau lien Microsoft vers le
modèle de publication.
Elle distingue l'ancienne route Agent Application du point de terminaison stable
de l'agent. Les deux GET de l'agent initial, avec et sans en-tête documenté,
renvoient 200 et des corps complets identiques octet par octet. L'agent possède
déjà point de terminaison, blueprint et identité d'instance, état activé,
dernière version 5, Activity/Invocations et Entra/BotServiceRbac inchangés.
Configuration de protocole et sélection de version sont imbriquées dans
agent_endpoint; l'approbation de publication vaut not_published.
Le nouveau modèle existe donc déjà; ce n'est pas une migration corrective non essayée. Aucun agent, point de terminaison, identité, droit ni sélecteur n'est modifié, et aucune question n'est soumise. La documentation conserve Entra comme alias AzureRbac et distingue accès direct et publication Bot Service. Elle n'établit pas la cause de l'erreur native conservée. Les six échecs de l'ancienne route restent des échecs; T005/T006 et l'acceptation finale restent ouverts.
Une corrélation locale des identités associe l'ID blueprint de l'activité dans l'erreur historique à l'ID objet de l'administrateur approuvé. L'ID du résumé correspond au client blueprint cible, inchangé entre la v3 conservée et la v5 actuelle; le client d'instance est aussi inchangé. Cela localise l'écart observé, sans prouver sa cause amont ni sa correction. Aucune nouvelle requête, question, substitution d'appelant ni modification de droits.
La reprise SP appariée distincte est interrompue avant soumission native : les intentions durables comptent zéro question autorisée et zéro refusée, sans opération en attente ni consommée. La reprise supprime le secret temporaire possédé, application, principal de service, brouillon, quatre rôles, service Search/index et groupe de ressources. Des lectures indépendantes confirment leur absence; aucune création de connexion de connecteur jetable n'a été engagée. Cinq agents initiaux, sept connexions, trois empreintes de schémas Search, récupération hébergée v5 et inventaire complet des rôles de la ressource d'embedding sont préservés. Les 181 fichiers historiques restent inchangés, y compris la suspension antérieure avant création.
L'inventaire du portail natif redirige vers la connexion. L'inventaire PAC officiel et le 404 Dataverse du brouillon sont vérifiés, pas l'absence dans le portail. Aucune connexion, répétition de question, élévation de privilèges ni modification d'authentification partagée pendant la reprise. Coût non finalisé. Ce nettoyage ne valide pas la révocation appariée; S5-10, T014, T016 et l'atelier restent ouverts.
La reprise connectée native
remplace l'ancien blocage de fenêtre OAuth. Le format ai:// documenté échoue
au test natif et ne sauvegarde aucune connexion. Un essai HTTPS distinct réussit
avec OAuth réel. Un brouillon Standard isolé, non publié, associe uniquement
l'index fictif Harbor/Forest de deux documents; connaissances Ready.
Des sauvegardes natives et clones officiels indépendants vérifient recherche
web et connaissances générales désactivées, sans modifier modèle,
authentification ou rubriques initiales.
La première cohorte figée réussit 3/4 : la question française reçoit une
réponse anglaise malgré des faits et citations corrects. Cet échec est conservé.
Aucune langue secondaire n'était configurée. Seul l'ajout du français modifie
la configuration; la langue française du panneau de test est ensuite choisie.
Une cohorte figée distincte réussit 4/4 : Harbor ouvre à 07:00, Forest
ferme à 21:00, le prix de navette absent provoque une abstention explicite,
et la réponse française conserve chaque fait avec sa citation réelle.
Les huit conversations distinctes présentent des traces Search natives et des
citations correspondant aux passages récupérés. Aucune question n'est rejouée
automatiquement et les configurations ne sont pas fusionnées pour l'acceptation.
La détection automatique de la langue saisie n'est pas démontrée.
Huit archives de diagnostic officielles restent privées. Celle du vélo dans
la reprise contient une configuration vide; les trois autres configurations
de reprise concordent. Les clones indépendants avant/après confirment les
17 fichiers YAML d'auteur identiques. Le validateur officiel échoue encore :
Cannot find module '@azure/msal-node-extensions'. La réussite du portail
et des relectures ne vaut pas validation de schéma YAML; aucun bundle modifié.
Un vrai clic de citation native ouvre la source fictive publiée immuable dans un nouvel onglet, avec les deux faits exacts visibles; le navigateur omet le fragment de section. S5-04/S5-07/S5-08/S5-09 réussissent uniquement dans ce périmètre fictif natif. Brouillon, connexion et index temporaires supprimés, avec absences vérifiées indépendamment, cinq identifiants d'agents antérieurs, sept lignes nom/connecteur/statut de connexion et trois empreintes de schémas Search initiaux préservés. Navigateur possédé fermé normalement; aucune ressource ARM, aucun rôle, stratégie ou paramètre d'authentification initial modifié. URL/corpus hôteliers originaux et test réel d'identité refusée restent ouverts. T014, critères de livraison/gouvernance et atelier complet restent non terminés.
Le test Search distinct sans clé
échoue à S5-10 : la référence native autorisée réussit, mais l'unique question
native suivante renvoie Harbor 07:00 et sa vraie citation après HTTP 403
sur les requêtes Search directes. Seul un nouveau rôle Reader possédé sur
l'index isolé est retiré; aucun droit administrateur initial n'est modifié.
Le même administrateur est utilisé, pas une identité indépendante non privilégiée.
La trace native contient deux documents fictifs sans erreur Search.
Principal natif effectif et cause restent non établis.
L'expiration de lecture est conservée; l'instantané officiel de la conversation existante est récupéré sans rejouer la question. Les deux configurations concordent; un clone indépendant vérifie les 17 fichiers d'auteur inchangés. Tous les objets possédés, dont service Search facturable et rôle d'embedding sur le compte existant, sont supprimés avec contrôles indépendants. Agents, connexions, compte/rôles d'embedding et schémas Search initiaux préservés; navigateur possédé fermé normalement. Coût réel non finalisé. La cohorte fictive antérieure 4/4 reste inchangée. S5-10, T014 et T016 restent ouverts.
L'examen d'identité ultérieur en lecture seule trouve une connexion Search réussie de l'administrateur approuvé avant le retrait. L'événement Search natif arrive environ 165 secondes après l'intention de suppression, pas après un achèvement de suppression mesuré. La documentation RBAC générale prévoit jusqu'à dix minutes de propagation. Ni délai ni connexion ne prouvent la cause de l'échec ou le principal effectif de la requête; les diagnostics Search n'exposent pas l'identité accédante.
Le contrôle préalable de retrait
refuse désormais les précontrôles natifs prématurés. Depuis la racine du dépôt,
exécuter python scripts\check_revocation_readiness.py <private-preflight.json>.
Il exige GET indépendant du rôle à 404, requête directe à 403, principal de
connexion natif vérifié et conversation neuve, avec horodatages à décalage UTC
ordonnés : retrait confirmé, au moins 600 secondes, authentification de connexion,
refus direct, puis nouvelle conversation. L'intention de suppression ne remplace
pas son contrôle indépendant. Ce contrôle valide uniquement les preuves fournies,
pas le refus natif ni un délai contractuel de révocation. La question historique
échouée n'est ni rejouée ni reclassée.
Les champs JSON sont assignmentGetStatus, directQueryStatus,
nativeConnectionPrincipalVerified, freshConversationVerified,
revocationVerifiedAtUtc, nativeConnectionAuthenticationVerifiedAtUtc,
directQueryVerifiedAtUtc et freshConversationVerifiedAtUtc.
Utiliser des contrôles indépendants réellement enregistrés, pas des dates estimées
ou inventées. Refus direct et contrôle de conversation doivent dater d'au plus
120 secondes au lancement; ce seuil local de fraîcheur n'est pas un engagement
contractuel du service.
Le nouveau précontrôle de refus différé utilise un nouveau service Search Basic sans clé et les deux mêmes documents fictifs. Référence directe autorisée et vectorisation réussissent. Le retrait du rôle Reader possédé est confirmé indépendamment à 404; l'attente réelle atteint 600,001 secondes avant la création d'une nouvelle connexion Entra formelle. Les requêtes directes suivantes renvoient 403. Un nouveau brouillon Standard non publié lie uniquement cet index, atteint Ready et conserve les instructions limitées aux sources, avec Web et connaissances générales désactivés.
Les lectures Graph interactives et non interactives bornées n'établissent pas de nouvelle connexion Search réussie. Les métadonnées du compte ne remplacent pas la preuve du principal; aucun horodatage d'authentification n'est inventé. Le contrôle exécutable renvoie BLOCK. L'export officiel confirme zéro question utilisateur et zéro exécution de source, avec seulement l'accueil affiché. Ready n'est pas une acceptation de requête; l'absence de preuve d'audit n'établit ni échec d'authentification ni cause. Ce n'est ni un test natif autorisé puis révoqué apparié, ni une réussite S5-10.
Brouillon, connexion, quatre rôles, Search/index et groupe possédés sont supprimés. Une lecture distincte du parent vérifie GET 404 pour les deux objets ARM et les quatre rôles, ainsi que l'identité exacte des cinq lignes d'agents, sept lignes de connexions, compte/rôles complets d'embedding et trois schémas d'origine. Les deux générations de navigateur possédées ferment normalement, sans commande en attente. Coût réel non finalisé; les ressources de l'atelier ne sont pas déclarées absentes. L'échec historique est inchangé; S5-10, T014 et l'acceptation de l'atelier restent ouverts.
Une lecture distincte ultérieure à 00:57:46 UTC trouve une connexion réussie du connecteur Search pour l'administrateur approuvé, horodatée 00:36:59 UTC, dans la fenêtre d'authentification de cette cohorte terminée. Les lectures bornées antérieures ne l'avaient pas établie; le délai exact de disponibilité de l'audit n'est pas mesuré. Le reçu conserve séparément les deux observations. Cette lecture n'écrit ni ressource ni permission, ne pose aucune question native et ne recrée pas la cohorte supprimée. Elle ne valide pas rétroactivement son contrôle et n'établit aucun résultat de requête native. Une future cohorte doit établir sa propre preuve d'authentification, pas réutiliser cet événement.
La nouvelle reprise contrôlée pose la question d'heure de fermeture exactement une fois dans une autre cohorte fictive isolée. Sa référence directe autorisée réussit. Le retrait Reader est confirmé à 404, puis 600,002 secondes s'écoulent avant la nouvelle connexion. La connexion réussie du connecteur de cette cohorte est observée indépendamment avant le test; aucune preuve d'authentification d'une cohorte supprimée n'est réutilisée.
Le contrôle public inchangé réussit immédiatement avant la soumission. La preuve
403 directe date de 38,226 secondes, et le contrôle de conversation neuve de
0,136 seconde. Search natif renvoie ConnectorRequestFailure / AzureAISearchClientError, avec zéro document renvoyé/vérifié et zéro citation.
La trace native n'expose aucun statut HTTP; aucun HTTP 403 natif n'est prétendu.
La réponse complète du parent est : « I'm sorry, I'm not sure how to help with
that. Can you try rephrasing? » L'interface affiche aussi « No information was
found that could help answer this. » Aucun fait source n'est renvoyé, mais une
erreur parent spécifique aux permissions n'est pas établie.
C'est une référence directe autorisée suivie d'un refus natif dès le premier usage, pas un test natif autorisé puis révoqué apparié ni une identité indépendante non privilégiée. Ni principal effectif par requête, ni cause historique, ni acceptation S5-10/T014 ne sont établis. L'échec antérieur et le précontrôle bloqué ne sont pas reclassés; aucune acceptation n'est combinée entre cohortes. Export officiel et configuration d'auteur inchangée sont conservés. Brouillon, connexion, quatre rôles, Search/index et groupe possédés sont indépendamment absents; une lecture du parent confirme les cinq lignes d'agents, sept lignes de connexions, compte/rôles complets d'embedding et trois schémas initiaux exacts. Le navigateur possédé ferme normalement, sans commande en attente. Coût réel et critères plus larges de l'atelier restent ouverts.
Le suivi en lecture seule de l'historique original distingue authentification d'annuaire rétablie et autorisation Dataverse. Le défi CAE Graph et l'expiration de la connexion navigateur normale restent consignés. Une lecture Graph indépendante ultérieure réussit pour l'administrateur approuvé; rôle Global Administrator et abonnement approuvé vérifiés. Aucune connexion par code d'appareil ne démarre; cause et délai exact du rétablissement ne sont pas établis.
La lecture administrative de l'environnement Power Platform réussit, mais la
requête de transcriptions limitée à l'agent original renvoie 403, faute de
prvReadconversationtranscript. Après rétablissement, les rôles directs restent
Basic User et Environment Maker; les droits de lecture des transcriptions et de
création/attribution des rôles restent absents. Un nouvel audit des cinq privilèges
définis réussit sans reclasser une assertion antérieure incomplète qui demandait
un nom de privilège inexistant. Aucun rôle ni politique de transcription n'est
modifié et aucune auto-élévation générale n'est tentée.
L'exécution History exacte du 19 octobre affiche encore In progress, l'accueil et la question originale, sans réponse complète. Aucune question rejouée, réponse historique reconstruite ou réponse plus récente substituée. T009 reste ouvert; une lecture administrative du tenant ne valide ni accès aux transcriptions ni exactitude historique.
Le suivi History des licences d'origine retrouve la question exacte du 19 octobre dans l'agent original. L'exécution reste In progress, sans réponse complète exposée, y compris après une seule actualisation normale. Aucune réponse n'est reconstruite. Un historique terminé du 24 octobre contient une autre question et ne remplace pas l'audit original. Ses neuf citations intégrées ont des destinations vides; un clic normal n'expose ni dialogue source, lecteur PDF, téléchargement ou nouvel onglet. Seuls des contrôles d'interface changent. Le PDF approuvé conservé est inchangé. Aucune nouvelle question ni écriture de configuration; le navigateur détenu ferme normalement. T009 reste ouvert.
Le point de publication wiki
constate la destination publique réelle sans changer sa visibilité. Les 133
fichiers wiki déjà suivis correspondent à l'ancienne référence canonique générée;
aucune modification humaine divergente n'est écrasée. L'instantané bilingue
validé de 38 pages est envoyé normalement sur la véritable branche master.
Lectures distantes indépendantes et pages anglaises/françaises rendues vérifient
la publication, dont la régression incomplète 10/11. Le premier échec d'ouverture
anglaise et sa récupération par navigation normale restent conservés.
Cela termine la partie publication, pas T016 ni l'acceptation de l'atelier.
Preuves privées et PDF originaux ne sont pas publiés.
Le nouvel inventaire ciblé vérifie indépendamment administrateur, locataire et abonnement approuvés, puis lit six ressources ARM précisément détenues : compte/projet Foundry, Search et Bot conservés, plus l'App Service MCP isolé et son plan B1. Les provisionnements réussissent et le site est Running. Ce n'est pas un nouvel audit de chaque modèle, définition hébergée, autorisation d'identité ou ressource du locataire.
La requête de facturation filtrée reçoit d'abord HTTP 429. Une reprise distincte, enregistrée après temporisation, réussit; l'échec original reste conservé. Elle rapporte 11,26126391 USD avant taxes, du 20 octobre à l'heure limite de la requête du 25 octobre. Seuls deux des six identifiants ont des lignes de coûts publiées. Ce n'est ni une facture finale ni la dépense actuelle complète; l'absence de ligne ne signifie pas gratuité, et les crédits Copilot sont exclus. Aucune configuration, inférence ou question native pendant cet inventaire.
Le formulaire de gouvernance renvoie uniquement l'indisponibilité de l'utilisateur, pas de responsable, date de revue, budget chiffré ni accords attribuables aux rôles Product Owner/Security/Tech Lead. Rien n'est inventé. T001/T002 et les validations de livraison dépendantes restent ouverts; l'autorisation générale de déploiement et dépenses est conservée, sans nouvelle demande.
La connexion administrateur assistée par l'utilisateur réussit désormais. Le reçu de récupération du candidat conserve la vérification indépendante de l'identité/environnement PAC, le clone officiel et les envois ciblés du brouillon. Cela remplace les anciens blocages d'authentification/clonage ci-dessous, pas l'échec de dépendances du plugin. Aucune stratégie n'est contournée.
Le premier test natif des recherches strictes échoue : l'orchestration choisit Search sources au lieu de la rubrique prévue. Une lecture indépendante trouve aussi des identités CTR/SAR distinctes avec deux dialogues CTR identiques. La cause de la copie intermédiaire reste inconnue; les preuves ne permettent pas de l'attribuer à PAC. Cet échec reste inchangé.
Author corrige les deux rubriques avec des conditions de message étroitement
ancrées, des réponses littérales et une fin explicite de conversation. Huit tests
locaux et 31 contrôles de schéma réussissent. Les trois fichiers modifiés
correspondent au clone distant indépendant. Le
test natif corrigé
réussit les cas CTR, délai SAR restreint et accueil sans source, une fois chacun.
Les 12 valeurs locales, attributions individuelles, conditions et avertissements
d'instantané correspondent. Ces instantanés ne sont ni une recherche réelle ni
une réparation de navigation native des citations; les traces de rubrique et
DynamicPlanFinished ne sont pas exposées.
La régression SAR générale préserve le routage spécialiste mais échoue en fidélité et couverture. Une correction des seules instructions parent réussit 33 contrôles locaux et sept contrôles de schéma, puis est envoyée et relue exactement. Son test natif corrigé distinct réussit routage et couverture sur deux messages visibles, mais seulement 15/16 citations sont exactes. Une limitation provisoire contredit aussi l'exception d'abus interne récupérée ensuite localement. Une synthèse finale correcte n'efface pas les erreurs déjà affichées. Le schéma installé de l'action Activity externe ne fournit aucun paramètre pris en charge pour supprimer ou capturer ces messages. Aucun YAML non pris en charge ni changement du récupérateur protégé n'est appliqué. Un contrat documenté de preuves sans émission reste un prérequis d'intégration, pas un substitut implémenté ou accepté.
Les régressions du brouillon final réussissent encore CTR, SAR restreint et accueil 3/3, avec une seule réponse finale chacun, sans paraphrase supplémentaire ni reprise. La préservation indépendante vérifie le parent d'origine et ses 26 lignes complètes de composants inchangés. Le candidat a exactement 28 composants : deux rubriques possédées et une modification limitée aux instructions existantes. Diagnostic Off, deux spécialistes On, date de publication, authentification/accès/déclencheur 2/2/1, quatre empreintes de fichiers et deux liaisons approuvées sont préservés. Aucune publication n'a lieu.
T007/T008 restent ouverts pour la fidélité de toute la sortie et la matrice de onze cas. Autorisation du diagnostic hébergé natif, navigation réelle du Lab 1, provenance de sa réponse historique, restauration du Lab 2, autres critères connectés, propriété/budget de rétention et accords attribuables restent distincts.
Le contrôle réel de l'assistant du tenant trouve Streamable HTTP et la configuration OAuth manuelle pour le candidat. Il est annulé sans identifiants saisis, connexion créée ni autre question native. Aucune réponse de conception indisponible n'est comptée comme accord humain; le travail local isolé continue sous l'autorisation existante.
Un point d'entrée MCP facultatif réutilise la récupération et le rendu vérifiés sous forme d'outil de données structurées, sans envoyer d'activités de conversation. Toute écoute hors boucle locale exige la configuration Entra complète : tenant, audience API, clients OAuth/utilisateurs autorisés et portée déléguée. Les tests de jetons signés et de protocole HTTP réel couvrent refus, provenance, sortie littérale, abstention, limites du parseur/corps et annulation. Le point d'entrée Activity/Invocations et le manifeste de production restent inchangés.
La preuve MCP locale réelle
utilise le client officiel et une question SAR d'origine inchangée, sans reprise.
Elle renvoie deux documents exacts, rc-002 et ip-006, texte identique au rendu
et provenance structurée; la définition du récupérateur protégé est identique
avant et après. Cela valide le contrat de données local, pas OAuth MCP Entra réel,
le déploiement MCP distant, la liaison candidat ou la fidélité native complète.
Aucune ressource Azure supplémentaire n'est créée pour cette preuve locale.
La poursuite hébergée suivante remplace sa limite de déploiement distant.
Le contrôle hébergé
vérifie maintenant un App Service Python 3.13 distinct : HTTPS uniquement,
TLS 1.2 minimum, FTP désactivé et deux stratégies de publication basique
désactivées. Les jetons absents ou invalides reçoivent chacun 401; la découverte
de ressource protégée renvoie 200, avec tenant, ressource et portée
Evidence.Read attendus. Le paquet autorisé contient cinq fichiers Python et
deux manifestes de dépendances, sans identifiants, environnement, cache ni tests.
Le déploiement Foundry d'origine reste intact.
Deux inscriptions possédées à tenant unique séparent API et client connecteur. Seule la portée déléguée dédiée est demandée, sans permission Graph ni accord pour tout le tenant. Le serveur sélectionne explicitement son identité managée pour les appels sortants, avec un rôle OpenAI User limité au compte existant. La configuration est relue; à ce contrôle préalable, accès délégué réel et récupération par identité managée ne sont pas encore vérifiés. La poursuite d'exécution suivante remplace uniquement la limite de récupération sortante. Le secret client de sept jours reste dans DPAPI de l'utilisateur courant; l'entrée PAC est protégée par droits d'accès et supprimée après usage.
PAC officiel crée un seul connecteur MCP après correction du premier échec local de longueur de titre. Son entrée native réelle et son rappel OAuth unique généré sont relus indépendamment; ce rappel est inscrit puis vérifié sur le client possédé. La première tentative échouée reste conservée.
L'administrateur du navigateur est confirmé indépendamment, mais la fenêtre de consentement de connexion native est bloquée. La documentation du navigateur VS Code confirme que les fenêtres contextuelles sont bloquées et les nouveaux onglets autorisés. Un flux normal code d'autorisation/PKCE dans un nouvel onglet atteint la demande de mot de passe de l'administrateur prévu. L'outil de réponse humaine signale une indisponibilité, pas un accord ni une connexion réussie. L'auxiliaire local borné est arrêté, son port est vérifié fermé et son rappel temporaire est supprimé; le rappel réel du connecteur reste préservé. Aucun nouvel appel MCP payant, question native ni liaison candidat n'a lieu.
La nouvelle lecture de préservation vérifie encore les 26 lignes d'origine, les mêmes 28 composants candidat, empreintes d'auteur exactes, fichiers, liaisons et états Off/On/On. Le récupérateur protégé, la définition hébergée courante en version 5 et ses identifiants de principal/client correspondent aussi. Aucune modification de stratégie/réseau Storage ni publication n'a lieu.
Le plan Linux B1 distinct en Sweden Central reste actif et facturable. L'estimation publique de calcul est de 0,018 USD/heure, pas une facture réelle, un total de crédits Copilot ni un budget numérique approuvé. Responsable/date de revue de rétention et accords attribuables restent absents.
Ce relais prévoyait initialement un consentement de preuves limité à l'utilisateur dans un navigateur autorisant les fenêtres contextuelles. L'approbation explicite ultérieure pour tout le tenant, consignée ci-dessous, remplace cette limite prévue. Les reçus historiques restent inchangés; l'autorisation de déployer seule ne vaut pas consentement pour tout le tenant.
La preuve réelle d'exécution hébergée
réussit maintenant la question SAR d'origine inchangée dans le conteneur
applicatif App Service, pas dans le conteneur de déploiement distinct.
Signature Microsoft, tenant et identité possédée sont vérifiés sans conserver
les jetons. La chaîne d'identifiants contient uniquement l'identité managée;
les cinq empreintes du code déployé et la configuration de récupération
correspondent aux références. Les deux documents renvoyés, rc-002 et ip-006,
et leur texte complet correspondent indépendamment au corpus épinglé.
Le récupérateur protégé reste identique avant et après.
Deux tentatives réelles antérieures restent conservées comme échecs HTTP 403.
La lecture d'une réponse existante identifie agents/read; des sondes sans
inférence distinguent propagation des droits et réussite réelle.
La route Responses du projet exige les deux actions de données du rôle de
compatibilité :
Microsoft.CognitiveServices/accounts/AIServices/agents/read et
Microsoft.CognitiveServices/accounts/AIServices/agents/write.
L'action d'écriture permet aussi de modifier des agents; aucune requête de
modification d'agent n'est effectuée. Seule cette attribution personnalisée
limitée au projet reste sur l'identité applicative possédée. Le rôle de modèle
limité au compte et les deux attributions d'essai runtime/consumer sont supprimés
puis relus indépendamment. Aucun droit Foundry User/Owner, Storage ou Search
n'est ajouté.
La nouvelle préservation native vérifie encore les 26 lignes d'origine, 28 composants candidat, contenu d'auteur exact, fichiers, liaisons, authentification et états Off/On/On. Les jetons entrants absents/invalides reçoivent toujours 401. Il s'agit de la récupération partagée sous l'identité sortante réelle, pas d'une connexion MCP déléguée réussie, d'une liaison candidat ni d'une réussite native complète. Aucune question native ni appel d'outil MCP nouveau n'est soumis. T007/T008, la matrice native de onze cas et la feuille de route restent ouverts.
La poursuite MCP native
vérifie maintenant l'administrateur prévu dans un profil Edge dédié, une vraie
connexion OAuth et le statut PAC Connected indépendant. L'utilisateur confirme
explicitement le consentement pour tout le tenant. Graph vérifie
AllPrincipals, aucun principal individuel et uniquement la portée dédiée
Evidence.Read. L'assistant n'effectue aucune écriture de consentement Graph.
Aucun profil ni cookie existant n'est copié; aucune stratégie npm ou de sécurité
du navigateur n'est contournée. Les reçus antérieurs sans consentement ou limités
à l'utilisateur restent historiques.
Après l'interruption Add/configure, la lecture indépendante retrouve toujours
28 composants candidat. La commande sans acquittement est archivée, pas rejouée.
La poursuite native réactive enregistre ensuite un composant MCP et découvre
retrieve_verified_workshop_evidence. Dataverse vérifie indépendamment la liaison
ModelContextProtocolMetadata générée avec les connecteur et connexion exacts.
Le candidat compte maintenant 29 composants.
Author remplace le routage de récupération émetteur du candidat par l'outil MCP
de données, avec récupération locale conservée pour SAR large et demandes hybrides.
L'interface native enregistre les instructions validées et désactive uniquement
l'ancien spécialiste de récupération. La lecture vérifie les instructions exactes,
les autres champs et toutes les autres définitions/états inchangés, diagnostic Off,
validation On et MCP On. Le parent original et ses 26 lignes complètes restent
inchangés. Le bundle de gestion échoue avec
MODULE_NOT_FOUND: @azure/msal-node-extensions; aucun correctif du bundle.
L'interface native prise en charge est utilisée.
Une soumission native fraîche du cas 6 d'origine inchangé produit une seule
réponse métier, sans le brouillon supplémentaire antérieur du spécialiste.
Les deux citations sont exactement les documents épinglés complets rc-002 et
ip-006, avec leurs marqueurs canoniques individuels exacts. La recherche locale
réelle et sa référence native sont visibles. Exceptions de seuil, formulaire,
délais conditionnels, couverture narrative et d'enquête, activité continue et
limites d'applicabilité réussissent le contrôle du tour complet. L'accueil et
la carte de consentement de connexion restent conservés dans la capture.
Les jetons absents ou malformés reçoivent encore 401. Aucune publication ni
modification Storage/réseau. Cela résout le défaut SAR natif borné, pas la
matrice complète : DynamicPlanFinished brut, onze cas frais, contrat du
diagnostic/SDK original, autres labs, budget/rétention et validations attribuables
restent ouverts. T007/T008 et la feuille de route ne sont pas déclarés terminés.
La matrice native initiale
réussit les cas d'origine 1-4, puis s'arrête au cas 5 : sept puces factuelles
n'ont pas de marqueur individuel. Les exports natifs officiels distinguent la fin
des topics déterministes 1-3 de DynamicPlanFinished non annulé pour les cas
génératifs. La découverte de capacités ne compte pas comme appel de preuves.
La correction d'attribution enregistrée par Author réussit un cas 5 frais : trois paragraphes factuels individuellement sourcés. Le tour SAR suivant échoue sur l'attribution : une notice d'applicabilité ajoutée par le moteur de rendu est citée comme un document source. La correction de frontière enregistrée supprime cette erreur et préserve deux citations MCP complètes exactes, mais le tour SAR suivant échoue sur la ponctuation locale. Un point ajouté dans une cellule locale citée n'est pas une citation exacte.
Aucune question échouée n'est automatiquement rejouée ni certifiée. Le dernier tour contient deux appels de preuves terminés avec la question inchangée, pas deux soumissions utilisateur; tous deux sont comptés et leurs documents vérifiés. Les faits locaux générés nécessitent des paraphrases sans guillemets, avec référence; les topics déterministes littéraux restent inchangés. Chaque modification d'instructions impose une cohorte fraîche de onze cas, sans fusion des réussites de configurations différentes. T007/T008, publication et feuille de route globale restent ouverts.
La matrice native complète remplace la limite de matrice précédente, pas ses échecs historiques. Les onze questions d'origine inchangées réussissent sur une seule configuration enregistrée. Réponses finales complètes, exports officiels, comparaisons de sources et revues sémantiques directes restent privés. Les treize exports du contenu agent, incluant une tentative échouée et le contrôle indépendant, ont le même SHA-256.
Douze soumissions de questions d'origine sont comptées : le cas 7 ne reçoit initialement aucune réponse métier ni plan dans l'attente bornée. Son message utilisateur réel et son export échoué sont conservés. La préservation exacte et les contrôles 401 réussissent, puis un rechargement normal du portail et une session fraîche acquittée précèdent une reprise réussie, comptée explicitement. Aucune cause plateforme n'est inventée ni tentative échouée effacée.
Les cas 1-3 conservent la fin des topics déterministes et douze citations locales
exactes. Les cas 4-11 conservent DynamicPlanFinished réel non annulé. Les sept
appels MCP métier transmettent les questions complètes inchangées et retournent
les documents/preuves rendues exactement épinglés. Le SAR large et les quatre
hybrides prouvent aussi la contribution du composant Markdown chargé prévu et sa
référence native réelle. Les réponses finales utilisent des paraphrases vérifiées,
attribuées individuellement, pas de prétendues citations MCP littérales.
T008 est terminé pour cette exécution. T007 reste ouvert pour le contrôle de validation distinct : le topic inchangé, puis l'action directe, produisent deux réponses constantes identiques. Les deux sont conservées; le transport réussi ne certifie pas une réponse unique. Parent original et 26 lignes complètes, 29 composants candidat, autres définitions/états, authentification et date de publication restent préservés. Aucune publication, modification de stratégie, nouvelle ressource ou rôle. Contrat diagnostic/SDK original, autres labs et gouvernance restent ouverts.
La régression après correction du contrôle ne modifie que le topic de contrôle démontré, par un seul enregistrement natif normal. La condition exacte d'Author conserve l'action existante et ajoute l'annulation avec activité traitée. Après un délai dépassé conservé et une reprise comptée séparément, les traces prouvent une invocation réelle, une liaison et une réponse exacte. Deux traces d'annulation ne sont pas deux invocations. Aucune réponse de succès codée en dur n'est ajoutée.
La nouvelle régression requise accepte 10/11 cas d'origine distincts, pas les onze. Le cas 9 termine d'abord les deux recherches prévues et un plan non annulé, sans réponse parent pendant 240 secondes. Sa reprise protégée ne produit ni plan ni réponse. Les deux exports officiels restent des échecs; aucune cause n'est établie et aucune troisième tentative n'est soumise. Les cas 10 et 11 réussissent leurs propres audits complets de sources, attribution, couverture et applicabilité.
Treize questions d'origine et deux contrôles totalisent quinze soumissions. Les reprises métier concernent les cas 2 et 9. La première réponse visible du cas 2 perd son export officiel lors d'un verrouillage du contrôleur et n'est pas acceptée. La commande d'export non lue est isolée, jamais rejouée. Les quatorze exports disponibles du contenu agent sont identiques. Sept appels MCP réels incluent l'appel de preuves réussi du cas 9 sans réponse. Le cas 7 actuel contient deux citations MCP exactes attribuées et un apport local supplémentaire permis et vérifié.
La lecture finale préserve parent original/26 lignes complètes, 29 composants candidat, toutes les autres lignes complètes, instructions, authentification et date de publication. Le navigateur détenu ferme normalement. Aucune publication, nouvelle ressource, déploiement Azure, attribution de rôle, autorisation ou modification de stratégie. T007 reste ouvert pour la régression actuelle incomplète; T008 conserve uniquement son exécution précédente acceptée. Les réussites de configurations différentes ne sont pas combinées.
Ce point antérieur conserve ses limites historiques de navigateur et d'authentification; la poursuite ci-dessus les remplace pour le candidat.
La livraison de transport vérifiée ajoute Invocations sans état au serveur Activity déterministe existant. La version 4 réussit d'abord la question SAR inchangée localement et à distance. La version 5 rejette explicitement les limites du parseur JSON; les 54 tests du service et les contrôles de dépendances réussissent. Le CLI de déploiement expire après l'enregistrement du service, mais des lectures indépendantes trouvent la version 5 active; doctor retourne 11 réussites, zéro échec et deux contrôles ignorés. Aucun déploiement n'est répété après cette expiration.
Les réponses SAR locales et hébergées finales correspondent exactement au rendu de deux documents. Sept contrôles hébergés réussissent : HTTP 401 sans jeton, OpenAPI authentifié, HTTP 400 pour entrée vide et limite d'entier JSON, HTTP 413 pour corps trop grand, abstention astronomique et compatibilité Activity. Les journaux corrélés excluent les appels de modèle pour les trois entrées authentifiées invalides. Le premier appel Activity direct omet la version API désormais requise et retourne HTTP 400; un appel corrigé distinct, protégé contre la répétition, retourne HTTP 200 avec rendu exact des sources. Aucune identité native ni sémantique de charge utile n'est modifiée.
Les deux protocoles, Entra plus BotServiceRbac, l'identité hébergée, le récupérateur d'origine en version 4 et les quatre ressources/rôles d'origine sont vérifiés. Le contrôle de préservation native préserve aussi les deux parents, définitions, empreintes des fichiers, liaisons approuvées, autorisations déléguées, cache possédé et profil PAC. Aucune stratégie Storage ni configuration réseau n'est modifiée. Réponses brutes et secrets restent privés.
T005 et l'acceptation native/matrice complète restent ouverts. La page partagée existante reste masquée; activation normale et clics du menu de compte ne rendent pas l'interface utilisable. Aucune nouvelle question native ni écriture de configuration. Le jeu d'évaluation généré supplémentaire est différé pendant l'indisponibilité de l'utilisateur, sans choix ni accord inventé. Responsable de rétention, date de revue, budget chiffré et validations organisationnelles attribuables restent manquants.
La livraison vérifiée est poussée sur main au commit 1f41cd6. La
nouvelle investigation de protocole
rétablit la visibilité normale du navigateur et vérifie indépendamment
l'administrateur attendu du site. Le catalogue montre toujours dix opérations
anciennes, sans Invocations/Responses hébergés. L'aperçu application n'expose
aucun contrat de paramètres avant configuration; il est annulé et Tools reste
vide. Ni absence côté backend ni cause de migration n'est prouvée.
Un contrôle de citation locale native utilise le cas CTR 2 inchangé sur le candidat fraude isolé. Réponse parent finale visible et dialogue de source cliquable sont observés, mais le passage affiché ne justifie pas le seuil. Il s'agit d'un défaut d'ancrage du candidat, pas du test d'acceptation du PDF de licences du Lab 1. Aucun événement runtime de fin de plan, audit de réponse historique complète ou corps d'erreur de connecteur n'est établi. Aucune configuration n'est modifiée.
La préparation d'édition limitée au candidat est bloquée avant clonage :
Manage signale son skill requis copilot-studio:manage-agent indisponible.
Aucun YAML n'est inventé, aucune configuration distante modifiée ni parent
d'origine touché. T005/T007 et T009 restent ouverts; contrat du connecteur et
outillage de gestion pris en charge doivent être rétablis avant correction.
La récupération de gestion
retrouve les instructions installées et exécute le bundle de clonage inchangé.
Il échoue avec MODULE_NOT_FOUND pour @azure/msal-node-extensions.
PAC permet le clonage, mais son identité actuelle appartient à un autre tenant;
ni authentification ni scripts installés ne sont modifiés. L'extension expose
une commande de clonage, sans outil appelable ici. Le choix humain demandé
reste indisponible; cela n'autorise pas le contournement de la limite documentée
pour les erreurs du script.
Le contrôle du véritable Lab 1 vérifie le conseiller existant et le PDF Ready. Une question inchangée recherche le guide attendu; deux passages correspondent aux pages physiques 6–7. Le clic sur la source PDF n'expose ni lecteur, ni détails, ni ancre observable : l'acceptation de navigation échoue. Ce résultat ne réutilise pas le contrôle fraude et ne certifie pas l'ancienne réponse complète.
Le contrôle d'inventaire du véritable Lab 2 ne trouve aucun agent permis configuré et identifié sans ambiguïté; les preuves conservées enregistrent la suppression antérieure de la source/connexion Search. Aucun agent de substitution, question nouvelle ou clic de citation. T010 reste bloqué, pas réussi. T009/T010 et l'édition du candidat nécessitent le rétablissement des prérequis pris en charge; aucune source, identité, autorisation ni réussite n'est inventée.
La récupération des dépendances retrouve ensuite le setup SessionStart et le
manifeste officiel des dépendances natives du plugin. Le répertoire de données
contient le manifeste, mais aucun des trois paquets requis. L'installation
normale et l'alternative du cache hors ligne échouent avec EALLOWREMOTE :
le téléchargement des paquets de type distant est désactivé. Aucun registre,
source de paquet ni stratégie n'est contourné. Ce blocage d'installation
n'autorise ni modification du bundle ni réutilisation du mauvais tenant.
L'audit historique local du Lab 1 vérifie empreinte, édition et pagination du PDF approuvé conservé, mais ne retrouve pas la réponse complète du 19 octobre avec provenance correspondante. Ni captures partielles ni réponses plus récentes ne la remplacent. Les totaux de faits restent inconnus; le critère historique reste indisponible, pas réussi.
La nouvelle récupération d'authentification prise en charge confirme indépendamment la présence du commit sur GitHub. La mise à jour officielle du plugin réussit, mais la version 1.0.11 est déjà la plus récente. L'authentification PAC interactive ne termine pas; l'option utilisateur seul exige explicitement un mot de passe, qui n'est pas fourni. Deux tentatives bornées de code appareil atteignent la page de saisie, mais clic et clavier normaux ne la font pas avancer. Le navigateur reste masqué malgré l'activation normale. Aucun écran MFA ni consentement n'est observé; aucune cause n'en est déduite. Les deux processus sont arrêtés, la page partagée retourne à Agents et les profils PAC initiaux restent intacts. Aucun code/jeton, contournement de stratégie ni profil administrateur non vérifié n'est utilisé pour cloner.
Les nouveaux contrôles Azure en lecture seule vérifient séparément administrateur/tenant dans les extensions Azure et Azure CLI; ils ne prouvent pas l'identité du site dans le navigateur. Les quatre ressources ARM conservées sont présentes. Les deux déploiements de modèles sont Succeeded en Sweden Central. Les compteurs exacts renvoient 26 sur 5 000 pour le chat et 1 sur 1 000 pour l'embedding, libellés en milliers de jetons par minute. Search Basic fonctionne en West US 2 avec un réplica/partition, identité système et authentification locale désactivée. Les quatre fournisseurs requis sont inscrits; un GET distinct vérifie Insights en minuscules après son omission par le filtre de liste sensible à la casse.
Cost Management rapporte désormais 7,650361288 USD avant taxes pour les quatre identifiants de ressources conservées et leurs descendants, dont 7,373 USD pour Search, du 20 au 24 octobre partiel. Aucun coût de ressource étrangère à l'atelier n'est inclus. La remontée peut être retardée : ce n'est ni une facture finale ni un total de crédits Copilot. Aucune inférence, nouvelle question, écriture de configuration, modification de rôle/stratégie, inscription de fournisseur, modification de facturation ou suppression. T001/T009 restent ouverts pour responsable, échéance, budget numérique, crédits du tenant et autres critères d'acceptation.
Microsoft Graph vérifie indépendamment l'administrateur actuel et renvoie quatre enregistrements de licences, dont sept plans filtrés liés à la création en provisionnement Success. Ces attributions ne prouvent pas l'ensemble des droits premium, les crédits du tenant ou une liaison de facturation de l'environnement.
Le contrôle préalable d'application
examine une autre route prise en charge, sans rejouer le diagnostic natif échoué.
Les métadonnées actuelles du connecteur authentifié exposent SendActivityV2
et SendActivityApplication. Six fichiers sources/dépendances inchangés sont
copiés dans un agent hébergé isolé. Le premier chargement de code JSON seul est
refusé et nettoyé; le déploiement multipart pris en charge crée ensuite la version 1
active et un Azure Bot automatique. Son client correspond à l'instance possédée.
Ce déploiement ne prouve ni exécution ni acceptation native : aucune question soumise.
La propriété explicite authorizationPolicy.type=Default reçoit HTTP 400 pour
discriminateur AuthorizationScheme absent. Le
corps minimal documenté de l'application
réussit ensuite. Une relecture indépendante HTTP 200 confirme provisionnement
Succeeded, authorizationScheme=Default et isolation Entra, avec identités
de blueprint/instance d'application distinctes. Aucun partage anonyme ni à
l'échelle de l'organisation n'est activé.
Le déploiement enfant Hosted reçoit HTTP 400 : le service refuse le protocole
Agent lors de la conversion d'énumération et signale aussi un champ de définition
requis. Agent est la valeur publiée dans la
référence ARM
et le SDK de gestion Microsoft. Aucun nom de protocole non documenté,
affaiblissement d'authentification, liaison native enregistrée ni rejeu de question
ne masque cet écart. T005/T006 restent ouverts; ni appelant natif effectif ni
sortie complète du parent ne sont prouvés.
L'agent, l'application, le déploiement enfant, le Bot et les droits possédés sont indépendamment absents après nettoyage. Les quatre lectures d'objets d'annuaire possédés renvoient 404; le contrôle du blueprint d'origine renvoie 200. Cela ne prouve pas une purge des éléments supprimés de l'annuaire. Définition, identités et métadonnées de la version 5 d'origine, inventaire ARM et inventaire des rôles du compte correspondent exactement. L'authentification du point d'entrée original n'est jamais modifiée. Les preuves brutes restent privées; les dépenses temporaires ne sont pas finalisées.
Le suivi des API antérieures
teste 2025-10-01-preview et 2026-01-15-preview, annoncées indépendamment par
le fournisseur. Une nouvelle application Default-RBAC/Entra référence la version 5
immuable d'origine, sans écrire cet agent ou son point d'entrée ni créer un autre
agent hébergé ou Bot. Chaque API reçoit une demande de déploiement Hosted
Agent/2.0.0; toutes deux renvoient HTTP 400 pour conversion d'énumération et
champ de définition requis. Chaque déploiement refusé est indépendamment absent
avec GET 404. Aucune question, nom de protocole non documenté ni acceptation
combinée. L'application et ses deux identités d'annuaire sont supprimées;
relectures complètes de l'agent/version d'origine, inventaires ARM/rôles/
applications et contrôle d'annuaire d'origine sont vérifiés.
Une API antérieure annoncée ne résout donc pas T005/T006.
Les essais des versions restantes du 26 octobre
testent 2026-03-15-preview, 2026-05-15-preview et 2026-07-15-preview,
uniquement après nettoyage indépendant de la cohorte de refus différé.
Chaque demande unique de déploiement Hosted Agent/2.0.0 reçoit HTTP 400 pour
conversion d'énumération et champ de définition requis; chaque enfant refusé
renvoie GET 404. Avec les trois essais antérieurs conservés, aucune des six
versions testées ne résout l'écart du contrat documenté. Aucune question native
ni de modèle direct n'est soumise.
Les métadonnées du fournisseur annoncent ces versions pour l'application parente, pas pour le déploiement enfant. La première recherche locale du type enfant échoue avant toute écriture; son répertoire vide est vérifié avant une reprise contrôlée utilisant le vrai type parent. L'annonce du parent ne prouve pas le support de l'API enfant. L'application et ses deux identités d'annuaire possédées sont indépendamment absentes; agent/version, inventaires ARM/rôles/ applications et contrôle d'annuaire d'origine sont préservés. Aucun protocole deviné ni authentification affaiblie. T005/T006 restent bloqués dans l'issue 2.
Le contrôle du paquet de canal privé examine la route documentée de préparation Microsoft 365/Teams sans publication, sur un autre agent possédé. Le portail officiel de l'administrateur approuvé affiche les points d'entrée Activity et Invocations d'origine actifs. Les relectures complètes de l'agent/version correspondent aussi aux références prises avant cette inspection du portail en lecture seule.
Le premier déploiement s'arrête sur la liaison locale FOUNDRY_PROJECT_ENDPOINT
manquante; des contrôles indépendants prouvent l'absence de changement d'agent,
de ressource ARM ou de rôle. Un déploiement multipart corrigé crée ensuite la
version 1 active et son Azure Bot correspondant, avec six fichiers sources/
dépendances inchangés. Aucun rôle n'est ajouté. Les identités Bot, application
web et moteur personnalisé du paquet local correspondent à l'instance possédée.
Son nom de développeur et ses liens de documentation produit par défaut pour
confidentialité/conditions ne constituent pas une approbation juridique de l'atelier.
Une demande documentée /microsoft365/zip utilise la portée Shared, sans
publication à l'échelle de l'organisation. Les URL de confidentialité/conditions
non approuvées sont omises plutôt qu'inventées. Le service renvoie HTTP 400,
dependency_error : PrivacyUrl must be a valid HTTPS URL. Ce résultat prouve
le blocage du champ de confidentialité, pas celui d'une validation ultérieure
des conditions. Aucun ZIP validé par le service, publication de catalogue,
chargement de paquet, question native ou question directe au modèle ne suit.
Déploiement et génération locale ne prouvent pas l'acceptation native ou du canal.
L'agent, le Bot et les identités d'annuaire possédés sont indépendamment absents après nettoyage. Les deux lectures possédées renvoient 404 et le contrôle du blueprint d'origine renvoie 200. Point d'entrée/agent/version d'origine complets, inventaire ARM et rôles du compte restent exacts. Les dépenses temporaires ne sont pas finalisées. Métadonnées juridiques approuvées et contrôles distincts d'appelant, de sortie, de confidentialité/conservation et de livraison restent nécessaires; T005/T006/T016 restent ouverts.
L'essai de chargement public observe la désactivation imposée du réseau public Storage et HTTP 403 malgré le RBAC limité. Aucune exemption, clé de repli ou modification de stratégie. Ressources et rôles temporaires supprimés, inventaire initial préservé. L'essai par réseau privé prouve ensuite S5-01 : exactement deux fichiers fictifs originaux, vérification DNS/IP privés, identité managée et deux relectures avec empreintes exactes. La reprise interrompue échoue avant l'indexeur; cet échec et une course de nettoyage DNS asynchrone récupérée sont conservés. Le retour aux quatre ressources initiales est vérifié avant une nouvelle tentative à garde distincte. Le chargement ne prouve ni S5-02 ni réponse connectée; T014 reste ouvert.
La vérification privée corrigée ferme désormais S5-01/S5-02. La tentative précédente, indexeur réussi mais relecture vectorielle HTTP 400, est conservée; le champ jetable est explicitement récupérable. La récupération CLI prise en charge reprend le travail déjà déployé, sans nouveau déploiement/chargement, en conservant l'échec de jeton expiré et les erreurs initiales de nettoyage. Indexation privée finale : deux fichiers, aucun échec ni avertissement; passages exacts, métadonnées parent/source et vecteurs réels de 1 536 dimensions vérifiés. Infrastructure, rôles et liens temporaires supprimés; objets/rôles/liens Search et quatre ressources initiales préservés indépendamment. Aucune stratégie Storage, configuration réseau public/clé/anonyme, agent ou route d'origine n'est affaiblie. Avec S5-03/S5-05/S5-06, cinq critères du lab 5 réussissent; réponses connectées, navigation, français et identité refusée gardent T014 ouvert.
L'inventaire et les contrôles de réparation, la relecture de l'état enregistré et la revue indépendante des labs conservent les nouvelles preuves séparément des échecs antérieurs.
- T001 avance : les quatre ressources ARM existantes, les identités du compte, du projet et de Search, les deux déploiements de modèles et les identifiants de propriété conservés concordent. Search Basic fonctionne avec un réplica et une partition. Cost Management retourne 6,219977042 USD avant taxes du 20 octobre à la période partielle du 23 octobre, dont 6,060 USD pour Search. La facturation peut être retardée. La balise d'expiration n'a rien supprimé; le propriétaire de rétention, l'échéance de revue et la limite de dépenses approuvée restent à définir.
- T002/T003 avancent localement : les huit empreintes sources correspondent encore
à
verified-retrieval-sdk-b4-20261022. Les 47 tests documentaires existants, les 33 tests de l'extension, les contrôles de dépendances/syntaxe et la validation canonique/wiki réussissent de nouveau. L'extension hébergée reste en version 1 active avec Entra et BotServiceRbac inchangés; la réparation SDK n'est pas déployée. - La préparation T005/T006 avance : trois GET Dataverse authentifiés confirment le diagnostic Inactive et son empreinte exacte inchangée. Le rattachement d'origine est Active avec identité et cible concordantes. Des lectures Foundry actuelles distinctes confirment que la cible sélectionne la version 4 active, dont la définition correspond au reçu de création. Sans définition Dataverse historique complète du rattachement, sa comparaison octet par octet reste impossible. Aucune réponse native n'a été retestée.
- T009/T010/T014 ont été réconciliées critère par critère. Les réussites historiques de sous-systèmes restent valables dans leur périmètre, mais aucun critère restant n'est nouvellement fermé. La revue précise les preuves manquantes : navigation des citations, corps d'erreur du connecteur, canal publié, confidentialité et requêtes connectées.
- La requête de récupération du navigateur natif a expiré sans identifiant de page. Ses effets restent inconnus; cela ne prouve pas qu'aucune page ne s'est ouverte. Une page non partagée ne fournit pas de parcours de test natif authentifié.
- Les validations attribuables et la décision de rétention ont été demandées une fois; l'utilisateur était indisponible. Elles restent en attente et ne sont pas déduites de la permission générale de reprise. Aucune configuration cloud, politique, permission, agent d'origine ou fichier source n'a été modifié. Aucun courriel, évaluation, déploiement, suppression ou publication distante n'a été effectué.
À ce point en lecture seule, les seize cases restaient ouvertes : chacune exigeait davantage. Le prochain déploiement exigeait les validations de l'artefact exact; les contrôles natifs indépendants exigent aussi un navigateur authentifié utilisable.
L'utilisateur a explicitement fourni toutes les validations nécessaires, dont les déploiements Azure et l'utilisation de crédits Copilot, le 23 octobre 2026 à 16:12:49 -04:00. Le reçu authorized-release.json applique cette autorisation à la réparation isolée existante et au défaut connexe démontré, sans inventer de signataires organisationnels.
- T003 terminée : le candidat SDK inchangé a été déployé en version 2. Le test Activity positif authentifié réel a réussi les extraits complets exacts et l'attribution individuelle. Les journaux de la même session montrent l'acquisition par identité managée et les appels aval.
- Les tests négatifs de version 2
ont révélé un vrai défaut sans preuve : un appel MCP approuvé terminé retournait
seulement un saut de ligne, provoquant
JSONDecodeError. L'entrée trop longue échouait correctement avant tout appel au modèle. Ces deux résultats sont conservés. - L'analyseur traite désormais uniquement le texte vide d'un appel d'outil vérifié terminé comme une absence de preuve. Une sortie absente, non textuelle ou non vide mal formée échoue explicitement. Cinq régressions ajoutées portent la suite à 38 tests réussis. La relecture de la réponse d'échec conservée réussit aussi sans nouvelle inférence. Cet artefact a été déployé en version 3 active, sans modifier Entra ni BotServiceRbac.
- T004 terminée dans son périmètre hébergé : trois tests Activity réels de version 3 réussissent : le cas 6 d'origine inchangé retourne deux extraits exacts avec attribution individuelle; la question d'astronomie inchangée retourne l'abstention exacte; l'entrée trop longue retourne l'erreur explicite sans appel au modèle. Ce sont trois requêtes nouvelles sans reprise, pas une acceptation native ni une matrice de onze cas. Les journaux n'exposent pas le principal aval exact et ne joignent pas indépendamment l'appartenance aux résultats cloud.
- L'erreur navigateur AADSTS65002 provenait de la demande de permissions Power
Platform par le client Azure CLI appartenant à Microsoft. Le consentement
du tenant et Azure RBAC ne remplacent pas la préautorisation du propriétaire
d'API Microsoft. Ces tentatives ont cessé. La
récupération par client possédé
crée un client public monotenant sans secret, utilise PKCE et accorde seulement
à l'utilisateur courant
MakerOperations.ReadetMakerOperations.ReadWrite. La liste d'évaluations du bot retourne HTTP 200, avec zéro jeu de tests. Aucun consentement global, rôle d'annuaire, secret client ou profil Azure n'a changé. - La préparation du test natif produit un CSV privé de deux cas. À ce stade, le prérequis restant exige l'interface : importer ce fichier dans le bot existant, configurer le profil utilisateur Microsoft Copilot Studio authentifié et enregistrer profil et jeu de tests. Leurs vrais identifiants sont nécessaires à une exécution API de brouillon. Aucun appel de création non documenté, accès anonyme ni évaluation native n'a été tenté.
Le diagnostic reste Inactive et la route d'origine version 4 est préservée. Six requêtes Activity hébergées ont été envoyées entre les versions 2 et 3; ce nombre n'est pas un total interne de modèles, de crédits Copilot ou de coûts. Après livraison, Cost Management retourne encore le même sous-total retardé de 6,219977042 USD. Les ressources et la nouvelle inscription possédée sont conservées pour les tests restants. Propriétaire/échéance de rétention et attribution organisationnelle indépendante restent ouverts. Aucune publication distante du dépôt ou du wiki n'a eu lieu. La validation locale à ce stade réussit 53 tests documentaires et 38 tests de l'extension, les contrôles de dépendances/syntaxe, la validation canonique, l'export wiki de 38 pages et sa validation. Ces contrôles ne certifient pas l'acceptation native ni celle des labs restants.
La configuration navigateur admin/MngEnv enregistre le jeu de deux cas, avec persistance vérifiée après navigation complète. Les sélections de compte/outil ne persistent pas dans l'interface, mais l'API documentée de brouillon accepte des liaisons authentifiées explicites. Le contrôle préalable vérifie l'appelant, le jeu enregistré et la liaison d'outil sans nouveaux scopes de connectivité. L'identifiant objet du propriétaire de connexion reste non vérifié indépendamment.
Après l'échec de chargement de la capacité optionnelle du worker, une transition d'état Dataverse prise en charge active uniquement le diagnostic existant. Métadonnées d'état réelles, empreinte exacte et contrôle de concurrence protègent l'opération. Les lignes complètes du rattachement d'origine et du parent restent inchangées.
Une évaluation native de brouillon authentifiée est acceptée avec HTTP 202 et se termine le 24 octobre 2026 à 00:19:34 UTC : deux résultats, une réussite et un échec General Quality, sans nouvelle soumission. L'échec indique abstention Yes, relevance No et completeness No. Le propriétaire retourné et la connexion correspondent à l'appelant vérifié et à la requête. Cela prouve l'exécution authentifiée, pas la livraison native exacte des sources. L'API n'expose ni les réponses ni la correspondance question/résultat. L'entrée d'intention diagnostique seule ne valide pas une recherche substantielle.
La restauration et lecture des preuves
confirment indépendamment le retour du diagnostic à Inactive, sa définition
exacte préservée et les lignes complètes du rattachement d'origine et du parent
inchangées. L'extension hébergée reste en version 3 active; son endpoint natif
sélectionne @latest et conserve Entra plus BotServiceRbac. La lecture documentée
des transcriptions, filtrée au bot et à la fenêtre du test, retourne
403 : privilège prvReadconversationtranscript manquant.
Le navigateur admin vérifié est retrouvé, mais sa demande normale de premier
plan échoue; aucune touche n'est envoyée. Aucun rôle, consentement, paramètre
d'authentification ou publication n'est modifié. Les métriques ne reproduisent
ni ne résolvent l'ancien 403 natif lié au tenant. T005/T006 et la matrice de onze
cas restent ouverts.
Les alternatives prises en charge
conservent les tentatives supplémentaires, sans réussite native. PAC officiel
2.14.1 est restauré dans un dossier isolé ignoré par Git via le flux NuGet V2
HTTPS, après échec TLS de V3. PAC identifie indépendamment le même utilisateur
admin/MngEnv et le même environnement. L'appartenance Global Administrator ne
fournit pas le rôle Dataverse manquant. L'API documentée d'auto-élévation refuse
le client pour UserManagement.Users.Apply, absent du catalogue réel des
permissions publiées. PAC retourne aussi 403; ses alternatives d'affectation
échouent à résoudre l'environnement. Chaque tentative vérifie la restauration
exacte des rôles Dataverse et du profil PAC actif. Aucun nouveau consentement,
rôle ou paramètre d'authentification n'est modifié. La découverte des capacités
du MCP local officiel réussit, puis le processus est arrêté; elle ne fournit pas
la transcription manquante.
Le rapprochement d'infrastructure T013
est terminé sans nouvel apply. Terraform 1.16.6 est restauré avec vérification
de l'empreinte officielle de l'archive. Une copie privée des 23 fichiers Terraform
d'origine reste identique avant et après init, validate et un plan enregistré
non appliqué. Les codes sont 0, 0 et 2, sans erreur ni avertissement de
validation, avec 15 instances proposées. L'inscription automatique des
fournisseurs est désactivée; une lecture Azure indépendante confirme l'absence
du groupe réservé au plan. Versions résolues : AzureRM 4.45.1, AzAPI 1.15.0,
AzureAD 2.48.0, Random 3.6.1 et HTTP 3.6.3.
La comparaison conserve l'ancien apply corrigé de 15 instances et son nettoyage.
Le plan inchangé propose encore GPT-4o 2024-05-13, déjà refusé, des valeurs
publiques/authentification locale et Search Standard sans identité attachée.
Il ne crée ni endpoint privé, ni projet Foundry, ni index de données. Les
surcharges préservant la stratégie et la vectorisation avec identité système
Search vérifiée séparément ne sont pas des propriétés du plan inchangé.
Aucune infrastructure existante n'est réappliquée. D5-02 et D5-03 disposent
désormais de preuves récentes; l'acceptation complète des labs 5.1 et 5 reste ouverte.
La première voie SDK obtient un vrai clone préservant les deux fichiers de connaissances. PAC officiel 2.14.1 refuse ensuite sa propre structure; le contrôle Author ne supprime aucun composant pour fabriquer un paquet. Le précontrôle distinct modèle/API de fichiers vérifie les empreintes en service et une liaison existante autorisée, mais n'exporte que 21 composants sur 26 et omet les instructions de routage parentes. Ces premiers contrôles ne créent aucun candidat, publication ni question SDK. Un dérivé privé complet exige encore reconstruction et vérification indépendante de fidélité avant publication ou acceptation des réponses.
Un candidat de préparation est maintenant créé et vérifié non publié. Les deux fichiers téléversés ont les empreintes d'origine; la liaison existante est vérifiée. L'authentification Entra intégrée et la stratégie d'accès sont préservées. La première création refuse un nom trop long sans conserver d'agent; le nom corrigé réutilise le même schéma. Le candidat conservé n'a encore que 21 composants, manque l'état de routage omis et n'est pas prêt pour le SDK. Aucune publication, extension de permission ni question pendant cette phase. Parent, composants, fichiers et référence de connexion d'origine restent inchangés.
La reconstruction Author couvre maintenant les 26 composants sources localement. Vingt-quatre définitions YAML réussissent la validation; l'unique avertissement concerne le nom d'affichage recommandé absent de la source, pas un comportement omis. Quatorze opérations préparées reproduisent les 26 composants attendus, instructions normalisées exactes et diagnostic inactif compris. Ce sont seulement des résultats locaux : gestion doit contrôler les préconditions, appliquer atomiquement et vérifier le candidat en service avant toute publication ou question SDK.
Le premier précontrôle de gestion s'arrête avant envoi du lot atomique : la synchronisation de fond avance l'ETag parent du candidat. Les 21 composants, empreintes et liaisons correspondent encore; la source reste inchangée. Seules les métadonnées de synchronisation diffèrent. Le relevé de capture indique donc zéro publication, question, activité ou permission écrite. Une actualisation limitée aux gardes de métadonnées doit revérifier tous les champs métier avant un essai atomique distinct, jamais ignorer une modification concurrente.
L'essai atomique rapproché réussit maintenant : les 14 sous-réponses sont HTTP 204. Une relecture indépendante confirme les 26 composants du candidat, définitions, références et états, instructions normalisées exactes, quatre empreintes source/candidat, liaison et contrôles Entra. Les lignes sources complètes restent inchangées. À ce point, le candidat n'est pas publié; le relevé de capture ne contient ni question, activité ni réponse finale. Publication et exécution SDK restent distinctes, sous l'autorisation de déploiement déjà donnée par l'utilisateur.
La publication du candidat
est maintenant confirmée indépendamment par l'API : Succeeded et date de
publication présente. PAC retourne 1 après un échec de son analyseur d'état;
aucune republication. Les 26 définitions/états, empreintes, liaisons et contrôles
Entra réussissent encore; parent et lignes sources complètes restent inchangés.
La tentative de capture du client possédé
s'arrête sans jeton Invoke lors de l'authentification silencieuse : zéro
question ou activité, aucune fin déduite. Permissions d'application et consentement
utilisateur exacts sont restaurés, anciens jetons conservés et profil PAC rétabli.
Le diagnostic pris en charge et l'authentification dans le bon profil navigateur
restent des travaux distincts; publier seul ne prouve pas l'acceptation.
Le diagnostic explicite
identifie maintenant AADSTS65001, consent_required, sans demande de claims.
Un contrôle silencieux avec erreur et un flux PKCE prompt=none du client
possédé échouent pour consentement. Un flux PKCE normal dans le profil vérifié
MCAPS Main Admin ne reçoit aucun rappel dans le délai; son écouteur est fermé.
Le relevé de récupération
indique zéro requête SDK et vérifie indépendamment la restauration exacte du
consentement/manifeste, les jetons conservés et les contrôles source/candidat inchangés.
Aucun cookie ni base de session lu. Un flux expiré n'est pas une autorisation
utilisable; tout consentement supplémentaire exige un nouveau rappel actif.
Le résultat de récupération bornée obtient maintenant un jeton Invoke vérifié après une attente unique de cinq minutes puis une tentative de rafraîchissement forcé. Ressource, scope, client et compte correspondent. La même configuration inclut les scopes OIDC standards : ils ne sont donc pas des causes prouvées de l'erreur initiale et aucun repli OAuth simple n'est nécessaire. Le démarrage SDK renvoie une activité de frappe sans démarrage complet utilisable; zéro question envoyée. Le blocage passe de l'authentification à la capture du démarrage, pas à une livraison complète du parent démontrée.
Des erreurs de transport interrompent d'abord le nettoyage; une récupération indépendante vérifie ensuite le manifeste et tous les consentements utilisateur du client restaurés exactement, accès Maker et rafraîchissement valide conservés, contrôles source/candidat préservés et profil PAC antérieur actif. UIA ne permet ni vérification complète du consentement ni identification sûre des onglets expirés : aucun Accept/Close à l'aveugle. N'acceptez pas les pages de consentement expirées du client possédé.
Le diagnostic SDK avec en-tête
récupère ensuite l'identifiant de conversation fourni par le serveur. Le démarrage
désactive son événement uniquement pour le diagnostic, sans valider l'accueil,
et se termine normalement.
Les deux captures de questions réelles
envoient Hello et le cas SAR 6 inchangé une seule fois chacun. Les trois requêtes
renvoient HTTP 200 et leurs flux se ferment normalement. Hello produit une demande
de précision sur l'enquête; SAR produit une Adaptive Card Azure AI Foundry Agent
Service demandant de connecter le compte puis de sélectionner Continue.
Aucune de ces actions n'est invoquée. Les événements SAR observés sont
DynamicPlanReceived, DynamicPlanStepTriggered et DynamicPlanStepBindUpdate,
pas DynamicPlanFinished. Aucune réponse métier ni comparaison de sources
n'est capturée. Le blocage est désormais l'autorisation utilisateur du connecteur
à l'exécution, malgré la liaison enregistrée. Restauration exacte des droits/cache
et préservation source/candidat sont de nouveau vérifiées. T005-T008 restent ouverts.
Le suivi d'autorisation du connecteur s'arrête avant Connect : profil navigateur et environnement sont identifiés, mais UIAutomation ne peut vérifier le compte administrateur connecté au site. Ce n'est pas un échec MFA ou OAuth observé. Aucune navigation Connect, soumission Continue, nouvelle question, modification de droits ou écriture cloud. Les contrôles indépendants source, candidat, fichiers, liaisons, application, consentements, cache et PAC réussissent. Une personne doit vérifier visuellement le compte MngEnv du site et terminer la connexion Foundry approuvée actuelle avant Continue; les pages OAuth expirées ne doivent pas être acceptées.
L'alternative visuelle limitée à la fenêtre ne prouve pas non plus l'identité : l'image PrintWindow inspectée est blanche, sans compte du site ni tenant lisibles. Aucune action Connect/Continue. L'état réduit initial du navigateur est restauré et les contrôles de préservation réussissent.
La garde initiale de capture au premier plan observe ensuite une autre fenêtre au premier plan et s'arrête sans prendre le focus, modifier la fenêtre cible ou capturer des pixels. Aucune autre fenêtre n'est inspectée. C'est un arrêt avant capture, pas un échec de comparaison d'identité.
La demande unique de mise au premier plan réussit ensuite : le navigateur vérifié est visible, non réduit et au premier plan. Son contrôle de compte du site ne prend pas en charge InvokePattern et la garde des limites de la zone compte refuse la capture. Aucune capture ni action Connect. L'état réduit initial est restauré; tous les contrôles de préservation réussissent. La vérification du compte reste obligatoire.
La récupération par page navigateur prise en charge vérifie ensuite l'UPN administrateur exact dans le menu du compte du site et la route de l'environnement cible. Le libellé du profil Edge n'est pas exposé et ne sert pas de preuve d'identité. Une seule soumission du formulaire Foundry Connect officiel avec le point de terminaison approuvé renvoie Unable to sign in. Please try again. Aucun succès de connexion : ni Continue ni nouvelle question SAR. La vérification d'identité du site est résolue, pas l'autorisation du connecteur. La soumission de création compte comme une écriture cloud, pas zéro. Les contrôles indépendants source/candidat/fichiers/liaisons/application/ consentements/cache/PAC réussissent sans erreur de vérification ou restauration. Le message seul ne prouve pas une cause OAuth, MFA, DLP ou RBAC; le diagnostic pris en charge reste nécessaire.
Après le signalement de connexion par l'utilisateur, le contrôle assisté montre encore un formulaire vide avec Create désactivé, pas un message de succès. Le contrôle en lecture seule de la liste et des détails vérifie ensuite que la connexion Foundry exacte référencée par le candidat est Connected dans les deux vues, avec vérification de l'administrateur du site et de l'environnement requis. Le propriétaire affiché est System Administrator et la dernière modification date du 21 octobre; cela ne prouve ni une modification par la connexion récente ni l'autorisation de la conversation suspendue. Aucune nouvelle création, action Continue ou question SAR dans ces deux contrôles. Les contrôles de préservation réussissent. La requête et la réponse de la création échouée n'ont pas été conservées : sa cause reste non classée. L'authentification du connecteur et le format du point de terminaison respectent le contrat officiel. L'état de la connexion permet une reprise limitée à l'exécution, pas une validation de réponse native, d'ancrage dans les sources ou de la feuille de route complète.
La reprise unique de la conversation initiale
envoie ensuite une seule fois la charge Retry exacte. HTTP 200 et la fermeture
normale du flux SDK renvoient l'indicateur de saisie et la même carte
d'autorisation Foundry, pas une réponse SAR. Le streamType=final de la carte
ne prouve ni récupération ni fin du plan : aucune citation, passage source,
événement DynamicPlanFinished ou fin de conversation observés.
Aucun second Retry, nouvelle question SAR, Create ou publication dans cet essai.
Le manifeste exact du client et tous les consentements de l'utilisateur sont
restaurés; seul le nouveau jeton d'accès Invoke est retiré, en conservant l'accès
Maker et la rotation valide du jeton de renouvellement. Les contrôles indépendants
source/candidat/fichiers/liaisons/authentification/PAC réussissent sans erreur
principale, de nettoyage ou de vérification. L'autorisation par utilisateur à
l'exécution reste à établir malgré l'état Connected de la connexion existante.
L'essai instrumenté après connexion au site utilise la cible Connect de cette nouvelle carte. Le formulaire d'exécution vérifié propose uniquement Create, sans sélection de la connexion existante. Entra ID User Login, le point de terminaison approuvé et les champs requis sont vérifiés avant une seule soumission. Le PUT de connexion renvoie HTTP 201 Created, l'interface affiche Unable to sign in. Please try again., puis le DELETE de nettoyage automatique renvoie HTTP 200. La création ne prouve pas l'autorisation. Les identifiants de requête et de corrélation restent privés; aucun événement de fenêtre OAuth, erreur de rappel ou corps d'erreur du service n'est capturé. La cause de l'échec reste non classée. Aucun autre Create, Continue ou SAR; les contrôles indépendants de préservation réussissent sans erreur de vérification ou nettoyage. La connexion humaine propre au connecteur, pas seulement au site, reste la prochaine limite. Ces éléments ne justifient aucun nouveau rôle, consentement global ou changement de point de terminaison.
L'audit supplémentaire en lecture seule
utilise l'accès administrateur existant à Microsoft Graph v1.0, sans nouveau
consentement. Les requêtes pour l'utilisateur exact entre 19:22 et 19:25 UTC,
dont une requête non interactive distincte, ne renvoient aucun événement.
La fenêtre élargie 19:00–19:30 UTC renvoie quatre connexions Power Apps/shell
Office réussies vers 19:12, pas un code d'échec du connecteur.
Le filtre signInEventTypes rejeté reste consigné; isInteractive eq false
réussit sur v1.0 sans API bêta. La latence des journaux et la portée des requêtes
interdisent de déduire l'absence de tentative ou un blocage de fenêtre.
Le formulaire d'exécution affiche encore l'erreur de connexion. Aucune
soumission au connecteur, action Continue, question ou modification de permission
ou politique dans ce diagnostic; la cause reste non classée.
La récupération après rechargement avec clic mesuré
teste une autre hypothèse après des erreurs de changement/réinitialisation réseau
du navigateur. Les métadonnées OIDC publiques du locataire renvoient HTTP 200,
sans transmission d'identifiants. Le point de terminaison approuvé et Entra User
Login sont vérifiés avant un seul clic Create par l'outil navigateur.
L'événement capturé porte isTrusted=true et une activation utilisateur active.
L'interface affiche pourtant Adding connection, puis Deleting connection et
la même erreur. Une absence d'activation fiable n'explique pas cette soumission.
Les erreurs réseau ne sont pas établies comme cause; la disponibilité des
métadonnées ne prouve pas l'autorisation du connecteur.
Cet essai ne capture ni l'identifiant créé ni les statuts PUT/DELETE :
l'affichage de suppression automatique ne prouve pas indépendamment l'absence
de ressource. Aucune action Continue, nouvelle question, modification de
permission ou publication ensuite. Les contrôles indépendants
source/candidat/fichiers/liaisons/consentements/cache/PAC réussissent sans erreur
de vérification ou restauration. Le diagnostic temporaire de clic est retiré.
La liste des connexions de l'utilisateur contient ensuite six lignes, dont
uniquement l'entrée Foundry initiale Connected; aucune entrée Foundry
supplémentaire ni commande de pagination observée. Cette preuve reste limitée
à la liste : l'absence de la ressource exacte n'est pas vérifiée, car
l'identifiant créé pendant l'essai n'a pas été capturé.
La récupération par le panneau de test Studio
établit ensuite un autre parcours pris en charge. Le cas SAR inchangé renvoie
une carte Open connection manager; son lien pva-studio réel affiche
l'outil Not Connected pour l'administrateur vérifié. Contrairement au formulaire
Connect direct, ce gestionnaire propose Create or pick a connection.
Une soumission associe la connexion approuvée existante, sans nouvelle connexion,
flux OAuth ou modification de permission. Le gestionnaire affiche ensuite
Connected via l'administrateur requis. Le retour à Studio réinitialise le panneau;
un seul nouveau cas SAR inchangé est envoyé après vérification de l'association.
Le parcours natif livre alors trois messages de réponse métier, sans carte d'autorisation ni indicateur de saisie lors de la capture. Une action visible porte le statut Completed en 25,92 secondes. Le parcours est rétabli, pas la fidélité aux sources : sept des neuf passages cités du premier message correspondent exactement; cinq des six du deuxième correspondent. Le dernier message généré ne contient aucun passage entre guillemets et ne peut réussir un contrôle de citation exacte par absence. Chaque extrait est comparé à son propre groupe source canonique affiché dans le corpus original épinglé. Réponses brutes et texte protégé restent privés. L'attente initiale expire car elle suppose des enfants directs dans le fil; la capture ultérieure utilise les articles Web Chat réellement imbriqués. Ni l'absence d'indicateur de saisie ni le statut de l'outil ne prouvent un événement protocolaire de fin du plan. L'autorisation du canal publié et la matrice complète de onze cas restent non prouvées.
Le diagnostic hébergé existant
est ensuite activé uniquement sur le candidat et invoqué une fois par la
connexion native rétablie. Il renvoie HTTP 403, ConnectorRequestFailure :
BotServiceRbac exige un identifiant de tenant Entra valide pour l'appelant
Activity. L'outil affiche Failed et zéro jeton, sans réponse métier.
Le diagnostic revient à Off; parent original, définitions/authentification du
candidat, liaisons de fichiers, application/consentements, cache possédé et
profil PAC sont vérifiés indépendamment.
L'essai Entra seul borné déjà autorisé modifie ensuite uniquement la liste d'autorisation du point isolé, en conservant Azure RBAC, sans jamais activer d'accès anonyme. Une seule question native dépasse l'erreur de tenant mais renvoie HTTP 400 : l'identifiant de blueprint de l'appelant Activity ne correspond pas au résumé de l'agent hébergé. Ce nouvel échec ne valide ni fidélité aux sources ni cause de migration d'identité. Le diagnostic du candidat revient à Off; les deux autres spécialistes restent On. Point/carte exacts, Entra avec BotServiceRbac, définition/identité de version 3 et octets du manifeste original sont vérifiés restaurés, sans erreur de vérification ou restauration. Aucun déploiement, nouvelle version, publication, changement de corpus ou de rôle. La fenêtre maximale de cinq minutes se termine plus tôt après l'essai. La prochaine étape est l'examen pris en charge du contrat protocole/connecteur, pas une nouvelle création de connexion ni le retrait permanent de BotServiceRbac.
Le contrôle natif du contrat en lecture seule observe dix actions après See all. La référence publique décrit des actions hébergées Invocations/Responses, mais aucune n'apparaît dans ce catalogue; cela ne prouve pas leur absence côté service. L'action Activity par application propose la connexion approuvée, mais son aperçu est annulé avant Add and configure. La liste des outils reste vide et le diagnostic Off. Le guide d'intégration natif officiel exige Activity, déjà exposé par le point réel. Aucun correctif officiel vérifié pour cette erreur exacte ni cause de migration d'identité n'est établi. Aucune identité appelante ou charge Activity n'est remplacée.
Le nouvel essai SDK publié après association Studio envoie exactement un cas SAR inchangé, sans reprise. Démarrage et question renvoient HTTP 200; les deux flux possédés se ferment normalement. Les cinq activités contiennent frappe, trois événements de démarrage/liaison de plan et carte Foundry Connect your account, pas de réponse métier ni fin du plan. L'association Studio ne prouve donc pas l'autorisation du canal publié. Aucun Connect, Continue, nouvelle connexion ou publication ne suit. Portée du manifeste possédé et consentement limité à l'utilisateur sont exactement restaurés. Seul le nouveau jeton d'accès Invoke est supprimé; accès Maker et entrées de rafraîchissement valides sont conservés. Définitions source/candidat, fichiers, liaisons, authentification, cas original et profil PAC passent les contrôles, sans erreur primaire, de restauration ou de vérification finale.
L'exécution Search fictive réelle ferme S5-03/S5-05/S5-06, pas T014. Elle teste le texte original Harbor/Forest, la vectorisation de requêtes sans clé en 1 536 dimensions, la recherche lexicale/vectorielle/hybride/sémantique et les deux assertions de filtrage. L'échec initial de disponibilité par statistiques reste conservé; le second essai utilise un comptage de recherche réel. Les deux index temporaires sont supprimés; les trois schémas existants sont vérifiés inchangés. Ces contrôles par chargement direct ne prouvaient pas l'acceptation Blob/indexeur; la vérification privée ultérieure ci-dessus valide S5-01/S5-02. Les réponses connectées, citations navigables, cohérence française et refus d'identité restent ouverts.
Le reçu suivant décrit les échecs antérieurs. La livraison autorisée de version 3 ci-dessus remplace seulement son état de déploiement, pas ses preuves historiques.
L'extension Python
vérifie les enregistrements récupérés contre un corpus sous licence dont l'empreinte
est fixée, puis restitue les citations par du code. Les tests locaux de transport
simulent le chargement du corpus et l'opération de réponse Azure.
Le reçu de l'extension
conserve la version hébergée 1, un SDK Activity déployé non corrigé, une erreur
native HTTP 403 et une erreur directe authentifiée HTTP 500 avant le gestionnaire
applicatif. La réparation locale Activity 1.0.0b4 et Microsoft Agents 1.9.0
passe sa régression. Son déploiement et les permissions aval de l'identité hébergée
restent à vérifier.
Utilisez les ressources isolées existantes et les interfaces prises en charge. Préservez les agents d'origine, les échecs, les preuves privées et le routage fonctionnel en version 4. Un appel SDK ne remplace pas une réponse native Copilot. Une vérification locale ne remplace pas une exécution cloud. Ne contournez pas la politique, n'activez pas l'accès anonyme et ne reconstituez pas les documents protégés. Le notebook sous licence n'est pas une preuve d'équivalence juridique ou documentaire avec ces originaux. Aucune migration d'architecture n'est nécessaire.
La permission générale de reprise et l'autorisation explicite ultérieure de déploiement/crédits sont enregistrées ci-dessus. Ne les redemandez pas. L'attribution indépendante des rôles Product Owner, équipe sécurité et responsable technique n'est pas établie par cette déclaration. Conservez cette distinction dans T002, les artefacts exacts et le retour arrière limité.
Les responsables sont des rôles d'exécution, pas des personnes désignées ou des approbations acquises. P0 supprime le blocage immédiat ou limite les coûts; P1 ferme l'acceptation fonctionnelle; P2 réconcilie les preuves et la publication.
| Étape | Priorité | Responsable | Dépend de | Preuve de clôture |
|---|---|---|---|---|
| 1.1 | P0 | Livraison et propriétaire cloud | Aucune | Inventaire, coûts, artefact et validations |
| 2.1 | P0 | Mainteneur de l'extension | 1.1 | Réparation Activity hébergée du lab 6 et extraits exacts |
| 3.1 | P1 | Copilot Manage et Test | 2.1 | Réponse native du lab 6, état enregistré et contrôle |
| 4.1 | P1 | Copilot Author et Test | 3.1 | Correspondance F6 et onze scénarios du lab 6 |
| 5.1 | P1 | Responsable des labs et Test | 1.1 | Reçus d'acceptation des labs 0, 1, 2 et 3 |
| 6.1 | P1 | Responsable politique et lab | 1.1 | BYOM connecté pris en charge ou exclusion explicite |
| 7.1 | P1 | Infrastructure et responsable lab | 1.1 | Reçus de déploiement et requêtes connectées labs 5/5.1 |
| 8.1 | P2 | Preuves et publication | 4.1,5.1,6.1,7.1 | Preuves bilingues, nettoyage et contrôles de livraison |
Les étapes 5.1, 6.1 et 7.1 peuvent avancer indépendamment après 1.1 si leurs ressources et sessions navigateur ne se chevauchent pas. Évitez les modifications concurrentes d'un agent partagé. Aucune date de fin n'est annoncée tant que les dépendances de licence, politique et validation ne sont pas résolues.
Exigence : REQ-001. Entrées : inventaire privé et reçu de l'extension.
- T001 [Plan:1.1] Réinventorier l'extension isolée, le Bot, le projet, Search, les embeddings et les identités à partir des preuves privées de propriété. Comparer les identifiants, états, versions et facturation réels. Désigner un propriétaire et une échéance de revue; une balise d'expiration ne supprime rien.
- T002 [Plan:1.1] Enregistrer l'artefact, le retour arrière limité et les validations attribuables du Product Owner, de l'équipe sécurité et du responsable technique avant déploiement. Conserver les identifiants privés hors du dépôt; publier seulement une référence expurgée.
Sortie : propriété et état courant vérifiés, limites de dépenses et de livraison explicites. Sans validation, les déploiements dépendants restent bloqués, mais les travaux documentaires et d'inventaire indépendants peuvent continuer.
Lab couvert : lab 6, point de contrôle de l'extension hébergée.
Exigence : REQ-002. Entrées : instructions de l'extension et manifeste de déploiement.
- T003 [Plan:2.1] Réexécuter les tests du service, les contrôles de dépendances et de syntaxe. Déployer l'artefact autorisé par l'utilisateur dans le projet existant. Conserver versions SDK résolues, version hébergée, journaux et retour arrière sans effacer l'échec précédent. Terminé : versions 2 et 3 déployées; les 38 tests actuels réussissent.
- T004 [Plan:2.1] Envoyer des requêtes Activity authentifiées avec enveloppes complètes, dont
serviceUrl. Vérifier sessions réelles, récupération/sélection, extraits exacts et comportements d'erreur/abstention avec les identifiants hébergés. Terminé : tests positif, abstention et entrée invalide de version 3 réussis; acceptation native et appartenance indépendante aux résultats restent exclues.
Sortie : l'erreur de constructeur disparaît dans l'hôte réel et la livraison fondée sur les sources réussit. Un point de contrôle de disponibilité ne suffit pas. Garder l'autorisation du point de terminaison inchangée pendant cette réparation initiale pour ne pas confondre les causes.
Lab couvert : lab 6, point de contrôle de l'agent connecté natif.
Exigence : REQ-003. Entrées : diagnostic enregistré inactif et route de contrôle.
- T005 [Plan:3.1] Résoudre le contrat natif de protocole/identité avec les métadonnées d'appelant et journaux pris en charge. L'essai Entra seul borné est exécuté et exactement restauré : HTTP 403 devient HTTP 400 de blueprint, sans livraison réussie. Conserver Azure RBAC et BotServiceRbac, sans accès anonyme ni permissions larges. Confier les changements gérés à Manage et le YAML à Author.
- T006 [Plan:3.1] Faire exécuter par Test un diagnostic natif et une question de contrôle inchangée. Capturer action native, corrélation hébergée, fin du tour parent et réponse affichée exacte. Désactiver ensuite le diagnostic, relire indépendamment son état inactif enregistré et vérifier la route d'origine.
Sortie : une réponse native démontre la livraison vérifiée, pas seulement un appel Activity direct. Si Entra uniquement n'est pas pris en charge ou ne corrige pas les métadonnées, conserver l'échec et utiliser le support officiel au lieu de contourner l'autorisation.
Lab couvert : lab 6, continuation et matrice F6 originale.
Exigence : REQ-004. Entrées : questions originales et audit des tours complets dans le rapport d'exécution.
- T007 [Plan:4.1] Faire corriger par Author uniquement les écarts démontrés de citations littérales, attribution par puce, obligations conditionnelles et couverture d'exemples dans le candidat isolé. Préserver l'accueil sans source, les recherches locales, le routage hybride et le contrôle fonctionnel.
- T008 [Plan:4.1] Faire exécuter par Test les onze scénarios inchangés dans une nouvelle session native après un précontrôle acquitté. Conserver les réponses finales complètes,
DynamicPlanFinished, les routes attendues, comparaisons de sources, attributions individuelles, pertinence, applicabilité et couverture des exemples pour chaque cas. Compter les reprises séparément. - T017 [Plan:4.1] Réconcilier chaque critère F6-01 à F6-12 du lab 6 avec son exécution, artefact, question, route et résultat exacts. Actualiser ensemble le guide du lab 6 et le registre de validation; conserver les échecs et distinguer la matrice originale de la continuation de onze scénarios. Réutiliser une preuve seulement si l'assertion correspond. Identifier explicitement le refus d'identité natif et le test sans Activity restants; ne pas substituer le refus Search du lab 5, une erreur de blueprint ou un transport direct réussi. Conserver la limite de source originale inaccessible. Exécuter uniquement un critère réellement manquant après disponibilité du prérequis ou correctif pris en charge, puis vérifier son nettoyage.
Sous-étape documentaire livrée le 2026-10-26 : douze dispositions avec provenance et publication bilingue synchronisée guide/registre/feuille de route dans la correspondance. L'acceptation d'exécution reste ouverte; les variantes ajoutées au guide ne deviennent pas automatiquement des obligations originales universelles. Actualisation documentaire : F6-04 PASS et F6-05 PASS au niveau du document sont liés dans les guide, registre et correspondance synchronisés. L'extrait affiché F6-05 ne contient pas ATO; aucune acceptation du fragment cité exact ou de la qualité globale des citations. La configuration prospective adaptée ne prouve pas l'équivalence historique.
Sortie : chaque cas et critère obligatoire justifié possède une preuve d'acceptation correspondante, sans recommencer le travail vérifié. Les captures fusionnées précédentes, quatre réponses extractives backend et notes génériques de qualité ne remplacent pas cette matrice. En cas d'échec, conserver la preuve, corriger la cause et reprendre les cas touchés et régressions de routage. La réconciliation documentaire T017 est livrée indépendamment de 3.1; les essais natifs dépendants exigent toujours leur correctif pris en charge. Une source originale protégée manquante n'autorise ni reconstruction ni certification d'exigences inconnues.
Exigence : REQ-005. Entrées : table de réexécution et guides.
- T009 [Plan:5.1] Revérifier pour le lab 0 licences, capacité, politique, permissions, quota, outils et budget. Pour le lab 1, fermer l'audit historique de réponse complète, navigation de citation et fidélité des corps d'erreur du connecteur aval. Utiliser des destinataires synthétiques/approuvés; ne renvoyer un courriel que si un critère manquant l'exige.
- T010 [Plan:5.1] Pour le lab 2, vérifier la navigation réelle vers le PDF externe et les réponses connectées positives/négatives. Pour le lab 3, vérifier télémétrie sur canal publié et confidentialité requise avec corrélation événement/KQL. Un événement authentique ne prouve pas l'absence de tous les identifiants plateforme.
Sortie : chaque lab possède son reçu observé pour tous les identifiants d'acceptation obligatoires. Conserver l'évaluation échouée initiale et expliciter toute exigence impossible à satisfaire au lieu de déclarer une réussite complète.
Exigence : REQ-006. Entrées : lab 4, dialogue et politique observés.
- T011 [Plan:6.1] Faire établir par le propriétaire de politique si le connecteur courant prend en charge Entra sous
disableLocalAuth=true. Sinon obtenir une exception formelle gouvernée ou une substitution/exclusion documentée et approuvée. Ne pas activer l'authentification locale ni contourner la politique par balises ou YAML. - T012 [Plan:6.1] Avec un chemin pris en charge, faire vérifier par Test invocation directe, récupération analysée, prompt connecté, réponses fondées, résultats vides et erreurs. Enregistrer chemin retenu et preuves dans les deux guides du lab 4 et le registre.
Sortie : les critères BYOM connectés réussissent. Une exclusion approuvée modifie le périmètre déclaré; elle n'est pas une réussite du lab original inchangé.
Exigence : REQ-007. Entrées : lab 5, lab 5.1, reçus du pipeline privé.
- T013 [Plan:7.1] Réconcilier le déploiement Terraform corrigé avec ressources requises, versions de fournisseurs, réseaux privés et identités. Préserver les preuves plan/apply et identifier les écarts à la source inchangée; ne pas réappliquer pour reproduire une infrastructure déjà démontrée. Rapprochement terminé : nouveaux init/validate/plan des sources inchangées, écarts réseau/identité/modèle explicites et ancien apply corrigé/nettoyage conservés; aucun nouveau déploiement ni réussite globale du lab.
- T014 [Plan:7.1] Faire exécuter par Test les requêtes connectées restantes, filtres, classement et champs attendus avec les lieux indiqués par les sources. Vérifier la navigation vers les URL d'hôtels originales si requise. Sans URL dans le corpus, consigner la limite et obtenir une décision de périmètre plutôt que fabriquer des liens.
Sortie : les comportements connectés requis passent avec sources traçables et écarts d'infrastructure documentés. Les réussites d'ingestion privée et de projection restent des preuves de sous-système, pas de certification intégrale.
Exigence : REQ-008. Entrées : nouveaux reçus et procédure de publication.
- T015 [Plan:8.1] Mettre à jour ensemble rapports anglais/français, registres, guides et reçus JSON expurgés. Préserver la chronologie et distinguer réussite, échec, blocage, exclusion et non-exécution. Supprimer uniquement les ressources jetables dont la propriété est vérifiée; sinon enregistrer propriétaire, revue des coûts et rétention explicite.
- T016 [Plan:8.1] Exécuter tests documentaires, validation canonique, export et validation wiki. Examiner visibilité réelle du dépôt, destination wiki et changements humains avant publication autorisée; vérifier ensuite révisions distantes et pages des deux langues. La publication de l'instantané en cours du 25 octobre est vérifiée, pas l'acceptation finale. Déclarer l'atelier terminé uniquement contre la liste finale ci-dessous.
Sortie : chaque exigence obligatoire possède une preuve actuelle, la publication est vérifiée si effectuée et aucune ressource d'essai sans propriétaire, coût expliqué ou décision de rétention ne reste. Une demande de suppression ne prouve pas l'absence.
Ces identifiants structurent les travaux restants, sans créer de nouveaux critères. Les guides et preuves d'acceptation conservées restent la référence.
| Exigence | Résultat restant | Étape | Tâches | Preuve requise |
|---|---|---|---|---|
| REQ-001 | Exécution approuvée à coûts maîtrisés | 1.1 | T001,T002 | Inventaire et validation attribuable |
| REQ-002 | Réparation SDK hébergée du lab 6 | 2.1 | T003,T004 | Activity hébergée et extraits exacts |
| REQ-003 | Livraison native authentifiée du lab 6 | 3.1 | T005,T006 | Tour complet et relecture d'état |
| REQ-004 | Acceptation F6 et onze scénarios lab 6 | 4.1 | T007,T008,T017 | Correspondance par critère et audit des tours |
| REQ-005 | Clôture des labs 0 à 3 | 5.1 | T009,T010 | Reçus positifs, négatifs et de confidentialité |
| REQ-006 | BYOM lab 4 pris en charge | 6.1 | T011,T012 | Décision de politique et prompt connecté |
| REQ-007 | Acceptation connectée labs 5 et 5.1 | 7.1 | T013,T014 | Déploiement et requêtes connectées |
| REQ-008 | Livraison bilingue honnête et nettoyage | 8.1 | T015,T016 | Docs, publication et relectures de nettoyage |
Depuis la racine du dépôt, utiliser les commandes existantes :
.\.venv\Scripts\python.exe -m unittest discover -s scripts -p 'test_*.py' -v
.\.venv\Scripts\python.exe scripts\validate_docs.py
.\.venv\Scripts\python.exe scripts\build_wiki.py --output .wiki-build
.\.venv\Scripts\python.exe scripts\validate_docs.py --wiki .wiki-buildConsulter les instructions du service pour son environnement virtuel et ses tests. Les essais réels exigent navigateur ou API pris en charge et authentifiés, ressources isolées approuvées, données sources réelles et corrélation synthétique unique. Sans navigateur natif, les API peuvent diagnostiquer le backend, mais l'acceptation native reste bloquée.
Avant toute déclaration de réussite complète :
- Toutes les tâches et tous les critères originaux obligatoires passent, sans échec obligatoire masqué par une exclusion.
- Chaque lab, y compris F6-01 à F6-12 du lab 6, possède une correspondance explicite entre preuves et assertions; aucun lab n'est omis parce que ses travaux utilisent une extension, MCP ou un autre titre de tâche.
- Les preuves natives et hébergées correspondent à l'artefact approuvé et préservent contenu exact, applicabilité, routage et comportements négatifs requis.
- Validations, rapports bilingues et reçus expurgés concordent avec les résultats; aucun secret, original protégé ou résultat inventé n'est publié.
- Les ressources possédées ont un nettoyage vérifié ou une rétention explicite à coûts maîtrisés; agents originaux et ressources étrangères restent intacts.
- La validation locale passe et toute publication revendiquée du dépôt/wiki a été relue indépendamment.
Source screenshots are not new executions. Les captures d'origine ne sont pas de nouvelles exécutions. See validation / voir le registre.