# Правила определения путей файлов

Текущая happy-path реализация строит путь документа по фиксированному шаблону:

`docs/<domain>/<platform>/<doc_type>/<doc_id>.md`

Пример:

`docs/orders/pprb/ui_page/orders.ui.list.md`

## Источники атрибутов

Для построения пути используются четыре основных атрибута:

- `domain`
- `application`
- `platform`
- `doc_type`
- `id` как `doc_id`

Если атрибуты явно указаны в подразделе `6.x`, нужно использовать их.
Если атрибут не указан, он может быть взят из общих метаданных аналитики или определен fallback-логикой.

## Нормализация сегментов

Каждый сегмент пути нормализуется одинаково:

- значение переводится в lowercase;
- все символы, кроме `a-z`, `0-9`, `.`, `_`, `-`, заменяются на `-`;
- ведущие и хвостовые `.` и `-` удаляются.

Примеры нормализации:

- `Payment Status` -> `payment-status`
- `UFS Orders` -> `ufs-orders`
- `crm.mobile` -> `crm.mobile`

## Значения по умолчанию

Если после нормализации сегмент пустой, используются fallback-значения:

- корневая папка: `domain`, иначе `application`, иначе `common`
- `platform` -> `web`
- `doc_type` -> `misc`
- `doc_id` -> `untitled`

## Что важно в текущей версии

- для корневой папки сначала используется `domain`;
- если `domain` не задан, используется `application`;
- `sub_domain` сейчас не участвует в построении пути;
- операции `create`, `update`, `delete` работают с одним и тем же правилом вычисления пути;
- специальных исключений для разных типов документов пока нет;
- отдельные каталоги для `pprb`, `ufs`, `web` задаются только через значение `platform`.

## Практическое правило для агента

Если нужно предложить или определить путь новой страницы, агент должен:

1. определить `application`;
2. определить `domain`;
3. определить `platform`;
4. определить `doc_type`;
5. определить стабильный `doc_id`;
6. взять корневую папку как `domain`, а если он пустой, то `application`;
7. нормализовать все сегменты;
8. собрать путь по шаблону `docs/<root>/<platform>/<doc_type>/<doc_id>.md`.