💭 в уме · писать не нужно
В u3 ты собрал промпт URL → insights и прогнал его руками. В u4 ты расписал лестницу: условия, расписание, уведомления.
Сегодня поднимаемся на две ступени сразу: условие и расписание. Вспомни, где у тебя копятся ссылки «прочитаю потом». Закладки, «Избранное» в мессенджере, открытые вкладки?
Сколько из них ты реально разобрал за последнюю неделю?
💭 в уме · писать не нужно
Представь утренний почтовый pipeline: ночью лента движется сама, а утром в конце ждёт готовая стопка разбора.
Какое решение pipeline должен уметь принять без тебя?
Trigger: расписание, каждый день в 8:00
Вход: inbox.txt — ссылки, которые ты накидал за день
Condition: ссылка уже есть в done.txt → пропустить
Action: агент читает страницу и пишет разбор по prompt.md
Выход: digest-ГГГГ-ММ-ДД.md, ссылка → done.txt
Ты дописываешь ссылку в inbox.txt одной строкой. Утром тебя ждёт готовый файл с разбором.
Скрипт будет запускаться каждый день по одному и тому же inbox.txt. Без условия он каждое утро заново разберёт все старые ссылки. Это ровно тот случай из u1: дубли и упор в лимиты.
done.txt — память pipeline о том, что уже сделано. Повторный запуск не меняет результат и не тратит лимиты. У такого свойства есть имя: идемпотентность.
В модуле 08 ты увидишь его в настоящем production-pipeline. Там строка состояния письма в базе (SQLite): повторный проход обработанное не трогает (08, «Оркестрация: Gmail-агент как кейс»). Метка — результат классификации. У тебя та же идея, только вместо базы — строка в файле.
Второе правило оттуда же: ссылка попадает в done.txt только после успешного разбора. Упал прогон — ссылка останется в очереди, и завтра скрипт попробует снова.