---
name: n-taze
description: >-
  Оновлення версій модулів проекту до останніх (усі екосистеми — JS/npm, Rust,
  Python тощо — через активні lang-плагіни) з аналізом major-змін і
  автоматичним рефакторингом несумісного коду
version: '2.0'
---

# n-taze — Оновлення версій проекту

## Мета

Оновити всі модулі проекту до останніх версій, виявити major-оновлення, перевірити сумісність змін з кодом проекту і за потреби зрефакторити несумісні місця. Кожна екосистема (JS/npm/bun, Rust/Cargo, Python/uv, …) — гілка відповідного lang-плагіна; конкретні команди гілок описані у фрагментах плагінів наприкінці цього файлу.

## Оркестрація — не одним промптом

`npx @7n/rules skill pi|cursor|codex taze` **не** передає цей файл одним суцільним
промптом в один агентський хід — так робив старий дизайн, і саме тому реальний
прогін міг зависати без жодної діагностики (один величезний непрозорий хід на
весь монорепо, без проміжних зупинок для перевірки прогресу). Замість цього `npm/skills/taze/js/orchestrate.mjs`:

1. Детерміновано, без LLM, виконує кроки 1-3 нижче для кожної екосистемної гілки через її EcosystemProvider (detect → backup → bump → diff; конкретні команди — у фрагменті відповідного плагіна наприкінці файлу).
2. Для кожного **окремого** major-запису з diff-у — один ізольований, обмежений виклик обраного раннера (кроки 4-6, лише для цього запису; промпт генерує `promptFor` провайдера, не цей SKILL.md).
3. Детерміновано прибирає бекапи (крок 7) і компонує звіт (крок 8) з результатів усіх ітерацій.

Усі екосистеми оркестратор веде через **EcosystemProvider-порт**
(`@7n/rules/plugin-api`, spec `docs/specs/2026-07-18-lang-plugins-extraction-spec.md`)
— lang-плагіни доставляються автоматично при першому запуску за файловим
сигналом (extension-point `taze`; JS/npm — `@7n/rules-lang-js` за кореневим
`package.json`) і додають свої гілки як фрагменти цього SKILL.md (блок
наприкінці файлу). Ядро — двигун без мовної специфіки: без сигналу екосистеми
у звіті немає навіть згадки про неї. Якщо тулчейн гілки не встановлено — вона
пропускається з причиною у звіті, не блокуючи інші.

Переваги: падіння/timeout на одному пакеті/крейті не втрачає прогрес по інших;
кожен виклик успадковує власний timeout раннера (короткий, бо скоуп малий —
один запис, не весь монорепо); видно прогрес по записах, а не чорну скриньку.

Кроки 1-8 нижче — **скелет** роботи будь-якої гілки (що означає кожен крок);
конкретні команди кожної екосистеми — у фрагменті її плагіна. Оркестратор
виконує кроки 1-3/7/8 програмно, 4-6 — як промпт на один запис.

## Передумови

- Чисте робоче дерево (`git status` без незакомічених змін у маніфестах/lock-файлах залежностей) — інакше різницю не відрізнити від оновлення.
- Запуск з кореня проекту.
- Передумови конкретних гілок (bun/bunx, cargo-edit, uv тощо) — у фрагментах плагінів наприкінці файлу; відсутній тулчейн не блокує інші гілки.

## Workflow (скелет — конкретика у фрагментах плагінів)

### 1. Зафіксувати стартовий стан

Перед оновленням зберегти копії маніфестів залежностей (`<manifest>.taze-bak`) — щоб потім детерміновано обчислити, які модулі стрибнули через major. Файли тимчасові, видаляються в кінці.

### 2. Запустити оновлення

Командою екосистеми підняти всі залежності до останніх версій, **включно з major**, і синхронізувати lock-файл.

### 3. Виявити major-оновлення

> **Не порівнюй маніфести вручну.** Класифікацію semver несе детермінований diff гілки (порівняння з `.taze-bak`-бекапом за caret-правилом: major = змінилась найлівіша ненульова компонента — `1.x→2.x`, `0.4.x→0.5.x`, `0.0.3→0.0.4`).

Major-записи йдуть у кроки 4–6; лічба сумісних (minor/patch) — у звіт кроку 8. Покриваються **прямі** залежності; транзитивні — за потреби окремо.

### 4. Зібрати breaking changes по кожному major-оновленню

Для кожного запису зі списку зібрати фактичні відмінності: CHANGELOG/Releases репозиторію пакета (джерело адреси — у фрагменті гілки), а без них — diff публічного API між кешованою старою версією і новою. Цікавлять: видалені/перейменовані експорти, змінені сигнатури, змінені типи, змінена поведінка за замовчуванням, видалені CLI-прапорці.

### 5. Перевірити сумісність з кодом проекту

Для кожного breaking change знайти використання зачепленого API в коді (`rg -n` по мові гілки). Класифікувати: **сумісно** — не використовується → нічого не робити; **несумісно** — перейти до п. 6.

### 6. Рефакторинг несумісних місць

Застосувати міграцію згідно з changelog пакета (перейменувати імпорт, оновити сигнатуру виклику, замінити видалену опцію еквівалентом тощо). Після правок — прогнати перевірки гілки (лінт/typecheck/тести — конкретні команди у фрагменті). Нетривіальна або неоднозначна міграція — **не вгадувати**: TODO у коді з посиланням на CHANGELOG і запис у звіт як ручна дія.

### 7. Прибрати тимчасові файли

Видалити всі `.taze-bak`-бекапи, створені на кроці 1.

### 8. Звіт користувачу

Для кожної обробленої гілки — окрема секція:

- **Оновлено (minor/patch):** кількість пакетів, без деталей.
- **Major-оновлення:** список `<name>: <old> → <new>` з посиланням на release notes.
- **Зрефакторено автоматично:** список файлів і коротко що саме змінено.
- **Потребує ручного втручання:** список TODO з причиною (нетривіальна міграція / неоднозначність / падіння тестів).
- **Стан перевірок:** перевірки гілки — pass/fail з номером рядка, де впало.

## Примітка

- Не запускати `npx @7n/rules lint` паралельно з іншими ESLint-задачами — діє правило з кореневого `CLAUDE.md`.
- Якщо проект — `npm/` пакет цього репо, після змін у `package.json` / коді треба підняти `version` і додати запис у `CHANGELOG.md` згідно з `npm/CLAUDE.md`.
- При великій кількості major-оновлень розбити PR по одному модулю на коміт — щоб `git bisect` залишався корисним. Це стосується пакетів кожної гілки окремо.