skills/westudy/references/pages.md

# Сторінки та стилі сайту

## Знайти ціль

- Перевір школу через get_profile за загальними правилами навички. Школу визначає підключення; не передавай businessId.
- Звичайна сторінка: search_pages за назвою/alias; kind=standalone, limit до 50, cursor для наступних результатів. Відповіді містять тільки метадані. Не вибирай перший неоднозначний збіг.
- Головна: get_page {homepage:true}. Курс: search_courses → підтверджений courseUuid → get_page {courseUuid}. search_courses повертає landing: pageUuid, hasCustomPage, usesDefault, isPublished. usesDefault стосується публічного шаблону; hasCustomPage може бути true для ще не опублікованої чернетки. У такому разі редагуй її, не створюй другу.
- get_page повертає source=custom/default/empty. pageUuid=null означає, що власної сторінки ще немає. Шаблон — лише початкова основа, не сутність школи. create_page створює власну чернетку. Існуюча головна/лендінг курсу спричиняє CONFLICT замість дубліката.
- Лендінги вебінарів, навчальні матеріали курсу та меню/призначення іншої головної сторінки цими командами не підтримуються.

## Типові блоки сторінок

Під час створення або повного перепроєктування головної за замовчуванням включай `courses_all`, якщо користувач явно не попросив прибрати блок курсів або задав структуру без нього. Місце секції обирай за композицією. Для лендінгу курсу за замовчуванням став `course_landing_promo` першим, якщо не запитаний інший початок чи сторінка без цього блока: він показує актуальні назву/фото курсу й має штатну реєстрацію. Прочитай `get_design_reference` для library=constructor, ids=`["page", "blocks/courses_all"]` або `["page", "blocks/course_landing_promo"]` відповідно; параметри, приклади й вимоги до хоста містить каталог.

Для лендінгу поточного курсу не дублюй courseUuid у `config.course_uuid` промоблока: публічний хост передає `data.course`, а явний config.course_uuid перемикає блок на `data.courses[uuid]`. Прив’язку сторінки до підтвердженого courseUuid виконуй командою сторінки. Не вигадуй даних курсів або дій реєстрації. Не дублюй наявні блоки, не повертай прибрані за проханням користувача. При точковому редагуванні не додавай/не переставляй секції заради цих рекомендацій. Явний вибір користувача має пріоритет.

## Поточна дизайн-система та приклади оформлення

Перед створенням або редагуванням сторінки школи прочитай `get_site_config`. Використовуй отриманий `generalConfig` для побудови, перевірки й перегляду сторінки. Він охоплює палітру, кольорові схеми, типографіку, кнопки, форми та інші системні стилі компонентів. Віддавай перевагу успадкуванню та посиланням на системні кольори й текстові ролі; зберігай наявні локальні винятки при сторонніх правках.

Коли немає прямого доручення змінити загальну дизайн-систему, коротко повідом: «Створюю сторінку в поточній дизайн-системі школи. Якщо потрібно змінити загальний стиль сайту, попроси про це окремо». Для редагування адаптуй текст: «Редагую сторінку зі збереженням поточної дизайн-системи школи…». Використовуй мову користувача, повідом один раз на початку роботи зі сторінкою та продовжуй виконання без додаткового погодження. Не повторюй підказку на кожній дрібній правці в тому самому завданні. Новий чат або `source=default/custom` не є підставою автоматично генерувати нову тему чи починати опитування про бренд.

Якщо користувач дає картинку, скриншот, сайт або інший приклад і просить схоже оформлення, порівняй саме запитані риси з чинною темою. Відмінна композиція, тексти чи фотографії не потребують зміни загального конфіга. Якщо суттєво відрізняються палітра, типографіка, оформлення кнопок або форм, а межі зміни не визначені, коротко назви відмінності й уточни: «Змінити загальну дизайн-систему для всього сайту чи відтворити цей стиль тільки на цій сторінці?» Поясни, що запис загального конфіга діє одразу на всі сторінки, які успадковують змінені стилі. Сам приклад не є дорученням змінити весь сайт. До відповіді не записуй спірні зміни оформлення; можна готувати незалежний зміст або тимчасовий перегляд пропозиції. Якщо приклад неможливо переглянути, повідом про це й не вигадуй візуальних відмінностей.

Якщо користувач уже вказав «лише ця сторінка/кнопка/форма», застосуй підтримувані локальні налаштування без зміни SITE-конфіга. Не проси знову вибрати область змін. Коли обрано зберегти стиль школи, адаптуй приклад до нього; не компенсуй це рішення масовим перевизначенням усіх стилів у блоках. Якщо потрібний локальний виняток не підтримується, поясни обмеження, а не змінюй глобальну тему мовчки.

За прямим дорученням змінити загальну тему використовуй `update_site_config` за правилами нижче, без повторного погодження вже визначеної дії. При генерації теми узгоджуй також кнопки, форми й інші компоненти; при частковій зміні збережи решту конфіга. Для перегляду пропозиції можна передати пробний конфіг у `preview_design`, явно назвавши його пропозицією. Для фактичної сторінки використовуй активний конфіг або результат успішного збереження нової теми: `create_page` / `update_page` не встановлюють переданий `generalConfig` у школі.

## Прочитати й відредагувати

1. get_page повертає `page` — native {blocks, config}, `metadata`, `lang`, `contentLang`, `revision`, `hasChanges`, `translationPublished`, `isPublished`. Це редакторський draft, а за його відсутності — опублікований контент. При відсутній мові береться опублікований переклад; contentLang показує який. Не бери основу з публічного сайту, бо там немає незавершених правок.
2. Окремо get_site_config повертає активний generalConfig та його revision. Потрібний SITE-конфіг для лендінгів; навчальні конфіги курсу цими командами не змінюються.
3. Читай каталог і потрібні розділи за [design.md](design.md). Для правки букви збережи решту native JSON, UUID, порядок і невідомі поля. Не перегенеровуй дизайн і не спрощуй ProseMirror. Не видаляй непідтримувані блоки заради валідації; поясни обмеження і запропонуй інтерфейс платформи.
4. create_page: kind=standalone/homepage/course, courseUuid лише для course; metadata.title і metadata.alias обов'язкові для standalone. `page` опціональний — без нього створюється порожня чернетка. З дизайном передай generalConfig для перевірки. generalConfig тут **не зберігається**.
5. update_page: pageUuid, lang із читання, expectedRevision, повний змінений page і generalConfig для перевірки. Непередані page/поля metadata залишаються незмінними. Сама команда не публікує і не приховує сторінку.
6. Нові форми/питання не мають UUID/id сутностей; їх видає PHP під час публікації. На тій самій сторінці зберігай наявні UUID блока/форми/питань. Не копіюй сутності з іншої сторінки, не підмінюй UUID і не змінюй тип існуючого питання. Не видаляй питання при сторонніх правках: публікація синхронізує їх із сутностями. Використання однієї наявної форми в різних місцях залишаємо інтерфейсу платформи.
7. При CONFLICT перечитай сторінку, порівняй зміни та повторно застосуй тільки намір користувача. Не замінюй revision на новий автоматично зі старим JSON. Нова версія даних — новий requestId.

## Публікація й негайні зміни

`publish_page` — окрема команда з окремим дозволом pages:publish. Викликай тільки коли користувач прямо попросив опублікувати цю сторінку або зміни. Погодження «зроби дизайн/відредагуй» саме по собі не означає публікацію. Використовуй revision щойно прочитаної/збереженої та перевіреної чернетки. Якщо запит уже містив публікацію, не проси повторного погодження без нової причини. Команда готує форми, переносить draft у content, прибирає draft і вмикає isPublished. Видимість спільна для мов: раніше опубліковані переклади також стають доступними. Після публікації бери нові UUID форм із результату, не з попереднього JSON.

`unpublish_page` — зняти сторінку з публікації за прямим дорученням користувача, з тим самим дозволом pages:publish. Передай pageUuid, lang і expectedRevision з get_page. Команда вимикає видимість **усіх мов** сторінки; lang визначає тільки версію прочитаних даних і мову відповіді. Контент, чернетки, метадані та спільні форми зберігаються. Це не видалення сторінки, не закриття самої форми та не повернення стандартного лендінгу. Якщо користувач просить приховати тільки один переклад, поясни, що команда приховує всю сторінку. Щоб згодом повернути публікацію, перечитай сторінку: publish_page опублікує наявну чернетку обраної мови, якщо вона є, тому не обіцяй просто повернення старого контенту.

`metadata` (title, description, alias, img) змінюється **одразу**, навіть у публічної сторінки. Не обіцяй чернетку метаданих. Alias можна змінювати тільки звичайній сторінці. Зміна адреси може зачепити існуючі посилання; використовуй лише за дорученням.

`update_site_config` зберігає **активні стилі всього сайту одразу**. Передай expectedRevision з get_site_config і повний generalConfig, зберігши неторкнуті поля. Використовуй лише за запитом змінити загальні стилі. Для експерименту з однією сторінкою достатньо preview_design з пробним конфігом; не записуй його глобально. Створення чернетки не є дорученням змінити весь сайт.

## Перевірка та результат

Перед записом дизайну — validate_design; після збереження перевір повернуту page і, якщо потрібно, створи preview_design з нею та актуальним generalConfig. Правила браузерного огляду — у design.md; форми не надсилати. Без браузера прямо скажи, що візуальна перевірка не виконувалася.

Кожен запис має requestId. Збережи його та executionId. Для QUEUED/RUNNING викликай get_execution. UNKNOWN/таймаут не означає, що запису немає: перевір виконання та стан сторінки. Не створюй іншу сторінку й не повторюй публікацію з новим requestId навмання. Повтор того самого requestId з тим самим payload повертає те саме виконання.

У фінальній відповіді назви сторінку й школу та точний стан: чернетку збережено / сторінку опубліковано / сторінку знято з публікації / активні стилі змінено. Якщо немає готового публічного URL у відповіді, не вигадуй адресу школи або маршрути. Preview є тимчасовим, не публічною адресою сторінки.