skills/westudy/references/questions.md

# Запитання для банків

Ці команди працюють із запитаннями в банку. Вони не створюють тест у лекції та не додають його до курсу.

## Вибір і читання

Знайди банк через `search_question_banks`; за потреби спочатку створи його через `create_question_bank`. Показуй школу, банк і курс (або загальний банк школи). Не вибирай перший з однакових результатів: уточни ціль у користувача. UUID бери з результатів сервера.

`list_questions` приймає `bankUuid`, необов'язкові `query` (фрагмент умови), `type`, `lang`, `limit` до 50 і `cursor`. Пошук буквальний, за текстом умови в усіх її мовах. `hasMore: true` потребує наступної сторінки навіть коли поточний фільтр дав порожній список. Для розрізнення показуй тип і preview. Порядок списку не означає порядок запитань у тесті.

`get_question` приймає `questionUuid` і `lang`. Повертає повний спрощений контент, UUID відповідей/пар, правильні відповіді, бали, `revision`, `usedByStudents` та фактичну мову `lang`. Для наступного редагування використовуй повернуту мову. Читання не потребує підтвердження.

## Створення

`create_questions` приймає `bankUuid`, `lang`, новий UUID `requestId` для цього пакета та масив `questions` від 1 до 50 елементів. Одне запитання — масив із одного елемента; окремої `create_question` немає.

Спочатку з'ясуй відсутні тему/матеріал, кількість і цільовий банк. Не повторюй уже надані питання. Можна запропонувати придатний тип, якщо користувач його не визначив. Для згенерованого набору покажи запитання, правильні відповіді та місце збереження, отримай одне погодження всього набору. Чітке прохання зберегти вже наданий користувачем готовий контент із відомою ціллю є дозволом. Не проси підтвердження кожного технічного пакета.

Кожне запитання має `type`, `content`, `points` (ціле 1–32767, типово 1) і поля свого типу:

| type | Поля й оцінювання |
| --- | --- |
| `default` | `answers`: 2–20 `{content, correct}`; щонайменше одна правильна. `selectionMode: "one"` — вибір одного правильного варіанта; `"all"` — вибрати всі правильні й жодного неправильного. |
| `match` | `pairs`: 2–20 `{left, right}`. Сервер створює UUID і зв'язки. Зараховуються всі правильно зіставлені пари; часткове оцінювання не підтримується. |
| `inputAuto` | `correctAnswer`: один непорожній рядок до 2000 символів. Платформа порівнює точний текст після обрізання крайніх пробілів і без урахування регістру; це не семантична перевірка. |
| `inputManual` | Додаткові поля не потрібні; оцінює викладач. |

`true_false` відсутній. Не підмінюй тип і не вигадуй непідтримувані поля.

До 50 запитань і до 512 KiB на пакет, включно з перетвореним контентом. Для 200 запитань — щонайменше 4 пакети; довгий контент потребує менших пакетів. Один пакет зберігається цілком або не зберігається. Уже успішні попередні пакети залишаються.

Зберігай `requestId`, `executionId` і результати пакетів у контексті. Повтор однакового `requestId` з тим самим вмістом повертає попереднє виконання; змінений вміст з цим ID дає конфлікт. За `QUEUED`/`RUNNING` використовуй `get_execution`. За невідомого результату не створюй новий ID, щоб «повторити»: це може створити дублікати. При помилці зупини наступні пакети й назви фактично створену кількість. За успіху відповідь містить `createdCount`, UUID/preview/type у початковому порядку.

## Імпорт із документа або готового матеріалу

Коли користувач просить перенести готові запитання з Word, іншого доступного документа чи повідомлення, спочатку перевір матеріал до виклику `create_questions`. Читання вкладення у чаті не означає завантаження файла до WeStudy. Якщо файл, частина тексту, таблиця або потрібне зображення недоступні для читання, явно назви цю межу; не вигадуй прочитаний зміст або загальну кількість запитань і не звітуй про повний імпорт.

Зістав кожне запитання з підтримуваним типом за змістом, способом відповіді та оцінюванням. Зберігай його номер із документа; якщо номера немає, використовуй коротку цитату або власну позначку, явно зазначивши, що її додано для узгодження. Зберігай відповідність цих позначок позиціям у пакетах і повернутим UUID. Заголовки, пояснення та спільна умова самі по собі не є окремими запитаннями: збережи потрібний контекст відповідних запитань.

- **Однозначно підтримується:** перенеси зміст і правильні відповіді без зміни логіки завдання. Звичайне нормалізування оформлення не вимагає окремого погодження. Чітке прохання додати надані готові запитання у визначений банк уже дозволяє цей запис.
- **Неоднозначне або неповне:** до запису назви конкретне запитання та що саме незрозуміло або відсутнє. Наприклад, не зазначено правильний варіант, незрозуміло, скільки відповідей треба вибрати, чи умова посилається на відсутній рисунок. Для перенесення готового матеріалу не домислюй правильні відповіді, умову, пари чи бали всупереч джерелу. Об'єднай уточнення в одне зрозуміле повідомлення.
- **Не підтримується або не схоже на тестове запитання:** прямо повідом про це, наведи номер/цитату і причину. Не перетворюй будь-який фрагмент автоматично на `inputManual` лише тому, що цей тип приймає довільний текст. Якщо є осмислена адаптація, запропонуй підтримуваний тип, покажи нове формулювання та поясни, як зміняться спосіб відповіді або оцінювання. Виконуй таку адаптацію лише після погодження; не видавай її за точне перенесення оригіналу.

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

Прохання **створити нові запитання на основі матеріалу** відрізняється від перенесення готових: у такому разі можна сформувати нові умови й відповіді, після чого показати та погодити згенерований набір за правилами створення вище. Не приписуй згенеровані запитання або відповіді оригінальному документу.

Після виконання обов'язково повідом фактично додану кількість і цільовий банк. Окремо переліч погоджені адаптації та всі недодані запитання з номерами/цитатами і причинами: пропущено за згодою, бракує даних, непідтримуваний тип чи помилка виконання. Адаптовані й успішно збережені запитання входять до загальної кількості доданих, не рахуй їх вдруге. Кількість доданих підтверджуй тільки успішними результатами сервера, а не числом підготовлених елементів. `QUEUED`, `RUNNING` та `UNKNOWN` позначай як непідтверджений результат; не називай їх успішними або точно недоданими. Якщо помилка відхилила цілий пакет, повідом про цей пакет і вже успішні попередні пакети; не кажи, що сервер пропустив лише один проблемний елемент.

## Контент і редагування

`content`, `left`, `right` — масив блоків:

- `{type: "html", html: "<p>Текст із <strong>виділенням</strong>.</p>"}`. Дозволено p, h1–h6, ul/ol/li, strong/em/u/br. Усі атрибути й небезпечні елементи прибираються сервером.
- `{type: "image", url: "https://…", alt: "…"}` — готове публічне зображення у сховищі підключеної школи.
- Лише для умови: `{type: "video", url: "https://…"}` або `{type: "video", fileUuid: "…"}`; необов'язкові posterUrl і lang. UUID має належати відеофайлу цієї школи. Відповіді підтримують лише текст і зображення.

Нові фото спочатку імпортуй за [правилами файлів](files.md) й дочекайся `READY`; використовуй повернуту адресу сховища. Наявні фото цієї школи повторно використовуй без копіювання. Не вигадуй адреси чи UUID і не вставляй img/video/iframe у HTML.

Перед `update_question` прочитай `get_question`. Передай `questionUuid`, незмінний `type`, повернуті `lang` та `expectedRevision: revision`. Потрібне лише одне запитання; масового редагування немає.

Переданий `content` цілком замінює відповідний контент. Сформуй новий повний масив і включи наявні фото/відео, якщо користувач не просив їх прибрати. Звичайне форматування може нормалізуватися. Стару версію редактора та складні непідтримувані блоки не адаптуй: поясни, що такий контент потрібно редагувати на платформі. Після помилки читання не записуй частково прочитаний вміст.

Для `default` поле `answers` містить явні зміни: `{uuid, content?, correct?}` для наявної відповіді; `{content, correct}` без UUID додає нову. Видалення — лише `removeAnswerUuids`. Для `match`: `pairs: [{leftUuid, left?, right?}]`; нова пара — `{left, right}`; видалення — `removePairUuids` із UUID лівих сторін. Відсутність відповіді в масиві змін нічого не видаляє. Не замінюй наявні UUID новими.

За `usedByStudents: true` можна редагувати формулювання, але не склад відповідей, правильність чи бали. Для зміни оцінювання запропонуй нове запитання. При конфлікті `revision` перечитай запитання та узгодь зміни; не підставляй нову версію механічно поверх чужої правки. Якщо запит користувача вже однозначно задає об'єкт і зміну — повторне погодження не потрібне; якщо треба вибрати запитання або є неоднозначність, спершу уточни.