An easy OOP problem for an architect. How to proceed?

Question

OOP

My dear Architect, if you take 5 minutes of your time and look at this example, you will be lucky all year long, I promise ;). ps: as well as I will be very happy.
The thing is, I have a hard time designing the structure for the application, but I did it before the requirements changed. Below I will show the shortest summary and tell you what has changed .. help!

It seems like the picture does not work, if so, then here is a link to Yandex.disk - " https://yadi.sk/i/wo4vavo8g7iuT "
A task was set, which is implemented in the scheme above: This order, in general, is divided into " suborders" (EmployeeOrder), which are distributed to employees. These "sub-orders" also contain date and task, as well as the employee who does (employee).
The customer makes an order (CustomerOrder). The order includes the following information: customer (customer), order date (date), task to be performed (task), order note (note).
It should be possible to add "sub-orders" to the order, delete them.
Task - Task is one of many classes that inherit a common interface.
Everything turned out maybe crooked, but working.
Now there is an additional requirement - to one of the types of tasks, namely "InterpretationTask", you need to add the ability to specify overtime for this order. Overtime is another type of task - "OverWorkInterpretationTask".
But here's the question:Where to put and how to link this overtime with the main order. It turns out that overtime work has the prerequisites to become a separate order - it is based on a separate OverWorkInterpretationTask, and should be processed in the program as a separate unit, but it also contains a lot in common and is generally built on the basis of the primary order - the customer is the same, the date is the same, the performer is the same but task is different.
Architect, waiting for your response!

Answer 1

Заказчик:
   ...

ЗапросЗаказчика:
  заказчик = FK(Заказчик)  
  // заказчик = М2М(Заказчик) - если заказчики могут обьединяться для запроса
  текст_заказа = текст  // raw запрос
  ...

Проект:
  запрос_заказчика = М2М(ЗапросЗаказчика)
  // менеджер разбивает raw запрос на таски
  
ТипТаска:
  название = текст //  интерпритация, сверхурочность, обучение, 

Таск
  проект = FK(Проект)
  // а можно привязать напрямую к ЗапросЗаказчика и убрать сушность Проект
  // проект = FK(ЗапросЗаказчика)
  тип_таска = М2М(ТипТаска) // сверурочное обучение
  исполнитель = FK(исполнитель)
  ...

Исполнитель:
  ...

Answer 2

If the overtime order is processed in the same way as the main one, it belongs to the "suborder" entity. Then it turns out that metaorders aggregate tasks, while the metaorder can be an order or a suborder that shares key properties with the parent order.
And taking into account your comment, it turns out that the order aggregates not only tasks, but also sub-orders. Then it has two aggregating attributes: tasks and suborders.