# Snos Podsistemy Iz Koda

> «Снеси updater», «убери scheduler, оставь ручной запуск», «выведи подсистему из эксплуатации», «удали из repo daemon, adapter, config, tests, документацию без хвостов».

- Skill: `kir-kopylov/snos-podsistemy-iz-koda` (Agent Skill, multi-file: 9 files)
- Install (CLI): `npx skillmds@latest add kir-kopylov/snos-podsistemy-iz-koda`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kir-kopylov/snos-podsistemy-iz-koda/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: kir-kopylov (https://skillmd.com/u/kir-kopylov)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/kir-kopylov/snos-podsistemy-iz-koda

---


# Subsystem Retirement Safeguard

## Запуск Навыка

При явном вызове или однозначном смысловом совпадении применяйте навык сразу. Перед первым шагом покажите ровно одну короткую контекстную строку (не более 30 слов) и продолжайте работу в том же ответе, не ожидая реакции:

Применяю **«Безопасное удаление подсистемы»**: <кратко назовите конкретную дополнительную процедуру или проверяемый результат для текущего запроса>; продолжаю без ожидания.

Не включайте в строку `author_github`, внутреннее имя папки или пересказ всего запроса. Не спрашивайте, применять ли навык.

Если одновременно подходят совместимые навыки, выберите минимальный набор и покажите одну общую строку. Если подходы ведут к несовместимым результатам и запрос не позволяет выбрать, спросите только о желаемом результате, не о разрешении применить навык.

Запуск навыка не расширяет полномочия. Выполните всю безопасную и уже разрешённую часть; запросите подтверждение только непосредственно перед ещё не разрешённым внешним или изменяющим действием. Не запрашивайте повторно уже данное разрешение и не дублируйте системное окно подтверждения.

## Обзор

Этот skill нужен после решения «подсистема больше не нужна». Он не проектирует замену и не превращает удаление в новый проект. Его результат — узкий diff, в котором ненужный механизм исчез, оставшийся пользовательский путь работает, а уже развёрнутые следы можно безопасно убрать.

Главное различение: одноразовая миграция старых установок — не продолжение удалённой подсистемы. У неё есть конкретный старый след, ограниченный срок жизни и отсутствие фонового runtime.

## Естественные Входы

- «Снеси updater целиком».
- «Убери scheduler и оставь только ручной запуск».
- «Удалите старый daemon из repo и release».
- «Выведи эту подсистему из эксплуатации без хвостов».
- «Удали adapter, его config, tests и документацию».

## Процесс

1. **Подтвердите решение и полномочия.** Нужна явная команда удалить именно эту подсистему. Если пока обсуждается, нужна ли она вообще, сначала примените `stop-lishnemu-uslozhneniyu`. Перед изменением Git-состояния используйте `sverka-git-pered-deystviem`: докажите target repo, branch, upstream, рабочее дерево и remote base.
2. **Сформулируйте остаточный контракт одной фразой.** Что пользователь сможет делать после удаления и каким единственным поддерживаемым путём. Пример: «Новые версии ставятся штатной CLI-командой из доверенного source; фоновых задач нет».
3. **Соберите карту поверхности.** Для каждого найденного элемента запишите evidence и решение `delete`, `keep`, `migrate once` или `unknown`:
   - runtime entrypoints, процессы, задачи, службы и фоновые вызовы;
   - installer/uninstaller, release assets, manifest, packaging и зависимости;
   - config, state, cache, registry и feature flags;
   - docs, onboarding, catalog и пользовательские сообщения;
   - tests, fixtures, CI jobs и test helpers;
   - следы уже развёрнутых версий вне repo.
4. **Остановите расширение scope.** Не стройте новый updater, orchestrator, repair service или compatibility platform взамен удаляемого механизма. Если остаточный контракт требует нового продукта, это отдельное архитектурное решение, а не часть retirement.
5. **Спроектируйте одноразовую миграцию, только если есть доказанный legacy-след.** Укажите точный owned identifier, безопасную границу пути, условие запуска, идемпотентность и поведение при `unknown`. Миграция удаляет только известный старый след, не создаёт scheduler и не поддерживает старый runtime.
6. **Удалите подсистему по всей карте.** Меняйте только подтверждённые элементы. Не трогайте соседние механизмы «заодно» и не маскируйте удаление переименованием.
7. **Докажите отсутствие хвостов.** Выполните repo-wide поиск по именам, entrypoints, config keys, asset names и старым trigger-фразам. Каждый остаток должен быть либо явной migration/negative assertion, либо ошибкой, которую надо убрать. Отдельно проверьте фактический состав release/package.
8. **Докажите остаточный контракт.** Запустите реальный smoke поддерживаемого пути в заявленном runtime. Статический поиск и parse check не доказывают, что CLI или ручной workflow действительно работает.
9. **Закройте проверку.** Запустите targeted checks, затем полный suite repo. Проверьте `git diff --check`, scope diff и отсутствие unrelated changes. Если пользователь просил публикацию, передайте чистый WIP в `provedenie-vetki-do-uborki`; не дублируйте его Git-процесс внутри этого skill.

## Формат Результата

```text
Удалено: [подсистема и поверхности]
Остаточный контракт: [одна фраза]
Сохранено как migrate once: [конкретный legacy-след или «ничего»]
Доказательства: [negative scan, runtime smoke, full suite]
Неизвестно: [только реально непроверенные внешние следы]
Следующий шаг: [одно действие]
```

## Границы

- Без явного разрешения на удаление выдавайте только карту и proposal; не меняйте repo или внешнюю систему.
- Не удаляйте пользовательские данные, неизвестные пути, чужие задачи, службы или config по совпадению имени.
- При `unknown` во внешнем состоянии останавливайте destructive cleanup и просите конкретное подтверждение.
- Не выдавайте отсутствие ссылок в repo за доказательство отсутствия уже развёрнутых задач или служб.
- Не сохраняйте старый runtime «на всякий случай». Допустим только узкий `migrate once` для доказанного legacy-следа.
- Не создавайте новую платформу доставки, observability или recovery под видом безопасного удаления.
- Не ослабляйте tests, чтобы удаление стало зелёным; меняйте контракт и проверки вместе.

## Опрос После Использования

Опрос задаётся один раз — после сдачи карты удаления и проверенного результата либо после явного стопа, не посреди рабочего цикла. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте.

```text
Опрос по skill:
1. Что в этом использовании snos-podsistemy-iz-koda было полезно?
2. Что стоит доработать в skill или его формате?
Можно ответить коротко или написать "пропустить".
```

Если пользователь ответил, сохраните санированную карточку в `~/.codex/skill-runs/snos-podsistemy-iz-koda/usage-feedback.jsonl` — лучше через bundled script:

```bash
python3 scripts/log_usage_feedback.py --liked "..." --improve "..." --outcome "..."
```

Script перед записью редактирует приватные пути, контакты и token-like строки и сохраняет в JSONL `redaction_applied` и `redaction_types`. Если запись невозможна из-за sandbox, прав или отсутствия tools, не делайте вид, что лог сохранён: скажите об этом и покажите короткую JSONL-карточку для ручного сохранения. Raw-ответы, контакты, пути и секреты не коммитить.

## Логирование Сбоев

Перед выполнением прочитайте локальный `known-exceptions.yaml` как список уже известных случаев и применяйте подходящее `do_next_time` без нового поиска.

Если пользователь поправил skill, tool/API/browser упал, нарушен режим работы, пришлось искать workaround или skill сделал ложное предположение, запишите приватную карточку в `~/.codex/skill-runs/<skill-name>/exception-log.jsonl`.

Пишите факты: что skill хотел сделать, что сделал, где сломался, какая предпосылка была ложной и что сделать в следующий раз. Если поле неизвестно, пишите `unknown`. Raw logs не коммитить.

## Definition Of Done

- Подсистема отсутствует в source, runtime entrypoints, shipped assets, config, docs, tests и CI, кроме явно перечисленной одноразовой миграции и negative assertions.
- Остаточный контракт сформулирован до правок и доказан реальным smoke.
- Уже развёрнутый legacy-след либо безопасно мигрируется, либо честно записан как `unknown` с владельцем следующего действия.
- Repo-wide negative scan, targeted checks, полный suite и scope review пройдены без ослабления защит.
- В diff нет replacement platform и unrelated cleanup.