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 залишається єдиним переписувачем shell.
У цьому профілі немає Graft хуків.

## 8. Оновлення та ремонт

Той самий запит має бути здатним запускатися повторно без дублікатів.

У режимі оновлення:

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

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

У режимі ремонту зберігайте версії, крім випадків доведеної несумісності
і явного рішення про оновлення.

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

Друге виконання без запитаних змін не повинно створювати
жодного хуку, MCP сервера або дубліката секції інструкцій.

## 9. Перевірки та докази

Тестуйте окремо:

- RTK виконуване та явне стиснення;
- автоматичне спрацьовування хуків, виключення та сирий пропуск;
- Graft: актуальність, відповідність результату репозиторію та збагачення LSP;
- MCP: функціональний сервер ТА фактичне завантаження в кожному клієнті;
- Ponytail: активація та ефективний режим;
- відсутність дублікатів та повторної самопідключення;
- остаточна валідність конфігурацій та ефективна область застосування.

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

Для кожного доступного та автентифікованого клієнта відкрийте нову сесію
у репозиторії з його звичайними захистами та видайте цей нейтральний квиток:

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

Не додавайте "use Graft".
Перевіряйте видимі виклики інструментів, а не внутрішню логіку.
Зберігайте мінімальні докази та редагуйте конфіденційні дані.

Якщо відсутнє підтвердження, вхід або дія в UI:
НЕ ТЕСТУВАЛОСЯ / ДІЯ КОРИСТУВАЧА, успіх ніколи не припускається.

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

У межах авторизованої області зберігайте коротку документацію з обслуговування:

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

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

Звіт про вирішальні команди, їх результати, змінені файли,
резервні копії та точні дії користувача.

Інвентаризуйте кінцеві хуки:
клієнт, походження, область, подія, матчер, роль та відредагована команда.

Завершіть:

Клієнт/версія | Ефективна область | Наявна конфігурація |
MCP завантажено | Graft спостерігався при першому огляді |
LSP | RTK | Ponytail | Залишкові докази/дії

Використовуйте явні стани:
CONFIGURED / LOADED / USAGE OBSERVED / NOT TESTED / BLOCKED / NOT APPLICABLE.

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

Особисті шляхи, секрети, кеші, графи, резервні копії та транскрипти
не повинні включатися у файли для коміту.

Показуйте остаточний статус Git та зміни, внесені цим втручанням,
відокремлюючи їх від попередніх змін. Нічого не комітьте.

Теги