An agent can announce completion before the browser has checked the result. I separated task start, operation and finish, refusing the final completion request while an input outcome remained unproven. A finished sentence must not stand in for finished work.
Starting needs a goal and a current context
Begin receives a concrete context and goal, checks the current profile and project and refuses a conflict with running program or notebook work. Missing goals fail explicitly. An execution ID is not created as an empty container whose purpose can be invented later.
Start then passes through the existing current-tab selection route. If that fails, the error finishes that attempted task and returns to the caller. The presence of an ID alone does not establish successful preparation of the first page operation. Acceptance and readiness need distinct inspection.
A task ID is not a reusable permit for any next action
Call requires the current task ID, program execution kind and running state, with matching profile and project. A finished task's ID cannot authorize another input. Nor can a caller silently substitute whichever other task is running.
The controller passes the current execution epoch to the Broker. Validation therefore concerns not merely an identifier's shape but the lifetime of the execution receiving the action. Binding the journal ID to the actual current work prevents old context from becoming a new operation.
Refuse completion while an outcome is unproven
Finish checks the controller's pending outcome and fails if one remains. Both the convenience API's blocked state and the host-side condition matter; another wrapper cannot remove the host check.
An unresolved outcome is not automatically converted into a definitive failure either. The caller can inspect the original result or stop as appropriate. Finish is nevertheless not a universal verifier of business meaning. Correct step expectations and necessary result checks remain caller responsibilities.
Separate task completion from reusable-asset creation
A normal finish can request automatic retention of a repeatable procedure. A workflow draft meeting step and action criteria is passed to the existing library. Every brief read need not become another program; retention has its own eligibility conditions.
A retention error creates an event explaining that automatic storage is incomplete. Work already performed and creation of a future reusable asset are not merged into one success sentence. The result may be complete without a reusable program. Recording that distinction avoids assuming such a program exists next time.
Retain specific refusal cases
The integration test ensures that finish does not reach completion while a task has a pending outcome. It also rejects calls with another task ID. Page-API tests check that uncertain Enter blocks finish and further input while permitting reads.
I compared those tests with the current handler and controller. This is not another live article-publication test. Running does not mean correct, and succeeded concerns the conditions that implementation checked. Interpreting either state requires the task-specific expectations and results beside it.
Do not hide responsibility behind a completion label
A screen may offer one finish button, but the implementation should explain what was checked. Separately retaining start, execution, verification and storage makes the customer-facing explanation more precise. Sending input differs from observing its result at the service.
For another program, inspect the function creating completion and identify unresolved conditions that can still exist before it. An agent may request finish, but its wording must not erase an outcome the executor could not verify. That is the core of this task-lifecycle design.