Stop Lishnemu Uslozhneniyu

Overengineering Stop Gate

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

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

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

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

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

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

Обзор

Этот skill нужен в момент, когда команда уже обсуждает дополнительные тесты, updater, scheduler, observability, rollback, подписи, миграции или отдельную платформу, но ещё не доказала, что сам механизм нужен исходному outcome.

Skill не проповедует минимализм. Он отделяет полезную сложность от сложности, которая обслуживает только саму себя. Сначала решается вопрос существования механизма, и только потом — вопрос его надёжности.

Главный контракт:

• исходный outcome формулируется одним предложением;
• каждый механизм проходит ledger механизм → конкретная боль → evidence → ownership cost → verdict;
• итоговый verdict — keep, simplify или delete;
• тестируется только invariant, который пережил verdict;
• фактическое удаление требует явного разрешения пользователя;
• ответ заканчивается одним следующим шагом.

Перед работой прочитайте шаблон complexity ledger и локальный known-exceptions.yaml.

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

• «Нахуя это вообще нужно?»
• «Это просто библиотечка командных скиллов.»
• «Ты наворачиваешь и наворачиваешь.»
• «Какие изменения очевидно и неизбежно нужны?»
• «Что здесь оставить, упростить или удалить?»
• «Стоит ли вообще писать этот regression test?»
• «Сначала докажи, что механизм нужен, потом предлагай hardening.»
• «Дай минимальный следующий шаг без новой платформы.»

Процесс

1. Заморозить Расширение

Не предлагайте новые компоненты, тестовые матрицы, CI jobs, метрики, миграционные платформы или runbooks, пока gate не закрыт. Уже предложенное не считать обязательным только потому, что на него потрачено время.

2. Вернуть Исходный Outcome

Сформулируйте в одной фразе, что пользователь хотел получить до появления спорного механизма.

Хорошо:

Outcome: Команда вручную устанавливает и обновляет одну библиотеку скиллов предсказуемым способом.

Плохо: перечислить текущую архитектуру и назвать её целью.

3. Собрать Только Нужное Evidence

Для repo или работающей системы сначала проверьте доступные файлы, usage, инциденты, требования, поддерживаемые среды и последствия удаления. Отделяйте наблюдаемый факт от вывода.

Не используйте отсутствие telemetry как доказательство отсутствия пользователей. Если дешёвая проверка возможна — выполните её. Если критичное evidence недоступно — gate остаётся открытым; не компенсируйте незнание уверенным delete.

4. Заполнить Complexity Ledger

Для каждого спорного механизма укажите:

• какую конкретную боль он снимает;
• какое evidence подтверждает боль и пользу механизма;
• стоимость владения: код, CI, секреты, release-процесс, поддержка, миграции, on-call, failure modes;
• что произойдёт без механизма;
• verdict: keep, simplify или delete.

Не подменяйте evidence словами «production-grade», «best practice», «на будущее» или «так делают сильные команды».

5. Вынести Verdict

• keep — механизм закрывает доказанную боль, а цена его отсутствия выше обоснованной стоимости владения.
• simplify — боль реальна, но outcome сохраняется при более узком контракте, ручном шаге или меньшем числе компонентов.
• delete — отдельная ценность механизма не доказана, его outcome уже закрыт проще, а последствия удаления проверены.

Высокий ущерб от ошибки — безопасность, потеря данных, деньги, compliance, необратимая публикация — не является поводом для слепого удаления. В такой строке сначала закройте evidence gap; при необходимости временно сохраните узкий safety invariant.

delete — рекомендация по дизайну, а не разрешение менять систему. Перед удалением получите явное согласие на конкретный scope. Если согласие уже дано в текущем диалоге, не спрашивайте повторно.

6. Определить Surviving Invariant

После verdict назовите единственное минимальное свойство, которое ещё нужно доказать:

• после keep — полезное свойство сохранённого механизма;
• после simplify — outcome более узкого решения;
• после delete — residual contract: нужный outcome работает без удалённого механизма.

Не пишите regression test для механизма, который решено удалить. Не тестируйте все мыслимые failure modes «на всякий случай». Проверка должна быть пропорциональна риску surviving invariant.

7. Дать Один Следующий Шаг

Верните ровно одно действие, которое зависит от verdict:

• keep → проверить surviving invariant;
• simplify → сделать минимальное сужение и проверить его outcome;
• delete без разрешения → запросить разрешение на указанный scope;
• delete с разрешением → передать удаление в snos-podsistemy-iz-koda без повторного проектирования подсистемы.

Формат Ответа

Outcome: <одно предложение>

| Механизм | Конкретная боль | Evidence | Ownership cost | Verdict |
| --- | --- | --- | --- | --- |
| ... | ... | ... | ... | keep / simplify / delete |

Surviving invariant: <одно проверяемое свойство>
Следующий шаг: <одно действие>

Если gate не закрывается из-за отсутствующего evidence, не имитируйте verdict. Назовите одну недостающую проверку и сделайте её следующим шагом.

Границы

• Не используйте skill для обычного проектирования с уже доказанными требованиями и согласованным complexity budget.
• Не превращайте его в автоматический запрет архитектуры, CI, observability, security controls или regression tests.
• Не удаляйте safety-critical механизм только потому, что пользователь раздражён его сложностью.
• Не считайте sunk cost аргументом в пользу keep.
• Не считайте отсутствие жалоб доказательством ненужности механизма.
• Не придумывайте usage, SLA, угрозы или стоимость поддержки. Непроверенное помечайте как inference или unknown.
• Не расширяйте анализ на весь repo, если пользователь оспаривает один механизм.
• Не выполняйте удаление без явного разрешения и подтверждённого scope.
• Не выдавайте roadmap. Один verdict, один surviving invariant, один следующий шаг.

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

Опрос задаётся один раз — после verdict и одного следующего шага либо после явного стопа из-за недостающего evidence. Не задавайте его посреди проверки. Если пользователь уже ответил «пропустить» в этой сессии, не переспрашивайте.

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

Если пользователь ответил, сохраните санированную карточку в ~/.codex/skill-runs/stop-lishnemu-uslozhneniyu/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/stop-lishnemu-uslozhneniyu/exception-log.jsonl.

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

Definition Of Done

Gate закрыт, если:

• исходный outcome дан одним предложением;
• ledger опирается на проверенное evidence и показывает ownership cost;
• каждому механизму присвоен обоснованный keep, simplify или delete;
• для удаления есть явное разрешение либо следующим шагом запрошено именно оно;
• выбран один surviving invariant, а тесты удаляемого механизма не продолжают жить по инерции;
• дан ровно один следующий шаг без нового слоя архитектуры.