Я дал системе не только действия, но и тормоза

Самая опасная автоматизация, это та, которая не умеет останавливаться.

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

Поэтому в какой-то момент проекту пришлось дать не только действия, но и дисциплину.

Как он описывает исходы своей работы:

PREPARED_DRAFT
NEEDS_HUMAN
SKIP
RETRYABLE_TRANSIENT
RATE_LIMITED_EXTERNAL

PREPARED_DRAFT фиксирует нормальный исход, в котором система может двигаться дальше.
NEEDS_HUMAN означает не сбой, а осознанную передачу решения человеку.
SKIP тоже не является ошибкой, потому что пропуск нерелевантной вакансии — это штатная часть работы.
RETRYABLE_TRANSIENT отделяет временную техническую проблему от логической.
RATE_LIMITED_EXTERNAL показывает, что ограничение возникло не внутри проекта, а во внешнем контуре HH.

Ключевой момент в том, что NEEDS_HUMAN и SKIP не должны открывать breaker.

Иными словами, проект не штрафует себя за нормальные рабочие исходы.
Он замедляется только там, где действительно началась инфраструктурная нестабильность или внешний rate limit.

Именно это превращает его из набора действий в рабочий runtime.

Он уже умеет ежедневно запускаться, идти по нужным search_mode, работать по активному профилю, соблюдать квоты, делать нужное число откликов, проходить простой путь автоматически, передавать uncertain cases в Telegram, подбирать их позже и не забывать, на чём остановился. Эти режимы и continuity layer закреплены в runtime profiles, controlled defaults и state-механике проекта.

Поэтому retry_queue, approval_requests, state и scheduler — не обслуживающие детали, а несущий каркас системы.

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