Телеграм канал «FreeBlock.Dev»

🔐 Доступ отозвали. А старая вкладка ещё работает?

Учебный сценарий: сотрудника убрали из проекта, но у него осталась открытая карточка клиента. Он нажимает «Сохранить» или запускает выгрузку. Исчезновение проекта из меню ещё не доказывает, что сервер запретил действие.

Проверьте отзыв прав как отдельный пользовательский сценарий:
• Откройте запись в двух тестовых сессиях.
• Из административной сессии отзовите доступ второй.
• Не обновляя её вкладку, попробуйте прочитать запись, сохранить правку и создать выгрузку.
• Проверьте прямой запрос к API, а не только скрытую кнопку.

🛠 Заранее определите, когда отзыв должен вступать в силу. Проверка на сервере должна учитывать актуальные полномочия; старое значение роли в сессии или кеше не должно сохранять доступ дольше принятого правила. Отдельно решите, что делать с уже поставленными в очередь заданиями.

При отказе объясните причину и безопасный следующий шаг. Не показывайте «сохранено», если операция была отклонена.

✅ Критерий приёмки: после отзыва доступа старая вкладка и API соблюдают одну и ту же политику. Уже скачанные пользователем данные такой проверкой обратно не отозвать.

Основа: OWASP рекомендует проверять полномочия для каждого запроса.
https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html

🕘 «Каждый день в 9:00» - ещё не полное требование.

Представьте сервис, который отправляет отчёт владельцу магазина. В настройках выбрано 9:00 по Варшаве. Если сохранить только фиксированное смещение от UTC, при изменении сезонного времени отправка может сместиться относительно местных часов.

Для регулярного расписания полезно хранить отдельно:
• местное время, которое выбрал пользователь;
• часовой пояс, например Europe/Warsaw;
• правило повторения;
• рассчитанный момент следующего запуска.

Фиксированное смещение вроде UTC+2 и часовой пояс - разные вещи. Правила часовых поясов могут меняться; база IANA обновляется с учётом таких изменений.

🧪 В приёмку добавьте не только обычный день. Проверьте переход сезонного времени и смену часового пояса пользователем. Для времени, которое пропускается или встречается дважды, заранее определите поведение: перенести, пропустить или выполнить один раз по выбранному правилу.

Показывайте дату, время и часовой пояс ближайшей отправки в интерфейсе. Так владелец продукта может проверить обещание сервиса без пересчёта UTC в голове.

Справочник IANA: https://www.iana.org/time-zones

🧪 После смены модели AI-помощник отвечает красивее. А задачу решает лучше?

Представьте помощника службы поддержки: он ищет ответы в базе знаний и предлагает текст сотруднику. Перед обновлением модели или промпта полезно сравнить старую и новую версии на одном наборе задач.

Соберите обезличенные примеры: обычный вопрос, неполные данные, противоречащие друг другу документы и случай, когда ответа в базе нет. Для каждого заранее запишите, что считается успехом.

Например, на вопрос об условиях доставки ответ должен:
• соответствовать действующему документу;
• содержать проверяемую ссылку на источник;
• уточнять регион, если без него условия неоднозначны;
• честно сообщать, что данных недостаточно, вместо выдуманного срока.

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

Повторите прогоны: ответы модели могут различаться. Спорные оценки проверьте вручную, особенно если ответы оценивает другая модель. Часть примеров оставьте вне настройки промпта, чтобы проверить результат на новых задачах.

Практический разбор оценки AI-систем у Anthropic:
https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents

Такой набор проверок помогает обсуждать обновление по конкретным ошибкам и улучшениям. Он не заменяет наблюдение за качеством после запуска.