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.

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

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

Границы

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

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

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

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

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

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.