@nitra/cursor 3.22.0 → 3.23.0

package/skills/start-check/SKILL.md

@@ -21,80 +21,53 @@ description: >-
 
 ### 1. Зібрати список воркспейсів
 
-Прочитай поле `workspaces` з кореневого `package.json`. Воно може містити glob-патерни (`packages/*`, `apps/*`) — розгорни кожен у конкретні директорії. Для кожної директорії прочитай її `package.json`.
-
-### 2. Відфільтрувати воркспейси зі `start`-скриптом
-
-Воркспейс перевіряється, лише якщо в його `package.json` є `scripts.start`. Решту — пропусти й познач у звіті як `SKIP (немає start)`.
-
-### 3. Класифікувати `start` і зафіксувати стан репо
-
-Скіл прогоняє **кожен** воркспейс зі `start` — запуск не пропускається. Але `start` буває двох типів, і це впливає і на трактування коду виходу, і на ризик побічних ефектів:
-
-- **Запуск сервера/застосунку** (`vite`, `next dev`, `nuxt dev`, `node`/`bun <server>`, `nodemon` тощо) — успіх визначається за живучістю процесу.
-- **CLI/разова дія** (зокрема ті, що мутують репо — sync, генерація коду, міграції, розгортання, перезапис конфігів) — успіх визначається за кодом виходу; такий `start` може **виконати реальну роботу** й лишити зміни в репозиторії.
-
-Щоб прогін мутаційного `start` не лишив сміття, зафіксуй стан робочого дерева **перед** запусками:
+> **Не парси `package.json`/glob вручну.** Розгортання воркспейсів і класифікацію `start` несе CLI.
 
 ```bash
-git status --porcelain > /tmp/n-start-check.before
+n-cursor start-check scan
 ```
 
-Цей знімок — база, щоб відкотити побічні ефекти (крок 5).
-
-### 4. Прогнати `start` послідовно
+Друкує JSON `[{ workspace, name, hasStart, startCmd, type }]` для root + усіх воркспейсів. `type` — `server` (dev-сервер/демон) чи `cli` (разова дія). Воркспейси з `hasStart:false` — `SKIP (немає start)` у звіті; решту прогоняй послідовно (крок 2).
 
-Запускай воркспейси **по черзі, НЕ паралельно**: dev-сервери конфліктують за портами, а послідовний прогон дає однозначну причину краху.
+### 2. Прогнати `start` кожного воркспейсу — по черзі
 
-`start` буває двох типів — скіл має їх розрізняти:
+> **Не запускай `perl alarm` і не інтерпретуй exit-коди вручну.** CLI запускає процес із grace-таймаутом (крос-платформно через `spawnSync`), класифікує OK/FAIL за типом і парсить лог.
 
-- **Довгий процес** (dev-сервер, демон): успіх = процес живий через grace-період без краху. Бажано дочекатися рядка готовності в логу (`ready`, `listening`, `Local:`, `started` тощо).
-- **Короткий процес** (CLI, разова дія): успіх = вихід із кодом `0`.
-
-macOS не має `timeout` як стандартної утиліти. Обмеж час через `perl` + `alarm`: `alarm` зводить SIGALRM, а `exec` зберігає той самий PID, тож таймер спрацьовує на справжньому процесі й знімає його після grace-періоду:
+Для кожного воркспейсу з `hasStart:true` (**по одному, НЕ паралельно** — dev-сервери конфліктують за портами):
 
 ```bash
-cd <workspace-dir>
-perl -e 'alarm shift; exec @ARGV' 12 bun run start > /tmp/n-start-check.log 2>&1
-CODE=$?
+n-cursor start-check run <workspace>   # напр. demo  (--grace <ms>, дефолт 12000)
 ```
 
-Інтерпретація `CODE`:
-
-- `142` — процес дожив до кінця grace-періоду й був знятий SIGALRM (`128 + 14`). Для **довгого процесу** (dev-сервер) це **успіх** — стартував і не впав.
-- `0` — процес завершився сам без помилки. Для **короткого процесу** (CLI, разова дія) це **успіх**.
-- будь-що інше — **FAIL**: крах або ненульовий вихід ще до кінця grace-періоду.
-
-Звір також лог: для dev-сервера — рядок готовності (`ready`, `listening`, `Local:`); для CLI — відсутність трас помилок.
-
-Альтернатива `cd` — `bun run --filter '<package-name>' start` (запуск за іменем пакета).
+Друкує JSON:
 
-`bun run start` прибирає свій дочірній процес при завершенні; якщо `start` у репо форкає демонів окремо — переконайся, що після перевірки нічого не лишилось висіти.
-
-### 5. Відкотити побічні ефекти прогону
+```
+{ workspace, type, exitCode, timedOut, status, ready, firstError, logTail, sideEffects }
+```
 
-Після кожного запуску звір поточний `git status --porcelain` зі знімком `/tmp/n-start-check.before` і відкоти **лише те, що з'явилося через прогін**:
+- `status: "OK"` — server дожив до кінця grace (`timedOut`) або встиг віддати рядок готовності; cli вийшов із кодом `0`.
+- `status: "FAIL"` — крах/ненульовий код до grace. `firstError` + `logTail` — для діагностики.
+- `sideEffects: { newFiles, changedTracked }` — read-only git-diff проти стану до запуску (для кроку 3).
 
-- нові невідстежувані файли/директорії (яких не було у знімку) — видали;
-- відстежувані файли, що стали зміненими, а у знімку були чисті — `git checkout -- <path>`;
-- усе, що було брудним **до** прогону, — НЕ чіпай: це зміни користувача, не пов'язані з прогоном.
+Розрізняй **помилку коду** (синтаксис, відсутній імпорт, падіння на ініціалізації) і **середовищний збій** (немає `.env`, недоступна БД/порт зайнятий) — останній не означає, що проєкт зламаний.
 
-Gitignored-артефакти (кеші, `node_modules`, логи) у `git status` не з'являються — їх чіпати не треба. Коли побічні ефекти прибрано, дерево повертається до стану знімка, тож наступний воркспейс стартує з чистої бази.
+### 3. Відкотити побічні ефекти прогону
 
-### 6. Зафіксувати результат
+CLI **не** мутує дерево сам (відкат — деструктивний, лишається явним). Якщо `run` повернув непорожній `sideEffects`, відкоти **лише те, що зʼявилося через прогін**, перш ніж запускати наступний воркспейс:
 
-Для кожного воркспейсу — статус і примітка:
+- `sideEffects.newFiles` — нові невідстежувані файли/директорії → видали (`rm`);
+- `sideEffects.changedTracked` — відстежувані файли, що стали зміненими → `git checkout -- <path>`.
 
-- `OK` — стартував (живий dev-сервер або вихід `0`).
-- `FAIL` — крах або ненульовий код. Додай витяг із логу: останні значущі рядки з помилкою.
-- `SKIP` — у воркспейсі немає `start`-скрипта (крок 2). Сам запуск `start` не пропускається.
+Усе, що було брудним **до** прогону, у `sideEffects` не потрапляє (CLI рахує лише різницю) — зміни користувача не чіпай. Gitignored-артефакти (кеші, `node_modules`) у git-diff не зʼявляються.
 
-Якщо мутаційний `start` лишив побічні ефекти (крок 5) — познач це в примітці: проєкт стартує, але `start` не є чистим запуском сервера.
+### 4. Звіт
 
-Розрізняй у звіті **помилку коду** (синтаксис, відсутній імпорт, падіння при ініціалізації) і **середовищний збій** (немає `.env`, недоступна БД/сервіс, зайнятий порт) — останній не означає, що проєкт зламаний.
+Підсумкова таблиця: `воркспейс | статус | примітка`, з даних `scan` + `run`:
 
-### 7. Звіт
+- `OK` — `status:"OK"` (живий dev-сервер або вихід `0`).
+- `FAIL` — `status:"FAIL"`; додай `firstError` / `logTail`.
+- `SKIP` — `hasStart:false`.
 
-Підсумкова таблиця: `воркспейс | статус | примітка`. Якщо є хоч один `FAIL` — винеси його окремо й покажи помилку повністю.
+Якщо `run` повернув непорожній `sideEffects` — познач у примітці: проєкт стартує, але `start` не є чистим запуском (мутує репо). Якщо є хоч один `FAIL` — винеси його окремо з повною помилкою.
 
 Скіл лише **діагностує** запуск. Виправлення коду — поза скоупом; якщо причина FAIL очевидна, познач її у звіті, але не правь, поки про це не попросять окремо.

package/skills/start-check/js/check.mjs

@@ -0,0 +1,211 @@
+/**
+ * `n-cursor start-check scan|run` — детермінована частина smoke-перевірки
+ * bun-монорепо для скілу `n-start-check`.
+ *
+ * Мотивація: скіл раніше казав LLM-агенту вручну розгортати glob-воркспейси,
+ * читати кожен `package.json`, класифікувати `start` (сервер vs CLI), запускати
+ * процес із таймаутом через `perl alarm`, інтерпретувати exit-коди й парсити лог
+ * на рядки готовності/помилки. Усе це детерміновано — скрипт робить це надійно й
+ * крос-платформно (`spawnSync` з `timeout`), а агент лишається тільки з
+ * діагностикою: **чому** саме воркспейс упав.
+ *
+ * `scan` — `[{workspace, name, hasStart, startCmd, type}]`.
+ * `run <ws>` — `{workspace, type, exitCode, timedOut, status, ready, firstError,
+ * logTail, sideEffects}` (sideEffects — read-only git-diff проти стану до запуску;
+ * власне відкат лишається явним кроком скіла).
+ */
+import { spawnSync } from 'node:child_process'
+import { existsSync } from 'node:fs'
+import { readFile } from 'node:fs/promises'
+import { join } from 'node:path'
+
+import { getMonorepoPackageRootDirs } from '../../../scripts/lib/workspaces.mjs'
+
+/** Маркери довгого процесу (dev-сервер/демон) у команді `start`. */
+const SERVER_CMD_RE = /\b(vite|next|nuxt|nodemon|serve|astro|remix|webpack-dev-server|http-server)\b|\bdev\b|--watch/
+/** Рядки готовності dev-сервера в логу (`\b` лише де треба — щоб «already» не матчив «ready»). */
+const READY_RE = /\bready\b|\blistening\b|\bstarted\b|\bcompiled\b|server running|local:/i
+/** Сигнатури помилок у логу. */
+const ERROR_RE = /(error|exception|fatal|cannot find|module not found|unhandled|panic|traceback)/i
+/** Скільки останніх рядків логу повертати. */
+const LOG_TAIL_LINES = 15
+
+/**
+ * Класифікує `start`-команду: довгий процес (сервер) чи разова дія (CLI).
+ * @param {string} startCmd значення `scripts.start`
+ * @returns {'server'|'cli'} тип процесу
+ */
+export function classifyStartType(startCmd) {
+  return typeof startCmd === 'string' && SERVER_CMD_RE.test(startCmd) ? 'server' : 'cli'
+}
+
+/**
+ * Зчитує `package.json` воркспейсу або повертає null.
+ * @param {string} dir абсолютний шлях до каталогу воркспейсу
+ * @returns {Promise<object|null>} розпарсений package.json або null
+ */
+async function readPkg(dir) {
+  const path = join(dir, 'package.json')
+  if (!existsSync(path)) return null
+  try {
+    return JSON.parse(await readFile(path, 'utf8'))
+  } catch {
+    return null
+  }
+}
+
+/**
+ * Сканує монорепо: для кожного воркспейсу — чи є `start`, його команда і тип.
+ * @param {string} cwd корінь репозиторію
+ * @returns {Promise<Array<{workspace:string, name:string|null, hasStart:boolean, startCmd:string|null, type:('server'|'cli'|null)}>>} список воркспейсів
+ */
+export async function scanStartWorkspaces(cwd) {
+  const roots = await getMonorepoPackageRootDirs(cwd)
+  const out = []
+  for (const ws of roots) {
+    const pkg = await readPkg(join(cwd, ws))
+    const startCmd = pkg?.scripts?.start ?? null
+    const hasStart = typeof startCmd === 'string' && startCmd.length > 0
+    out.push({
+      workspace: ws,
+      name: pkg?.name ?? null,
+      hasStart,
+      startCmd: hasStart ? startCmd : null,
+      type: hasStart ? classifyStartType(startCmd) : null
+    })
+  }
+  return out
+}
+
+/**
+ * Парсить лог процесу: готовність (сервер), перша помилка, хвіст.
+ * @param {string} log обʼєднаний stdout+stderr
+ * @returns {{ready:boolean, firstError:string|null, logTail:string}} витяг
+ */
+export function parseStartLog(log) {
+  const text = log ?? ''
+  const lines = text.split('\n')
+  const firstError = lines.find(l => ERROR_RE.test(l))?.trim() ?? null
+  const logTail = lines
+    .filter(l => l.trim() !== '')
+    .slice(-LOG_TAIL_LINES)
+    .join('\n')
+  return { ready: READY_RE.test(text), firstError, logTail }
+}
+
+/**
+ * Read-only знімок `git status --porcelain` як множина рядків.
+ * @param {string} cwd корінь репозиторію
+ * @returns {Set<string>} рядки porcelain (статус + шлях)
+ */
+function gitPorcelain(cwd) {
+  const res = spawnSync('git', ['status', '--porcelain'], { cwd, encoding: 'utf8' })
+  if (res.status !== 0 || typeof res.stdout !== 'string') return new Set()
+  return new Set(res.stdout.split('\n').filter(l => l.trim() !== ''))
+}
+
+/**
+ * Обчислює побічні ефекти прогону як різницю git-станів до/після.
+ * @param {Set<string>} before знімок до
+ * @param {Set<string>} after знімок після
+ * @returns {{newFiles:string[], changedTracked:string[]}} нові untracked і ново-змінені tracked шляхи
+ */
+function diffSideEffects(before, after) {
+  const newFiles = []
+  const changedTracked = []
+  for (const line of after) {
+    if (before.has(line)) continue
+    const path = line.slice(3)
+    if (line.startsWith('??')) newFiles.push(path)
+    else changedTracked.push(path)
+  }
+  return { newFiles, changedTracked }
+}
+
+/**
+ * Запускає `start` одного воркспейсу з grace-таймаутом і класифікує результат.
+ * @param {string} cwd корінь репозиторію
+ * @param {string} workspace відносний шлях воркспейсу
+ * @param {{graceMs?:number, type?:('server'|'cli'), spawnImpl?:Function}} [opts] grace-період, тип (інакше з package.json), інʼєкція spawn для тестів
+ * @returns {Promise<{workspace:string, type:string, exitCode:number|null, timedOut:boolean, status:('OK'|'FAIL'), ready:boolean, firstError:string|null, logTail:string, sideEffects:{newFiles:string[], changedTracked:string[]}}>} результат прогону
+ */
+export async function runWorkspaceStart(cwd, workspace, opts = {}) {
+  const { graceMs = 12_000, spawnImpl = spawnSync } = opts
+  const dir = join(cwd, workspace)
+  const pkg = await readPkg(dir)
+  const startCmd = pkg?.scripts?.start
+  if (typeof startCmd !== 'string' || startCmd.length === 0) {
+    throw new Error(`У воркспейсі ${workspace} немає scripts.start`)
+  }
+  const type = opts.type ?? classifyStartType(startCmd)
+
+  const before = gitPorcelain(cwd)
+  const res = spawnImpl('bun', ['run', 'start'], {
+    cwd: dir,
+    encoding: 'utf8',
+    timeout: graceMs,
+    killSignal: 'SIGTERM'
+  })
+  const timedOut = res.error?.code === 'ETIMEDOUT' || res.signal === 'SIGTERM'
+  const exitCode = typeof res.status === 'number' ? res.status : null
+  const { ready, firstError, logTail } = parseStartLog(`${res.stdout ?? ''}${res.stderr ?? ''}`)
+
+  // server: успіх = дожив до кінця grace (timedOut) або встиг віддати рядок готовності.
+  // cli: успіх = чистий вихід 0 у межах grace.
+  const status = type === 'server' ? (timedOut || ready ? 'OK' : 'FAIL') : exitCode === 0 ? 'OK' : 'FAIL'
+
+  return {
+    workspace,
+    type,
+    exitCode,
+    timedOut,
+    status,
+    ready,
+    firstError,
+    logTail,
+    sideEffects: diffSideEffects(before, gitPorcelain(cwd))
+  }
+}
+
+const USAGE = 'Usage: n-cursor start-check <scan | run <workspace> [--grace <ms>]>'
+
+/**
+ * CLI: `scan` друкує список воркспейсів зі `start`; `run <ws>` запускає один і
+ * друкує класифікований результат. Обидва — JSON у stdout.
+ * @param {string[]} args аргументи після `start-check`
+ * @param {string} [cwd] корінь репозиторію (інʼєкція для тестів)
+ * @returns {Promise<number>} exit code
+ */
+export async function runStartCheckCli(args, cwd = process.cwd()) {
+  const sub = args[0]
+
+  if (sub === 'scan') {
+    process.stdout.write(`${JSON.stringify(await scanStartWorkspaces(cwd))}\n`)
+    return 0
+  }
+
+  if (sub === 'run') {
+    const workspace = args[1] && !args[1].startsWith('--') ? args[1] : undefined
+    if (!workspace) {
+      console.error(USAGE)
+      return 1
+    }
+    const graceAt = args.indexOf('--grace')
+    const graceMs = graceAt === -1 ? undefined : Number(args[graceAt + 1])
+    if (graceAt !== -1 && (!Number.isFinite(graceMs) || graceMs <= 0)) {
+      console.error('✗ --grace очікує додатнє число (мс)')
+      return 1
+    }
+    try {
+      const result = await runWorkspaceStart(cwd, workspace, graceMs ? { graceMs } : {})
+      process.stdout.write(`${JSON.stringify(result)}\n`)
+      return 0
+    } catch (error) {
+      console.error(`✗ ${error.message}`)
+      return 1
+    }
+  }
+
+  console.error(USAGE)
+  return 1
+}

package/skills/taze/SKILL.md

@@ -43,9 +43,15 @@ bun install
 
 ### 3. Виявити major-оновлення
 
-Порівняти `package.json.taze-bak` з оновленим `package.json` (а також `bun.lock.taze-bak` ↔ `bun.lock` для транзитивних). Для кожної залежності, у якої змінилась перша значуща цифра semver (`1.x.x → 2.x.x`, `0.4.x → 0.5.x`, `0.0.x → 0.1.x`) — додати в список «потребує перевірки».
+> **Не порівнюй `package.json` вручну.** Класифікацію semver несе CLI — детерміновано, по всіх воркспейсах.
 
-Minor/patch — пропускати, їх вважаємо сумісними.
+```bash
+n-cursor taze diff
+```
+
+Друкує компактний JSON: `{ "major": [{workspace, pkg, from, to}], "minorPatch": <N>, "totalChanged": <N> }`. `major` — список залежностей, у яких змінилась найлівіша ненульова компонента semver (`1.x→2.x`, `0.4.x→0.5.x`, `0.0.3→0.0.4`); саме він іде в кроки 4–6. `minorPatch` — лічба сумісних (для звіту в кроці 8).
+
+Покриває **прямі** залежності з `package.json` (root + воркспейси). Транзитивні major-стрибки (`bun.lock`) — за потреби переглянь окремо; основний ризик breaking-змін — у прямих.
 
 ### 4. Зібрати breaking changes по кожному major-оновленню
 
@@ -94,7 +100,7 @@ rm package.json.taze-bak bun.lock.taze-bak
 
 Коротко в одному повідомленні:
 
-- **Оновлено (minor/patch):** кількість пакетів, без деталей.
+- **Оновлено (minor/patch):** кількість пакетів (`minorPatch` із кроку 3), без деталей.
 - **Major-оновлення:** список `<name>: <old> → <new>` з посиланням на release notes.
 - **Зрефакторено автоматично:** список файлів і коротко що саме змінено.
 - **Потребує ручного втручання:** список TODO з причиною (нетривіальна міграція / неоднозначність / падіння тестів).

package/skills/taze/js/diff.mjs

@@ -0,0 +1,154 @@
+/**
+ * `n-cursor taze diff` — read-only детермінований diff версій залежностей між
+ * `package.json` і його бекапом `package.json.taze-bak` (root + усі воркспейси
+ * монорепо), із класифікацією кожної зміни за semver.
+ *
+ * Мотивація: скіл `n-taze` раніше казав LLM-агенту вручну порівнювати backup із
+ * новим `package.json` по всіх воркспейсах і вирішувати, де «змінилась перша
+ * значуща цифра semver» (major). Це детермінований JSON-diff + semver-логіка —
+ * скрипт робить це за мілісекунди й без помилок, а агент отримує готовий список
+ * major-оновлень для справді когнітивної роботи (читання CHANGELOG, рефакторинг).
+ *
+ * «Breaking» (major) рахуємо за caret-семантикою — змінилась найлівіша ненульова
+ * компонента: `1.x→2.x`, `0.4.x→0.5.x`, `0.0.3→0.0.4`. Minor/patch вважаємо
+ * сумісними.
+ */
+import { existsSync } from 'node:fs'
+import { readFile } from 'node:fs/promises'
+import { join } from 'node:path'
+
+import { getMonorepoPackageRootDirs } from '../../../scripts/lib/workspaces.mjs'
+
+/** Поля package.json із залежностями, які порівнюємо. */
+const DEP_FIELDS = ['dependencies', 'devDependencies', 'peerDependencies', 'optionalDependencies']
+
+/** Дефолтний суфікс бекапу, який створює крок 1 скіла (`cp package.json package.json.taze-bak`). */
+const DEFAULT_BACKUP_SUFFIX = '.taze-bak'
+
+// Заякорено на початок (після можливих range-операторів `^~>=<`, пробілів, `v`),
+// щоб НЕ ловити версію всередині protocol-specifier-ів (`workspace:1.0.0`, `npm:x@1.2.3`).
+const SEMVER_RE = /^[\s~^>=<v]*(\d+)\.(\d+)\.(\d+)/
+
+/**
+ * Парсить semver-ядро зі specifier-а (ігнорує range-префікси `^`/`~`/`>=` тощо).
+ * @param {string} spec версійний specifier із package.json
+ * @returns {{major:number, minor:number, patch:number}|null} ядро або null для не-semver (`workspace:*`, git-url, `*`)
+ */
+export function parseVersion(spec) {
+  if (typeof spec !== 'string') return null
+  const m = SEMVER_RE.exec(spec)
+  if (!m) return null
+  return { major: Number(m[1]), minor: Number(m[2]), patch: Number(m[3]) }
+}
+
+/**
+ * Чи є перехід `from → to` breaking за caret-семантикою (змінилась найлівіша
+ * ненульова компонента).
+ * @param {{major:number,minor:number,patch:number}} from стара версія
+ * @param {{major:number,minor:number,patch:number}} to нова версія
+ * @returns {boolean} true — major/breaking
+ */
+export function isBreaking(from, to) {
+  if (from.major !== to.major) return true
+  if (from.major > 0) return false
+  if (from.minor !== to.minor) return true
+  if (from.minor > 0) return false
+  return from.patch !== to.patch
+}
+
+/**
+ * Порівнює два package.json-обʼєкти й повертає зміни залежностей.
+ * @param {object} oldPkg розпарсений старий package.json (бекап)
+ * @param {object} newPkg розпарсений новий package.json
+ * @param {string} workspace мітка воркспейсу (`.` для кореня)
+ * @returns {{major: Array<{workspace:string, pkg:string, from:string, to:string}>, minorPatch:number}} зміни
+ */
+export function diffPackageJson(oldPkg, newPkg, workspace) {
+  const major = []
+  let minorPatch = 0
+  for (const field of DEP_FIELDS) {
+    const oldDeps = oldPkg?.[field]
+    const newDeps = newPkg?.[field]
+    if (!oldDeps || !newDeps) continue
+    for (const [pkg, from] of Object.entries(oldDeps)) {
+      const to = newDeps[pkg]
+      if (to === undefined || to === from) continue
+      const fromV = parseVersion(from)
+      const toV = parseVersion(to)
+      if (fromV && toV && isBreaking(fromV, toV)) {
+        major.push({ workspace, pkg, from, to })
+      } else {
+        minorPatch += 1
+      }
+    }
+  }
+  return { major, minorPatch }
+}
+
+/**
+ * Читає JSON-файл або повертає null, якщо файл відсутній / невалідний.
+ * @param {string} path абсолютний шлях
+ * @returns {Promise<object|null>} розпарсений обʼєкт або null
+ */
+async function readJsonOrNull(path) {
+  if (!existsSync(path)) return null
+  try {
+    return JSON.parse(await readFile(path, 'utf8'))
+  } catch {
+    return null
+  }
+}
+
+/**
+ * Збирає diff по всьому монорепо: для кожного воркспейсу порівнює
+ * `<ws>/package.json` з `<ws>/package.json<backupSuffix>`.
+ * @param {string} cwd корінь репозиторію
+ * @param {string} [backupSuffix] суфікс бекап-файлу
+ * @returns {Promise<{major: Array<{workspace:string, pkg:string, from:string, to:string}>, minorPatch:number, totalChanged:number, comparedWorkspaces:number}>} агрегований diff
+ */
+export async function collectTazeDiff(cwd, backupSuffix = DEFAULT_BACKUP_SUFFIX) {
+  const roots = await getMonorepoPackageRootDirs(cwd)
+  const major = []
+  let minorPatch = 0
+  let comparedWorkspaces = 0
+  for (const ws of roots) {
+    const dir = join(cwd, ws)
+    const oldPkg = await readJsonOrNull(join(dir, `package.json${backupSuffix}`))
+    const newPkg = await readJsonOrNull(join(dir, 'package.json'))
+    if (!oldPkg || !newPkg) continue
+    comparedWorkspaces += 1
+    const res = diffPackageJson(oldPkg, newPkg, ws)
+    major.push(...res.major)
+    minorPatch += res.minorPatch
+  }
+  return { major, minorPatch, totalChanged: major.length + minorPatch, comparedWorkspaces }
+}
+
+const USAGE = 'Usage: n-cursor taze diff [--backup-suffix <suffix>]'
+
+/**
+ * CLI: `n-cursor taze diff` друкує компактний JSON зі списком major-оновлень і
+ * лічбою minor/patch. Read-only.
+ * @param {string[]} args аргументи після `taze`
+ * @param {string} [cwd] корінь репозиторію (ін'єкція для тестів)
+ * @returns {Promise<number>} exit code
+ */
+export async function runTazeCli(args, cwd = process.cwd()) {
+  if (args[0] !== 'diff') {
+    console.error(USAGE)
+    return 1
+  }
+  const flagAt = args.indexOf('--backup-suffix')
+  const backupSuffix = flagAt === -1 ? DEFAULT_BACKUP_SUFFIX : args[flagAt + 1]
+  if (!backupSuffix) {
+    console.error(USAGE)
+    return 1
+  }
+  const diff = await collectTazeDiff(cwd, backupSuffix)
+  if (diff.comparedWorkspaces === 0) {
+    console.error(`✗ Не знайдено жодного package.json${backupSuffix} — спершу зроби бекап (крок 1 скіла).`)
+    return 1
+  }
+  process.stdout.write(`${JSON.stringify(diff)}\n`)
+  return 0
+}

package/types/bin/n-cursor.d.ts

@@ -1,2 +1,2 @@
 #!/usr/bin/env node
-export {};
+export {}

package/skills/fix-tests/SKILL.md

@@ -1,119 +0,0 @@
----
-name: n-fix-tests
-description: >-
-  Ітеративно дописати тести щоб підвищити mutation score — читає вцілілі мутанти з COVERAGE.md і запускає агент до конвергенції
----
-
-# n-fix-tests — підвищення mutation score
-
-## Мета
-
-Читає структурований JSON-блок вцілілих мутантів з `COVERAGE.md` і ітеративно дописує тести що їх вловлюють. Зупиняється коли score перестає покращуватись (конвергенція).
-
-## Передумови
-
-- У `COVERAGE.md` є секція `## Вцілілі мутанти` з JSON-блоком
-- Залежності встановлені (`bun i`)
-- `bun run coverage` (або `n-cursor coverage`) доступний
-
-## Workflow
-
-### Крок 1: Зчитай вцілілих мутантів
-
-Прочитай `COVERAGE.md`. Знайди секцію `## Вцілілі мутанти`. Знайди огороджений блок ` ```json ` у цій секції і розбери JSON-масив.
-
-Якщо секція відсутня або масив порожній — зупинись з повідомленням:
-`✓ Жодних вцілілих мутантів — mutation score повний`
-
-Запамʼятай поточну кількість вцілілих: `prevCount = масив.length`
-
-### Крок 2: Знайди test-команду і coverage-команду
-
-Прочитай `package.json` у кореневій директорії.
-
-**test-команда** (перша що існує):
-
-1. `scripts["test"]` з `package.json`
-2. fallback: `bun test`
-
-**coverage-команда** (перша що існує):
-
-1. `scripts["coverage"]` з `package.json` → виклик: `bun run coverage`
-2. fallback: `n-cursor coverage`
-
-### Крок 3: Для кожного файлу — запускає Agent
-
-Згрупуй мутанти по полю `file`. Для кожної групи виконай:
-
-**3a. Знайди / визнач test файл (завжди у `tests/` директорії):**
-
-Цільовий файл завжди: `<dir>/tests/<basename>.test.mjs`
-(де `<dir>` — директорія source-файлу, `<basename>` — ім'я без розширення)
-
-- Source: `<cwd>/<file>` (прочитай вміст)
-- Test файл:
-  1. Якщо `<dir>/tests/<basename>.test.mjs` існує → використай його
-  2. Якщо `<dir>/<basename>.test.js` або `<dir>/<basename>.test.mjs` існує (co-located) →
-     - Перенеси файл до `<dir>/tests/<basename>.test.mjs`
-     - Оновити відносні `import` шляхи якщо є (тепер треба `../` рівень вгору)
-  3. Якщо жоден не знайдено → буде створено `<dir>/tests/<basename>.test.mjs`
-
-**3b. Сформуй промпт для Agent:**
-
-```
-Тобі дані вцілілі мутанти зі Stryker для файлу `<file>`.
-Ці мутанти вціліли, тому що наявні тести НЕ вловили конкретні зміни коду.
-
-**Вихідний код** (`<file>`):
-\`\`\`
-<зміст source-файлу>
-\`\`\`
-
-**Наявні тести** (`<test-file>`):
-\`\`\`
-<зміст test-файлу або "файл ще не існує">
-\`\`\`
-
-**Вцілілі мутанти** (кожен — зміна коду що НЕ вловлена):
-<для кожного мутанта:>
-- Рядок <line>, колонка <col>: `<original>` → `<replacement>` (тип мутації: <mutantType>)
-
-**Завдання:**
-Допиши мінімальні test-cases у файл `<test-file>` які б вловили кожен із перелічених мутантів.
-Правила:
-- НЕ видаляй і НЕ змінюй наявні тести
-- Стиль тестів — відповідно до наявного файлу (той самий фреймворк, той самий стиль describe/test)
-- Якщо файл ще не існує — створи `<dir>/tests/<basename>.test.mjs` з правильними імпортами.
-  Приклад: source `src/services/auth-store.js` → test `src/services/tests/auth-store.test.mjs`,
-  import: `import { ... } from '../auth-store.js'`
-- Після написання запусти: `bun test <test-file>` і переконайся що всі тести проходять (виправ якщо падають)
-```
-
-**3c. Запусти Agent** з цим промптом і дочекайся завершення.
-
-### Крок 4: Перевір що всі тести проходять
-
-```bash
-bun test  # або test-команда з кроку 2
-```
-
-Якщо тести падають — поверни конкретний Agent (для того файлу) з помилкою і попроси виправити.
-
-### Крок 5: Запусти coverage і порівняй
-
-```bash
-bun run coverage  # або coverage-команда з кроку 2
-```
-
-Прочитай новий `COVERAGE.md`, знайди і розбери JSON-масив вцілілих.
-`newCount = новий масив.length`
-
-**Рішення:**
-
-- Якщо `newCount < prevCount` → повтор з Кроку 1 з оновленим масивом
-- Якщо `newCount >= prevCount` → зупинись:
-  `✓ Конвергенція: mutation score більше не покращується. Вціліло: <newCount> мутантів.`
-
-## Зупинка після конвергенції
-
-Конвергенція — нормальний результат. Деякі мутанти не можна вбити (захищений зовнішнім станом, недетермінована логіка тощо). Не намагайся виправити те що не змінилось після ітерації.

package/skills/fix-tests/meta.json

@@ -1 +0,0 @@
-{ "auto": ["js-lint"], "worktree": true }