Manage Beget Site

Работа С Сайтами На Beget

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

Главная Модель

Не считать сайт одной папкой и не искать один универсальный источник правды. Для каждой затронутой единицы состояния определить:

источник правды
фактическое live-состояние
желаемое состояние
владельца изменения
способ доставки или редактирования
способ резервирования
способ проверки
способ отката

Учитывать при наличии:

• код и публичные файлы;
• собранные ассеты;
• CMS-контент и базу;
• пользовательские uploads;
• конфигурацию и секреты;
• PHP или другой runtime;
• кэш и сессии;
• cron, очереди и процессы;
• правила веб-сервера;
• домен, DNS и SSL;
• внешние хранилища и сервисы.

Разделять:

• deploy-owned — части, которые обновляются из проекта;
• runtime-owned — данные, которые возникают или изменяются на работающем сайте.

Не удалять runtime-owned данные только потому, что их нет в локальном проекте.

Начать С Контекста Проекта

1. Прочитать применимые AGENTS.md и project skills.
2. Проверить Git-состояние и не затронуть чужие незавершённые изменения.
3. Найти существующий deploy/project документ.
4. Установить, что именно пользователь поручил: исследовать, опубликовать, обновить, восстановить, переключить или исправить.
5. Не считать старый чат доказательством текущего server state.

Если проектной фиксации нет, после первого доказанного структурного прохода создать или предложить создать её по project-contract.md. Не создавать тяжёлый отчёт ради мелкой CMS-правки.

Выбрать Операционный Режим

Read-Only Диагностика

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

Плановый Выпуск

Изменить правильный проектный источник, проверить выпускной кандидат, затем опубликовать утверждённый состав.

Управляемая Правка Через CMS

Если CMS является источником конкретного контента, менять его в CMS, а не создавать локальный HTML-дубль. Проверить публичную страницу и побочные маршруты.

Перенос Или Переключение

Рассматривать файлы, данные, runtime, домен и серверную конфигурацию как связанную систему. Планировать период, когда трафик может попадать на разные контуры.

Emergency Hotfix

Применять прямую live-правку только когда цена ожидания выше риска. Сделать соразмерный бэкап и после стабилизации вернуть изменение в соответствующий проектный источник.

Восстановление

До записи связать копию с конкретным доменом, папкой, базой, временем и составом. После восстановления повторить live-проверку.

Выполнить Рабочий Цикл

1. DISCOVER

Определить источники, серверный доступ, существующие документы и доступные инструменты. Для Beget-среды читать beget-environment.md.

2. CLASSIFY

Классифицировать систему по фактическому устройству, а не только по названию CMS:

• статический артефакт;
• серверный код без базы;
• файлы + база;
• управляемая CMS;
• process-based приложение;
• неизвестный или смешанный стек.

Для неизвестного стека обязательно читать stack-discovery.md.

3. MAP_STATE

Построить карту единиц состояния, источников, владельцев и зависимостей. Отметить deploy-owned и runtime-owned части.

4. PLAN

Выбрать ветку из deployment-branches.md. Составить манифест:

сайт и live URL
операционный режим и технологический класс
источники правды затронутых единиц
deploy-owned и runtime-owned части
доказанный целевой Beget-контур
точный состав изменения
что не будет затронуто
точный видимый список удаления или `NO_DELETIONS`
бэкап и проверка его пригодности
ожидаемая недоступность
триггеры и порядок отката
live-проверки
неизвестные и остаточный риск
достаточно ли текущего разрешения

5. PROVE_TARGET

Связать фактами:

live-домен
-> document root или точку запуска
-> нужное приложение/runtime
-> фактическую базу и внешнее состояние при наличии

Не угадывать public_html. Не считать имя папки доказательством назначения.

6. PROVE_BACKUP

Резервировать все изменяемые единицы, необходимые для отката. Проверить существование, размер, читаемость, принадлежность и способ восстановления.

Для изменяемого динамического сайта получить согласованную точку восстановления файлов, базы и uploads либо явно зафиксировать остаточный риск. Читать rollback-and-incidents.md.

7. AUTHORIZE_WRITE

Сопоставить текущую команду пользователя с манифестом.

Считать текущую команду достаточным разрешением, если одновременно:

• пользователь прямо поручил live-операцию;
• проект и назначение однозначны;
• состав не расширился после исследования;
• не возник новый существенный риск;
• операция соответствует ожидаемому уровню разрушительности.

В этом случае дать короткое предоперационное обновление с назначением, бэкапом, действием и проверкой и продолжить без повторного вопроса.

Запросить отдельное подтверждение, если:

• пользователь просил план, аудит или read-only проверку;
• live или путь выбирается из нескольких вариантов;
• манифест существенно шире исходной команды;
• dry-run показал неожиданное удаление или изменение;
• затрагиваются неупомянутые база, домен, DNS, PHP, процессы или runtime-owned данные;
• последствия или откат не доказаны.

Для любого удаления на live владелец должен увидеть точный список удаляемых путей или объектов и явно разрешить именно его. Общая команда опубликуй или задеплой не разрешает скрытое удаление внутри синхронизации. Не задавать второй одинаковый вопрос, если текущая команда уже прямо одобряет показанный список и после dry-run он не изменился. Новый элемент или расширившийся список требуют нового подтверждения.

8. APPLY

Выполнить только утверждённый состав. До массовой операции получить dry-run или эквивалентный diff.

Не использовать удаляющую синхронизацию без подтверждённого allowlist, проверенного бэкапа, точного видимого списка удаления и явного разрешения владельца на этот список. Общая команда на публикацию этого не заменяет. Не печатать секреты. Не размещать дампы и бэкапы в webroot или Git.

9. LIVE_VERIFY

Проверить не факт загрузки, а рабочий результат. Читать live-verification.md.

Минимум:

• правильный домен и канонические редиректы;
• главная и представители затронутых типов;
• ассеты и пользовательское действие;
• административный сценарий при наличии CMS;
• формы, cookies и внешние интеграции при затрагивании;
• логи и отсутствие новых критических ошибок;
• отсутствие публичных setup/import/backup/diagnostic файлов.

HTTP 200 не доказывает правильность содержания и поведения.

10. ACCEPT Или ROLLBACK

Сохранить выпуск только после live-проверки. При срабатывании заранее определённого триггера не исправлять production бесконечно: вернуть согласованную версию и проверить её.

11. RECORD

Зафиксировать фактический выпуск соразмерно риску и повторяемости. Указать безопасные факты, бэкапы, проверки, отклонения и остаток. Не записывать секреты.

Emergency-правку вернуть в проектный источник в текущем проходе. Если это невозможно, явно зафиксировать drift и ближайшее обязательное действие.

Всегда Соблюдать

• Не редактировать локальный или серверный дубль, который не является источником нужной единицы.
• Не считать локальную версию единственным источником всего сайта.
• Не печатать пароли, приватные ключи, полный .env и конфигурацию с секретами.
• Не считать созданный файл доказанным бэкапом без проверки.
• Не смешивать несогласованные по времени файлы и базу как одну точку восстановления.
• Не перезаписывать uploads, CMS-данные или server-owned конфигурацию общей синхронизацией.
• Не оставлять публичные служебные инструменты.
• Не удалять старый рабочий контур до приёмки нового и отдельного решения.
• Не удалять live-пути или объекты, которые не были показаны владельцу в точном списке и явно им одобрены.
• Не закрывать внешнее действие владельца техническим статусом сайта.
• Не применять CMS-специфичную команду к неизвестной системе без актуальной официальной документации.
• Не считать staging доказательством поведения live-домена.
• Не завершать работу, пока нужные сессии и проверки продолжают выполняться.

Остановиться

Остановить production-запись и объяснить недостающее, если нельзя доказать хотя бы одно критичное звено:

• источник изменяемой единицы;
• фактический live-контур;
• runtime-owned границы;
• пригодный бэкап;
• порядок отката;
• достаточное разрешение;
• способ проверить результат.

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

Формат Пользовательских Обновлений

До записи сообщить человеческим языком:

что изменится и на каком сайте
что сохранено для отката
почему текущее разрешение достаточно или чего не хватает
как будет проверен результат

После работы сообщить:

что реально изменено
где проверено на live
какие бэкапы доступны
готов ли откат
какой остаток или внешнее действие осталось

Не подменять этот ответ длинным техническим логом.