2026 Locked Technology & Version Manifest A stable course baseline that prevents silent major- version drift and makes every command, file and explanation internally consistent.
Book 3 · Technology decisions and upgrade policy Course baseline: September 17, 2026 · Windows-first · Project-driven · Production-oriented
Contents 1. Why version locks matter 7. TypeScript
Phase 00 | Page 2 of 6
Why version locks matter in a long course Framework documentation changes quickly. A command that is correct for one major version may be wrong for another. The course therefore separates current ecosystem awareness from course reproducibility. We research current stable releases at course start, choose the baseline, record it, then stop silently upgrading.
A newer version appearing during the course is a note, not permission to rewrite completed phases. Upgrades are separate engineering exercises with their own migration plan.
Course Technology Policy Reason version
Node.js 24.21.0 Locked runtime baseline Node 24 is LTS; Node 26 is Current. LTS
pnpm 12.4.2 Locked package/ Current release includes recent Windows/install workspace manager reliability fixes.
Next.js 16.3.3 Locked frontend 16.3 is Active LTS; 16.3.3 is the August security framework line release baseline.
React 19.3.0 Locked React baseline Current stable React release.
NestJS core 12.0.3 Locked backend Latest Nest 12 patch observed at course lock. framework
Nest CLI 12.0.3 Locked scaffold/CLI Matched to Nest 12 course instructions. baseline
Fastify 5.12.5 Locked HTTP platform Stable v5; v6 is alpha and excluded.
TypeScript 7.0.2 Locked language/tooling Current stable TypeScript release. baseline
Prisma CLI 7.9.1 HARD LOCK Course requirement; Prisma 8 is not used.
@prisma/client 7.9.1 HARD LOCK Must match Prisma 7.9.1 course workflow.@prisma/ 7.9.1 HARD LOCK PostgreSQL driver adapter for Prisma 7. adapter-pg
Phase 00 | Page 3 of 6
Supabase JS 2.116.0 Lock when auth phase Current v2 SDK baseline observed at course lock. begins
TanStack Query 5.103.1 Lock when server-state Stable v5 line. phase begins
Zod 4.6.5 Lock when validation/ Stable v4 baseline. form phases begin
React Hook 7.88.0 Lock when forms phase Stable v7; v8 beta excluded. Form begins
Tailwind CSS 4.3.3 Optional UI track Core course begins with understandable CSS; baseline Tailwind comes as an applied UI track.
Playwright 1.63.0 Lock when E2E phase Cross-browser end-to-end testing baseline. begins
Node.js: prefer LTS for a production learning baseline
Node 26 is the Current release line, while Node 24 is LTS. Production applications should generally target an LTS line rather than using Current merely because the number is larger. The course locks Node 24.21.0 so tooling and native dependencies are reproducible.
Node 26 Node 24 Course Current LTS Node 24.21.0
Figure 1 - Release choice is not “largest version wins” - Course stability prefers an LTS runtime while still documenting what Current means.
Next.js 16.3 is the Active LTS line. The course baseline uses the patched 16.3.3 release rather than an older vulnerable 16.x patch. React 19.3.0 is the current stable React release and is paired with the Next.js 16.3 course line.
Phase 00 | Page 4 of 6
NestJS 12.0.3 is paired with Fastify 5.12.5. Fastify 6 is alpha at the course lock date, so it is intentionally excluded. This is a recurring course lesson: production engineering values maturity and compatibility over novelty.
Prisma 8 is in release-candidate status in September 2026 and changes the workflow substantially. The supplied course specification requires Prisma 7.9.1. That is a sensible educational constraint: Prisma 7 remains supported, and locking 7.9.1 prevents a long-running course from mixing Prisma 7 commands with Prisma 8 behavior.
Every Prisma command in this course must be version-consistent with 7.9.1. If a later phase needs an upgrade, the upgrade is taught as a migration project rather than performed silently.
# Run from the appropriate project/workspace directory
node -v
pnpm -v
pnpm exec tsc -v
pnpm exec next --version
pnpm exec nest --version
pnpm exec prisma version# Package versions can also be inspected from package.json / pnpm-lock.yaml
1. Pin majors and important patch versions deliberately. 2. Commit the lockfile. 3. Never copy a command from documentation without checking the documentation version. 4. Security patches receive explicit review; they are not ignored merely because versions are locked. 5. Major upgrades happen between milestones, with tests green before and after.
• Node.js Releases: nodejs.org/en/about/previous-releases and release blog.
Phase 00 | Page 5 of 6
The manifest is a contract. It exists so a lesson written in Phase 08 still makes sense when you are in Phase 30.
Phase 00 | Page 6 of 6
2026 Version Manifest 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 “2026 Version Manifest” as one observable behavior. Write the success signal before touching code.
Trace the boundary map: User intent → UI boundary → API contract → business rule → persistence → observable result. 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 one-page architecture map plus an ADR-style note describing the responsibilities of Next.js, NestJS, Prisma, PostgreSQL/Supabase, and supporting infrastructure.. 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 “2026 Version Manifest” to a different TaskFlow resource or input. Write the acceptance criteria first, implement it, and provide the evidence that each criterion is satisfied.
Write one responsibility and one non-responsibility for each layer.
Use the smallest change that demonstrates this lesson. Stop after it works and capture evidence.Treating Supabase as one undifferentiated magic backend
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.