team-onboardlisted

# Ввод в проект Задача, которой нет у разработчика-одиночки: передать контекст, накопленный командой. Устная передача теряет ровно то, что дороже всего, — причины решений. Цель — не пересказать структуру каталогов (её видно), а извлечь то, что в коде не написано: почему сделано так, где нельзя трогать и что уже пробовали. ## 1. Собери карту по фактам Прочитай `CLAUDE.md`, `README`, манифесты зависимостей, конфигурацию CI. Выясни и покажи одним экраном: - стек и версии; - команды: тесты, линтеры, сборка, запуск локально; - слои и направление зависимостей; - где точки входа: HTTP, консольные команды, обработчики очередей, планировщик. Не переписывай сюда структуру папок. Человек её увидит. ## 2. Найди договорённости, которых нет в документации Это главная часть, и её источник — история, а не файлы: - **Часто правящиеся файлы.** `git log --format= --name-only | sort | uniq -c | sort -rn | head -20` — верх списка показывает, где сосредоточена сложность и куда придётся вернуться. - **Файлы, которые не трогают годами.** Обратный конец того же списка: либо стабильное ядро, либо зона, куда боятся заходить. Различить помогает покрытие тестами. - **Массовые правки одним коммитом** — следы миграций и соглашений, принятых разом. Сообщение такого коммита обычно объясняет правило, которого нет в документации. - **Откаты и повторные попытки** (`git log --grep='revert\|откат'`) — самое ценное: тут написано, что уже пробовали и почему не сработало. ## 3. Определи вла