Зелёный тест, успешный ответ API, экран без видимых ошибок. Каждый из этих результатов что-то подтверждает. Но ни один сам по себе не отвечает на вопрос, завершена ли задача человека и не осталось ли за пределами проверки важной ответственности приложения.

В сентябре в ArkTelos Lab вышло двенадцать материалов. Они не складывались в серию по одному пакету или архитектурному шаблону. Зато при подготовке каждого возвращался похожий вопрос: где заканчивается доказанное поведение инструмента и начинается решение, которое ещё должна принять команда?

На ревью это различие легко потерять. Демонстрация успешного сценария создаёт ощущение, что спор закрыт. Но если человек успел закрыть экран, данные в кэше устарели или агент получил разрешение на уже изменившуюся задачу, прежний результат подтверждает только прежние условия. Возникает не абстрактное требование «предусмотреть крайние случаи», а вполне конкретный разговор: кто владеет незавершённой работой, какой факт можно повторно прочитать и какое действие требует нового подтверждения?

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

AI и агенты. Результат работы инструмента не равен разрешению изменить приложение или данные. Genkit Dart 0.16: изменение Tool-контракта — повод проверить интеграцию, а не объявить прежнее поведение гарантированным. Согласие на действие AI-агента: пользователь подтверждал показанное предложение; если исходные данные изменились, старое согласие нельзя переносить на новое действие без проверки. Package skills в Dart: инструкция может поставляться вместе с пакетом, но это ещё не доказывает, что агент её прочитал и применил. Проверка работающего Flutter-приложения агентом: анализ исходников и наблюдение за экраном отвечают на разные вопросы. Наличие MCP-инструмента не подтверждает его использование.

Архитектура. Механизм удобно выбирать после того, как названа ответственность. Иначе даже аккуратное разделение файлов может спрятать смешанные контракты. Ошибка, состояние и эффект: результат операции, повторно читаемое состояние экрана и действие интерфейса живут по разным правилам. Операция после закрытия экрана: удаление маршрута не отменяет автоматически работу, которая была запущена раньше. Глобальный обработчик ошибок: он может помочь с диагностикой, но не должен решать за конкретный сценарий, что показать человеку и нужен ли повтор. Свежесть данных в кэше: видимые данные, время их последнего подтверждения и неудачное обновление нельзя без потерь свести к одному «загружено».

Жизненный цикл и обновления. Вызов API завершился — ответственность не обязательно закончилась. Выход пользователя и get_it: закрытая область зависимостей не уничтожает сохранённые ссылки на объекты и не объясняет судьбу незавершённой асинхронной работы. Обновление flutter_secure_storage: история релизов библиотеки не равна истории обновлений на телефонах пользователей. Промежуточную версию могли пропустить.

Человек и производительность. Улучшение нужно оценивать по тому, какую задачу оно меняет, а не по названию технологии. JSON и isolate: экран может перестать замирать, хотя готовый результат начнёт приходить позже. Это разные критерии успеха. Взаимодействие не только через экран: текст, доступность, альтернативы жестам и обратная связь должны сохранять смысл всей пользовательской задачи. Локальный AI не исправит неясную кнопку или потерянный выбор.

В этих статьях нет одной «правильной архитектуры на все случаи». Есть более полезная привычка: после слова «работает» уточнять, что именно работает, для кого и при каких условиях. Полный выпуск связывает все двенадцать материалов и ведёт к статьям с кодом, источниками и границами экспериментов.

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