ИИ для практиков ускоряем работу, монетизируем нав

 «ИИ для практиков: ускоряем работу, монетизируем навыки!» -
пособие: от «валенка» до «профи».


Глава 1. Основы цифровой компетентности и тестирование ПО

Уровень БАЗОВЫЙ
Тема 1.1. Организация данных: структура папок (raw/processed/reports/scripts) и .gitignore
Цель: организовать поток данных так, чтобы они не терялись, не путались и не «ломались» при переносе между устройствами.

Ключевые понятия (коротко):
Файловая система и пути. Структура папок важнее названий файлов. Если скрипт каждый раз ищет файл вручную — это не автоматизация.
Сети и протоколы. Важно понимать, как данные уходят в облако и где может теряться точность (например, при конвертации координат).
Версии и бэкапы. Git — не только для программистов: это способ зафиксировать «вчера считал так, сегодня иначе, а где ошибка?».
Схема (единая для всех):
В каждой задаче — универсальная схема и 3–4 разнопрофильных варианта. Смысл разный, шаги — одинаковые. Это и даёт уверенность: видим, что метод работает в любой нише, но можем спокойно пропустить то, что уже знаем.
Задача 1.1.1.: создать типовую структуру проекта и файл .gitignore под свою сферу
Что делать (по шагам):
1. Создать на рабочем столе корневую папку проекта: Project_1.
2. Внутри Project_1:
o создать текстовый файл .gitignore.txt (точка в начале обязательна);
o создать 4 папки: raw, processed, reports, scripts.
3. В .gitignore прописать ровно эти строки:
text
.tmp
Thumbs.db
__pycache__/
*.log
4. В каждую из 4 папок положить по одному файлу (любой формат: картинка, txt, pdf..).

Примеры под разные профили (механика одна, смысл разный)
Профиль raw processed reports scripts
Ремесленник фото заготовок, сканы эскизов, заметки от руки обработанные фото для каталога, макеты принтов карточки заказов, статусы, фото готовых изделий Excel калькулятор
Автор голосовые заметки, черновики, референсы отредактированные главы письма редактора, версии текстов, отзывы скрипт подсчёта слов
Строитель Замеры и фото дефектов, сметы от подрядчиков схемы, планы, пересчитанные объёмы акты, фото, письма заказчику, отчёты калькулятор плитки
Маркетолог сырые выгрузки CSV/Excel, логи очищенные таблицы, сводные, графики презентации, выводы, дашборды скрипт расчёта CTR

Что необходимо увидеть (критерий успеха): структура понятна любому человеку, открывшему папку; Git не индексирует мусор.
• В папке проекта: ровно 4 папки и файл .gitignore.
• В каждой папке — по 1 файлу.
• Git игнорирует временные файлы как «новые».

Тема 1.2. Кибербезопасность для пользователя: 2FA, шифрование архивов, список чувствительных данных.

!!! ВАЖНО: Никогда не храните пароли и ключи в Git. Даже в .gitignore. Для этого используйте переменные окружения или менеджеры секретов.

ЦЕЛЬ: защитить данные и не потерять результаты расчётов из;за случайного удаления или «чужого» скрипта.
Ключевые правила:
Не хранить чувствительные данные в открытом виде. Файлы — в зашифрованных архивах или в защищённых папках.
Включить двухфакторную аутентификацию (2FA) на облачных хранилищах и GitHub. Это стандарт, а не «сложно».
Проверять зависимости скриптов. Если ставишь библиотеку, смотри, что она делает, и фиксируй версии в requirements.txt.

Привязка к задачам:
При загрузке данных в облачные ИИ;сервисы важно понимать, куда и зачем они уходят.
Все материалы, расчёты и отчёты должны лежать в чёткой структуре, чтобы через месяц не гадать, какой файл правильный.

Задача 1.2.1: защитить чувствительные данные и зафиксировать правила доступа

!!! ВАЖНО: Никогда не храните пароли и ключи в Git. Даже в .gitignore. Для этого используйте переменные окружения или менеджеры секретов.

Что выполнить:
1. На отдельном листе или в заметке выписать 5–7 пунктов «чувствительных данных»: пароли, контакты, финансовые данные, реквизиты, доступы, прайсы.
2. Выбрать 1 способ защиты:
o 2FA на почте/облаке, и(ли)
o шифрование архива (7 Zip с AES 256).
3. Если шифруете:
o создать архив с тестовым файлом и поставить пароль;
o проверить, что без пароля файл не открывается.
4. Написать 3 правила: где хранятся чувствительные данные, кто имеет доступ, как их передавать.
5. Протестировать: попробовать «потерять» тестовый файл и убедиться, что он защищён.
Примеры по профилям
Профиль Чувствительные данные Защита Правило
Ремесленник контакты клиентов, прайсы 2FA + прайс в зашифрованном архиве «не кидаю прайсы в общий чат»
Автор черновики, договора шифрование папки с черновиками «черновики — только в облаке с 2FA»
Строитель сметы, реквизиты, акты отдельные папки с шифрованием «сметы — только по ссылке с паролем»
Маркетолог базы контактов, отчёты по конкурентам 2FA + архивация с паролем «никаких публичных ссылок на базы»

Что необходимо увидеть (критерий успеха): теперь знаем, какие данные нельзя выкладывать в открытый доступ, и какой базовый механизм защиты.
• Список из 5–7 чувствительных пунктов.
• Рабочий способ защиты (галочка «2FA включена» или рабочий зашифрованный архив).
• 3 коротких правила, которые реально сможете соблюдать.

!!! ВАЖНО: Никогда не храните пароли и ключи в Git. Даже в .gitignore. Для этого используйте переменные окружения или менеджеры секретов.


Тема 1.3. ОС и CLI: базовые команды, виртуальные окружения(venv), активация.
Цель: автоматизировать рутину (копирование, конвертация, запуск скриптов) и не зависеть от «кнопочного» интерфейса.

Что реально пригодится:
Командная строка (CLI): копировать файлы, запускать скрипты, проверять версии программ.
Виртуальные окружения (venv): чтобы разные проекты не конфликтовали по версиям библиотек.
WSL (Windows Subsystem for Linux): если пользуетесь Windows, это даёт доступ к удобным CLI;инструментам без перехода на Linux.
Привязка к задачам:
Скрипт должен работать стабильно и на ноутбуке, и на сервере. Виртуальные окружения решают эту проблему.
CLI позволяет запускать пересчёт по расписанию или при появлении новых замеров.

Задача 1.3.1: подготовить изолированную среду для скриптов
Что выполнить:
1. Установить Python 3.10–3.12 с python.org. . Создать venv: python -m venv Project_Env. Открыть терминал (cmd/PowerShell/Terminal)
2. В папке Project_1 выполнить:
bash
python -m venv Project_Env

В продвинутом уровне создать requirements.txt и записать туда зависимости (CI/Docker).
3. Активировать окружение:
o Windows:
bash
Project_Env\Scripts\activate
o Linux/macOS:
bash
source Project_Env/bin/activate
4. Проверить версию:
bash
python --version
(должна быть 3.10+).
5. В папке scripts создать файл hello.py и вставить:
python
print("OK")
6. Запустить:
bash
python scripts/hello.py


Примеры функций под профили (механика одинаковая)
Профиль Функция
Ремесленник умножает цену на количество, выводит итог - скрипт считает стоимость материалов по списку (цена ; количество)..
Автор считает длину текста, выводит «слов: N» скрипт проверяет длину текста и количество слов (для контроля объёма глав).
Строитель конвертирует м; ; шт. плитки при заданной площади одной плитки- скрипт конвертирует единицы (м; ; шт. плитки при заданной площади одной плитки)..
Маркетолог делит клики на показы, выводит процент (CTR) - скрипт считает CTR (клики / показы ; 100) по двум числам..

Критерий успеха: команда python --version показывает корректную версию, окружение активировано.
• Слева в терминале (Project_Env) — среда активна.
• python --version показывает 3.10+.
• При запуске скрипта выводится OK.


Тема 1.4. Облачные инструменты: синхронизация папки проекта и Git (init/add/commit).
Зачем: синхронизация данных между устройствами (ноутбук, смартфон, планшет) и воспроизводимость расчётов.

Что использовать:
Облачное хранилище (Google Drive, OneDrive, Nextcloud, Yandex.Cloud) — синхронизация папки проекта.
Git/GitHub — контроль версий скриптов и отчётов.
Docker (перспективно) — чтобы «на моём ноутбуке работает» превращалось в «работает везде одинаково».

Задача 1.4.1.: синхронизировать проект и зафиксировать первый коммит.

Что выполнить:
1. В облаке (Google Drive, OneDrive, Nextcloud, Yandex.Cloud) создать папку Project_1 и включить синхронизацию на компьютере.
2. Переместить локальную папку Project_1 в папку облака или убедиться, что локальная папка Project_1 синхронизируется (в терминале, находясь в папке Project_1, выполните: Включить автосинхронизацию папки проекта в облаке).
3. В корне проекта выполнить команды:
bash
git init
git add .
git commit -m "Initial project structure"
4. Проверить статус:
bash
git status
Должно быть: nothing to commit, working tree clean.
Примеры (разные типы проектов, одна механика):

Ремесленник: папка с фото изделий, прайсом, шаблоном заказа.
Автор: папка с главами, синопсисом, заметками.
Строитель: папка с замерами, сметами, фотоотчётами.
Маркетолог: папка с таблицами, графиками, выводами.

Что необходимо увидеть (критерий успеха): есть короткий чек;лист и пример баг;репорта; мы понимаем, как описывать ошибки.
• Папка Project_1 отображается в облаке и синхронизируется (значки облака рядом с файлами).
• Есть первый коммит.
• git status показывает «nothing to commit».
Примпечание: Сейчас — это «git init, git add, git commit», а в 1.7 — уже ветки, PR, CI, Docker.

Тема 1.5. Тестирование как инженерная практика: юнит;тесты, граничные случаи.
Зачем: проверять расчёты: по допускам, по граничным случаям, по воспроизводимости.

Базовые практики:

Юнит;тесты: проверять отдельные функции (например, расчёт уклона).
Граничные случаи: что происходит при уклоне 0%, при глубине 0 м, при отрицательных отметках.
Регрессионные тесты: убедиться, что после правки старые расчёты не ломаются.

Задача 1.5.1.: написать функцию и тест, который ловит ошибку на граничных случаях.

Что выполнить:
В папке scripts создать файл test_ratio.py и вставить код:
python

def percent_ratio(a, b):
    if b == 0:
        return 0
    return (a / b) * 100

assert percent_ratio(10, 20) == 50.0
assert percent_ratio(0, 10) == 0.0
assert percent_ratio(5, 0) == 0.0
Запустить:
bash

python scripts/test_ratio.py

Если ошибок нет — всё ок.
Если есть ошибка — посмотрите, какая строка подсвечивается, и проверьте, нет ли опечатки: assert проверяет условие, если оно ложно — программа падает с ошибкой. Это и есть тест.

Примеры (смысл разный под нишу, код одинаковый):

Ремесленник: percent_ratio — процент брака в партии изделий.
Автор: процент готовности главы (написано / план).
Строитель: процент выполнения этапа (факт / план по площади).
Маркетолог: процент конверсии (заказы / клики).
Что необходимо увидеть (критерий успеха): тесты проходят, деление на ноль обрабатывается, мы понимаем, как проверять граничные случаи.
• Терминал ничего не пишет (все assert прошли).
Либо выводится сообщение об ошибке с указанием строки (тогда исправляем опечатку).


Тема 1.6. Документация ошибок и чек листы: баг;репорт по шаблону, чек;лист проверок.
Зачем: быстро находить и исправлять ошибки, а также показывать результаты заказчику или себе через месяц.

Что делать:
Чек;лист проверок: короткий список, что обязательно проверить (система координат, единицы измерения, учёт откосов).
Баг;репорт - коротко и по делу: ввод, ожидаемый результат, фактический, причина, статус.
Отчёт о тестировании: таблица: тест, ожидаемый, фактический, статус, комментарий.

Привязка к типовым задачам:

Когда считаем, можем сразу заложить «чек;лист» проверок, чтобы не забыть необходимые условия.
Если скрипт выдал неожиданный результат, баг;репорт помогает быстро понять, в чём проблема.

Задача 1.6.1: зафиксировать ошибку и подготовить чек лист для запуска скрипта
Что выполнить:

Баг репорт (универсальный шаблон)
Поле Значение
Ввод a=10, b=0, вызов percent_ratio
Ожидаемый 0 (защита от деления на ноль)
Фактический Ошибка division by zero
Причина Не обработан случай b=0
Статус Исправлено

Примеры описания ошибки под профили:

Ремесленник: ошибка расчёта стоимости при нулевом количестве.
Автор: ошибка подсчёта слов при пустом файле.
Строитель: ошибка конвертации при отрицательном значении площади.
Маркетолог: ошибка расчёта CTR при нулевом числе показов.

Чек лист из 4 пунктов для запуска любого скрипта
1. Есть ли входные данные?
2. В правильном ли формате?
3. Активировано ли виртуальное окружение?
4. Зафиксированы ли версии библиотек?
Что необходимо увидеть (критерий успеха): есть короткий чек;лист и пример баг;репорта; мы понимаем, как описывать ошибки.

Заполненный баг;репорт (хотя бы один пример).
Чек;лист из 4 пунктов, который вы реально можете использовать.


Уровень ПРОДВИНУТЫЙ
Тема 1.7. Контроль версий (ветки, pull request), CI/CD, Docker для воспроизводимости окружения
   В теме 1.4 вы научились фиксировать изменения в проекте с помощью git init, add и commit — это база для сохранности работы. Теперь переходим к следующему уровню надёжности: как не потерять изменения при откате, не сломать проект правками и гарантировать, что у другого пользователя (или в CI) всё запустится точно так же, как у вас. Для этого используем ветки, pull request, CI/CD и Docker.

ПРИМЕЧАНИЕ:   Git: ветки и PR для одиночки. Для одиночного автора (особенно ремесленника или строителя) ветка feature/* и PR могут оказаться избыточными. Если работаете в одиночку — можно без PR, но обязательно делайте отдельные ветки. Если планируете передать проект или показать заказчику — делайте PR».
Когда CI можно пропустить, а когда — нельзя:
Личный проект, только для себя: достаточно локальных тестов и понятных коммитов. CI не обязателен.
Работа в команде или с ассистентом; проект для передачи другому человеку, показа заказчику, публикации: CI обязателен— это единственный способ быстро увидеть ошибки до того, как они попадут в основную версию.. Он автоматически проверяет, что новый код не сломал старый, и показывает статус (зелёный/красный) прямо в интерфейсе PR.
ВЫВОД: Для личного проекта: достаточно тестов и понятных коммитов. Для передачи проекта/показа заказчику и работы в команде: CI обязателен, чтобы видеть ошибки до мерджа.

Задача 1.7.1: сделать так, чтобы изменения не терялись, проект не ломался, а у другого пользователя всё запускалось «как у тебя» (три гарантии): Git (контроль версий), CI/CD (автопроверка) и Docker (одинаковое окружение).
Суть:  не правим всё подряд в главной ветке — создаём отдельную ветку под задачу, делаем в ней изменения, а потом просим «принять» их через pull request. При каждом pull request автоматически запускается проверка (тесты, линтер, сборка). Если проверка падает — видим это до мерджа (Merge).

Контроль версий: ветки и pull request (минимальный сценарий) — не теряем работу и не ломаем проект откатом.
CI/CD — изменения автоматически проверяются и мы видим ошибку до того, как она попадёт в основную версию.
Docker — проект запускается одинаково у вас, у заказчика и в CI.

Минимальный рабочий сценарий (Python стек, GitHub/GitLab)
1. Убедиться, что ветка актуальна:
bash
git pull origin main
2. Создать ветку под задачу:
bash
git checkout -b feature/task-1
3. Сделать изменения, протестировать локально.
4. Закоммитить:
bash
git add .
git commit -m "описание изменений: добавляем Dockerfile и тесты"
5. Отправить ветку:
bash
git push origin feature/task-1
6. На сайте репозитория создать pull request из feature/task-1 в main.
7. Проверить diff, оставить комментарии, при необходимости доработать и запушить снова.
8. После проверки — кнопка Merge.
Важные проверки (чтобы не было боли)
• Ветка создана от актуального main (перед этим git pull origin main).
• В коммитах нет чувствительных данных (пароли, ключи).
• Дифф в PR понятный, логическими кусками (не «всё сразу»).
Чек лист воспроизводимости (перед передачей проекта). Перед тем как передать проект, проверьте:
1. Есть requirements.txt.
2. Есть Dockerfile.
3. Есть README с инструкцией «как запустить».
Это закроет классическую проблему «у меня работает, а у других нет».

Примеры для четырёх групп пользователей и минимальный рабочий набор:

Ремесленник (например: производство, шаблоны изделий)
   Что хранить в Git: файлы шаблонов, инструкции, версии чертежей, changelog изменений.
   Зачем ветки: отдельная ветка под новую форму/размер, чтобы не ломать текущие шаблоны.
   Pull request: мастер или технолог проверяет изменения перед тем, как пустить в производство.
Практический смысл: если новая форма не пошла — откатываемся к стабильной ветке без потери всей базы.

Автор (литература, жанр, контент)
   Что хранить в Git: тексты глав, синопсисы, варианты редакций, метаданные.
   Зачем ветки: ветка «редакция для издательства», ветка «альтернативный финал», ветка «адаптация под аудио».
   Pull request: редактор подтверждает версию перед публикацией.
Практический смысл: всегда есть «чистая» версия, можно показать историю правок, легко собрать сборник из разных веток.

Строитель (участок, уклоны, дорожки, пруд)
   Что хранить в Git: планы участка, отметки высот, спецификации материалов, журнал работ, фотофиксацию по версиям: каждая ветка — это этап стройки, PR — согласование с подрядчиком..
   Зачем ветки: ветка «план пруда», ветка «план дорожек», ветка «изменения по насыпи».
   Pull request: согласование с подрядчиком или проектировщиком.
Практический смысл: не перепутать версии плана, зафиксировать, кто и когда вносил правки, иметь «архивную» версию для споров или гарантий.
Маркетолог (лендинги, креативы, кампании)
   Что хранить в Git: макеты, тексты объявлений, скрипты, A/B-варианты, UTM-метки.
   Зачем ветки: ветка «A/B тест объявления», ветка «новая посадочная», ветка «сезонная кампания».
   Pull request: арт-директор или клиент подтверждает вариант.
Практический смысл: быстрый откат, прозрачность изменений, возможность собрать «историю кампании» для отчёта.

CI/CD: минимальный пайплайн (GitHub Actions)
(CI не обязателен для личного проекта, но обязателен для продвинутого уровня)

Суть: при каждом pull request автоматически запускаются проверки (тесты, линтер, сборка). Цель не в том, чтобы сделать “идеальный пайплайн”, а в том, чтобы видеть ошибку до того, как она попадёт в основную версию.

Пример «было/стало» для CI

Было: вы вручную запускали тесты после каждой правки, забывали про новые файлы, иногда случайно ломали старые функции и замечали это только через несколько дней.
Стало: при каждом pull request тесты запускаются автоматически. Статус (зелёный чек или красный крест) виден прямо в интерфейсе GitHub/GitLab. Ошибка ловится сразу, до попадания в основную ветку.

Минимальный пример на GitHub Actions для Python (файл .github/workflows/ci.yml):
Файл: .github/workflows/ci.yml
yaml

name: CI
on: [push, pull_request]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Set up Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - run: pip install -r requirements.txt
      - run: pytest

Что это даёт:
Тесты запускаются автоматически при PR.
Видим статус (зелёный/красный) прямо в интерфейсе PR.
Меньше риска, что «у меня работает, а у других нет».
Примеры применения по группам:

Ремесленник: CI проверяет, что все файлы шаблонов открываются, а скрипты генерации не падают.
Автор: CI проверяет орфографию/стилистику, валидацию метаданных, сборку PDF-сборника.
Строитель: CI проверяет целостность файлов чертежей, соответствие спецификаций, валидацию координат/отметок.
Маркетолог: CI проверяет ссылки, валидацию HTML/CSS, отсутствие битых изображений, корректность UTM-меток.

На что обратить внимание:

Не нужно сразу строить сложную пайплайн-машину. Начинаем с одного джоба: «запустить тесты». Если проект простой — можно даже без CI, но для «продвинутого» уровня это обязательный минимум.


Docker для воспроизводимости окружения: упаковывает всё нужное (ОС-уровень, зависимости, переменные, порты) в образ, чтобы проект запускался одинаково везде.

Зачем: без «у меня работает, а у других нет».

Docker: минимальный Dockerfile
Файл: Dockerfile в корне проекта
dockerfile

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
CMD ["python", "scripts/hello.py"]
Файл: .dockerignore
Не копируйте в Docker;образ всё подряд — это раздувает размер и замедляет сборку. Создайте файл .dockerignore в корне проекта, исключите pycache, .git, логи:
text

.git
__pycache__
*.log
.env
.DS_Store
Это сразу снизит количество ошибок «не собирается» и ускорит сборку.

docker-compose.yml (если нужны база/сервисы):
yaml
version: "3.8" services: app: build: . ports: - "8000:8000" environment: - ENV=production
Команды:
bash

docker build -t my-app .
docker run -p 8000:8000 my-app
# или
docker compose up –build

Примеры по группам:

Ремесленник: Docker с инструментами генерации шаблонов и конвертации форматов — любой помощник запускает и получает одинаковые файлы.
Git: хранить версии шаблонов, техкарт, чертежей, changelog изменений.
Ветки: отдельная ветка на каждую новую форму/размер, чтобы не ломать текущий выпуск.
CI: проверка, что скрипты генерации шаблонов запускаются и выдают файлы без ошибок.
Docker: контейнер с генератором шаблонов — любой помощник запускает и получает одинаковые файлы без установки зависимостей.
Автор: Docker со сборщиком книг/PDF — стабильная сборка без зависимости от ОС и установленных программ.
Git: тексты глав, синопсисы, варианты редакций, метаданные, changelog правок.
Ветки: ветка «редакция для издательства», ветка «альтернативный финал» (— это не только про код, но и про творческий эксперимент), ветка «адаптация под аудио».
CI: автоматическая проверка орфографии/стилистики, валидация метаданных, сборка PDF-сборника.
Docker: контейнер со сборщиком книг/PDF — стабильная сборка без зависимости от ОС и установленных программ.
Строитель: Docker с библиотеками для работы с координатами/отметками, конвертацией DXF/DWG — воспроизводимость расчётов и чертежей.
Git: планы участка, отметки высот, спецификации материалов, журнал работ, фотофиксация по версиям. Каждая ветка — это этап стройки, PR — согласование с подрядчиком..
Ветки: ветка «план пруда», ветка «план дорожек», ветка «изменения по насыпи» — чтобы не смешивать правки.
CI: валидация координат/отметок, проверка целостности файлов чертежей, соответствие спецификаций.
Docker: контейнер с библиотеками для работы с координатами, конвертацией DXF/DWG — воспроизводимость расчётов и чертежей.
Маркетолог: Docker с набором скриптов для валидации лендингов, проверки ссылок, генерации отчётов — быстрый запуск на любом компьютере.
Git: макеты, тексты объявлений, скрипты, A/B-варианты, UTM-метки, changelog кампаний.
Ветки: ветка «A/B тест объявления», ветка «новая посадочная», ветка «сезонная кампания».
CI: проверка ссылок, валидация HTML/CSS, отсутствие битых изображений, корректность UTM-меток.
Docker: контейнер с набором скриптов для валидации лендингов, проверки ссылок, генерации отчётов — быстрый запуск на любом компьютере.


Практические задания (по группам)

Общее: создать репозиторий, сделать ветку, внести 2–3 изменения, оформить PR, затем Merge.

Ремесленник: положить в репозиторий шаблоны, добавить CI-проверку, что файлы открываются.
Автор: положить тексты, добавить CI для проверки орфографии и сборки PDF.
Строитель: положить план участка и отметки, добавить CI для валидации координат.
Маркетолог: положить макеты и тексты, добавить CI для проверки ссылок и валидации HTML.

Для всех: упаковать инструменты/скрипты в Docker и запустить локально; убедиться, что без Docker проект тоже собирается.

«Контроль версий фиксирует изменения и защищает от потерь. CI/CD даёт автоматическую проверку, чтобы ошибки не попадали в основную версию. Docker делает окружение одинаковым везде. Вместе это минимальный «продвинутый» набор, который превращает разовую работу в воспроизводимый, проверяемый и понятный процесс — и одинаково полезен и ремесленнику, и автору, и строителю, и маркетологу.»

Что необходимо увидеть (критерий успеха):

Частая ошибка новичков. НЕОБХОДИМО  —  НЕ забыть убедиться, что в истории коммитов нет паролей, ключей, токенов и других чувствительных данных. Проверить командой: git log -p — не должно быть строк вида API_KEY=..., PASSWORD=.... Если такие есть — их нужно срочно убрать из истории.
Репозиторий с ветками: есть ветка feature/*, есть main, есть хотя бы один закрытый pull request с понятным diff и комментарием.
Зелёный статус CI: в интерфейсе GitHub/GitLab у последнего коммита — зелёный чек (не красный крест), тесты проходят.
Рабочий Docker-образ: docker build завершается без ошибок, docker run запускает приложение/скрипт, результат совпадает с локальной версией.
Воспроизводимость: на «чистой» машине (или в CI) проект собирается и работает так же, как у автора — без ручных доустановок и «у меня работает».


Практический артефакт по своей группе:

Ремесленник: шаблон/чертёж, сгенерированный в контейнере и проверенный CI.
Автор: PDF-сборник или отчёт о валидации текстов.
Строитель: валидированный план/журнал с отметками высот и координатами.
Маркетолог: отчёт о проверке ссылок/HTML и валидных UTM-метках.