@uipath/skills 1.195.0

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

@@ -0,0 +1,131 @@
+# connector-trigger task — Implementation (Direct JSON Write)
+
+> **Node `type` value: `wait-for-connector` (schema-kebab).** NEVER write `connector-trigger` (plugin folder name) into the JSON `type` field. The CLI `--type connector-trigger` flag is a separate concept — used only when calling the legacy `uip maestro case tasks describe` command. The current path uses `uip maestro case spec --type trigger`. 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 --type trigger --input-details` once, reads the populated `caseShape`, substitutes placeholders, and mints the task. See [`../../../phased-execution.md`](../../../phased-execution.md).
+
+Fetch the populated trigger task scaffold via `uip maestro case spec --type trigger --input-details`, then drop it into `caseplan.json` as a `wait-for-connector` task. 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.
+
+For shared CLI invocation, placeholder substitution, anti-patterns, and the canonical form for filter expressions with variable references, see [connector-trigger-common.md](../../../connector-trigger-common.md). For the per-sink canonical-form table covering all expression-syntax decisions in this skill, see [bindings-and-expressions.md § Canonical form per sink](../../../bindings-and-expressions.md#canonical-form-per-sink). This doc covers only the **task-specific** parts.
+
+## Prerequisites from Planning
+
+The `tasks.md` entry provides:
+
+| Field | Example |
+|---|---|
+| `type-id` | `"7dc57f24-894c-5ae2-a902-66056fa40609"` |
+| `connection-id` | `"fc82e610-c454-4bc7-a1a5-b5aa529d1ba6"` |
+| `connector-key` | `"uipath-microsoft-outlook365"` |
+| `object-name` | `"Message"` |
+| `event-operation` | `"EMAIL_RECEIVED"` |
+| `event-mode` | `"polling"` or `"webhooks"` |
+| `input-values` | `{"eventParameters":{"parentFolderId":"AAMkADNm..."}}` (already resolved IDs) |
+| `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 literally from `tasks.md`:
+
+```jsonc
+{
+    // eventParameters from tasks.md input-values.eventParameters (or omit when absent)
+    "eventParameters": "<input-values.eventParameters or omit>",
+    // filter — FilterTree object from tasks.md (or omit when not authored)
+    "filter": "<filter from tasks.md or omit>"
+}
+```
+
+Full input-details contract: [`case-spec-input-details.md`](../../../case-spec-input-details.md).
+
+### Step 2 — Run `case spec` with input-details
+
+Single CLI call replaces the legacy `get-connection` + `case tasks describe --type connector-trigger` two-call pattern. See [common § Phase 3 Implementation Step 2](../../../connector-trigger-common.md#step-2--run-case-spec-with-input-details) for the command and response handling.
+
+### Step 3 — Required-event-param validation (HARD GATE)
+
+This is a hard gate — do NOT proceed to write the task until every required event parameter has a non-empty value in the populated `caseShape.inputs[name="eventParameters"].body`.
+
+1. From the lean planning-phase spec (run with `--skip-case-shape` per [common § Planning Pipeline 5](../../../connector-trigger-common.md#5-validate-required-event-parameters-hard-gate)), collect `inputs.eventParameters[?required]`.
+2. After Step 2's call (with the populated caseShape), scan `caseShape.inputs[name="eventParameters"].body` and verify every required event parameter has a value.
+3. If any required event parameter is missing, **AskUserQuestion** — list the missing parameters with their `name` and what kind of value is expected.
+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 event parameters.** Trigger registration fails at runtime when a required event parameter is missing.
+
+### Step 4 — Mint binding IDs and trigger registration key
+
+Per [common § Step 3](../../../connector-trigger-common.md#step-3--mint-binding-ids-and-when-applicable-trigger-registration-key). Note for in-stage triggers: `<eventTriggerKey>` uses `<connection-id>_<startNode.id>` — `startNode.id` is the case-level start node, NOT the stage id (matches FE convention).
+
+### Step 5 — Substitute placeholders in `caseShape.context`
+
+Per [common § Step 4](../../../connector-trigger-common.md#step-4--substitute-placeholders-in-caseshapecontext). Three placeholders: `{{CONN_BINDING_ID}}`, `{{FOLDER_BINDING_ID}}` (when present), `{{TRIGGER_REGISTRATION_KEY}}` (when the trigger has event parameters).
+
+### Step 6 — 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
+- `id` = same as `var`
+- `elementId` = the task's elementId
+
+For each entry in `caseShape.outputs[]`: same fields, **plus the dedup rule** per [common § Step 5](../../../connector-trigger-common.md#step-5--mint-var--id--elementid-on-inputs-and-outputs) (`response` / `error` collide across multiple connector tasks/triggers).
+
+**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 — Build task and write to caseplan.json
+
+```json
+{
+  "id": "<taskId>",
+  "type": "wait-for-connector",
+  "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.WaitForEvent",
+    "context": "<caseShape.context — placeholders substituted in Step 5>",
+    "inputs":  "<caseShape.inputs  — var/id/elementId minted in Step 6>",
+    "outputs": "<caseShape.outputs — var/id/elementId minted, dedup applied in Step 6>",
+    "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 8 — Append root-level bindings
+
+Per [common § Root-level bindings](../../../connector-trigger-common.md#root-level-bindings). Two entries (ConnectionId, FolderKey), `resourceKey` = `connection-id`. Deduplicate against existing root bindings.
+
+### Step 9 — 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.
+
+## Graceful degradation
+
+**Always create the task** — even on errors. Start with `data: { "serviceType": "Intsvc.WaitForEvent" }` 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-event-param gate fails (user declines) | Placeholder per Rule 8 OR re-prompt | `[SKIPPED] required event parameter <name> missing — placeholder task per Rule 8` |
+| All succeed | Full population per Steps 4-9 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 `"wait-for-connector"` and `data.serviceType` is `"Intsvc.WaitForEvent"`
+2. `data.context[]` populated from `caseShape.context` with placeholders substituted (`=bindings.<connBindingId>`, etc.)
+3. `data.context[name="metadata"].body.activityPropertyConfiguration.configuration` is a `=jsonString:…` string (CLI-produced; do not modify)
+4. When the trigger has event parameters: `data.context[name="metadata"].body.bindings[Property].metadata.ParentResourceKey` is `EventTrigger.<eventTriggerKey>` (substituted from `EventTrigger.{{TRIGGER_REGISTRATION_KEY}}`)
+5. Root bindings exist for ConnectionId + folderKey with the minted ids; `data.bindings[]` is empty `[]`
+6. Each entry in `data.inputs[]` / `data.outputs[]` has `var` / `id` / `elementId` minted; uniqueness rule applied for outputs
+7. `bindings_v2.json` `resources` array matches the schema-appropriate bindings array (v19: `root.data.uipath.bindings[]`; v20: top-level `bindings[]`) after the deferred sync

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

@@ -0,0 +1,51 @@
+# connector-trigger task — Planning
+
+A connector-based trigger **inside a stage** — waits for an external event before continuing.
+
+The planning pipeline is shared with the [event trigger](../../triggers/event/planning.md) — see [connector-trigger-common.md](../../../connector-trigger-common.md) for the full resolution pipeline (TypeCache lookup → connection pick → `case spec` discovery → reference resolution → required-field gate → SDD mapping → input-values + filter authoring).
+
+## When to Use
+
+Pick this plugin when the sdd.md describes a task that **suspends the stage until an external event fires**:
+
+- "Wait until a new row appears in Salesforce"
+- "Continue when a Slack reaction is added"
+- "Suspend until an email arrives in Inbox"
+
+Distinguish from:
+
+- **Case-level event triggers** (start the case from outside) → [`plugins/triggers/event/`](../../triggers/event/planning.md)
+- **Connector activity** (call out, don't wait) → [connector-activity](../connector-activity/planning.md)
+- **Timer wait** (not connector-driven) → [wait-for-timer](../wait-for-timer/planning.md)
+
+## Resolution Pipeline
+
+Follow the pipeline in [connector-trigger-common.md § Planning Pipeline](../../../connector-trigger-common.md#planning-pipeline). All steps are identical for both in-stage triggers and case-level event triggers.
+
+## tasks.md Entry Format
+
+```markdown
+## T<n>: Add connector-trigger task "<display-name>" to "<stage>"
+- type-id: <uiPathActivityTypeId>
+- connection-id: <connection-uuid>
+- connector-key: <connectorKey>
+- object-name: <objectName>
+- event-operation: <eventOperation>
+- event-mode: <polling|webhooks>
+- input-values: {"eventParameters": {"parentFolderId": "AAMkADNm..."}}
+- filter: {"groupOperator":"And","index":0,"uuId":null,"filters":[{"id":"subject","operator":"Contains","value":{"isLiteral":true,"rawString":"\"urgent\"","value":"urgent"},"uiId":null}]}
+- isRequired: true
+- runOnlyOnce: false
+- order: after T<m>
+- lane: <n>
+- verify: Confirm task created with correct event parameters
+```
+
+## Unresolved Fallback
+
+> **Rule 17 exception.** Empty `Connections` from `get-connection` (the connector trigger 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:` and `filter:`
+- Execution creates a placeholder task (display-name + type only) per [placeholder-tasks.md](../../../placeholder-tasks.md)

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

@@ -0,0 +1,64 @@
+# process 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": "t8GQTYo8O",
+  "type": "process",
+  "displayName": "Run KYC",
+  "elementId": "Stage_aB3kL9-t8GQTYo8O",
+  "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 process --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`: `"ProcessOrchestration"`
+- `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. Set `data.name` = `=bindings.<nameBindingId>`, `data.folderPath` = `=bindings.<folderPathBindingId>`
+3. 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).
+4. 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: "process"`
+- `data.name` and `data.folderPath` start with `=bindings.`
+- the bindings array has 2 entries: `resource: "process"`, `resourceSubType: "ProcessOrchestration"`, `propertyAttribute` = `name` / `folderPath`
+- `data.inputs` and `data.outputs` populated (unless placeholder)
+- `id` captured in `id-map.json`

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

@@ -0,0 +1,60 @@
+# process task — Planning
+
+An RPA-driven automated process task. Invokes a UiPath process (or agentic process) by name and folder.
+
+## When to Use
+
+Pick this plugin when the sdd.md describes a task as any of:
+
+- `PROCESS` — a regular UiPath process
+- `AGENTIC_PROCESS` — an agentic process orchestrated by UiPath
+- Generic "run automation X" where X is a published process
+
+For RPA robot tasks specifically, prefer [rpa](../rpa/planning.md). For Coded workflows / API-workflows, use [api-workflow](../api-workflow/planning.md).
+
+## Required Fields from sdd.md
+
+| Field | Source | Notes |
+|-------|--------|-------|
+| `display-name` | Process Reference "Name" | Shown in the UI |
+| `name` | Process Reference "Name" |  |
+| `folder-path` | Process Reference "Folder" | Required for disambiguation. |
+| `task-type-id` | Registry resolution (see below) | Enables auto-enrichment via `tasks describe`. |
+| `inputs` | sdd.md task data mapping | See [bindings-and-expressions.md](../../../bindings-and-expressions.md) |
+| `outputs` | Discovered via `tasks describe` | Listed for downstream cross-task references |
+| `runOnlyOnce` | sdd.md (default `true`) |  |
+| `isRequired` | sdd.md (default `true`) |  |
+
+## Registry Resolution
+
+1. **Primary cache file:** `process-index.json` for `PROCESS`, `processOrchestration-index.json` for `AGENTIC_PROCESS`.
+2. **Identifier field:** `entityKey`.
+3. **Cross-type fallback.** If the primary cache file has no match, search both files — the sdd.md label is not authoritative. A process registered as `process` may be mislabeled `AGENTIC_PROCESS` in sdd.md and vice versa.
+4. **Match priority:** exact name + exact folder > exact name, multiple folders (pick matching) > exact name only > no match.
+5. **Discover inputs/outputs:** after resolving the `entityKey`, fetch the input/output schema via `tasks describe` — see [bindings-and-expressions.md § Discovering output names](../../../bindings-and-expressions.md). Record input names, types, and output names. Unrecognized inputs in sdd.md → ask the user (**AskUserQuestion** with matching field names + "Something else").
+
+## Unresolved Fallback
+
+If no match is found across both cache files after `registry pull`:
+
+- Mark the task line: `<UNRESOLVED: process "<name>" in folder "<folder>" not found in registry>`
+- Omit `inputs:` and `outputs:`; capture intended wiring in a fenced ```` ```text ```` code block (not `#` prefixed — it renders as markdown H1).
+- Continue planning for remaining tasks.
+- Execution creates a placeholder task (no `data.context.taskTypeId`, no bindings). See [placeholder-tasks.md](../../../placeholder-tasks.md).
+
+## tasks.md Entry Format
+
+```markdown
+## T<n>: Add process task "<display-name>" to "<stage>"
+- taskTypeId: <entityKey>
+- folder-path: "<folder>"
+- inputs:
+  - <input_name> = "<literal-or-expression>"
+  - <input_name> <- "<Stage>"."<Task>".<output>
+- outputs: <out1>, <out2>, <out3>
+- 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/rpa/impl-json.md

@@ -0,0 +1,65 @@
+# rpa 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": "tQ2pVx7Lm",
+  "type": "rpa",
+  "displayName": "Extract Invoice Data",
+  "elementId": "Stage_aB3kL9-tQ2pVx7Lm",
+  "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.
+- **Do not flip to `type: "process"`** based on registry. The `rpa` vs `process` distinction comes from sdd.md intent.
+
+## Procedure
+
+**Step 0 — Get inputs/outputs schema:**
+
+```bash
+uip maestro case tasks describe --type rpa --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`: omit (no resourceSubType for rpa tasks)
+- `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. Set `data.name` = `=bindings.<nameBindingId>`, `data.folderPath` = `=bindings.<folderPathBindingId>`
+3. 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).
+4. 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: "rpa"` (NOT `"process"`)
+- `data.name` and `data.folderPath` start with `=bindings.`
+- the bindings array has 2 entries: `resource: "process"`, no `resourceSubType`, `propertyAttribute` = `name` / `folderPath`
+- `data.inputs` and `data.outputs` populated (unless placeholder)
+- `id` captured in `id-map.json`

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

@@ -0,0 +1,49 @@
+# rpa task — Planning
+
+An RPA robot task. The sdd.md component type is `RPA`. The task node's `type` field is `"rpa"`, but the cached registry entity typically lives in `process-index.json` — the registry does not separate "process" from "rpa" at storage time.
+
+## When to Use
+
+Pick this plugin when the sdd.md explicitly labels a task as `RPA` (e.g., "RPA robot does X"). The distinction from `process` is **semantic** (sdd.md intent) rather than structural (registry representation).
+
+If sdd.md is ambiguous between `PROCESS` and `RPA`, default to `process` unless the sdd.md mentions UI automation, desktop apps, or robot-specific concerns.
+
+## Required Fields from sdd.md
+
+Same shape as [process/planning.md](../process/planning.md):
+
+| Field | Notes |
+|-------|-------|
+| `display-name` | from Process Reference |
+| `name` | from Process Reference |
+| `folder-path` | from Process Reference |
+| `task-type-id` | from registry (`entityKey` in `process-index.json`) |
+| `inputs`, `outputs`, `runOnlyOnce`, `isRequired` | see [bindings-and-expressions.md](../../../bindings-and-expressions.md) |
+
+## Registry Resolution
+
+1. **Primary cache file:** `process-index.json` (yes — RPA tasks share this cache with `process`).
+2. **Identifier field:** `entityKey`.
+3. Use the sdd.md `RPA` label to set `type: "rpa"` on the task node; use the cache `entityKey` for `data.context.taskTypeId`.
+4. If no match in `process-index.json`, search all other cache files as a fallback.
+5. Discover inputs/outputs via `tasks describe` — see [bindings-and-expressions.md § Discovering output names](../../../bindings-and-expressions.md).
+
+## Unresolved Fallback
+
+Mark `<UNRESOLVED: rpa "<name>" in folder "<folder>" not found in registry>`. 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).
+
+## tasks.md Entry Format
+
+```markdown
+## T<n>: Add rpa task "<display-name>" to "<stage>"
+- taskTypeId: <entityKey>
+- folder-path: "<folder>"
+- inputs:
+  - <input_name> = "<value>"
+- outputs: <out1>
+- 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/wait-for-timer/impl-json.md

@@ -0,0 +1,97 @@
+# wait-for-timer task — Implementation (Direct JSON Write)
+
+> **Phase split.** Written in Phase 2 only. The timer task has no variable inputs to bind — `timerType` + duration come from `tasks.md` planning. Phase 3 does not revisit this plugin. See [`../../../phased-execution.md`](../../../phased-execution.md).
+
+Write the timer task directly to `caseplan.json`. No CLI command needed.
+
+## Task JSON Shape
+
+> **ID and elementId format.** Task `id` is `t` + 8 random chars. `elementId` is the composite `${stageId}-${taskId}`.
+
+```json
+{
+  "id": "tWm4Vx9Tp",
+  "type": "wait-for-timer",
+  "displayName": "Approval Escalation Timer",
+  "elementId": "Stage_aB3kL9-tWm4Vx9Tp",
+  "isRequired": false,
+  "shouldRunOnlyOnce": true,
+  "data": {
+    "timerType": "timeDuration",
+    "timeDuration": "PT3M"
+  }
+}
+```
+
+## Procedure
+
+**Step 1 — Create task with empty data:**
+
+1. Generate task ID: `t` + 8 alphanumeric chars (unique across all tasks)
+2. Generate elementId: `<stageId>-<taskId>`
+3. Write the task with `"data": {}` to the target stage's `tasks[]` array (in its own task set)
+
+```json
+{
+  "id": "tWm4Vx9Tp",
+  "type": "wait-for-timer",
+  "displayName": "Approval Escalation Timer",
+  "elementId": "Stage_aB3kL9-tWm4Vx9Tp",
+  "isRequired": false,
+  "shouldRunOnlyOnce": true,
+  "data": {}
+}
+```
+
+**Step 2 — Populate timer details:**
+
+4. Read the timer type from tasks.md (`every`, `at`, or `time-cycle`)
+5. Set `data.timerType` and the corresponding duration field (see below)
+
+**Step 3 (separate):** Entry conditions are added in Step 10
+
+## Timer Types
+
+### timeDuration — fixed delay
+
+```json
+"data": { "timerType": "timeDuration", "timeDuration": "PT3M" }
+```
+
+ISO 8601 duration format (e.g., `PT3M`, `PT1H30M`, `P2D`). Time units use `PT` prefix, date units use `P` (no `T`). Weeks → `P7D` (Luxon doesn't output `W`).
+
+**Bounded repetition** — when tasks.md specifies `repeat: N`, add `data.repeat` as a string alongside `timeDuration`. Omit `data.repeat` entirely for a single fire.
+
+```json
+"data": { "timerType": "timeDuration", "timeDuration": "PT1H", "repeat": "5" }
+```
+
+Pairs with `timeDuration` only. For bounded repetition with a start datetime, use `timeCycle` instead.
+
+### timeDate — specific datetime
+
+```json
+"data": { "timerType": "timeDate", "timeDate": "2026-04-26T09:00:00.000+00:00" }
+```
+
+ISO 8601 datetime with timezone offset. Always include milliseconds and offset.
+
+### timeCycle — repeating interval
+
+```json
+"data": { "timerType": "timeCycle", "timeCycle": "R5/2026-03-03T12:00:00.000+00:00/PT1H" }
+```
+
+Composite format: `R{repeatCount}/{startDatetime}/{duration}`
+
+| Example | Meaning |
+|---|---|
+| `R/PT15S` | Every 15 seconds, infinite |
+| `R5/PT1H` | Every hour, 5 times |
+| `R/2026-03-03T12:00:00.000+00:00/P1D` | Daily starting March 3, infinite |
+
+Omit repeatCount segment for infinite (`R/...`). Omit datetime segment if no start time (`R/PT1H`).
+
+## Post-Write Verification
+
+Confirm task exists in the correct stage with `type: "wait-for-timer"` and `data.timerType` + duration field set.

package/skills/uipath-maestro-case/references/plugins/tasks/wait-for-timer/planning.md

@@ -0,0 +1,70 @@
+# wait-for-timer task — Planning
+
+A timer task inside a stage. Suspends the stage for a duration, until a specific time, or on a repeating cycle.
+
+## When to Use
+
+Pick this plugin when the sdd.md describes a task that **pauses or delays execution** within a stage. Typical patterns:
+
+- "Wait 24 hours before reminding"
+- "Delay until next business day at 9 AM"
+- "Poll every hour for up to 5 iterations"
+
+Distinguish from:
+
+- **Case-level timer triggers** (start the case on a schedule) → [`plugins/triggers/timer/`](../../triggers/timer/planning.md)
+- **Connector event wait** → [connector-trigger](../connector-trigger/planning.md)
+
+## Required Fields from sdd.md
+
+| Field | Source | Notes |
+|-------|--------|-------|
+| `display-name` | sdd.md task name | |
+| Either `timeDuration` (`--every`) OR `timeCycle` OR `timeDate` (`--at`) | sdd.md timer semantics | At least one required |
+| `repeat` | sdd.md (optional) | Number of repetitions — omit for infinite |
+| `isRequired` | sdd.md (default `true`) | |
+
+## Registry Resolution
+
+**No cache lookup required.** Timer is a built-in task type with no registry representation — no `taskTypeId`, no `enrich`, no `describe`.
+
+## Duration Formats
+
+Accepted `--every` values:
+
+| Format | Example | Meaning |
+|--------|---------|---------|
+| Seconds | `10s` | 10 seconds |
+| Minutes | `5m` | 5 minutes |
+| Hours | `1h` | 1 hour |
+| Days | `2d` | 2 days |
+| Weeks | `1w` | 1 week |
+| Months | `3mo` | 3 months |
+| ISO 8601 | `PT10S` | 10 seconds (raw ISO) |
+
+Accepted `--at` values: ISO 8601 datetime (e.g., `2026-04-26T10:00:00.000Z`).
+
+Accepted `--time-cycle` values: raw ISO 8601 repeating interval (e.g., `R/PT1H` = repeat every hour, infinite). Overrides `--every`, `--at`, `--repeat` if set.
+
+## Translation Guidance
+
+- "Wait X hours" → `--every Xh`, no `--at`, no `--repeat`.
+- "Every day at 9 AM" → `--every 1d --at <ISO datetime with 09:00>`.
+- "Every hour, up to N times" → `--every 1h --repeat N`.
+- "Run repeatedly forever every N" → `--time-cycle R/PT<N>`.
+
+Ambiguous phrasing → **AskUserQuestion** with 2–3 candidate interpretations + "Something else".
+
+## tasks.md Entry Format
+
+```markdown
+## T<n>: Add wait-for-timer task "<display-name>" to "<stage>"
+- every: 1h
+- at: 2026-04-26T09:00:00.000Z   # optional
+- repeat: 5                       # optional
+- time-cycle: R/PT1H              # optional (overrides above)
+- 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
+```