Kornilov Tools · Daniil Kornilov 

Представь: на сайте плохо видна кнопка заявки. Ты просишь ИИ «сделать страницу красивее».

В ответ меняются цвета, заголовок и половина блоков. А ты хотел всего лишь заметную кнопку.

Это пример расплывчатой задачи. «Красивее» не объясняет, что именно мешает и где пора остановиться.

Вместо «сделай красиво»:

«На телефоне плохо видна кнопка заявки в первом блоке. Измени только её размер и отступы. Текст, цвета и версию для компьютера оставь. Покажи, что поменял».

Здесь понятно, что исправляем, что можно трогать и что должно остаться.

Это не волшебный промпт. Результат всё равно нужно открыть и проверить. Если одной правки мало, сначала попроси объяснить почему.

«Напиши умнее» — слишком много вариантов.

«Убери термины, сократи вступление и оставь один понятный пример» — уже задача.

Перед следующим запросом закончи фразу: «Я пойму, что готово, когда…». Если закончить трудно, уточни результат до начала работы.

В небольшом проверяемом эксперименте есть правило доставки: ниже суммы 5 000 условных денежных единиц доставка стоит 500, начиная с 5 000 — бесплатно. Все суммы целые; это учебный пример, а не тариф магазина.

Проверка только одна: для суммы 6 000 доставка должна быть бесплатной.

Правильная функция проходит тест. Но его проходят и три ошибочных варианта: бесплатная доставка всегда; платная доставка ровно на пороге; неправильная стоимость ниже порога.

Все варианты правильно отвечают на единственный заданный вопрос. Код проверки работает, но выбранный пример не отличает правильное решение от этих ошибок.

Вместо просьбы «добавь ещё тестов» полезно назвать возможные дефекты и проверить, замечает ли их набор испытаний.

В нашем примере ожидаемые результаты такие:

— сумма 4 999: доставка 500;
— сумма 5 000: доставка 0;
— сумма 6 000: доставка 0.

Этот набор пропускает правильную функцию и отклоняет каждый из трёх ошибочных вариантов. Проверка выполнена в Node.js; речь только об этой модели правила, без оценки реального магазина или сравнения моделей.

Такая техника похожа на ручной начальный шаг мутационного тестирования: намеренно меняем реализацию и наблюдаем, какие проверки обнаружили изменение. Описание подхода и терминов:
https://stryker-mutator.io/docs/General/faq/

Если помощник написал и функцию, и тест, он может дважды пропустить одну границу. Согласие этих двух частей само по себе не подтверждает требование.

Сформулируйте запрос конкретно: «Назови три правдоподобные ошибки в этом правиле. Внеси каждую отдельно и покажи, какое утверждение падает».

Начните с одного важного правила: права доступа, граница тарифа, отклонение неверного импорта. Ожидаемый результат должен следовать из требований. Если его никто не может объяснить, сначала уточните само правило.

Кнопка экспорта позеленела. Сервер вернул 202. Файла ещё нет.

Разберём условный сервис: пользователь запускает выгрузку, API принимает задание, а отдельный обработчик готовит файл. Если интерфейс сразу пишет «Экспорт готов», он обещает результат, который система пока не подтвердила.

HTTP 202 означает, что запрос принят в обработку. Работа может ещё не начаться, завершиться позже или закончиться ошибкой. Сам ответ не доказывает, что файл создан.

Описание статуса в MDN:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/202

Для такого сервиса полезно разделить состояния: запрос отправляется, задание в очереди, файл готовится, готов, ошибка. Отдельно — состояние неизвестно, когда проверить обработчик сейчас не получается.

Это состояния конкретного приложения. Способ проверки результата нужно определить в его API: например, ресурс статуса по идентификатору задания. Код 202 сам по себе такого адреса не создаёт.

Представьте последовательность:

Задачу «обновить Node.js» закрыли, сборка зелёная. Но работающий контейнер может по-прежнему использовать старый runtime.
 
Это учебный сценарий: версия поменялась в CI, а в развёртывание ушёл прежний образ. Никакого противоречия — тесты проверили одно, пользователи получили другое.
 
После октябрьского выпуска исправлений Node.js стоит проверить не только изменение конфигурации, но и фактическую версию в рабочей среде.
 
Официальный источник:
https://nodejs.org/en/blog/vulnerability/october-2026-security-releases
 
Что сохранить после обновления
 
Запишите версию, которую наблюдаете в рабочей среде, идентификатор развёрнутого артефакта и результат выбранных проверок. Версия на ноутбуке не подтверждает версию фонового обработчика или контейнера на сервере.
 
Для учебного сервиса импорта CSV я бы выбрал запуск, загрузку корректного файла, отказ на некорректном и один запрос к внешней интеграции. Это пример набора проверок: для своего приложения выберите важные пользовательские сценарии.
 
Рядом с каждой проверкой нужны ответственный, ожидаемый результат и наблюдение. Если подтверждения нет, оставьте проверку открытой. Так незаконченная работа не превращается в зелёную галочку.
 
Готовый инструмент: Launch Control Desk
 
Я сделал Launch Control Desk для небольших запусков, где нужно держать проверки и решение по выпуску вместе. В локальном приложении можно назначать ответственных, записывать доказательства, зависимости и риски, а затем выгружать обзор. Есть два набора стартовых проверок: цифровой продукт и веб-сервис.
 
Инструмент не обновляет Node.js, не выполняет тесты и не подтверждает безопасность приложения автоматически. Его задача — собрать результаты выполненной вами работы так, чтобы их можно было проверить и передать коллеге.
 
В комплекте — приложение для браузера на компьютере, инструкции RU/EN и примеры. Распакуйте ZIP и откройте index.html. Рабочие данные остаются локально; JSON-копии сохраняйте отдельно.
 
Цена — 1 190 ₽ разово, без обязательной подписки внутри приложения.
Купить и скачать Launch Control Desk:
https://boosty.to/swiftuidev/posts/68708fd5-1dad-4ed3-ac0c-3356d796a00f?utm_source=boosty&utm_medium=post&utm_campaign=news_20261022
 
Если вы отвечаете за ближайший выпуск, начните с одного приложения: внесите версию, назначьте владельца и приложите результаты реальных проверок.
 
Я Даниил Корнилов, автор Kornilov Tools. Подпишитесь на блог и Telegram — здесь выходят практические разборы работы с релизами, данными и клиентскими задачами:
https://t.me/SwiftUIDaily

Клиент просит добавить секцию с тарифами, которой не было в исходном объёме. До начала работы отправьте конкретное предложение: результат, исключения, доплата и новый срок.
 
Учебный пример:
 
«Добавляем три карточки тарифов в текущем дизайне. Тексты предоставляете вы. Оценка — 3 часа, доплата — 3 000 ₽, срок проекта сдвигается на один рабочий день. Интеграция оплаты в этот запрос не входит. Начну после подтверждения объёма, цены и срока».
 
Суммы и часы здесь вымышлены — замените их своей оценкой и условиями проекта.
 
Scope Change Desk помогает собрать такой запрос и сохранить решение клиента рядом с исходными условиями проекта. Внутри — журнал допработ, оценки, статусы и выгрузка отдельного документа. Можно вести до 100 проектов локально в браузере.
 
В комплекте — офлайн-приложение RU/EN, самостоятельная Excel-таблица с формулами, примеры и инструкции. Excel и приложение не синхронизируются; сохраняйте JSON-копии проектов отдельно.
 
790 ₽ разово. Обязательная подписка внутри инструмента не нужна.
 
Купить и скачать Scope Change Desk:
https://boosty.to/swiftuidev/posts/7175948d-3f36-46e8-8553-8109a21d79cb?utm_source=boosty&utm_medium=post&utm_campaign=scope_20261018
 
Отправленный запрос ещё не означает согласование или оплату: подтверждение клиента и факт оплаты фиксируются отдельно.
 
Подпишитесь на блог, чтобы получать следующие разборы и обновления Kornilov Tools. Короткие примеры также публикую в Telegram: https://t.me/SwiftUIDaily

Команда Node.js анонсировала исправления безопасности для веток 26.x, 24.x и 22.x на 21 октября 2026 года или вскоре после этой даты. Максимальная указанная серьёзность — HIGH. Исправленные версии ещё предстоит проверить по финальному сообщению: анонс не равен состоявшемуся выпуску.
 
Официальный источник: https://nodejs.org/en/blog/vulnerability/october-2026-security-releases
 
До выхода обновлений можно подготовить короткую карточку для каждого приложения:
 
1. Где работает приложение и кто за него отвечает.
2. Какая версия Node.js реально запускается в production.
3. Где задаётся версия: образ, конфигурация сборки или другой источник.
4. Какие сценарии нужно проверить после обновления.
5. Как восстановить предыдущий артефакт, если проверка обнаружит проблему.
 
Проверяйте среду развёртывания отдельно от своего ноутбука. Команда node --version в локальном терминале отвечает только за этот терминал.
 
Для учебного сервиса импорта проверками могли бы стать запуск приложения, успешная загрузка тестового файла, отказ на некорректном файле и один запрос к внешней интеграции. Для другого приложения набор будет другим: выбирайте сценарии по реальному риску.
 
После выхода исправлений сверьте финальное уведомление, выберите версию для поддерживаемой ветки и пересоберите тот артефакт, который действительно развёртывается. После запуска запишите наблюдаемую версию и результат проверок. Одного изменения номера в конфигурации недостаточно для подтверждения обновления сервера.
 
В Launch Control Desk можно вручную собрать ответственных, подтверждения и решение по выпуску. Инструмент не обновляет Node.js и не выполняет тесты; эти действия остаются за командой.
 
Описание и пример результата: https://pease163.github.io/digital-products/products/launch-control.html?utm_source=boosty&utm_medium=post&utm_campaign=news_20261016

«Сделал приложение на SwiftUI» — по такой фразе трудно понять, какую задачу вы решили.

Для одного проекта ответьте на восемь вопросов:

1. Что не работало и кому это мешало?
2. За какую часть отвечали лично вы?
3. Какое решение приняли?
4. Какую альтернативу отбросили и почему?
5. Что наблюдали после изменения?
6. Чем подтверждается результат: diff, запись экрана, сценарий проверки?
7. Что осталось непроверенным?
8. Что сделали бы иначе в следующий раз?

Учебный пример: в форме импорта JSON сначала проверяется файл, а текущий черновик заменяется только после подтверждения. Результат можно показать сценарием: создать черновик, выбрать некорректный JSON и убедиться, что текст остался на месте. Это конкретнее, чем «улучшил UX»; проценты без измерений здесь не нужны.

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

Сначала соберите один законченный кейс. Скриншот показывает экран, а объяснение решения помогает понять вашу работу.

Для этого есть бесплатная форма Kornilov Tools: один кейс, локальный черновик, экспорт Markdown и HTML. Без аккаунта. Резервную JSON-копию сохраняйте отдельно: очистка данных браузера может удалить черновик.