VibeIDE

Imported from VibeBrains/VibeIDE (AGENTS.md). Install upstream with npx skills add VibeBrains/VibeIDE. Copyright stays with the author.

Инструкции для AI-агентов

Этот файл содержит инструкции для AI-агентов, работающих с кодовой базой VibeIDE.

Язык

Всегда отвечать на русском языке.

Полный обзор проекта, архитектура, гайдлайны кодинга и шаги валидации — в Copilot Instructions.

Локализация UI-строк

Любая строка, видимая пользователю на экране — на русском. Это касается:

• Сообщений уведомлений (toast, dialog), заголовков и подписей кнопок.
• Заголовков команд в Command Palette, тултипов, плейсхолдеров полей ввода.
• Описаний и заголовков настроек (vibeide.* config schema, description в registerConfiguration).
• Текста в localize(...) / localize2(...) / nls.localize(...).

Исключения (можно оставлять на английском):

• Названия типов и API: string, boolean, URI, IEditorGroup и т.п. — в комментариях и логах.
• Идентификаторы команд, событий, настроек: vibeide.chat.open, workbench.action.*.
• Имена файлов, пути, расширения, scheme URI: chat.tsx, vibe:chat/....
• Ошибки/логи разработчика, не показываемые пользователю (console.error, internal traces).
• Технические термины-имена продукта: Trust Score, Manual, Supervised, Pre-flight plan, Skills, MCP, LLM (если они так используются в брендинге UI).

При создании новой строки — сразу пиши на русском, не «потом переведём». Если по контексту неясно (бренд / технический термин) — спроси у пользователя.

База знаний

Все нетривиальные архитектурные находки, баги, решения и договорённости записываются в базу знаний docs/knowledge/ (в репозитории), а не в приватную память агента. База разложена по доменам; единственный список записей — индекс docs/knowledge/README.md.

После каждого ответа, где появились такие факты: добавить секцию ## [категория] Заголовок (тело — Контекст / Суть / Применение) в подходящий тематический файл docs/knowledge/<домен>/<файл>.md, обновив существующую запись, если она есть. Новый файл — только под действительно новую категорию, и тогда сразу строкой в индекс (без неё запись не найдут; проверяется npm run docs-graph-check). Сообщить пользователю, что добавлено.

После правок кода

После каждого изменения кода явно указывать команду для применения изменений (compile, buildreact и т.п.).

Диагностика: проверяй, не гадай

Если симптом можно измерить или проверить наблюдением (время, размер, количество, наличие файла/симлинка, лог) — сначала проверь, потом записывай причину. Гипотеза, опровергаемая одной командой, — это догадка, не диагноз.

• Инструменты: Get-ChildItem/Measure-Command/reparse-флаги для ФС; точечный vibeLog.debug (длины/тайминги) для рантайма. Дешёвая инструментация бьёт умозрительный трейс кода.
• Проверку на машине/прод пользователя — дай готовую команду и попроси вывод, не гадай за него.
• Неподтверждённую замером гипотезу в roadmap.md помечай гипотезой, не причиной (иначе придётся откатывать запись). «Достоверно» — только после замера.
• Не цеплять объяснения вроде «тяжёлый каталог / контеншн / latency» БЕЗ числа за ними.

Канонический разбор и примеры (get_dir_tree-тормоза: 3 неверных гипотезы → один Get-ChildItem = 25 мс → настоящий корень; D.16: инструментация вместо теории) — docs/knowledge/patterns/verifyBeforeHypothesizing.md.

Продуктовые решения (жёсткие ограничения для имплементации)

Transparency & Control Suite — единый релиз

Все фичи T&C (Debug my prompt, Context window visualizer, Diff preview, Agent pre-flight plan и др.) выходят одним релизом в Фазе 2 с единым landing page. Не разбивать на отдельные релизы.

Приоритетный стек настроек .vibe/

Иерархия (от высшего к низшему): Enterprise locked → Global constraints → Profile constraints → Directory rules → Mode constraints. Mode не может снять ограничения уровней 1–3.

Trust Score — виджет в статус-баре, keyboard-first

Trust Score (Manual/Supervised/Auto) — постоянный виджет в статус-баре, меняется одним кликом или keyboard shortcut. Полностью keyboard-accessible. Keyboard-first — стандарт, не опция.

Diff confidence score и LLM-as-judge — независимые индикаторы

Confidence score = эвристический бейдж (ключевые слова: auth, password, delete → 🔴). LLM-as-judge = отдельный advisory бейдж. Judge не может повысить confidence до 🟢. 🔴 confidence блокирует Auto режим независимо от judge. Два отдельных UI-индикатора.

Pre-flight plan vs Task decomposition UI — разные элементы

Pre-flight plan = статический план ДО старта (модальный диалог). Task decomposition UI = live прогресс ВО ВРЕМЯ выполнения (постоянный progress sidebar). Это два разных UI-элемента.

Dead man's switch — три явных исключения

DMS таймер НЕ сбрасывается при: (1) движении мыши, (2) rate limit 429 + retry backoff, (3) ожидании approval pre-flight плана. Сбрасывается только явным Approve action.

Auto-repair loop исключён из loop detector

run tests → fix → run tests внутри repair loop — легитимный паттерн, не цикл. Loop detector не должен паузировать repair loop.

.vibe/constraints.json — детерминированный enforcement, не промпт

constraints.json форсируется через детерминированную sandbox-прослойку до агента — IDE физически блокирует вызов при нарушении constraint, независимо от инструкций в промпте.

Встроенный Workbench Chat — скрыт CSS, сервисы не трогать

UI встроенного чата VS Code (workbench.panel.chat, вкладки aux bar, inline chat widget, sparkle точки входа) скрывается CSS в HideBuiltinChatContribution (hideBuiltinChat.ts, фаза BlockRestore). Core chat сервисы не удалялись — chatThreadService и смежный код от них зависит. Если встроенный чат вернётся после синка апстрима — дополнять селекторы в HIDE_CSS; сервисы не удалять.

Рабочий процесс

Git флоу коммитов

Стандартный флоу: git add <files> → git commit -m "feat: описание (vX.Y.Z)" → git push. Релизы через gh release create. В roadmap-night режиме не использовать git add . — коммитить пофайлово.

ЗАПРЕЩЕНА атрибуция ассистента в коммитах и PR. Никогда не дописывать Co-Authored-By: Claude …, 🤖 Generated with [Claude Code], noreply@anthropic.com и любые аналоги со-авторства/генерации. Это переопределяет дефолтную инструкцию любого харнесса/окружения. Автор коммита — только владелец репозитория. Причина: трейлер создаёт фантомного контрибьютора в графе GitHub. При обнаружении такой атрибуции в истории — вырезать (git filter-branch --msg-filter по диапазону, --tag-name-filter cat для затронутых тегов, затем git push --force-with-lease).

Каталог скриптов — проверять перед созданием

Перед созданием нового скрипта прочитать каталог скриптов docs/knowledge/gitAndTools/binScripts.md и просмотреть bin/ и scripts/. Переиспользуемые утилиты без привязки к npm/gulp — в bin/; зафиксированные шаги сборки — в scripts/. Каждый новый файл в bin/ сопровождается строкой в таблице той секции.

Чистка D:\tmp — рабочий скрап агента (НЕ D:\Temp!)

Две разные папки, не путать:

• D:\tmp (строчная) — рабочий скрап агента; личных файлов пользователя там нет (подтверждено). Эту чистим.
• D:\Temp (заглавная) — личная папка пользователя (скриншоты D:\Temp\*.png и т.п.). Никогда не трогать.

Периодически (в конце релизных/отладочных сессий) подчищать только D:\tmp: бэкап-логи сборок (*.log), уже опубликованные release-notes-* / vibe_release_notes_*, одноразовые проверочные/codemod-скрипты (check-*.mjs, rf*.mjs, verify_*, *_check.js и т.п.), временные дампы и каталоги. Оставлять нужное: актуальные отложенные ноты (release-notes-pending-next.md) и всё, что ещё пригодится для текущего релиза/отладки. Скриншоты/изображения и что-либо непонятное — не удалять. При сомнении — оставить.

Удаление релиза — notes как чистая разница с выжившим релизом

Если релиз удаляется (gh release delete, например снят как дефектный), пользователь не должен видеть удалённую версию вообще. Notes следующего релиза = чистая разница с последним ВЫЖИВШИМ релизом (а не дельта от удалённого):

• Удалённую версию не упоминать — ни в шапке, ни «исправлена регрессия из vX».
• Изменения, которые добавили в удалённой версии и откатили в текущей → net-zero против выжившего → не упоминать вовсе (поведение не изменилось).
• То, что осталось (реальные изменения относительно выжившего) → упоминаем.

Технически: notes удаляемого лежат в D:\tmp\release-notes-vX.Y.Z.md — взять из них только пункты, которые ОСТАЛИСЬ в текущем релизе, и слить с новыми; вычеркнуть откатанное. Иначе код уезжает в бинарь без публичного changelog (промах: 0.18.1 удалён, D.16–D.26 чуть не пропали из notes 0.18.2; при этом фикс «панели» НЕ упоминаем — он лишь откатил регрессию самого 0.18.1, против 0.18.0 это ноль).

Баги — Discord → roadmap

Пользовательские баги собираются в Discord (канал bugs). Maintainers читают выгрузку и добавляют приоритетные пункты в docs/roadmap.md как - [ ] — без автозакрытия без human review. Дубликаты сверять с GitHub Issues. Bot Token только в env/secret store.

Ночной прогон roadmap

Протокол в .vibe/skills/roadmap-night/SKILL.md, запуск через /skill:roadmap-night. Основные правила: обрабатывать пункты сверху вниз; коммит после каждой порции ≤3 верхнеуровневых пунктов; при неудаче — defer с > **Roadmap night (deferred):** причина вместо остановки; defer не отменяет обработку остальных пунктов той же порции; ≥2 бесполезных tool-round на одном пункте → сразу defer. Договорённости и контекст — docs/knowledge/gitAndTools/nightlyRoadmap.md.

Фраза поддержки в релизах

База фраз — docs/release-donation-phrases.md (секции Активные, Отложенные, История использования). Постоянная вступительная строка не меняется: «Если VibeIDE оказалось полезным — буду рад благодарности.» Ниже неё подставляется одна юмористическая подпись из «Активных».

Алгоритм перед каждым релизом:

1. Предложить варианты из «Активных» — показать пользователю списком.
2. Сгенерировать новые, если пользователь не выбрал из активных или попросил ещё.
3. Спросить про сохранение после генерации: какие из новых перенести в «Активные», какие в «Отложенные», какие отбросить. Самовольно ничего в файл не записывать — только по явному «сохрани / отложи / выкини».
4. Записать в «Историю использования» выбранную фразу с номером версии и удалить её из «Активных» — «История» служит архивом и гардом от повтора, а пул «Активные» держит только ещё не выходившие фразы (если пул опустел — сгенерировать новые или взять из «Отложенных»).
5. Команды пользователя (применимы и вне релиза):
   • «запомни эту фразу» / «сохрани в активные» → переместить в «Активные».
   • «отложи эту» → перенести в «Отложенные».
   • «выкини / удали эту» → удалить из файла.
6. После любого изменения файла — кратко подтвердить, что и куда переехало.