Tensionix ENDERU
GitHub28 репозиториевDaily Tech3 подписчикаaudion.devвитрина продуктовRSSлента выпусков
← Все заметкиProjects

Manifest Reference

config/tool_manifest.yaml описывает шаблонные операции для GUI.

Минимальная операция:

operations:
  - id: validate_input
    title: "Validate input"
    title_ru: "Проверить input"
    description: "Check input and print inventory."
    description_ru: "Проверить input и вывести инвентаризацию."
    tooltip: "Runs a local inventory check without changing files."
    tooltip_ru: "Запускает локальную проверку без изменения файлов."
    service: "system_core.services.sample_service:validate_input"
    kind: "safe"

Поля:

Правила:

Вложенные Меню

Для больших CLI-проектов используйте operation_groups. Дерево может иметь несколько уровней: например лаунчер -> формат -> профиль -> запуск.

operation_groups:
  - id: convert
    title: "Convert"
    title_ru: "Конвертация"
    tooltip_ru: "Выберите формат и профиль конвертации."
    children:
      - id: office
        title: "Office"
        title_ru: "Office"
        fields:
          - id: input_formats
            type: "checkboxes"
            label: "Input formats"
            label_ru: "Форматы input"
            default: []
            min_selected: 1
            options:
              - value: "docx"
                label: "DOCX"
              - value: "xlsx"
                label: "XLSX"
              - value: "pptx"
                label: "PPTX"
        children:
          - id: run_convert
            title: "Run"
            title_ru: "Запуск"
            service: "system_core.services.sample_service:run_sample_job"

Если задан operation_groups, видимый список команд строится из дерева. Важные плоские operations нужно продублировать в дереве.

Fields

fields показываются на финальном экране команды, наследуются дочерними узлами и передаются в context.operation.parameters. Кнопка запуска находится в верхней строке команды справа от названия, а Назад - слева.

Порядок fields лучше задавать по смыслу пользовательского решения, а не по порядку CLI-аргументов. Ставьте связанные поля рядом: ключ с моделью, формат с профилем, источник с режимом. Редкие числовые/ручные параметры можно пометить advanced: true или вынести ниже через локальные правила рендера.

Логические Секции Полей

Когда параметров становится много, не оставляйте их одной простынёй. Поля можно явно собрать в блоки:

fields:
  - id: source_url
    type: "text"
    group: "source"
    label_ru: "Ссылка"

  - id: output_format
    type: "radio"
    group: "output"
    label_ru: "Формат результата"

Поддерживаются ключи:

Если section равен advanced, expert или rare, поле попадёт в Дополнительно. Если section содержит другое значение, оно используется как визуальная группа.

Типовые группы:

Если группа не задана, GUI попробует сгруппировать поле по id и type. Это запасной механизм. В реальном проекте лучше явно назвать группы в manifest: так экран остаётся логичным даже при переносе десятков параметров.

Команды в children должны быть связаны с объектом текущей формы. Если leaf меняет конкретный список, cache или файл, отражайте это в title_ru/title: Ключ в избранное, Модель в избранное, Сделать инструкцию активной, Импортировать файл. Не используйте безымянные В избранное, Сохранить, Применить, когда рядом несколько fields и непонятно, к чему относится действие.

Подписи И Тултипы Полей

У поля две пары текстов, и они делят работу:

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

Тултип поля берётся из tooltip, при его отсутствии - из hint, затем из label. Поэтому длинное объяснение держите в tooltip, а не раздувайте hint: иначе оно окажется прямо в окне и вытеснит собой всё остальное.

Поддерживаемые типы:

Для checkboxes используйте:

Для миграции CLI-проектов удобно делать так: GUI собирает список чекбоксов в context.operation.parameters, сервис превращает его в аргумент старого CLI, например --extensions docx,pptx,xlsx, и уже CLI фильтрует работу. По умолчанию чекбоксы лучше оставлять пустыми: обычно пользователь хочет обработать что-то конкретное.

Динамические Options

Для select, radio и checkboxes можно не хранить список вариантов в YAML, а загрузить его из Python provider:

fields:
  - id: selected_input_files
    type: "checkboxes"
    label: "Staged input files"
    label_ru: "Файлы в input"
    default: []
    options_source: "system_core.services.sample_service:input_file_options"
    cache_seconds: 20

options_source использует формат module:function. Provider может принимать root проекта или не принимать аргументов. Он должен вернуть список:

[
    {"value": "example.docx", "label": "example.docx", "label_ru": "example.docx"},
]

GUI кэширует результат на cache_seconds секунд и показывает кнопку Обновить список. Если provider упал, GUI покажет ошибку как один вариант списка, а не уронит окно.

Для развитых LLM-проектов это заменяет старые ручные файлы со списками моделей. Не держите одновременно options_source/cache/favorites/smoke и статический models.yaml как равноправные источники. Manifest должен указывать динамический источник, а устойчивые значения вроде лимитов, prompts и env-настроек должны жить отдельно от model ids.

Профили / Пресеты

profile_buttons удобны для типовых наборов галочек и настроек:

fields:
  - id: sample_profiles
    type: "profile_buttons"
    label: "Quick presets"
    label_ru: "Быстрые профили"
    presets:
      - id: office
        label: "Office"
        label_ru: "Office"
        values:
          input_formats: ["docx", "pptx", "xlsx"]
          include_metadata: true
      - id: reset
        label: "Reset"
        label_ru: "Сброс"
        values:
          input_formats: []
          include_metadata: false

Пресет только меняет field_values; пользователь видит результат и сам нажимает Запустить.

Правлено 28.08.2026