Laboratoire des fondamentaux de GitHub Copilot Business

Préalables

• Une copie locale de ce dépôt
• Des versions de Node.js et de npm compatibles avec l’environnement testé
• Un poste GitHub Copilot Business régi par votre organisation

Objectifs d’apprentissage

• Repérer la limite locale des données du dépôt.
• Distinguer le contexte source public des secrets et des données réelles de demandeurs.
• Exécuter une validation ciblée et interpréter sa preuve.

Repères dans le dépôt

src/app/layout.tsx

Confirmer la coquille de l’application et l’avis de sécurité permanent.

src/lib/stockage/db.ts

Examiner la limite IndexedDB locale au navigateur.

Notes sur les preuves

• Le code source du dépôt et la sortie des tests ciblés constituent les preuves de ce module; les explications générées demeurent des propositions jusqu’à leur vérification.

Étapes

1. 1

   Examiner la limite du dépôt

   Ouvrez les deux repères du dépôt et trouvez où sont définis la langue du document, l’avis de sécurité et la base de données locale.

   Demandez à Copilot d’expliquer uniquement ces fichiers sélectionnés, puis vérifiez chaque affirmation dans le code source.

   Requête

   Explique les limites relatives aux données locales et à la sécurité indiquées uniquement dans src/app/layout.tsx et src/lib/stockage/db.ts. Cite le fichier pour chaque affirmation et précise ce que ces fichiers ne prouvent pas.

   Résultats attendus

   • Vous pouvez expliquer que l’application est un prototype statique en français canadien dont les dossiers restent dans IndexedDB, dans le navigateur.
2. 2

   Exécuter les tests ciblés de la fondation

   Exécutez la commande ciblée à la racine du dépôt et lisez le nom des tests avant d’accepter le résultat.

   npm run test -- lab-content fundamentals-lab

   Résultats attendus

   • Les tests du contrat de langue et du rendu sémantique réussissent dans les deux langues.

Récupération

• Écartez toute explication générée qui ne peut pas être reliée aux fichiers sélectionnés.
• Si des dépendances manquent, exécutez npm ci à la racine du dépôt, puis relancez la commande de test ciblée.

Dépannage

La commande de test ciblée ne trouve pas les tests du laboratoire.

Confirmez que les dépendances ont été installées depuis la racine du dépôt et que les deux fichiers de test demandés se trouvent sous src.

Question de vérification

Préalables

• Avoir terminé LAB-00.
• Ouvrir la conversation Copilot dans VS Code à la racine du dépôt.

Objectifs d’apprentissage

• Distinguer l’exportation statique des services d’exécution.
• Suivre la validation et la persistance locale dans les fichiers sélectionnés.
• Remplacer les suppositions générées par des preuves citées.

Repères dans le dépôt

src/lib/domaine/demande.types.ts

Examiner le dossier local versionné et les statuts fixes.

src/lib/domaine/demande.schemas.ts

Comparer la validation du brouillon et celle de la transmission simulée.

src/lib/stockage/db.ts

Confirmer que Dexie conserve les données dans IndexedDB, dans le navigateur.

next.config.ts

Confirmer la limite de l’exportation statique.

Notes sur les preuves

• Le code prouve l’exportation statique, les deux niveaux de validation, les valeurs fixes du domaine et la persistance IndexedDB. Il ne prouve ni un déploiement hébergé ni la configuration d’une stratégie d’organisation.

Étapes

1. 1

   Demander une carte d’architecture circonscrite

   Sélectionnez uniquement les quatre repères ci-dessus et demandez un flux de données concis qui cite chaque affirmation.

   Requête

   À partir des seuls fichiers sélectionnés, cartographie l’entrée, la validation, la persistance et la sortie de compilation. Cite le fichier pour chaque affirmation et marque les suppositions comme non vérifiées.

   Résultats attendus

   • La carte distingue la validation permissive du brouillon, la validation plus stricte de la transmission simulée, la persistance IndexedDB et l’exportation statique.
2. 2

   Comparer la carte au dépôt

   Ouvrez chaque emplacement cité. Retirez les affirmations sur des routes API, une authentification, un stockage serveur ou un déploiement que le code sélectionné n’établit pas.

   npm run build

   Résultats attendus

   • La compilation statique se termine et produit l’exportation sans service dorsal ni variable d’environnement d’exécution.

Récupération

• Si la réponse dépasse les fichiers sélectionnés, répétez la limite et régénérez-la.
• Si la compilation échoue, conservez la sortie et diagnostiquez l’échec avant d’accepter la carte.

Dépannage

Copilot décrit une application serveur Next.js habituelle.

Montrez-lui output: export dans next.config.ts et demandez-lui de retirer toute affirmation serveur absente des fichiers sélectionnés.

Question de vérification

Préalables

• Avoir terminé LAB-01.
• Partir d’un écart propre ou isoler les modifications de l’exercice.

Objectifs d’apprentissage

• Circonscrire une tâche de test avec des invariants explicites.
• Comparer les assertions générées à la fonction pure d’admissibilité.
• Obtenir une preuve ciblée avant la validation élargie.

Repères dans le dépôt

src/lib/domaine/admissibilite.ts

Comprendre le résultat pur et l’ordre des critères.

src/lib/domaine/admissibilite.test.ts

Prolonger le style existant de tests pilotés par les données.

Notes sur les preuves

• Un test utile vérifie les critères manquants exacts et leur ordre, pas seulement le nombre d’échecs.

Étapes

1. 1

   Générer un cas mixte

   Demandez un écart limité au test qui respecte le style paramétré existant et ne touche pas admissibilite.ts.

   Requête

   Ajoute un cas mixte piloté par les données dans src/lib/domaine/admissibilite.test.ts. Vérifie les critères manquants exacts dans l’ordre du code source. Ne modifie pas le code de production.

   Résultats attendus

   • L’écart proposé modifie uniquement le fichier de test ciblé et nomme explicitement les critères attendus.
2. 2

   Exécuter et examiner la preuve ciblée

   Examinez l’écart, exécutez le test ciblé, puis confirmez que le code source de production demeure inchangé.

   npm run test -- admissibilite

   Résultats attendus

   • Les tests d’admissibilité réussissent et l’écart ne modifie aucun comportement de production.

Récupération

• Si une attente générée contredit l’ordre du code source, corrigez le test à partir d’admissibilite.ts.
• Si le code de production a changé, écartez cette portion et redemandez un écart limité au test.

Dépannage

Vitest ne trouve aucun fichier de test correspondant.

Exécutez la commande depuis la racine du dépôt et utilisez le nom de fichier admissibilite comme filtre.

Question de vérification

Préalables

• Avoir terminé LAB-02.
• Savoir examiner un écart Git et annuler les modifications d’un exercice.

Objectifs d’apprentissage

• Repérer deux implémentations dupliquées.
• Évaluer la pertinence d’une fonction pure commune.
• Tester les limites d’horodatages anciens et futurs avant la validation élargie.

Repères dans le dépôt

src/components/demandes/assistant-provider.tsx

Examiner la première implémentation de prochaineDateModification.

src/components/fichier/selecteur-pdf-local.tsx

Examiner la seconde implémentation.

Notes sur les preuves

• Les fonctions dupliquées justifient l’extraction; les tests ciblés et de limites prouvent la conservation du comportement.

Étapes

1. 1

   Demander un plan circonscrit

   Demandez un plan avant toute modification. Exigez une fonction pure, le remplacement direct des appels et des tests pour les horodatages anciens et futurs.

   Requête

   Planifie la plus petite refactorisation qui remplace les deux implémentations de prochaineDateModification par une fonction pure. Préserve la sortie ISO monotone. Inclue des tests pour les horodatages anciens et futurs. Ne modifie rien pour l’instant.

   Résultats attendus

   • Le plan nomme les deux appels, un emplacement commun, des tests ciblés et aucune modification sans rapport.
2. 2

   Appliquer, réviser et valider

   N’approuvez que les fichiers circonscrits, examinez l’écart, puis exécutez les deux filtres de tests touchés.

   Requête

   Implémente le plan minimal approuvé. Arrête-toi après la fonction, ses tests de limites et les deux remplacements d’appel, puis résume l’écart.

   npm run test -- assistant-provider selecteur-pdf-local

   Résultats attendus

   • Les tests ciblés réussissent, les deux composants utilisent une fonction commune et une entrée ancienne ou future produit toujours un horodatage ultérieur.

Récupération

• Annulez l’écart de l’exercice si l’ordre temporel change ou si la portée dépasse les fichiers nommés.
• Si les tests ciblés échouent, comparez les anciennes et les nouvelles sorties à la limite en cause avant une autre modification.

Dépannage

La fonction générée retourne l’heure actuelle pour une entrée future.

Refusez la modification. Le résultat doit être ultérieur à l’heure actuelle et à l’horodatage fourni.

Question de vérification

Préalables

• Avoir terminé LAB-03.
• Installer les navigateurs Playwright requis par le projet.

Objectifs d’apprentissage

• Utiliser les noms accessibles français exacts.
• Tester le focus et les questions manquantes, pas seulement l’apparence.
• Exécuter Chromium avant la matrice élargie.

Repères dans le dépôt

src/components/admissibilite/verificateur-admissibilite.tsx

Suivre le focus et les messages de réponses incomplètes.

e2e/accessibilite.spec.ts

Reprendre le modèle axe existant.

e2e/validation-finale.spec.ts

Réutiliser les modèles de validation du clavier et du débordement.

Notes sur les preuves

• Le focus sur l’alerte, le texte exact des questions manquantes, l’absence de résultats axe graves ou critiques et l’absence de débordement sont des vérifications distinctes.

Étapes

1. 1

   Rédiger le parcours de réponses manquantes

   Demandez un cas Playwright qui soumet des questions sans réponse, vérifie le focus et les détails, exécute axe et vérifie le débordement.

   Requête

   Ajoute un test Playwright ciblé pour les questions d’admissibilité incomplètes. Utilise le nom accessible français exact du bouton, vérifie le focus de l’alerte et chaque question manquante, exécute axe et vérifie le débordement horizontal. Ne modifie pas le composant.

   Résultats attendus

   • Le test proposé utilise les rôles et les noms accessibles plutôt que des sélecteurs CSS pour les contrôles visibles.
2. 2

   Exécuter la vérification dans le navigateur

   Comparez les sélecteurs générés au composant, puis exécutez la vérification Chromium ciblée.

   npm run test:e2e -- --project=chromium --grep "questions incomplètes"

   Résultats attendus

   • Le parcours incomplet réussit avec les preuves de focus, de questions manquantes, d’axe et de débordement.

Récupération

• Si le filtre ne trouve aucun test, harmonisez le titre du test et la commande avant d’élargir l’exécution.
• Si axe ou le focus échoue, corrigez la sémantique sous-jacente plutôt que d’affaiblir l’assertion.

Dépannage

L’instruction anglaise ne trouve pas le bouton d’envoi.

Utilisez le nom accessible français exact : Vérifier l’admissibilité.

Question de vérification

Préalables

• Avoir terminé LAB-04.
• Utiliser uniquement le fichier fictif sous e2e/fixtures.

Objectifs d’apprentissage

• Suivre la validation PDF et la persistance IndexedDB.
• Vérifier que la sélection ne produit aucune requête API.
• Refuser les affirmations non étayées sur l’antivirus, le chiffrement, le téléversement ou la validation serveur.

Repères dans le dépôt

src/lib/fichier/pdf-local.ts

Examiner la validation locale de l’extension, du type MIME, du contenu vide et de la taille.

src/components/fichier/selecteur-pdf-local.tsx

Suivre la sélection locale et le cycle de vie de l’URL objet.

src/lib/stockage/documents.repository.ts

Confirmer la persistance locale du document dans le navigateur.

e2e/parcours-local.spec.ts

Examiner les preuves existantes de persistance sans réseau.

Notes sur les preuves

• Le code peut établir la validation et la persistance locales. Il ne prouve ni la sécurité de l’appareil, ni l’absence de logiciel malveillant, ni le chiffrement au repos, ni la conformité juridique.

Étapes

1. 1

   Classer les affirmations de confidentialité

   Demandez une révision en trois colonnes : prouvé par le code, non prouvé et déduction interdite. Vérifiez chaque ligne.

   Requête

   Révise uniquement les fichiers PDF et de dépôt sélectionnés. Classe chaque affirmation de confidentialité ou de sécurité comme prouvée par le code, non prouvée ou déduction interdite. Cite les fichiers exacts. N’affirme aucun téléversement, antivirus, chiffrement ou validation serveur.

   Résultats attendus

   • La révision confirme la validation et le stockage locaux tout en refusant explicitement les capacités absentes du code.
2. 2

   Vérifier le comportement réseau local

   Exécutez le scénario PDF existant et examinez les requêtes capturées avant d’accepter la révision.

   npm run test:e2e -- --project=chromium --grep "PDF"

   Résultats attendus

   • Le PDF fictif est validé et restauré localement sans requête vers une API d’application.

Récupération

• Supprimez le document fictif dans l’application pour réinitialiser l’état local du navigateur.
• Retirez toute affirmation générée dépourvue de preuve directe dans le code ou le navigateur.

Dépannage

Une URL blob est prise pour un téléversement.

Une URL blob du navigateur désigne un contenu local en mémoire. Vérifiez le réseau dans Playwright plutôt que de déduire un téléversement de l’URL.

Question de vérification

Préalables

• Avoir terminé LAB-05.
• Savoir réviser les modifications et les approbations de commandes proposées dans l’EDI.

Objectifs d’apprentissage

• Limiter l’agent aux fichiers et invariants nommés.
• Réviser les commandes avant de les approuver.
• Refuser toute affirmation de traitement réel ou de progression chronométrée.

Repères dans le dépôt

src/lib/domaine/machine-etats.ts

Examiner les trois transitions avant permises.

src/lib/domaine/machine-etats.test.ts

Verrouiller les quatre statuts et les transitions interdites.

src/components/demandes/suivi-simule.tsx

Préserver le libellé exact de simulation et de conservation locale.

Notes sur les preuves

• Les indications actuelles du produit précisent que le mode agent peut choisir des fichiers, modifier et exécuter des commandes approuvées. Les contrôles disponibles peuvent varier selon la stratégie et le client; vérifiez votre interface actuelle.

Étapes

1. 1

   Déléguer une amélioration de test circonscrite

   Demandez au mode agent d’améliorer un test de la machine à états sans modifier les statuts, les transitions, les minuteries ou les affirmations de l’interface. Révisez son plan.

   Requête

   Améliore un test piloté par les données de la machine à états en utilisant uniquement machine-etats.ts et machine-etats.test.ts. Préserve les quatre statuts exacts et les trois transitions avant. N’ajoute ni minuterie, ni traitement dorsal, ni décision réelle. Demande une approbation avant les commandes.

   Résultats attendus

   • La modification proposée est petite, limitée au test et nomme les invariants fixes qu’elle préserve.
2. 2

   Approuver étroitement et réviser l’écart

   N’approuvez que la commande ciblée, examinez chaque ligne modifiée et refusez les changements aux avertissements ou à la progression de production.

   npm run test -- machine-etats

   Résultats attendus

   • Les tests de la machine à états réussissent et l’écart révisé n’introduit ni nouveau statut ni progression automatisée.

Récupération

• Arrêtez l’agent et écartez ses changements s’il sort des fichiers nommés ou modifie un invariant fixe.
• Si une commande exige un accès plus large que prévu, refusez-la et exécutez vous-même la commande ciblée.

Dépannage

Le mode agent ou un choix de modèle est indisponible.

Utilisez la conversation pour proposer le même écart circonscrit, ou révisez manuellement la requête et le correctif attendu; la disponibilité dépend du forfait, de la stratégie et du client actuels.

Question de vérification

Préalables

• Avoir terminé LAB-06.
• Utiliser la preuve de remplacement enregistrée si les vues d’agent infonuagique ou d’organisation sont indisponibles.

Objectifs d’apprentissage

• Vérifier la parité structurelle et le naturel de l’anglais et du français canadien.
• Traiter la sortie de l’agent infonuagique comme une proposition de demande de tirage à réviser.
• Distinguer la gestion des postes des indicateurs d’utilisation différés.

Repères dans le dépôt

README.md

Réviser les indications du dépôt en anglais.

README.fr.md

Réviser les indications équivalentes en français canadien.

src/content/lab/en-CA.ts

Comparer les identifiants et commandes stables du laboratoire.

src/content/lab/fr-CA.ts

Réviser le français canadien naturel et la parité des limites de sécurité.

Notes sur les preuves

• Le travail de l’agent infonuagique produit de façon asynchrone une demande de tirage qui exige toujours une révision humaine. S’il est indisponible, utilisez la requête, l’écart fictif et la liste de contrôle; ne contournez pas la stratégie de l’organisation.
• La gestion des postes fait foi pour les licences. Les mesures couvrent certaines surfaces, dépendent en partie de la télémétrie de clients à jour et peuvent présenter des lacunes historiques permanentes; tenez compte du délai et des réserves d’attribution.
• Les conditions de volume directes de GitHub ne régissent pas les achats effectués par les canaux Microsoft. Les notes propres aux fournisseurs de modèles peuvent aussi modifier le traitement; un modèle visible ne prouve ni des conditions identiques ni un droit d’utilisation.

Étapes

1. 1

   Réviser la documentation bilingue

   Utilisez Copilot pour signaler les différences de structure, puis révisez manuellement le sens, le français canadien, les commandes, les routes, la sécurité et les affirmations datées.

   Requête

   Compare README.md à README.fr.md et en-CA.ts à fr-CA.ts. Signale les différences de structure, de commandes, de routes, de sécurité et de terminologie. Ne considère pas une traduction littérale comme une preuve de qualité linguistique.

   npm run check:docs

   npm run check:release -- --scope contract

   Résultats attendus

   • Les contrôles automatisés de parité réussissent et une personne révise séparément les corrections linguistiques ou factuelles.
2. 2

   Réviser les preuves de délégation et d’adoption

   Si la stratégie le permet, déléguez un enjeu de documentation et révisez sa demande de tirage. Sinon, révisez un écart fictif local. Notez le type de preuve et la date de la source.

   Requête

   Propose une demande de tirage limitée à la documentation qui corrige un écart vérifié. Garde les identifiants, commandes, routes et limites de sécurité alignés. Inclue une validation ciblée et indique les affirmations qui exigent une vérification actuelle de première partie.

   Résultats attendus

   • La révision distingue une demande de tirage réelle d’une preuve de remplacement et ne déduit ni l’adoption, ni les licences, ni la stratégie à partir d’une seule mesure.

Récupération

• Utilisez l’écart fictif enregistré lorsque la délégation infonuagique, les mesures ou les vues de stratégie sont indisponibles.
• Annulez tout libellé généré qui est peu naturel, non étayé ou incompatible avec le registre d’affirmations du manifeste.

Dépannage

L’agent infonuagique, la page de stratégie ou la vue des mesures est indisponible.

Utilisez la révision locale de remplacement et des sources actuelles de première partie. Consignez la limite plutôt que de modifier la stratégie ou d’inventer une preuve.

Question de vérification

Préalables

• Avoir terminé LAB-00 à LAB-07.
• Choisir un enjeu fictif et local qui n’exige ni service dorsal, ni authentification, ni télémétrie, ni stockage de progression.

Objectifs d’apprentissage

• Définir la portée, les invariants et les exclusions avant la génération.
• Réviser séparément le code, la sécurité, l’accessibilité et les preuves.
• Consigner les décisions que l’automatisation ne pouvait pas prendre.

Repères dans le dépôt

src/lib/domaine/admissibilite.ts

Utiliser une surface de domaine pure pour une modification ou un test circonscrit.

src/components/admissibilite/verificateur-admissibilite.tsx

Utiliser le contrat d’interface accessible comme preuve de révision.

e2e/validation-finale.spec.ts

Réutiliser les contrôles élargis d’accessibilité et de mise en page adaptative.

Notes sur les preuves

• Un dossier de preuve complet contient la requête circonscrite initiale, l’écart révisé, la sortie du test ciblé, les sorties d’analyse et de compilation, les preuves du navigateur au besoin et un court relevé des décisions humaines.

Étapes

1. 1

   Définir et implémenter l’enjeu

   Rédigez les critères d’acceptation, les fichiers nommés, les invariants, les exclusions et le premier contrôle ciblé. Demandez un plan, approuvez un petit écart, puis révisez chaque ligne.

   Requête

   Planifie une petite amélioration dans les seuls fichiers nommés. Préserve les données fictives locales, les noms accessibles français, l’exportation statique et les règles de domaine. Ajoute ou prolonge des tests ciblés. N’ajoute ni service dorsal, ni authentification, ni télémétrie, ni stockage de progression. Arrête-toi pour révision avant les commandes élargies.

   npm run test -- admissibilite

   Résultats attendus

   • Le contrôle ciblé réussit et chaque partie de l’écart correspond à un critère d’acceptation sans modification étrangère.
2. 2

   Constituer le dossier de preuve

   Exécutez les contrôles élargis, inspectez le navigateur si l’interface a changé et notez les décisions factuelles, d’accessibilité, linguistiques ou de portée qui exigeaient un jugement humain.

   Requête

   Révise l’écart final selon les critères d’acceptation et les exclusions. Dresse les preuves de chaque critère, signale les affirmations non étayées et indique les décisions qui exigent encore un jugement humain.

   npm run lint

   npm run test

   npm run build

   npm run test:e2e -- --project=chromium

   Résultats attendus

   • Le dossier distingue les propositions générées, les résultats exécutables, les observations dans le navigateur et les conclusions humaines.

Récupération

• Annulez les modifications étrangères ou risquées et relancez le premier contrôle ciblé avant la validation élargie.
• Si un échec élargi précède le projet intégrateur, consignez sa reproduction et sa disposition au lieu d’affirmer que la livraison est verte.

Dépannage

La modification proposée s’élargit pendant la validation.

Arrêtez, revenez au dernier contrôle ciblé réussi, retirez les changements sans rapport et rétablissez un seul critère d’acceptation réfutable.

Question de vérification