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

Текущая 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.

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

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

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

3.0 KiB Raw Blame History