Hands-On Lab and Phase Exit Follow, modify, implement, engineer, and prove Phase 11 understanding
Phase 11 - Persistent Task CRUD API Volume 03 - Database Engineering
Architecture milestone Build persistent CRUD
↓
↓
Phase 11 replaces process memory with durable PostgreSQL-backed application behavior.
Hands-on lab - build persistence without copying blindly Use the reference snapshot only after attempting the steps yourself. The goal is to prove that you understand which layer owns each operation.
Level 1 - Follow • Apply the additive TaskFlow domain migration.
• Run prisma generate and confirm the NestJS build still succeeds.
• Run prisma/seed.ts and record the generated Project ID.
• Register TasksModule and start the API.
• Create, list, read, update, and delete a Task through HTTP.
Level 2 - Modify • Create three Tasks with different priorities.
• Update one Task from TODO to IN_PROGRESS, then DONE.
• Give another Task a description, then set description back to null.
• Verify updatedAt changes while createdAt remains stable.
Level 3 - Implement • Add a service method that returns only Tasks for a given projectId. You may expose it temporarily through a project-scoped route, but do not add pagination yet.
• Return only the fields the caller needs with Prisma select, then explain what changed in the TypeScript return shape.
• Write a PowerShell script that creates a Task, updates it, reads it, restarts the verification manually, and finally deletes it.
Level 4 - Engineer Suppose production already contains 100,000 legacy Todo rows and the business now wants the new Project/Task model. Explain why simply dropping Todo is unacceptable. Propose an additive migration, data backfill/mapping strategy, verification step, and later cleanup migration. No code is required until the migration plan is coherent.
Phase exit questions Question What a strong answer should mention
Why is PrismaService not business logic? It exposes DB access; domain behavior belongs in services
Why does Task need projectId? The durable model requires project ownership/relationship
Why preserve the Todo table temporarily? Additive migration avoids accidental destructive change
Why does TypeScript not validate JSON? Types disappear at runtime; Phase 12 adds validation
What proves persistence? Same row survives NestJS process restart
Why return 404 for P2025? Translate storage-specific absence into HTTP resource semantics
Exit checklist • [ ] prisma validate passes.
• [ ] add_taskflow_domain migration applies.
• [ ] prisma generate runs after schema changes.
• [ ] seed prints a valid Project ID.
• [ ] POST /tasks persists a row.
• [ ] GET collection/detail reads durable rows.
• [ ] PATCH modifies a row.
• [ ] DELETE returns 204 and removes a row.
• [ ] Missing Task returns 404.
• [ ] Restarting NestJS does not erase data.
• [ ] Next.js can render the durable list.
• [ ] You can explain why malformed input remains the next problem.
You now have a real HTTP -> NestJS -> Prisma -> PostgreSQL CRUD path. The next architectural weakness is the untrusted request body. That becomes Phase 12.
Hands On Lab 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 and Phase Exit” as one observable behavior. Write the success signal before touching code.
Trace the boundary map: HTTP contract → controller → service rule → Prisma operation → database row. 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: Working /tasks API supporting create/list/read/update/delete against PostgreSQL with consistent error behavior.. 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 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.
Implement partial update without overwriting omitted fields accidentally.
Use the smallest change that demonstrates this lesson. Stop after it works and capture evidence.PATCH treats omitted values as null/empty
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.