Engineering Workflow, Windows First How professional developers move from requirement to branch, code, verification, debugging, review and deployable change.
Book 4 · Workflow, discipline and development habits Course baseline: September 17, 2026 · Windows-first · Project-driven · Production-oriented
Contents 1. The engineering loop 7. Environment variables and secrets
Phase 00 | Page 2 of 6
The engineering loop matters more than typing speed requirement, locate the responsible layer, make the smallest coherent change, verify behavior, and preserve a clean history.
Figure 1 - Professional change loop - This loop is repeated from the first health endpoint to production deployment.
The course uses ordinary Windows PowerShell as the primary shell. Every command will say where it runs. Paths containing spaces are quoted. Bash-only syntax is never silently mixed into PowerShell instructions.
cd "C:\Projects\TaskFlow\apps\api"
Get-Location
pnpm run start:devPhase 00 | Page 3 of 6
A correct command executed from the wrong workspace can produce a misleading package, script or configuration error. Always include location in your debugging model.
User-profile tooling instead of unnecessary admin rights
On restricted Windows machines, global package setup should prefer user-owned locations rather than assuming Administrator privileges. The course will document permission failures such as Corepack attempting writes under C:\Program Files\nodejs , then teach a user-profile installation strategy when appropriate.
taskflow/ workspace
apps/web apps/api Next.js NestJS + Fastify
packages/* only when justified
Figure 2 - Repository responsibility map - The monorepo is a container for independently owned applications and later shared packages.
Phase 00 | Page 4 of 6
When an error appears, avoid replacing whole files. First determine which layer can actually produce the observed symptom.
Button does nothing Browser/UI Console, event handler, disabled state.
Request blocked before API Browser/network DevTools Network, CORS message.
404/405 HTTP/controller routing Method/path mismatch.
401/403 Authentication/authorization Token/guard/permission logs.
400/422 Validation boundary DTO/schema error details.
409 Business rule/database constraint Unique conflict or domain rule.
500 Backend runtime/data access Server logs and stack trace.
Figure 3 - Debug from the outside inward - Evidence narrows the search area before code changes begin.
Configuration enters the course when a layer first needs it. Secrets never appear in screenshots, example repositories or PDF source snippets. Public browser variables and server-only secrets are treated differently.
Phase 00 | Page 5 of 6
# Example documentation only
DATABASE_URL="postgresql://..."
NEXT_PUBLIC_API_URL="http://localhost:4000"1. Start from a known-green main branch. 2. Create a focused branch for a coherent change. 3. Make small, verifiable commits. 4. Keep generated artifacts and secrets out of commits unless intentionally versioned. 5. Before merge: lint, typecheck, tests and production build. 6. Review the diff for accidental files and architecture drift.
□ Requirement is satisfied. □ Expected behavior was manually verified. □ Error/failure path is understood. □ Lint passes. □ Typecheck passes. □ Relevant tests pass. □ Production build passes when applicable. □ No secret or debug artifact leaked. □ Architecture documentation still matches reality.
AI can accelerate explanation, search, refactoring and test design, but it should not erase your mental model. The course treats AI like a pair programmer: it may propose changes, but you should be able to explain what layer changed, why the change is correct, and how you verified it.
Never accept a large generated patch as “correct” because it compiles. Read the diff, identify the responsibility of every new file, and verify the behavior at the boundary that matters.
Phase 00 | Page 6 of 6
CI turns repository rules into automated gates. A useful pipeline must be understandable, reproducible locally, secure, and able to fail for the right reasons.
Restate the goal of “Engineering Workflow” as one observable behavior. Write the success signal before touching code.
Trace the boundary map: git event → runner → install → quality gates → artifact/deploy decision. 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.
name: CI
on: [pull_request]
jobs:
verify:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: corepack enable
- run: pnpm install --frozen-lockfile
- run: pnpm lint && pnpm typecheck && pnpm test && pnpm buildDo 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.
Compare Node/pnpm versions, lockfile state, environment variables, OS assumptions, and generated artifacts.
Set least-privilege permissions at workflow/job level and isolate untrusted pull-request code from secrets.
Without copying the final source, create a second small scenario that applies “Engineering Workflow” to a different TaskFlow resource or input. Write the acceptance criteria first, implement it, and provide the evidence that each criterion is satisfied.
Trace create-task from click to database commit and back to the screen.
Use the smallest change that demonstrates this lesson. Stop after it works and capture evidence.Choosing infrastructure before defining responsibilities
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.