Chapter 37 only showed the relationship from the Task side – this chapter adds the INVERSE side on Project, so a project knows its OWN tasks.

Adding the tasks property

use Doctrine\Common\Collections\ArrayCollection;
use Doctrine\Common\Collections\Collection;

// ... inside the class:

#[ORM\OneToMany(targetEntity: Task::class, mappedBy: 'project')]
#[Groups(['project:read'])]
private Collection $tasks;

public function __construct()
{
    $this->createdAt = new \DateTimeImmutable();
    $this->tasks = new ArrayCollection();
}

public function getTasks(): Collection
{
    return $this->tasks;
}

EXACTLY the same ArrayCollection/Collection pattern as in the Symfony course (chapter 31) – mappedBy: 'project' points to the project property on Task, EXACTLY the reverse of inversedBy from chapter 37.

The relationship in the API response

curl -k https://localhost/api/projects/1

{
  "id": 1,
  "name": "Website Relaunch",
  "tasks": [
    "/api/tasks/1",
    "/api/tasks/2"
  ]
}

tasks appears as an ARRAY of IRI STRINGS – NOT as embedded task objects. Chapter 40 explains WHY that's the DEFAULT representation and how it can be changed ON PURPOSE.

Read-only: no write group on tasks

tasks DELIBERATELY belongs ONLY to project:read, NOT to project:write – tasks get created via POST /api/tasks (chapter 37), NOT via a nested array when creating a project. This decision is explored further in chapter 45.