resume/AI_GUIDELINES.md

# Критерии и ограничения для ИИ

Этот файл — компас для любой доработки репозитория. Перед тем как добавлять/менять кейсы, вопросы или легенду, свериться с этим документом.

## Цель репозитория

Подготовка к собеседованиям на позиции **«Инженер сопровождения»** и **«DevOps-инженер»** (уровень middle). Кандидат: [RESUME.md](RESUME.md) — Картман Эрик, 4 года 5 месяцев опыта, основной стек — мониторинг (Grafana/Prometheus/Mimir), Ansible, Docker, Nginx, ELK, Linux/Bash, CI/CD, немного тестирования (Selenium) и вспомогательные языки (Python, SQL, C/C++). Дополнительно — самостоятельная pet-практика (Kubernetes, PostgreSQL, сети, Kafka, Vault), см. раздел ниже.

Подготовка опирается не только на резюме, но и на разбор реальных прошедших собеседований — [interview/real-interviews.md](interview/real-interviews.md) и сырые заметки в [interview/](interview/). Оценочные суждения из чужих заметок о конкретных людях/компаниях (личные впечатления автора заметок) не переносятся в кейсы или ответы — используется только фактическое содержание вопросов.

## Ключевая рамка: кейсы должны быть реальными, а не выдуманными

Это центральное ограничение всего репозитория.

- **Знания по многим технологиям из резюме в основном теоретические.** Задача не в том, чтобы написать красивую историю, а в том, чтобы кандидат реально выполнил мини-лабу (домашний стенд, чаще всего на Docker/Docker Compose), получил настоящий опыт — и уже про этот опыт мог уверенно рассказывать и отвечать на уточняющие вопросы.
- Каждый `CASE.md` в `stack/*/` должен содержать **воспроизводимую инструкцию**: команды, конфиги, docker-compose, ожидаемый результат. Не абстрактное описание «как обычно это делается», а то, что можно взять и повторить на своей машине.
- **Не сочинять конкретные вымышленные факты** о работе в АО ТНИИС или ОКБ СУХОЙ (несуществующие цифры, инциденты, имена коллег, названия внутренних систем и т.п.). Разрешено обобщённо описывать типовые задачи роли («инженер сопровождения занимается тем-то») — это соответствует духу резюме, но детали должны опираться на то, что кандидат реально проделал в кейсе.
- Технологии, отсутствующие в опыте работы, но указанные в навыках резюме (Python, SQL, C/C++), — вписываются в легенду как вспомогательные инструменты внутри реальных задач (скрипты автоматизации, запросы к БД мониторинга и т.п.), тоже подкреплённые кейсом.
- **Технологии, которых нет вообще ни в одном рабочем месте (Kubernetes, PostgreSQL как СУБД, сетевая база, Kafka, Vault)** — согласованное расширение легенды по итогам разбора реальных собеседований ([interview/real-interviews.md](interview/real-interviews.md)). Вписываются **только** как честный pet-проект/домашняя лаборатория (раздел «Домашняя лаборатория / pet-проект» в [legend/LEGEND.md](legend/LEGEND.md)) — никогда не приписываются к опыту в АО ТНИИС или ОКБ СУХОЙ. На собеседовании позиционируются прямо: «в рабочем стеке этого не было, поднимал себе дома, чтобы разобраться».

## Политика цифр нагрузки

Вопросы вида «с каким трафиком сталкивался» / «как справишься с масштабом X» закрываются через [legend/CAPACITY.md](legend/CAPACITY.md) и три чётко разделённых источника цифр, которые нельзя смешивать:

1. Публичные документированные пределы технологий (со ссылкой на характер источника).
2. Реальные замеры, полученные прогоном инструментов на собственных CASE.md-стендах.
3. Факты о реальном масштабе, заполняемые только пользователем лично.

**Не сочинять «продовые» или «типичные для компании такого профиля» цифры нагрузки** — ни как метрики с работы, ни как параметры pet-лабы, выдаваемые за нечто большее, чем они есть.

## Согласованность

Все документы должны быть непротиворечивы друг другу:

- Даты, названия компаний, стек — как в [RESUME.md](RESUME.md).
- Легенда ([legend/LEGEND.md](legend/LEGEND.md)) — единый источник истины про то, «где и зачем» применялась технология. Кейсы и ответы на вопросы ссылаются на неё, а не противоречат.
- Если кейс меняет понимание того, как технология использовалась — обновить LEGEND.md в этом же заходе.

## Стиль

- Все документы — на русском, в markdown.
- Ответы на вопросы в `QUESTIONS.md` — от первого лица, разговорным языком, как кандидат реально бы ответил, с опорой на кейс. Не копировать формулировки из документации слово в слово.
- Без канцелярита и не заученно — если ответ звучит как выученный наизусть параграф, это плохой ответ и его надо переписать.
- Все даты в тексте записываются в формате `dd-mm-yyyy` (например, `18-07-2026`), а не `yyyy-mm-dd` или другими способами.

## Куда идти

- Порядок проработки категорий следует частотности тем в реальных собеседованиях, зафиксированной в [interview/real-interviews.md](interview/real-interviews.md) и разложенной по шагам в [interview/study-plan.md](interview/study-plan.md) — не порядку строк резюме.
- Добавлять вопросы «от простого к сложному»: сначала база (что такое, зачем нужно), потом — сравнение с альтернативами, потом — как бы решал проблему X.
- При появлении новых разборов реальных собеседований — обновлять матрицу тем в [interview/real-interviews.md](interview/real-interviews.md) и маппить новые вопросы на существующие/новые категории, а не оставлять их непокрытыми.
- Держать README.md как актуальную карту готовности (что проработано, что нет).

## Куда не идти

- Не придумывать метрики/цифры, которых нет в резюме и не проверены кейсом («настроил 200 дашбордов» и т.п.).
- Не добавлять технологии, которых нет ни в резюме, ни в согласованном расширении легенды.
- Не делать кейсы избыточно сложными для уровня middle — стенд должен быть реалистичным для домашней проработки, а не production-инсталляцией.
- Не переписывать RESUME.md без явного запроса пользователя — правки резюме пользователь вносит/подтверждает сам.
- **Не закладывать в резюме или легенду техники обмана работодателя/площадки** — например, дублирующие профили с намеренно искажёнными данными (изменённые ФИО/возраст/контакты) для обхода отказов. Это не входит в понятие «подготовка к собеседованию». См. разбор в [RESUME_RULES.md](RESUME_RULES.md) → «Осознанно не применено».

## Правила оформления резюме

Отдельный применённый чек-лист внешних best practices по резюме — в [RESUME_RULES.md](RESUME_RULES.md). Он же фиксирует, что было сознательно отброшено и почему.