@uipath/skills 1.195.0

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

@@ -0,0 +1,176 @@
+# event trigger — Implementation (Direct JSON Write)
+
+Configure the case-level event trigger by writing directly into the trigger node in `caseplan.json`. Field discovery and reference resolution are done during [planning](planning.md). Phase 3 calls `uip maestro case spec --type trigger --input-details` once and consumes the populated `caseShape`.
+
+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 **trigger-node-specific** parts.
+
+> **v20 layout-strip (Rule 19).** Read `Schema:` header from `tasks.md`. In **v20 mode**, omit ALL of: `position`, `style`, `measured`, `width`, `height`, `zIndex` from the trigger node. Skip the position-computation step entirely. Keep `data.parentElement`, `data.isInvalidDropTarget`, `data.isPendingParent`, `data.label`, `data.description`, `data.uipath`. Recipe shape below shows v19 fields; v20 strips listed render fields and skips position math. Placeholder-fallback logic and `entry-points.json` shape are identical across schemas.
+
+## Prerequisites from Planning
+
+The `tasks.md` entry provides: `type-id`, `connection-id`, `connector-key`, `object-name`, `event-operation`, `event-mode`, `input-values`, `filter`.
+
+## Step 1 — Build `--input-details` JSON from tasks.md
+
+Construct the input-details object literally from `tasks.md`:
+
+```jsonc
+{
+    "eventParameters": "<input-values.eventParameters or omit>",
+    "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 trigger node 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 per the Placeholder fallback section below if user declines.
+
+> **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). For event triggers, `<eventTriggerKey>` uses `<connection-id>_<startNode.id>` where `startNode.id` is the trigger node's own id (since the event trigger IS the start node for its case-entry path) — matches FE convention at `PackagingUtil.ts:227`.
+
+## Step 5 — Substitute placeholders in `caseShape.context`
+
+Per [common § Step 4](../../../connector-trigger-common.md#step-4--substitute-placeholders-in-caseshapecontext).
+
+## Step 6 — Mint `var` / `id` on trigger CONFIG inputs
+
+For each entry in `caseShape.inputs[]` (these are trigger configuration: `eventParameters`, `filter`, etc.):
+- `var` = `v` + 8 alphanumeric chars
+- `id` = same as `var`
+- **No `elementId`** on trigger inputs (different from in-stage task inputs).
+
+> **`caseShape.outputs[]` are NOT minted here.** Under B's redesign, all writes to `triggerNode.data.uipath.outputs[]` are owned by the variables plugin (see [`../../variables/global-vars/impl-json.md` § Dispatcher Loop](../../variables/global-vars/impl-json.md)). This plugin captures the un-minted `caseShape.outputs[]` into `tasks/trigger-spec-cache.json` (Step 8) for the variables plugin to consume.
+
+## Step 7 — Build trigger node and write to caseplan.json
+
+### 7a. Identify or create the trigger node
+
+For a **single-trigger case**, configure the existing `trigger_1` node. For **multi-trigger cases**, create a new node:
+- ID: `trigger_` + 6 alphanumeric chars
+- Position: `{ x: -100, y: 620 }` (auto-stack below existing triggers; v19 only)
+
+Set the trigger's display name from `tasks.md`. Record `T<N> → trigger_xxxxxx` in `id-map.json` so the variables plugin can resolve T-number references.
+
+### 7b. `data` structure
+
+```json
+{
+  "label": "<display-name>",
+  "uipath": {
+    "serviceType": "Intsvc.EventTrigger",
+    "context": "<caseShape.context — placeholders substituted in Step 5>",
+    "inputs":  "<caseShape.inputs  — var/id minted in Step 6; NO elementId>",
+    "outputs": [],
+    "bindings": []
+  }
+}
+```
+
+> `outputs: []` is initialized empty. The variables plugin populates it in Phase 3 Step 6.2 using the sidecar from Step 8 below.
+
+## Step 8 — Write trigger-spec-cache.json sidecar
+
+Write the un-minted `caseShape` into the shared sidecar artifact for the variables plugin to consume. Path: `tasks/trigger-spec-cache.json` (relative to project directory). Keyed by T-number.
+
+```jsonc
+// tasks/trigger-spec-cache.json
+{
+  "T02": {
+    "context": "<caseShape.context — post-substitution from Step 5>",
+    "inputs":  "<caseShape.inputs — un-minted, with body schema intact>",
+    "outputs": "<caseShape.outputs — un-minted, with body schema intact>"
+  },
+  "T03": { ... }
+}
+```
+
+**Important — un-minted shape:**
+
+- Do NOT mint `var` / `id` / `elementId` on the `outputs[]` entries written to the sidecar — the variables plugin mints them at Step 6.2 according to whether the SDD references each output. The plain field name from the schema is preserved (e.g., `name: "subject"`).
+- Do NOT strip `body` from the outputs — the variables plugin needs the full JSON Schema when emitting the root companion (especially for `jsonSchema`-typed outputs).
+
+**Sidecar lifecycle:**
+
+- **Persistence.** The sidecar persists across hard stops (Phase 2 approval gate, Phase 2 publish-for-preview, etc.) so Phase 3 re-entry doesn't lose spec data. Do NOT regenerate on re-entry — read the existing file.
+- **Regeneration.** Rule 6 (`Continue with regenerate from scratch`) replaces the sidecar entirely (Write, not append), starting from an empty `{}`. Rule 7 (`Continue without regenerate`) preserves the existing sidecar.
+- **Multi-trigger append.** Trigger plugin runs once per trigger T-entry. Each invocation **merges by T-number** into the existing sidecar JSON: read the file, set or replace the top-level `<T-number>` key, write back. Append order is **T-number ascending** (T02 then T03 then ...). Re-running a single trigger T-entry overwrites only its own key; other triggers' keys are untouched. This makes the sidecar **idempotent** for multi-trigger cases.
+- **Abort cleanup.** On `Abort` (per [`phased-execution.md`](../../../phased-execution.md) abort semantics), the sidecar persists alongside other artifacts — `phased-execution.md` mandates no artifact deletion on abort; user owns partial state. On the next run with regenerate-from-scratch (Rule 6) the sidecar is overwritten; otherwise it is reused.
+- **Edit discipline.** Per Rule 13, edit via Read + Write/Edit only. Do NOT use jq, sed, or any other tool that bypasses the file-state tracker.
+
+The variables plugin consumes this in Phase 3 Step 6.2 — see [`../../variables/global-vars/impl-json.md` § Inputs the plugin reads](../../variables/global-vars/impl-json.md) and § Dispatcher Loop.
+
+## Step 9 — 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 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.
+
+## Placeholder fallback (unresolved connector / connection)
+
+When the T-entry carries `<UNRESOLVED>` on `type-id`, `connection-id`, or `connector-key`, skip Steps 2-10 and write a placeholder node instead. Mirrors the connector-task placeholder pattern in [placeholder-tasks.md](../../../placeholder-tasks.md) — structure preserved, runtime config deferred.
+
+```json
+{
+  "id": "<trigger_xxxxxx>",
+  "type": "case-management:Trigger",
+  "position": { "x": -100, "y": <stateful per §7a> },
+  "style": { "width": 96, "height": 96 },
+  "measured": { "width": 96, "height": 96 },
+  "data": {
+    "parentElement": { "id": "root", "type": "case-management:root" },
+    "label": "<display-name>",
+    "description": "<description from sdd.md>",
+    "uipath": { "serviceType": "Intsvc.EventTrigger" }
+  }
+}
+```
+
+`data.uipath` carries **only** `serviceType` — no `context[]`, `inputs[]`, `outputs[]`, `bindings[]`, `metadata`. Equivalent intent to a connector-task `data: {}` placeholder; trigger nodes need `label` / `description` / `parentElement` to render at all.
+
+**Sibling artifacts:** append the matching `entry-points.json` entry per [manual/impl-json.md § Recipe — entry-points.json](../manual/impl-json.md#recipe--entry-pointsjson). Create the trigger-edge to the first stage normally — both endpoints exist, guardrails pass. No root bindings, no `inputOutputs[]` entries from this trigger.
+
+**Log:** `[SKIPPED] Event trigger "<display-name>" written as placeholder — connector "<connector-key>" / connection unresolved.`
+
+**Upgrade:** regenerate from scratch (Rule 5) — no in-place mutation path. Trigger config is sibling-file-coupled (`entry-points.json`, root variable bindings); a partial in-place edit leaves siblings stale.
+
+## Graceful degradation — unified placeholder conditions
+
+Three distinct conditions can trigger placeholder fallback for an event trigger. All three downgrade to the same placeholder shape (per § Placeholder fallback above); only the surfacing message and the AskUserQuestion offered differ.
+
+| Trigger | What's happening | Placeholder action | Log |
+|---|---|---|---|
+| **Planning-time unresolved** (tasks.md T-entry carries `<UNRESOLVED>` on `type-id` / `connection-id` / `connector-key`) | Registry lookup didn't find the connector or connection at planning time | Skip Steps 2–10 entirely; write the placeholder node directly per § Placeholder fallback | `[SKIPPED] Event trigger "<display-name>" written as placeholder — connector "<connector-key>" / connection unresolved.` |
+| **`case spec` failure at Phase 3** (T-entry was resolved at planning, but the CLI call fails at implementation — connection deleted between phases, transient API error) | Spec call itself errored | Catch the exception; fall through to placeholder fallback shape | `[SKIPPED] case spec failed — event trigger downgraded to placeholder` |
+| **Required-event-param gate failure at Phase 3** (spec call succeeded, but `caseShape.inputs[name="eventParameters"].body` is missing required fields after AskUserQuestion either declined or didn't fully resolve) | Required event parameter never collected | If user picked decline or re-prompt failed, fall through to placeholder | `[SKIPPED] required event parameter <name> missing — event trigger downgraded to placeholder` |
+
+**Why full placeholder (not `typeId`/`connectionId` preservation)?** Event triggers are sibling-file-coupled (`entry-points.json` entry, root variable bindings for In args). A partial in-place edit leaves siblings stale. Phase-3 `case spec` failure on event triggers therefore downgrades fully to placeholder — asymmetric with connector-task graceful-degradation, which preserves `data.typeId + data.connectionId` because the in-stage parent node can render without sibling-file coupling (see [`../../tasks/connector-activity/impl-json.md`](../../tasks/connector-activity/impl-json.md) for the connector-task fallback table — it preserves more state because the coupling profile is different).
+
+All issues appended per [logging/impl-json.md](../../logging/impl-json.md).
+
+## Post-Write Verification
+
+1. `data.uipath.serviceType` is `"Intsvc.EventTrigger"` (not `WaitForEvent` or `CuratedTrigger`).
+2. **Fully configured:** `context[]`, `inputs[]` (CONFIG inputs only — no `elementId`), `outputs[]` (empty array — populated later by variables plugin Step 6.2), and `bindings[] = []` all present per §7b.
+3. **`tasks/trigger-spec-cache.json` exists** with this trigger's T-number as a top-level key, containing un-minted `context`, `inputs`, `outputs` from `caseShape`.
+4. **`id-map.json`** contains `"T<N>": { "kind": "trigger", "id": "<triggerId>" }` for this trigger.
+5. **Placeholder:** all four `data.uipath` fields beyond `serviceType` **absent** (not empty arrays); no root bindings entries from this trigger; no `trigger-spec-cache.json` entry from this trigger; `[SKIPPED]` log entry present.
+6. `data.context[name="metadata"].body.activityPropertyConfiguration.configuration` is a `=jsonString:…` string (CLI-produced; do not modify).
+7. When the trigger has event parameters: `data.context[name="metadata"].body.bindings[Property].metadata.ParentResourceKey` is `EventTrigger.<eventTriggerKey>` (substituted from `EventTrigger.{{TRIGGER_REGISTRATION_KEY}}`).
+8. Trigger node wired as `--source` in an edge to the first stage.
+9. `entry-points.json` has a matching entry referencing the trigger node ID.

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

@@ -0,0 +1,55 @@
+# event trigger — Planning
+
+A case-level trigger that fires on an external connector event. Starts the case when the event matches a filter.
+
+The planning pipeline is shared with the [connector-trigger task](../../tasks/connector-trigger/planning.md) — see [connector-trigger-common.md](../../../connector-trigger-common.md) for the full 7-step resolution pipeline.
+
+## When to Use
+
+Pick this plugin when the sdd.md describes the case as starting in response to an external event:
+
+- "When a new email arrives in Inbox"
+- "On each new Jira issue with priority High"
+- "When a file is uploaded to SharePoint"
+
+Distinguish from:
+
+- **User-initiated start** → [manual](../manual/planning.md)
+- **Scheduled start** → [timer](../timer/planning.md)
+- **In-stage event wait** → [connector-trigger task](../../tasks/connector-trigger/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 event triggers and in-stage connector-trigger tasks.
+
+## tasks.md Entry Format
+
+T-number is T02 for the first trigger row in sdd.md, T03+ for subsequent rows in multi-trigger cases — see [planning.md §4.3](../../../planning.md).
+
+```markdown
+## T02: Configure event trigger "<display-name>"
+- 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}]}
+- order: after T01
+- verify: Confirm trigger configured with correct event parameters
+```
+
+## Unresolved Fallback
+
+> **Rule 17 exception.** Empty `Connections` from `get-connection` (the trigger activity exists in typecache but no IS connection is registered) does NOT require the Rule 17 gate — proceed directly to placeholder.
+
+> **Planning emits the T-entry; execution emits a placeholder trigger node.** "Cannot resolve the connector / connection yet" is not a reason to drop the trigger from `tasks.md` or from `caseplan.json` — the no-omission rule (planning.md §4.0) applies to triggers the same as it does to stages, edges, tasks, and conditions. The pattern mirrors the connector-trigger task placeholder in [placeholder-tasks.md](../../../placeholder-tasks.md): structure preserved, runtime config deferred.
+
+If the connector or connection cannot be resolved:
+- Mark **every connector-derived field** with `<UNRESOLVED: reason>` in the T-entry — `type-id`, `connection-id`, `connector-key`, `object-name`, `event-operation`, and `event-mode` all derive from the connector / connection lookup, so when the connector itself is unresolved, none of them have authoritative values. Mark each one explicitly rather than omitting them (so the user sees the full attach checklist when upgrading).
+- Omit `input-values:` and `filter:` from the T-entry — there is no schema to wire against.
+- **Execution creates a placeholder trigger node** with `serviceType: "Intsvc.EventTrigger"` as the only `data.uipath` field (no `context[]`, `metadata`, `inputs`, `outputs`, or `bindings`). The node carries `id`, `label`, `description`, `parentElement`, and standard render fields so the FE renders it as an event trigger awaiting attachment. See [`impl-json.md` § Placeholder fallback](impl-json.md#placeholder-fallback-unresolved-connector--connection).
+- The matching `entry-points.json` entry **is still appended** — entry-points are structural BPMN references and do not depend on connector resolution.
+- Trigger-edges from this trigger to its first stage **are still created** — both endpoints exist (placeholder trigger + stage), so the edges plugin's both-endpoints-exist guardrail passes.
+- Document the missing trigger and its `<UNRESOLVED>` fields in the completion report so the user knows what to attach after registering the IS connection.

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

@@ -0,0 +1,139 @@
+---
+direct-json: supported
+---
+
+# manual trigger — JSON Implementation
+
+Cross-cutting direct-JSON rules live in [`case-editing-operations.md`](../../../case-editing-operations.md).
+
+> **v20 layout-strip (Rule 19).** Read `Schema:` header from `tasks.md`. In **v20 mode**, omit ALL of: `position`, `style`, `measured`, `width`, `height`, `zIndex` from the trigger node. Skip the position-computation step entirely. Keep `data.parentElement`, `data.isInvalidDropTarget`, `data.isPendingParent`, `data.label`, `data.description`, `data.uipath`. Recipe shapes below show v19 fields; in v20 mode strip the listed render fields and skip position math. `entry-points.json` shape is identical across schemas.
+
+## Purpose
+
+Append one secondary manual trigger to the schema. This plugin performs **two file writes as an atomic pair**:
+
+1. Append a `case-management:Trigger` node to `caseplan.json.nodes`.
+2. Append a matching entry to `entry-points.json.entryPoints` (sibling of `caseplan.json`).
+
+The sibling-file sync is the main reason this plugin needs a dedicated JSON recipe rather than reusing a generic "add node" primitive — orchestrator discovers entry points via `entry-points.json`, so a trigger node without a matching entry is invisible to runtime.
+
+## Input spec (from `tasks.md`)
+
+| Field | Required | Notes |
+|---|---|---|
+| `displayName` | yes | T-entry title or `display-name:` field. Fallback: `Trigger ${existingTriggerCount + 1}`. The first manual trigger written into a fresh caseplan therefore defaults to `"Trigger 1"`. |
+| `description` | yes | Always emitted into `data.description`. Sourced from the T-entry's `description:` field when present; otherwise the LLM infers a natural-language description from surrounding sdd.md context. |
+
+Position is not a user input. It is computed statefully (see below).
+
+## Pre-flight
+
+1. **`caseplan.json` exists** at `<SolutionDir>/<ProjectName>/caseplan.json`. Created by the `case` plugin at T01. If absent, run that plugin first — do not synthesize.
+2. **`entry-points.json` exists** in the same directory (sibling of `caseplan.json`). Written by the `case` plugin's § Scaffold at T01. If absent, hard-fail (`entry-points.json not found in <dir>. Run the case plugin first to scaffold the project.`). Do not lazily create it — a missing `entry-points.json` indicates an incomplete project scaffold, not a recoverable state.
+3. Both files must be parseable JSON. Read → validate → modify → write.
+
+## ID generation
+
+- **Trigger node ID** — `trigger_` + 6 random chars from `[A-Za-z0-9]`. Algorithm per [`case-editing-operations.md § ID Generation`](../../../case-editing-operations.md#id-generation).
+- **Entry-point `uniqueId`** — `crypto.randomUUID()`. Generate inline:
+
+  ```bash
+  node -e "console.log(crypto.randomUUID())"
+  ```
+
+Record `T<n> → trigger_xxxxxx` in `id-map.json` for downstream cross-reference (edges that target this trigger's id).
+
+## Position (stateful)
+
+**Before writing**, count every trigger node:
+
+```text
+existingTriggers = schema.nodes.filter(n => n.type === "case-management:Trigger")
+```
+
+Then compute:
+
+```text
+if existingTriggers.length === 0:
+  position = { x: -100, y: 200 }
+else:
+  position = { x: -100, y: max(existingTriggers[].position.y) + 140 }
+```
+
+The `length === 0` branch fires for the primary trigger written into a fresh caseplan (case plugin emits `nodes: []`). Subsequent triggers fall into the `else` branch, stacking at `y + 140` each time.
+
+Do not short-circuit to a hard-coded `y` value — the algorithm must handle any schema state the upstream mutations may have produced.
+
+## Default-name fallback
+
+If the T-entry does not supply `display-name`:
+
+```text
+displayName = `Trigger ${existingTriggers.length + 1}`
+```
+
+With `trigger_1` pre-seeded, the first secondary trigger without a display name becomes `"Trigger 2"`, the second `"Trigger 3"`, etc.
+
+## Recipe — `caseplan.json` (append to `schema.nodes`)
+
+Append (not prepend) the trigger node:
+
+```json
+{
+  "id": "<trigger_XXXXXX>",
+  "type": "case-management:Trigger",
+  "position": { "x": -100, "y": <computed> },
+  "style": { "width": 96, "height": 96 },
+  "measured": { "width": 96, "height": 96 },
+  "data": {
+    "parentElement": { "id": "root", "type": "case-management:root" },
+    "label": "<displayName>",
+    "description": "<description from sdd.md or LLM-inferred>"
+  }
+}
+```
+
+**No `data.uipath` key.** Absence of `uipath` is the manual trigger's signature. `serviceType` only appears on timer (`Intsvc.TimerTrigger`) and event (`Intsvc.EventTrigger`) variants.
+
+## Recipe — `entry-points.json` (append to `entryPoints`)
+
+Read the file, parse, append:
+
+```json
+{
+  "filePath": "/content/<basename(caseplanFile)>.bpmn#<trigger_XXXXXX>",
+  "uniqueId": "<crypto.randomUUID()>",
+  "type": "CaseManagement",
+  "input":  { "type": "object", "properties": {} },
+  "output": { "type": "object", "properties": {} },
+  "displayName": "<displayName>"
+}
+```
+
+Where `basename(caseplanFile)` is the schema file's base name including extension (typically `caseplan.json`), yielding a `filePath` fragment like `/content/caseplan.json.bpmn#trigger_xY2mNp`.
+
+Write back with **4-space indent** (`JSON.stringify(obj, null, 4)`).
+
+## Write order
+
+Write both files atomically in this order:
+
+1. `caseplan.json` — node appended.
+2. `entry-points.json` — entry appended.
+
+If the second write fails, the `caseplan.json` mutation must be rolled back to avoid a half-written state. Simplest rollback: re-read the `caseplan.json` that existed pre-mutation (kept in memory), write it back. Prefer fail-fast: verify `entry-points.json` exists BEFORE the first write.
+
+## Post-write validation
+
+After writing, confirm:
+
+- `caseplan.json.nodes` contains the new node with the generated `trigger_XXXXXX` id, at the end of the array.
+- `nodes[].type === "case-management:Trigger"`.
+- `nodes[].data.label` matches the resolved `displayName`.
+- `nodes[].data.description` is present and non-empty (direct-JSON-write divergence — always emitted).
+- `nodes[].data.parentElement` always present. `style`, `measured` present in v19; absent in v20 (Rule 19).
+- `nodes[].data.uipath` is **absent** (manual triggers have no `uipath` key).
+- `entry-points.json.entryPoints` contains a new entry with `filePath` ending in `#<trigger_XXXXXX>` and `displayName === <displayName>`.
+
+Run `uip maestro case validate <caseplan.json> --output json` after all triggers for this plugin's batch are added.
+

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

@@ -0,0 +1,38 @@
+# manual trigger — Planning
+
+A case-level trigger that the user starts by hand (e.g., clicking "Start" in the Case App). No schedule, no event — it just waits for a human.
+
+## When to Use
+
+Pick this plugin when the sdd.md describes the case as starting on user action:
+
+- "User initiates the case from the portal"
+- "Operator starts a new case manually"
+- "Start button in the Case App"
+
+If the sdd.md says the case runs on a schedule, use [timer](../timer/planning.md). If it starts from an external event, use [event](../event/planning.md).
+
+## Required Fields from sdd.md
+
+| Field | Source | Notes |
+|-------|--------|-------|
+| `display-name` | sdd.md (optional at the T-entry; required in output) | Defaults to auto-generated `Trigger N` where `N = existingTriggerCount + 1`. The first manual trigger written into a fresh caseplan therefore defaults to `"Trigger 1"`. |
+| `description` | sdd.md (optional at the T-entry; **required in output**) | Always emitted. If sdd.md omits it, the LLM infers a natural-language description from the surrounding context (e.g., trigger's role in the sdd flow diagram or narrative). |
+
+Position is NOT a T-entry input. It is auto-computed at execution time following the same stateful pattern as stages — see `impl-json.md` for the formula.
+
+## Registry Resolution
+
+**None.** Manual triggers have no registry representation.
+
+## tasks.md Entry Format
+
+```markdown
+## T02: Configure manual trigger "Start Manually"
+- display-name: "Start Manually"
+- description: "Operator kicks off a case from the portal"
+- order: after T01
+- verify: Confirm node appended to caseplan.json.nodes and matching entry appended to entry-points.json.entryPoints; capture TriggerId
+```
+
+Both `display-name` and `description` are carried through to execution. `description` is always emitted into `caseplan.json.nodes[].data.description` (deliberate divergence from CLI which emits conditionally — the LLM ensures the key is present on every skill run so downstream tooling can rely on it).

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

@@ -0,0 +1,127 @@
+---
+direct-json: supported
+---
+
+# timer trigger — JSON Implementation
+
+Cross-cutting direct-JSON rules live in [`case-editing-operations.md`](../../../case-editing-operations.md).
+
+> **v20 layout-strip (Rule 19).** Read `Schema:` header from `tasks.md`. In **v20 mode**, omit ALL of: `position`, `style`, `measured`, `width`, `height`, `zIndex` from the trigger node. Skip position-computation. Keep `data.parentElement` (when applicable per Case A vs B below), `data.isInvalidDropTarget`, `data.isPendingParent`, `data.label`, `data.description`, `data.uipath`. Recipe shapes below show v19 fields; v20 strips listed fields and skips position math. `entry-points.json` shape is identical across schemas.
+
+## Purpose
+
+Add a scheduled trigger to a case. Adapts shape to whether any Trigger node already exists in `schema.nodes`: emits the initial `trigger_1` minimal shape if none, or a secondary trigger with full render fields if one or more exist. Dual-file write: `caseplan.json` + `entry-points.json`.
+
+## Input spec (from `tasks.md`)
+
+| Field | Required | Notes |
+|---|---|---|
+| `timeCycle` | yes | ISO 8601 repeating interval. Consumed verbatim — no parsing, no decomposition. |
+| `displayName` | no | Defaults to `Trigger <N>` where `N = existingTriggerCount + 1`. |
+
+## Adaptive recipe
+
+Count existing Trigger nodes in `schema.nodes` **before** writing:
+
+```text
+existingTriggers = schema.nodes.filter(n => n.type === "case-management:Trigger")
+```
+
+### Case A — zero existing triggers (first-trigger path)
+
+Emit the canonical first-trigger shape with the timer `uipath` block:
+
+```json
+{
+  "id": "trigger_1",
+  "type": "case-management:Trigger",
+  "position": { "x": 0, "y": 0 },
+  "data": {
+    "label": "<displayName or \"Trigger 1\">",
+    "uipath": {
+      "serviceType": "Intsvc.TimerTrigger",
+      "timerType": "timeCycle",
+      "timeCycle": "<timeCycle from tasks.md>"
+    }
+  }
+}
+```
+
+No `style`, no `measured`, no `width`/`height`, no `data.parentElement`. Studio Web hydrates these on load.
+
+### Case B — one or more existing triggers (secondary-trigger path)
+
+Emit a secondary trigger with full render fields:
+
+```json
+{
+  "id": "trigger_<6-rand>",
+  "type": "case-management:Trigger",
+  "position": { "x": -100, "y": <computed> },
+  "style": { "width": 96, "height": 96 },
+  "measured": { "width": 96, "height": 96 },
+  "data": {
+    "parentElement": { "id": "root", "type": "case-management:root" },
+    "label": "<displayName or \"Trigger <N>\">",
+    "uipath": {
+      "serviceType": "Intsvc.TimerTrigger",
+      "timerType": "timeCycle",
+      "timeCycle": "<timeCycle from tasks.md>"
+    }
+  }
+}
+```
+
+**Position `y` computation:**
+
+```text
+y = max(existingTriggers[i].position.y) + 140
+```
+
+When the only existing trigger sits at `{x: 0, y: 0}`, the first secondary timer trigger lands at `{x: -100, y: 140}`.
+
+The `x` coordinate is always `-100`.
+
+## `entry-points.json` append (required in both cases)
+
+Locate `entry-points.json` adjacent to `caseplan.json` (same directory). Append one entry:
+
+```json
+{
+  "filePath": "/content/<caseplan-basename>.bpmn#<triggerId>",
+  "uniqueId": "<UUID v4>",
+  "type": "CaseManagement",
+  "input":  { "type": "object", "properties": {} },
+  "output": { "type": "object", "properties": {} },
+  "displayName": "<same as node.data.label>"
+}
+```
+
+- `<caseplan-basename>` — the literal filename of the case file (typically `caseplan.json`), producing a path like `/content/caseplan.json.bpmn#trigger_xxxxxx`.
+- `<UUID v4>` — fresh `crypto.randomUUID()` per write. Non-deterministic; normalizer strips in golden diff.
+- `displayName` matches `node.data.label` (including the `Trigger <N>` default if `displayName` absent).
+
+**Write order:** `caseplan.json` first, then `entry-points.json`. If the second write fails, the skill surfaces the inconsistency to the user rather than silently half-applying.
+
+## ID generation
+
+- First-trigger path: literal `trigger_1` (no randomness).
+- Secondary path: `trigger_` prefix + 6 random chars per [`case-editing-operations.md § ID Generation`](../../../case-editing-operations.md#id-generation).
+
+Record `T<n> → <triggerId>` in `id-map.json` for downstream cross-reference.
+
+## Post-write validation
+
+After writing, confirm:
+
+- `schema.nodes` contains the new Trigger node with the expected `id`
+- `node.data.uipath.serviceType == "Intsvc.TimerTrigger"`
+- `node.data.uipath.timerType == "timeCycle"`
+- `node.data.uipath.timeCycle` is byte-identical to the input string
+- For Case A (v19): node has no `style`/`measured`/`width`/`height`/`data.parentElement`
+- For Case B (v19): `style == measured == {width: 96, height: 96}` and `data.parentElement == {id: "root", type: "case-management:root"}`
+- **v20 (both Case A and Case B):** node has NO `position`, `style`, `measured`, `width`, `height`, `zIndex` (Rule 19). `data.parentElement` retained when Case B applies; absent in Case A — same logic as v19, just no layout fields
+- `entry-points.json.entryPoints` has a new entry with `filePath` containing the new `triggerId` and `displayName` matching `node.data.label`
+
+Run `uip maestro case validate <file> --output json` after all triggers for this plugin's batch are added.
+

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

@@ -0,0 +1,77 @@
+# timer trigger — Planning
+
+A case-level trigger that fires on a schedule — once at a specific time, on a repeating interval, with an optional repeat count.
+
+## When to Use
+
+Pick this plugin when the sdd.md describes the case as running on a schedule:
+
+- "Every hour"
+- "Daily at 9 AM"
+- "Every Monday for 5 weeks"
+- Cron-like phrasing
+
+For user-initiated starts, use [manual](../manual/planning.md). For external events, use [event](../event/planning.md).
+
+## Required Fields from sdd.md
+
+Compose a single canonical `timeCycle` string (ISO 8601 repeating interval) from the sdd.md phrasing.
+
+| Field | Source | Notes |
+|-------|--------|-------|
+| `timeCycle` | sdd.md schedule phrasing → ISO 8601 repeating interval | Canonical format: `R[<count>]/[<start-iso>/]<duration>` |
+| `displayName` | sdd.md (optional) | Defaults to `Trigger N` where N = existing-trigger-count + 1 |
+
+## Registry Resolution
+
+**None.** Timer triggers have no registry representation.
+
+## timeCycle Composition
+
+The `timeCycle` field is a single ISO 8601 repeating-interval expression:
+
+```
+R[<count>]/[<start-iso>/]<duration>
+```
+
+- `R` alone — infinite repetitions
+- `R<n>` — exactly `n` repetitions
+- `<start-iso>` — optional start moment, ISO 8601 datetime (include explicit offset or `Z`)
+- `<duration>` — ISO 8601 duration (`PT<time>` for sub-day units, `P<date>` for day-or-larger units)
+
+### Duration reference
+
+| Friendly phrase | ISO 8601 duration |
+|-----------------|-------------------|
+| 10 seconds | `PT10S` |
+| 5 minutes | `PT5M` |
+| 1 hour | `PT1H` |
+| 2 days | `P2D` |
+| 1 week | `P1W` |
+| 3 months | `P3M` |
+
+### sdd.md phrasing → `timeCycle`
+
+| sdd.md phrasing | `timeCycle` |
+|-----------------|-------------|
+| Every hour | `R/PT1H` |
+| Every 30 minutes | `R/PT30M` |
+| Daily at 9 AM UTC | `R/2026-04-26T09:00:00.000Z/P1D` |
+| Every hour, 10 times | `R10/PT1H` |
+| Every 10 min, 12 times starting 2026-04-21 22:00 PDT | `R12/2026-04-21T22:00:00.000-07:00/PT10M` |
+| Every day at 9 AM UTC, 30 times | `R30/2026-04-26T09:00:00.000Z/P1D` |
+
+When the sdd.md phrasing is ambiguous (missing start time, timezone, repeat count), **AskUserQuestion** with 2–3 candidate interpretations + "Something else". Do not silently default timezone or count.
+
+## tasks.md Entry Format
+
+```markdown
+## T02: Configure timer trigger "<display-name>"
+- timeCycle: R12/2026-04-21T22:00:00.000-07:00/PT10M
+- displayName: "<optional — defaults to Trigger N>"
+- sdd-intent: "<prose restatement for reviewer — e.g. Every 10 min, starting 2026-04-21 22:00 PDT, 12 times>"
+- order: after T01
+- verify: node added to schema.nodes with data.uipath.serviceType == Intsvc.TimerTrigger; entry-points.json has matching entry; timeCycle exact match
+```
+
+`sdd-intent` is reviewer-only prose — the execution phase ignores it. `timeCycle` is the canonical executable field, written directly into `node.data.uipath.timeCycle` per [`impl-json.md`](impl-json.md).