atlas v0.3.6

0.3.6 — линтер в ноль, честная статистика ночного бэкапа

Линтер (#942) — ruff check . был красным (147 ошибок), то есть джоба test
не могла проходить ни на dev, ни в MR: гейт качества молча не работал. Теперь
All checks passed.

• 44 ошибки исправлены автофиксом (неиспользуемые импорты, пустые f-строки).
• 15 неиспользуемых переменных убраны вручную. Три из них — в боевом коде
  (junctions.py, stats.py ×2): мёртвые остатки рефакторинга, поведение не
  меняют, но именно они прятались за шумом из тестов.
• Два правила вынесены в per-file-ignores с обоснованием: E702 для tests/*
  (компактные setup-строки — осознанный стиль набора) и E402 для
  migrations/env.py (alembic импортирует после настройки окружения).

Ночной бэкап (#922) — строка итога перестала врать. В логе 2026-07-20 было
«121 ok, 11 failed», и все 11 «падений» оказались репозиториями без удалёнки.

• daily_backup.sh отдаёт exit 2 для «бэкапить некуда» (нет origin, не
  git-репозиторий) отдельно от настоящих сбоев (exit 1).
• Обход считает их как skipped: DONE: N ok, M skipped (нет remote), K failed.
  Строка FAILED: появляется только при реальных ошибках.
• Каждый проект обходится один раз. Логические папки-группы
  (Clients|Products|Tests|_Inbox) — junction-ссылки на физику _storage/,
  поэтому проекты обходились дважды (132 захода вместо ~66). Дедупликация — по
  физическому пути (pwd -P разрешает junction).
• Корень портфеля переопределяется через ATLAS_PROJECT_ROOT — без этого обход
  нечем покрыть тестами; добавлен tests/test_backup_sweep.py, включая прогон
  на настоящем junction.

atlas v0.3.5

0.3.5 — чистая установка навыка: allowlist вместо .skillignore (#936)

Механизм из 0.3.4 не сработал: skills/atlas/.skillignore попадает в опись
файлов хаба, но до папки навыка не доезжает вообще, а без файла skillkit
фильтрацию не включает («иначе ничего не делаем»). После обновления на 0.3.4 в
навыке по-прежнему лежали src/, pyproject.toml, install/, CHANGELOG.md
и копия skills/atlas/.

Состав установки теперь задаёт allowlist files: во frontmatter SKILL.md —
он читается из самого SKILL.md, который доезжает всегда. Решение проверено
прогоном настоящего skillkit.filter на копии структуры стора:

files:
  - /SKILL.md
  - /_skill_meta.toml
  - /agents/**
  - /references/**
  - /.venv/**

Две детали, без которых оно ломается (обе поймались на прогоне, не в теории):

• якоря / — без них SKILL.md матчится на любом уровне (gitignore-
  семантика), и вложенная копия skills/atlas/SKILL.md переживает фильтр;
• /.venv/** — allowlist удаляет всё неперечисленное, а per-skill venv
  (65 МБ, из него работает CLI-шим atlas) не защищён ни
  _PRESERVED_ROOT_NAMES, ни preserved_paths: последний skillkit хардкодит и
  из манифеста не читает. Без этой строки первый же update снёс бы venv вместе
  с рабочей командой atlas.

Тесты tests/test_skill_payload.py переписаны под allowlist и стерегут оба
требования плюс покрытие всех файлов тела навыка.

atlas v0.3.4

0.3.4 — changelog в релизах, чистая установка навыка, онбординг с проверкой CLI

Доставка changelog (#926) — способ ведения CHANGELOG.md не меняется,
механизируется только доставка. Раньше описание релиза не доходило никуда:
теги на github были lightweight, GitHub Releases не создавались (0 на 12 тегов),
на PyPI не было даже ссылки.

• scripts/release_notes.py — извлекает секцию версии; один и тот же текст идёт
  в аннотацию тега, в GitHub Release и в проверку CI.
• Тег на github теперь аннотированный, с телом секции (publish_public_github.sh),
  причём с --cleanup=verbatim: по умолчанию git -F вырезает строки на #,
  то есть заголовок версии молча пропадал бы из каждого тега.
• GitHub Release создаётся тем же скриптом через Releases API (первый релиз
  на 13 тегов). Шагом в .github/workflows/publish.yml это сделать нельзя:
  публикация в github идёт PAT-ом без scope workflow, и GitHub отвергает пуш
  целиком, если в нём меняется хоть что-то в .github/workflows/. Повторный
  прогон тега обновляет существующий релиз, а не плодит второй.
• [project.urls]: Changelog, Release Notes, Issues — PyPI показывает их
  отдельными ссылками с иконками (PEP 753).
• Джоба release-guard в GitLab CI падает ДО публикации, если версия
  разъехалась (pyproject / __init__ / манифест навыка / pin atlas-pm / тег)
  или в CHANGELOG.md нет секции для тега. Версии на PyPI неизменяемы —
  ловить рассинхрон нужно до, а не после.
• atlas update --check отдаёт release_notes_url и печатает «что нового»:
  CHANGELOG.md в wheel не попадает, а страница PyPI показывает README.

Установка навыка ставит только навык (#936) — skills/atlas/.skillignore.
Репозиторий монорепный (CLI в src/, навык в skills/atlas/), хаб знает про
подпапку, но его опись файлов перечисляет пути от корня — поэтому на update в
папку навыка налипали src/, pyproject.toml, install/ и даже копия
skills/atlas/ внутри самого навыка.

• Выбран IGNORE-режим, а не allowlist files: во frontmatter: allowlist удаляет
  всё неперечисленное, а per-skill .venv/ (65 МБ, из него работает CLI-шим
  atlas) не защищён — preserved_paths skillkit хардкодит и из манифеста не
  читает. Первый же update снёс бы venv вместе с рабочей командой.
• tests/test_skill_payload.py роняет сьют, если в репозитории появился новый
  верхнеуровневый каталог, не учтённый фильтром.

Онбординг навыка (#941) — секция [onboarding] дополнена тем, чего не
хватало агенту, чтобы довести установку до конца:

• шаг 0 — проверка atlas --version и что делать, если CLI не встал: у
  tooling-навыка пакет ставит skillkit, и он этого не может, когда в системе нет
  ни uv, ни pipx, ни pip. Даны команды установки менеджера под Windows / macOS /
  Linux и предупреждение про PATH в уже открытой оболочке;
• шаг 5a — бэкап портфеля (backup run / status / schedule install)
  сразу после подключения git-хостинга: без remote бэкапить некуда;
• контракт секции закреплён тестами (tests/test_skill_onboarding.py), включая
  запрет хардкодить версию в тексте.