s-skillkit 0.2.2__tar.gz → 0.3.2__tar.gz

{s_skillkit-0.2.2 → s_skillkit-0.3.2}/.gitignore

@@ -1,50 +1,50 @@
-# === atlas universal gitignore ===
-
-# OS / IDE
-.DS_Store
-Thumbs.db
-.vscode/
-.idea/
-*.swp
-*.swo
-
-# Sensitive
-.env
-.env.local
-*.key
-*.pem
-secrets/
-private/
-
-# Python
-__pycache__/
-*.py[cod]
-.venv/
-venv/
-.pytest_cache/
-.ruff_cache/
-*.egg-info/
-
-# Node / JS
-node_modules/
-.next/
-dist/
-build/
-
-# Temporary / large
-*.log
-*.tmp
-nul
-NUL
-*.zip
-*.rar
-*.7z
-
-# Media (selectively unignore via !path/*.ext if needed for fixtures)
-*.mp4
-*.mov
-*.avi
-*.mkv
+# === atlas universal gitignore ===
+
+# OS / IDE
+.DS_Store
+Thumbs.db
+.vscode/
+.idea/
+*.swp
+*.swo
+
+# Sensitive
+.env
+.env.local
+*.key
+*.pem
+secrets/
+private/
+
+# Python
+__pycache__/
+*.py[cod]
+.venv/
+venv/
+.pytest_cache/
+.ruff_cache/
+*.egg-info/
+
+# Node / JS
+node_modules/
+.next/
+dist/
+build/
+
+# Temporary / large
+*.log
+*.tmp
+nul
+NUL
+*.zip
+*.rar
+*.7z
+
+# Media (selectively unignore via !path/*.ext if needed for fixtures)
+*.mp4
+*.mov
+*.avi
+*.mkv
 
 # git worktrees (агентские)
-.worktrees/
+.worktrees/

s_skillkit-0.3.2/.gitlab-ci.yml

@@ -0,0 +1,31 @@
+# Автопубликация на PyPI по семвер-тегу vX.Y.Z через Trusted Publishing (OIDC).
+# Токены НИГДЕ не хранятся: GitLab выдаёт короткоживущий OIDC-токен (PYPI_ID_TOKEN),
+# он одноразово обменивается на PyPI API-токен. Издатель настраивается на pypi.org:
+#   Manage -> Publishing -> GitLab  (namespace=S-kits, project=skillkit,
+#   top-level pipeline file=.gitlab-ci.yml, environment — пусто).
+# Запускается ТОЛЬКО на тег vX.Y.Z (обычный push на main ничего не публикует).
+stages: [publish]
+
+publish-pypi:
+  stage: publish
+  image: ghcr.io/astral-sh/uv:python3.12-bookworm
+  rules:
+    - if: $CI_COMMIT_TAG =~ /^v\d+\.\d+\.\d+$/
+  id_tokens:
+    PYPI_ID_TOKEN:
+      aud: pypi
+  script:
+    - uv build
+    # обмен GitLab OIDC -> одноразовый PyPI API-токен (Trusted Publishing):
+    - |
+      export UV_PUBLISH_TOKEN=$(python3 - <<'PY'
+      import json, os, urllib.request
+      req = urllib.request.Request(
+          "https://pypi.org/_/oidc/mint-token",
+          data=json.dumps({"token": os.environ["PYPI_ID_TOKEN"]}).encode(),
+          headers={"Content-Type": "application/json"},
+      )
+      print(json.load(urllib.request.urlopen(req))["token"])
+      PY
+      )
+    - uv publish

{s_skillkit-0.2.2 → s_skillkit-0.3.2}/AGENTS.md

@@ -1,45 +1,45 @@
-# AGENTS.md — skillkit
-
-> Контекст для AI-ассистентов (Claude Code, ChatGPT, Cursor и т.п.), работающих
-> над этим проектом.
-
-## Что это
-
-(заполнить one-line)
-
-## Atlas
-
-Проект зарегистрирован в Atlas-БД (Atlas). Карточка:
-
-```sh
-atlas projects get skillkit
-```
-
-Любые изменения метаданных (приоритет, статус, теги) — через atlas CLI:
-
-- `atlas projects update skillkit --priority P0` — поменять приоритет
-- `atlas add-tags skillkit -t domain:<slug>` — добавить тег
-- `atlas projects move skillkit --to-type <type>` — конвертировать тип
-
-## Тип / Статус (на момент создания)
-
-- type=`kit`, status=`experiment`, priority=`P1`
-
-## Правила работы
-
-- Все исходные тексты, документы, код проекта — в этом репо.
-- Чувствительные данные (`.env`, токены, ключи) — игнорируются `.gitignore`.
-- AI-ассистенту разрешено: читать, генерировать, редактировать в этом репо.
-
-## Канонические команды
-
-- `atlas projects get skillkit` — карточка проекта
-- `atlas task list --project skillkit` — задачи проекта (когда W7
-  волна будет реализована)
-
-<!-- atlas:usage:start -->
-## Управление проектом — через Atlas
-
-Этот проект ведётся в Atlas (личная PM-система портфеля). Для задач/проектов/эпиков/бэкапов
-используй CLI `atlas` и вызывай навык `atlas` — вся логика и роутинг внутри навыка.
-<!-- atlas:usage:end -->
+# AGENTS.md — skillkit
+
+> Контекст для AI-ассистентов (Claude Code, ChatGPT, Cursor и т.п.), работающих
+> над этим проектом.
+
+## Что это
+
+(заполнить one-line)
+
+## Atlas
+
+Проект зарегистрирован в Atlas-БД (Atlas). Карточка:
+
+```sh
+atlas projects get skillkit
+```
+
+Любые изменения метаданных (приоритет, статус, теги) — через atlas CLI:
+
+- `atlas projects update skillkit --priority P0` — поменять приоритет
+- `atlas add-tags skillkit -t domain:<slug>` — добавить тег
+- `atlas projects move skillkit --to-type <type>` — конвертировать тип
+
+## Тип / Статус (на момент создания)
+
+- type=`kit`, status=`experiment`, priority=`P1`
+
+## Правила работы
+
+- Все исходные тексты, документы, код проекта — в этом репо.
+- Чувствительные данные (`.env`, токены, ключи) — игнорируются `.gitignore`.
+- AI-ассистенту разрешено: читать, генерировать, редактировать в этом репо.
+
+## Канонические команды
+
+- `atlas projects get skillkit` — карточка проекта
+- `atlas task list --project skillkit` — задачи проекта (когда W7
+  волна будет реализована)
+
+<!-- atlas:usage:start -->
+## Управление проектом — через Atlas
+
+Этот проект ведётся в Atlas (личная PM-система портфеля). Для задач/проектов/эпиков/бэкапов
+используй CLI `atlas` и вызывай навык `atlas` — вся логика и роутинг внутри навыка.
+<!-- atlas:usage:end -->

s_skillkit-0.3.2/CHANGELOG.md

@@ -0,0 +1,329 @@
+# Changelog
+
+Все заметные изменения кита `s-skillkit` фиксируются здесь. Формат близок к
+[Keep a Changelog](https://keepachangelog.com/ru/1.1.0/); версионирование —
+[SemVer](https://semver.org/lang/ru/).
+
+## [0.3.1] — 2026-07-21
+
+Круг 3 независимой проверки нашёл два настоящих дефекта в правках 0.3.0 и один
+того же класса рядом. Все три — про уничтожение чужого, которого кит не ставил.
+
+### Fixed — гейт принадлежности стал свойством ОПЕРАЦИИ, а не команды
+
+- **ДЕФЕКТ A — обход гейта через `migrate_scope`.** В 0.3.0 проверка «удаляем
+  только своё» стояла внутри `remove`. Гейт, привязанный к КОМАНДЕ, обходила
+  соседняя команда: `migrate_scope` звала `_link_into_scope(..., force=True)`, а
+  тот безусловным `_force_rmtree` сносил каталог, стоящий на месте будущей
+  ссылки. Воспроизведено: наша copy в `~/.codex/skills/notebooklm` + ЧУЖОЙ
+  `~/.agents/skills/notebooklm` → после `migrate_scope` чужой payload уничтожен,
+  канон заменён junction'ом. Лечение — не затыкание `migrate_scope`, а сведение
+  ВСЕГО разрушения к одному входу `skillkit.installer.ownership.PathGuard`,
+  который сам проверяет улику принадлежности. `migrate_scope` больше не
+  подставляет `force`: занятый чужим канон отменяет миграцию навыка целиком (в
+  `failed`), обе стороны на диске целы. Обойти гейт нельзя ПО ПОСТРОЕНИЮ:
+  разрушение в зоне агента доступно только через `destroy_in_scope` /
+  `clear_for_link` / `take_into_store` (каждый зовёт `assert_ours`), в
+  собственной зоне кита — через `destroy_in_store` / `swap_in_store` (требуют,
+  чтобы путь лежал ВНУТРИ стора). Стережёт архитектурный тест: он читает AST
+  пакета и запрещает прямые `_force_rmtree` / `move` / `remove_link` / `os.replace`
+  вне узкого списка модулей — новая команда физически не повторит дефект.
+- **ДЕФЕКТ B — осиротевший `~/.antigravity/skills`.** Выпущенный тег `v0.2.1`
+  ставил навыки agy в `~/.antigravity/skills` (`git show v0.2.1:…/antigravity.py`
+  — `dirname = ".antigravity"`); коммит 067c840 объявил путь legacy, 4d093a2 убрал
+  совсем, и на момент круга 3 `AntigravityTarget.legacy_dirnames` был пуст.
+  Установки выпущенной версии стали невидимы для `status`, `remove` и
+  `migrate_scope`. Путь снова объявлен `legacy_dirnames = (".antigravity",)` —
+  это безопасно благодаря гейту (чужих соседей `google-flow` / `notebooklm` /
+  `telegram` без нашей меты не сносим). Инвариант «ни одного осиротевшего пути»
+  закрыт тестом: таблица `_EVER_WROTE` перечисляет КАЖДУЮ раскладку из истории
+  тегов и коммитов, тест требует, чтобы сегодня каждая была каноном или заявленным
+  legacy (в т.ч. project-scope наследие `<project>/.antigravity/skills`), и сам
+  ловит снятое объявление (`test_the_invariant_actually_catches_a_dropped_legacy`).
+- **Тот же класс дефекта в `mcp_register`.** `_read_config` возвращал `{}` на
+  любом не-словаре, и следом `_write_config` клал на место чужого ВАЛИДНОГО, но
+  не-объектного конфига (напр. JSON-массива пользователя) наш объект — данные
+  исчезали без предупреждения. Теперь такой конфиг даёт `status=error` и остаётся
+  нетронутым — как уже вёл себя `hook_register`. Оба писателя настроек агента
+  ведут себя одинаково.
+- **`_force_rmtree` стал link-aware**: снимает ссылку КАК ссылку и не идёт
+  внутрь. `shutil.rmtree` отсекает только POSIX-symlink, а Windows junction для
+  него — обычный каталог, и удаление уходило бы СКВОЗЬ него в цель (стор или
+  чужой каталог).
+- **Улика принадлежности — по МАРКЕРУ содержимого меты, а не по ИМЕНИ файла.**
+  `is_managed_dir` считал каталог нашим по одному лишь НАЛИЧИЮ `_skill_meta.json`,
+  без разбора. Любой посторонний инструмент, положивший файл-тёзку, попадал под
+  снос без `force`. Теперь `_build_meta` штампует устойчивый маркер
+  (`_skillkit_managed: skillkit/skill-meta/v1`, единая точка `stamp_ownership`),
+  и каталог считается нашим ТОЛЬКО по этому маркеру. Оба прежних требования
+  удовлетворены сразу: файл-тёзка чужого формата (без маркера) → каталог НЕ наш
+  (`ForeignPathError`, снос лишь через `force`); битый JSON вокруг уцелевшего
+  маркера — всё равно наш (сырая подпись как неразрушимая улика, порча остальных
+  полей неважна). Обратная совместимость для очень старых copy-установок без
+  маркера — через вторую независимую улику `PathGuard.is_ours`: ссылка в наш
+  стор (стор — доверенная зона). Маркер — версия формата, не бренд: ребрендинг
+  `set_managed_by` на него не влияет.
+- **AST-детектор разрушающих вызовов больше не обходится алиасами импортов.**
+  Архитектурный тест ловил `shutil.rmtree`/`.unlink`/голые имена, но пропускал
+  `import os as o; o.remove(p)`, `from os import remove; remove(p)` и
+  `from shutil import rmtree as rt; rt(p)` — то есть сторожил ФОРМУ записи, а не
+  инвариант. Детектор теперь разрешает алиасы импортов (`_resolve_aliases`) и
+  покрывает полный набор разрушающих имён `os` (`remove`/`unlink`/`rmdir`/
+  `replace`/`rename`) и `shutil` (`rmtree`/`move`); безобидные `str.replace` /
+  `dataclasses.replace` по-прежнему игнорируются.
+- **Круг 4 — две остаточные асимметрии «чужое → наше».** (1) `has_ownership_marker`
+  спускался к сырой подписи и при УСПЕШНО разобранном JSON: чужая мета, где наша
+  строка лежала во вложенном поле или в свободном тексте, объявлялась нашей.
+  Сырая подпись теперь — ветка ИСКЛЮЧИТЕЛЬНО для не-парсящегося файла; разобравшийся
+  JSON решает только ключом верхнего уровня. (2) AST-детектор не видел свои же
+  примитивы через модуль (`fsops._force_rmtree`, `ownership.destroy_entry`) —
+  ловил их лишь по голому имени; добавлены в ветку атрибутов, три формы обхода
+  закреплены контрпримерами.
+
+### Added
+
+- `skillkit.installer.ownership` (`PathGuard`, `same_path`) + `ForeignPathError`
+  (потомок `ScopeConflict` — прежние `except ScopeConflict` ловят его без правок),
+  экспортированы из `skillkit`.
+- Тесты `tests/test_destructive_ownership_gate_2026_07_21.py` — воспроизведение
+  ДЕФЕКТА A через `migrate_scope` (до правки чужое гибнет, после — переживает,
+  параметризовано по таргетам), гейт на линковке install, `force` как выход,
+  «сторовые» методы к scope неприменимы, тест-над-тестом на детектор
+  архитектурного правила и защита `mcp_register`. Добавлено: воспроизведение
+  улики-по-имени (чужой каталог с файлом-тёзкой `_skill_meta.json` без маркера
+  переживает install и remove без `force`), юнит-тесты `is_managed_dir` на
+  маркер (нет маркера → не наш; битый JSON с уцелевшим маркером → наш) и
+  контрпримеры детектора ровно на три алиасные формы обхода.
+- `stamp_ownership` — публичный экспорт `skillkit` (штамповка маркера
+  принадлежности в meta-словарь).
+- Тесты `tests/test_legacy_paths_no_orphans_2026_07_21.py` — инвариант «нет
+  осиротевших путей» (дом и project-scope) + доказательство, что он ловит снятое
+  объявление.
+
+## [0.3.0] — 2026-07-21
+
+### Changed (BREAKING) — раскладки навыков приведены к ДОКАЗАННОЙ таблице
+
+Основание — живой опыт того же дня: прогоны `agy --print` и `opencode run` с
+навыками-пробами, у каждой пробы своё кодовое слово в `description`; по его
+появлению в ответе видно, прочитан навык или нет. Проба INDIA (`~/.codex/skills`,
+opencode её НЕ видит) доказывает, что модель не поддакивает, а различает каталоги.
+
+- **Antigravity: `~/.agents/skills` → `~/.gemini/config/skills`.** Это
+  ЕДИНСТВЕННОЕ место, откуда agy читает навыки (проба BRAVO). Не читает:
+  `~/.agents/skills` (ALPHA), `~/.gemini/skills` (CHARLIE), рабочие
+  `.agents/skills` и `.gemini/skills` (DELTA/GOLF — даже из настоящего
+  git-проекта). Прежний `.agents` — каталог Codex/OpenCode: установщик рапортовал
+  успех, а agy навыка не видел (тот же класс ошибки, что снятый `~/.antigravity`;
+  третья и последняя итерация этого пути).
+- **Antigravity: project-scope больше НЕ поддержан** — `base_dir(project=...)` /
+  `slug_dir(project=...)` / `install(project=...)` бросают новый
+  `ScopeUnsupported` (потомок `SkillkitError`/`RuntimeError`). Ставить в каталог,
+  который агент не читает, и рапортовать успех — хуже явного отказа. Признак для
+  потребителя: `IAgentTarget.supports_project_scope`.
+- **Antigravity: `exists()` — по `~/.gemini/config`**, а не по голому `~/.gemini`
+  (последний есть и у gemini-cli). В chain детекта agy стоит последним.
+- **Codex: навыки `~/.codex/skills` → `~/.agents/skills`** (project —
+  `<project>/.agents/skills`) по ДОКУМЕНТАЦИИ агента; живьём не проверено —
+  аккаунт отдаёт 402 `deactivated_workspace`, помечено как документация, а не
+  опыт. Конфиг остался своим: `~/.codex/config.toml` (у таргета теперь два
+  корня — `root` для навыков, `config_root` для конфига; оба подставляются в
+  тестах). `exists()` — по `~/.codex`, потому что `.agents` общий с OpenCode.
+  **Прежний канон не осиротел:** `~/.codex/skills` объявлен
+  `CodexTarget.legacy_dirnames` — навык, поставленный китом ДО переезда, снова
+  находится (`status`), снимается (`remove`) и переезжает на новый канон
+  (`migrate_scope`: наше переносит, чужое пропускает). Заявить старый путь стало
+  можно только вместе с гейтом принадлежности (ниже): рядом в `~/.codex/skills`
+  лежат десятки чужих каталогов.
+
+### Fixed (BREAKING в поведении `remove`) — кит удаляет ТОЛЬКО то, что ставил сам
+
+- **`SkillStore.remove` больше не сносит каталог без нашей меты.** Раньше
+  найденная copy-папка удалялась `_force_rmtree`'ом безусловно, а после переезда
+  Codex каноном стал ОБЩИЙ `~/.agents/skills`, где рядом лежат руками положенные
+  чужие навыки (`find-skills`, `notebooklm`, `shadcn` на машине владельца — slug
+  `notebooklm` совпадает с нашим уже сейчас). Достаточно было
+  `remove(slug="notebooklm")`, чтобы потерять чужие данные; воспроизведено в
+  песочнице до правки. Теперь единый гейт принадлежности стоит на ВСЕ таргеты и
+  на оба вида установки: путь снимается, только если в нём лежит наша
+  `_skill_meta.json` (`skillkit.is_managed_dir`) ЛИБО это ссылка в наш стор
+  (отдельная улика — битая ссылка меты не отдаёт, но убрать её надо).
+- **Отказ явный, а не молчаливый:** `RemoveResult.skipped_foreign` (пути, к
+  которым не притронулись) + `RemoveResult.message` («каталог не наш … не
+  трогаю») для печати потребителем.
+- **`remove(..., force=True)`** — единственный и осознанный выход из-под защиты,
+  чтобы правило не создало НЕУДАЛЯЕМЫХ навыков: установки очень старых версий
+  кита (и наши копии, из которых мету стёрли руками) меты не имеют. По умолчанию
+  выключен: цена ошибки «не удалили» — мусор, цена ошибки «удалили» — чужие данные.
+- **`uv.lock` синхронизирован с `pyproject.toml`** (0.2.4 → 0.3.0). Лок отстал от
+  бампа версии, и первый же прогон тестов чинил его сам, делая дерево грязным.
+  Держится тестом `tests/test_packaging_lock.py`.
+
+### Added
+
+- **`OpenCodeTarget`** (`skillkit.targets.opencode`, экспортирован из `skillkit`,
+  в chain детекта между Codex и Antigravity). Канон: global
+  `~/.config/opencode/skills` (JULIET), project `<project>/.opencode/skills`
+  (MIKE). Агент читает ещё `~/.opencode/skills` (KILO), `~/.agents/skills`
+  (HOTEL) и `<project>/.agents/skills` (LIMA) — кит туда НЕ пишет и НЕ убирает:
+  legacy — это «куда кит РАНЬШЕ СТАВИЛ», а не «что агент умеет читать», а в эти
+  каталоги навыки OpenCode кит не размещал никогда; `.agents` вдобавок общий с
+  Codex, и его владелец — `CodexTarget`. MCP-формат OpenCode не снят ⇒
+  `mcp_config()` = `None` (`status=manual`), выдумывать не стали.
+- **`AntigravityTarget.mcp_config()` реализован**: `~/.gemini/config/mcp_config.json`,
+  JSON, ключ `mcpServers` (файл найден на диске 2026-07-21). Раньше возвращал
+  `None` — «формат неизвестен». Форма совпала с Claude Code, `mcp_register`
+  пишет её без правок.
+- **`ScopeUnsupported`** в иерархии ошибок + `BaseAgentTarget.supports_project_scope`
+  и `skill_entrypoint` (`"SKILL.md"`; плоский `<имя>.md` не читает ни один агент —
+  проба FOXTROT лежала в том же каталоге, что видимая BRAVO, и отличалась ТОЛЬКО
+  формой, контролируемый опыт с одной переменной).
+- Тесты `tests/test_agent_skill_layouts_2026_07_21.py` — по одному на каждый путь
+  доказанной таблицы (включая «чужое в общих каталогах переживает remove» и
+  «форма — каталог, а не плоский .md»). Домашний каталог владельца не задевается:
+  во все таргеты подставляется `root=` внутри `tmp_path`.
+- Тесты `tests/test_remove_ownership_guard_2026_07_21.py` — воспроизведение
+  сценария потери чужого каталога (для КАЖДОГО таргета), `--keep-local` под тем
+  же гейтом, `force` как выход, чужая ссылка не снимается, битая ссылка в наш
+  стор снимается, и весь путь миграции Codex со старого канона.
+- `tests/test_packaging_lock.py` — `uv.lock` не расходится с `pyproject.toml`.
+
+### Примечание для потребителей
+
+Чтобы agy читал навыки вообще, в `~/.gemini/settings.json` нужен
+`experimental.skills = true`. Кит этот файл НЕ трогает — он общий с gemini-cli,
+включение остаётся разовым осознанным действием владельца.
+
+## [0.2.4] — 2026-07-21
+
+### Added — навык объявляет ХУК, установщик его ставит и снимает
+
+- **`[[hooks]]` в `_skill_meta.toml`** — четвёртый артефакт установки рядом с
+  `cli` / `mcp` / `runtime_dependencies`: `event` + `command` (обязательны),
+  `matcher` / `timeout` / `status_message` / `marker` (опционально). Форма
+  эталонная — та же, что у SessionStart-хука `atlas setup`: в настройки агента
+  прописывается ВСТРОЕННАЯ команда CLI (`atlas session-hook`), а не файл-скрипт
+  (не зависит от `python`/`python3` в PATH). Нормализация как у `onboarding`:
+  поля нет → пусто, мусор молча отброшен, publish/install не падает.
+- **`skillkit.hook_register`** — `register_hook` / `unregister_hook` /
+  `list_hooks`. Идемпотентно (повтор установки ничего не переписывает), заменяет
+  собственную устаревшую запись, **не трогает чужие хуки и чужие настройки**,
+  битый файл настроек не затирает (`status=error`), агент с неизвестным
+  расположением → `status=manual`.
+- **`IAgentTarget.hook_config()` + `HookConfigDescriptor`** — расположение файла
+  настроек знает сам агент (как `mcp_config`). Claude Code: global →
+  `<root>/settings.json`, project → `<project>/.claude/settings.json`. Путь
+  берётся от `root` таргета, поэтому подстановка `root=` уводит запись в
+  песочницу (боевой `~/.claude/settings.json` в тестах не задевается).
+- **`tooling`**: `apply_tooling_artifacts` ставит хуки последним шагом (после
+  CLI — хук обычно и есть вызов установленной команды), `revert_tooling_artifacts`
+  снимает их при disable/remove. Осиротевший хук иначе звал бы удалённую команду
+  на каждом старте сессии агента.
+- Механика мёржа вынесена за seam `hook_register._hook_engine()`: когда в
+  `agentskit` появится generic-движок хуков, переезд = замена тела ЭТОЙ функции.
+
+### Removed — старая dot-папка Antigravity убрана совсем
+
+- `AntigravityTarget.legacy_dirnames` очищен: прежняя dot-папка агента больше не
+  известна киту даже на чтение. Решение владельца: она появилась по нашей ошибке
+  и агентом не читалась никогда. **Улика (машина владельца, 2026-07-21): папка НЕ
+  пустая** — в ней три папки навыков (`google-flow` / `notebooklm` / `telegram`),
+  и это НЕ установки кита (нет `_skill_meta.json`, положены руками). Это и есть
+  главный довод против legacy-пути: `SkillStore.remove` сносит найденную
+  copy-папку rmtree'ом БЕЗ проверки меты и по совпадению slug'а снёс бы чужое.
+  Теперь кит туда не смотрит вовсе; `remove` / `resolve_slug_dir` /
+  `migrate_scope` / `exists` работают по канону `.agents/skills` и не ломаются.
+  Три оставшиеся папки — ручное решение владельца (кит их больше не видит).
+- Сам механизм `legacy_dirnames` в `BaseAgentTarget` сохранён (generic, пригодится
+  агенту, который РЕАЛЬНО сменит раскладку); у всех встроенных таргетов он пуст.
+
+## [0.2.3] — 2026-07-21
+
+### Fixed — Antigravity: навыки ставились туда, куда агент НЕ смотрит
+
+- **`AntigravityTarget.dirname`: `.antigravity` → `.agents`.** Канон раскладки
+  теперь `<project>/.agents/skills/<name>/SKILL.md` и `~/.agents/skills/…` —
+  ровно то, что сам Antigravity называет местом навыков (его вывод «Create new
+  skills»: `~/.agents/skills`, `~/.gemini/antigravity-cli/skills`,
+  `~/.gemini/skills`). Прежний `~/.antigravity/skills` не читается агентом
+  вообще: всё «установленное» лежало мёртвым грузом.
+- **Обратная совместимость на ЧТЕНИЕ (`legacy_dirnames`).** Новое поле
+  `BaseAgentTarget.legacy_dirnames` + `legacy_base_dirs()` / `legacy_slug_dirs()`
+  / `resolve_slug_dir()`: пишем в канон, а видим и старую раскладку. Иначе
+  status врал бы «навыка нет», а `remove` оставлял мусор.
+- **`SkillStore.remove()`** снимает навык и по канону, и по старым путям;
+  `target_dir` в отчёте — то место, где навык реально лежал.
+- **`SkillStore.migrate_scope()`** обходит и старые каталоги: наша copy-установка
+  переезжает в стор и линкуется по канону, ссылка по старому пути
+  пересоздаётся; чужие (без `_skill_meta.json`) папки не трогаются.
+- `exists()` считает агента установленным и по старой папке (пока пользователь
+  не мигрировал, она — единственная улика присутствия агента).
+- Другие таргеты (`claude_code`, `codex`) не задеты: у них `legacy_dirnames` пуст.
+
+## [0.2.2] — 2026-07-21
+
+### Fixed — монорепо-навык (навык в подпапке репозитория)
+
+- **`skill_path` переживает установку**: `_skill_meta.json` теперь хранит
+  подпапку навыка, а `SkillStore.update()` берёт её оттуда, если не передали
+  явно. Раньше в `update` стоял жёсткий `skill_path=None` — обновление
+  материализовало КОРЕНЬ монорепо, и в папку навыка налипали `src/`,
+  `pyproject.toml` и копия самого навыка, а `SKILL.md` оказывался этажом ниже
+  (в таком виде Claude Code навык не видит).
+- **`preserved_paths` читаются из `_skill_meta.toml`** навыка, а не только из
+  захардкоженного списка. Навык может защитить свои данные (папку с БД,
+  кэш) — они переживут обновление; общие дефолты (`_local/`,
+  `browser_profiles/`) при этом сохраняются.
+
+### Added — детект пакетного менеджера (`pkg_manager`)
+
+- `detect_project()` определяет экосистему по маркерам: python (`uv.lock`,
+  `pyproject.toml`, `requirements.txt`), node с КОНКРЕТНЫМ менеджером по
+  lock-файлу (`bun`/`pnpm`/`yarn`/`npm`, при нескольких — по времени
+  изменения), rust, go, ruby, php.
+- `missing_manager_report()` вместо голого «не найдены ни uv, ни pip» отдаёт
+  машиночитаемые факты: тип проекта и маркер, чего не хватает, команда
+  установки под ТЕКУЩУЮ ОС и список реально доступных альтернатив. ИИ-агент
+  может довести установку сам.
+
+## [0.2.0] — 2026-07-15
+
+### Added — install-kit (установка навыка «под ключ» со ВСЕМИ зависимостями)
+
+- **`uv_bootstrap.ensure_uv()`** — гарантирует наличие `uv`: `which` →
+  официальный Astral-инсталлер (Windows PowerShell `install.ps1` / POSIX
+  `curl … install.sh | sh`) → фолбэк `python -m pip install uv`; PATH-плюмбинг
+  через `path_store`. Идемпотентно, graceful (не смогли поставить → `None`),
+  мокабельно (сеть не дёргается в тестах).
+- **`binary_installer`** — обобщение bespoke-`install_xray` в переиспользуемый
+  примитив внешних бинарей с GitHub Releases:
+  - `ensure_binary(name, *, github_repo, asset_match, dest_dir, version=None,
+    bin_subpath=None, force=False) -> Path` — latest/тег → выбор ассета
+    (callable/паттерн) → скачивание → распаковка zip/tar → `chmod 0o755` (POSIX)
+    → удаление архива; идемпотентно; на сбое — `BinaryInstallError`;
+  - `platform_asset_name(templates, *, system=None, arch=None)` — резолв имени
+    ассета по текущей ОС×архитектуре (ключи `(os, arch)` или строки `"os-arch"`);
+  - `is_binary_installed(name, dest_dir, *, bin_subpath=None)`.
+- **`deps_installer`** — новые kind `binary` / `github-release` в
+  `runtime_dependencies`: несут spec-словарь `{name, github_repo,
+  asset_match|asset_templates, dest, version?, bin_subpath?}` и делегируют
+  `ensure_binary`. Ветки `pip`/`npm`/`system` не изменены.
+- **`manifest.build_manifest`** — сохраняет полный spec-словарь бинарей (не
+  только `kind`/`spec`), чтобы install мог поставить внешний бинарь.
+- **`bootstrap.bootstrap_skill(skill_dir, *, manifest=None, gate_check=None,
+  run_self_check=True) -> dict`** — оркестрация: `ensure_uv` → python-deps
+  (`uv sync` при наличии `pyproject.toml`, иначе per-spec) → внешние бинари →
+  опциональный `gate_check`-хук (graceful, без жёсткой завязки на s-xray-gate) →
+  `run_self_check`. Отчёт `{uv, deps, binaries, gate, self_check}`; ни один шаг
+  не роняет установку.
+- **`bootstrap.run_self_check(skill_dir) -> (bool, str)`** — находит и запускает
+  `scripts/self_check.py` (venv-python навыка → `uv run` → текущий интерпретатор),
+  возвращает `(ok, output)`.
+- Экспорт в `skillkit.__all__`: `ensure_uv`, `ensure_binary`,
+  `is_binary_installed`, `platform_asset_name`, `bootstrap_skill`,
+  `run_self_check` (+ `BinaryInstallError`, подмодули `uv_bootstrap` /
+  `binary_installer` / `bootstrap`).
+
+### Changed
+
+- `version` 0.1.9 → 0.2.0.