Добавьте свой инструмент в WireCat
Как попасть со своим инструментом командной строки в группу «Инструменты сообщества» на wirecat.dev и в WireCat Desktop: что нужно, pull request, проверка, обновления и снятие.
Вы сделали инструмент командной строки и хотите, чтобы его находили рядом с инструментами WireCat. Эта страница для авторов вне WireCatLabs. Она показывает, что нужно вашему инструменту, как попросить о включении в список, что мы проверяем и что происходит после слияния. Инструмент из списка появляется на wirecat.dev в группе «Инструменты сообщества», а в WireCat Desktop у тех, кто включил инструменты сообщества.
Список не делает ваш инструмент частью WireCat. У него остаются ваше название, ваше пространство имен npm и ваш репозиторий. Вы и дальше сами его делаете и выпускаете.
Кто может добавить инструмент
Инструменты WireCat читают сообщения, почту и файлы людей. Поэтому мы не берем инструменты у всех подряд. Инструменты приходят от одобренных авторов, которые подают заявку или получают приглашение, и для каждого нужно доказательство, что наши проверки на нем прошли, и одобрение человека из команды в конце. Прием заявок пока не открыт. Чтобы спросить, откройте issue в cli-docs.
Что нужно инструменту
- Он собран из шаблона или отвечает тому же стандарту. Начните с Создайте свой CLI. Все проверки «Done when» из чек-листа нового CLI проходят в CI вашего инструмента.
- Каждая команда называет профиль. Профиль это имя одного из ваших аккаунтов, например
personal. Инструмент никогда не выбирает аккаунт сам, а без профиля выдает ошибку со списком вариантов. Это касается каждой команды, примера, справки и страницы. - Его репозиторий публичный. Для пакета из приватного репозитория npm не делает запись provenance, и мы не можем проверить код, который не видим. Инструмент из приватного репозитория можно добавить только на своем компьютере, как непроверенный.
- Он публикуется в npm из GitHub Actions через trusted publishing. Релиз запускается из
release.ymlв репозитории самого инструмента, на веткеmain. WireCat Desktop проверяет npm provenance каждого релиза, то есть подписанную запись о том, где npm собрал пакет. Приложение отказывается ставить релиз, если запись не указывает на этот workflow в вашем репозитории. Шаблон настраивает это за вас. - В планах: публикация через наш workflow релиза. Ваш
release.ymlбудет вызывать закрепленную версию workflow WireCatLabs, который запускает наши проверки стандартов и потом публикует пакет. Тогда запись provenance называет наш workflow тем, что собрал пакет, и любой видит, что наши проверки на этом релизе прошли. - У него свое название. Публикуйте в своем пространстве имен npm, например
@example/acme-cli.@wirecatи название «WireCat» остаются нашими. Не берите имя, которое WireCat оставил за своими инструментами, напримерtg,maxилиmail. - У него есть тег релиза и страницы. Тег
vX.Y.Z, совпадающий с версией в npm, и на этом теге папкаdocsс вашими страницами иmeta.json, где они перечислены. Сайт копирует страницы оттуда.
Попросите о включении в список
- Выпустите версию, которую хотите показать. Поставьте тег
vX.Y.Z, иrelease.ymlопубликует ее. - Откройте pull request в cli-docs. Добавьте инструмент в
tools.jsonс"community": true. Добавьте его имя и вcontent/docs/meta.json,meta.ru.jsonиmeta.es.json. - Добавьте переводы, если их нет. Сайт на английском, русском и испанском. Страницы на двух других языках
кладутся в
translations/<name>/в cli-docs, аpnpm docs:translation acceptих записывает. - Приложите доказательства в pull request. Зеленый прогон CI на коммите с тегом и результат проверки свежим агентом, которую описывает чек-лист нового CLI.
Вот полная запись для инструмента acme:
{
"name": "acme",
"displayName": "Acme Notes",
"repo": "example/acme-cli",
"package": "@example/acme-cli",
"lang": "en",
"summary": {
"en": "Your Acme notes on your computer, searchable offline.",
"ru": "Ваши заметки Acme на вашем компьютере, с поиском без сети.",
"es": "Tus notas de Acme en tu ordenador, con búsqueda sin conexión."
},
"docsRef": "v1.0.0",
"community": true,
"desktop": {
"tagline": "Acme notes, searchable with your WireCat data",
"bin": "acme",
"profiles": { "args": ["profile", "list", "--json", "--no-record"], "shape": "items" },
"doctor": ["{profile}", "doctor", "--json", "--record"],
"runs": null,
"search": null,
"setup": ["{profile}", "setup"],
"signIn": { "gives": "your Acme notes", "asks": "an Acme API token", "guide": "https://example.com/acme/token" },
"skill": null,
"mcp": null,
"mcpServer": null,
"tasks": null,
"sync": null,
"storeInfo": null,
"storeTables": null,
"storeTableSizes": null,
"storeCheck": null,
"storeBackup": null,
"storeBackupEncrypted": null,
"storage": { "app": "acme-cli", "env": "ACME" },
"settings": null
}
}Поля:
nameэто команда, которую набирают люди. Для приложения это от 2 до 16 строчных латинских букв.repoэтоowner/nameна GitHub, вне WireCatLabs.packageэто имя в npm с пространством имен.langэто язык ваших страниц.summaryэто одна строка на каждом из трех языков.docsRefэто тег релиза, с которого сайт копирует ваши страницы.desktopэто то, что нужно WireCat Desktop, чтобы установить, проверить и подключить ваш инструмент. Без него инструмент будет только на сайте.taglineне длиннее 55 символов.binэто программа, которую ставит npm.storageэто имя папки и префикс переменных окружения, которые ваш инструмент передает вresolvePathsиз cli-base. Пишитеnullдля команды, которой у инструмента нет.- В каждом списке только простые слова команды. Буквы, цифры и
._:=,/+@-, не больше двух дефисов в начале и места для подстановки вроде{profile}. Без пробелов, кавычек и знаков оболочки.
Запись сообщества не может задавать partOf, commandPrefix, memory, taskBoard, bot, storeReset,
storeResetPreview, configRepair и signIn.command. Они только для инструментов самого WireCat.
Что мы проверяем
Проверки идут по порядку. Сначала автоматические, а последним одобряет человек.
Автоматически, в pull request:
- Уже есть: тесты в cli-docs запускают те же правила записи, что и приложение, так что плохая запись
desktopне пройдет pull request. - В планах: provenance релиза называет ваш репозиторий, а когда он появится, и наш workflow релиза.
- В планах: наши проверки стандартов запускаются заново на исходниках с вашего тега релиза.
- В планах: пакет из npm проверяется на секреты и вредоносный код.
- В планах: свежий агент проверяет инструмент в CI, получив только наш справочник и ваш репозиторий.
Человек из команды одобряет, следуя списку проверки инструментов сообщества. Пока запланированных проверок нет, он проверяет это вручную:
- Чек-лист нового CLI зеленый в вашем CI, на коммите с тегом.
- Проверка свежим агентом не нашла открытых пробелов.
- Каждая команда, пример, справка и страница называют профиль.
- Ничто не использует
@wirecatи название «WireCat». - На релизе с тегом команды doctor и setup из записи работают как написано для нового профиля, и каждая другая команда из записи существует.
- Папка данных из
storageпринадлежит только вашему инструменту.
Ревью проверяет, как инструмент собран и выпущен. Оно не проверяет все, что инструмент делает.
После слияния
- Сайт показывает его в группе «Инструменты сообщества», со страницами с тега
docsRef. - Список для приложения пересобирается. При каждом обновлении сайта собирается и подписывается список инструментов сообщества для WireCat Desktop. Сайт обновляется при каждом слиянии и раз в день.
- Пользователи приложения видят его, только если сами захотели. Инструмент появляется, когда человек в настройках
включает «Включить инструменты сообщества» и перезапускает приложение. У него значок Сообщество, а до установки
подпись «Сделано
<owner>, не WireCat. Приложение проверяет, где npm собрал пакет, но не что он делает.» - Каждая установка проверяется. Перед установкой приложение проверяет, что npm собрал этот релиз из
release.ymlвашего репозитория наmain.
Сайт собирает и подписывает список для приложения, и WireCat Desktop читает его, когда включено Включить инструменты сообщества.
Обновления
- Новые версии. Как новые версии проверяются и доходят до пользователей, сейчас продумывается.
- Страницы на сайте берутся с тега
docsRef. Ежедневная проверка открывает issue в cli-docs, когда выходит новый релиз. Pull request, который переноситdocsRefна новый тег, обновляет ваши страницы после ревью. Его можно открыть и самому. - Изменения записи
desktop, например новая команда, идут через pull request и то же ревью.
Снятие из списка
Мы снимаем инструмент, когда он нарушает правила выше или когда об этом просит автор. Запись уходит из tools.json,
и следующее обновление сайта публикует список без нее.
- На сайте инструмент пропадает из группы «Инструменты сообщества».
- В приложении инструмент больше не предлагается, начиная со следующего запуска после получения нового списка. Приложение никогда не удаляет копию, которую человек установил.
- В планах: приложение показывает снятый, но установленный инструмент как «Больше нет в списке», с кнопкой удаления.
Попробуйте до включения в список
Свой инструмент можно добавить в WireCat Desktop до любой проверки. Тогда у него метка Не проверен.
- В настройках включите Разрешить инструменты, которые WireCat не проверял и подтвердите предупреждение кнопкой Разрешить.
- На странице «Инструменты» нажмите Добавить свой инструмент, вверху рядом с Проверить снова. Введите имя пакета в npm и нажмите Проверить пакет. WireCat только читает npm: пока ничего не устанавливается.
- Экран проверки показывает издателя, репозиторий, версию, где npm его собрал и что он запрашивает. Нажмите Добавить, затем Установить и запустить во втором вопросе.
Desktop читает манифест инструмента, contracts/wirecat.json, из пакета в npm, поэтому инструмент должен его
содержать (Создайте свой CLI). Инструмент из закрытого репозитория можно добавить так, но
нельзя включить в список. Все экраны и что значит каждый отказ показывает страница Добавить свой инструмент.
Что дальше
- Создайте свой CLI, чтобы начать инструмент из шаблона.
- Вход и соответствие стандартам о правилах, которым следует каждый инструмент.
Вход в сервис и соответствие стандартам
Как инструмент входит к провайдеру и держит секреты вне хранилища и экрана, а также стандарты, проверки и выпуски cli-core, которым он должен следовать.
Архитектура
Как устроены tg и max — пакеты, слои, контракт адаптера, локальное хранилище и приёмы, на которых всё держится.