@uipath/skills 1.195.0 → 1.196.0

package/skills/uipath-ixp/references/project-setup-guide.md

@@ -1,90 +0,0 @@
-# Project Setup Guide
-
-Complete workflow for creating a **new** IXP project, labelling all documents, and getting initial metrics. Run all steps end-to-end automatically.
-
-> **Wrong page if the project already exists.** Use `uip ixp documents upload <project-name> <file>` — see [CLI Reference § Uploading documents](cli-reference.md#uploading-documents-to-an-existing-project).
-
-## Step 1 — Create the Project
-
-If the user provides a name, use it. If not, generate a temporary name (e.g., `ixp_project_NNNN` with a random number) — the project will be renamed in Step 3 after the taxonomy reveals the document type.
-
-`<folder-path>` is filtered to supported document files — see [CLI Reference § Supported document files](cli-reference.md#supported-document-files).
-
-**Option A — Auto-suggest taxonomy (default):**
-
-```bash
-uip ixp projects create "<name>" <folder-path> --output json
-```
-
-If the user specified what to extract, add `-d` for a better taxonomy suggestion:
-
-```bash
-uip ixp projects create "<name>" <folder-path> -d "<what to extract>" --output json
-```
-
-This uploads documents and auto-suggests a taxonomy based on the document content (and the description if provided).
-
-**Option B — Blank project + import taxonomy from file:**
-
-If the user provides a taxonomy file, create a blank project and import separately:
-
-```bash
-uip ixp projects create "<name>" <folder-path> --skip-taxonomy --output json
-uip ixp projects import-taxonomy <project-name> <taxonomy-file> --output json
-```
-
-The taxonomy file can be in either format — the CLI auto-detects based on which keys are present:
-
-- `{ "field_types": [...], "label_group": {...} }` — use when importing a taxonomy suggested by a previous `project create` run
-- `{ "entity_defs": [...], "label_groups": [...] }` — use when importing a taxonomy file provided by the user, or cloning from an existing project (exported via `uip ixp projects get-taxonomy`)
-
-Use the `ProjectName` from the create output for all subsequent commands. This is the lowercase slug with UUID and `-ixp` suffix (e.g., `my_invoices-f1afa9ef-ixp`), NOT the Title.
-
-Create the working directory using the returned `ProjectName`:
-
-```bash
-mkdir -p /tmp/ixp/<project-name>/{docs,text,taxonomies,prompts}
-```
-
-## Step 2 — Configure the Model
-
-Before labelling, configure the extraction model based on what the documents look like. Download 2-3 sample document images and view them:
-
-```bash
-uip ixp documents list <project-name> --output json
-uip ixp documents download <project-name> <document-id> -o /tmp/ixp/<project-name>/docs/sample --output json
-```
-
-View with the **Read tool**, then decide:
-
-| Document characteristics | Pre-processing | Model |
-|--------------------------|---------------|-------|
-| Simple documents, no tables | `none` | `gemini_2_5_flash` |
-| Documents with simple tables or multiple tables | `table_mini` | `gemini_2_5_flash` |
-| Complex nested tables, merged cells, multi-page tables | `table` | `gemini_2_5_flash` |
-| Very long documents (100+ pages) | `none` or `table_mini` | `gemini_2_5_pro` |
-
-Apply the configuration:
-
-```bash
-uip ixp projects configure-model <project-name> \
-  --model gemini_2_5_flash \
-  --preprocessing <none|table_mini|table> \
-  --output json
-```
-
-**Default recommendation:** `--model gemini_2_5_flash --preprocessing table_mini` — works well for most invoice/document types.
-
-## Step 3 — Name the Project
-
-Based on the taxonomy from Step 1 (e.g., if it has "Invoice Details", "Line Items", "Bill-To" → it's an invoices project), give the project a descriptive title:
-
-```bash
-uip ixp projects update-title <project-name> "Vendor Invoices" --output json
-```
-
-Skip this step if the user already provided a meaningful name in Step 1.
-
-## Step 4 — Label All Documents
-
-Follow the [Label Documents Guide](label-documents-guide.md) to label every document in the project.

package/skills/uipath-maestro-case/references/plugins/edges/impl-json.md

@@ -1,152 +0,0 @@
----
-direct-json: supported
----
-
-# edges — JSON Implementation
-
-Cross-cutting direct-JSON rules live in [`case-editing-operations.md`](../../case-editing-operations.md).
-
-## Purpose
-
-Connect two nodes (Trigger → Stage or Stage → Stage) by appending an edge object to `edges`. Edge type is **inferred from the source node** — never specified explicitly.
-
-The same recipe covers add / edit / remove — direct JSON writes state declaratively: "make `edges` match the desired set."
-
-> **Schema neutrality.** Edge shape is **identical across v19 and v20** — both use the top-level `edges[]` array, same per-edge fields. Per Rule 19 in v20, do NOT emit `data.waypoints` (lifted to top-level `layout.edges[<edgeId>].waypoints`); skill never authored waypoints anyway, so this is a no-op. `zIndex` is NOT in the layout-strip list; edge-level `zIndex` (when sdd.md requests one) stays at the edge level in both schemas.
-
-## Input spec (from `tasks.md`)
-
-| Field | Required | Notes |
-|---|---|---|
-| `source` | yes | Trigger ID (e.g., `trigger_1`) or Stage ID. Resolved from `id-map.json`. |
-| `target` | yes | Stage ID. Resolved from `id-map.json`. Never an ExceptionStage — see Guardrails. |
-| `label` | no | Display label on the connector (Studio Web "Name"). Optional — emit when sdd.md states one or planning's inference rules apply; otherwise emit `data.label: ""`. See [`planning.md` § Labels](planning.md#labels). |
-| `sourceHandle` direction | no | `right` (default) \| `left` \| `top` \| `bottom` |
-| `targetHandle` direction | no | `left` (default) \| `right` \| `top` \| `bottom` |
-| `zIndex` | no | Integer. Omit the key entirely when unset. |
-
-## Guardrails (enforce before writing)
-
-1. **Both endpoints exist in `schema.nodes`.** If either `source` or `target` is missing, halt — do not write a dangling edge.
-2. **Neither endpoint is an `case-management:ExceptionStage`.** Exception stages have no edges (see [`planning.md` § Wiring Constraints](planning.md#wiring-constraints)). They are reached via an interrupting `stage-entry-conditions` rule and exited via a `return-to-origin` `stage-exit-conditions` rule. Reject the write and flag to the user.
-3. **`target` is not a Trigger.** Edges always flow into a Stage (regular Stage only).
-4. **No duplicate edge with the same `source`+`target` pair** unless the sdd.md explicitly declares parallel edges. Warn if one already exists.
-
-## ID generation
-
-- Prefix: `edge_`
-- Suffix length: 6
-- Algorithm: per [`case-editing-operations.md § ID Generation`](../../case-editing-operations.md#id-generation)
-
-Record `T<n> → edge_xxxxxx` in `id-map.json` for the audit trail, even though no downstream node references edges by ID.
-
-## Edge-type inference
-
-```text
-sourceNode = schema.nodes.find(n => n.id === source)
-edgeType   = sourceNode.type === "case-management:Trigger"
-             ? "case-management:TriggerEdge"
-             : "case-management:Edge"
-```
-
-Do NOT accept a caller-supplied `type` — always derive it from the source node.
-
-## Handle strings
-
-Exactly **four underscores** each side:
-
-```text
-sourceHandle = `${source}____source____${sourceDir}`   # sourceDir default: "right"
-targetHandle = `${target}____target____${targetDir}`   # targetDir default: "left"
-```
-
-## Recipe — Add
-
-Append this object to `schema.edges` — always append, never prepend.
-
-### TriggerEdge (source is a Trigger)
-
-```json
-{
-  "id": "<edge_xxxxxx>",
-  "source": "<triggerId>",
-  "target": "<stageId>",
-  "sourceHandle": "<triggerId>____source____<sourceDir>",
-  "targetHandle": "<stageId>____target____<targetDir>",
-  "data": { "label": "<label>" },
-  "type": "case-management:TriggerEdge"
-}
-```
-
-### Edge (source is a Stage)
-
-```json
-{
-  "id": "<edge_xxxxxx>",
-  "source": "<sourceStageId>",
-  "target": "<targetStageId>",
-  "sourceHandle": "<sourceStageId>____source____<sourceDir>",
-  "targetHandle": "<targetStageId>____target____<targetDir>",
-  "data": { "label": "<label>" },
-  "type": "case-management:Edge"
-}
-```
-
-### Optional-field emission rules
-
-Omitted inputs yield absent keys (matches `JSON.stringify`'s drop-undefined behavior):
-
-| Input | Emission |
-|---|---|
-| `zIndex` unset | Omit the `zIndex` key entirely |
-| `sourceHandle` direction unset | Still emit the key with default `right` |
-| `targetHandle` direction unset | Still emit the key with default `left` |
-
-Key insertion order (cosmetic — frontends accept any order):
-
-```text
-id, source, target, sourceHandle, targetHandle, [zIndex], data, type
-```
-
-## Recipe — Edit
-
-Find the edge by `id` in `schema.edges` and mutate in place:
-
-| Field | Mutable | Notes |
-|---|---|---|
-| `id` | no | Immutable. |
-| `source` | no | Immutable. To rewire, remove + re-add. |
-| `target` | no | Immutable. To rewire, remove + re-add. |
-| `type` | no | Derived from `source`. Immutable. |
-| `data.label` | yes | Mutable; may be `""` when no rule applies. Always emit the key so the JSON shape stays consistent — write `""` to clear. |
-| `sourceHandle` | yes | Re-construct with new direction, keep same `source` ID. |
-| `targetHandle` | yes | Re-construct with new direction, keep same `target` ID. |
-| `zIndex` | yes | Set or `delete` to clear. |
-
-> To re-wire an edge (change `source` or `target`), **remove and re-add**. This preserves the invariant that `sourceHandle`/`targetHandle` always reference the current endpoints.
-
-## Recipe — Remove
-
-```text
-schema.edges = schema.edges.filter(e => e.id !== edgeId)
-```
-
-Nothing references edges by ID in `caseplan.json`, so no cascade cleanup is needed. A stage removal still cascades to its edges — that logic lives in the stages JSON recipe (`Delete a node` in [`case-editing-operations.md`](../../case-editing-operations.md#delete-a-node)), not here.
-
-## Semantic position
-
-Edges live in the top-level `schema.edges` array. Always append new edges to the end.
-
-## Post-write validation
-
-After writing, confirm:
-
-- `schema.edges` contains the new edge with the generated ID
-- `edges[].type` matches the inference (`TriggerEdge` iff source is a Trigger)
-- `edges[].sourceHandle` and `edges[].targetHandle` use exactly 4 underscores each side
-- `edges[].source` and `edges[].target` resolve to existing `schema.nodes` entries
-- `edges[].data.label` key is present (value may be `""` when no rule applies — see [`planning.md` § Labels](planning.md#labels))
-- `edges[].zIndex` is present iff the T-entry declared one
-
-Run `uip maestro case validate <file> --output json` after all edges for this plugin's batch are added.
-

package/skills/uipath-maestro-case/references/plugins/edges/planning.md

@@ -1,93 +0,0 @@
-# edges — Planning
-
-Edges connect nodes in the case graph — Trigger → Stage, Stage → Stage, Stage → ExceptionStage, etc. Every stage must have at least one inbound edge or it will be orphaned.
-
-## When to Use
-
-Always. Every `tasks.md` has one edge entry per transition in the sdd.md flow graph. One plugin covers both edge variants (`TriggerEdge` and `Edge`) — the type is inferred from the source node's type in `schema.nodes`.
-
-## Edge Types (inferred from source)
-
-| Source node type | Target node type | JSON type |
-|-------------------|------------------|-----------|
-| Trigger | Stage | `case-management:TriggerEdge` |
-| Stage | Stage | `case-management:Edge` |
-
-The plugin's `impl-json.md` resolves the source node's `type` field in `schema.nodes` and writes the matching edge `type` automatically. The planning T-entry only records `source` and `target` names.
-
-## Wiring Constraints
-
-**Exception / secondary stages have no edges at all — neither inbound nor outbound.** Do not create any edge where `source` or `target` is an exception stage.
-
-- ❌ `source: "<exception-stage-name>"` — never.
-- ❌ `target: "<exception-stage-name>"` — never (applies to TriggerEdge and Edge alike).
-- ✅ Exception stages are **reached via an interrupting entry condition** on the exception stage itself, not via an edge. See [stage-entry-conditions plugin](../conditions/stage-entry-conditions/planning.md).
-- ✅ Exception stages **exit via a `return-to-origin` exit condition**, not via an outbound edge. See [stage-exit-conditions plugin](../conditions/stage-exit-conditions/planning.md).
-
-If the sdd.md describes an exception stage with edges, flag to the user: re-model as a regular stage, or use the conditions-only pattern above.
-
-### Orphan check scope
-
-The orphan check in the planning pipeline applies to **regular stages only** — every regular stage must be the target of at least one edge. Exception stages intentionally have no edges and are not orphans.
-
-This constraint is also documented in the [stages plugin](../stages/planning.md#wiring-constraints-for-exception--secondary-stages).
-
-## Required Fields from sdd.md
-
-| Field | Source | Notes |
-|-------|--------|-------|
-| `source` | sdd.md flow arrow origin | Trigger ID or stage name |
-| `target` | sdd.md flow arrow destination | Stage name |
-| `label` | inferred (see § Labels) | Optional. Emit when sdd.md states one or an inference rule applies; otherwise leave blank. |
-| `source-handle` | sdd.md (rarely specified) | `right` (default) \| `left` \| `top` \| `bottom` |
-| `target-handle` | sdd.md (rarely specified) | `left` (default) \| `right` \| `top` \| `bottom` |
-
-## Labels
-
-Edge labels are **display-only** — they do not control routing. Routing conditions live on the source stage's `exitConditions`, not on the edge. Labels annotate intent so the diagram in Studio Web is readable (Studio Web renders this as the connector's "Name").
-
-Labels may be blank. Emit one only when sdd.md states it explicitly or an inference rule below applies.
-
-### Inference rules (apply in order)
-
-1. **TriggerEdge** (source is a Trigger node) → label = `"Start"`. For multi-trigger cases, label = trigger displayName (e.g., `"Manual"`, `"On timer"`, `"On <event>"`).
-2. **Stage→Stage with branching exit conditions in sdd.md** → label = matching branch outcome from the source stage's exit-condition text. Examples: `"Approved"`, `"Rejected"`, `"Timeout"`, `"Escalated"`. One edge per outcome → one label per outcome.
-
-If sdd.md states an explicit edge label, use it verbatim and skip inference. Otherwise (e.g., Stage→Stage with single outbound and no branching), leave the label blank.
-
-### Anti-patterns
-
-- **Do NOT infer from edge index** (`"Edge 1"`, `"Edge 2"`) — meaningless to the user.
-- **Do NOT read exit-condition text from another T-entry** — read directly from sdd.md, preserve plugin isolation.
-- **Do NOT fabricate a label** when no inference rule applies — leave it blank.
-
-## Handles
-
-Handle directions control visual rendering (where the edge emerges from the source, where it enters the target). Defaults (`right` / `left`) match the horizontal left-to-right canvas layout. Only override when the sdd.md specifies a specific routing, e.g., an exception branch going down to a lower stage.
-
-## Ordering
-
-Edges are created **after** all stages exist so both endpoints can resolve. Each edge references the initial Trigger node (created by the triggers plugin at T02) or stage IDs captured in the stages capture map.
-
-## tasks.md Entry Format
-
-```markdown
-## T<n>: Add edge "<source>" → "<target>"
-- source: "<trigger-id-or-stage-name>"
-- target: "<stage-name>"
-- label: "<inferred or sdd.md-stated label>"   # optional, omit line when blank
-- source-handle: right      # optional
-- target-handle: left       # optional
-- order: after T<m>
-- verify: Confirm Result: Success, capture EdgeId
-```
-
-## Multi-Trigger Cases
-
-When the sdd.md has multiple entry points (manual + timer + event), each non-default trigger is added via its plugin ([`plugins/triggers/`](../triggers/)), returning a `TriggerId`. Each trigger needs its own outgoing edge to the relevant first stage. Record one edge entry per trigger.
-
-## Orphan Check
-
-After all edges are planned, cross-check: every **regular stage** (type `stage`) in `tasks.md §4.4` must appear as a `target` in at least one edge entry. Missing → sdd.md has an orphan regular stage; flag to the user.
-
-Exception stages are **excluded** from this check — they intentionally have no edges. Any exception stage present in `tasks.md` that also appears in an edge entry is an error (see Wiring Constraints above).