А теперь по-настоящему

Между твоим Enter и появлением страницы происходит шесть вещей.

1. Браузер спрашивает адрес. Он идёт в DNS — систему, которая переводит имена в числа — и спрашивает: какой IP-адрес у этого имени? Получает что-то вроде 84.201.148.12.
2. Браузер стучится по этому адресу. Устанавливается соединение — то, что называют TCP. Считай, дозвонился.
3. Договариваются о шифровании. Это TLS-рукопожатие: сервер показывает сертификат, браузер проверяет, что он настоящий и не просрочен. Замок в адресной строке — про это и только про это.
4. Браузер отправляет HTTP-запрос. Дословно: «дай мне файл по пути /».
5. Приходит ответ. Код 200 и текст файла index.html. Или 404, если такого файла нет, или 500, если на той стороне что-то сломалось.
6. Браузер читает HTML и видит ссылки на другие файлы — стили, скрипты, картинки. И за каждым идёт отдельным запросом. Одна страница — это обычно десятки запросов, а не один.

Слово статика, которое дальше будет встречаться постоянно, означает ровно это: файлы лежат готовыми и отдаются как есть. Никто ничего не вычисляет в момент запроса.

Тут стоит остановиться и заметить неочевидное: в этой цепочке нет ничего, что выполняло бы твой код. Есть хранилище файлов и браузер. Всё. Программа, которая думает на той стороне, появляется только тогда, когда ты её специально заводишь — и это отдельная история, глава 2.

А теперь по-настоящему

Три ступени. Это осевая конструкция всего учебника — дальше почти каждая тема будет привязана к одной из них.

Термины, которые ты услышишь: бакет — та самая папка на первой ступени. Serverless — про вторую (название врёт: сервер там есть, просто он не твой и живёт секунды). VPS или дроплет — третья ступень, арендованная машина. Аптайм — доля времени, когда всё это доступно.

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

Как понять, что пора выше? Первая ступень заканчивается там, где нужно что-то запомнить между визитами пользователей. Вторая — там, где надо что-то делать без запроса: по расписанию, в фоне, самому.

А теперь по-настоящему

Объектное хранилище. Кладёшь файлы, включаешь режим раздачи сайта, привязываешь домен. Не умеет ничего, кроме отдачи файлов, — и в этом его сила: нечему падать. Дёшево до неприличия. Минус: любая динамика требует чего-то ещё.

Платформа-конструктор. Netlify, Vercel, Firebase Hosting, Cloudflare Pages. Подключаешь репозиторий — платформа сама собирает и раскладывает при каждом изменении, сама выписывает сертификат, сама раздаёт файлы через CDN (сеть серверов по миру, чтобы пользователю отвечал ближайший). Даёт превью-ссылку на каждую ветку. За пять минут и бесплатно.

Обратная сторона — вендор-лок. Их функции, их хранилище, их формат конфигурации работают только у них. Пока проект — статика, переезд занимает вечер. Как только ты начал пользоваться их функциями и хранилищем, переезд означает переписывание.

Свой сервер (VPS). Полный контроль и полная ответственность. Единственный вариант, если нужна круглосуточная работа, чужое системное ПО или что-то тяжёлое. Цена — обновления безопасности, настройка, мониторинг. Это работа, которая не кончается.

Шаред-хостинг — тот, что с панелью управления и рекламой «сайт за 99 рублей». Для наших задач мёртв: там неудобно выкладываться из репозитория, старые версии всего и никакого нормального доступа. Упоминаю, чтобы ты его узнал и прошёл мимо.

Ещё два слова из этого мира. Билд — сборка исходников в готовые файлы (у чистой статики его просто нет). Холодный старт — задержка первого запроса, пока функция просыпается.

А теперь по-настоящему

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

TTL — время жизни записи в чужих кэшах, в секундах. Поставил 3600 — значит, мир может держать старое значение ещё час после твоей правки. Это не поломка, это дизайн. Практический вывод: перед плановой сменой записей TTL снижают заранее, а не в момент правки.

Регистратор и DNS-провайдер — разные роли, и это источник половины путаницы. Регистратор — там, где домен куплен. DNS-провайдер — там, где реально живут записи. Часто это одна компания, но не обязательно: у домена есть NS-записи, которые говорят, чьи серверы за него отвечают. Если NS указывают на Cloudflare, а ты правишь записи в панели регистратора — ты правишь мёртвую копию. Ничего не применится, и ошибок тебе никто не покажет.

Откуда берётся замок. Сертификат выдаёт центр сертификации, и почти всегда автоматически по протоколу ACME. Чтобы убедиться, что домен твой, он просит завести TXT-запись с именем _acme-challenge и определённым значением. Видит её — выписывает сертификат на три месяца, потом молча продлевает. Пока запись на месте, ты об этом не думаешь. Снёс её при уборке — через несколько месяцев сайт внезапно «сломается».

Проксирование. У Cloudflare каждая запись бывает в двух режимах. DNS-only (серое облако) — просто отдаёт адрес. Проксируемая (оранжевое) — трафик идёт через Cloudflare, он кэширует, прячет настоящий адрес и подменяет сертификат своим. Второй режим полезен, но ломает сценарии, где хостинг сам выпускает сертификат и хочет видеть настоящего посетителя. Если инструкция хостинга говорит «DNS-only» — это не перестраховка.

А теперь по-настоящему

В эту тему обычно валят четыре разных вопроса и пытаются решить их одним ответом. Они решаются по отдельности, и важность у них очень разная.

1. Скорость. Расстояние даёт задержку. Звучит важно, на практике для статики это десятки миллисекунд, и человек их не замечает. А если хостинг раздаёт через CDN — файл вообще приедет с ближайшего к пользователю узла. Обычно это наименее важный из четырёх факторов, хотя обсуждают его чаще всего.
2. Доступность. Блокировки работают в обе стороны. Зарубежный хостинг может оказаться недоступен части твоих пользователей. Зарубежный сервис может не пустить тебя — по адресу, по карте, по номеру телефона при регистрации. Проверяется только опытом, обещаниям на сайте сервиса верить нельзя.
3. Оплата. Самый частый реальный блокер. Российской картой не оплатить многие зарубежные сервисы; зарубежной картой неудобно платить за российские. Бесплатный тариф однажды кончается, и вот тогда выясняется, что заплатить нечем. Проверять надо до того, как проект написан, а не после.
4. Законы о данных. Если собираешь персональные данные российских пользователей — имена, почты, телефоны, — есть требования к тому, где эти данные хранятся. Я не юрист и не буду им притворяться: важно знать, что вопрос существует, и задать его до запуска, а не после первой жалобы.

И честно: для сайта-визитки без форм и без личных данных всё это почти не имеет значения. Бери что удобнее. Значение появляется ровно в трёх случаях: у тебя есть пользователи, есть платежи или есть чужие персональные данные.

А теперь по-настоящему

Окно и оболочка — разные вещи. Окно (Терминал, PowerShell, iTerm) рисует буквы. Оболочка (shell) внутри него разбирает то, что ты написал, и запускает программы. Отсюда путаница «в одном окне работает, в другом нет» — окна разные, но ломается обычно из-за разных оболочек, у которых свои правила.

Текущая директория. Оболочка всегда «стоит» в какой-то папке, и все относительные пути считаются от неё. Половина ошибок «файл не найден» — это не отсутствие файла, а нахождение не там.

PATH — список папок, в которых оболочка ищет программы. Когда ты пишешь python, она перебирает эти папки и берёт первое совпадение. Отсюда «команда не найдена» у установленной программы: установлена, но не в том месте, где её ищут. И отсюда же «запускается не та версия»: нашлась другая раньше.

Два потока вывода. Обычный результат идёт в stdout, ошибки — в stderr. Это два разных канала, хоть и выглядят в окне одинаково. Поэтому бывает «команда ничего не вывела» — на самом деле вывела, просто в другой канал, а ты его перенаправил или не туда посмотрел.

Код возврата. После каждой команды остаётся число: 0 — успех, любое другое — нет. Это скучно и это самое важное в главе.

Почему агенту удобен терминал. Именно из-за кода возврата. У команды есть однозначный машинно-проверяемый результат: выполнил, посмотрел число, понял, получилось ли, решил, что делать дальше. Кнопку в чужом интерфейсе агент нажать не может и понять её результат тоже. Терминал — это не эстетика, это единственная поверхность, где агент может действовать и проверять себя.

И сразу снимем главный страх: Claude Code, который ты видишь в окне приложения, под капотом — тот же самый терминал. Это визуальная обёртка для тех, кому чёрный экран некомфортен. Ничего другого там не происходит.

А теперь по-настоящему

Репозиторий — папка проекта, за которой Git следит. Стал ей после команды git init. Вся история при этом лежит внутри самой папки, в скрытом каталоге .git. Стёр его — стёр всю историю, файлы останутся, прошлое исчезнет.

Коммит — сохранёнка. Снимок состояния всех файлов плюс сообщение, зачем ты его сделал. Каждый знает своего предшественника, поэтому получается цепочка — история.

Staging и зачем этот лишний шаг. Сначала git add, потом git commit. Кажется бюрократией, но смысл есть: ты правил пять файлов, а в эту сохранёнку хочешь положить только три. git add — это «вот эти беру», git commit — «запечатал». Для агентной работы это ещё и момент, когда ты смотришь, что вообще собираешься сохранить.

Ветка — параллельная линия сохранёнок. Отпочковался, поэкспериментировал, не понравилось — выкинул ветку, основная линия не тронута. HEAD — указатель «ты сейчас вот здесь».

.gitignore — список того, за чем Git следить не должен: временные файлы, тяжёлое, и — критически важно — секреты. Подробнее в главе 8.

Git и GitHub — разные вещи. Git целиком работает на твоей машине и в интернете не нуждается. GitHub — сервис, куда можно отправить копию. Можно годами пользоваться Git без всякого GitHub.

Worktree — одним абзацем, чтобы ты узнал слово. Обычно у тебя одна папка и в ней одна ветка за раз. Worktree позволяет разложить две ветки одного репозитория в две разные папки и работать с ними одновременно. Полезно, когда агент экспериментирует, а ты параллельно смотришь рабочую версию. Не нужно на старте — просто знай, что такое есть.

И главное, что стоит услышать в начале: правильного способа делать коммиты не существует. Как правильно называть? Как часто? Что класть в один? Нет такого. Есть только удобный тебе. Единственное объективное правило — коммит должно быть возможно откатить, не задев несвязанное.

А теперь по-настоящему

Он решает три разные задачи, и полезно понимать, какая из них твоя.

1. Бэкап. Самая недооценённая. Ноутбук — единственная копия твоей работы ровно до первого git push.
2. История и совместная работа. Видно, что менялось; можно обсуждать изменения; можно пустить второго человека.
3. Источник для деплоя. Хостинги умеют следить за репозиторием и выкладывать сайт при каждом изменении. Об этом глава 9.

Remote — «дальняя» копия репозитория, обычно по имени origin. git push — отправить свои коммиты туда, git pull — забрать оттуда. Приватный репозиторий видишь только ты и кого пустишь; публичный — весь интернет, включая поисковики и роботов, которые целенаправленно ищут в чужом коде ключи.

GitHub Actions — машина, которая делает что-то при каждом пуше: собирает, проверяет, выкладывает. Описывается файлом в репозитории. Ей можно дать секреты — они хранятся отдельно от кода, и человек, открывший репозиторий, их не увидит.

README.md — первый файл, который открывает и человек, и агент. Три абзаца о том, что это за проект и как его запустить, экономят потом часы.

А теперь по-настоящему

Три механизма по возрастанию сложности — по одному на каждую ступень из главы 2.

1. Синхронизация файлов. Берём содержимое папки и копируем в хранилище. Никакой сборки, никакого запуска. Самый прозрачный вариант: что положил, то и отдаётся.

Здесь живёт флаг, о который бьются все. Синхронизация обычно умеет режим «удалять то, чего нет у источника». Он нужен — иначе на сервере годами копится мусор. Но он означает: удалил файл локально — он исчезнет и на сайте. Это не баг, это буквально смысл слова «синхронизация».

2. Автодеплой платформы. Платформа следит за репозиторием: увидела пуш — забрала код, собрала, разложила. Даёт логи сборки (читай их, когда «не работает») и превью-ссылки на ветки. Ты не управляешь процессом, ты его настраиваешь один раз.

3. Скрипт на своём сервере. Подключиться, забрать свежий код, поставить зависимости, перезапустить процесс. Максимум контроля и максимум мест, где может отвалиться.

Слова, которые встретятся: билд — сборка исходников в готовые файлы (у чистой статики его нет). Артефакт — то, что получилось после сборки. Пайплайн — вся цепочка от пуша до живого сайта. Окружение — набор настроек: обычно есть «боевое» и хотя бы твоё локальное.

Почему «локально работает, а там нет». Четыре причины покрывают почти все случаи:

• Файл есть у тебя, но не уехал — он в .gitignore.
• Переменные окружения заданы у тебя и не заданы там.
• Разные версии — языка, библиотек, системы.
• Пути. У тебя Изображения/Фото.PNG откроется как фото.png, на сервере — нет: там регистр важен.

А теперь по-настоящему

Пять мест, где это вылезает. Симптомы разные, причина одна.

1. Пути. В Linux — прямые слэши от корня: /home/user/project. В Windows — буква диска и обратные слэши: C:\Users\ilya\project. Обратный слэш во многих языках означает «следующий символ особенный», поэтому путь молча превращается в мусор: C:\Users\ilya становится C:Usersilya. Обрубленный путь в тексте ошибки — это почти всегда съеденные слэши.
2. Имена команд. В Linux интерпретатор Python зовут python3. В Windows — просто python, а python3 ведёт на заглушку из магазина приложений, которая молча не работает. То же с pip против python -m pip. Агент по привычке пишет первое, получает невнятную ошибку и тратит несколько попыток подряд, чтобы догадаться.
3. Кавычки и экранирование. У оболочек разные правила: где-то одинарные кавычки означают одно, где-то другое. Одна и та же команда работает в одном окне и падает в другом с невразумительным сообщением про синтаксис.
4. Кодировки. Windows исторически читает и пишет файлы не в UTF-8. Отсюда UnicodeDecodeError с упоминанием charmap и кракозябры вместо русского текста.
5. Переводы строк. Windows завершает строку двумя невидимыми символами, Linux одним. Шелл-скрипт, отредактированный на Windows, на сервере падает с bad interpreter: /bin/bash^M. Символ ^M в конце сообщения — визитная карточка.

Какую оболочку выбрать. Из коробки у тебя, скорее всего, cmd — там нет ни вкладок, ни нормальной истории. Стоит перейти на PowerShell: он уже установлен и заметно удобнее.

Git Bash — вторая дорога: он даёт привычные Linux-команды, и многие инструкции из интернета в нём просто работают. Цена — он переписывает пути на свой лад, и часть настроек агента может потерять ориентиры.

Честный вывод, без «правильного ответа»: обе дороги кривые. Как и почти всё в этой индустрии — выбор не между хорошим и плохим, а между плохим и не самым плохим. Важно не угадать «правильную», а выбрать одну осознанно и записать выбор в инструкции, чтобы агент не гадал.

Шаги

1. Проверь, что Git вообще есть. git --version Ответ вида git version 2.x.x — всё в порядке. «Команда не найдена» — поставь Git и перезапусти терминал: без перезапуска он не появится.
2. Представься. Один раз на всю жизнь. git config --global user.name "Твоё Имя" git config --global user.email "ты@почта.ру" Это уйдёт в каждый твой коммит. Почта попадёт в публичную историю, если репозиторий станет публичным, — используй ту, которую не жалко.
3. Зайди в папку проекта и сделай её репозиторием. cd "C:/путь/к/проекту" git init Появилась скрытая папка .git. С этого момента история пишется.
4. Создай .gitignore — до первого коммита, не после. Файл с таким именем в корне проекта, внутри — что не отслеживать. Минимум: .env .env.* node_modules/ *.log .DS_Store Почему до, а не после: попавшее в историю остаётся в ней навсегда. Добавить правило потом — значит перестать отслеживать дальше, но не стереть прошлое.
5. Посмотри, что Git видит. git status Список файлов, за которыми он пока не следит. Прочитай его. Это единственный момент, когда легко заметить лишнее.
6. Отбери файлы для первой сохранёнки. git add . Точка означает «всё из текущей папки, кроме игнорируемого».
   Перед git add . посмотри git status и убедись, что в списке нет ключей, паролей, .env и чужих персональных данных. Это займёт пять секунд и иногда экономит очень много.
7. Запечатай. git commit -m "Первый коммит: рабочая версия проекта" Сообщение пиши для себя из будущего. Через месяц «update» тебе ничего не скажет.
8. Создай пустой репозиторий на GitHub. Через сайт: New repository, имя, Private. Не ставь галочки «добавить README» и «добавить .gitignore» — иначе на той стороне появится своя история, и первый push упрётся в конфликт.
9. Свяжи локальный репозиторий с GitHub. git remote add origin https://github.com/ТВОЙ_ЛОГИН/ИМЯ_РЕПО.git origin — просто общепринятое имя для «основной дальней копии».
10. Отправь. git push -u origin master Если ветка называется main, подставь его — git status покажет имя в первой строке. Флаг -u нужен только в первый раз: он запоминает связку, дальше хватит просто git push.

Путь 1. Платформа с автодеплоем

Когда этот путь твой: проект в GitHub, нужен результат сегодня, домен можно привязать позже.

1. Зарегистрируйся через GitHub. Так платформа сразу увидит репозитории.
2. Подключи репозиторий. Add new site → Import an existing project, выбери свой.
3. Укажи ветку и папку публикации. Для чистой статики команда сборки пустая, папка публикации — та, где лежит index.html. Ошибка на этом шаге даёт «страница не найдена» при живом деплое.
4. Дождись сборки и прочитай лог. Даже если всё зелёное — открой и посмотри, как он выглядит в норме. Когда сломается, ты будешь знать, с чем сравнивать.
5. Открой выданный адрес. Он некрасивый, но рабочий и уже с сертификатом.
6. Привяжи домен. Платформа скажет, какую запись завести. Дальше — глава 4.

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

Путь 2. Объектное хранилище

Когда этот путь твой: нужна максимальная дешевизна и предсказуемость, важна страна размещения, готов потратить час на первую настройку.

1. Создай бакет. Имя часто должно совпадать с доменом — проверь требования до создания, переименовать нельзя.
2. Включи режим раздачи сайта и укажи главную страницу (index.html) и страницу ошибки.
3. Сделай содержимое публичным. Пока не сделаешь — будешь получать отказ в доступе и думать, что сломался деплой.
4. Залей файлы. Первый раз можно через интерфейс, дальше — командой синхронизации или через автоматику.
5. Проверь по служебному адресу до привязки домена. Так ты отделишь проблемы хранилища от проблем DNS.
6. Привяжи домен и дождись сертификата. Обычно нужна дополнительная служебная запись, и выпуск занимает от минут до часов.

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

Путь 3. Свой сервер

Когда этот путь твой: нужна круглосуточная работа — фоновые задачи, расписание, бот.

1. Создай машину в панели провайдера. Самой дешёвой обычно хватает.
2. Подключись по SSH. Первый раз спросит подтверждение ключа — это нормально.
3. Забери код. git clone https://github.com/ЛОГИН/РЕПО.git cd РЕПО
4. Поставь зависимости и задай переменные окружения. Секреты — в файл вне репозитория, а не в код.
5. Запусти процесс так, чтобы он пережил закрытие терминала и поднимался сам после перезагрузки.
6. Проверь, что он действительно работает, а не «запустился и упал»: посмотри статус и логи.

Первое, что сломается: процесс, умирающий вместе с твоим терминалом. Второе — отсутствующие переменные окружения, которых на твоей машине не видно, потому что там они есть.

Готовый .gitignore

Положи в корень проекта. Комментарии оставь — через полгода они объяснят тебе твои же решения.

Строка !.env.example — не опечатка. Восклицательный знак означает исключение из правила выше: шаблон со списком нужных переменных и пустыми значениями хранить надо. Это документация, по которой ты сам через месяц поймёшь, что настраивать.

Куда класть секреты вместо кода

Как проверить, не утекло ли уже

1. Посмотри, что вообще отслеживается.git ls-files Пробеги глазами. Файлы с говорящими именами — .env, config, secret, credentials — открой и проверь.
2. Поищи по всей истории, а не только по текущим файлам.git log -p -S "sk-" --all git log -p -S "PASSWORD" --all Флаг -S ищет коммиты, где строка появлялась или исчезала. Подставь префиксы ключей своих сервисов.
3. Проверь, что репозиторий действительно приватный, и посмотри список тех, у кого есть доступ. Там бывают неожиданные люди — соавторы старых экспериментов, интеграции, боты.

Правило при передаче проекта

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

Минута перед пушем

1. Что именно уезжает? git status git diff --staged Первая команда — список файлов, вторая — построчные изменения. Если видишь незнакомое — разберись до пуша, а не после.
2. Что пропало? git status --short | findstr "^ D" Отдельный вопрос, потому что удаления замечают хуже, чем добавления. При синхронизирующем деплое случайно стёртый файл исчезнет и с живого сайта.
3. Нет ли секретов? Пробеги список из шага 1 глазами: .env, что-то со словом key, token, secret, password, любые выгрузки с чужими данными.
4. Оно вообще работает? Открой локально и ткни в то, что менял. Звучит унизительно очевидно — и пропускается чаще всего.
5. Та ли ветка? git branch --show-current Пять секунд против получаса разбирательств.
6. Понятно ли сообщение коммита? Проверка: прочитает ли его человек через месяц и поймёт ли, что и зачем. «Правки» и «update» проверку не проходят.
7. Знаю ли я, как откатиться? Не абстрактно, а конкретно: какая команда, какая кнопка. Если ответа нет — узнай сейчас, а не в момент, когда сайт лежит.
8. Хорошее ли сейчас время? Пуш в пятницу вечером перед выходом из дома — классика жанра. Автоматика сработает через минуту, а чинить будет некому.

Пункты 1–3 обязательны всегда. Остальные — по ситуации, но именно они превращают чеклист из ритуала в инструмент.

1. Сайт не открывается совсем

Проверь по порядку: открывается ли в приватном окне и с телефона по мобильному интернету (отсекает твой кэш и твою сеть) → не истёк ли домен → на месте ли DNS-записи → жив ли хостинг (статусная страница провайдера).

Как не повторить: включи автопродление домена и проверь, что уведомления идут на живую почту. Истёкший домен — самая обидная и самая частая причина.

2. Сайт открывается, но старый

Проверь: приватное окно → жёсткое обновление (Ctrl+F5) → прошла ли выкладка вообще (логи автоматики) → сброс кэша на стороне сети раздачи.

Как не повторить: привыкни проверять результат в приватном окне. Это отсекает 80% ложных тревог.

3. Выкладка прошла, изменений нет

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

Как не повторить: один раз прочитай лог успешной выкладки целиком. Дальше отличия будут бросаться в глаза.

4. Браузер ругается на сертификат

Проверь: на месте ли служебная TXT-запись для продления → не включил ли кто-то проксирование → совпадает ли имя в сертификате с адресом (частый случай: сертификат на site.ru, а открываешь www.site.ru).

Как не повторить: запиши, зачем заведена каждая служебная DNS-запись, прямо в комментарии к ней. Через полгода ты не вспомнишь и снесёшь при уборке.

5. Локально работает, на боевом нет

Проверь четыре причины по порядку: файл не уехал (он в .gitignore) → не заданы переменные окружения → разные версии → регистр в путях (у тебя Logo.PNG и logo.png — один файл, на сервере — два разных).

Как не повторить: заведи .env.example со списком нужных переменных и держи имена файлов в нижнем регистре.

6. Случайно удалил файл и закоммитил

Чинится. Найди коммит, где файл ещё был, и достань его оттуда:

Как не повторить: пункт 2 чеклиста перед пушем — смотреть, что пропало.

7. Запушил секрет

Порядок жёсткий: отозвать и перевыпустить ключ прямо сейчас → проверить журнал использования и счёт → добавить файл в .gitignore → чистка истории последней и по желанию.

Как не повторить: практика 3 целиком.

8. Агент сломал проект, а коммита не было

Что можно попробовать: история чата агента — иногда прежнее содержимое файла видно там → локальная история файлов в редакторе, если он её ведёт → корзина, если файл удалён целиком.

А честный ответ такой: скорее всего, восстановить нечего. Это единственный пункт в списке, где нет надёжного способа. Git не поможет — сохранять было нечего. Перезаписанный файл не лежит в корзине.

Как не повторить: коммит перед тем, как дать агенту большую задачу. Одна команда, пять секунд, и этот пункт списка перестаёт существовать. Именно поэтому глава 7 говорит, что Git — это то, что позволяет разрешать агенту больше.

Четыре правила формулировки

1. Симптом, а не диагноз. Ты не знаешь, что сломалось, — иначе не спрашивал бы. Назвав поломку своим именем, ты сужаешь поиск до своей же догадки, и агент послушно ищет там, где ты показал.

Было: «сломался деплой, почини».
Стало: «я запушил 20 минут назад, на сайте старая версия, в логах автоматики всё зелёное».

2. Контекст окружения в первой же реплике. Операционная система, хостинг, что менялось последним. Без этого агент по умолчанию предполагает Linux и выдаёт команды, которые у тебя не работают, — а вы оба потратите на это несколько попыток.

Было: «не работает команда».
Стало: «Windows 11, PowerShell, сайт на статике, вчера менял DNS. Команда падает вот так: [вывод целиком]».

3. Проси план проверки, а не решение. Это самое важное правило страницы. Агент, которого просят починить, начинает чинить — трогать файлы, менять настройки. Если гипотеза была неверна, ты получаешь исходную поломку плюс новые изменения, в которых уже не разобраться.

Было: «почини».
Стало: «дай пять гипотез по убыванию вероятности и как проверить каждую. Ничего не меняй, пока я не скажу».

4. Запрети менять то, что не объяснил. Простое правило: сначала объяснение, потом действие. Оно и тебя учит, и ловит случаи, когда агент собирается сделать не то.

Формулировка: «объясни, что делает эта команда и что она изменит на диске, до того как выполнять».

Почему «сделай лучше» не работает

У агента нет твоего критерия «лучше». Он начинает угадывать — и угадывает по среднему, то есть делает шаблонно. Ты смотришь на результат, он тебе не нравится, ты снова говоришь «сделай лучше», и цикл повторяется, сжигая лимиты.

Лечится переводом «лучше» в проверяемое: «сократи вдвое», «убери всё, что не отвечает на вопрос X», «сделай так, чтобы это открывалось за секунду». Критерий должен быть таким, чтобы вы оба могли посмотреть на результат и согласиться, выполнен он или нет.

Готовые запросы под восемь аварий

Шаги

1. Выбери оболочку и закрепи выбор. Открой PowerShell (не cmd) и закрепи на панели задач, чтобы дальше всегда запускать одно и то же. Проверка: $PSVersionTable.PSVersion Если не сработало — ты в cmd, а не в PowerShell. Закрой и открой именно PowerShell.
2. Проверь, какой Python реально вызывается. python --version python3 --version Первая должна дать версию. Вторая — либо ошибку, либо открытие магазина приложений: это заглушка, не интерпретатор.
   Если python тоже открывает магазин — ты ещё не ставил настоящий Python, либо при установке не была отмечена галочка «Add to PATH». Поставь заново с галочкой.
3. Включи режим UTF-8 глобально. setx PYTHONUTF8 1 Обязательно открой новый терминал — переменная не появится в уже открытом. Проверка: python -c "import sys; print(sys.flags.utf8_mode)" Ждём 1. Получил 0 — терминал старый, перезапусти.
4. Напиши блок про окружение в файл инструкций агента. В CLAUDE.md в корне проекта (или в глобальный, если хочешь один раз на всё). Готовый текст — подставь свои значения: ## Рабочее окружение ОС: Windows 11. Пользовательский терминал: PowerShell. Оболочка для выполнения команд: [PowerShell / Git Bash] — используй ЕЁ синтаксис, не смешивай с другой. Python: вызывать `python`, НЕ `python3` (`python3` на этой машине — заглушка из Microsoft Store). Установка пакетов: `python -m pip`, не `pip3`. PYTHONUTF8=1 выставлен глобально — encoding='utf-8' в open() передавать не нужно. Пути: в кавычках, через прямые слэши — "C:/Users/имя/проект". Обратные слэши съедаются как экранирование. Проверка: начни новый диалог и спроси «в каком окружении мы работаем». Агент должен ответить по этому блоку, а не догадками.
5. Настрой переводы строк — если в проекте есть скрипты для Linux-сервера. Создай .gitattributes в корне: *.sh text eol=lf Без этого Git на Windows может дописать в скрипты лишний символ, и на сервере они упадут с bad interpreter: /bin/bash^M. Файлов .sh в проекте нет — шаг пропусти.
6. Проверь всё вместе. Попроси агента выполнить одну команду, которая задевает все настройки сразу: python -c "import sys,os; print(sys.version.split()[0], sys.flags.utf8_mode, os.getcwd())" Должны увидеть версию, единицу и путь к текущей папке — без ошибок кодировки и без нескольких попыток со стороны агента. Если агент пробует несколько раз — блок из шага 4 либо не написан, либо лежит не там, где агент его читает.

Как пользоваться

Прочитал главу и не уверен, что понял, — найди в таблице проект, который её иллюстрирует, и посмотри, как там сделано. Одна и та же тема на трёх ступенях выглядит по-разному, и понимание приходит именно из сравнения: почему здесь так, а там иначе.