Changing a model name alone was not enough to establish an image-generation path. Chat mode, model selection, a dedicated tool and existing input coexist on the page. Northstar separates what each selection changes and avoids treating an enabled menu as successful generation.
Keep mode, model and capability as separate inputs
The execution contract separates mode, model/power and feature. Empty model or power preserves the current site selection, while an image or video feature follows dedicated-tool selection. A visible model menu and a selected generation tool are different state. One value should not erase the user's distinct choices.
This does not assume identical menus across services. The procedure reads exact names and states actually supplied by the page and returns a relevant error for absence or ambiguity. Knowing a menu label is not proof that an account has the capability. Registered feature families remain distinct from actual availability in the service.
Treat more-tools menus and new-chat requirements as state
Gemini chooseTool checks the add menu and observes a recognized more-tools section if the requested tool is absent. A candidate must be unique, and an already checked choice is not clicked again. A new-chat prompt proceeds only under the explicit option; otherwise the dialog is closed and an error preserves the existing conversation.
Opening a menu does not create an artifact. Actual sending, a new response and ready requested media are checked later. Inflating tool-selection success into complete generation can hide provider refusal or account restrictions. Starting-path readiness and final output therefore receive separate records.
Distinguish tool-inserted text from a person's draft
Selecting a tool can place its own name in an empty composer. Treating every such label as a user draft blocks valid work; treating every label as disposable risks erasing actual writing. The code accepts selectedToolDraft only when the composer was empty beforehand and the exact tool name appeared immediately after its own selection.
Unrelated user text is preserved before tool selection. Existing tests separate the exact tool label from another draft and require no fill in the latter case. Timing and the procedure's own action provide a narrower basis than guessing from similar words. The exception should identify its own transient text, not authorize general clearing.
A model change does not erase an unavailability response
The actual record checks video-tool selection and different model states before requests, yet neither produces new video. I do not turn that into a timeless claim that a particular model cannot generate video. It remains an observation of those account, screen and input conditions, including absence of a new artifact.
Image editing likewise distinguishes an implementation error confusing a sketch window with a composer from a correctly delivered instruction followed by provider refusal. Fixing the former cannot certify success of the latter. Entering the correct tool path and obtaining the requested service result are different evidence.
Recheck the actual UI even when familiar words appear
One test reports a missing requested mode instead of ending in a generic property-access exception. Another handles real mode buttons without exposed pressed state rather than inventing their meaning from a model selector. Diagnosis is more useful when it preserves differences in the screen contract.
This task read original functions, existing tests and historical records without making a new model or tool selection. The independent generation observer is not a menu selector either. Its results cannot establish actual compatibility of a tool/model combination. The handover must connect what was observed with what remains unverified.
Preserve the meaning of the result alongside selection convenience
A customer need not memorize internal feature names, but should be able to read what was prepared and what actually resulted. Separating tool selected, request delivered and new media ready makes a stopping point concrete.
I want service management to be described through the relationship between selection and outcome, rather than the number of buttons automation can press. Distinguishing menu presence, current model and actual artifact narrows the distance between a program's claim and the work performed. Those small distinctions make future operation and diagnosis easier.