A successful draft check did not necessarily describe the draft being requested. Recent development records contain a case where a check started from another draft still succeeded. The comparison condition itself was not the central problem: the program had substituted a historically bound tab for the requested subject. I read the retained failure account alongside the changed source and revisited the need to bind a result to its subject.
Checking the matching draft twice was not enough
The existing report records two successful checks on reference draft A, followed by another success when the request came from different draft B. The run identified A as its main target while the request context identified B. It had repeatedly established that A matched the reference. Applying a correct condition to the wrong material can make a success record conceal the problem.
I therefore inspected target selection before interpreting the content comparison as success or failure. I did not reproduce that original live run while writing this article. This is a maker review of the retained false-positive account, the subsequent correction report, and the remaining functions and tests. The explanation concerns selection structure and does not disclose customer drafts or account contents.
A saved program binding had a legitimate original purpose
The ordinary program-tab reuse function first looks for a tab already bound to that program. Remembering a previous writing location can be useful for repeated work. The problem appeared when the same priority was used for a preflight whose job was to read the requested draft. Returning to a historically successful location changes the question that a current-state check is answering.
Earlier articles distinguish writing destinations from reference tabs and current requests from old recommendations. This case asks a different question: even between similar editors on the same service, can a read-only result be attached to the wrong draft? The correction narrows which kind of program must remain bound to its request instead of replacing every general writing-destination policy.
Classify an inspection from its steps rather than its name
isReadOnlyCheck identifies a nonempty Recipe whose steps are all verify operations and which declares no auxiliary tabs. A program is not treated specially just because its name says inspection. Empty definitions, definitions containing input steps, and multi-tab definitions do not enter this narrow path. The program runner derives the internal readOnlyCheck value from those conditions.
I do not describe this as a new public boolean that a caller can assert to acquire the special behavior. What matters is a matching definition reaching the host's limited read path. Read-only also does not mean zero host-state changes: the code still handles ownership, selection and loading. Its relevant preservation boundary avoids navigation, new tabs and overwriting the existing automation binding.
Do not replace a missing explicit tab with another candidate
The new selector prefers the defaultTabId captured for the request and uses currentTabId only when that explicit default is absent. An explicit identifier that cannot be found does not silently fall back to another candidate. The tab must have the matching profile and workspace and the exact URL, and an auxiliary alias cannot expand the check into another-tab flow. Two tabs at the same address can still be different inspection subjects.
The host borrows the selected page without overwriting its automationKey. That preserves another publisher program's binding instead of letting the preflight take it over. The function does not authenticate a login or establish the semantic identity of a draft. Its identifier, scope and URL checks precede the separate title and body conditions that inspect the requested content.
Failure on the other draft was the required result
The existing installed-version report records a pass on the reference draft, a content mismatch on the other draft, and another pass when the same check is reused on the reference. The middle failure is a correct rejection of a draft that differs from the reference, rather than evidence that the feature broke. The sequence tests reuse without borrowing the success of the old tab.
The original unit-test file also addresses requested-tab priority, preservation of bindings, and rejection of a missing identifier or a different account, workspace, URL or alias. I read those tests and reports but did not rerun the original product tests, installation or live site here. Historical evidence that the false-positive receipt was retained is not counted as a new execution achievement of this article.
A passing preflight does not automatically bind the next write
This correction concerns where a limited inspection program reads. The report explicitly leaves unfinished a common connection that would bind every downstream writing workflow to the inspected tab. If a tab or draft changes after inspection, the earlier result must not become permission for the next input. How subject and time remain connected to subsequent work is a separate contract.
I reused the existing request-bound-work-context module as the shared material. Its current public ZIP was downloaded again, checked for byte count and hash, and extracted for eighteen synthetic tests. It is a pure rule for explicit tab, profile and workspace selection and for separating destination from references. It verifies no actual URL, draft, login, read-only classification or downstream write binding. The link lets readers inspect a starting point without attaching guarantees from a different implementation.