A missing image or video can make every failure look like a program defect. Failing to send input differs from delivering it correctly and receiving a provider's inability response. Northstar narrows the diagnosis and preserves absence of the requested artifact instead of substituting another result as success.
First distinguish how far delivery reached
Separate failure to find a tool, failed input verification, unavailable send readiness and a new answer without the required artifact. Similar empty outcomes have different evidence. Current dispatched state can be recorded conservatively before input, so its name alone does not prove the provider received the question.
Actual recorded clicks, replies and original receipts must be considered together. Human authentication is another boundary distinct from an implementation defect. One generic failure state can encourage irrelevant repairs or resending the same request. The observed events should be separated before deciding what needs a fix.
Fixing a sketch-path error is not successful image generation
The actual image-edit record contains an error confusing a sketch screen with a language-input composer. The implementation was corrected to deliver the instruction in the current conversation. The provider then reported inability and no new edited image appeared. Fixing delivery was not reported as successful generation.
The historical record stops a long wait and reads the original reply without resending. It also avoids downloading the original image again as if it were a newly edited result. Repaired program behavior and the artifact produced by an external service need their own evidence, even when they belong to one user request.
Classify refusal together with a new answer and absent media
WaitAnswer inspects recognized unavailability/quota phrases only when a new answer is no longer busy and required ready media are absent. The refusal content must stabilize before GEMINI_MEDIA_UNAVAILABLE. An old refusal elsewhere in conversation or a lone page word cannot directly classify the present request.
This remains a bounded expression pattern, not a model understanding every language, quotation or account condition. Unrecognized wording may still result in a timeout. The account should explain the observed reply and media state rather than claiming automatic diagnosis of the service's underlying cause.
Do not discard ready media merely because refusal words appear
A counterexample test retains completion when refusal-like text accompanies a new ready image in the same answer. Rather than choosing words over artifacts categorically, the path examines the requested media evidence. Mentioning inability in prose does not necessarily mean an artifact is absent.
Conversely, a long explanation cannot satisfy a video request with no new video. Historical requests under different observed model states still retained zero-media outcomes. Those are facts about those executions, not timeless product claims that an account or model can never perform the task.
Separate inspection of an existing failure from a fresh request test
This task compares historical reports and refusal/video proof with current functions and existing tests. It neither resends the original request nor attempts to change the provider's answer. Correct classification in a fixture containing historical wording differs from successful generation of a fresh real artifact.
The shared module stabilizes a declared synthetic unavailable response and returns media_unavailable. It does not classify natural language and keeps business-success verification False even for observed_complete. Its thirty-two unit tests support that contract, not an accuracy statistic for every real-service refusal.
Precise failure diagnosis makes the next step smaller
An implementation error needs a focused reproduction and function fix. Human verification needs a handoff in the existing session. An observed inability reply needs retention of that reply and missing artifact. Unknown causes should remain unknown. Repeating work must not substitute for diagnosis.
I want a program to leave useful evidence even when it fails to produce the customer's desired result. An account of what was attempted, how far it was verified and what is still absent makes the next judgment concrete. Preserving the original outcome is a stronger basis for extensible automation than a success phrase hiding failure.