@uipath/skills 1.195.0

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

@@ -0,0 +1,66 @@
+# case-management task — Implementation (Direct JSON Write)
+
+> **Phase split.** Phase 2 writes shape with empty input values. Phase 3 binds values per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). See [phased-execution.md](../../../phased-execution.md).
+
+## Task JSON Shape
+
+```json
+{
+  "id": "tZ8rMn4Vp",
+  "type": "case-management",
+  "displayName": "Run Vendor Onboarding Sub-Case",
+  "elementId": "Stage_aB3kL9-tZ8rMn4Vp",
+  "isRequired": true,
+  "shouldRunOnlyOnce": true,
+  "data": {
+    "name": "=bindings.bG0SraLpg",
+    "folderPath": "=bindings.bH1iJK2lm",
+    "inputs": [],
+    "outputs": []
+  }
+}
+```
+
+- `id`: `t` + 8 alphanumeric chars. `elementId`: `${stageId}-${taskId}`.
+- `data.name` / `data.folderPath` MUST be `=bindings.<id>` references — never literals.
+
+## Procedure
+
+**Step 0 — Get inputs/outputs schema:**
+
+```bash
+uip maestro case tasks describe --type case-management --id "<entityKey>" --output json
+```
+
+Fallback: planning-captured schema from tasks.md. If unavailable, placeholder per [placeholder-tasks.md](../../../placeholder-tasks.md).
+
+**Step 1 — Root-level bindings:**
+
+Read [bindings/impl-json.md § Full binding shape — non-connector tasks](../../variables/bindings/impl-json.md) for the canonical 7-field shape (all required — omitting any causes Studio Web render failure). Per-task overrides:
+
+- `resource`: `"process"`
+- `resourceSubType`: `"CaseManagement"`
+- `name` / `folderPath` defaults: from `tasks.md` `name` / `folder-path` fields
+
+Dedup per [§ Deduplication](../../variables/bindings/impl-json.md).
+
+**Step 2 — Write task:**
+
+1. Generate `id` (`t` + 8 chars) and `elementId` (`<stageId>-<taskId>`)
+2. **Recursion guard** — confirm the sub-case `entityKey` from tasks.md does NOT match the current case's own entityKey (direct recursion) and does not appear as an ancestor in already-written `case-management` tasks (transitive recursion). If either check fails, flag for user review.
+3. Set `data.name` = `=bindings.<nameBindingId>`, `data.folderPath` = `=bindings.<folderPathBindingId>`
+4. Write `data.inputs[]` / `data.outputs[]` from Step 0 schema. Each input: `{ name, type, id, var, elementId, value: "" }`. Each output: `{ name, type, id, var, value, source, target, elementId }`.
+
+   **Output binding.** Apply [io-binding/impl-json.md § Output Binding Shapes](../../variables/io-binding/impl-json.md#output-binding-shapes). The Step 0 schema for this plugin is the `tasks describe` output (Step 0 above).
+5. Append to target stage's `tasks[laneIndex][]`
+
+> Entry conditions added in Step 10. Input value bindings in Phase 3 per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md).
+
+## Post-Write Verification
+
+- `type: "case-management"`
+- `data.name` and `data.folderPath` start with `=bindings.`
+- the bindings array has 2 entries: `resource: "process"`, `resourceSubType: "CaseManagement"`, `propertyAttribute` = `name` / `folderPath`
+- `data.inputs` and `data.outputs` populated (unless placeholder)
+- No circular self-reference
+- `id` captured in `id-map.json`

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

@@ -0,0 +1,52 @@
+# case-management task — Planning
+
+A nested case task. Invokes another case definition as a sub-case within the current one. Enables hierarchical / recursive case structures.
+
+## When to Use
+
+Pick this plugin when the sdd.md describes a task that spawns or delegates to another case definition. Typical patterns:
+
+- Parent case orchestrates multiple sub-cases
+- Long-running sub-workflow packaged as its own case
+
+If sdd.md describes a simple stage-to-stage flow within the same case, do not use this — use regular stages and edges.
+
+## Required Fields from sdd.md
+
+| Field | Source | Notes |
+|-------|--------|-------|
+| `display-name` | Case Reference "Name" | |
+| `name` | Case Reference "Name" | |
+| `folder-path` | Case Reference "Folder" | |
+| `task-type-id` | Registry resolution (below) | `entityKey` in `caseManagement-index.json` |
+| `inputs` | sdd.md task data mapping | Passed as case-instance inputs to the sub-case |
+| `outputs` | Discovered via `tasks describe` | Returned when the sub-case completes |
+| `runOnlyOnce` | sdd.md (default `true`) | |
+| `isRequired` | sdd.md (default `true`) | |
+
+## Registry Resolution
+
+1. **Primary cache file:** `caseManagement-index.json`.
+2. **Identifier field:** `entityKey`.
+3. Match by exact name + folder.
+4. Discover inputs/outputs via `tasks describe` — see [bindings-and-expressions.md § Discovering output names](../../../bindings-and-expressions.md).
+
+## Unresolved Fallback
+
+Mark `<UNRESOLVED: case "<name>" in folder "<folder>" not found in caseManagement-index.json>`. Omit `inputs:` and `outputs:`; capture intended wiring in a fenced ```` ```text ```` code block (not `#` prefixed — it renders as markdown H1). Execution creates a placeholder task — see [placeholder-tasks.md](../../../placeholder-tasks.md). Note: if the referenced sub-case has not been deployed yet, it will not appear in the registry — the user must deploy it before the parent case can reference it.
+
+## tasks.md Entry Format
+
+```markdown
+## T<n>: Add case-management task "<display-name>" to "<stage>"
+- taskTypeId: <entityKey>
+- folder-path: "<folder>"
+- inputs:
+  - <input_name> = "<value>"
+- outputs: <out1>, <out2>
+- runOnlyOnce: true
+- isRequired: true
+- order: after T<m>
+- lane: <n>  # FE layout; increment per task. Within `runs-sequentially` group, parallel members share a lane (semantic).
+- verify: Confirm Result: Success, capture TaskId
+```

package/skills/uipath-maestro-case/references/plugins/tasks/connector-activity/impl-json.md

@@ -0,0 +1,271 @@
+# connector-activity task — Implementation (Direct JSON Write)
+
+> **Node `type` value: `execute-connector-activity` (schema-kebab).** NEVER write `connector-activity` (plugin folder name) or `connector_activity` into the JSON `type` field. The CLI `--type connector-activity` flag is a separate concept — used only when calling `uip maestro case tasks describe` (legacy) or `uip maestro case spec --type activity` (current). See SKILL.md Rule 16 + Plugin Index.
+
+> **Phase split.** Runs across both phases. Phase 2 writes `data.typeId` + `data.connectionId` only — no `case spec` call in Phase 2. Phase 3 calls `case spec --input-details` once, reads the populated `caseShape`, and mints the task. See [`../../../phased-execution.md`](../../../phased-execution.md).
+
+Fetch the populated connector task scaffold via `uip maestro case spec --input-details`, then drop it into `caseplan.json`. Field discovery and reference resolution are done during [planning](planning.md) — implementation reads resolved values from `tasks.md` and threads them through the spec call.
+
+## Prerequisites from Planning
+
+The `tasks.md` entry provides:
+
+| Field | Example |
+|---|---|
+| `type-id` | `"c7ce0a96-2091-3d94-b16f-706ebb1eb351"` |
+| `connection-id` | `"bc095c1f-671f-4669-8634-b7164fa46aa0"` |
+| `connector-key` | `"uipath-microsoft-outlook365"` |
+| `object-name` | `"send-mail-v2"` |
+| `input-values` | `{"bodyParameters":{"message.toRecipients":"user@example.com"},"queryParameters":{...}}` (already resolved IDs, dotted body keys) |
+| `filter` (optional) | `{"groupOperator":"And","filters":[...]}` (FilterTree object — present only when planning Step 7 authored a filter) |
+| `isRequired` | `true` |
+| `runOnlyOnce` | `false` |
+
+## Configuration Workflow
+
+### Step 1 — Build `--input-details` JSON from tasks.md
+
+Construct the input-details object from `tasks.md`, rewriting every value containing a reference to its canonical sink form (connector body fields use `=js:(<expr>)`):
+
+```jsonc
+{
+    // bodyParameters from tasks.md input-values.bodyParameters (dotted keys preserved;
+    // each value rewritten to canonical form per Step 1.a)
+    "bodyParameters": "<input-values.bodyParameters with values rewritten>",
+    // queryParameters from tasks.md input-values.queryParameters (same rewrite rule)
+    "queryParameters": "<input-values.queryParameters with values rewritten>",
+    // pathParameters from tasks.md input-values.pathParameters (same rewrite rule)
+    "pathParameters":  "<input-values.pathParameters with values rewritten>",
+    // filter — FilterTree object from tasks.md (or omit when not authored)
+    "filter": "<filter from tasks.md or omit>"
+}
+```
+
+Synthetic HTTP request activities (`object-name === "httpRequest"` / `"http-request"`) reject `bodyParameters` — pass HTTP body via `queryParameters` instead, or omit. The CLI rejects bodyParameters at validation time.
+
+Full input-details contract: [`case-spec-input-details.md`](../../../case-spec-input-details.md).
+
+#### Step 1.a — Rewrite references to canonical sink form
+
+Connector body sinks (`bodyParameters`, `queryParameters`, `pathParameters`) require `=js:(...)` wrap for every reference. Resolve cross-task refs first, then apply the wrap:
+
+| Value in tasks.md | Value passed to CLI |
+|---|---|
+| `"=vars.X"` | `"=js:(vars.X)"` |
+| `"=metadata.X"` | `"=js:(metadata.X)"` |
+| `"=bindings.X"` | `"=js:(bindings.X)"` |
+| `"=<other-prefix>.X"` (e.g. `=response.X`, `=Error.X`, `=datafabric.X`, `=orchestrator.JobAttachments[0]`) | `"=js:(<other-prefix>.X)"` — strip leading `=`, wrap in `=js:(...)` |
+| `"<- "Stage"."Task".out"` | resolve to `"=vars.<outputVar>"` → `"=js:(vars.<outputVar>)"` |
+| `"=js:(<expr>)"` (pre-wrapped operator expression) | pass-through unchanged |
+| `"<literal value>"` (no leading `=`) | pass-through unchanged |
+
+Full per-sink rule and FE source-of-truth: [bindings-and-expressions.md § Canonical form per sink](../../../bindings-and-expressions.md#canonical-form-per-sink).
+
+#### Step 1.b — Array-of-object body fields: pre-input scan (MANDATORY)
+
+Before passing `bodyParameters` to the CLI, scan for keys containing literal `[*]`. Halt if any are present — the binding is malformed.
+
+The `[*]` in `inputs.bodyFields[].name` is **schema notation** (JSONPath-style "array of") for documentation only — NOT a valid input key. Array-of-object body fields MUST be expressed in tasks.md `input-values.bodyParameters` as real JSON arrays under the parent name (see [`planning.md` § Array-of-object body fields](planning.md)). The planner is responsible for emitting the correct shape; this step is a safety net.
+
+**Halt condition.** If any `bodyParameters` key contains literal `[*]`, halt with explicit error:
+```
+ERROR: bodyParameters key '<key>' contains literal '[*]'.
+        Spec field was: <spec field name>. Expected: '<parent>' with a real JSON array value.
+        Fix in tasks.md input-values.bodyParameters; do NOT pass [*] keys to the CLI.
+```
+
+The CLI accepts the literal `field[*]` key (well-formed JSON) and validate passes, but runtime APIs reject with HTTP 400 `UnableToDeserializePostBody`. The check repeats as a post-write verification — see [Step 8 Post-Write Verification](#post-write-verification) item #11.
+
+### Step 2 — Run `case spec` with input-details
+
+```bash
+uip maestro case spec --type activity \
+  --activity-type-id "<type-id>" \
+  --connection-id "<connection-id>" \
+  --input-details "<json from Step 1>" \
+  --output json
+```
+
+The Phase 3 call omits `--skip-case-shape` (incompatible with `--input-details` — see [case-spec-input-details.md § Validation rules](../../../case-spec-input-details.md#validation-rules-invalidinputdetailserror-on-violation)). The CLI returns the full `caseShape` populated with values from `--input-details`.
+
+Save the response. The interesting parts:
+
+> **`case spec --output json` returns PascalCase keys.** The `.Data.*` read paths below reflect that (`.Data.CaseShape.Context`, not `.Data.caseShape.context`). A camelCase jq path returns `null`. The spliced subtree is re-cased to camelCase on the way to disk — see Step 6.
+
+| Variable | Source |
+|---|---|
+| `spec.identity` | `.Data.Identity` — connectorKey, connectorName, connectorVersion, objectName, objectDisplayName, full TypeCache entry |
+| `spec.connection.folderKey` | `.Data.Connection.FolderKey` — needed for the FolderKey binding |
+| `spec.caseShape.inputs[]` | `.Data.CaseShape.Inputs` — pre-filled body / queryParameters / pathParameters / file inputs |
+| `spec.caseShape.outputs[]` | `.Data.CaseShape.Outputs` — response (JSON Schema body) / curated / Error |
+| `spec.caseShape.context[]` | `.Data.CaseShape.Context` — 8-entry FE-canonical array, with `{{CONN_BINDING_ID}}` / `{{FOLDER_BINDING_ID}}` placeholders |
+| `spec.diagnostics.fallbacks[]` | `.Data.Diagnostics.Fallbacks` — surface to `build-issues.md` when non-empty. |
+
+> **Each connector task runs its own `case spec`.** Even when two tasks share the same `connection-id`, `caseShape` is task-shape-specific (different `objectName`, `httpMethod`, `inputs`, `outputs`). Never reuse another task's spec output.
+
+### Step 3 — Required-field validation (HARD GATE)
+
+This is a hard gate — do NOT proceed to write the task until every required field has a non-empty value in the `caseShape.inputs[].body`.
+
+1. From the lean planning-phase spec (run with `--skip-case-shape` in [planning](planning.md) Step 3), collect `inputs.*[?required]`.
+2. After Step 2's call (with the populated caseShape), scan `caseShape.inputs[].body` and verify every required field has a value.
+3. If any required field is missing, **AskUserQuestion** — list the missing fields with their `displayName` and what kind of value is expected. Free-form input is appropriate when the value space is open-ended (channel names, message bodies, IDs); when a finite set of sensible values exists (e.g. an `enum`), present them via AskUserQuestion per the dropdown rule in [SKILL.md](../../../../SKILL.md).
+4. Re-run Step 2 after collecting the missing values, OR fall back to placeholder task per Rule 8 if user declines to provide a value.
+
+> **Do NOT guess or skip missing required fields.** A missing required field will cause a runtime error. It is always better to ask than to assume.
+
+### Step 4 — FilterBuilder detection (when planning authored a filter)
+
+When `tasks.md` carries a `filter:` object, the activity's operation must declare a `FilterBuilder` design parameter. The CLI rejects the filter at configure time when no FilterBuilder param exists; the planning step 7 should already have caught this by checking `spec.filter` presence, but verify here as a safety net.
+
+- `spec.filter` present (with `builder: "ceql"` and `fields[]`) → CEQL filter is supported. Pass the structured tree under `--input-details.filter`. The CLI compiles it into both halves of the contract: the runtime CEQL string at `caseShape.inputs[name="queryParameters"].body.<filterParamName>` AND the design-time tree under `essentialConfiguration.savedFilterTrees.<filterParamName>` (inside the `=jsonString:` blob in `caseShape.context[name="metadata"].body.activityPropertyConfiguration.configuration`).
+- **Do NOT pass a raw CEQL string under `queryParameters.where`** (or whichever connector-specific name) when authoring a filter. The CLI rejects this; even if it didn't, the design-time tree would be empty and Studio Web would render the filter widget as `undefined` when the activity is reopened.
+- Tree shape, operator table, examples → [/uipath:uipath-platform — Filter Trees (CEQL)](../../../../../uipath-platform/references/integration-service/activities.md#filter-trees-ceql).
+
+If the operation has no FilterBuilder parameter, server-side filtering is not supported — the spec will return `filter: undefined`. Filter downstream (post-execution) instead.
+
+### Step 5 — Mint binding IDs
+
+Mint two prefixed IDs for the connection + folder bindings:
+
+| Binding | ID format |
+|---|---|
+| Connection binding | `b` + 8 alphanumeric chars (e.g. `bA1B2C3D4`) |
+| Folder binding | `b` + 8 alphanumeric chars (different from connection binding) |
+
+These ids are **picked inline by the agent** (per SKILL.md Rule 13) — no subprocess.
+
+Save them as `<connBindingId>` and `<folderBindingId>` for Step 6.
+
+### Step 6 — Substitute binding placeholders in `caseShape.context`
+
+`caseShape.context[]` carries placeholders at the spec output:
+
+```jsonc
+[
+    { "name": "connection", "type": "string", "value": "=bindings.{{CONN_BINDING_ID}}" },
+    { "name": "folderKey",  "type": "string", "value": "=bindings.{{FOLDER_BINDING_ID}}" },  // present only when spec.connection.folderKey !== null
+    // …other entries (connectorKey, resourceKey, objectName, method, path, metadata) — values are fully resolved already
+]
+```
+
+Replace the two placeholders with the minted ids:
+
+- `{{CONN_BINDING_ID}}` → `<connBindingId>` (Step 5)
+- `{{FOLDER_BINDING_ID}}` → `<folderBindingId>` (Step 5; entry only present when folderKey was non-null)
+
+The **entire** `caseShape.context[]` array, and every nested subtree under it, is CLI-authoritative. The ONLY permitted modifications are the placeholder substitutions in the table above and the key-casing normalization below. **Every other key — current or future, top-level or nested — must be copied from the spec output, regardless of what those keys are or how many there are.** The doc cannot enumerate them all; the CLI's emitted shape is the contract. Composing or reconstructing any subtree of `caseShape.context` from agent memory is FORBIDDEN.
+
+> **Mechanical contract.** At gather time (Step 2), persist the full `case spec` response to `tasks/spec-cache.<elementId>.json` (one file per task). At write time, **Read that file and splice `Data.caseShape.context` verbatim** into `data.context`, then re-case keys (next paragraph). The skill is a substituter, not a composer — the only edits between Read and Write are the placeholder substitutions above and that keys-only re-casing. **Never retype `context` content from agent reasoning.**
+
+> **Normalize key casing (PascalCase → camelCase).** `case spec --output json` emits PascalCase keys (`Name`/`Type`/`Value`/`Target`/`Body`/`DisplayName`/`Source`; nested `ActivityPropertyConfiguration`/`UiPathActivityTypeId`/…; response-schema `Properties`/`Definitions`/`Title`/`Items`); the caseplan disk schema is camelCase. After splicing `context` / `inputs` / `outputs` (and their nested `body`), lower-case the first character of every object **key**, preserving the rest (`DisplayName`→`displayName`, `UiPathActivityTypeId`→`uiPathActivityTypeId`). **Keys only — never values:** `"name": "Subject"`, `"source": "=response.Subject"`, and `=jsonString:` / `=js:` blobs are case-sensitive identifiers and stay verbatim. Full rule + rationale: [connector-trigger-common.md § Normalize key casing](../../../connector-trigger-common.md#normalize-key-casing-pascalcase--camelcase).
+
+### Step 7 — Mint `var` / `id` / `elementId` on inputs and outputs
+
+Generate task ID (`t` + 8 alphanumeric chars) and elementId (`<stageId>-<taskId>`).
+
+For each entry in `caseShape.inputs[]`:
+- `var` = `v` + 8 alphanumeric chars (unique across the case — see uniqueness rule in [global-vars/impl-json.md](../../variables/global-vars/impl-json.md))
+- `id` = same as `var`
+- `elementId` = the task's elementId
+
+For each entry in `caseShape.outputs[]`:
+- Same fields, plus the **dedup rule**: `caseShape.outputs[]` returns generic names like `response` and `error` for every connector task. When multiple connector tasks exist in the same case, these collide. Apply the [uniqueness rule](../../variables/global-vars/impl-json.md#uniqueness-rule): collect all existing output `var` values across every task already in `caseplan.json`; if a `var` already exists, append a counter suffix starting at 2 (e.g., `response` → `response2`, `error` → `error2`). Update `var`, `id`, `value`, and `target` (as `=<new var>`) with the suffixed name. `name`, `displayName`, and `source` stay unchanged.
+
+**Output binding.** Apply [io-binding/impl-json.md § Output Binding Shapes](../../variables/io-binding/impl-json.md#output-binding-shapes). The Step 0 schema for this plugin is `caseShape.outputs[]` from `case spec` (Step 2 above). The dedup rule above applies first; output binding consumes the deduped names.
+
+#### Step 7.a — Multipart file inputs
+
+When `caseShape.inputs[]` contains an entry with `target: "file"` (multipart sink — emitted by `case spec` for activities whose IS spec has `multipart.parameters[].isFile === true`, e.g., Outlook Send Email):
+
+- `target` is a **literal string** `"file"` (the IS request-shape multipart sink name), NOT an expression. Preserve verbatim — do not prepend `=`.
+- `value` MUST be `"=vars.<fileVarId>"` (whole-record reference). The FE picker is `selectionOnly` for file inputs (`IntsvcActivityPropertiesUtils.tsx:272-279`) — only a file-typed case Variable can be wired; freeform expressions are rejected at picker time. Sub-field references (`=vars.<id>.FullName`) are NOT valid for file inputs — the runtime adapter expects the full JobAttachment record to dereference.
+- No `source`, no `body`, no `displayName` on the multipart file input entry — `case spec` returns just `{name, type, target}`; mint `var` / `id` / `elementId` / `value` per Step 7 and stop.
+- The runtime adapter dereferences `=vars.<fileVarId>` to the JobAttachment record at execution time and streams bytes from the JobAttachment store into the multipart `file` part of the outbound HTTP request.
+
+### Step 8 — Build `data` and write to caseplan.json
+
+Generate the task skeleton:
+
+```json
+{
+  "id": "<taskId>",
+  "type": "execute-connector-activity",
+  "displayName": "<display-name from tasks.md>",
+  "elementId": "<stageId>-<taskId>",
+  "isRequired": "<from tasks.md, default true>",
+  "shouldRunOnlyOnce": "<from tasks.md runOnlyOnce, default false>",
+  "data": {
+    "serviceType": "Intsvc.ActivityExecution",
+    "context": "<caseShape.context — placeholders substituted in Step 6>",
+    "inputs":  "<caseShape.inputs  — var/id/elementId minted in Step 7>",
+    "outputs": "<caseShape.outputs — var/id/elementId minted, dedup applied in Step 7>",
+    "bindings": []
+  }
+}
+```
+
+Append the task to the target stage's `tasks[]` array. Default: own task set (one task per lane). **Exception:** if this task is a parallel member of a `runs-sequentially` group, push into the shared lane of that group (shared lane = parallel siblings inside the sequence, semantic).
+
+### Step 9 — Append root-level bindings
+
+Read [bindings/impl-json.md § Full binding shape — connector tasks](../../variables/bindings/impl-json.md) for the canonical 7-field shape on each entry (all required — omitting any causes Studio Web render failure). Per-task value sources:
+
+- `<connection-id>` (drives `resourceKey` on both bindings + ConnectionBinding `default`): from this task's `tasks.md` entry
+- `<connectorKey>` (drives ConnectionBinding templated `name`): from `tasks.md`
+- `<folderKey>` (FolderKey binding `default`): from `spec.connection.folderKey` in Step 2 response. **Omit the FolderKey binding entirely when this value is null** (matches `binding-builder.ts:73-83`).
+- Binding IDs `<connBindingId>` / `<folderBindingId>` come from Step 5.
+
+Dedup per [§ Deduplication](../../variables/bindings/impl-json.md). Source-of-truth code: `binding-builder.ts` in `uipcli-case-validate/packages/case-tool/src/utils/`.
+
+### Step 10 — Sync IS connection cache
+
+After writing root bindings, populate IS connection cache per [bindings-v2-sync.md § Populate IS connection cache](../../../bindings-v2-sync.md). Skip if `case spec` failed.
+
+> **`bindings_v2.json` regeneration is deferred** — runs once at end of Step 9.7 in [implementation.md](../../../implementation.md) (after all connector tasks), not per-task. See [bindings-v2-sync.md § When to Run](../../../bindings-v2-sync.md).
+
+## Graceful degradation
+
+**Always create the task** — even on errors. Start with `data: { "serviceType": "Intsvc.ActivityExecution" }` and progressively populate.
+
+| Step failed | What gets populated | Log |
+|---|---|---|
+| `case spec` fails | Phase 2 shape preserved — `data.typeId` + `data.connectionId` only, no Phase 3 inputs/outputs/context enrichment. Distinct from a Rule 8 placeholder (`data: {}`) — typeId/connectionId are resolved, only the spec-driven enrichment is skipped. Log per Rule 8 reporting | `[SKIPPED] case spec failed — typeId/connectionId preserved, no enrichment` |
+| Required-field gate fails (user declines) | Placeholder per Rule 8 OR re-prompt | `[SKIPPED] required field <name> missing — placeholder task per Rule 8` |
+| All succeed | Full population per Steps 5-10 including bindings_v2 sync | — |
+
+All issues appended to the shared issue list per [logging/impl-json.md](../../logging/impl-json.md).
+
+## Post-Write Verification
+
+1. `type` is `"execute-connector-activity"`
+2. `data.serviceType` is `"Intsvc.ActivityExecution"`
+3. `data.context[]` has: `connectorKey`, `connection`, `resourceKey`, `folderKey` (when applicable), `objectName`, `method`, `path`, `metadata` — but NOT `operation` or `_label`
+4. `data.context[name="connection"].value` is `=bindings.<connBindingId>` (substituted from `{{CONN_BINDING_ID}}`)
+5. `data.context[name="folderKey"].value` is `=bindings.<folderBindingId>` (substituted from `{{FOLDER_BINDING_ID}}`); entry absent when `spec.connection.folderKey` was null
+6. `data.context[name="metadata"].body.activityPropertyConfiguration.configuration` is a `=jsonString:…` string (CLI-produced; do not modify)
+7. Root bindings exist for ConnectionId + folderKey with the minted ids
+8. `data.bindings[]` is empty `[]`
+9. Each entry in `data.inputs[]` and `data.outputs[]` has `var` / `id` / `elementId` minted (uniqueness rule applied for outputs)
+10. `bindings_v2.json` `resources` array matches the schema-appropriate bindings array (v19: `root.data.uipath.bindings[]`; v20: top-level `bindings[]`) after the deferred sync
+11. **No literal `[*]` keys in `data.inputs[name="body"].body` (or any input body).** Scan recursively (JSON.stringify + regex `"[^"]*\\[\\*\\][^"]*"\\s*:`). If any key contains literal `[*]`, halt — Step 1.b translation was skipped or incomplete. The body MUST use real arrays under parent names (e.g., `"toRecipients": [{...}]`), never `"toRecipients[*]": {...}`. Validate passes regardless; runtime APIs reject with HTTP 400.
+
+## What NOT to Do
+
+- **Do NOT add `operation` or `_label` to `data.context[]`.** The FE only adds `operation` for triggers; activity context must not have it.
+- **Do NOT add `designTimeMetadata` to the metadata body.** The FE does not include it for case management tasks.
+- **Do NOT add top-level `errorState` to the metadata body.** Error state belongs inside `activityPropertyConfiguration.errorState` only — that's already the shape in `caseShape.context`.
+- **Do NOT copy root bindings into `data.bindings[]`.** Leave it as `[]`. The FE crashes if activity tasks have task-level binding copies.
+- **Do NOT reconstruct `caseShape.context` (or any nested subtree) from agent memory.** Printing the keys of `context` and later re-emitting from memory drops any subtree not fully expanded in context. Persist the full `case spec` response to `tasks/spec-cache.<elementId>.json` at gather time; at Write time, Read it and splice `Data.caseShape.context` verbatim. See Step 6.
+- **Do NOT write the spec's PascalCase keys to disk verbatim.** `case spec` emits PascalCase; the caseplan disk schema is camelCase. After splicing, lower-case the first character of every object key in the spec subtree — keys only, never values. See Step 6 and [connector-trigger-common.md § Normalize key casing](../../../connector-trigger-common.md#normalize-key-casing-pascalcase--camelcase).
+- **Do NOT pass a raw CEQL string under `queryParameters.where`** (or whichever connector-specific name) when authoring a filter. Pass the structured tree under `filter:` in tasks.md and let the CLI compile both halves.
+- **Do NOT pass `ceqlExpression` directly under `--input-details`.** Derived only.
+- **Do NOT pass `bodyParameters` for synthetic HTTP request activities.** Use `queryParameters` instead, or omit.
+- **Do NOT pass literal `field[*]` keys in `bodyParameters`.** The `[*]` in `inputs.bodyFields[].name` is JSONPath-style schema notation meaning "array of"; it is NOT a valid input key. Express array-of-object body fields as real JSON arrays under the parent name (see [planning.md](planning.md)). Pre-input scan in [Step 1.b](#step-1b--array-of-object-body-fields-pre-input-scan-mandatory) halts on any literal `[*]` key.
+- **Do NOT auto-inject `entryConditions`.** Step 10 in [implementation.md](../../../implementation.md) handles them — injecting here creates duplicates.
+- **Never reuse a reference ID from a prior case or session.** Reference IDs (e.g., Jira project keys, Slack channel IDs) are scoped to the authenticated account behind each connection. Always resolve fresh via `uip is resources run list` against the current `--connection-id`. See [/uipath:uipath-platform — reference-resolution.md § Reference IDs Are Connection-Scoped (CRITICAL)](../../../../../uipath-platform/references/integration-service/reference-resolution.md#reference-ids-are-connection-scoped-critical).
+- **Do NOT call legacy `uip maestro case tasks describe` or `uip is resources describe`.** `case spec --input-details` replaces both. The legacy commands still work but produce a different shape that doesn't include `caseShape` / placeholders.
+
+## Known Limitations
+
+- The CLI-produced `essentialConfiguration` uses `essentialConfiguration` only (not `optionalConfiguration`). Tasks work at runtime (debug/publish) but the FE editor may not render certain fields until the user re-configures the task in the UI. DAP repopulates these on form open. Documented in `~/Documents/knowledge/Skill_CLI/connector/case-spec-fe-discrepancies.md` (CLI-side).

package/skills/uipath-maestro-case/references/plugins/tasks/connector-activity/planning.md

@@ -0,0 +1,202 @@
+# connector-activity task — Planning
+
+A connector activity task inside a stage. Calls an external service (Jira, Slack, Salesforce, Gmail, etc.) via UiPath Integration Service.
+
+This plugin is **schema-data-driven** — one plugin covers every connector. Connector-specific input shapes are discovered from the `case spec` CLI's normalized output, not baked into this plugin.
+
+## When to Use
+
+Pick this plugin when the sdd.md describes a task as `CONNECTOR_ACTIVITY` or names a specific external service action (e.g., "send a Slack message", "create a Jira issue", "update Salesforce opportunity").
+
+For **connector-based triggers** inside a stage (wait for an external event), use [connector-trigger](../connector-trigger/planning.md).
+
+For **case-level event triggers** (outside any stage), use [`plugins/triggers/event/`](../../triggers/event/planning.md).
+
+## Resolution Pipeline
+
+Run these steps during planning. Each step feeds into the `tasks.md` entry.
+
+### 1. Find the connector in TypeCache
+
+If `~/.uip/case-resources/typecache-activities-index.json` does not exist, run `uip maestro case registry pull` first (missing file is a precondition failure, not a 0-match — Rule 17 gate does not apply). If still missing after pull, the tenant has no connector activities — emit placeholder per § Unresolved Fallback below.
+
+Read `~/.uip/case-resources/typecache-activities-index.json` directly. Match on `displayName` or `connectorKey` + operation description from sdd.md. Record `uiPathActivityTypeId`.
+
+### 2. Resolve the connection
+
+```bash
+uip maestro case registry get-connection \
+  --type typecache-activities \
+  --activity-type-id "<uiPathActivityTypeId>" --output json
+```
+
+Returns `Entry`, `Config`, and `Connections`.
+
+- **Single connection** → use it.
+- **Multiple connections** → **AskUserQuestion** with connection names + "Something else".
+- **Empty `Connections`** → mark `<UNRESOLVED: no IS connection for <connectorKey>>` and omit `input-values:`. Execution creates a placeholder task — see [placeholder-tasks.md](../../../placeholder-tasks.md).
+
+Record `connection-id`, `connector-key`, `object-name` from the response.
+
+Connection selection rules (default-preference, `--refresh` retry, multi-connection disambiguation, ping verification, BYOA workflow): see [/uipath:uipath-platform — connections.md](../../../../../uipath-platform/references/integration-service/connections.md).
+
+### 3. Discover the operation contract via `case spec`
+
+One CLI call replaces the legacy `case tasks describe` + `is resources describe` dance:
+
+```bash
+uip maestro case spec --type activity \
+  --activity-type-id "<uiPathActivityTypeId>" \
+  --connection-id "<connection-id>" \
+  --skip-case-shape \
+  --output json
+```
+
+`--skip-case-shape` returns a leaner response (no `caseShape`) — the right size for planning. Phase 3 re-runs the same command without the flag, plus `--input-details`, to mint the populated `caseShape`. See [`case-spec-input-details.md`](../../../case-spec-input-details.md) for the full `--input-details` JSON contract.
+
+> **Synthetic HTTP request branch.** When `spec.identity.objectName` is `"httpRequest"` or `"http-request"`, the activity is the synthetic generic-HTTP path — `bodyParameters` is rejected (no curated body schema). Pass HTTP body via `queryParameters` instead, or omit. Spec output reflects this in `inputs.bodyFields = []`.
+
+The response carries everything the planning phase needs:
+
+| Spec output | What it tells you |
+|---|---|
+| `inputs.bodyFields[]` | Body request fields with `name` (dotted), `dataType`, `required`, `description`, optional `defaultValue` / `enum` / `reference` |
+| `inputs.pathParameters[]`, `inputs.queryParameters[]` | URL-template substitutions and query-string params with the same per-field shape |
+| `inputs.multipart` | `null` for non-multipart; otherwise `{ bodyFieldName, parameters[] }` — multipart upload contract |
+| `outputs.responseFields[]` | Response shape; `[?responseCurated]` are FE-broken-out outputs, `[?primaryKey]` are id fields |
+| `outputs.pagination` | `null` for non-list, `{ maxPageSize: N }` for list operations |
+| `filter` | `undefined` when the activity does NOT support server-side filtering. Present when it does, with `builder: "ceql"` and `fields[]` listing every searchable field |
+| `references[]` | Cross-references (lookups). Each entry includes a pre-built `discoverCommand` runnable string |
+| `diagnostics.fetched` / `fallbacks` | What endpoints succeeded / fell back; surface `fallbacks` to the user when meaningful |
+
+### 4. Resolve reference fields
+
+Check `inputs.{bodyFields, pathParameters, queryParameters}` for entries with a `reference` object. Each carries a pre-built `discoverCommand`:
+
+```jsonc
+"reference": {
+    "objectName": "MailFolder",
+    "lookupValue": "id",
+    "lookupNames": ["displayName"],
+    "discoverCommand": "uip is resources run list uipath-microsoft-outlook365 MailFolder --connection-id <id>"
+}
+```
+
+Run the `discoverCommand` exactly as given. Match the sdd.md value to `lookupNames[0]` in the results. Use the resolved `lookupValue` (the id) in `input-values`.
+
+> **Reference IDs are connection-scoped.** Resolve every reference field freshly against the current `--connection-id`, immediately before writing tasks.md. Never reuse an ID resolved against a different connection — silent runtime fault. Full mechanism: [/uipath:uipath-platform — reference-resolution.md § Reference IDs Are Connection-Scoped (CRITICAL)](../../../../../uipath-platform/references/integration-service/reference-resolution.md#reference-ids-are-connection-scoped-critical).
+
+> **Paginate when looking up by name.** `execute list` returns one page (up to 1000 items); check `Data.Pagination.HasMore` + `Data.Pagination.NextPageToken`. Re-run with `--query "nextPage=<NextPageToken>"` until found or `HasMore` is `"false"`. Short-circuit on first match.
+
+If a reference cannot be resolved, **AskUserQuestion** with the candidates (dropdown when finite set, plus "Something else"). Do not guess.
+
+### 5. Validate required fields (HARD GATE)
+
+This is a hard gate — do NOT proceed to writing tasks.md until every required field has a value.
+
+1. Collect every `inputs.*[?required]` entry from the spec output (across `bodyFields`, `pathParameters`, `queryParameters`).
+2. For each, check whether sdd.md names a value (literal, variable reference, or cross-task output).
+3. If missing and no `defaultValue`, **AskUserQuestion** — list the missing fields with their `displayName` and what kind of value is expected.
+4. Free-form input is appropriate when the value space is open-ended (channel names, message bodies, IDs); when a finite set of sensible values exists (e.g. an `enum`), present them via AskUserQuestion per the dropdown rule in [SKILL.md](../../../../SKILL.md).
+5. Only after all required fields have values, proceed to step 6.
+
+> **Do NOT guess or skip missing required fields.** A missing required field will cause a runtime error. It is always better to ask than to assume.
+
+### 6. Map SDD inputs to connector fields
+
+SDD input names rarely match connector field names exactly. Match each SDD input to a `bodyFields`/`pathParameters`/`queryParameters` entry by comparing the SDD field name against the `displayName` (or `name`) from Step 3.
+
+For each required field in spec.inputs.*, there must be a matching SDD input. If a required field has no match, **AskUserQuestion** — never leave required fields unmapped.
+
+Values can be:
+- **Static literals** — `"Payment__c"`, `"Text"`, `42`
+- **Resolved reference IDs** — from Step 4
+- **Case variable references** — `=vars.X` (impl wraps as `=js:(vars.X)` for the connector body sink before passing to the CLI)
+- **Metadata references** — `=metadata.X` (impl wraps as `=js:(metadata.X)`)
+- **Pre-wrapped operator expressions** — `=js:(vars.amount > 5000)` (already canonical — pass-through)
+- **Cross-task refs** — `<- "Stage"."Task".output` (impl resolves to `=vars.<outputVar>` then wraps)
+
+> **tasks.md carries SDD-natural form.** The implementation step (Step 9.7 of connector-activity impl) rewrites every reference to its canonical sink form when constructing `--input-details`. Connector body sinks use `=js:(<expr>)`. Full rule: [bindings-and-expressions.md § Canonical form per sink](../../../../bindings-and-expressions.md#canonical-form-per-sink).
+
+### 7. Optional — author a server-side filter
+
+If `spec.filter` is present (i.e. the operation declares a `FilterBuilder` parameter and supports CEQL), the user can author a filter tree. If `spec.filter` is `undefined`, server-side filtering is not supported on this operation — filter downstream (post-execution) instead.
+
+Filter tree shape, operator table, anti-patterns, worked examples: [/uipath:uipath-platform — Filter Trees (CEQL)](../../../../../uipath-platform/references/integration-service/activities.md#filter-trees-ceql). Same shape applies to triggers (compiler differs — JMESPath instead of CEQL).
+
+The filter tree goes into `tasks.md` under `filter:` as a literal JSON object — Phase 3 passes it to `case spec --input-details`. Do NOT pass a raw CEQL string under `queryParameters.where` (or whichever connector-specific name) when authoring a filter — case-tool rejects this at configure time, and the round-trip from Studio Web breaks.
+
+### 8. Build input-values
+
+Using the mapped fields from Step 6, build the `input-values` JSON with dot-path field names from `inputs.bodyFields[].name`:
+
+```json
+{
+    "bodyParameters": {"message.toRecipients": "=vars.managerEmail", "message.subject": "=vars.caseId", "message.body.content": "=vars.description", "message.body.contentType": "Text"},
+    "queryParameters": {"limit": 50},
+    "pathParameters":  {"id": "AAMkAGI..."}
+}
+```
+
+Dotted keys (`message.body.content`) get nested into structured objects via `nestDottedKeys` at Phase 3 mint time — the planner just records the dotted form.
+
+#### Array-of-object body fields — SDD authors business shape; planner translates to wire shape
+
+When `inputs.bodyFields[].name` contains `[*]` (e.g. `toRecipients[*].emailAddress.address`, `attachments[*]`, `blocks[*].text`), the `[*]` is **schema notation** meaning "array of" — borrowed from JSONPath. The SDD describes the input at a **business level**; the planner translates to wire shape using the spec's flat field-name metadata.
+
+**Translation algorithm.** Group spec body fields by parent (the prefix before `[*]`). For each parent:
+
+| Spec — fields with `[*]` for this parent | SDD value form | Planner output (wire shape into `tasks.md input-values.bodyParameters[<parent>]`) |
+|---|---|---|
+| Exactly one sub-field `<parent>[*].<leaf>` of `dataType: <T>` | List of scalars matching `<T>` (e.g. `["a@x", "b@y"]`) | `[nestUnder(<leaf>, v) for v in sdd_value]` — each scalar becomes `{<leaf nested>: v}` |
+| One or more sub-fields | List of objects already matching the element shape (e.g. `[{"emailAddress":{"address":"a@x"}}]`) | Pass through unchanged |
+| Two or more sub-fields under the same parent | List of scalars | **Halt + AskUserQuestion** — scalars are ambiguous (which sub-field?). Ask user for object list. |
+| Any | Single scalar (not a list) | **Halt + AskUserQuestion** — confirm whether user meant single-element list |
+
+**Worked example — Outlook `Message`:**
+
+Spec exposes `toRecipients[*].emailAddress.address` (one sub-field, dataType `string`) and `bccRecipients[*].emailAddress.address` (same shape). SDD:
+
+```
+| toRecipients  | Array of string | ["a@x"]           |
+| bccRecipients | Array of string | ["b@x", "c@x"]    |
+```
+
+Planner emits to `tasks.md input-values.bodyParameters`:
+
+```json
+{
+    "toRecipients":  [{"emailAddress":{"address":"a@x"}}],
+    "bccRecipients": [{"emailAddress":{"address":"b@x"}}, {"emailAddress":{"address":"c@x"}}]
+}
+```
+
+**Never** emit a key with literal `[*]` in `bodyParameters`. The CLI accepts it (well-formed JSON) and validate passes; runtime APIs (Microsoft Graph, Slack, etc.) reject with HTTP 400 `UnableToDeserializePostBody`. Pre-input scan in [`impl-json.md` § Step 1.b](impl-json.md#step-1b--array-of-object-body-fields-pre-input-scan-mandatory) halts on any literal `[*]` key.
+
+## tasks.md Entry Format
+
+```markdown
+## T<n>: Add connector-activity task "<display-name>" to "<stage>"
+- type-id: <uiPathActivityTypeId>
+- connection-id: <connection-uuid>
+- connector-key: <connectorKey>
+- object-name: <objectName>
+- input-values: {"bodyParameters":{...},"queryParameters":{...},"pathParameters":{...}}
+- filter: {"groupOperator":"And","index":0,"uuId":null,"filters":[{"id":"Status","operator":"Equals","value":{"isLiteral":true,"rawString":"\"Active\"","value":"Active"},"uiId":null}]}
+- isRequired: true
+- runOnlyOnce: false
+- order: after T<m>
+- lane: <n>
+- verify: tasks.md `input-values` covers every `inputs.*[?required]` from the lean spec across `bodyFields`, `queryParameters`, `pathParameters` — see Step 5 above.
+```
+
+`filter:` is optional and present only when the operation supports CEQL (i.e. `spec.filter` was non-null in step 7).
+
+## Unresolved Fallback
+
+> **Rule 17 exception.** Empty `Connections` from `get-connection` (the connector activity exists in typecache but no IS connection is registered) does NOT require the Rule 17 gate — proceed directly to placeholder.
+
+If the connector or connection cannot be resolved:
+- Mark `type-id` or `connection-id` with `<UNRESOLVED: reason>`
+- Omit `input-values:` entirely — no schema to wire against
+- Execution creates a placeholder task (display-name + type only) per [placeholder-tasks.md](../../../placeholder-tasks.md)