Hands-On Lab, Exercises & Phase Exit Rebuild the workspace independently, diagnose realistic failures, reason about dependency ownership, and prove readiness for Next.js.
Hands-On Lab, Exercises and Phase Exit This book turns Phase 02 from reading into skill. The goal is not to remember a sequence of commands; it is to build the repository from a clean parent folder and explain why every root file exists.
Lab - Rebuild the foundation without looking Create a fresh practice folder outside your main course repository. From memory, reproduce the TaskFlow root structure up to the first clean Git commit. Do not copy the reference files until after your attempt.
Lab requirements • Create a new folder and initialize Git. • Create package.json with name, version, private, packageManager, engines and workspace:list. • Create .node-version with the exact course Node version. • Create pnpm-workspace.yaml with apps/* and packages/*. • Run pnpm install and explain why pnpm-lock.yaml belongs in Git. • Create .gitignore and .gitattributes from memory, then compare with the reference. • Create a concise README. • Inspect git diff before staging and git diff --staged before committing. • Commit with a message that describes the checkpoint.
Level 1 - Follow Run these verification commands in your practice repository and write down what each proves:
Get-Location
Get-ChildItem -Force
node --version
pnpm --version
pnpm run workspace:list
git statusLevel 2 - Modify Change the README to explain in your own words why apps/ and packages/ are different. Then use Git to inspect the unstaged change, stage only README.md, inspect the staged diff, and unstage it without discarding your edit.
Hint: this exercise is about Git state, not about rewriting the entire repository.
Level 3 - Implement Without changing directories into a future application, write the command you would use to add a dependency specifically to a workspace package named @taskflow/web. Then explain why using -w instead would change dependency ownership. Do not actually install a framework in Phase 02.
Level 4 - Engineer A teammate proposes this repository immediately:
packages/ common/ types/ utils/ core/ shared/ config/ api-client/
Write a short design review. Which packages would you reject today, and what concrete reuse pressure would justify creating one later? Your answer should reference responsibilities, not aesthetics.
Architecture tracing exercise For each item below, identify its owner:
@nestjs/core root / apps/web / apps/apiTroubleshooting scenarios Scenario A - Root warning You are at taskflow/ and run pnpm add react. pnpm warns about adding a dependency to the workspace root. What is the correct thought process?
Scenario B - Package missing apps/web exists but pnpm workspace:list does not show it. What two conditions should you inspect first?
Scenario C - Secret tracked You accidentally committed .env before adding the ignore rule. Why is editing .gitignore insufficient? What security action may be necessary?
Scenario D - Empty folders vanish After cloning your repository, apps/ and packages/ are missing. Is the clone broken? Explain Git's behavior and why we intentionally avoided placeholder files.
Knowledge check • What makes taskflow a Git repository? • What makes taskflow a pnpm workspace? • Why is the root package.json marked private? • Why do we pin Node in both .node-version and engines.node? • Why should pnpm-lock.yaml be committed? • What does workspace:* guarantee? • Why is ERR_PNPM_ADDING_TO_ROOT useful? • What is the difference between .gitignore and .gitattributes? • Why are Next.js and NestJS not installed at the root? • Why did we avoid Turborepo and shared packages in this phase?
Answer guide Repository: the .git directory created by git init. Workspace: the root pnpm-workspace.yaml plus matching packages. private: prevents accidental publication of the coordination package. Version pins: .node-version drives fnm selection while engines communicates compatibility. Lockfile: reproducible resolved dependency graph. workspace:* requires local workspace resolution. Root warning: forces explicit dependency ownership. .gitignore:
controls intentionally untracked files; .gitattributes: controls file attributes such as text normalization. Framework ownership: install where imported. No Turbo/shared packages yet: no current problem requires them.
Phase exit checklist • I can recreate the repository without copy/pasting every command. • I can explain every root file in one sentence. • I can identify whether a dependency belongs to the root, web, API or a future shared package. • I understand that the monorepo is one repository with multiple independent application runtimes. • I can inspect Git state before and after staging. • I can diagnose workspace-root and version-scope problems systematically. • My main TaskFlow repository has a clean checkpoint commit.
Next - Phase 03: Next.js Fundamentals We finally have a trustworthy home for the frontend. In Phase 03 we will create apps/web as the first real workspace package and teach Next.js as an application runtime rather than as a generator command. The architecture will evolve from a repository with no application runtime to Browser -> Next.js.
serves UI to
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: repository root → workspace package → dependency graph → task runner → artifact. 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: TaskFlow repository root with apps/web, apps/api, shared packages, workspace metadata, root scripts, and clean Git hygiene.. 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.
Create the repository root and initialize Git before generating applications.
Use the smallest change that demonstrates this lesson. Stop after it works and capture evidence.Using relative imports across app boundaries instead of package contracts
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.