diff --git a/angular/angular-teamwork-ru.md b/angular/angular-teamwork-ru.md
new file mode 100644
index 000000000..0832ebfc5
--- /dev/null
+++ b/angular/angular-teamwork-ru.md
@@ -0,0 +1,133 @@
+# Командный playbook: чеклисты и протоколы
+
+---
+
+В этом документе **W1, W2, W3 ...** — это номера недель командной работы (W1 — первая неделя командного таска). Все артефакты и ритуалы привязаны к этой шкале.
+
+## Чеклист первой недели
+
+К концу W1 (первой недели командной работы) в команде должны существовать все эти артефакты. Проверять — на созвоне в конце недели по списку.
+
+### Команда и роли
+
+- [ ] Команда сформирована и зафиксирована письменно (в README.md): кто и какой github-логин.
+- [ ] Тимлид назначен явно. Конкретный человек (ментор или студент), который двигает встречи и репозиторий. Можно ротировать, но в каждый момент времени кто-то один.
+- [ ] Распределение задач проговорено публично в чате. Не «все делают всё», а «А — роутинг и shared, B — стейт, C — дизайн и стили, D — CI и тесты».
+- [ ] Скриншот часовых поясов всех участников закреплён в чате.
+- [ ] Каждый участник написал хотя бы одну запись в дневник.
+
+### Репозиторий
+
+- [ ] Репозиторий публичный.
+- [ ] `README.md` заведён и ведётся как живой документ: описание проекта, список команды (с github-логинами), стек, как запустить локально, ссылка на деплой и дашборд. Обновляется каждый раз, когда меняется что-то из перечисленного, а не «заполним перед защитой».
+- [ ] `DECISIONS.md` заведён в корне репозитория — это журнал командных решений: выбор стека, архитектурные развилки, изменения scope, договорённости про процессы. Первая запись делается на первой неделе: «выбрали X, потому что Y, альтернативы рассмотрели Z». Каждое следующее значимое решение — новая запись с датой и автором.
+- [ ] Защищены `main` и `develop` (или эквивалент): минимум 1–2 аппрува на merge.
+- [ ] Шаблон PR (`.github/PULL_REQUEST_TEMPLATE.md`) с минимальным чеклистом: что сделано, как тестировал, какие риски.
+- [ ] Конвенция имени веток зафиксирована в README или CONTRIBUTING.md.
+- [ ] Husky / pre-commit хук поднят: линтер, формат, типы.
+- [ ] CI запускает на каждый PR: build, lint, тесты.
+- [ ] Если работаете с кодинг-агентом: AGENTS.md или CLAUDE.md в корне с базовыми конвенциями проекта.
+
+### Ритуалы
+
+- [ ] Зафиксирован один еженедельный созвон команды (день, время в часовом поясе, длительность). Никто его не пропускает без предупреждения.
+- [ ] Ритуал регулярного 1-строчного сигнала в чате («сегодня делаю X, блокеров нет / есть Y»). Не для отчётности, а чтобы команда видела, кто жив.
+- [ ] У каждой команды должне быть свой канал в Telegram(или на отдельный Discord сервер): общий, без личек по проектным темам. Личка — для «давай созвонимся», не для обсуждения проекта. Все решения и обсуждения должны быть видны для всех.
+
+### Решения и архитектура
+
+- [ ] Стек выбран и зафиксирован записью в `DECISIONS.md`. Если выбор был спорным — в записи указаны рассмотренные альтернативы и почему выбрали именно это.
+- [ ] Scope разбит на параллельные модули без жёстких зависимостей. Проверка: если выпадает любой один человек, проект всё ещё доезжает до защиты в урезанном виде.
+- [ ] Договорённость про code review: что обсуждается (логика, тесты, читаемость, имена), что не обсуждается (форматирование — в линтер). Записана в CONTRIBUTING.md.
+
+---
+
+## Чеклист каждой недели
+
+Раз в неделю на созвоне:
+
+- [ ] Все участники написали хотя бы по одной записи в дневник? Если кто-то нет — обсудить с ним напрямую, не публично.
+- [ ] Распределение задач на ближайшую неделю проговорено и зафиксировано в issue/board.
+- [ ] `README.md` всё ещё актуален? Если за неделю поменялся стек, состав команды, способ запуска или ссылки — обновить сразу, не «потом».
+- [ ] Решения этой недели записаны в `DECISIONS.md`? Любое решение, на которое команда потратила больше получаса спора, должно остаться зафиксированным.
+- [ ] PR не висят в open больше 3 дней без ревью? Если висят — назначить ответственного.
+- [ ] Никаких заброшенных веток старше 2 недель в репозитории.
+- [ ] Деплой работает? Когда последний раз проверяли вживую?
+- [ ] Кто отстаёт? Кто опережает? Нужно ли перераспределить нагрузку?
+
+Раз в две недели или после каждой защиты:
+
+- [ ] Что мы изменим в работе после этой защиты? Один конкретный пункт, не «всё улучшим».
+
+---
+
+## Анти-паттерны (что выглядит нормально, но ведёт в стену)
+
+| Антипаттерн | Почему опасен | Чем заменить |
+|---|---|---|
+| «Давайте все равны, лидер не нужен» | Никто не двигает встречи, решения зависают, команда теряет неделю на каждом выборе | Назначить тимлида явно, можно ротировать каждые 2 недели |
+| «Сначала закодим, потом разберёмся» | К W3 разные участники работают по разным правилам, ревью превращается в холивар | Минимальный baseline в W1: ветки, PR, линтер |
+| «Решим архитектуру голосованием на созвоне» | Тот, кто проиграл голосование, потом работает через силу или саботирует | Один человек с мандатом и сроком приносит готовый прототип, команда принимает |
+| «Лекция от тимлида: я разобрался — расскажу» | Полу-знание плохо передаётся, аудитория стесняется переспрашивать | Парная работа по проблеме, когда она возникла |
+| «Закрытый репозиторий, пока не доделаем» | Ментор, координатор и Tandi не видят, что вы живы; первая обратная связь — на защите | Публично с первого дня, неидеальный README лучше пустого |
+| «Команда из 6 — мы быстрее справимся» | Координация растёт квадратично; больше времени уходит на синки, чем на код | Scope под 3 человека, остальные расширяют |
+| «У нас нет дизайнера, разберёмся по ходу» | Гигантизм макета и переделка вёрстки на W4 | Дизайн-передача в реальном времени, или явный owner UI с правом решать |
+| «Дневники — это бюрократия» | Молчун в команде не виден до защиты, выгорание не ловится | Дневник = сценарий вашей собственной защиты |
+
+---
+
+## Протоколы повторяющихся ситуаций
+
+### «Один из нас не выходит на связь»
+
+1. Тимлид пишет ему в личку: «Привет, ты как? Чем могу помочь?» Не публично — публичность работает как обвинение.
+2. Если не отвечает 48 часов — пишет в общем чате @упомянув: «{имя}, дай знать, что происходит, мы за тебя волнуемся».
+3. Если не отвечает 4 дня — тимлид пишет координатору курса. До этого момента команда не пытается «решить сама».
+4. Параллельно команда перераспределяет его задачи как если бы его не было. Возвращающийся участник получает короткий weekly digest решений и догоняет.
+
+### «У нас архитектурный спор в PR на 15 комментариев»
+
+1. Останавливаем тред в PR. Кто-то из участников пишет: «Выносим в созвон / ADR».
+2. Назначается один человек, который принимает решение по этому вопросу. У него есть 2–3 дня и право показать готовый прототип.
+3. Решение фиксируется записью в `DECISIONS.md`: дата, тема, что выбрали, почему, какие альтернативы рассмотрели, кто решал.
+4. Закрываем PR с этим решением, остальные комментарии откладываем в issue.
+
+### «Мы не успеваем — что резать»
+
+1. Список фич делится на три уровня: must (без этого защищаться нельзя), should (без этого защита будет бледной), nice (если останется время).
+2. Если в W6 кажется, что не успеваете must — режется should, и команда возвращается к защите must.
+3. Если режется must — это сигнал координатору и ментору сразу, не за два дня до защиты.
+4. Не бывает «успеем в последнюю неделю». Все, кто верили, что успеют в последнюю неделю, не успевали.
+
+### «Тиммейт вышел из команды»
+
+1. Команда фиксирует это явно (в чате, в README): кто вышел, когда, что из его задач остаётся.
+2. Тимлид перераспределяет его задачи. Если оставшиеся не справляются по объёму — пишет координатору с просьбой урезать scope.
+3. Не «мы за него тянем» молча. Вытягивание молча = выгорание через две недели.
+
+### «У нас конфликт между двумя участниками»
+
+1. Не на code review. PR — не место для разбора отношений.
+2. Тимлид (или ментор, если тимлид — одна из сторон) садится с обоими отдельно и слушает. Не пытается «помирить за один созвон».
+3. Если конфликт про код — выносим в `DECISIONS.md` с чётким owner-решением. Если про роли — переговариваем распределение задач.
+4. Если конфликт про человеческое — пишем координатору. Это не «мы должны справиться сами».
+
+### «Мы не понимаем, что мы делаем»
+
+Это нормальное состояние W3–W4. Самая частая фраза в дневниках Tandem: «не понимаю, что мы делаем». Если так чувствует один — это нормально, дневник как раз для этого. Если так чувствуют все — это сигнал созвониться с ментором и пересобрать scope.
+
+---
+
+## Минимальный набор артефактов команды
+
+К концу проекта в репозитории должны быть:
+
+- `README.md` — живой документ: описание проекта, состав команды с github-логинами, стек, как запустить локально, ссылки на деплой и дашборд. Обновляется по ходу проекта, а не за два дня до защиты.
+- `DECISIONS.md` — журнал командных решений, который вы вели всю дорогу: стек, архитектурные развилки, изменения scope, договорённости. Это и есть ваша история проекта; на защите по нему легко рассказывать.
+- `CONTRIBUTING.md` — конвенции веток, PR, ревью, тестов.
+- `AGENTS.md` или `CLAUDE.md` — конвенции для кодинг-агента (если используете).
+- `.github/PULL_REQUEST_TEMPLATE.md` — шаблон PR.
+- Дневники каждого участника — там, где договорились их вести.
+- Деплой, который работает.
+
+Это не «положено» — это то, что делает команду читаемой для ментора, координатора, агента и нового члена команды, который вернулся после болезни.