GitHub Copilot Business fundamentals lab

Prerequisites

• A local clone of this repository
• Node.js and npm versions compatible with the tested environment
• A GitHub Copilot Business seat governed by your organization

Learning objectives

• Identify the repository's local data boundary.
• Separate public source context from secrets and real applicant data.
• Run a focused validation command and interpret its evidence.

Repository references

src/app/layout.tsx

Confirm the application shell and permanent safety notice.

src/lib/stockage/db.ts

Inspect the browser-local IndexedDB boundary.

Evidence notes

• Repository source and focused test output are the evidence for this module; generated explanations are proposals until verified.

Steps

1. 1

   Inspect the repository boundary

   Open the two repository references and identify where the document language, safety notice, and local database are defined.

   Ask Copilot to explain only those selected files, then verify every statement against the source.

   Prompt

   Explain the local data and safety boundaries shown only in src/app/layout.tsx and src/lib/stockage/db.ts. Cite the file for every statement and identify anything the files do not prove.

   Expected results

   • You can explain that the application is a French Canadian static prototype whose records remain in browser-local IndexedDB.
2. 2

   Run focused foundation tests

   Run the focused command from the repository root and review the test names before accepting the result.

   npm run test -- lab-content fundamentals-lab

   Expected results

   • The locale-contract and semantic-renderer tests pass in both languages.

Recovery

• Discard any generated explanation that cannot be traced to the selected files.
• If dependencies are missing, run npm ci from the repository root, then repeat the focused test command.

Troubleshooting

The focused test command cannot find the lab tests.

Confirm that dependencies were installed from the repository root and that the two requested test file names are present under src.

Knowledge check

Prerequisites

• Complete LAB-00.
• Open Copilot Chat in VS Code at the repository root.

Learning objectives

• Distinguish static export from runtime services.
• Trace validation and browser persistence across selected files.
• Replace generated assumptions with cited source evidence.

Repository references

src/lib/domaine/demande.types.ts

Review the versioned local record and fixed status types.

src/lib/domaine/demande.schemas.ts

Compare draft and simulated-submission validation.

src/lib/stockage/db.ts

Confirm Dexie stores data in browser-local IndexedDB.

next.config.ts

Confirm the static-export boundary.

Evidence notes

• The source proves static export, two validation levels, fixed domain values, and local IndexedDB persistence. It does not prove a hosted deployment or an organization policy configuration.

Steps

1. 1

   Request a bounded architecture map

   Select only the four references above and ask for a concise data-flow map with a citation for each claim.

   Prompt

   Using only the selected files, map input, validation, persistence, and build output. For each claim, cite the file and mark assumptions as unverified.

   Expected results

   • The map identifies permissive draft validation, stricter simulated-submission validation, IndexedDB persistence, and static export.
2. 2

   Check the map against the repository

   Open each cited location. Remove claims about API routes, authentication, server storage, or deployment because the selected source does not establish them.

   npm run build

   Expected results

   • The static build completes and emits the export without requiring a backend or runtime environment variable.

Recovery

• If the answer ranges beyond the selected files, restate the file boundary and regenerate it.
• If the build fails, preserve the output and diagnose that failure before accepting the architecture map.

Troubleshooting

Copilot describes a typical Next.js server application.

Point it to output: export in next.config.ts and ask it to retract every server claim not supported by the selected files.

Knowledge check

Prerequisites

• Complete LAB-01.
• Start from a clean diff or isolate your exercise changes.

Learning objectives

• Frame a test-only task with explicit invariants.
• Review generated assertions against the pure eligibility function.
• Use focused evidence before broader validation.

Repository references

src/lib/domaine/admissibilite.ts

Understand the pure eligibility result and criterion order.

src/lib/domaine/admissibilite.test.ts

Extend the existing table-driven test style.

Evidence notes

• A useful test checks the exact missing criteria and their order, not only the number of failures.

Steps

1. 1

   Generate one mixed-response case

   Ask for a test-only diff that follows the existing parameterized style and leaves admissibilite.ts unchanged.

   Prompt

   Add one table-driven mixed-response case to src/lib/domaine/admissibilite.test.ts. Assert the exact missing criteria in source order. Do not edit production code.

   Expected results

   • The proposed diff changes only the focused test file and names the expected missing criteria explicitly.
2. 2

   Run and inspect focused evidence

   Review the diff, run the focused test, then confirm production source remains unchanged.

   npm run test -- admissibilite

   Expected results

   • The eligibility tests pass and the diff contains no production behaviour change.

Recovery

• If a generated expectation conflicts with source order, correct the test from admissibilite.ts rather than the generated explanation.
• If production code changed, discard that portion and regenerate a test-only diff.

Troubleshooting

Vitest reports that no matching test file was found.

Run the command from the repository root and use the existing admissibilite file name as the filter.

Knowledge check

Prerequisites

• Complete LAB-02.
• Know how to inspect a Git diff and revert an exercise change.

Learning objectives

• Locate two duplicate implementations.
• Evaluate whether one pure helper is justified.
• Test stale and future timestamp boundaries before broad validation.

Repository references

src/components/demandes/assistant-provider.tsx

Inspect the first prochaineDateModification implementation.

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

Inspect the second implementation.

Evidence notes

• The duplicated functions are the evidence for extraction; passing focused component tests and boundary tests are the evidence for preserved behaviour.

Steps

1. 1

   Ask for a constrained plan

   Request a plan before edits. Require one pure helper, direct call-site replacement, and tests for stale and future timestamps.

   Prompt

   Plan the smallest refactoring that replaces the two prochaineDateModification implementations with one pure helper. Preserve monotonic ISO output. Include stale and future timestamp tests. Do not edit yet.

   Expected results

   • The plan names both call sites, one helper location, focused tests, and no unrelated changes.
2. 2

   Apply, review, and validate

   Approve only the bounded files, inspect the diff, then run the two affected component test filters.

   Prompt

   Implement the approved minimal plan. Stop after the helper, its boundary tests, and the two call-site replacements, then summarize the diff.

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

   Expected results

   • Focused tests pass, both components use one helper, and stale or future input still yields a later ISO timestamp.

Recovery

• Revert the exercise diff if timestamp ordering changes or the scope grows beyond the named files.
• If focused tests fail, compare old and new outputs at the failing boundary before making another edit.

Troubleshooting

The generated helper returns the current time for a future input.

Reject the change. The helper must return a timestamp later than both the current time and the supplied timestamp.

Knowledge check

Prerequisites

• Complete LAB-03.
• Install Playwright browsers required by the project.

Learning objectives

• Use exact French accessible names in an English instruction.
• Test focus and missing-question details, not appearance alone.
• Run Chromium before the broader browser matrix.

Repository references

src/components/admissibilite/verificateur-admissibilite.tsx

Trace incomplete-answer focus and messages.

e2e/accessibilite.spec.ts

Follow the existing axe pattern.

e2e/validation-finale.spec.ts

Reuse overflow and keyboard validation patterns.

Evidence notes

• Focus on the alert, exact missing-question text, no serious or critical axe findings, and no horizontal overflow are separate observable checks.

Steps

1. 1

   Draft the missing-answer flow

   Ask for one Playwright case that submits with unanswered questions, verifies focus and details, runs axe, and checks overflow.

   Prompt

   Add one focused Playwright test for incomplete eligibility answers. Use the exact French accessible button name, assert alert focus and each missing question, run axe, and check horizontal overflow. Do not change the component.

   Expected results

   • The proposed test uses roles and accessible names rather than CSS-only selectors for user-facing controls.
2. 2

   Run the browser check

   Review the generated selectors against the component, then execute the scoped Chromium check.

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

   Expected results

   • The incomplete flow passes with focus, missing-question, axe, and overflow evidence.

Recovery

• If the grep matches no test, align the test title and command before broadening execution.
• If axe or focus fails, fix the underlying semantics rather than weakening the assertion.

Troubleshooting

The English instruction cannot find the submit button.

Use the application’s exact French accessible name: Vérifier l’admissibilité.

Knowledge check

Prerequisites

• Complete LAB-04.
• Use only the fictitious fixture under e2e/fixtures.

Learning objectives

• Trace PDF validation and IndexedDB persistence.
• Verify selection produces no API request.
• Reject unsupported antivirus, encryption, upload, or server-validation claims.

Repository references

src/lib/fichier/pdf-local.ts

Review local extension, MIME, emptiness, and size validation.

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

Trace local selection and object URL lifecycle.

src/lib/stockage/documents.repository.ts

Confirm browser-local document persistence.

e2e/parcours-local.spec.ts

Inspect existing no-network and persistence evidence.

Evidence notes

• Source review can establish local validation and persistence. It cannot establish device security, malware safety, encryption at rest, or legal compliance.

Steps

1. 1

   Classify privacy claims

   Ask for a three-column review: proven by source, not proven, and prohibited inference. Verify every row yourself.

   Prompt

   Review only the selected PDF and repository files. Classify each privacy or security claim as proven by source, not proven, or prohibited inference. Cite exact files. Do not claim upload, antivirus, encryption, or server validation.

   Expected results

   • The review states that validation and storage are local while explicitly rejecting capabilities absent from source.
2. 2

   Verify local-only network behaviour

   Run the existing PDF browser scenario and inspect any captured requests before accepting the review.

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

   Expected results

   • The fictitious PDF is validated and restored locally without an application API request.

Recovery

• Delete the selected fictitious document through the application if you want to reset browser-local state.
• Remove any generated claim that lacks direct source or browser evidence.

Troubleshooting

A blob URL appears and is mistaken for an upload.

A browser blob URL references local in-memory content. Confirm network behaviour in Playwright rather than inferring an upload from the URL.

Knowledge check

Prerequisites

• Complete LAB-05.
• Know how to review proposed file edits and command approvals in your IDE.

Learning objectives

• Constrain agent scope to named files and invariants.
• Review commands before approval.
• Reject real processing or timer-based progression claims.

Repository references

src/lib/domaine/machine-etats.ts

Review the three allowed forward transitions.

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

Lock the four statuses and forbidden transitions.

src/components/demandes/suivi-simule.tsx

Preserve exact simulation and local-only wording.

Evidence notes

• Current product guidance says agent mode can choose files, edit, and run approved commands. Available controls can vary by policy and client, so verify your current interface rather than assuming it.

Steps

1. 1

   Delegate a constrained test improvement

   Ask agent mode to improve one state-machine test without changing statuses, transitions, timers, or UI claims. Review its plan before approval.

   Prompt

   Improve one table-driven state-machine test using only machine-etats.ts and machine-etats.test.ts. Preserve the four exact statuses and three forward transitions. Do not add timers, backend processing, or real decision claims. Ask before running commands.

   Expected results

   • The proposed change is small, test-focused, and names the fixed invariants it preserves.
2. 2

   Approve narrowly and review the diff

   Approve only the focused test command, inspect every changed line, and reject edits to disclaimer text or production progression.

   npm run test -- machine-etats

   Expected results

   • The state-machine tests pass and the reviewed diff introduces no new status or automated progression.

Recovery

• Stop the agent and discard changes if it reaches outside the named files or alters a fixed invariant.
• If a command requires broader access than expected, decline it and run the focused command yourself.

Troubleshooting

Agent mode or a model choice is unavailable.

Use chat to draft the same bounded diff, or review the provided prompt and expected patch manually; availability depends on current plan, policy, and client.

Knowledge check

Prerequisites

• Complete LAB-06.
• Use the recorded fallback if cloud-agent or organization views are unavailable.

Learning objectives

• Check English and Canadian French structural parity and natural language.
• Treat cloud-agent output as a pull-request proposal requiring review.
• Separate seat management from lagging usage indicators.

Repository references

README.md

Review English repository guidance.

README.fr.md

Review equivalent Canadian French guidance.

src/content/lab/en-CA.ts

Compare stable lab IDs and commands.

src/content/lab/fr-CA.ts

Review natural Canadian French and safety parity.

Evidence notes

• Cloud-agent work is asynchronous pull-request evidence that still requires human review. If unavailable, use the prompt, mock diff, and review checklist; do not bypass organization policy.
• Seat management is the licensing source of truth. Usage metrics cover selected surfaces, depend partly on current client telemetry, and can have permanent historical gaps; allow for reporting lag and attribution caveats.
• GitHub-direct volume terms do not govern Microsoft purchasing channels. Provider-specific model footnotes can also change handling conditions, so visible model options do not prove identical terms or entitlement.

Steps

1. 1

   Review bilingual documentation

   Use Copilot to flag structural differences, then manually review meaning, Canadian French, exact commands, routes, safety wording, and dated claims.

   Prompt

   Compare README.md with README.fr.md and en-CA.ts with fr-CA.ts. Report structural, command, route, safety, and terminology differences. Do not treat literal translation as proof of language quality.

   npm run check:docs

   npm run check:release -- --scope contract

   Expected results

   • Automated parity checks pass and a human reviewer records any language or factual corrections separately.
2. 2

   Review delegation and adoption evidence

   If policy permits, delegate a documentation-only issue and review its pull request. Otherwise, review a mock diff locally. Record evidence type and current source date.

   Prompt

   Propose a documentation-only pull request that corrects one verified discrepancy. Keep stable IDs, commands, routes, and safety wording aligned. Include focused validation and identify claims needing current first-party verification.

   Expected results

   • The review distinguishes a live pull request from fallback evidence and does not infer adoption, licensing, or policy from one metric.

Recovery

• Use the recorded mock diff when cloud delegation, metrics, or organization policy views are unavailable.
• Revert generated wording that is unnatural, unsupported, or inconsistent with the manifest claim register.

Troubleshooting

The cloud agent, policy page, or metrics view is unavailable.

Use the local fallback review and current first-party sources. Record the limitation rather than changing policy or inventing evidence.

Knowledge check

Prerequisites

• Complete LAB-00 through LAB-07.
• Choose a fictitious, local-only issue that needs no backend, authentication, telemetry, or progress storage.

Learning objectives

• Frame scope, invariants, and exclusions before generation.
• Review code, safety, accessibility, and evidence separately.
• Record decisions that automation could not make.

Repository references

src/lib/domaine/admissibilite.ts

Use a pure domain surface for a bounded change or test.

src/components/admissibilite/verificateur-admissibilite.tsx

Use the accessible UI contract as review evidence.

e2e/validation-finale.spec.ts

Reuse broad accessibility and responsive checks.

Evidence notes

• A complete evidence packet contains the original bounded prompt, reviewed diff, focused test output, lint and build output, browser evidence where relevant, and a short human-decision record.

Steps

1. 1

   Frame and implement the issue

   Write acceptance criteria, named files, invariants, exclusions, and the first focused check. Ask for a plan, approve a small diff, then review each changed line.

   Prompt

   Plan one small improvement using only the named files. Preserve local-only fictitious data, French accessible names, static export, and existing domain rules. Add or extend focused tests. Do not add backend, auth, telemetry, or progress storage. Stop for review before broad commands.

   npm run test -- admissibilite

   Expected results

   • The focused check passes and the diff is traceable to each acceptance criterion without unrelated edits.
2. 2

   Build the evidence packet

   Run broad checks, inspect the browser when UI changed, and record which factual, accessibility, language, or scope decisions required human judgment.

   Prompt

   Review the final diff against the acceptance criteria and exclusions. List evidence for each criterion, flag unsupported claims, and identify decisions that still require human judgment.

   npm run lint

   npm run test

   npm run build

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

   Expected results

   • The evidence packet separates generated proposals, executable results, browser observations, and human conclusions.

Recovery

• Revert unrelated or unsafe changes and rerun the earliest focused check before broad validation.
• If a broad failure predates the capstone, record reproducible evidence and its disposition instead of claiming a green release.

Troubleshooting

The proposed change expands while validation is running.

Stop, return to the last green focused check, remove unrelated edits, and re-establish one falsifiable acceptance criterion.

Knowledge check