I gave the system not only actions but also brakes

The most dangerous automation is the kind that can’t stop.

If a system treats any non-standard case as the same error, it starts destroying itself: it retries where a person is needed, keeps going where a pause is required, and turns a working pipeline into a source of its own noise.

So at some point the project had to be given not only actions but also discipline.

How it describes the outcomes of its work:

PREPARED_DRAFT
NEEDS_HUMAN
SKIP
RETRYABLE_TRANSIENT
RATE_LIMITED_EXTERNAL

PREPARED_DRAFT records a normal outcome in which the system can move on. NEEDS_HUMAN means not a failure but a deliberate handover of the decision to a person. SKIP isn’t an error either, because skipping an irrelevant vacancy is a regular part of the work. RETRYABLE_TRANSIENT separates a temporary technical problem from a logical one. RATE_LIMITED_EXTERNAL shows that the limit arose not inside the project but in HH’s external circuit.

The key point is that NEEDS_HUMAN and SKIP must not open the breaker.

In other words, the project doesn’t penalise itself for normal working outcomes. It slows down only where infrastructure instability or an external rate limit has really begun.

That’s what turns it from a set of actions into a working runtime.

It can already start daily, follow the right search_mode, work by the active profile, keep to quotas, make the required number of applications, go through the simple path automatically, pass uncertain cases to Telegram, pick them up later and not forget where it stopped. These modes and the continuity layer are fixed in the project’s runtime profiles, controlled defaults and state mechanics.

So retry_queue, approval_requests, state and scheduler aren’t service details but the load-bearing frame of the system.

Without them this would just be a bot that can do something. With them it’s a personal employment infrastructure able to work regularly and not burn out at the first instability.