crun-model-router

crun-model-router — навык для выбора и проверки подходящей медиа-модели Crun по структурированному намерению пользователя. Он предназначен для случаев, когда человек описывает желаемый результат изображения, видео, аудио или музыки, но не называет точную модель, а также когда требуется осознанно сопоставить качество, скорость, reference media или native audio. Результатом работы является не случайный выбор по названию, а нормализованное намерение и маршрут к модели, который можно проверить через инструменты репозитория. На первом этапе запрос приводится к одному JSON-объекту. В него входят modality со значением image, video или audio, operation с конкретной операцией вроде text-to-image, image-edit, text-to-video, image-to-video, reference-to-video, text-to-speech или music-generate, а также quality со значением balanced или best и speed со значением balanced или fast. Дополнительно фиксируются native_audio как логическое ограничение и reference_media как список переданных референсных материалов. Явные ограничения пользователя нужно сохранять. Операцию допустимо выводить из переданных медиа только тогда, когда это однозначно следует из запроса; при неопределённости нельзя подменять требование догадкой. Источником правды для routing labels и priority служат каталог models.json и связанный с ним runtime. Для маршрутизации предусмотрен crun_cli.py: намерение можно передать через JSON-файл или stdin командой models route --intent-file, а выбранную модель проверить командой models describe --model. После выбора по умолчанию показывается selected. Варианты alternatives следует показывать только тогда, когда различия между ними действительно важны для решения или пользователь прямо просит сравнение. Такой порядок отделяет основной маршрут от необязательных альтернатив и не перегружает результат перечнем моделей без объяснимой причины. Проверка выбранной модели должна опираться на её required_input_fields и input_schema. Нужно запросить только те обязательные сведения, которые нельзя вывести из уже полученного намерения. Нельзя самостоятельно придумывать поля ввода и нельзя копировать схему соседней модели: разные модели могут требовать разные данные, а перенос чужой схемы создаёт ошибочную инструкцию для следующего шага. Поэтому описание входной формы должно быть получено из актуальной информации о выбранной модели, а не реконструировано по сходству её имени с другими кандидатами. Если статический кандидат отсутствует или отклонён, для поиска доступных вариантов используется models list. Возможности и priority нельзя выводить из одного названия модели или из предположения по схеме. Если каталог должен знать новую возможность или новый приоритет, это изменение нужно явно внести в models.json. Если жёсткое требование пользователя конфликтует с доступными кандидатами, корректное поведение — сообщить о конфликте, а не молча ослаблять ограничение и не выдавать несовместимую модель за подходящую. Навык отвечает именно за нормализацию намерения, выбор и инспекцию модели. Проверку доступности или стоимости он передаёт отдельному crun-account-credits/SKILL.md, а создание задания и его мониторинг — crun-task-runner/SKILL.md. Такое разделение сохраняет границы этапов: выбранная модель сначала должна соответствовать намерению и актуальной схеме входа, затем могут выполняться отдельные проверки доступности и последующая работа с заданием. Практический сценарий включает описание желаемого медиа-результата, фиксацию ограничений, маршрутизацию, чтение обязательных полей и передачу результата следующему специализированному skill.