# Как агенту читать спецификацию «42»

Этот файл задаёт порядок чтения. Правила остаются в структурированных источниках ниже.

## Как читать спеку

- `/architecture.md` — устройство спецификации, источники истины и связь человеческих и машинных проекций.
- `/release.json` — текущая версия и SHA-256-ревизии артефактов и сущностей; это первая проверка обновления.
- `/changes.json` — структурированные изменения между версиями; `/spec-changelog.md` — их человеческая проекция.
- `/spec.json` — нормативный канон: выбор компонента, пропсы, поведение, ограничения и отступления.
- `/examples.json` — живые Svelte-примеры, автоматически прочитанные из демо сайта.
- `/tokens.json` — значения и алиасы токенов; источник значений — CSS-слои.
- `/scope.json` — фактическое покрытие «компонент × скин».
- `/content.md` — правила текста для интерфейса и документации.
- `/spec.schema.json`, `/consumer.schema.json` и `/lock.schema.json` — контракты форматов канона и потребителя.
- `/consumer-examples.json` — одинаковый manifest/lock-протокол для Vue и Svelte.
- `/<id>.md` — компактное Markdown-зеркало одного компонента, когда весь JSON избыточен.
- Удалённый MCP отдаёт те же источники через `ds42://…`; инструменты поиска и diff не создают отдельного канона.

## Порядок работы

- Сначала сравни `/release.json` или `ds42://release/current` с локальным `42.lock.json`. Если ревизии совпадают, миграция не нужна.
- Если ревизии различаются, вызови `diff_releases` или прочитай затронутые записи `/changes.json` и работай только с сущностями из локального `42.consumer.json`.
- Определи пользовательское намерение и найди кандидатов по `useCases.when`; исключи совпадения с `useCases.avoid`.
- Сверь `alternatives`, затем выбери один существующий компонент — не изобретай новый молча.
- Примени `guidelines` выбранной сущности и релевантных практик: `must` обязателен, `must-not` запрещён, `should` требует причины для отступления.
- При изменении видимого текста или документации обязательно прочитай `/content.md`.
- Сверь допустимые пропсы, невозможные комбинации, клавиатуру, доступность и сознательные `departures`.
- Возьми ближайший пример из `/examples.json`; адаптируй содержимое, не создавая новый вариант ради одного экрана.
- Используй только токены из контракта компонента; наличие брендового покрытия проверь в `/scope.json`.

## Проверка результата

- Проверь результат по исходному намерению, а не только по валидности отдельных компонентов.
- Проверь клавиатурный путь, текстовые имена и ошибки; цвет не должен быть единственным носителем смысла.
- После адаптации обнови локальный `42.lock.json` только для реально сверенных артефактов и сущностей.
- Для изменения самой системы выполни тесты схемы, токенов и статическую сборку.

## Пробелы и изменения системы

- Если правило отсутствует или два источника расходятся, зафиксируй пробел и остановись — не подставляй усреднённый паттерн из интернета.
- Новый компонент, ось, значение оси или сознательное отступление требует решения дизайнера.
- Изменение поведения обновляет data-модуль и все проекции в том же диффе; изменение формата — schema, version и changelog.

## Шаблон задачи

> Задача: [намерение и место]. Сравни локальный 42.lock.json с текущим release, затем выбери затронутые сущности из 42.consumer.json. Примени правила из /spec.json, пример из /examples.json и значения из /tokens.json. Если канона не хватает, перечисли пробелы.