@uipath/skills 1.196.0 → 1.197.0

package/skills/uipath-maestro-bpmn/references/author/references/planning-impl.md

@@ -1,104 +0,0 @@
-# Planning Implementation
-
-Use this reference for pass 2 of BPMN authoring: fill the model-owned UiPath extension XML after the BPMN skeleton has been confirmed.
-
-## Pass 2 goal
-
-Pass 2 makes the confirmed skeleton locally coherent for validation and packaging:
-
-- Root variables and scoped subprocess variables.
-- Entry point IDs on runnable root start events.
-- Variable mappings on tasks, events, scripts, subprocesses, and ends.
-- Lint-compatible expressions using [expression-authoring.md](../../shared/expression-authoring.md).
-- Resource bindings for documented non-Integration-Service service shells and
-  the plain connectionless HTTP recipe.
-- Script task metadata and input/output mapping.
-- Retry, error mapping, multi-instance metadata, UiPath transaction-root marker,
-  and tags when specified.
-- Draft Integration Service intent handed to CLI enrichment.
-
-## Fill order
-
-1. **Entry points** - add `uipath:entryPointId` to root start events that should be runnable.
-2. **Variables** - add root `uipath:variables` for entry point inputs, process globals, outputs, and schemas; add subprocess variables only when scope requires them.
-3. **Mappings** - add `uipath:mapping` where values move between variables, task inputs, task outputs, and end outputs.
-4. **Bindings** - add root `uipath:bindings` only for documented non-Integration-Service resources or placeholder-safe binding shapes.
-5. **Task shells** - add documented non-Integration-Service `uipath:activity` or `uipath:event` metadata, or the plain connectionless HTTP recipe, when the task wrapper and service type contract are known. Use [supported-elements.md](supported-elements.md) and [task-recipes/](task-recipes/) before writing XML.
-6. **Scripts** - add BPMN script CDATA, `uipath:scriptVersion`, merged `args` input, schema, and outputs.
-7. **Runtime behavior metadata** - add retry, error mapping, documented
-   multi-instance characteristics, UiPath transaction-root marker, or tags only
-   when user intent is explicit. Use [error-handling.md](../../shared/error-handling.md)
-   for retry, boundary error, event subprocess, and error mapping shapes. Do not
-   generate `bpmn:transaction`; it is preserve-only.
-8. **CLI-owned enrichment** - hand Integration Service activities/triggers and generated package metadata to the CLI.
-
-## Variables
-
-Root variables define the public entry point contract and process-wide data. Use stable IDs and preserve existing IDs during brownfield edits unless renaming is required.
-
-- `uipath:input` is read-only entry input.
-- `uipath:inputOutput` can be updated during execution.
-- `uipath:output` is emitted by entry point outputs.
-- `elementId` scopes entry inputs to the root start event that owns the entry point.
-- JSON schema variables store schema content in CDATA.
-- Do not move a variable between root and subprocess scope without checking every mapping and expression.
-
-## Bindings
-
-Root bindings describe resources that packaging turns into `bindings_v2.json`.
-
-- Use expressions in service context values: `=bindings.<binding id>`.
-- Keep `resourceKey`, `resourceSubType`, and `propertyAttribute` placeholder-safe unless a public-safe value is provided.
-- Do not paste connection IDs, folder keys, URLs, queue IDs, release keys, or tenant-specific names.
-- Let the CLI generate or enrich binding resources for Integration Service and dynamic schemas.
-
-## Expressions
-
-- Use a leading `=` where Maestro expects an expression.
-- Treat strings without `=` as literals.
-- Avoid assignment operators in condition, skip, and mapping expressions where fields require read-only expression evaluation.
-- Keep gateway condition expressions on sequence flows, not on the gateway itself.
-- Keep script source in BPMN `script` CDATA with `scriptFormat="JavaScript"`.
-- Read [expression-authoring.md](../../shared/expression-authoring.md) before
-  writing `vars`, `result`, `bindings`, `iterator`, or `vars.error` references.
-
-## Non-Integration-Service task shells
-
-The model may fill documented non-Integration-Service shells only when the required fields are known and public-safe. Examples include variable mappings, script tasks, Orchestrator process/agent/API workflow starts, business rules, queue item creation, HITL, message events, and supported agent execution shells.
-
-Wrapper choices are not optional:
-
-- RPA, agent, API workflow, A2A, and create-and-wait queue work use `bpmn:serviceTask`.
-- Queue create uses `bpmn:sendTask`.
-- Business rules use `bpmn:businessRuleTask`.
-- HITL uses `bpmn:userTask`.
-- Agentic and case-management process calls use `bpmn:callActivity`.
-- Script work uses `bpmn:scriptTask`.
-
-For every shell:
-
-- Include the correct `uipath:type` service type and version only when documented.
-- Add required `uipath:context` fields inside `uipath:activity` or `uipath:event`.
-- Add task payload inputs and output mappings in a sibling
-  `uipath:mapping version="v1"` element.
-- Use CDATA for JSON payload `uipath:input` bodies and target declared
-  variables with `uipath:output var="..."`.
-- Validate that each binding or variable reference resolves.
-
-## Integration Service handoff
-
-For connector-backed or dynamically schematized `Intsvc.*` activities and triggers, pass 2 should stop at the enrichment boundary unless registry-backed CLI output is available. Confirmed plain connectionless HTTP is the documented pass-2 exception and must follow [task-recipes/http-request.md](task-recipes/http-request.md).
-
-The CLI must own:
-
-- Connector key, operation/event, object, and version metadata.
-- Selected connection binding and generated resource metadata.
-- Trigger property bindings.
-- Dynamic input/output schemas and generated output metadata.
-- `bindings_v2.json` entries.
-
-If the CLI cannot enrich yet, leave a clear blocker in the summary and do not treat the project as ready for Operate.
-
-## Done state
-
-Pass 2 is done when model-owned XML is complete, Integration Service enrichment is either complete or explicitly blocked, generated package files are current or intentionally absent, and validation has been run.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/agents/impl.md

@@ -1,34 +0,0 @@
-# Agent Implementation
-
-This document defines the implementation boundary for agent task recipes. Agents are implemented as `bpmn:serviceTask`; see [task-recipes/agent-job.md](../../task-recipes/agent-job.md) for the per-deployment-style shell decision table.
-
-## Model-owned implementation
-
-The model may edit:
-
-- `bpmn:serviceTask` wrapper for agent invocation.
-- Draft `Orchestrator.StartAgentJob` activity shell only for folder-deployed
-  dependencies confirmed as `processType: "Agent"`. Use resolved process
-  identity context from the current shell guidance, generated bindings, and
-  current input/output schema metadata.
-- `A2A.AgentExecution` activity shell for external A2A agents addressed by URL/skillId/authToken.
-- Input CDATA for public-safe invocation payloads.
-- Output mappings for job ID, status, result, and structured fields.
-- Timeout/error boundary events and validation gateways.
-
-## CLI or operator-owned implementation
-
-The CLI or operator must resolve:
-
-- Real agent resource identity, version, folder, and binding metadata.
-- Dynamic schemas for agent inputs and outputs.
-- Deployment, creation, or modification of the agent itself.
-
-## Validation expectations
-
-- Agent resource binding resolves before upload/run. For `StartAgentJob`, local
-  validation only proves source and package structure; an authorized run in the
-  target environment is required before claiming runtime behavior.
-- Input variables and output variables exist.
-- Timeout and invalid-output paths are modeled when needed.
-- High-impact outputs have review or validation gates when required by user intent.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/agents/planning.md

@@ -1,38 +0,0 @@
-# Agent Planning
-
-Use this reference when planning agent execution from BPMN. Agents are resource recipes for `bpmn:serviceTask`, not peer BPMN element types. See [task-recipes/agent-job.md](../../task-recipes/agent-job.md).
-
-## When to use
-
-- Starting a UiPath agent job.
-- Calling an A2A or external agent execution shell.
-- Routing based on agent status, answer, or structured output.
-- Combining agent work with HITL validation, RPA jobs, or business rules.
-
-## Planning steps
-
-1. Identify agent type, invocation style, input contract, output contract, and timeout behavior.
-2. Decide whether the agent resource already exists or must be created by a sibling workflow outside this skill.
-3. Plan variables for prompt/input, structured output, status, and errors.
-4. Add validation or HITL review if agent output affects high-impact decisions.
-5. Use placeholder-safe bindings for agent resources.
-6. Plan fallback paths for timeout, no answer, or invalid output.
-
-## Model may draft
-
-- `bpmn:serviceTask` wrapper with the wrapper shell that matches the process
-  type and invocation style (`Orchestrator.StartAgentJob` draft shell for
-  folder-deployed dependencies confirmed as `processType: "Agent"`;
-  `A2A.AgentExecution` for external A2A; `Intsvc.*AgentExecution` for
-  Integration Service external agents). See
-  [../../task-recipes/agent-job.md](../../task-recipes/agent-job.md) for the
-  decision table.
-- For `Orchestrator.StartAgentJob`, resolved process identity context and
-  generated process bindings from the current shell guidance. Do not treat
-  local validation as proof of executable agent invocation.
-- Input/output mappings, boundary timeout/error paths, and gateways.
-- Public-safe resource placeholders.
-
-## Stop conditions
-
-Stop before Operate when agent identity, version, input schema, output schema, or resource binding is unresolved.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/api-workflows/impl.md

@@ -1,37 +0,0 @@
-# API Workflow Implementation
-
-This document defines the implementation boundary for API workflow task recipes. API workflows are implemented as `bpmn:serviceTask`; see [task-recipes/api-workflow.md](../../task-recipes/api-workflow.md).
-
-Use the canonical shell from
-[shared/wrapper-shells.md](../../../../shared/wrapper-shells.md): a
-`bpmn:serviceTask` containing `uipath:activity version="v1"` and nested
-`uipath:type value="Orchestrator.ExecuteApiWorkflowAsync" version="v1"`,
-with request and result payloads as direct `uipath:activity` children.
-Do not author new API workflow XML with legacy
-`<uipath:activity type="Orchestrator.ExecuteApiWorkflowAsync">` shorthand.
-
-## Model-owned implementation
-
-The model may edit:
-
-- `bpmn:serviceTask` wrapper for API workflow execution.
-- Documented `Orchestrator.ExecuteApiWorkflowAsync` `uipath:activity` shell.
-- Request input CDATA in `uipath:activity` using `vars.<variableId>` references.
-- `uipath:activity` outputs for invocation result and errors.
-- Retry and boundary error metadata when specified.
-
-## CLI or operator-owned implementation
-
-The CLI or operator must resolve:
-
-- Real API workflow resource identity and folder binding.
-- Dynamic request and response schemas.
-- Generated binding resources and package metadata.
-
-## Validation expectations
-
-- Workflow binding resolves before upload/run.
-- Request body matches the resolved schema.
-- Output mappings target declared writable variable ids.
-- Fire-and-forget versus wait behavior is explicit.
-- No private endpoint URLs, resource IDs, or exported payloads are committed.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/api-workflows/planning.md

@@ -1,28 +0,0 @@
-# API Workflow Planning
-
-Use this reference when planning API workflow execution from BPMN. API workflows are resource recipes for `bpmn:serviceTask`, not peer BPMN element types. See [task-recipes/api-workflow.md](../../task-recipes/api-workflow.md).
-
-## When to use
-
-- Calling an Orchestrator API workflow asynchronously.
-- Passing structured request data to an API workflow.
-- Routing based on workflow status or structured response.
-- Combining API workflows with connector, agent, RPA, or HITL steps.
-
-## Planning steps
-
-1. Identify API workflow resource, input schema, output schema, timeout, and error behavior.
-2. Decide whether execution is fire-and-forget or waits for completion.
-3. Plan request variables, response variables, job/status variables, and mapping.
-4. Add retries or boundary errors for transient failures.
-5. Use placeholders until the API workflow binding and schemas are resolved.
-
-## Model may draft
-
-- `bpmn:serviceTask` wrapper with documented `Orchestrator.ExecuteApiWorkflowAsync` shell.
-- Input/output mappings and public-safe request examples.
-- Boundary error paths and gateways.
-
-## Stop conditions
-
-Stop before Operate when workflow identity, schema, binding, or wait semantics are unresolved.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/business-rules/impl.md

@@ -1,36 +0,0 @@
-# Business Rule Implementation
-
-This document defines the implementation boundary for business rule task recipes. Business rules are implemented as `bpmn:businessRuleTask`; see [task-recipes/business-rule.md](../../task-recipes/business-rule.md).
-
-Use the canonical shell from
-[shared/wrapper-shells.md](../../../../shared/wrapper-shells.md): a
-`bpmn:businessRuleTask` containing `uipath:activity version="v1"` and nested
-`uipath:type value="Orchestrator.BusinessRules" version="v1"`, with fact and
-result payloads as direct `uipath:activity` children.
-Do not author new business rule XML with legacy
-`<uipath:activity type="Orchestrator.BusinessRules">` shorthand.
-
-## Model-owned implementation
-
-The model may edit:
-
-- `bpmn:businessRuleTask` wrapper.
-- Documented `Orchestrator.BusinessRules` `uipath:activity` shell.
-- Input CDATA for facts in `uipath:activity` using `vars.<variableId>` references.
-- `uipath:activity` outputs for rule result, matched rule, diagnostics, and outcome.
-- Gateway conditions that route by declared rule outputs through `vars.<variableId>`.
-
-## CLI or operator-owned implementation
-
-The CLI or operator must resolve:
-
-- Real business rule resource identity, version, and binding metadata.
-- Dynamic input/output schemas.
-- Generated package metadata.
-
-## Validation expectations
-
-- Rule binding resolves before upload/run.
-- Facts match the resolved rule input contract.
-- Result variables exist and route expressions are assignment-free.
-- Fallback or manual review paths exist when rule failure is recoverable.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/business-rules/planning.md

@@ -1,29 +0,0 @@
-# Business Rule Planning
-
-Use this reference when planning business rule execution from BPMN. Business rules are `bpmn:businessRuleTask`, not generic service tasks. See [task-recipes/business-rule.md](../../task-recipes/business-rule.md).
-
-## When to use
-
-- Evaluating rule tables or decision logic managed outside the BPMN diagram.
-- Routing based on a rule result.
-- Keeping business decisions separate from script code or gateway expressions.
-- Combining rule evaluation with HITL review, queueing, RPA, or API workflow calls.
-
-## Planning steps
-
-1. Identify rule resource, input facts, output shape, and decision routes.
-2. Decide whether rule failure should stop, retry, or route to manual review.
-3. Declare variables for facts, result, diagnostics, and selected outcome.
-4. Add a gateway after the rule task when result values drive routing.
-5. Use placeholder-safe bindings until the rule resource is resolved.
-
-## Model may draft
-
-- `bpmn:businessRuleTask` wrapper with documented `Orchestrator.BusinessRules` shell.
-- Input/output mappings and post-rule gateway conditions.
-- Retry and boundary error paths.
-- Public-safe binding placeholders.
-
-## Stop conditions
-
-Stop before Operate when rule identity, input schema, output schema, version, or binding is unresolved.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/call-activity-subprocess/impl.md

@@ -1,67 +0,0 @@
-# Call Activity and Subprocess Implementation
-
-This document defines the implementation boundary for call activities and subprocesses. For agentic or case-management process calls, see [task-recipes/call-activity.md](../../task-recipes/call-activity.md).
-
-## Model-owned implementation
-
-The model may edit:
-
-- `bpmn:subProcess`, event subprocess, and `bpmn:callActivity`.
-- Nested events, tasks, gateways, flows, and diagram planes.
-- Scoped variables and `uipath:mapping` for boundary data.
-- Boundary events, retries, and error mappings.
-- Placeholder-safe called element references when documented.
-
-## Subprocess rules
-
-- Use inline `bpmn:subProcess` when the work stays in the local BPMN source and
-  needs local tasks, gateways, variables, or boundary handlers.
-- Keep sequence flows inside the subprocess scope. Do not connect a nested node
-  directly to a root-level node.
-- Put subprocess-local variables in the subprocess extension elements only when
-  they should not be root state.
-- Use root variables for data that must leave the subprocess.
-- Expanded subprocesses need visible child shapes and edges in the diagram.
-- Collapsed subprocesses may show only the wrapper shape, but nested content
-  still needs a product-supported diagram strategy before upload.
-
-## Event subprocess rules
-
-- Use event subprocesses for scoped error or message handling, not as generic
-  containers.
-- Set `triggeredByEvent="true"`.
-- Give the event subprocess exactly one start event.
-- For error event subprocesses, use a supported error start definition and the
-  shapes from [error-handling.md](../../../../shared/error-handling.md).
-- Prefer a boundary error event when one activity owns the failure branch.
-  Prefer an event subprocess when the scope needs a shared fallback handler.
-
-## Call activity rules
-
-- Use `bpmn:callActivity` when execution leaves the local BPMN scope for an
-  agentic, case-management, or other called process contract.
-- Keep called-resource identity placeholder-safe until the CLI or operator
-  resolves the actual resource.
-- Put call inputs and outputs in the same mapping pattern as other activities:
-  payload inputs read `=vars.<variableId>` and outputs target declared mutable
-  variable ids.
-- Add boundary events and retry/error mapping only when the called process
-  contract makes the error behavior explicit.
-- Do not inline a called process into a subprocess unless the user explicitly
-  wants a local copy of the child workflow.
-
-## CLI or operator-owned implementation
-
-The CLI or operator must resolve:
-
-- Real called process, package, API workflow, agent, or solution resource identity.
-- Generated bindings and package metadata.
-- Dynamic input/output schemas for called resources.
-
-## Validation expectations
-
-- Sequence flows stay within subprocess scope.
-- Event subprocess start rules are satisfied.
-- Call activity inputs and outputs match declared contracts.
-- Nested visible elements have diagrams.
-- Called-resource bindings are resolved before upload/run.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/call-activity-subprocess/planning.md

@@ -1,29 +0,0 @@
-# Call Activity and Subprocess Planning
-
-Use this reference when planning reusable or scoped process blocks. For agentic or case-management process calls, see [task-recipes/call-activity.md](../../task-recipes/call-activity.md).
-
-## When to use
-
-- Expanded subprocesses for local scoped work.
-- Event subprocesses for scoped exception handling.
-- Call activities for reusable processes or external workflows.
-- Isolating variables, retries, and boundaries.
-
-## Planning steps
-
-1. Decide whether the work is local subprocess content or a call to another reusable process.
-2. Define subprocess start/end behavior, variables, and mappings.
-3. Confirm whether nested content must render in Studio Web and needs its own diagram.
-4. Plan boundary events on the activity or subprocess.
-5. Keep sequence flows inside scope; use mappings for data crossing boundaries.
-6. Record unresolved called-resource bindings as placeholders.
-
-## Model may draft
-
-- `bpmn:subProcess`, event subprocess, and `bpmn:callActivity` structure.
-- Scoped variables, input/output mappings, loop metadata, and diagram geometry.
-- Boundary events and error paths.
-
-## Stop conditions
-
-Stop when a called process/resource is unknown, subprocess scope would be crossed by sequence flows, or input/output contracts are unclear.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/connectors/impl.md

@@ -1,29 +0,0 @@
-# Connector Implementation
-
-This document defines the implementation boundary for connector-backed BPMN elements.
-
-## Model-owned implementation
-
-The model may edit:
-
-- Standard BPMN wrapper elements around connector intent.
-- Variables and mappings that consume connector outputs.
-- Error, timeout, and fallback paths.
-- Diagram geometry.
-
-## CLI-owned implementation
-
-The CLI or registry-backed tool must generate:
-
-- `Intsvc.*` `uipath:activity` or `uipath:event` payloads.
-- Connector key, operation/event, object, and version context.
-- Connection binding expressions and `bindings_v2.json` resources.
-- Dynamic input/output schemas and generated output metadata.
-- Trigger property bindings for connector triggers.
-
-## Validation expectations
-
-- Every executable connector element has enriched context, inputs, outputs, and schemas.
-- Binding expressions resolve.
-- Required parameters and filters are present.
-- No tenant URLs, connection IDs, folder keys, or copied exported metadata are committed.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/connectors/planning.md

@@ -1,33 +0,0 @@
-# Connector Planning
-
-Use this reference for connector-backed activities and triggers. Connector execution is Integration Service-owned.
-
-## When to use
-
-- Connector activities.
-- Connector triggers.
-- Connector-backed waits.
-- Unified HTTP or authenticated HTTP through Integration Service.
-- Dynamic connector schemas.
-
-## Planning steps
-
-1. Identify connector, operation or event, object, filters, inputs, outputs, and failure behavior.
-2. Decide if the connector is a start trigger, intermediate wait, service task, or boundary behavior.
-3. Plan surrounding BPMN structure and variables.
-4. Record required operator choices: connection, folder scope, operation, filters, and output variable names.
-5. Leave enrichment to the CLI before validation for upload/run.
-
-## Model may draft
-
-- Placeholder BPMN wrappers with stable IDs and public-safe labels.
-- Surrounding flows, gateways, variables, and error paths.
-- Draft notes that describe connector intent.
-
-## CLI must provide
-
-- Connector metadata, operation/event metadata, connection binding, trigger properties, schemas, and generated binding resources.
-
-## Stop conditions
-
-Stop before Operate if the connector element is not CLI-enriched or if copied private connection metadata appears in the source.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/gateways/impl.md

@@ -1,32 +0,0 @@
-# Gateway Implementation
-
-This document defines the implementation boundary for BPMN gateways.
-
-## Model-owned implementation
-
-The model may edit:
-
-- `bpmn:exclusiveGateway`, `bpmn:inclusiveGateway`, `bpmn:parallelGateway`, and `bpmn:eventBasedGateway`.
-- Incoming and outgoing `bpmn:sequenceFlow` references.
-- `default` attributes for exclusive and inclusive split gateways.
-- `bpmn:conditionExpression` on outgoing flows.
-- Gateway shapes and sequence flow edges.
-
-## Implementation rules
-
-- Store branch logic on outgoing sequence flows, not on the gateway element.
-- Use a leading `=` for runtime expressions where Maestro expects expressions;
-  follow [expression-authoring.md](../../../../shared/expression-authoring.md).
-- Do not use assignment expressions in gateway conditions.
-- Prefer explicit default flows for fallthrough paths.
-- Use parallel gateways only when every branch should run or rejoin.
-- Use event-based gateways only when the next route is determined by the first event that occurs.
-- Do not generate `bpmn:complexGateway`; preserve imported complex gateways only.
-
-## Validation expectations
-
-- Split gateways have the right number of outgoing flows.
-- Join gateways have the right number of incoming flows.
-- Defaults reference an outgoing flow from the same gateway.
-- Conditional branches reference declared variables with `vars.<variableId>`.
-- Event-based gateway outgoing flows lead to valid catch events or receive tasks.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/gateways/planning.md

@@ -1,34 +0,0 @@
-# Gateway Planning
-
-Use this reference when planning BPMN routing, branching, and joining.
-
-## When to use
-
-- Exclusive, inclusive, parallel, or event-based decisions.
-- Merging alternative paths.
-- Joining parallel or inclusive work.
-- Waiting for one of several events.
-
-## Planning steps
-
-1. Identify whether the gateway splits, joins, or does both.
-2. Choose the simplest gateway type that matches the business semantics.
-3. Put human-readable branch intent on outgoing sequence flows.
-4. Decide the default route for exclusive and inclusive splits.
-5. Decide join semantics for parallel and inclusive branches.
-6. Ensure no sequence flow crosses subprocess or participant scope.
-7. Plan diagram placement so conditions and routes are reviewable.
-
-## Model may draft
-
-- Standard gateway elements.
-- Outgoing sequence flow conditions and default flow references.
-- Public-safe IDs, names, and diagram geometry.
-- Text annotations that explain unresolved business decisions.
-
-## Stop conditions
-
-Stop for user input when branch conditions are ambiguous, defaults are unknown, or a join can deadlock because the triggering split semantics are unclear.
-
-Do not plan new `bpmn:complexGateway` paths. Preserve imported complex gateways
-and report them as unsupported for regeneration.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/hitl/impl.md

@@ -1,42 +0,0 @@
-# HITL Implementation
-
-This document defines the implementation boundary for HITL task recipes. HITL is implemented as `bpmn:userTask`; see [task-recipes/hitl.md](../../task-recipes/hitl.md).
-
-Use the canonical shell from
-[shared/wrapper-shells.md](../../../../shared/wrapper-shells.md): a
-`bpmn:userTask` containing `uipath:activity version="v1"` and nested
-`uipath:type value="Actions.HITL" version="v1"`, with task data and result
-payloads as direct `uipath:activity` children.
-
-## Model-owned implementation
-
-The model may edit:
-
-- `bpmn:userTask` wrapper for human work.
-- Documented `Actions.HITL` `uipath:activity` shell.
-- Input body CDATA in `uipath:activity` using synthetic payload fields.
-- `uipath:activity` outputs for action result, completed fields, comments, and decision values.
-- Boundary timeout/error events and post-task gateways.
-
-## Operator or CLI-owned implementation
-
-The operator or tooling must resolve:
-
-- Real Action Center app, form, folder, queue, group, or assignee references.
-- Dynamic form schemas and generated resources.
-- Tenant-specific routing and notification metadata.
-
-For a new draft HITL node, do not add an orphan root `uipath:bindings` entry
-just to represent an unresolved Action Center form or app. Keep unresolved
-Action Center resources in the project notes until the operator or CLI supplies
-a concrete binding contract. If a binding is authored, it must be referenced by
-the task and backed by generated package metadata before Operate.
-
-## Validation expectations
-
-- Task inputs use `vars.<variableId>` and outputs target declared writable variable ids.
-- Outcome gateway conditions match possible result values.
-- Timeout paths do not discard required process state.
-- Binding references are placeholders or resolved generated resources, and no
-  unreferenced HITL binding is left in root metadata.
-- No personal names, emails, tenant URLs, or exported form payloads are committed.

package/skills/uipath-maestro-bpmn/references/author/references/plugins/hitl/planning.md

@@ -1,30 +0,0 @@
-# HITL Planning
-
-Use this reference when planning human-in-the-loop Action Center tasks in BPMN. HITL is `bpmn:userTask`, not a generic service task. See [task-recipes/hitl.md](../../task-recipes/hitl.md).
-
-## When to use
-
-- Human approval, validation, enrichment, or exception handling.
-- A task must pause the process until a person completes work.
-- Outcomes route the process through gateways.
-- Escalation or timeout paths are required.
-
-## Planning steps
-
-1. Define the human decision or data entry outcome.
-2. Decide required inputs, task payload, outputs, assignee/routing intent, due date, and escalation behavior.
-3. Plan result variables and gateway routes after completion.
-4. Add timeout or cancellation paths when the process cannot wait indefinitely.
-5. Use public-safe placeholders for queues, groups, folders, apps, and task titles.
-6. Confirm whether any Action Center resource must be resolved by tooling or the operator.
-
-## Model may draft
-
-- `bpmn:userTask` wrapper and `Actions.HITL` shell when the contract is documented.
-- Input/output mappings and outcome routes.
-- Boundary timeout/error paths.
-- Public-safe labels and diagram geometry.
-
-## Stop conditions
-
-Stop before Operate when real assignee, folder, app, task form, schema, or resource binding is unresolved.