install-maintenance-graft-rtk-ponytail-lite

Промпт

# Проверенная установка и обслуживание — Graft + RTK + Ponytail lite

Вы работаете в текущем репозитории для установки, обновления, ремонта или проверки этого стека:

- Graft: понимание кода, локальный граф и обогащение LSP.
- RTK: снижение шума в терминале.
- Ponytail: облегчённая политика с нативной интеграцией при совместимости.

Начните с инвентаризации только для чтения. Затем задайте недостающие вопросы ниже.
После ответов выполните разрешённые операции до финальных проверок.

Не начинайте установку, не определив клиентов и область применения.
Не спрашивайте повторно о решении, уже принятом в этом разговоре.

## 1. Инвентаризация, затем выбор пользователя

### Инвентаризация без изменений

Определите:

- ОС, архитектуру, оболочку, окружение: локальная машина, WSL, SSH, контейнер;
- корень репозитория, рабочее дерево, статус Git и текущие операции Git;
- фактические пути, версии и способ установки Git, Node, npm, RTK, Graft и доступных клиентов;
- отдельно Claude Code, Codex, Kimi, Cursor Agent CLI и Cursor IDE;
- Gemini, Copilot CLI или другие клиенты, уже присутствующие как опциональные цели;
- фактически используемые каталоги конфигураций, переменные перенаправления и любой оркестратор, например AgentsRoom;
- существующие конфигурации пользователя, проекта, плагинов и унаследованных хуков.

Проверьте личность `agent` перед тем, как считать его Cursor.
Наличие бинарника не доказывает аутентификацию, работоспособность хука или загрузку MCP.

Не запускайте автоматические обновления, подключения или установки во время этой инвентаризации.
Не публикуйте никаких секретных значений.

Представьте краткую таблицу:
Клиент | Бинарник/версия | Эффективная конфигурация | Известный статус.

### Вопросы для единовременного запроса

Задавайте только вопросы, на которые отсутствует ответ:

1. Операция:
   - Установить отсутствующие компоненты и сохранить совместимые версии.
   - Обновить стек до проверенных стабильных версий.
   - Отремонтировать существующую установку, сохранив её версии.
   - Только проверить, без изменений.

2. Клиенты:
   - Все обнаруженные клиенты.
   - Выбор из фактически обнаруженного списка.
   - Также подготовить конфигурацию для некоторых отсутствующих клиентов.

3. Область интеграции:
   - Общий проект: переносимые конфигурации, предназначенные для репозитория.
   - Личный проект: активация для этого репозитория, не версионируемые локальные файлы.
   - Глобальный пользователь: активация для проектов этого пользователя.
   - Смешанный: отдельный выбор по клиенту или компоненту.

Если область смешанная, задайте только необходимые уточнения.

Для обновления также спросите о любых ограничениях по версии, если они ещё не известны.
Иначе предложите явные стабильные версии.

Не устанавливайте и не обновляйте сами клиентские приложения:
операция касается Graft, RTK, Ponytail и их необходимых зависимостей.
Устаревший клиент сообщается с требуемой версией и дальнейшими действиями.

### Сделайте выбор конкретным

Перед записью отобразите планируемый результат:

Компонент/клиент | Целевая версия | Область | Целевые файлы | Общий эффект | Запасной вариант

Объясните в частности:

- Исполняемый файл, установленный на уровне пользователя, может обслуживать несколько репозиториев.
- Обновление этого исполняемого файла влияет на всех его локальных пользователей.
- Плагин может иметь глобальный кэш, но активацию по проекту.
- Хук по проекту может использовать общий статус.
- Индекс Graft остаётся специфичным для репозитория/рабочего дерева.
- Глобальная конфигурация, предоставляемая оркестратором, может быть изолирована для проекта: проверьте её фактическую область, а не только имя.

После получения выбора продолжайте без повторных подтверждений.
Запрашивайте новое решение только если ограничение требует расширения области или изменения материального решения.

## 2. Правила выполнения

Порядок:
инвентаризация → выбор → резервные копии → RTK → Graft/LSP → Ponytail → инструкции → проверки → отчёт.

Соблюдайте инструкции репозитория и администрируемые политики.
Если файл управляется AgentsRoom или другим оркестратором,
используйте его официальный механизм; не изменяйте напрямую сгенерированные файлы.

Перед каждым изменением:

- проверьте формат И структуру JSON/JSONC/TOML конфигураций;
- сделайте резервную копию затронутых файлов вне репозитория с ограниченным доступом;
- зафиксируйте версии и элементы, необходимые для отката;
- просмотрите dry-run установщика, если он есть.

Неверный файл никогда не должен заменяться пустой конфигурацией.

Объединяйте конфигурации, сохраняя другие MCP, хуки, права,
инструкции, комментарии, когда возможно, и статусные строки.
Не меняйте правила одобрения или доверенные отпечатки.

Сохраняйте предварительные изменения Git. Без коммитов, пушей, сбросов,
очисток, стэшей или изменений кода приложения.
В случае нерешённого конфликта или текущей операции Git приостановите
записи в репозитории; продолжайте независимую диагностику.

Не устанавливайте Graphify, CodeGraph, Caveman или Headroom.
Старую конфликтующую интеграцию удаляйте только после точной идентификации,
резервного копирования и в пределах разрешённой области.
Не удаляйте глобально инструмент, используемый в других местах.

Ошибка блокирует зависимые шаги, но не другие независимые клиенты.
Не объявляйте шаг успешным, чтобы обойти ограничение.

## 3. Возможности и область: проверьте перед настройкой

Обратитесь к справке установленных версий и документам соответствующих
публикуемых версий, которые вы будете использовать:

- https://github.com/rtk-ai/rtk
- https://github.com/trailhq/Graft
- https://github.com/DietrichGebert/ponytail
- официальная документация каждого выбранного клиента.

Основная/разработческая ветка может описывать функции, отсутствующие в релизе.
Для сомнительной опции проверьте релиз, справку или поставляемый код.

Установите для каждой интеграции:

Клиент | Доступные хуки проекта | Совместимый установщик |
Область активации | Область состояния | Доказательство

Не путайте:
"клиент принимает хуки проекта"
и "установщик этого инструмента умеет устанавливать их на уровне проекта."

Контрольные точки для повторной проверки в текущих версиях:

- Claude: настройки пользователя, общий проект и локальный проект.
- Cursor: хуки пользователя и проекта; тестировать IDE и CLI отдельно.
- Codex: конфигурации пользователя/проекта и активация плагинов;
  проверять фактически доступные механизмы хуков.
- Kimi: не предполагать конфигурацию хуков на проект;
  различать конфигурацию пользователя, инструкции проекта и параметры запуска.
- Gemini/Copilot: проверять их собственные механизмы, если выбраны.

Если установщик не учитывает запрошенную область действия:

1. Искать соответствующую официальную опцию.
2. В противном случае использовать документированную ручную конфигурацию того же адаптера,
   только если его протокол и пути остаются совместимыми.
3. В противном случае использовать резервный вариант с явными инструкциями/префиксом.
4. Никогда не переключаться молча на глобальный.

Проверять унаследованные глобальные хуки перед добавлением их локальных эквивалентов:
они могут накапливаться, а не заменять друг друга.
Сохранять хуки безопасности. Сообщать о глобальных эффектах, которые остаются активными.

## 4. RTK

Проверять источник `rtk-ai/rtk`, версию, справку, конфигурацию
и `rtk gain`. Ошибка `gain` может быть вызвана базой или правами:
это не достаточное доказательство плохого пакета.

Устанавливать или обновлять с уже используемым менеджером, если это уместно.
Проверять источник формулы или пакета и полученную версию.
Избегать одновременных установок и ненужных изменений PATH.
Не запускать слепо `cargo install rtk`.

Консультироваться с `rtk init --help` для выбранной версии.
Выбирать опции по клиенту и области; не копировать систематически
`-g` из примера документации.

Не предполагать, что интеграция Codex всегда простая инструкция,
или что у неё всегда есть хук: это зависит от версии RTK.
Также проверять несовместимости между опциями инициализации.

В фактически прочитанной конфигурации объединять исключения:

    [hooks]
    exclude_commands = ["graft", "curl", "playwright"]

Сохранять существующие исключения и проверять их учёт.
Если эта настройка глобальная, указывать этот эффект перед изменением.
Отключать опциональную телеметрию документированным механизмом,
в пределах разрешённой области.

RTK: единственный компонент, уполномоченный переписывать shell-команды.
Хуки безопасности, аудита и утверждения остаются применимыми.

Не копировать хук Claude в другой клиент без документированной совместимости.
Без эффективного переписывания настраивать явный префикс `rtk`.
Избегать двойных хуков и двойных префиксов.

## 5. Graft с LSP

### Установка и конфиденциальность

Проверять идентичность пакета `@nanonets/graft`, его опубликованную версию
и требования к Node.

Устанавливать вне зависимостей приложения, в подходящем месте.
Не изменять package.json или lockfile проекта для установки Graft.

Применять `DO_NOT_TRACK=1` с первого запуска и в MCP.
Использовать официальную команду отключения телеметрии, если доступна.

Не активировать Brain, аккаунт, обогащение LLM или `--deep`.
Не обещать нулевой трафик без проверки.

Не запускать автоматически `graft init`.
Предпочитать явное подключение; установщик может писать вне репозитория.

### По-настоящему рабочий LSP

Перед исследованием кода приложения соблюдать правила Graft репозитория.
Затем определить полезные языки и ознакомиться с интеграциями LSP
выбранной версии Graft.

Повторно использовать совместимые серверы, уже присутствующие.
Устанавливать только необходимые серверы с зафиксированными версиями,
по возможности вне зависимостей приложения.

Проверять:

- исполняемый файл и его версию;
- доступность в PATH процесса Graft/MCP;
- языковые и рабочие предпосылки;
- поддержку этой версией Graft.

После чтения справки использовать, в частности, если доступны эти опции:

    graft build --lsp --no-ignore --no-gitignore
    graft check
    graft ask "Where are the main entry points and API routes, if any?" --source

Применять DO_NOT_TRACK к этим командам с текущим синтаксисом shell.

Проверять значение опций: в некоторых версиях,
`--no-ignore` и `--no-gitignore` предотвращают запись файлов исключений;
они не означают "индексировать игнорируемые файлы".

Явно управлять исключением Git для `/graft/` в соответствии с выбранной областью.
Проверять это с помощью Git. Не удалять автоматически уже отслеживаемые файлы.
Сохранять аннотации и содержимое, созданное человеком.

Сборка с `--lsp` и кодом выхода 0 не доказывает использование LSP.
Искать целевые доказательства: сервер действительно запущен, результат разрешения,
обогащённые связи или документированная диагностика.

Отчитываться по языкам:
LSP проверен / доступен без наблюдаемого обогащения / недоступен / не поддерживается.

Никогда не загружать весь граф или wiring.json в контексте.
Также проверять, сохраняется ли обогащение LSP после автоматического обновления;
если не гарантировано, документировать необходимую явную реконструкцию.

### MCP и актуальность

Настроить единственную эффективную точку входа Graft на клиента.
Определить фактически поддерживаемый файл, схему и область.

Для каждого сервера проверять:
установленную команду, аргументы MCP, DO_NOT_TRACK, PATH и рабочий каталог.

Не предполагать, что `.kimi-code/mcp.json`, `.mcp.json` или другой файл загружается автоматически: подтверждать механизм клиента или необходимую опцию запуска.

Глобальная конфигурация MCP приемлема только если целевой процесс корректно обрабатывает каждый репозиторий. Иначе держать MCP на уровне проекта.

Не использовать `npx -y ...@latest` при каждом запуске.
Не контролировать версии абсолютных личных путей или секретов.
Не придумывать универсальную переменную `${workspaceFolder}`.

В этом профиле не добавлять хуки Graft.
Без smart-grep, grep-redirect или перехвата shell Graft.

Проверять обновление и отсутствие непреднамеренного отключения.
Неудачное обновление запрещает представлять граф как свежий.

Проверять старые интеграции и метаданные авто-подключения перед миграцией.
Удалять только идентифицированные и сохранённые элементы.
Проверять, что они не появляются снова после запуска MCP и запроса.

### Статистика Graft

Отдельная операция, наблюдаемое использование и сбор статистики.

В зависимости от версии, `graft stats` зависит от хуков сессии.
Без этих хуков может появиться сообщение «сеанс еще не записан», несмотря на успешные запросы Graft.

Не подделывайте статистику и не запускайте `graft init`, чтобы это сообщение исчезло.

Если пользователю нужны нативные статистики, укажите совместимость доступных хуков измерения и явно запросите эволюцию профиля без хуков перед любой активацией.

## 6. Ponytail lite

Предпочитайте официальную интеграцию, совместимую с клиентом и областью.
Проверьте её манифест, события и зависимости.

Различайте:
установку плагина, активацию, режим по умолчанию и текущее состояние режима.

Проверьте фактически читаемые источники:
конфигурацию, `PONYTAIL_DEFAULT_MODE`, постоянное состояние и данные плагина.
`defaultMode: lite` не доказывает, что старое полное состояние было заменено.

Если режим общий для нескольких разговоров, укажите это.
В области проекта не меняйте глобальный режим по умолчанию без уведомления.
Используйте документированный локальный механизм или политику lite по инструкциям.

По клиентам:

- Claude/Codex: официальная установка и активация в доступной области.
  Проверьте подкоманды перед использованием.
  Одобрение хуков остаётся за пользователем.
- Cursor: официальный адаптер или правило инструкции; избегайте их накопления.
  Если существует `scripts/cursor-hooks.js install --project`, запустите скрипт
  из корня целевого репозитория, используя официальный путь checkout.
  Без `--project` проверьте пользовательское расположение.
  Проверьте сгенерированные пути: проектный хук с абсолютным путём
  к личному checkout не переносим и не должен коммититься.
- Kimi: ищите совместимый официальный адаптер. Иначе политика lite
  в AGENTS.md; добавляйте минимальный локальный скилл только если полезен
  и если подтверждены его формат и загрузка.
  Определяйте его как адаптацию, не обещая нативных команд или статистики.
- Другие выбранные клиенты: применяйте ту же проверку, без автоматического переноса
  событий Claude/Codex.

Держите checkout адаптера на идентифицированной версии или коммите.
Не выполняйте git pull на изменённом checkout.
Не добавляйте строку состояния или визуальный индикатор.

Проверьте фактический режим в новой сессии.

## 7. Компактные общие инструкции

Объединяйте блок, ограниченный:

    <!-- agent-stack:start -->
    ...
    <!-- agent-stack:end -->

в AGENTS.md. Сохраняйте весь внешний контент и добавления человека.
Не копируйте этот запрос установки в инструкции агента.

Блок должен содержать:

### Graft

Для понимания или изменения кода сначала исследуйте приложение:
`graft ask "<точный вопрос>" --source`, или фактически доступный инструмент MCP Graft.

Инструкции, скиллы, Git, конфигурации и обнаружение MCP могут предшествовать.
После ориентации читайте напрямую полезные части.
Для вызывающих используйте доступные команды/инструменты трассировки.

В случае устаревшего графа: проверьте, адаптированная реконструкция с LSP, затем новый запрос.
После неудачного поиска: целевой graft grep, затем прямое чтение
или ограниченный rg с объяснением ограничения.

Предоставленный файл, стек вызовов, конфигурация или неиндексированный язык
позволяют прямое целевое чтение.
Отсутствие в графе не доказывает отсутствия кода или вызывающих.

После изменений: graft blast, проверенная база Git и соответствующие тесты.
Без --name, без полной загрузки графа.
Отчёт о фактическом числе вызовов и любых ошибках.

### RTK

Проверенный хук: разрешите переписывание без двойного префикса.
Иначе: явно префиксируйте совместимые команды.
Никогда не передавайте Graft через RTK.

Для полного вывода: вызовите --full, если доступно, или прокси.
Не перезапускайте автоматически команду с побочными эффектами.
Сохраняйте пайплайны и перенаправления.

Перед валидацией: реальные распакованные диффы, diff --cached,
diff --check и отдельная проверка новых файлов.
Без автоматической постановки в индекс.

### Ponytail lite

Правильно реализуйте запрос и переиспользуйте существующее.
Кратко сообщайте о значительно более простом решении.
Сохраняйте валидацию, безопасность, разрешения, доступность, транзакции
и необходимые тесты. Проверяйте использования перед удалением или инлайнингом.

Полная версия только по явному запросу, никогда ультра по умолчанию.
Аудит не вызывает редизайн.
Исправление имеет приоритет для безопасности, парсеров, конкуренции и миграций.

Не утверждайте, что общий режим локален для разговора.
После авторизованного полного проверьте возврат к lite.
Отключение не удаляет уже внедрённые инструкции.

### Загрузка

Подтвердите, как каждый клиент фактически загружает эти инструкции.
Используйте документированные минимальные импорты/адаптеры.
Избегайте дублирований и циклических импортов.

RTK остаётся единственным переписывателем оболочки.
В этом профиле нет Graft хуков.

## 8. Обновление и ремонт

Один и тот же запрос должен иметь возможность повторного запуска без дубликатов.

В режиме обновления:

1. Перечитайте выбор области и ранее проверенное состояние.
2. Сравните установленные версии, целевые версии и несовместимые изменения.
3. Сделайте резервную копию перед любой миграцией.
4. Обновляйте только выбранные компоненты.
5. Обновляйте плагины/адаптеры официальным механизмом.
6. Переоцените возможности: старый запасной вариант может быть заменён
   нативной интеграцией, теперь доступной в той же области.
7. Мигрируйте только ключи и блоки, принадлежащие этому стеку.
8. При необходимости перестройте граф и перепроверьте LSP.
9. Перезапустите необходимые процессы MCP/клиента:
   существующий процесс может всё ещё работать на старой версии.
10. Повторите проверки и тесты изменённых интеграций.

Не переустанавливайте без необходимости компонент, который уже соответствует требованиям.
Не запускайте общее обновление пакетов машины.

В режиме ремонта сохраняйте версии, кроме случаев доказанной несовместимости
и явного решения об обновлении.

Подготовьте целевой откат: предыдущие версии, резервные копии
и точные команды. Не восстанавливайте слепо весь файл,
если с момента резервной копии произошли другие изменения.

Второй запуск без запрошенных изменений не должен создавать
никаких хуков, MCP сервера или дублирующихся секций инструкций.

## 9. Проверки и доказательства

Тестируйте отдельно:

- RTK исполняемый и явное сжатие;
- автоматический запуск хуков, исключения и прямой пропуск;
- Graft: актуальность, соответствие результата репозиторию и обогащение LSP;
- MCP: функциональный сервер И фактическая загрузка в каждом клиенте;
- Ponytail: активация и эффективный режим;
- отсутствие дубликатов и повторно появившейся самосборки;
- окончательная валидность конфигураций и эффективный охват.

Наличие файла не является доказательством загрузки.
Внешний MCP-зонд не является доказательством загрузки в клиенте.
Явный префикс RTK не является доказательством автоматического хука.

Для каждого доступного и аутентифицированного клиента откройте новую сессию
в репозитории с обычными защитами и выдайте этот нейтральный билет:

"Без изменения кода найдите основные точки входа.
Если есть API, укажите, где монтируются его маршруты, и проследите
путь к бизнес-логике. Укажите файлы и строки."

Не добавляйте "используйте Graft".
Проверяйте видимые вызовы инструментов, а не внутреннюю логику.
Сохраняйте минимальные доказательства и редактируйте конфиденциальные данные.

Если отсутствует подтверждение, вход или действие UI:
НЕ ПРОВЕРЕНО / ДЕЙСТВИЕ ПОЛЬЗОВАТЕЛЯ, успех не предполагается.

## 10. Результат

В пределах разрешённого охвата ведите краткую документацию по обслуживанию:

- выбор операции, клиенты и охват;
- точные версии, источник и дата проверки;
- механизмы конфигурации и ограничения;
- реконструкция Graft/LSP;
- процедура обновления, проверки и отката.

Для общей установки используйте `docs/agent-stack.md`.
Для личной/глобальной установки храните информацию, специфичную для машины,
вне версионируемых файлов.
В режиме только проверки предоставьте отчёт без создания этих файлов.

Отчёт должен содержать решающие команды, их результаты, изменённые файлы,
резервные копии и точные действия пользователя.

Инвентаризируйте итоговые хуки:
клиент, источник, охват, событие, сопоставитель, роль и отредактированная команда.

Завершите:

Client/version | Effective scope | Present configuration |
MCP loaded | Graft observed on first exploration |
LSP | RTK | Ponytail | Remaining proof/action

Используйте явные состояния:
CONFIGURED / LOADED / USAGE OBSERVED / NOT TESTED / BLOCKED / NOT APPLICABLE.

Классифицируйте файлы:
TO COMMIT AFTER REVIEW / TO IGNORE / MACHINE CONFIGURATION.

Личные пути, секреты, кэши, графы, резервные копии и транскрипты
не должны включаться в файлы для коммита.

Отобразите итоговый статус Git и изменения, внесённые этим вмешательством,
отличая их от предшествующих изменений. Ничего не коммитьте.

Теги