Using the current tab is convenient until a user explicitly asks for another destination. A site name mentioned inside content must not redirect work either. I first distinguished an actual choice from a word occurring in the material.
Define the default for an unspecified choice
The design defaults generic writing to the tab selected when the request begins. A later research tab differs from that request-time value. A subsequent new request should establish its default from the selection at that later time.
This does not permanently restrict work to one visible screen. Explicit sites, tabs and multiple destinations retain their routes. A default helps omitted choices; it is not an instruction overriding a concrete human selection. Convenience and precedence need to be explained together.
Distinguish an exact tab choice from a site name
The planner handles explicit permitted tab IDs and quoted tab titles. A precise destination ID outranks incidental site names in the prompt being sent. An ID designated as reference is not promoted into a writing choice.
Tests also reject substitution when the requested tab is closed, foreign to the project or outside permitted profiles. The missing choice remains visible. A precise identifier does not remove ownership checks; both the human choice and actual availability need to agree.
A platform label is less specific than a resource address
A named service home can reuse an existing page of that service, while an account path or specific resource needs narrower matching. Sharing a blog platform does not justify choosing another owner's editor. Login labels and resource ownership identifiers differ too.
Candidate ranking uses the current tab, preferred project account and editor status. Ranking is not proof of universal uniqueness. Account conflicts and missing names receive separate ambiguity treatment. The stricter single-candidate synthetic module and the product's ranking policy are not identical implementations.
Do not promote manuscript words into instructions
Routing-instruction extraction separates explicit title-and-body material from preceding routing instructions. Expressions describing an asset's eventual use differ from its generation service. An image for a blog made in Gemini has Gemini as the current generation destination.
These are rules for known Korean and English expressions, not perfect interpretation of every sentence. Tests should show which expressions support a choice rather than silently broadening exceptions. Material that does not specify a destination must not be treated as the user's actual routing instruction.
Separate historical routing from current MCP responsibility
The earlier embedded CLI used such planning before starting work. Current manual MCP begin is a different entry receiving explicit context. The browser cannot be described as internally using a model to select tabs from every natural-language request. The external caller must inspect and bind the actual destination.
This account compares retained functions, tests and historical documentation. I performed no new live account switch or writing. A stored account label also differs from live authentication. Useful defaults reduce repeated choice without removing current identity and scope checks.
Visible precedence makes automation easier to repair
Company-specific software combines common defaults with exceptional requests. Without precedence, convenience and risk become hard to distinguish. Tab selection needs an explicit relationship among request, precise choice, permitted scope and candidate criteria.
This is not a reason to ask the user every question again. Clear choices should be used directly while genuinely missing information remains visible. Knowing the selection basis lets a repair add the needed condition without arbitrarily changing an account or manuscript.