Imported from PolinaShun/shundeevacare-site (AGENTS.md). Install upstream with npx skills add PolinaShun/shundeevacare-site. Copyright stays with the author.

ShundeevaCare — сайт психолога Полины Шундеевой

Правила для любых ИИ-агентов (Hermes, Cursor) и людей, которые работают с этим репозиторием. Читать целиком перед первой правкой. Раздел «Релиз» — обязательный: его нарушение 18.09.2026 оставило сайт пустым (разбор в конце файла).

1. Что это

Статический сайт психолога-психоаналитика Полины Шундеевой. HTML/CSS/JS, без бэкенда и админки.

Прод: https://shundeevacare.ru — это ветка main этого репозитория
Пуш в main = публикация на сайте. Отдельного «деплой-шага руками» нет
Хостинг: Cloud4box (статикa + SSL Let's Encrypt, авто-обновление)
Домен: на владельце сайта, продлевает она сама

2. Карта файлов

Файл	Назначение
`index.html`	Главная
`for-psychologists.html`	Страница для психологов
`blog.html`	Блог
`reviews.html`	Отзывы
`materials/index.html`	Хаб материалов
`materials/*.html`	Статьи
`robots.txt`	Правила индексации
`sitemap.xml`	Карта сайта
`llms.txt`	Описание сайта для ИИ-поисковиков
`.htaccess`	Правила Apache (кэш, MIME, безопасность)
`TEST_PROTOCOL.md`	Чек-лист перед публикацией
`scripts/ftp_deploy.py`	Единственный разрешённый способ выкладки
`.github/workflows/deploy.yml`	Запускает скрипт выкладки на пуш в `main`

Секретные доступы (хостинг, панель, FTP) — в локальном CONTEXT.md у владельца. В репозитории их нет и быть не должно.

3. 🚫 ЖЁСТКИЙ ЗАПРЕТ: не ходить на хостинг по FTP

Запрещено подключаться к хостингу по FTP, FTPS или SFTP — ни читать, ни писать, ни «просто посмотреть», ни «быстро поправить один файл». Без исключений по инициативе агента.

Почему это правило жёсткое:

FTP-сервер хостинга работает нестабильно. Он периодически не присылает финальный ответ 226: клиент видит «FTP response timeout», а файл на сервере остаётся нулевым или обрезанным (реальные следы: index.html 0 байт, sitemap.xml 0, blog.html обрезан до 10 464, PDF — до 1 045 092). Ориентироваться на код ответа FTP нельзя, только на размер файла.
Любая запись мимо git расходится с репозиторием. После этого никто не знает, что реально на проде: файлы живут своей жизнью, а следующий деплой перезаписывает или обнуляет их.
Это уже привело к аварии. 18.09.2026 сайт лежал с пустыми страницами именно из-за записи в обход нормального пути.
SFTP на этом хостинге нет — не тратить время на попытки (порт открыт, но подсистема отключена).
Ручная загрузка через панель ISPmanager — тоже не штатный путь. Допускается только как аварийное восстановление, только по прямому указанию владельца сайта или Веры, и обязательно с последующей сверкой всех файлов по размерам и фиксацией результата в git.

Единственный разрешённый способ записи на сайт:

правки в репозитории → коммит → пуш в main → GitHub Actions → scripts/ftp_deploy.py

Скрипт сам заливает файлы, сверяет размеры на сервере и повторяет попытки; падает только если размеры не сошлись. Он устроен так специально из-за поведения FTP — не заменять его на готовые FTP-экшены.

4. Порядок релиза (обязательный)

git pull перед работой. Владелец правит сайт сам и может переписать историю (force-push) — локальная копия легко окажется «в прошлом».
Правки — только в файлах репозитория. Никаких правок прямо на хостинге.
Пройти TEST_PROTOCOL.md по изменённым страницам.
Вызвать независимого критика (раздел 5). Без его таблицы PASS релиз не считается проверенным.
Коммит с внятным сообщением, затем пуш. Пуш — по явной команде владельца сайта («пушим»), а не по инициативе агента.
После прогона Actions проверить результат фактом (раздел 7): размеры файлов и отдачу страниц. Зелёный прогон — не доказательство, доказательство — совпавшие размеры и рабочие страницы.

5. Независимый критик — обязательный шаг релиза

Перед объявлением релиза готовым запускать отдельного агента-критика: отдельный вызов/сессия, минимум та же модель (лучше сильнее), без участия того, кто делал правку.

Что передать критику:

исходную задачу и критерии приёмки;
итоговый артефакт или git diff;
реальные результаты тестов и проверок.

Что критик ищет (он не переписывает работу, он её проверяет):

пропущенные требования и расхождение с задачей;
регрессии: что сломалось рядом, что перестало работать;
небезопасные допущения («наверное, домен жив», «наверное, файл залился»);
выдуманные факты: «сделано», «проверено», «залито» без доказательства;
тесты, которые не доказывают заявленный результат.

Формат замечаний: каждое — с доказательством и уровнем BLOCKER / MAJOR / MINOR. В конце — таблица PASS / FAIL / UNPROVEN по каждому критерию приёмки.

Правила после ревью: BLOCKER и обоснованные MAJOR исправляются, релевантные тесты повторяются; повторное ревью — только после существенных правок. Критик не нужен для справок, навигации и механических правок с детерминированной проверкой (например, добавить одну ссылку в список).

6. Что нельзя без согласования владельца

Видимый текст — заголовки, описания, кнопки, карточки, тексты статей. Ни одного символа.
Стиль и структура страниц — визуальная часть согласуется отдельно.
Можно без согласования: <head> (title, description, canonical, OG/Twitter, JSON-LD), robots.txt, sitemap.xml, llms.txt, TEST_PROTOCOL.md, код скриптов выкладки.

При добавлении статьи обязательны: materials/<slug>.html с canonical/OG/Article-schema, карточка в materials/index.html, строка в sitemap.xml и строка в llms.txt.

Другие запреты:

.github/workflows/ — только через ревью. Флаг dangerous-clean-slate (полная очистка каталога хостинга перед заливкой) возвращать нельзя ни при каких условиях: именно он стёр сайт 18.09.2026.
Ссылки — только относительные (без / в начале).
Секреты — только в GitHub Secrets. Никогда в файлы, коммиты, комментарии. CONTEXT.md в git не коммитить.

7. Как проверять результат (фактом, а не на слово)

# 1. Сверка файлов с хостингом: сколько расхождений (ничего не меняет)
DRY_RUN=1 FTP_USERNAME=<секрет> FTP_PASSWORD=<секрет> python3 scripts/ftp_deploy.py
#    ждём «расхождений 0»

# 2. Отдача страниц (пока домен жив — обычным curl)
curl -o /dev/null -s -w "%{http_code}\n" https://shundeevacare.ru/sitemap.xml
curl -o /dev/null -s -w "%{http_code}\n" https://shundeevacare.ru/

# 3. Разметка: JSON-LD и метаданные на месте
curl -s https://shundeevacare.ru/blog.html | grep -c 'application/ld+json'
curl -s https://shundeevacare.ru/ | grep -o '<title>[^<]*'

Правила проверки:

Код ответа сам по себе ничего не доказывает. 200 на страницу бывает и у пустого файла (после аварии index.html отдавался с кодом 200, будучи 0 байт). Проверять размер и содержимое.
О состоянии прода судить по файлам, а не по «вроде должно было залиться».
Если проверка невозможна (не отвечает домен, нет доступа) — так и сказать, а не делать вывод по догадке.

8. Разбор аварии 18.09.2026 (почему правила именно такие)

Домен истёк 10.09.2026, сайт восемь дней не открывался, об этом никто не знал. Теперь есть ежедневная проверка с оповещением.
Файлы на хостинге побились не из-за домена: деплой с флагом dangerous-clean-slate сначала вычистил каталог сайта, а потом упал на шаге заливки. Сайт остался без index.html, reviews.html, sitemap.xml, с обрезанными страницами.
Ошибка была не в паролях и не в ключах, а в самом FTP хостинга (Timeout (control socket)).
Восстановили файлы вручную через панель, деплой переписали на скрипт с проверкой размеров — прогон снова зелёный.
Вывод: писать на сайт только через git, FTP напрямую не трогать, результат подтверждать размерами.

9. Частые задачи

Добавить статью: создать materials/<slug>.html (canonical, OG, Article schema, Breadcrumb) → добавить карточку в materials/index.html → строку в sitemap.xml (lastmod = дата коммита) → строку в llms.txt → прогнать TEST_PROTOCOL.md → критик → пуш.

Поправить SEO: можно без согласования владельца, меняются только <head> и служебные файлы; после — проверка критиком, если правок больше одной строки.

Проверить, что сайт живой: команды из раздела 7.

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

shundeevacare-site

About