@uipath/skills 1.196.0 → 1.197.0

package/skills/uipath-maestro-bpmn/references/author/references/task-recipes/http-request.md

@@ -1,119 +0,0 @@
-# HTTP Request Recipe
-
-Use this recipe for a confirmed plain HTTP request where the workflow owns the URL,
-method, payload, and response parsing. Do not use it for connector-authenticated
-operations, Integration Service connector objects, dynamic connector schemas, or
-tenant-specific connection resources; those remain CLI-enriched Integration
-Service work.
-
-## Modeling boundary
-
-Choose the BPMN element for the skeleton before choosing this implementation
-recipe. For confirmed request-and-continue HTTP work, the current supported
-implementation wrapper is `bpmn:sendTask` with `Intsvc.HttpExecution`. If the
-skeleton uses a different supported BPMN shape for a clear modeling reason, do
-not rewrite the topology just to use this recipe.
-
-Do not represent an executable HTTP call as:
-
-- A blank `bpmn:task` or unlabeled placeholder after pass 2 is expected to be
-  executable.
-- A script task that performs network I/O.
-- A connector activity with guessed metadata or copied tenant values.
-
-If the executable HTTP activity shape is unavailable in the current tooling,
-keep the node as draft intent and report it as not implemented.
-
-## HTTP shape decision
-
-| Scenario | Authoring decision |
-| --- | --- |
-| Plain connectionless request and the workflow owns URL, method, payload, and parsing | Use this `Intsvc.HttpExecution` recipe after skeleton confirmation. |
-| Connector-authenticated request, tenant connection, dynamic connector schema, or object operation | Keep the BPMN node as draft intent and hand enrichment to the CLI. |
-| Solution/V2 unified HTTP shape is explicitly available from current tooling | Let CLI enrichment generate `Intsvc.UnifiedHttpRequest`; do not copy this recipe by hand. |
-| Unsure which HTTP runtime is active | Keep draft intent and report the missing enrichment decision. |
-
-## Executable contract
-
-For confirmed connectionless HTTP execution, use the current UiPath HTTP
-activity shape rather than a generic connector guess:
-
-- `uipath:type` service type: `Intsvc.HttpExecution`.
-- Request fields are explicit runtime inputs: `mode`, `method`, `url`,
-  `headers`, `parameters`, and `body`.
-- JSON fields use CDATA and valid JSON objects; use `{}` when no headers,
-  parameters, or body are required.
-- Output maps the activity `response` to a declared JSON variable with
-  `source="=response"`.
-- Downstream script or mapping steps consume that response variable and write
-  typed process variables for business decisions.
-
-Declare variables for:
-
-- Configurable request inputs when the caller should control them.
-- Raw HTTP response, including status code and body.
-- Parsed fields that downstream gateways, scripts, or outputs need.
-- Final user-facing result variables.
-
-## Generic XML shape
-
-Use this shape for plain connectionless HTTP. Keep IDs, names, URL, method,
-and target variables specific to the workflow; keep the field set intact.
-
-```xml
-<uipath:inputOutput id="Var_HttpResponse" name="httpResponse" type="jsonSchema"><![CDATA[
-{"type":"object"}
-]]></uipath:inputOutput>
-
-<bpmn:sendTask id="Task_CallHttpEndpoint" name="Call HTTP endpoint">
-  <bpmn:extensionElements>
-    <uipath:activity version="v1">
-      <uipath:type value="Intsvc.HttpExecution" version="v1" />
-      <uipath:context>
-        <uipath:input name="mode" type="string" value="manual" />
-        <uipath:input name="method" type="string" value="GET" />
-        <uipath:input name="url" type="string" value="https://example.invalid/resource" />
-        <uipath:input name="headers" type="json"><![CDATA[{}]]></uipath:input>
-        <uipath:input name="parameters" type="json"><![CDATA[{}]]></uipath:input>
-        <uipath:input name="body" type="json"><![CDATA[{}]]></uipath:input>
-      </uipath:context>
-      <uipath:output name="response" type="json" source="=response" var="Var_HttpResponse" />
-    </uipath:activity>
-  </bpmn:extensionElements>
-  <bpmn:incoming>Flow_Previous_CallHttpEndpoint</bpmn:incoming>
-  <bpmn:outgoing>Flow_CallHttpEndpoint_Next</bpmn:outgoing>
-</bpmn:sendTask>
-```
-
-For `POST`, `PUT`, or `PATCH`, keep `headers`, `parameters`, and `body`
-present. Put JSON request payloads in `body` CDATA and parse the raw response
-in a downstream script task rather than embedding business logic in the HTTP
-activity.
-
-## Verification
-
-Local validation is necessary but not enough to call HTTP work implemented.
-Before reporting an HTTP node as executable, verify one of:
-
-- CLI/Studio Web enrichment generated the HTTP activity metadata.
-- A debug/run instance shows the HTTP element received request inputs and
-  produced the mapped response variable.
-
-When a run is available, inspect instance variables and confirm:
-
-- The HTTP task output includes status and response body.
-- Parse steps read the raw response variable and produce non-placeholder
-  business variables.
-- Final outputs reflect parsed runtime data, not canned text.
-
-## Status language
-
-Use precise status in summaries:
-
-- **Executable** - request activity, input fields, output variable, and
-  downstream mappings are present; runtime variable evidence is available if a
-  run was performed.
-- **Draft** - BPMN shape and intent are present, but executable HTTP metadata is
-  missing or awaiting enrichment.
-- **Mock** - the process returns fixed sample data instead of calling HTTP.
-- **Blocked** - required URL, auth, schema, or enrichment decision is missing.

package/skills/uipath-maestro-bpmn/references/author/references/task-recipes/queue.md

@@ -1,21 +0,0 @@
-# Queue Recipe
-
-Use the BPMN wrapper that matches the confirmed queue behavior.
-
-| Operation | BPMN element | Extension type |
-| --- | --- | --- |
-| Create queue item and continue | `bpmn:sendTask` | `Orchestrator.CreateQueueItem` |
-| Create queue item and wait for completion | `bpmn:serviceTask` | `Orchestrator.CreateAndWaitForQueueItem` |
-
-The model may draft:
-
-- Queue task wrapper, variables, payload mappings, outputs, and BPMN DI.
-- Public-safe payload fields, reference, priority, deadline, and transaction metadata.
-- Duplicate-reference and unavailable-queue error paths.
-
-CLI or operator must resolve:
-
-- Queue identity, folder binding, generated package resources, and any downstream callback contract.
-- Tenant-specific queue names, queue IDs, and folder keys.
-
-Do not model downstream processing implicitly. Add an explicit wait, callback, or follow-up task when the process needs a completion result.

package/skills/uipath-maestro-bpmn/references/author/references/task-recipes/rpa-job.md

@@ -1,23 +0,0 @@
-# RPA Job Recipe
-
-The current supported implementation wrapper for confirmed RPA process
-execution is `bpmn:serviceTask` with `Orchestrator.StartJob`.
-
-Use a complete `StartJob` context: process key, folder key, folder ID, folder
-path, and process name. Resolve these values from process and folder discovery
-before execution; keep examples public-safe.
-
-The model may draft:
-
-- Stable service task ID, display name, incoming/outgoing flows, and BPMN DI.
-- Root variables for process inputs, job status, output arguments, and errors.
-- Public-safe `uipath:activity` shell only when the required context/input/output contract is known.
-- Boundary error or timeout paths and post-job gateways.
-
-CLI or operator must resolve:
-
-- Real process identity, release/folder binding, robot/runtime scope, and generated binding resources.
-- Input/output argument schemas.
-- Whether the task waits for completion or only starts the job.
-
-Stop before Operate if process binding, folder scope, argument schema, or wait semantics are unresolved.

package/skills/uipath-maestro-bpmn/references/author/references/validation.md

@@ -1,118 +0,0 @@
-# Validation
-
-Run validation after the local BPMN edit is coherent. Do not chase every intermediate invalid state while creating nodes and flows.
-
-## Local checks
-
-Validate these before Operate:
-
-- The pass 1 skeleton has been confirmed or the edit is small and explicitly summarized.
-- New source does not generate any structure listed in
-  [Current generation exclusions](supported-elements.md#current-generation-exclusions).
-- A pass 1 skeleton uses business-readable conditions rather than runtime
-  `=vars.<variableId>` expressions for variables that do not exist until pass 2.
-- BPMN XML parses with the UiPath extension descriptor.
-- At least one valid diagram and plane exists.
-- Diagram plane references an existing root process, collaboration, or subprocess.
-- Every rendered node has a shape and every rendered edge has waypoints.
-- Root variables, bindings, migration metadata, and UiPath transaction-root
-  markers are structurally valid.
-- New root variables use `uipath:input`, `uipath:inputOutput`, or
-  `uipath:output`; generic `uipath:variable direction="..."` appears only when
-  preserving imported XML.
-- Entry point IDs are unique and appear on root-level start events.
-- Entry point input variables use an `elementId` matching the start event.
-- Binding expressions in context values resolve to root bindings.
-- Required context/input fields are present for documented service types.
-- Sequence flows connect legal source and target types.
-- Message flows do not connect elements inside the same pool.
-- Message event definitions reference declared `bpmn:message` elements.
-- Gateway splits have valid conditions/defaults.
-- Each scope has at most one blank start event.
-- Event subprocesses have exactly one start event.
-- Boundary error events and error event subprocesses reference valid error definitions.
-- Boundary events own their exception outgoing flows; attached activities do
-  not list boundary exception flows as normal incoming/outgoing flows.
-- Multi-instance collection bindings reference declared variables, subprocess item access uses the documented iterator shape, and sequential/parallel metadata is explicit.
-- Expressions avoid assignment operators in fields that require read-only expression evaluation.
-- Runtime expressions use `vars.<variableId>`, `bindings.<bindingId>`, `result`,
-  or the documented iterator/error namespaces instead of bare variable names.
-- Output mappings target declared mutable variables.
-- Retry and error mapping metadata use current attributes from
-  [shared/error-handling.md](../../shared/error-handling.md).
-- CLI-owned Integration Service fields have been enriched or are clearly marked as blockers.
-
-For local-only authoring, always execute at least one validation command before
-packaging. The current local CLI validator expects a BPMN/XML file path, so use
-the main source file:
-
-```bash
-uip maestro bpmn validate ProjectName/ProjectName.bpmn --output json
-```
-
-Only validate a project directory if the installed CLI explicitly supports that
-shape. If the installed CLI does not expose validation, run an explicit XML
-parse command against the BPMN source, for example:
-
-```bash
-python3 -c "import xml.etree.ElementTree as ET; ET.parse('ProjectName/ProjectName.bpmn')"
-```
-
-Do not treat reading the file or visually inspecting generated metadata as a
-validation step; the validation command must run and succeed before `pack`.
-
-## Package checks
-
-Before executing `uip maestro bpmn pack`, ensure the project directory contains
-`project.uiproj`, `operate.json`, `entry-points.json`, `bindings_v2.json`, and
-`package-descriptor.json`. If any generated file is missing, regenerate it or
-write the placeholder-safe local-only shape from
-[shared/local-metadata-regeneration-guide.md](../../shared/local-metadata-regeneration-guide.md)
-before packing.
-
-### Validator coverage across CLI surfaces
-
-`uip maestro bpmn pack` and `uip solution pack` share the same BPMN validation
-rules. A BPMN that passes one will hit the same diagnostics under the other on
-the packager-level rules (binding-backed `Orchestrator.StartAgentJob` context
-inputs, contract placement, declared variables, expression scoping, and the
-rest). Do not assume one CLI surface is "less strict" than the other.
-
-The Studio Web Health Analyzer runs a separate canvas-side rule set and can
-surface issues that neither CLI command catches (or vice versa). Treat Health
-Analyzer as a third signal, not a duplicate. When a real run surfaces a
-diagnostic that the CLI did not flag, report it as a packager-validator gap so
-the rule reaches every caller.
-
-When generated package files exist, verify that:
-
-- `bindings_v2.json` matches root bindings and enriched resource metadata.
-- `entry-points.json` matches root start events, entry point IDs, and variable schemas.
-- `operate.json` points at the intended main BPMN file and content type.
-- `package-descriptor.json` includes the BPMN and generated JSON files under content.
-
-Use [shared/local-metadata-regeneration-guide.md](../../shared/local-metadata-regeneration-guide.md) when a mismatch requires local regeneration or Integration Service enrichment.
-
-## Result handling
-
-- Blocking errors must be fixed before upload, publish, debug, or run.
-- Warnings may be acceptable for local drafts, but warnings about CLI-owned executable elements are blockers for real runs.
-- If validation tooling is missing, report the exact checks that could not run and keep the project in Author state.
-- If Integration Service enrichment is unavailable, validation can pass only for source shape review; do not report the project as ready for Operate.
-
-## Implementation status summary
-
-When handing off to Operate or reporting completion, classify each external,
-resource-backed, HTTP, human, child-process, or script-enrichment node:
-
-- **Executable** - the node has concrete runtime metadata, declared input/output
-  variables, mappings to downstream variables, and no unresolved placeholder.
-- **Draft** - the BPMN shape and intent are present, but runtime metadata,
-  binding, schema, or enrichment is unresolved.
-- **Mock** - the node returns fixed sample data or bypasses the real external
-  action.
-- **Blocked** - required user, tenant, connection, schema, URL, or credential
-  information is missing.
-
-Do not use "fully implemented" for a process that contains draft, mock, or
-blocked nodes. Name those nodes explicitly and state what is still required.

package/skills/uipath-maestro-bpmn/references/shared/bpmn-xml-contract.md

@@ -1,197 +0,0 @@
-# BPMN XML Contract
-
-This document summarizes the public-safe authoring boundary for Maestro BPMN XML. It intentionally avoids raw exported BPMN, tenant data, connection identifiers, private names, URLs, or local paths.
-
-## Baseline document
-
-Generated BPMN must be valid BPMN 2.0 with the UiPath extension namespace.
-
-- `bpmn:definitions` includes standard BPMN, BPMNDI, DI, DC, and the UiPath namespace.
-- The UiPath namespace URI is `http://uipath.org/schema/bpmn` and the preferred prefix is `uipath`.
-- Do not declare `uipath` as `http://schemas.uipath.com/workflow/activities` in
-  Maestro BPMN files.
-- Use one executable root process by default. Use collaboration/pools only when the user explicitly asks for that model.
-- Studio Web import requires at least one valid `bpmndi:BPMNDiagram` with a `bpmndi:BPMNPlane`.
-- Every visible flow node should have a `bpmndi:BPMNShape` with bounds.
-- Every visible edge should have a `bpmndi:BPMNEdge` with waypoints.
-- Conditions and scripts should use a leading `=` where Maestro expects expressions.
-- UiPath extension expressions should read BPMN variables through `vars.<variableId>`,
-  for example `=vars.Var_RequestId`, rather than bare names.
-- For lint-sensitive expression details, see [expression-authoring.md](expression-authoring.md).
-- CDATA is the expected representation for JSON bodies, schemas, scripts, variable schemas, custom output bodies, and case-management payload bodies.
-- XML comments must remain parseable. Do not put `--` inside comments, and do
-  not use dashed decorative separator lines in BPMN XML comments.
-
-## Supported model-authored BPMN
-
-For the supported element map and UiPath extension wrapper table, see [author/supported-elements.md](../author/references/supported-elements.md).
-
-The model may directly author standard BPMN structure when user intent is clear.
-Anything listed in
-[Current generation exclusions](../author/references/supported-elements.md#current-generation-exclusions)
-is preserve-only for imported files and must not be generated in new source.
-
-- Events: start, end, boundary, intermediate catch, and intermediate throw events.
-- Event definitions: none, timer, message, error, and terminate end events where supported by the runtime path.
-- Gateways: exclusive, inclusive, parallel, and event-based gateways.
-- Tasks and activities: task, service task, send task, receive task, user task, business rule task, script task, and call activity.
-- Containers: subprocess and supported event subprocesses. Expanded subprocesses need a second diagram when nested content must render in Studio Web.
-- Flow and annotation elements: sequence flow, message flow, association, data input/output association, group, text annotation, categories, messages, errors, data stores, item definitions, and resources.
-- Loop markers: documented multi-instance parallel or sequential loop metadata. UiPath collection/element metadata belongs under the loop characteristic extension elements.
-
-Conservative defaults:
-
-- Start with one root process and one blank start event unless the process needs a trigger entry point.
-- Use sequence flows for routing inside one process.
-- Put gateway conditions on outgoing sequence flows and set a default flow where appropriate.
-- Attach boundary error events to activities and reference valid error definitions.
-- Give event subprocesses exactly one start event.
-- Avoid sequence flows that cross subprocess scope or pool boundaries.
-
-## Two-pass authoring boundary
-
-For non-trivial authoring, split generation into two passes:
-
-- **Pass 1: BPMN skeleton** - author standard BPMN process structure, event definitions, gateway conditions, subprocess scopes, sequence/message flows, annotations, and BPMN DI. Use placeholder labels or annotations for resource intent. Keep gateway conditions business-readable; do not use Maestro runtime expressions such as `=vars.<variableId>` until pass 2 declares those variables. Preserve existing extension XML in brownfield files.
-- **Operator confirmation** - confirm the process shape before filling execution-specific XML.
-- **Pass 2: model-owned UiPath XML** - add root variables, entry point IDs, mappings, documented bindings, script metadata, retry/error metadata, loop metadata, and documented service shells from [wrapper-shells.md](wrapper-shells.md).
-- **CLI enrichment** - generate or enrich Integration Service activity/trigger payloads, connector bindings, dynamic schemas, and generated package files.
-
-Do not combine connector selection, connection binding, dynamic schema generation, and topology rewrites in one opaque edit.
-
-## Executable contract boundary
-
-The current confirmed generation boundary is preserve/model-shell only for areas whose runtime contract depends on tenant state, registry metadata, or non-BPMN subscriptions. Do not add generation guidance that creates executable payloads for those areas until the contract is fixture-backed and CLI-validated.
-
-- Signals: do not generate new signal definitions or signal event definitions.
-  Preserve imported signal XML and report it as unsupported for regeneration
-  unless a current product contract and local validation prove support.
-- Plain connectionless HTTP: after skeleton confirmation, model authors may use
-  the documented [HTTP request recipe](../author/references/task-recipes/http-request.md)
-  when the workflow owns the URL, method, payload, and parsing, and no
-  connector connection or dynamic connector schema is needed.
-- Integration Service: model authors may create the surrounding BPMN node and
-  document connector intent. They may also create a non-executable draft
-  `Intsvc.*` shell with `uipath:type value="Intsvc.<Variant>"` and placeholder
-  strings. Except for the documented pass-2 plain connectionless HTTP recipe,
-  executable `Intsvc.*` activity/event XML, connection bindings, connector
-  metadata, trigger property bindings, filters, parameters, and dynamic schemas
-  require live registry-backed CLI enrichment for the target tenant before
-  upload, debug, publish, or deploy.
-- Brownfield files: preserve imported signal or Integration Service extension XML unless the user explicitly asks for normalization and the CLI can validate the replacement.
-
-## UiPath extensions the model may write
-
-Use lower-case XML aliases in examples and authoring guidance:
-
-- Root `uipath:variables version="v1"` with input, input/output, and output variables.
-- Root `uipath:bindings version="v1"` for placeholder-safe resource bindings when the binding contract is documented.
-- Root-level start event `uipath:entryPointId value="..."` for runnable entry points.
-- `uipath:mapping version="v1"` for `BPMN.Variables` mappings.
-- `uipath:scriptVersion value="..."` for script task metadata. Prefer `v3` for new script tasks; preserve imported `v2` metadata unless the user explicitly migrates it.
-- `uipath:migrationVersion version="..."` as import migration metadata to preserve, including numeric values such as `5`, `11`, and `11.5`.
-- `uipath:loopCharacteristics inputCollection="..." inputElement="..."` under loop characteristic extensions.
-- `uipath:retry`, `uipath:errorMapping`, and `uipath:tags` when the user gives explicit public-safe metadata. For retry, boundary errors, event subprocesses, and error mapping shapes, see [error-handling.md](error-handling.md).
-- `uipath:activity` and `uipath:event` shells for documented non-Integration-Service service types.
-
-New authored `uipath:activity` and `uipath:event` shells use the canonical
-nested type element:
-
-```xml
-<uipath:activity version="v1">
-  <uipath:type value="Orchestrator.StartJob" version="v1" />
-</uipath:activity>
-```
-
-Do not use legacy shorthand such as `<uipath:activity type="...">` in new XML.
-For task payloads, keep the wrapper type and resource context in
-`uipath:activity`; put variable inputs and outputs in a sibling
-`uipath:mapping version="v1"` element whose `var` attributes target declared
-variable ids.
-
-For new root variables, use `uipath:input`, `uipath:inputOutput`, and
-`uipath:output` children. Do not author generic `uipath:variable
-direction="..."` entries in new source; preserve imported instances only when
-normalizing the file is out of scope.
-
-Do not invent `uipath:caseManagement` payloads without a dedicated case-management contract. Preserve imported `uipath:caseManagement` and unknown generic `uipath:Activity` payloads unless the edit explicitly normalizes them.
-
-## Non-Integration-Service task shells
-
-> Copyable minimal XML shell per wrapper: [wrapper-shells.md](wrapper-shells.md).
-
-The model may author placeholder-safe shells for documented non-Integration-Service task types when it has enough user intent and no private identifiers are embedded. Choose the BPMN wrapper first:
-
-- `BPMN.Variables`
-- `BPMN.ScriptTask` as `bpmn:scriptTask` with script CDATA, `uipath:scriptVersion`, and mapping metadata.
-- `Actions.HITL` as `bpmn:userTask`.
-- `Orchestrator.StartJob`, `Orchestrator.StartAgentJob`, `Orchestrator.ExecuteApiWorkflowAsync`, `Orchestrator.CreateAndWaitForQueueItem`, and `A2A.AgentExecution` as `bpmn:serviceTask`.
-- `Orchestrator.CreateQueueItem` as `bpmn:sendTask`.
-- `Orchestrator.BusinessRules` as `bpmn:businessRuleTask`.
-- `Orchestrator.StartAgenticProcess`, `Orchestrator.StartAgenticProcessAsync`, `Orchestrator.StartCaseMgmtProcess`, and `Orchestrator.StartCaseMgmtProcessAsync` as `bpmn:callActivity`.
-- `Maestro.ReceiveMessageEvent` and `Maestro.SendMessageEvent` as message event wrappers.
-- `Maestro.CasePlanScheduler` only when a dedicated case-management contract is available; otherwise preserve imported XML.
-
-Keep resource identity fields synthetic or placeholder-based until CLI or user-provided public-safe data resolves them.
-
-For copyable minimal XML shells, read [wrapper-shells.md](wrapper-shells.md)
-before authoring a task wrapper.
-
-### Script-task body rule
-
-A `<bpmn:script>` body on `bpmn:scriptTask` is only valid when the task also
-carries UiPath script metadata. `uip maestro bpmn validate` accepts the body
-when **at least one** of these extension elements is present inside
-`<bpmn:extensionElements>`:
-
-- `<uipath:scriptVersion value="v3" />` (preferred for new tasks; `v2` is
-  preserve-only on imports)
-- `<uipath:mapping>` containing `<uipath:type value="BPMN.ScriptTask" version="v1" />`
-- `<uipath:mapping>` containing `<uipath:type value="BPMN.Variables" version="v1" />`
-
-Without one of those, the validator rejects the body. If the task does not
-need to execute JavaScript, drop the `<bpmn:script>` and express the logic as
-a `BPMN.Variables` output mapping on a generic `bpmn:task`, or as a condition
-on a downstream gateway.
-
-## CLI-owned or CLI-enriched areas
-
-The CLI must generate, enrich, or validate these before upload, debug, publish, or deploy:
-
-- Integration Service activity operation metadata.
-- Integration Service trigger metadata and trigger property bindings.
-- Connection binding resources and connector metadata.
-- Dynamic input/output schemas for connectors, event triggers, unified HTTP, external agents, external workflows, API workflows, and generated outputs.
-- `bindings_v2.json`, including deduped resources and metadata.
-- `entry-points.json`, including schema extraction from root variables and entry point file wiring.
-- `operate.json`, including project ID, main file, content type, target framework, and runtime options.
-- `package-descriptor.json`, including manifest entries for BPMN and generated JSON.
-- Package identifiers and final package paths.
-- XML parse validation with the UiPath moddle descriptor.
-- Maestro validation parity for connections, gateways, start events, subprocess crossing, boundary errors, required fields, assignment-free expressions, variables, and resource references.
-- Project scaffolding and canonical BPMN filename selection.
-
-## Validation expectations
-
-Validation should report:
-
-- XML parse errors.
-- Missing or orphaned BPMN diagrams.
-- Missing shape/edge geometry for rendered elements.
-- Invalid root variables, bindings, migration metadata, or UiPath transaction-root markers.
-- Duplicate or invalid entry point IDs.
-- Entry point variables whose `elementId` does not match the start event.
-- Context binding expressions that do not resolve to root bindings.
-- Missing required service-type context/input fields.
-- Illegal sequence-flow or message-flow connections.
-- Gateway split/default-flow issues.
-- Multiple blank starts in a single scope.
-- Invalid event subprocess starts.
-- Invalid or duplicate error references.
-- Expressions with assignment operators in fields that require read-only expression evaluation.
-- Output references that do not match root or scoped variables.
-- Unresolved solution resources when validating inside a solution context.
-
-## Migration behavior
-
-Prefer current extension shapes instead of relying on import migrations. Preserve existing `uipath:migrationVersion` values, including numeric values like `5`, `11`, and `11.5`, and preserve unknown extension payloads such as generic `uipath:Activity`. Warn on old or unknown migrations unless the file cannot be interpreted.

package/skills/uipath-maestro-bpmn/references/shared/cli-conventions.md

@@ -1,46 +0,0 @@
-# CLI Conventions
-
-The BPMN skill assumes a split boundary: model-authored BPMN source plus CLI validation, enrichment, packaging, and cloud lifecycle.
-
-## Output parsing
-
-When a CLI result is parsed programmatically, request JSON output. If the command does not support JSON output yet, do not scrape human text silently; report that the command is not machine-readable and keep the next step manual or advisory.
-
-## Side-effect boundary
-
-Local validation, registry discovery, static inspection, and package dry-run style commands are authoring-safe. Upload, publish, deploy, debug, process run, instance lifecycle, and cloud resource mutation are operate actions and require explicit user consent.
-
-## Login boundary
-
-Authoring should work without login for local source edits and static validation. Registry-backed discovery, Integration Service enrichment, resource refresh, upload, debug, publish, process inspection, and run diagnosis may require login.
-
-## Integration Service enrichment
-
-For Integration Service nodes and triggers, use CLI or registry-backed tooling to:
-
-- Resolve connector and operation metadata.
-- Bind a selected connection.
-- Generate or enrich `uipath:activity` / `uipath:event` XML.
-- Generate `bindings_v2.json` resources.
-- Generate dynamic input and output schemas.
-- Validate required context/input fields.
-
-If enrichment tooling is unavailable, leave the element as a draft intent and record the open question. Do not hand-author connection IDs or private resource metadata.
-
-## Local metadata regeneration
-
-When BPMN source changes, regenerate or verify local package metadata before cloud actions. The derived files are `entry-points.json`, `bindings_v2.json`, `operate.json`, and `package-descriptor.json`; the BPMN source and registry-backed enrichment inputs are authoritative. Follow [local-metadata-regeneration-guide.md](local-metadata-regeneration-guide.md) for entry point schema, binding resource, and `Intsvc.*` payload drift checks.
-
-## Validation before operate
-
-Before upload, debug, publish, or deploy, run the available local checks for:
-
-- BPMN XML parse.
-- Diagram presence and geometry.
-- UiPath extension structure.
-- Entry point extraction.
-- Binding reference resolution.
-- Generated package file consistency.
-- Integration Service enrichment completeness.
-
-Warnings about CLI-owned fields are blockers when the affected element will execute in a real run.

package/skills/uipath-maestro-bpmn/references/shared/error-handling.md

@@ -1,82 +0,0 @@
-# Error Handling
-
-Maestro supports BPMN error paths plus UiPath-specific retry and error-mapping
-metadata. These features are executable behavior, so add them in pass 2 only
-after the process shape and error intent are clear.
-
-## BPMN error paths
-
-- Declare reusable errors with `bpmn:error` and a stable `errorCode`.
-- Attach `bpmn:boundaryEvent` with `bpmn:errorEventDefinition` to the activity
-  whose failure should branch locally.
-- Omit `errorRef` on an error event definition only for a deliberate catch-all
-  handler.
-- Use event subprocesses for scoped error handling that should catch errors not
-  handled by a more local boundary event.
-- Give each event subprocess exactly one start event.
-- Boundary error event outgoing flows are exception flows. Do not also list
-  those flows as normal outgoing flows on the attached activity.
-
-## Retry metadata
-
-Place retry metadata inside the activity extension elements:
-
-```xml
-<uipath:retry maxRetryCount="2" retryBackoff="PT30S" retryAllErrors="false">
-  <uipath:errorDefinition errorRef="Error_ServiceUnavailable" />
-</uipath:retry>
-```
-
-Supported retry attributes are:
-
-- `maxRetryCount`
-- `retryBackoff`
-- `retryAllErrors`
-- `retryBackoffType`
-- `maxDuration`
-- `exponentialBase`
-
-Do not use stale aliases such as `maxAttempts` or `interval` in new XML.
-
-## Error mapping metadata
-
-Use error mapping when an activity needs to classify runtime failures for
-retry, routing, or diagnostics:
-
-```xml
-<uipath:errorMapping version="v1">
-  <uipath:error
-    id="Mapped_ServiceUnavailable"
-    errorRef="Error_ServiceUnavailable"
-    priority="1"
-    condition="=vars.error.code == &quot;SERVICE_UNAVAILABLE&quot;"
-    detail="Service unavailable"
-    retryable="true" />
-</uipath:errorMapping>
-```
-
-Error mapping entries support:
-
-- `id`
-- `errorRef`
-- `priority`
-- `condition`
-- `detail`
-- `retryable`
-
-Use `errorRef` to connect to a declared `bpmn:error`. Use `priority` when
-multiple mappings may match. Conditions are lint-sensitive expressions and may
-read the built-in runtime error through `vars.error`.
-
-Do not use `code="..."` on `uipath:error` in new XML; model the code on
-`bpmn:error errorCode="..."` and reference it through `errorRef`.
-
-## Validation checklist
-
-- Every `errorRef` resolves to a declared `bpmn:error`.
-- Retry attributes use current names.
-- Error mapping priorities are numeric.
-- Error mapping `retryable` values are `true` or `false`.
-- Conditions use `=vars.error...` and contain no assignments.
-- Boundary handlers are attached to valid activities.
-- Event subprocess handlers stay inside the scope whose errors they catch.