Stage Runtime Skill

Stage Accelerator Runtime

Scope

Only handles existing stage accelerator instances, stages, tasks, and their runtime data. Do not use it for stage accelerator definitions, nodes, publishing, start or stop, or configuration deletion.

This skill only handles explicitly identified instances, stages, tasks, stage tasks, and business records. Do not treat instance detail, task detail, or validation results as authorization to write.

Tool Routing

Read And Validation Rules

• stage_runtime_back-to-validate is a pure validation read. It may execute directly once the target instance and target stage are confirmed. It only reports whether rollback is allowed and must not automatically call stage_runtime_move-to or stage_runtime_complete-back-to-task.
• stage_runtime_reactive-validate is also validation-only. It may only report whether reactivation is allowed and must not automatically call stage_runtime_reactive.
• stage_runtime_get-task-by-id is the primary read tool for task identity, task state, returned task context, and task-editable data.
• stage_runtime_get-tasks-info-by-instance-id-and-stage-id is the primary read tool for stage-scoped task lists under a known instance.
• stage_runtime_get-instance-id-by-object-id is the record-to-instance lookup path when the user starts from entityId + objectId.
• stage_runtime_query-move-to-result is only for jobId returned by stage_runtime_move-to.

Completion, Editing, And Movement Rules

Regular completion

Use stage_runtime_complete when the task should be completed without changing business fields in the same request.

• Its data is only task-side associated data.
• Do not treat it as field-update JSON.

Default-layout update and complete

Use stage_runtime_update-and-complete when the user needs to update default-layout fields and complete together.

• taskId is required.
• data must be the wrapper object required by the task contract.
• data.updateJson must be a JSON string containing real writable field changes only.

Flow-layout save only

Use stage_runtime_edit only to save flow-layout form data.

• It does not complete the task.
• objectData, details, originalData, and originalDetails are string parameters whose contents must be valid JSON.

Returned task completion

Use stage_runtime_complete-back-to-task when the task is a returned task and the business action is to complete it and move to a target stage.

• Before this write, first run stage_runtime_back-to-validate.
• workflowInstanceId and stageId must both be explicit and confirmed.
• data is for default-layout data.
• flowLayoutEditData is for flow-layout save data and may include taskId, objectData, details, optionInfo, originalData, originalDetails, and notValidate.

Terminal pre-task completion

Use stage_runtime_complete-terminal-pre-task only for terminal-state prerequisite tasks.

• At least one of the required task data payloads must be provided according to the task contract.
• Do not replace it with regular complete.

Rollback and move

Use stage_runtime_move-to only with an explicit target stage.

• When the user is effectively rolling back to an earlier stage, run stage_runtime_back-to-validate first.
• A passed validation is not authorization to execute the move.
• Do not guess "previous stage" or "last stage"; stageId must be explicitly determined.

Reactivation

Before stage_runtime_reactive, first run stage_runtime_reactive-validate.

• Even if validation passes, reactivation still needs a separate write preview and explicit confirmation.
• activeStageId must be explicit and confirmed.

Async Rules

• stage_runtime_move-to may run asynchronously. When it returns jobId, only stage_runtime_query-move-to-result may be used to query that async result.
• Continue async result polling only when the service provides a polling interval such as queryIntervalSecond; otherwise report that the request was accepted and the final state is unverified.
• stage_runtime_complete-back-to-task is special: its async default is true. To force synchronous execution, explicitly pass false.
• For other asynchronous stage operations without a dedicated result-query path in this skill, do not report accepted requests or jobId as final business success.

Write Data Rules

• Arrays and objects must follow the target tool contract exactly.
• Field updates may only use real writable fields returned by task context or explicitly provided by the user.
• Do not fabricate stageId, activeStageId, candidateIds, objectIds, sourceWorkflowId, data, flowLayoutEditData, objectData, originalData, or version-like concurrency fields.
• Risk flags such as ignoreNoBlockValidate, ignoreSkipInNoBlockValidate, noBlockValidate, notValidate, and related bypass fields default to omitted or false.
• Only pass a validation-bypass flag as true when the user explicitly requests it, understands the impact, and confirms that exact flag in the final write preview.

Identifier Contract

• entityId is the business object API name.
• objectId is the business record ID.
• workflowInstanceId is the stage accelerator runtime instance ID.
• stageId is the explicit rollback or move target stage.
• activeStageId is the stage to enter after reactivation.
• taskId is the runtime task ID.
• stageTaskId is the stage task ID and must not be mixed with taskId.
• activityId is only optional task-detail context.
• jobId is only for stage_runtime_query-move-to-result.
• candidateIds must be real user IDs.
• objectIds must be real business record IDs.

Write Secondary Confirmation

Before every write, present a final business-facing preview and wait for an explicit affirmative in a later user message for the same unchanged operation.

• The preview should state the recognizable stage instance or task target, target stage when applicable, field changes or handler or association changes, comment, async choice, and impact scope.
• Do not expose raw tool names, raw payload JSON, or internal IDs unless the user explicitly asks.
• Validation results, parameter clarification, and read-only outputs are not authorization.
• Any change to target, target stage, action, task data, handler list, associated records, async choice, validation bypass flags, or comment invalidates the prior confirmation and requires a new preview.
• After valid authorization, execute the write once. Do not silently chain another write.

Result Reporting

Report the actually executed operation, target, server result, and any read-only verification evidence.

• Only treat the operation as successful when the response clearly proves success.
• For async acceptance without a terminal result, report that the request was accepted and the final business state remains unverified.