Hands-On Lab, Exercises & Phase Exit Prove the environment through observable commands, Git history, a verification report, four exercise levels, and a Phase 01 assessment.
Book 7 · Lab & assessment Course baseline: September 17, 2026 · Windows-first · Project-driven · Production-oriented
Contents 1. Lab A - workspace 6. Exercise ladder
Phase 01 | Page 2 of 6
Phase 01 hands-on lab: prove the workstation This lab turns the phase from reading into observable skill. Complete it in an ordinary PowerShell session. If your organization prevents an installation step, record the constraint and verify everything that is permitted.
$DevRoot = "$HOME\Developer" New-Item -ItemType Directory -Path $DevRoot -Force Set-Location $DevRoot New-Item -ItemType Directory -Path "full-stack-2026-lab" -Force Set-Location "full-stack-2026-lab" Get-Location
Verification The current path ends with Developer\full-stack-2026-lab .
fnm use 24.21.0
node -v
npm -v
pnpm -v
git --version
code --versionRecord the output in your notes. Do not continue until unexpected versions have an explanation.
Get-Command node
Get-Command npm
Get-Command pnpm
Get-Command git
Get-Command codeFor every command, write one sentence explaining which directory owns the executable or shim.
Phase 01 | Page 3 of 6
git init
"# Full-Stack Developer 2026 - Environment Lab" | Set-Content README.md
git add README.md
git diff --staged
git commit -m "docs: initialize environment lab"
git status
git log --oneline -3"Phase 01 Environment Report" | Set-Content environment-report.txt "Generated: $(Get-Date -Format o)" | Add-Content environment-report.txt "PowerShell: $($PSVersionTable.PSVersion)" | Add-Content environment-report.txt "Node: $(node -v)" | Add-Content environment-report.txt "npm: $(npm -v)" | Add-Content environment-report.txt "pnpm: $(pnpm -v)" | Add-Content environment-report.txt "Git: $(git --version)" | Add-Content environment-report.txt Get-Content environment-report.txt
This is intentionally not an automated installer. It is evidence that the learner understands verification.
Level 1 - Follow 1. Run every verification command and record expected outputs. 2. Open the lab with code . . 3. Create and commit one Markdown file.
Level 2 - Modify 1. Create a second directory whose name contains spaces and navigate into it correctly. 2. Temporarily append a fake directory to the current shell PATH, print PATH, then close the shell and explain why it disappeared. 3. Use Get-Command -All node and explain the result.
Level 3 - Implement 1. Write a PowerShell script named verify-environment.ps1 that checks the five tool versions and exits non-zero if the Node or pnpm version is not the locked baseline. 2. Do not copy a complete solution from the book. Use if , command output, and exit .
Phase 01 | Page 4 of 6
Level 4 - Engineer Design a small onboarding procedure for a new developer on a restricted corporate laptop. Your plan must avoid unnecessary administrator rights, preserve existing PowerShell configuration, verify PATH resolution, and produce an evidence report.
1. Why is Node treated as a project/runtime dependency rather than a permanent global assumption? 2. Why can corepack enable fail for a non-admin user even when Node itself works? 3. What does pnpm exec protect us from? 4. Why should Get-Location be one of the first commands when a project CLI cannot find its files? 5. What is the difference between Git identity and GitHub authentication? 6. Why is git diff --staged valuable before a commit? 7. What does PATH determine? 8. Why can a freshly installed command require a new terminal?
1. Projects need reproducible runtime compatibility; version managers make selection explicit. 2. It may attempt to write shims into a protected machine-wide Node directory. 3. It resolves a tool from project dependencies, preserving the project's exact version. 4. Relative configuration and manifest discovery depends on the working directory. 5. Git identity is commit metadata; GitHub authentication authorizes access to a remote service. 6. It shows exactly what the next snapshot will contain. 7. Which executable directories the shell searches, in order. 8. The old process inherited environment values before installation changed persistent settings.
□ I can explain working directory, PATH, and environment variables. □ I can switch to Node 24.21.0 LTS with fnm. □ npm reports 11.19.0. □ pnpm reports 12.4.2 from an ordinary user shell. □ Git is installed, configured, and understood at working-tree/staging/commit level. □ VS Code opens the current workspace from PowerShell. □ I can diagnose “command not recognized,” EPERM, and wrong-version problems. □ I completed the environment report and committed the practice repository.
Phase 01 | Page 5 of 6
Phase 02 - Monorepo, pnpm Workspaces & Repository Foundation. We will finally create the real TaskFlow repository. Phase 01 taught us to trust the workstation; Phase 02 will teach us how to structure a repository that can contain a Next.js frontend and NestJS backend without premature abstraction.
Figure 2 - Phase 01 to Phase 02 - The environment becomes infrastructure beneath the real project rather than something we keep modifying every lesson.
Phase 01 · Book 7 · Lab & assessment
Phase 01 | Page 6 of 6
Hands On Lab Exercises and Phase Exit matters because it changes a real boundary in TaskFlow. The goal is to understand the inputs, owner, observable output, and failure modes before adding more abstraction.
Restate the goal of “Hands On Lab Exercises and Phase Exit” as one observable behavior. Write the success signal before touching code.
Trace the boundary map: source file → tool/runtime → process → OS environment → terminal evidence. Mark the one boundary this lesson changes.
Inspect the current repository state and record the exact files, route, table, or runtime involved. Avoid creating an abstraction before you can name the existing owner.
Implement the smallest vertical slice. Add one coherent change, run the narrowest verification command, and read the output before continuing.
Connect the slice to TaskFlow’s phase artifact: A verified toolchain report showing shell, Git, Node, Corepack/pnpm, editor, PATH, ports, and diagnostic commands.. Verify behavior from the outside as a user or API client would.
Create one controlled failure that is safe to reproduce. Predict the symptom first, capture evidence, locate the earliest broken boundary, then fix only that cause.
Close the reference and rebuild or explain the core change from memory. Record what you would monitor or test before trusting the same change in production.
Input -> owner -> transformation -> observable output -> failure evidenceDo not copy this as a finished answer. Predict what each boundary does, type the smallest useful slice, run it, then compare the result with your prediction.
Return to the nearest observable boundary: input, network, process log, database, or rendered UI. Compare actual evidence with the predicted path.
Change one variable at a time and reproduce the original failure after the fix; otherwise you have correlation, not diagnosis.
Without copying the final source, create a second small scenario that applies “Hands On Lab Exercises and Phase Exit” to a different TaskFlow resource or input. Write the acceptance criteria first, implement it, and provide the evidence that each criterion is satisfied.
Open ordinary PowerShell and record pwd, whoami, and PATH-related observations.
Use the smallest change that demonstrates this lesson. Stop after it works and capture evidence.Different shells resolving different PATH values
Predict the symptom before causing the failure. Then locate the earliest boundary where reality diverges from expectation.Why does this responsibility live here, what input does it trust, what output proves success, and what would go wrong if another layer owned it?
If your explanation is vague, repeat the boundary trace before moving on.Close the reference. Reproduce the core idea from memory or explain the exact request/data flow aloud. Then check your diff or notes for accidental shortcuts that bypass validation, authorization, error handling, or verification earned in earlier phases.