Призначення TU

src/tus/tu-assignment.service.ts — єдиний виконавець змін призначень TU: тімлід і оператор у змінах, client manager картки, зняття призначень.

Дані: project_tus (assignments) · Swagger: тег TUs · План: ProjectTU

Що робить модуль

Змінює тімліда й оператора у змінах TU з перевіркою прав, кандидата й адмін панелі та CAS-записом.
Знімає призначення за командою Stack і під час refresh TU.
Супроводжує кожну зміну однаковим набором ефектів: дзеркало в Stack, події в tu_logs, оновлення зв’язків TU, повідомлення Electron Gateway.

Усі джерела змін — frontend, Stack, refresh — проходять через один виконавець. Новий тригер визначає лише вибір TU, правило і ініціатора.

Для пакета змін один раз завантажуються TU, згадані користувачі Stack і адмін панелі.
Кожна TU обробляється окремо: помилка потрапляє у failed, обробка решти триває.
Права:
- тімлід — director; client manager на своїх TU; top manager у межах своєї структури (поточний і новий тімлід — з його структури);
- оператор — тімлід у своїй зміні; top manager у зміні свого тімліда.
Видалена TU не призначається. Кандидат — активний користувач потрібної ролі в проєкті. Тімлід належить адмін панелі TU (збіг за canonical або партнерським ID адмін панелі) і не стоїть в іншій зміні тієї ж TU. Оператор належить тімліду зміни.
CAS. Зміна тімліда звіряє лише поточного тімліда і знімає оператора зміни; зміна оператора звіряє пару тімлід + оператор. При розбіжності запис не виконується, TU повертається в failed.
Ефекти рахуються з різниці стану зміни до і після запису.

Тригер	Що знімається	Помилка
Stack, `POST /v2/internal/tus/detach`: тімліда чи оператора заблоковано або видалено, тімліду змінено адмін панель, оператору — тімліда	роль цього користувача в усіх TU проєкту	TU з помилкою у `failed`, решта обробляється
Refresh TU: TU переїхала до іншої адмін панелі або видалена	тімлід і оператор у всіх змінах TU	зупиняє refresh

Client manager цими проходами не знімається: він закріплений за карткою TU.

Після запису кожної TU:

Дзеркало в Stack: TU додається або прибирається в профілях тімліда й оператора — для legacy-читань.
Події призначення і зняття в tu_logs — окремо для тімліда, оператора і client manager; ініціатор — користувач з токена або система.
Перерахунок зв’язків TU від моменту зміни — також після часткового запису.

Після всього пакета — повідомлення в Electron Gateway: спершу зняті TU, потім призначені. Недоступність Gateway логується і не скасовує зміну.

Роут	Що робить	Ролі
`POST /v2/tus/changeTeamLeads`	призначення або зняття тімліда у зміні для пакета TU	director, top manager, client manager
`POST /v2/tus/changeOperators`	призначення або зняття оператора у зміні для пакета TU	top manager, тімлід

Роут	Хто викликає	Навіщо
`POST /v2/internal/tus/detach`	Stack	зняття ролі користувача з усіх TU проєкту

Зміна тімліда завжди знімає оператора зміни: оператор закріплений за парою з тімлідом, а не за зміною.
Дзеркало в профілях Stack існує лише для legacy-читань і позначене TODO(tu-user-link); нові логіки його не читають.
Платформа надсилає в Electron Gateway лише факти змін; оновлення програми оператора виконує Gateway (поки — stack-golden).

Синхронізація client manager зі Stack реалізована в сервісі, але не підключена: frontend-роуту й internal-виклику немає. Client manager у project_tus заповнює лише міграція; зміна картки в Stack на платформу не доходить.