RFC 0001: объявляемое обнаружение, структурированные идентификаторы и ориентировочная цена в SKU.md

SKU.md 1.0.0-beta намеренно небольшой: корневой каталог по адресу /sku.md, необязательные документы со знаниями о товарах и ссылка Source у каждого факта. Благодаря этому его легко проверять, но остаются три пробела, важные для независимых магазинов в покупках через диалог с AI. RFC 0001 — черновик предложения, который их закрывает.

RFC не входит в действующую спецификацию. Его пока не реализует ни один валидатор, генератор, CLI, инструмент MCP или Agent Skill, и в случае принятия все документы 1.0.0-beta останутся действительными. Полный текст — в RFC 0001.

Пробел первый: магазины на платформах не могут использовать корневой путь

Спецификация требует, чтобы путь каталога был ровно /sku.md. В руководстве проекта по Shopify зафиксировано, что платформа управляет корнем магазина и ограничивает префиксы App Proxy. Хостинг через файловую библиотеку на других платформах обычно опирается на перенаправление, которое меняет итоговый путь. Такие продавцы часто могут отдавать тот же Markdown по другому пути того же источника, но сейчас это не соответствует спецификации.

RFC оставляет /sku.md первым местом, куда смотрит читатель. Если файла там нет, магазин может объявить другой URL каталога того же источника с помощью одной из пяти подсказок, которые проверяются в фиксированном порядке:

1. Зарезервированный путь /.well-known/sku.md; сначала его нужно зарегистрировать в IANA.
2. HTTP-заголовок Link в ответе главной страницы с rel="alternate", type="text/markdown" и title="SKU.md".
3. HTML-элемент link на главной странице с тем же отношением.
4. Ссылка с текстом SKU.md catalog в разделе Product knowledge файла llms.txt.
5. Строка в agents.md, начинающаяся с SKU.md catalog:.

Последние две совпадают со ссылками, которые уже сейчас рекомендует руководство по ссылкам для обнаружения, так что магазин, добавивший их сегодня, заранее получит и объявление.

Каждая подсказка должна оставаться в пределах того же источника, а объявленный файл проверяется так же, как корневой каталог. Две противоречащие подсказки считаются конфликтом. RFC также просит читателей предпочитать подсказки, требующие контроля над главной страницей, подсказкам в файлах, которые платформа может перегенерировать: более свободное правило пути повышает риск объявить каталогом содержимое, которое продавец не контролирует.

Пробел второй: идентификаторы записаны свободным текстом

По GTIN, MPN, бренду и SKU продавца торговые системы решают, относятся ли два упоминания к одному товару. В 1.0.0-beta их можно указать в разделе Identifiers, но только свободным текстом. RFC добавляет структурированную форму, которую парсер читает без догадок:

## Identifiers
- GTIN: 00012345678905 [Source](https://www.example-outdoor.com/products/tent)
- MPN: UL2P-24 [Source](https://www.example-outdoor.com/products/tent)
- Brand: Example Outdoor Gear [Source](https://www.example-outdoor.com/pages/about)
- SKU: TENT-UL2P-GRN [Source](https://www.example-outdoor.com/products/tent)

Метки GTIN, MPN, Brand, SKU и ISBN зарезервированы. GTIN должен проходить проверку контрольной цифры GS1, а пункт, который начинается с зарезервированной метки, но нарушает правило, признаётся недействительным и не превращается молча в обычный текст. Если идентификаторы различаются по вариантам, после значения можно добавить for и название варианта. Когда структурированный GTIN расходится с Product JSON-LD или фидом, читатель должен сообщить о конфликте и направить покупателя на актуальную страницу, а не выбирать одно из значений.

Пробел третий: для цены нет места вовсе

В диалоговых покупках цена часто становится первым фильтром. 1.0.0-beta не допускает актуальную цену в статичных файлах, и RFC сохраняет это правило. Оно добавляет необязательный раздел Reference price с датой и источником:

## Reference price
- USD 349.00 as of 2026-08-11 [Source](https://www.example-outdoor.com/products/tent)
- USD 299.00 to 349.00 as of 2026-08-11 for all variants [Source](https://www.example-outdoor.com/products/tent)

Валюта задаётся кодом ISO 4217, сумма пишется с точкой и без разделителя тысяч, а дата as of не может быть позже даты Updated документа. В разделе нельзя указывать цены со скидкой, купоны, цены для участников программ, доставку, налоги или остатки. Читатель, использующий значение, обязан подавать его как датированный ориентир, не должен применять его для корзины или оформления заказа и должен считать дату старше 90 дней устаревшей.

Это самая спорная часть черновика. Логика такая: ассистент, фильтрующий по бюджету, пропустит товар без каких-либо сведений о цене, а понятный датированный ориентир с источником отправит покупателя на актуальную страницу за подтверждением.

Что RFC оставляет в стороне

Несколько идей из того же обзора отложены до следующих предложений: корневой раздел Markets для регионов продаж, языков и валют; необязательные разделы Brand и Categories в корневом каталоге; вынос ограничения графа в 31 документ из спецификации; мягкий профиль разбора для читателей; рекомендации о том, как Markdown-ресурсы соотносятся с Sitemap и каноническими страницами. RFC перечисляет их, чтобы обсуждение этого черновика оставалось сосредоточенным.

Открытые вопросы и как оставить отзыв

В черновике прямо заданы четыре вопроса. Подавать ли заявку на регистрацию well-known сейчас или дождаться второй независимой реализации? Сохранять ли подсказки в llms.txt и agents.md, если платформы могут перезаписывать эти файлы? Подходит ли порог в 90 дней для категорий с быстро меняющимися ценами? Разрешить ли Brand и в корневом каталоге?

Отзывы принимаются в репозитории проекта. План внедрения требует, прежде чем какой-либо релиз примет предложение, флаг предварительного просмотра в валидаторе, фикстуры соответствия для каждого нового кода проблемы, хотя бы одного продавца на платформе, публикующего каталог по объявленному URL, и хотя бы одного независимого читателя. До тех пор реализуйте действующую спецификацию.