@uipath/skills 1.201.0-preview.621 → 1.202.0-preview.635

package/skills/uipath-maestro-flow/references/evaluate/references/upload-safety.md

@@ -1,82 +0,0 @@
-# Upload Safety: Do Not Auto-Run `uip solution upload`
-
-The eval run requires the Flow solution to exist in Studio Web. The temptation, when an eval run errors with a missing-solution or missing-IDs error, is to "fix" it with `uip solution upload`. **Don't.**
-
-## The Rule
-
-**The skill must NEVER run `uip solution upload` automatically as part of an evaluation workflow. Always ask the user first.**
-
-This applies regardless of whether:
-
-- The local project was created via `uip maestro flow init` and never uploaded.
-- The local project was downloaded from Studio Web via `uip solution download` and edited locally.
-- The user is working in a VS Code-authored solution / personal workspace and the project may not match what is on Studio Web.
-- The CLI errors with `solution-id could not be resolved` or any variant.
-
-## Why
-
-`uip solution upload` is a write operation against Studio Web. It either creates a new solution or **overwrites** the existing one matched by `SolutionId` from the local working tree. Three concrete failure modes if the skill auto-uploads:
-
-1. **The user is iterating locally** in VS Code or the filesystem and intended to test something **before** publishing. Auto-upload pushes work-in-progress to Studio Web where teammates and triggers may pick it up.
-2. **The user pulled the solution from Studio Web** to edit a small piece. Auto-upload sends the partial local state back, potentially **overwriting** changes another user made on Studio Web in the meantime.
-3. **The local solution diverged from Studio Web** (e.g., a teammate edited the solution on Studio Web while the dev was working locally). Auto-upload silently discards the remote-side changes — they are not merged.
-
-In all three cases the user loses work or surprises a teammate. The cost of pausing to ask is one prompt; the cost of an unwanted upload can be hours of recovery.
-
-## What To Do Instead
-
-When `eval run start` cannot resolve the solution:
-
-1. **Stop and ask the user.** Use plain language: "Your Flow solution doesn't appear to be in Studio Web (or its IDs aren't resolvable from the local working tree). I can't run an eval until it is. How do you want to proceed?"
-2. **Offer the options explicitly:**
-   - **Upload now** — the user runs (or asks the skill to run) `uip solution upload <SolutionDir> --output json`. They acknowledge that this will write to Studio Web.
-   - **Pass IDs explicitly** — the user provides `--solution-id` and `--project-id` for an existing Studio Web solution. The skill plumbs them through to `eval run start`.
-   - **Cancel** — they meant to test something else (e.g., `flow debug`).
-3. **Wait for an explicit decision.** Do not infer one from context, prior commands, or comments in the project.
-
-## How to Detect "Local Workspace or VS Code"
-
-There is no single CLI flag that says "this project is local-only." The signals to weigh, in priority order:
-
-1. **`SolutionStorage.json` is missing or has no `SolutionId`.** The local working tree has not been linked to a Studio Web solution. `uip solution upload` would CREATE a new solution; the user might not want a new tenant entry.
-2. **`.vscode/` directory exists in the solution root.** Strong signal that the dev is authoring in VS Code; assume they are iterating locally.
-3. **The directory is under a workspace path the user has indicated they edit locally** (`~/Code/...`, `~/dev/...`, etc., or any path that is not the default Studio Web download location). Treat as local-first.
-4. **`uip solution upload` has never been recorded** in the recent shell history or in the conversation. If the skill cannot point to a prior explicit upload, do not assume the project is in Studio Web.
-
-If ANY of these signals is true, skip auto-upload entirely and ask.
-
-## How to Detect "Solution Already in Studio Web"
-
-The cheapest check is to attempt a read-only run command before doing anything else:
-
-```bash
-uip maestro flow eval run list --set "<set_name>" --path <flow_project> --output json
-```
-
-If this returns successfully (even with zero past runs), the solution is in Studio Web. If it errors with a missing-solution or auth error, treat the solution as not-yet-uploaded — and follow the rule above.
-
-Alternatively, `eval run start` itself will fail fast with a clear error. Either way: **read-only probe first; ask before upload.**
-
-## When the User Explicitly Asks to Upload
-
-If the user tells the skill to upload (e.g., "go ahead and upload the solution"), the skill is allowed to run:
-
-```bash
-uip solution upload <SolutionDir> --output json
-```
-
-In that response:
-
-1. Echo the command back so the user can see exactly what is being run.
-2. Run it and report the `SolutionId` and `DesignerUrl` from the output.
-3. Then proceed with the eval run.
-
-Even with explicit consent, do not chain `solution upload` automatically into the next step — surface the result first.
-
-## Anti-patterns
-
-- **Don't run `uip solution upload` as part of "fixing" an eval-run error.** Ask first.
-- **Don't infer consent from a vague instruction like "make the eval work."** That is not consent to upload; it is a request to diagnose.
-- **Don't auto-retry an eval run after a failed solution-resolution by attempting `uip solution upload` and re-running.** That doubles down on the wrong action.
-- **Don't run `uip solution upload` while another user might be editing the solution on Studio Web.** Even with explicit consent, warn the user that overwriting concurrent edits is a possible outcome.
-- **Don't combine `flow debug` and `eval run` in the same session against the same solution.** Each carries its own Studio Web debug session; mixing them confuses run IDs and may trigger unexpected uploads.

package/skills/uipath-maestro-flow/references/operate/references/run.md

@@ -1,99 +0,0 @@
-# Run — Execute a Flow
-
-Execute a flow on demand and monitor progress. Three modes: **debug** (controlled re-run with full Studio Web visibility), **process run** (trigger a deployed process), **job inspection** (status and traces). All require `uip login`.
-
-## Pre-flight
-
-1. **Logged in.** `uip login status --output json` returns success. See [shared/cli-conventions.md — Login state](../../shared/cli-conventions.md#5-login-state).
-2. **For debug runs: solution resources refreshed.** Always run before `flow debug` so connection and process resource declarations are in sync with project bindings:
-
-   ```bash
-   uip solution resources refresh --solution-folder <SolutionDir> --output json
-   ```
-
-## Debug — controlled end-to-end run
-
-> **Confirm consent first.** `flow debug` executes the flow for real — sends emails, posts messages, calls APIs. See the consent-before-debug rule in [SKILL.md](../../../SKILL.md). Do not run without explicit user authorization.
-
-```bash
-UIPCLI_LOG_LEVEL=info uip maestro flow debug <path-to-project-dir> --output json
-```
-
-The argument is the **project directory path** (the folder containing `project.uiproj`). Use `<ProjectName>/` from the solution dir, or `.` if already inside the project dir.
-
-Pass input arguments when the flow has input parameters:
-
-```bash
-UIPCLI_LOG_LEVEL=info uip maestro flow debug <path-to-project-dir> --output json \
-  --inputs '{"numberA": 5, "numberB": 7}'
-```
-
-Bind local files to file-typed input variables with `--attachment <variableId>=<localPath>` (repeatable). `<variableId>` (left of `=`) must match the `id` of a `variables.globals[]` entry with `direction:"in"` and `type:"file"`:
-
-```bash
-# Replace <variableId> and <localPath> placeholders below with your own values.
-UIPCLI_LOG_LEVEL=info uip maestro flow debug <path-to-project-dir> --output json \
-  --attachment <variableId>=<localPath> \
-  --attachment <variableId>=<localPath>
-```
-
-> **Pre-flight.** Confirm each `<variableId>` exists in the flow's `variables.globals[]` with `direction:"in"` and `type:"file"`. See [shared/cli-commands.md — Pre-flight](../../shared/cli-commands.md#pre-flight---attachment-binding).
-
-> **Reading the bound file.** At runtime a `file` variable is an object — a Script node reads the uploaded name via `$vars.{triggerNodeId}.output.{id}.FullName`. See [shared/variables-and-expressions.md — Runtime shape of a `file` variable](../../shared/variables-and-expressions.md#file-input).
-
-### Reporting debug runs to the user
-
-The CLI response includes a **Studio Web URL** (where the user inspects the run) and an **instanceId** (for log/trace correlation). Parse both from the JSON output — typically `Data.studioWebUrl` and `Data.instanceId` — and **always show them as the first two lines of the summary**:
-
-```text
-Studio Web URL: <url>
-Instance ID: <instanceId>
-
-<run status, node traces, errors, etc.>
-```
-
-If either value is missing from the response, emit the label with `<not returned by CLI>` rather than dropping the line. Do not bury these values below the run summary — the user should see them immediately without scrolling.
-
-See [shared/cli-commands.md — uip maestro flow debug](../../shared/cli-commands.md#uip-maestro-flow-debug) for additional options.
-
-## Process run — trigger a deployed process
-
-For flows already deployed to Orchestrator (via [ship.md](ship.md) → Orchestrator path):
-
-```bash
-uip maestro flow process list --output json                           # discover deployed processes
-uip maestro flow process run <process-key> <folder-key> --output json # trigger a run
-```
-
-Pass input arguments and/or bind file-typed input variables:
-
-```bash
-# Replace <variableId> and <localPath> placeholders below with your own values.
-uip maestro flow process run <process-key> <folder-key> --output json \
-  --inputs '{"numberA": 5, "numberB": 7}' \
-  --attachment <variableId>=<localPath>
-```
-
-> **Pre-flight.** Confirm each `<variableId>` exists in the flow's `variables.globals[]` with `direction:"in"` and `type:"file"` — see [shared/cli-commands.md — Pre-flight](../../shared/cli-commands.md#pre-flight---attachment-binding). On `process run` only: `--attachment` overrides `--inputs` on key collisions; `--validate` accepts pre-uploaded attachment references for file-typed slots (passes the JSON-schema check even though the slot's nominal type is `string`).
-
-Run `uip maestro flow process --help` for all subcommands and options.
-
-## Job inspection — status and traces
-
-```bash
-uip maestro flow job status <job-key> --output json   # check status of a running or completed job
-uip maestro flow job traces <job-key> --output json   # stream the verbose execution timeline
-```
-
-> **Traces are verbose** and contain the full execution timeline. Use them only when needed for diagnosis — start from incidents first via [diagnose/CAPABILITY.md](../../diagnose/CAPABILITY.md).
-
-## What's next
-
-- **Run failed?** Triage via [diagnose/CAPABILITY.md](../../diagnose/CAPABILITY.md) — start with incidents, escalate to traces only if needed.
-- **Need to intervene in a running instance** (pause, resume, cancel, retry)? See [manage.md](manage.md).
-
-## Anti-patterns
-
-- **Never run `flow debug` as a validation step.** Use `uip maestro flow validate` for correctness checking; debug is for end-to-end execution.
-- **Never skip `solution resources refresh` before debug.** Stale resource declarations cause runtime binding failures even when the local `.flow` is correct.
-- **Never start diagnosis from `job traces`.** Traces are last-resort — see [diagnose/CAPABILITY.md](../../diagnose/CAPABILITY.md) for the priority ladder.