A disappearing stop button can precede an empty response or unfinished media. Waiting a long fixed duration instead can waste time after an answer is already ready. Northstar's waiting logic combines observable conditions rather than treating one elapsed duration as completion.

Not generating is only part of the completion condition

Busy is derived from the service's stop control. If no new answer exists or busy remains true, waitAnswer clears last and stable and continues. Absence of stop does not immediately return true. A new response and required content must coexist before stability comparison starts.

The indicator is not a direct API into every internal model state. It is an observation interpreted by a site adapter recognizing known controls. A timer cannot eliminate the possibility of changed layout or a missing generation marker. Completion is therefore described as a combination of observations rather than the presence or absence of one button.

Distinguish the initial value from consecutive repeats

The original function stores a first signature as last and sets stable to zero. The next identical signature produces one, and another produces two and passes. Two repeats follow the initial eligible observation. The shorthand two stable checks should not be misread as completion after only two snapshots in total.

The signature includes trimmed response text and, for media requests, associated media names and ordinals. Not every original branch includes answer identity in that signature. The shared example adds identity for a narrower comparison and is not introduced as an identical reproduction of the entire original state machine.

Do not count stability when the required evidence is absent

An empty body for a text target clears stable and waits. Media targets likewise require ready corresponding output. Repeatedly observing an empty string is not stable answer evidence. Repetition of the waiting loop and repetition of completion evidence must be different concepts.

Controls requesting user intervention and error responses also remain outside ordinary completion. Some media-unavailability replies become a distinct error after their own stability check. A stable inability statement cannot quietly become evidence that the requested generated artifact is ready. The state name should retain the meaning of the observed result.

Polling intervals do not promise a fixed success time

Until observes, tests, briefly pauses and reads again. The current ordinary interval is six hundred milliseconds, or two seconds for a very long timeout. Those values do not guarantee that every response finishes within a particular duration. Unmet conditions end with a defined error rather than causing another request to be sent.

The earlier local-wait article examined the cost of creating another model turn for every wait. This question concerns what qualifies as completion inside the wait. Reading a run receipt and inspecting service text/media stability use different evidence and conditions despite sharing a repeated-observation shape.

Separate fixture stability from actual-service completion

Existing fixtures begin with partial/streaming output and later return a finished answer. Tests keep the send count at one when reusing the request and distinguish user waiting from completed state. This task read those tests and waitAnswer without asking the original service a new question.

The shared module's thirty-two checks actually reset stability for busy state and changed text, media or answer identity. It accepts increasing declared timestamps rather than sleeping on a real polling interval. Those tests therefore do not measure network latency or the factual accuracy of a provider's final output.

Retain the limits of a stability claim in the result

Three matching observations do not establish permanent finality or truth. They mean the defined completion condition matched within the adapter's observed scope. Large bodies and complex artifacts still need attention to observation bounds and actual file checks. A short state name must not expand the evidence behind it.

I want a completion description the next worker can trust: when generation was active, what repeated and what remains unverified. Those facts allow further inspection without resending the request. Stability observation contributes to that continuity rather than serving as the only judgment that a business purpose was fulfilled.