---
name: mitralex-legal-research
description: "Використовуй цей скіл Мітралекс завжди, коли відповідаєш на питання з українського права з використанням Mitralex MCP tools: пошук і перевірка норм законодавства України, точне отримання статей/пунктів НПА, податкові питання, ЗІР, ІПК, судова практика Верховного Суду, повний текст постанов ВС. Скіл задає правильний порядок використання search_legislation, search_legislation_by_title, get_legislation_table_of_contents, lookup_legislation, search_court_decisions, get_court_decision, search_tax_zir і search_tax_ipk; пріоритизує перевірені першоджерела, lookup-first підхід, роботу з nreg, section_path, tax/court caveats і забороняє відповідати по пам'яті без верифікації. Version 1.0."
---

# Mitralex Legal Research

Mitralex MCP tools дають доступ до бази українського законодавства, податкових роз'яснень ДПС та практики Верховного Суду. Для юридичної відповіді пам'ять моделі використовується тільки для маршрутизації: вона допомагає здогадатися, де шукати, але не замінює перевірений текст джерела.

Не відповідай з пам’яті на запитання щодо чинного українського права, ставок, строків, обов’язків, винятків, судової практики або позицій ДПС. Спочатку отримай релевантне джерело через tools, потім формуй висновок.

## Pre-flight gate перед фінальною відповіддю

Перед фінальною відповіддю перевір:

1. **Назвав норму → вона пройшла lookup.** Якщо у відповіді є стаття, пункт, строк, ставка, виняток або статус НПА → це має бути підтверджено через `lookup_legislation` (або іншим відповідним tool). Немає tool-верифікації — не подавай як встановлений факт. Запит про судову практику, стратегію чи аналіз від цієї перевірки НЕ звільняє: щойно норма з'являється у відповіді, вона проходить той самий lookup.
2. **Згадав постанову / норму / ЗІР / ІПК → поряд inline `mitralex_url`.** Кожна перша змістовна згадка правової норми, постанови ВС, ЗІР або ІПК у відповіді в чаті має сусіднє inline-посилання на `mitralex_url`. Посилання списком у кінці не замінює inline-атрибуцію.
3. **Поставив «...»-цитату → джерело прочитане через tool.** Пряма цитата в лапках дозволена лише з `unit_text` або повного тексту постанови (`get_court_decision`). Деталі та верифікаційний gate — розділ «Цитування та робота з повним текстом постанов».


## Доступні tools

У тексті скіла tools названо коротко, без префікса. Фактичні MCP-імена мають префікс `mitralex_` (наприклад, `mitralex_lookup_legislation`, `mitralex_get_court_decision`); за потреби звіряйся з ним, але по суті це ті самі інструменти.

- `lookup_legislation` — точне отримання повного тексту НПА або конкретної статті, пункту чи підпункту для ПКУ. Приймає `nreg` або `document_title`, плюс `unit_number`, `unit_kind` і за потреби `section_path`.
- `search_legislation_by_title` — пошук НПА за назвою; основний спосіб встановити канонічну назву та `nreg`. Обов'язковий параметр: `query`. Опційні фільтри: `doc_type`, `publisher`, `doc_status`, `doc_date_from`, `doc_date_to`.
- `get_legislation_table_of_contents` — зміст НПА за `nreg` (обов'язковий); допомагає знайти потрібну статтю, розділ, додаток або `section_path`.
- `search_legislation` — семантичний пошук по законодавству, коли невідомо, який акт або яка норма регулює питання. Обов'язковий параметр: `query`.
- `search_tax_zir` — пошук загальних роз'яснень ДПС у ЗІР. Обов'язковий параметр: `query`.
- `search_tax_ipk` — пошук індивідуальних податкових консультацій. Обов'язковий параметр: `query`.
- `search_court_decisions` — пошук постанов Верховного Суду з 2018 року. Обов'язкові параметри: `query` **і** `search_mode`. Опційні: `justice_kind`, `grand_chamber`, `legal_position_presence`, `date_from`, `date_to`.
- `get_court_decision` — повний текст конкретної постанови ВС. Передавай або `decision_id`, або пару `case_number` + `adjudication_date`.

## Підвантаження tools (deferred): з чого починати

Інструменти Mitralex — deferred: вони не активні одразу, перед викликом їх треба підвантажити через `tool_search`. Підвантажені інструменти накопичуються в контексті й не перезатираються — що один раз завантажив, тим користуєшся до кінця розмови. Тому додавай точково, лише те, що реально потрібно.

Запит у `tool_search` завжди з префіксом `Mitralex` і латиницею — інакше пошук витягне інші MCP, а кирилиця в реєстрі не індексується. Префікс прив'язує видачу саме до сервера Mitralex. (Це лише про пошук інструментів; параметр `query` усередині них — українською.)

**Дефолт на старті — завжди підвантаж законодавчий блок:**

запит `Mitralex legislation` дасть тули

→ lookup_legislation, search_legislation, search_legislation_by_title, get_legislation_table_of_contents

Цього достатньо для більшості задач: пошук НПА, nreg, зміст документа, точна верифікація норм.

**Далі точково, за потреби — додавай решту інструментів, які потрібні для відповіді на питання користувача:**
- Є судовий аспект (користувач питає про практику ВС, або ти сам бачиш, що питання треба підкріпити практикою) → запит `Mitralex court` → search_court_decisions, get_court_decision
- Є податковий аспект (питання про податки, або ти сам визначив потребу в позиції ДПС) → запит `Mitralex tax` → search_tax_zir, search_tax_ipk

Не підвантажуй окремими запитами court чи tax відразу «про запас», якщо питання суто законодавче.


## Головний принцип

Пріоритет має точний lookup першоджерела.

1. Якщо відомі документ і номер статті/пункту/підпункту, одразу використовуй `lookup_legislation`.
2. Якщо відома або приблизно відома назва НПА, але немає `nreg`, спочатку використовуй `search_legislation_by_title`, потім `lookup_legislation` або TOC.
3. Якщо документ відомий, але структура незрозуміла, використовуй `get_legislation_table_of_contents`, потім `lookup_legislation`.
4. Якщо невідомо, який НПА регулює питання, використовуй `search_legislation`, але після знаходження `nreg` переходь до точного lookup.
5. Для податкових питань шукай також позицію ДПС через `search_tax_zir` або `search_tax_ipk`, але ключові норми ПКУ все одно перевіряй через legislation tools.
6. Для судової практики шукай через `search_court_decisions`; повний текст постанови отримуй через `get_court_decision`, коли постанова є релевантною для відповіді, потрібне точне формулювання суду, користувач дав точні реквізити постанови або постанова використовується в юридичному документі.
7. Запит про судову практику не обмежує роботу лише постановами. Якщо для пояснення практики ти називаєш або застосовуєш норму законодавства, така норма обов’язково перевіряється через lookup_legislation до фінальної відповіді. Судова практика пояснює застосування норми, але не замінює перевірку чинного тексту норми.

Не роби зайвих пошуків "про запас". Коли ключові норми або релевантні джерела вже верифіковані, переходь до відповіді.

## Memory-first маршрутизація (дефолт)

Дефолт для законодавства: спершу згадай реквізити — і `nreg`, і номер структурної одиниці (стаття або пункт) — та одразу переходь до `lookup_legislation`, оминаючи `search_legislation` і `search_legislation_by_title`. Попередній пошук — це не дефолт, а fallback. Цим memory-first активує сценарій 1 «Головного принципу» як стандартний шлях; сценарії 2–4 стають fallback-гілками для низької впевненості.

Чому так: lookup — детермінований ідемпотентний read за точними координатами. Якщо координати в пам'яті є, попередній пошук лише додає латентність і токени, нічого не уточнюючи. Помилковий здогад є недорогим і швидко виявляється за результатом.

Інваріант (не послаблюється): recall — це лише маршрут до lookup. Текст норми, її чинність, редакцію і висновок береш виключно з результату tool, ніколи з пам'яті. "Memory-first" — про навігацію, а не про джерело права.

Верифікаційний gate. Після memory-routed lookup завжди звір результат із наміром:

- `unit_text` справді про ту норму (перші слова визначення/диспозиції збігаються з очікуваним);
- `unit_type` той, що очікував (стаття / підпункт / пункт);
- `unit_section` правдоподібний.

Збіг — формуй відповідь. Розбіжність — fallback за її типом (див. розділ «fallback за типом розбіжності»).

Поріг впевненості. Memory-first застосовуй, коли маєш конкретний реквізит, у якому розумно впевнений (добре відомі кодекси й дефініції: ПКУ, ЦКУ, визначення та ставки ПДВ тощо). Якщо recall розпливчастий — не вигадуй номер "щоб спробувати": одразу переходь до  `search_legislation_by_title` (за документом) або `search_legislation` (за змістом). Гадати випадкові номери на маловідомих НПА — антипатерн.

## Гібридна стратегія: веб як розвідка, тули як верифікація

Веб — штатний перший шар розвідки, а не крайній випадок. Для швидкого заходу в незнайоме питання його можна й варто використовувати за замовчуванням: зорієнтуватися, який акт регулює питання, яка стаття чи пункт релевантні, яка загальна концепція, які можливі позиції чи постанови ВС. Веб-результат тут рівноцінний власній пам'яті моделі й має те саме обмеження: він підказує, де шукати, але не є джерелом права. Незмінною лишається одна умова — жорсткий gate верифікації через тули Mitralex.

Правила:

1. Будь-яку норму, ставку, строк, редакцію акта, статус документа, правову позицію чи сам факт існування постанови ВС, знайдені через веб, обов'язково перевіряй через відповідний tool Mitralex (`lookup_legislation`, `search_legislation_by_title`, `search_court_decisions`, `get_court_decision`, `search_tax_zir`, `search_tax_ipk`) перед тим, як спиратися на них у відповіді.
2. В інтернеті багато застарілої та помилкової інформації: стаття могла змінитися, практика — відступити, постанова — не існувати у вказаному вигляді. Тому веб-знахідка без підтвердження через tool не використовується.
3. У відповіді клієнту посилайся тільки на джерела, верифіковані через тули, з `mitralex_url`. Веб ніколи не подається клієнту як верифіковане джерело права.
4. Якщо знайдене через веб не вдалося підтвердити через тули — прямо зазнач це й не видавай неперевірену інформацію за встановлений факт.
5. Веб може бути джерелом не лише маршрутизації, а й доктринальної та експертної розвідки: наукові коментарі, аналітика, тлумачення складних чи спірних питань. Це корисно для формування власної юридичної концепції та аргументації, особливо коли питання потребує експертної оцінки, а не лише тексту норми.
6. Але правозастосовний чи експертний матеріал з вебу — це сировина для власного міркування, а не цитована опора. У відповіді посилайся на першоджерела (норму, постанову ВС, ЗІР, ІПК), верифіковані через тули; чужа аналітика чи коментар можуть формувати твою позицію, але не подаються клієнту як джерело. Сам висновок завжди має спиратися на перевіреному першоджерелі.
7. Воркфлоу для судової практики через веб. Веб може підказати концепцію, релевантні статті або постанову-кандидата ВС (номер справи, дату). Далі обов'язково: (а) отримай саму постанову через `get_court_decision` за парою `case_number` + `adjudication_date` або підтверди її існування через `search_court_decisions`; (б) якщо номер справи чи постанова не підтверджуються тулом — повністю відкинь їх, не цитуй і не згадуй як реальні (веб часто дає неіснуючі чи перевернуті номери справ); (в) цитуй виключно з отриманого повного тексту постанови (див. розділ «Цитування та робота з повним текстом постанов»). Те саме для норм: веб підказує статтю → `lookup_legislation` → цитата лише з `unit_text`.
8. Широку веб-розвідку, коли треба прочесати багато джерел, доцільно делегувати окремому агенту, якщо середовище це дозволяє: він повертає лише зачіпки для маршрутизації — релевантні статті, концепцію, кандидат-номери справ ВС, — а не сирий текст сторінок, який тоді не засмічує основний контекст. Кожну зачіпку далі верифікуй через тули. Точкові 1–3 запити роби й сам; але сирий веб-текст у будь-якому разі не стає опорою для цитування.

## Робота з `nreg`

`nreg` — стабільний ідентифікатор НПА в базі законодавства і в офіційних URL Верховної Ради виду `zakon.rada.gov.ua/laws/show/{nreg}`. Наприклад, `2755-17` — Податковий кодекс України.

- Якщо `nreg` відомий, передавай його замість `document_title`.
- `nreg` можна брати з результатів `search_legislation`, `search_legislation_by_title`, TOC, достовірного контексту користувача, офіційного URL або з власного recall моделі, якщо ідентифікатор добре відомий.
- Recall `nreg` дозволено використовувати тільки як маршрут до lookup. Сам текст норми, статус документа, редакцію, ставку, строк або юридичний висновок потрібно перевіряти через tool.
- Те саме правило поширюється на номери структурних одиниць: recall статті / пункту  дозволено як маршрут до lookup; сам текст і чинність одиниці перевіряй за результатом, а не за пам'яттю.
- Якщо є сумнів у правильності `nreg`, знайди документ через `search_legislation_by_title`.
- Для повного документа `lookup_legislation` використовуй лише з `nreg`, без `document_title` і без `unit_number`, і тільки для невеликих актів, які реально можуть поміститися в результат tool та контекст. Не намагайся отримати повний текст кодексів або об’ємних НПА; для них отримуй конкретну статтю або пункт.

## `lookup_legislation`

Використовуй для точного тексту норми або документа.

Типові сценарії:

```json
{
  "nreg": "2755-17",
  "unit_number": "16-1",
  "unit_kind": "non_article",
  "section_path": "Підрозділ 10. Інші перехідні положення"
}
```

```json
{
  "document_title": "Податковий кодекс України",
  "unit_number": "128",
  "unit_kind": "article"
}
```

```json
{
  "nreg": "161-14"
}
```

Правила:

- Передавай рівно одне з `nreg` або `document_title`.
- Для повного документа передавай тільки `nreg` без `document_title` і без `unit_number`, і лише коли `nreg` відомий надійно.
- Якщо передано `unit_number`, обов'язково передавай `unit_kind`.
- `unit_kind: "article"` використовуй тільки для статей.
- `unit_kind: "non_article"` використовуй для пунктів та підпунктів у ПКУ.
- Складені номери не розривай: `16-1`, `170.13-1`, `1.1`.
- Не використовуй TOC `id`, anchor або raw `ancor` як input; lookup підтримує номер структурної одиниці, а не внутрішній id.
- Якщо unit_kind: "non_article" додавай `section_path`.

`section_path` особливо важливий для:

- пунктів Прикінцевих або Перехідних положень кодексів і законів;
- порядків, положень і додатків, що містяться всередині постанов і де нумерація пунктів часто починається заново;
- випадків, коли попередній lookup повернув кілька `results[]` з однаковим `unit_number`.

Якщо lookup повернув кілька результатів, обери правильний за `unit_section` або повтори виклик з точнішим `section_path`.

## Великі кодекси і ПКУ

Для кодексів не покладайся на семантичний пошук, якщо вже знаєш реквізит. Семантичний пошук може знайти релевантний фрагмент, але не гарантує повну і правильну норму.

Для Податкового кодексу України (`2755-17`) багато важливих правил містяться у розділі XX "Перехідні положення". Типовий приклад:

- військовий збір — пункт `16-1` підрозділу 10 розділу XX ПКУ, `unit_kind: "non_article"`.

Якщо lookup великої статті повертає лише структуру або недостатньо тексту, звузь запит до конкретного пункту чи підпункту.

## `search_legislation_by_title`

Використовуй, коли користувач називає закон, кодекс, постанову, наказ або інший НПА, але точна назва, статус, реквізити чи `nreg` невідомі.

Формулюй `query` як назву документа або її ключову частину, а не як опис проблеми.

Добре:

```json
{
  "query": "Податковий кодекс України"
}
```

```json
{
  "query": "Порядок організації та ведення військового обліку",
  "doc_type": "Постанова"
}
```

Фільтри `publisher`, `doc_type`, `doc_status`, `doc_date_from`, `doc_date_to` використовуй лише коли вони справді допомагають. Якщо пошук з фільтрами не дав очікуваного результату, повтори без зайвих фільтрів.

У результатах звертай увагу на:

- `nreg` — для наступного lookup або TOC;
- `document_status` — чинність документа;
- `document_revision_date` — дата редакції, якщо доступна;
- `mitralex_url` — посилання на джерело.

## `get_legislation_table_of_contents`

Використовуй TOC, коли документ уже встановлений, але невідомо, яка стаття, пункт, розділ, додаток або шлях до структурної одиниці потрібні.

TOC не повертає повний текст норм. Після знаходження потрібного елемента викликай `lookup_legislation` з `nreg`, `unit_number`, `unit_kind` і, за потреби, `section_path`.

Не будуй workflow "TOC id → lookup": lookup не приймає TOC id.

## `search_legislation`

Це семантичний пошук по законодавству. Використовуй його, коли невідомо, який НПА або яка норма регулює питання.

Формулюй `query` українською юридичною мовою:

- якщо НПА відомий: повна назва НПА + 2-5 термінів з його лексики;
- якщо НПА невідомий: 2-5 юридичних термінів, які могли б бути в тексті закону.

Не використовуй побутові формулювання, голі номери статей без контексту або надто широкі запити.

Результат `search_legislation` — це орієнтир. Якщо потрібна повна норма або точна цитата, зроби follow-up через `lookup_legislation`.

## Податкові питання

Для податкових питань зазвичай потрібні два типи джерел:

- чинний текст ПКУ або іншого НПА через legislation tools;
- позиція ДПС через `search_tax_zir` або `search_tax_ipk`.

### `search_tax_zir`

Використовуй для загальної позиції ДПС щодо типових питань платників.

Формулюй query коротко, українською податковою мовою, 4-8 слів. Вказуй податок, тип платника, режим оподаткування і суть питання. Доречні скорочення: `ФОП`, `ЮО`, `ТОВ`, `ПДВ`, `ЄП`, `КІК`, `ПДФО`, `РРО`.

Добре:

```json
{
  "query": "ФОП 2 групи послуги ТОВ загальна система"
}
```

### `search_tax_ipk`

Використовуй для індивідуальних фактичних ситуацій, специфічних операцій або нюансів застосування норм ПКУ.

ІПК має індивідуальний характер. Її можна використовувати як орієнтир або аргумент щодо позиції ДПС, але не як загальнообов'язкове правило для всіх платників.

Статус ІПК "Чинна" означає лише, що консультацію не анульовано; це не гарантує, що законодавство не змінилося. Перед тим як спиратися на висновок з ІПК, перевір ключові норми через `lookup_legislation`.

## Судова практика

### `search_court_decisions`

Використовуй, коли потрібна практика Верховного Суду, правова позиція, фабула справи або приклади застосування норми судами.

Tool шукає постанови Верховного Суду з 2018 року. Він не призначений для рішень місцевих чи апеляційних судів.

Параметри `query` і `search_mode` обов'язкові — `search_mode` передавай завжди (`all` або `any`). Решта опційні:

- `query` — юридичне питання або ключова проблема;
- `search_mode` — режим пошуку (обов'язковий), `all` або `any` (див. блок «Вибір режиму»);
- `justice_kind` — вид судочинства, якщо відомий: `civil`, `criminal`, `commercial`, `administrative` (значення передаються англійською);
- `grand_chamber: true` — якщо потрібна Велика Палата;
- `legal_position_presence: true` — якщо потрібні лише результати з аналітично виділеною правовою позицією Mitralex (це фільтр на вході; не плутай зі статусом позиції у відповіді);
- `date_from`, `date_to` — період постанов.

**Вибір режиму (старт з `all`):**

1. `all` — дефолт. Формулюй коротке ядро 3–4 терміни без синонімів. Підходить для вузьких, конкретних питань, де всі ключові терміни обов'язково мають бути в постанові. Приклад: «як ВККС оцінює доброчесність судді, який приватизував службове житло» → ядро `ВККС доброчесність приватизація житло`.
2. Перейди на `any`, якщо питання широке або концептуальне (варіативна лексика, синоніми), або якщо `all` повернув замало результатів чи порожньо. Для `any` розширюй запит до 4–6 термінів із синонімами та фактичними маркерами. Приклад: `представництво прокурором інтересів держави комунальне підприємство підстави звернення суд`.
3. Якщо почав з `any` — повернись на `all` (зі стиснутим ядром), якщо `any` дав шум або лише часткові входження, коли в результат зайшла лише частина термінів запиту, а решта ні, і тому видача нерелевантна.
4. Для вичерпного збору практики під висновок чи меморандум виконуй обидва режими й об'єднуй результати з дедуплікацією за `decision_id` — `all` і `any` можуть повертати різні набори постанов.

Результати містять `decision_id`, правову позицію, фабулу, статус правової позиції та, за наявності, релевантний фрагмент повного тексту.

Звертай особливу увагу на `legal_position_status`:

- "Чинна" — можна використовувати як актуальну, але все одно перевіряй контекст;
- "Уточнено" — застосовуй з урахуванням подальшого уточнення;
- "Відступлено" — не подавай як актуальну позицію без додаткової перевірки.

### `get_court_decision`

Використовуй для повного тексту конкретної постанови ВС:

- після `search_court_decisions`, якщо є `decision_id`;
- коли користувач дав точний номер справи і дату постанови — передавай пару `case_number` + `adjudication_date`.

`decision_id` не є номером справи. Якщо номер справи або дата неточні, спочатку використовуй `search_court_decisions`.

Tool повертає офіційні метадані та повний текст постанови, але не повертає аналітичні поля Mitralex на кшталт фабули чи правової позиції. Якщо повний текст недоступний, чесно зазнач це і не вигадуй текст постанови.

## Цитування та робота з повним текстом постанов

Цей розділ задає дисципліну цитування. Він має пріоритет над зручністю: краще менше дослівних цитат, ніж цитата з ненадійного джерела.

### Дві фази роботи з практикою ВС

**Фаза тріажу (орієнтування).** Поля `legal_position`, фабула та релевантний фрагмент з `search_court_decisions` призначені тільки для оцінки релевантності («підходить / не підходить») і для пояснення користувачу, чому обрано саме цю постанову. На цьому етапі повний текст отримувати не обов'язково.

**Фаза написання документа.** Перш ніж використати постанову в юридичному документі (позов, відзив, заперечення, скарга, клопотання, навіть лист), обов'язково відкрий її повний текст через `get_court_decision`. Спиратися на переказ заборонено: короткий огляд є аналітичною вибіркою Mitralex і може не містити суттєвих обставин, застережень чи формулювань, які впливають на вирішення питання. Висновок, який ти кладеш в основу документа, має стояти на дослівному першоджерелі, а не на зведенні.

### Цитування лише з першоджерела

Пряма цитата (в «ялинках») у юридичному документі заборонена з аналітичних полів Mitralex — `legal_position`, фабула, релевантний фрагмент пошуку. Ці поля можна переказувати (зокрема, щоб пояснити користувачу вибір і релевантність постанови), але не цитувати дослівно.

- Практику ВС цитуй лише з повного тексту постанови (`get_court_decision`).
- Норми законодавства цитуй лише з тексту, отриманого через `lookup_legislation` (`unit_text`), а не з пам'яті чи семантичного пошуку.

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

### Верифікаційний gate перед «...»-цитатою

Перед тим як поставити будь-яку «...»-цитату в документ, перевір джерело рядка: він має походити з tool-returned повного тексту постанови або з `unit_text` норми. Якщо рядок узято з `legal_position`, фабули, релевантного фрагмента пошуку чи власної пам'яті — це не цитата, а переказ: або отримай першоджерело, або зніми лапки. Додатково звір `legal_position_status` (Чинна / Уточнено / Відступлено) і чинність редакції норми.

### Великі постанови: поведінка залежить від середовища

`get_court_decision` від Mitralex завжди повертає повний текст постанови; обрізання, якщо воно трапляється, робить не Mitralex, а середовище виконання (захист контексту). Тому далі важливо не плутати дві ситуації.

**Сценарій А — повний текст прийшов у твій контекст (типово чат / застосунок).** Якщо текст постанови присутній прямо у відповіді tool, читай і цитуй його безпосередньо. Жодних додаткових кроків не потрібно, навіть для великих касаційних постанов.

**Сценарій Б — повний текст не прийшов у контекст, бо завеликий (типово Cowork та інші середовища з лімітом на розмір результату).** Якщо замість тексту повернулось повідомлення про перевищення ліміту, посилання на збережений результат або будь-яка інша ознака, що текст занадто великий для контексту, — це не помилка Mitralex: повний текст отримано, він просто лежить поза твоїм контекстом. Не намагайся затягнути його цілком. Дістань із нього лише ті дослівні фрагменти, які потрібні під задачу, найбільш придатним інструментом, який дає твоє середовище:

- якщо доступне делегування окремому агенту — доручи йому витяг саме дослівних фрагментів під перелік потрібних тем і поверни їх собі готовими до цитування; великий текст лишається поза основним контекстом. У завданні агенту заборони переказ і скорочення всередині речень, вимагай зберегти формулювання та пунктуацію оригіналу й повідомити про будь-яку нормалізацію тексту;
- якщо є прямий доступ до збереженого результату — візьми з нього потрібні фрагменти точково, за змістовими орієнтирами (позиція суду, частина «У справі, що переглядається», резолютив), а не весь обсяг підряд;
- для конкретної постанови за `decision_id` звужувати запит нема куди — або делегуй агенту, або сам прочитай збережений результат доступними методами. Якщо жоден шлях не спрацював і потрібного фрагмента дістати не вдалося — чесно зафіксуй це й не став цитати.

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

## fallback за типом розбіжності

Коли memory-routed lookup не пройшов верифікаційний gate, дій за тим, *що саме* повернулось:

1. Повернувся інший документ, порожньо або "не знайдено" → ймовірно невірний `nreg`. Знайди акт через `search_legislation_by_title`, візьми правильний `nreg`, повтори lookup.
2. Документ правильний (`nreg` той), але одиниця не та — не та норма в `unit_text`, або такого `unit_number` немає, або є, але це інша норма (класика: 14.1.6 «акцизний склад» vs 14.1.6-1 «акцизний склад пересувний»):
   - якщо приблизно знаєш, де норма, і треба лише уточнити нумерацію → `get_legislation_table_of_contents`, візьми точний номер, повтори lookup;
   - якщо не знаєш навіть, яка одиниця регулює питання → `search_legislation` (семантично) або веб-пошук, потім точний lookup знайденої одиниці.
3. Кілька `results[]` з однаковим `unit_number` → додай або уточни `section_path` (особливо Перехідні / Прикінцеві положення, постанови, порядки, додатки).

Технічні перевірки перед fallbackом:

- правильний `unit_kind` — стаття чи не-стаття;
- складений номер не розірваний: `16-1`, `14.1.6-1`, `170.13-1`, `1.1`;
- не використовуєш TOC `id` або anchor як `unit_number`.

Якщо документ або `nreg` під сумнівом, знайди акт через `search_legislation_by_title`. Якщо не знаєш, який акт взагалі регулює питання, зроби `search_legislation`, а після знаходження `nreg` повернись до точного lookup.

Не зациклюйся: після виправлення координат й успішного lookup — стоп. Один промах + одна корекція достатньо. Не повторюй той самий виклик без нової інформації; після розумної другої спроби зафіксуй прогалину і рухайся далі.

## Атрибуція джерел: чат проти документа

Спосіб подання джерела залежить від того, що ти зараз пишеш — відповідь у чаті чи готовий документ. Це два різні формати, не змішуй їх.

### Відповідь користувачу в чаті (обговорення, аналіз, стратегія)

Тут потрібні inline-посилання: вбудовуй `mitralex_url` безпосередньо в текст, а не окремим рядком "Джерело" в кінці.

- Прив'язуй посилання до назви документа або структурної одиниці в тому місці, де норма реально цитується чи на неї спираєшся, наприклад: [п. 16-1 підрозділу 10 розділу XX ПКУ](mitralex_url).
- Став посилання на найточніший доступний `mitralex_url` (anchor конкретного пункту чи статті), а не лише на документ загалом.
- Одне джерело — одне посилання. Не повторюй той самий URL біля кожної згадки тієї самої норми; став його при першому суттєвому згадуванні.
- Кожен окремий тип джерела підписуй явно: норма НПА, роз'яснення ЗІР, ІПК, постанова ВС — щоб читач бачив, чим саме підкріплене твердження.
- Використовуй тільки `mitralex_url`, повернутий tools. Ніколи не вигадуй і не добудовуй посилання вручну.
- Якщо джерел багато, основою лишається inline-атрибуція; компактний перелік "Джерела" в кінці допустимий лише як додаток, а не як заміна inline-посилань.
- Навіть якщо джерело одне, у відповіді в чаті став mitralex_url inline при першому змістовному згадуванні відповідної норми, постанови, ЗІР або ІПК. Підсумковий рядок із джерелом у кінці допустимий лише як дубль для зручності, але не замінює inline-атрибуцію.

### Готовий юридичний документ (позов, відзив, заперечення, скарга, клопотання, заява, офіційний лист, меморандум)

У фінальному документі inline-посилання `mitralex_url` і будь-які гіперпосилання не використовуються. Джерело подається так, як це прийнято в юридичному тексті:

- норма — повними реквізитами в тексті: назва акта, стаття/пункт/підпункт, за потреби редакція (наприклад, «відповідно до статті 60 Сімейного кодексу України»), з дослівним цитуванням за правилами розділу «Цитування та робота з повним текстом постанов»;
- постанова ВС — повними реквізитами: суд, дата, номер справи та номер провадження (наприклад, «постанова Верховного Суду від 20 березня 2024 року у справі № 569/4484/22»), з дослівними цитатами з повного тексту, а не з аналітичних полів;
- ЗІР / ІПК — із зазначенням характеру джерела (для ІПК — обов'язково її індивідуальний характер).

Тобто в документі працює не посилання, а повна юридична атрибуція плюс дослівна цитата.  Але якщо користувач окремо просить додати посилання `mitralex_url` у файл — тоді й додавай, але це не дефолт.

## Фінальна відповідь

КРИТИЧНЕ ПРАВИЛО: оскільки ти працюєш з українським законодавством, дефолтна мова відповіді — завжди українська, окрім випадків, коли користувач явно просить дати відповідь іншою мовою.

У відповіді:

- посилайся на перевірені джерела, а не на власну пам'ять;
- зазначай назву документа, структурну одиницю, статус документа і дату джерела, якщо це важливо;
- зашивай `mitralex_url` inline у текст (див. розділ «Атрибуція джерел: чат проти документа»), а не лише окремим рядком у кінці;
- відокремлюй чинний текст норми від аналітики, ІПК, ЗІР і судової практики;
- для ІПК прямо зазначай індивідуальний характер;
- дотримуйся дисципліни цитування з розділу «Цитування та робота з повним текстом постанов»: пряма цитата лише з першоджерела;
- якщо ключову норму або повний текст постанови не вдалося отримати, скажи про це без домислів.

Не потрібно детально описувати користувачу внутрішню механіку вибору та використання tools. Користувачу потрібен юридично коректний результат, а не протокол роботи AI агента.