I wanted both Python and notebook entry points without maintaining two copies of the browser procedure. Separate click code would invite one version to drift after a fix. I kept presentation and input review appropriate to each format while sharing the definition and host execution route that perform the work.
Both library entry points start from the same definition
Runner start loads one program and selects Python or notebook mode. Python launches the companion workflow; notebook mode passes the notebook and result location to the shared notebook runner. Inputs and run identity come from the same preparation. Two menu choices do not create two business definitions.
Definition hashing and selected-file checks happen before execution rather than disappearing in notebook mode. Changing the presentation format should not weaken those boundaries. Native exceptions such as capture remain separate, so the architecture should not be described as forcing every plugin through a Python child process.
The SDK does not create another browser
Browser recipe calls use the run connection, credentials and identity supplied by the host. They do not launch another Chrome or copy cookies to establish login. The host validates the current run and forwards to the common recipe engine, retaining semantic-target and action checks in that execution route.
This connection is not an operating-system sandbox or complete protection against hostile code under the same user account. General local Python capabilities differ from the browser SDK contract. Shared transport means the workflow converges on one route; it does not remove every concern associated with running local code.
Use notebook cells to review the shared procedure in stages
The generated notebook creates a Workflow and input items. Preparation exposes material and destination, run performs work, and status reads results. Explanatory cells guide the operator without duplicating browser-click implementation in each cell.
A library-launched single run and an operations notebook opened inside a project use different adapters. One calls Browser through the run connection; the other uses host preparation and item-run tools. Sharing the business route does not mean those adapters have identical lifetimes or resume rules. That distinction needs to remain visible in the notebook instructions.
Distinguish a repeated cell from a new business run
Within a library run connection, the same key and inputs share an existing promise. A project operations notebook instead retains job identity, item identity, input fingerprint and definition digest in its journal. Reusing a finished cell result and beginning another occurrence therefore belong to different layers.
Legitimate new work needs a new execution context, but changing an identity to evade unresolved-outcome protection is not legitimate continuation. Treating every adapter as identical would conceal that difference. One definition can serve several views while each button still needs an explainable work lifetime. Detailed duplicate protection is examined separately.
Compare changed inputs with actual retained results
The existing library UI scenario enters data into a fixture iframe through Python and reads the resulting CSV bytes. After restart it runs notebook mode with another input, checks that the linked automation tab is not duplicated and inspects executed notebook cells. That examines behavior beyond merely finding both menu names.
This content work reads those tests and implementation without rerunning the application. The shared synthetic module compares CLI and its authored notebook code-cell plans within twenty-two tests. It does not verify a separate Jupyter kernel or remote Studio connector. Each verification scope remains identified rather than combined into a broader compatibility claim.
Reduce duplicated logic while explaining each entry point
Sharing fixed workflow logic reduces the places where a common defect must be repaired. It still leaves the task of explaining preparation and results appropriately to Python and notebook users. Code reuse alone does not make the operating flow understandable.
A website administrator and management CLI have the same relationship: one requests through a visual interface, the other through commands and data. Core validation and storage can remain shared while each entry presents accurate state. Supporting several tools is therefore less about multiplying independent implementations than connecting them to one business contract with clear operating boundaries.