Block 3 is COMPLETE. An API that accepted ANY arbitrary JSON has become an API that SPECIFICALLY checks what it stores, and SPECIFICALLY controls what it returns.

What block 3 covered

• Chapter 19: #[Assert\NotBlank]/#[Assert\Length], automatic validation on POST/PUT/PATCH.
• Chapter 20: the violations array in detail, distinguishing 400 vs. 422.
• Chapter 21: more constraints, custom error messages with placeholders.
• Chapter 22: validation groups vs. serialization groups as FUNDAMENTALLY different concepts.
• Chapter 23: normalizationContext and #[Groups] for reading.
• Chapter 24: denormalizationContext for writing, protected fields.
• Chapter 25: computed fields without a database column (isRecent).
• Chapter 26: a custom validator (UniqueProjectName).
• Chapter 27: DTOs as an alternative to groups when the response format diverges more heavily.

Project state at the end of block 3

api/
└── src/
    ├── Entity/
    │   ├── Project.php   ← validation + groups + computed field
    │   └── Tag.php       ← still read-only
    ├── Dto/
    │   └── ProjectSummary.php  ← concept only, NO provider yet
    ├── Validator/
    │   ├── UniqueProjectName.php
    │   └── UniqueProjectNameValidator.php
    └── DataFixtures/
        └── AppFixtures.php

Apply it yourself: completing the Status entity

If the chapter 18 exercise (a custom Status entity) was completed: add #[Assert\NotBlank] to label and #[Assert\Choice(choices: ['#dc2626', '#f59e0b', '#16a34a'])] to color, plus #[Groups(['status:read'])] on BOTH fields.

What's coming in block 4

So far, GET /api/projects ALWAYS returns ALL projects AT ONCE – with hundreds or thousands of entries, NEITHER practical NOR performant. Block 4 (chapters 29-36) introduces pagination, filtering by field values, and sorting – ALL without a SINGLE line of custom query code, EXACTLY like the automatic CRUD from block 2.