Ошибки валидатора llms.txt: отклонять или предупреждать?

Согласно предложению v2, название проекта или сайта в H1 — единственный обязательный раздел. Валидатор должен отклонять отсутствующий или некорректный H1 и сломанный синтаксис ссылок списка файлов. Он не должен считать недостающий обзор, относительный URL или большой файл недействительными, если опубликованные правила явно не задают более строгий профиль.

Ключевые выводы

• Для обязательного синтаксиса и редакционных рекомендаций нужны разные уровни строгости.
• 90 из 113 измеренных ответов, начинавшихся с H1, использовали цитату; остальные 23 показывают, что такая частота не является требованием.
• Машиночитаемые коды правил делают поведение CI проверяемым.

Что должно считаться ошибкой?

Ошибки должны указывать содержимое, которое парсер не может интерпретировать согласно предложению. Например, пустой файл, первая значимая строка не H1, дополнительный H1 или элемент списка файлов, не являющийся ссылкой Markdown.

Номера строк и стабильные коды правил важны. H1_REQUIRED позволяет действовать, а «ваш файл плох» — нет. Задача CI должна завершаться с ненулевым кодом только из-за документированных ошибок, а не субъективного предпочтения стиля.

Что должно оставаться предупреждением?

Обзор в цитате необязателен. Таковы же пояснительная преамбула, разделы H2, примечания после ссылок и раздел Optional. Валидатор может рекомендовать их, если они улучшают понимание, но не должен переписывать предложение.

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

Как выглядят рабочие файлы?

Снимок нашего каталога включает 113 файлов, возвращающих текст и начинающихся с H1. В девяноста есть обзор в виде цитаты. Медианный файл содержит 7 разделов H2 и 76 разобранных ссылок списка, а наблюдаемое число разделов варьируется от 0 до 84.

Эти распределения показывают, почему частоту нельзя путать с корректностью. Распространённая особенность не становится автоматически обязательной, а редкая, но разрешённая структура — автоматически ошибочной. Сопоставляйте реальные примеры с формальными правилами.

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

Публикуйте точные правила, их уровень строгости и версию спецификации. Разделяйте три слоя:

1. Ошибки: парсер не может построить требуемую структуру.
2. Предупреждения: разрешённое содержимое может снизить переносимость или ясность.
3. Информация: эксплуатационные наблюдения, например размер или отсутствие связей обнаружения.

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

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

Недействительно ли отсутствие цитаты?

Нет. В v2 это необязательно, хотя часто полезно.

Недействителен ли файл размером более 50 KB?

В предложении не указан универсальный максимум. Размер может быть поводом для информационной проверки, но не для выдуманной синтаксической ошибки.

Может ли корректный файл всё же быть плохим?

Да. По синтаксису нельзя определить, являются ли выбранные страницы актуальными, релевантными или безопасными.