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

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

@@ -22,7 +22,7 @@
 ```
 
 - `id`: `t` + 8 alphanumeric chars. `elementId`: `${stageId}-${taskId}`.
-- `isRequired` and `shouldRunOnlyOnce` come from the SDD task envelope via `tasks.md`; default `shouldRunOnlyOnce` to `false` when omitted. Do not infer run-once from task type.
+- `isRequired` and `shouldRunOnlyOnce` come from the SDD task envelope; default `shouldRunOnlyOnce` to `false` when omitted. Do not infer run-once from task type.
 - `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.
 
@@ -34,7 +34,7 @@
 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).
+Fallback: planning-captured schema from `registry-resolved.json`. If unavailable, placeholder per [placeholder-tasks.md](../../../placeholder-tasks.md).
 
 **Step 1 — Root-level bindings:**
 
@@ -42,7 +42,7 @@ Read [bindings/impl-json.md § Full binding shape — non-connector tasks](../..
 
 - `resource`: `"process"`
 - `resourceSubType`: omit (no resourceSubType for rpa tasks)
-- `name` / `folderPath` defaults: from `tasks.md` `name` / `folder-path` fields. `folder-path` is the resolved registry `folders[0].fullyQualifiedName` (per [planning.md § Registry Resolution](planning.md#registry-resolution)) — never the raw sdd.md "Folder", which may be a parent path and faults the job at runtime.
+- `name` / `folderPath` defaults: from `registry-resolved.json` `name` / `folder-path` fields. `folder-path` is the resolved registry `folders[0].fullyQualifiedName` (per [planning.md § Registry Resolution](planning.md#registry-resolution)) — never the raw sdd.md "Folder", which may be a parent path and faults the job at runtime.
 
 Dedup per [§ Deduplication](../../variables/bindings/impl-json.md).
 

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

@@ -19,7 +19,7 @@ Same shape as [process/planning.md](../process/planning.md):
 | `folder-path` | Resolved registry `folders[0].fullyQualifiedName` — NOT the sdd.md "Folder" (which may be a parent path). Binds to `data.folderPath`; Orchestrator starts the job here at runtime. See [§ Registry Resolution](#registry-resolution). |
 | `task-type-id` | from registry (`entityKey` in `process-index.json`) |
 | `inputs` | see [bindings-and-expressions.md](../../../bindings-and-expressions.md) |
-| `outputs` | follow the shared [I/O-binding output-list contract](../../variables/io-binding/planning.md#canonical-tasksmd-output-list) |
+| `outputs` | follow the shared [I/O-binding output-list contract](../../variables/io-binding/planning.md#canonical-output-list) |
 | `runOnlyOnce`, `isRequired` | from sdd.md (`runOnlyOnce` defaults false if omitted; do not infer true from task type) |
 
 ## Registry Resolution
@@ -34,26 +34,30 @@ Same shape as [process/planning.md](../process/planning.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>"
-- name: "<resource-name>"
-- taskTypeId: <entityKey>
-- folder-path: "<folder>"
-- inputs:
-  - <input_name> = "<value>"
-- outputs:
-  - <SDD output row, copied verbatim>
-- runOnlyOnce: false
-- isRequired: true
-- activation-mode: <sequential|parallel|event-triggered|adhoc|fan-in|conditional-gate>   # required
-- entry-rule: <runs-sequentially|current-stage-entered|wait-for-connector|adhoc|selected-tasks-completed>   # required; must pair with activation-mode — see ../../conditions/task-entry-conditions/planning.md
-- order: after T<m>
-- lane: <n>  # structural/layout position only; sequencing is the task entry rule plus data.tasks order.
-- verify: Confirm Result: Success, capture TaskId
+Mark `<UNRESOLVED: rpa "<name>" in folder "<folder>" not found in registry>`. Omit the resolved-schema keys `inputs` / `outputs`; capture the intended wiring in the entry's `wiringNotes` string array. Execution creates a placeholder task — see [placeholder-tasks.md](../../../placeholder-tasks.md).
+
+## Fields to Resolve
+
+Ledger entry in `tasks/registry-resolved.json` — Rule 9's keys plus this type's lookup output:
+
+```json
+{
+  "stage": "<stage>",
+  "task": "<display-name>",
+  "taskType": "rpa",
+  "cacheFile": "process-index.json",
+  "searchQuery": "<name the SDD used to seed the lookup>",
+  "matches": [],
+  "selected": {},
+  "name": "<resource-name>",
+  "taskTypeId": "<entityKey>",
+  "folder-path": "<folder>",
+  "rationale": "<why this match was selected>"
+}
 ```
 
+`matches` is the complete exact-name set from the refreshed cache and `selected` is the chosen match object (or `null` after a genuine empty lookup — see [placeholder-tasks.md § `registry-resolved.json` Entry Shape](../../../placeholder-tasks.md#registry-resolvedjson-entry-shape)).
+
+Everything else the SDD declares — inputs, outputs, required, run-only-once, activation mode, entry rule, lane, and verify text — stays in `sdd.md`. The ledger holds only what the registry lookup produced; Phase 2 reads the contract straight from the SDD ([planning.md § Step 4](../../../planning.md)).
+
 <!-- END: planning.md -->

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

@@ -1,6 +1,6 @@
 # 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).
+> **Phase split.** Written in Phase 2 only. The timer task has no variable inputs to bind — `timerType` + duration come from the SDD's tinning. 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.
 
@@ -24,7 +24,7 @@ Write the timer task directly to `caseplan.json`. No CLI command needed.
 }
 ```
 
-> **Envelope source.** `isRequired` and `shouldRunOnlyOnce` come from the SDD task envelope via `tasks.md`; default `shouldRunOnlyOnce` to `false` when omitted. Do not infer run-once from timer task type.
+> **Envelope source.** `isRequired` and `shouldRunOnlyOnce` come from the SDD task envelope; default `shouldRunOnlyOnce` to `false` when omitted. Do not infer run-once from timer task type.
 > **`data` holds ONLY `timerType` + the duration field.** `skipCondition` and all other envelope fields are top-level siblings of `data`, never nested inside it (a misplaced one passes `validate` silently but is never applied). See [case-schema.md](../../../case-schema.md) §7 Tasks — BaseTask shape.
 
 ## Procedure
@@ -49,7 +49,7 @@ Write the timer task directly to `caseplan.json`. No CLI command needed.
 
 **Step 2 — Populate timer details:**
 
-4. Read the timer type from tasks.md (`every`, `at`, or `time-cycle`)
+4. Read the timer type from the SDD (`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
@@ -64,7 +64,7 @@ Write the timer task directly to `caseplan.json`. No CLI command needed.
 
 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.
+**Bounded repetition** — when the SDD specifies a repeat count, add `data.repeat` as a string alongside `timeDuration`. Omit `data.repeat` entirely for a single fire.
 
 ```json
 "data": { "timerType": "timeDuration", "timeDuration": "PT1H", "repeat": "5" }

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

@@ -56,10 +56,12 @@ Accepted `--time-cycle` values: raw ISO 8601 repeating interval (e.g., `R/PT1H`
 
 Ambiguous phrasing → **AskUserQuestion** with 2–3 candidate interpretations + "Something else".
 
-## tasks.md Entry Format
+## Fields to Resolve
 
-```markdown
-## T<n>: Add wait-for-timer task "<display-name>" to "<stage>"
+Timers are a built-in type with no registry dependency, so a wait-for-timer task produces **no `tasks/registry-resolved.json` entry**. These are reasoning fields only — Phase 2 reads them from `sdd.md` ([planning.md § Step 4](../../../planning.md)).
+
+```text
+wait-for-timer task "<display-name>" in stage "<stage>"
 - every: 1h
 - at: 2026-04-26T09:00:00.000Z   # optional
 - repeat: 5                       # optional
@@ -68,7 +70,6 @@ Ambiguous phrasing → **AskUserQuestion** with 2–3 candidate interpretations
 - runOnlyOnce: false
 - activation-mode: <sequential|parallel|event-triggered|adhoc|fan-in|conditional-gate>   # required
 - entry-rule: <runs-sequentially|current-stage-entered|wait-for-connector|adhoc|selected-tasks-completed>   # required; must pair with activation-mode — see ../../conditions/task-entry-conditions/planning.md
-- order: after T<m>
 - lane: <n>  # structural/layout position only; sequencing is the task entry rule plus data.tasks order.
 - verify: Confirm Result: Success, capture TaskId
 ```

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

@@ -8,16 +8,16 @@ For shared CLI invocation, placeholder substitution, anti-patterns, and the cano
 
 ## Prerequisites from Planning
 
-The `tasks.md` entry provides: `type-id`, `connection-id`, `connector-key`, `object-name`, `event-operation`, `event-mode`, `input-values`, `filter`.
+The SDD row 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
+## Step 1 — Build `--input-details` JSON from the resolved entry
 
-Construct the input-details object literally from `tasks.md`:
+Construct the input-details object literally from `registry-resolved.json`:
 
 ```jsonc
 {
     "eventParameters": "<input-values.eventParameters or omit>",
-    "filter": "<filter from tasks.md or omit>"
+    "filter": "<filter from registry-resolved.json or omit>"
 }
 ```
 
@@ -63,7 +63,7 @@ For a **single-trigger case**, configure the existing `trigger_1` node. For **mu
 - ID: `trigger_` + 6 alphanumeric chars
 - No node-level layout fields (Rule 18 — `position`, `style`, `measured`, etc. omitted)
 
-Set the trigger's display name from `tasks.md`. Record `T<N> → trigger_xxxxxx` in `id-map.json` for downstream cross-reference — incl. the global-vars plugin resolving this event trigger's node id for an In-argument whose `sourceTriggers` names this trigger's T-number (or, when this event trigger is the primary trigger T02, an In-arg with blank `sourceTriggers`).
+Set the trigger's display name from the SDD's Case Triggers row. Record `T<N> → trigger_xxxxxx` in `id-map.json` for downstream cross-reference — incl. the global-vars plugin resolving this event trigger's node id for an In-argument whose `sourceTriggers` names this trigger's T-number (or, when this event trigger is the primary trigger T02, an In-arg with blank `sourceTriggers`).
 
 ### 7b. `data` structure
 
@@ -109,7 +109,7 @@ Write the un-minted `caseShape` into the shared sidecar artifact for the variabl
 
 - **Persistence.** The sidecar persists across hard stops (Phase 2 publish-for-review, 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.
+- **Multi-trigger append.** Trigger plugin runs once per trigger row. 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 row 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.
 
@@ -125,7 +125,7 @@ After writing root bindings, populate IS connection cache per [bindings-v2-sync.
 
 ## 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.
+When the resolved 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
 {
@@ -155,8 +155,8 @@ Three distinct conditions can trigger placeholder fallback for an event trigger.
 
 | 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` |
+| **Planning-time unresolved** (the resolved 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** (the resource 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).

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

@@ -22,35 +22,46 @@ Distinguish from:
 
 Follow the pipeline in [connector-trigger-planning.md § Planning Pipeline](../../../connector-trigger-planning.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
+## Fields to Resolve
+
+T-number is T02 for the first trigger row in sdd.md, T03+ for subsequent rows in multi-trigger cases — see [planning.md Case Triggers](../../../planning.md).
+
+Ledger entry in `tasks/registry-resolved.json` — Rule 9's keys plus the resolved connector fields:
+
+```json
+{
+  "stage": null,
+  "task": "<display-name>",
+  "taskType": "event-trigger",
+  "cacheFile": "typecache-triggers-index.json",
+  "searchQuery": "<trigger display name>",
+  "matches": [],
+  "selected": {},
+  "type-id": "<uiPathActivityTypeId>",
+  "connection-id": "<connection-uuid>",
+  "connector-key": "<connectorKey>",
+  "object-name": "<objectName>",
+  "event-operation": "<eventOperation>",
+  "event-mode": "polling",
+  "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 }] },
+  "rationale": "<why this trigger and connection were selected>"
+}
 ```
 
+A case-level trigger has no stage, so `stage` is `null`. `event-mode` is `polling` or `webhooks`; `input-values` and `filter` are real JSON objects, not strings. The display name and description stay in `sdd.md` ([planning.md § Step 4](../../../planning.md)).
+
 ## Unresolved Fallback
 
 Two entry paths: **Scenario A** — connector not found in TypeCache ([connector-trigger-planning.md § 1 No-match](../../../connector-trigger-planning.md#1-find-the-trigger-in-typecache), after the Rule 17 gate); **Scenario B** — connector found but connection unresolved, only after the create offer ([connector-trigger-planning.md § Resolve the connection](../../../connector-trigger-planning.md#2-resolve-the-connection)) is **declined** or fails. When `Connections` is empty, offer to create one first — do not jump straight here.
 
 > **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, tasks, and conditions. The pattern mirrors the connector-trigger task placeholder in [placeholder-tasks.md](../../../placeholder-tasks.md): structure preserved, runtime config deferred.
+> **Planning emits the element; execution emits a placeholder trigger node.** "Cannot resolve the connector / connection yet" is not a reason to drop the trigger from `caseplan.json` — the no-omission rule (planning.md completeness principle) applies to triggers the same as it does to stages, 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.
+- Mark **every connector-derived field** with `<UNRESOLVED: reason>` in the element — `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 element — there is no schema to wire against.
 - **Execution creates a placeholder trigger node** with `serviceType: "Intsvc.EventTrigger"` as the only `data.inputs` field (no `context[]`, `metadata`, `inputs`, `outputs`, or `bindings`). The node carries `id`, `display.label`, `description`, `parentElement`, `typeVersion`, 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.
 - **No trigger-edge is created** (Rule 20). The first stage's `case-entered` entry condition starts the case regardless of whether this trigger is resolved or a placeholder.

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

@@ -13,12 +13,12 @@ Append one secondary manual trigger to the schema. This plugin performs **two fi
 
 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`)
+## Input spec (from `sdd.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. |
+| `displayName` | yes | the SDD row's display name. 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 element'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).
 
@@ -41,7 +41,7 @@ Record `T<n> → trigger_xxxxxx` in `id-map.json` for downstream cross-reference
 
 ## Default-name fallback
 
-If the T-entry does not supply `display-name`:
+If the SDD row does not supply a display name:
 
 ```text
 existingTriggers = schema.nodes.filter(n => n.type === "uipath.case.trigger")

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

@@ -16,22 +16,23 @@ If the sdd.md says the case runs on a schedule, use [timer](../timer/planning.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). |
+| `display-name` | sdd.md (optional at the element; 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 element; **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.
+Position is NOT a element 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
+## Fields to Resolve
 
-```markdown
-## T02: Configure manual trigger "Start Manually"
+A manual trigger has no registry dependency, so it produces **no `tasks/registry-resolved.json` entry**. These are reasoning fields only — Phase 2 reads them from `sdd.md` ([planning.md § Step 4](../../../planning.md)).
+
+```text
+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
 ```
 

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

@@ -8,7 +8,7 @@ Cross-cutting direct-JSON rules live in [`case-editing-operations.md`](../../../
 
 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`)
+## Input spec (from `sdd.md`)
 
 | Field | Required | Notes |
 |---|---|---|
@@ -39,7 +39,7 @@ Emit the canonical first-trigger shape with the timer `uipath` block:
     "inputs": {
       "serviceType": "timer",
       "timerType": "timeCycle",
-      "timeCycle": "<timeCycle from tasks.md>"
+      "timeCycle": "<timeCycle from sdd.md>"
     }
   }
 }
@@ -63,7 +63,7 @@ Emit a secondary trigger with `data.parentElement` included:
     "inputs": {
       "serviceType": "timer",
       "timerType": "timeCycle",
-      "timeCycle": "<timeCycle from tasks.md>"
+      "timeCycle": "<timeCycle from sdd.md>"
     }
   }
 }

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

@@ -63,14 +63,15 @@ R[<count>]/[<start-iso>/]<duration>
 
 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
+## Fields to Resolve
 
-```markdown
-## T02: Configure timer trigger "<display-name>"
+A timer trigger has no registry dependency, so it produces **no `tasks/registry-resolved.json` entry**. These are reasoning fields only — Phase 2 reads them from `sdd.md` ([planning.md § Step 4](../../../planning.md)).
+
+```text
+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.inputs.serviceType == timer; entry-points.json has matching entry; timeCycle exact match
 ```
 

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

@@ -2,7 +2,7 @@
 
 Top-level binding creation. Referenced by **all** task plugins — non-connector tasks for name + folderPath bindings, connector tasks for ConnectionId + folderKey bindings. Every task type MUST create bindings; see each task plugin's §Root-level bindings section.
 
-> **No `planning.md`** — bindings are created during implementation (driven by each task plugin's §Root-level bindings), not planned as standalone T-entries. Intentional, not a gap.
+> **No `planning.md`** — bindings are created during implementation (driven by each task plugin's §Root-level bindings), not planned as standalone elements. Intentional, not a gap.
 
 ## Destination
 
@@ -96,8 +96,8 @@ The FolderKey binding is **omitted entirely** when `spec.connection.folderKey` i
 
 | Field | Source |
 |---|---|
-| `name` | `tasks.md` `name` field (captured from registry during planning: `entry.name` for process types, `entry.deploymentTitle` for action) |
-| `folderPath` | `tasks.md` `folder-path` field (captured from registry during planning: `entry.folders[0].fullyQualifiedName` for process types, `entry.deploymentFolder.fullyQualifiedName` for action) |
+| `name` | `registry-resolved.json` `name` field (captured from registry during planning: `entry.name` for process types, `entry.deploymentTitle` for action) |
+| `folderPath` | `registry-resolved.json` `folder-path` field (captured from registry during planning: `entry.folders[0].fullyQualifiedName` for process types, `entry.deploymentFolder.fullyQualifiedName` for action) |
 
 ### resourceKey construction — non-connector tasks
 
@@ -117,8 +117,8 @@ Examples:
 
 | Binding | `name` | `propertyAttribute` | `default` | `resourceKey` |
 |---|---|---|---|---|
-| ConnectionBinding | `` `${connectorKey} connection` `` (templated, e.g. `"uipath-microsoft-outlook365 connection"`) | `"ConnectionId"` | `connection-id` from `tasks.md` | `connection-id` from `tasks.md` |
-| FolderKey binding (omit when `spec.connection.folderKey === null`) | `"FolderKey"` (PascalCase) | `"folderKey"` (camelCase — different from `name`) | `folderKey` from `get-connection` (Step 1) | `connection-id` from `tasks.md` (same as ConnectionBinding) |
+| ConnectionBinding | `` `${connectorKey} connection` `` (templated, e.g. `"uipath-microsoft-outlook365 connection"`) | `"ConnectionId"` | `connection-id` from `registry-resolved.json` | `connection-id` from `registry-resolved.json` |
+| FolderKey binding (omit when `spec.connection.folderKey === null`) | `"FolderKey"` (PascalCase) | `"folderKey"` (camelCase — different from `name`) | `folderKey` from `get-connection` (Step 1) | `connection-id` from `registry-resolved.json` (same as ConnectionBinding) |
 
 ### Task references
 

package/skills/uipath-maestro-case/references/plugins/variables/global-vars/impl-json.md

@@ -102,7 +102,7 @@ Rationale: the formal In-arg slot id surfaces in the case BPMN as `<uipath:input
 
 ## Inputs the plugin reads at Phase 3 Step 6.2
 
-1. **`tasks.md`** variable T-entries — for category, type, default, sourceTrigger(s), sourceField(s). On `Category=In` rows, `sourceTriggers` is a single T-number selecting the bound trigger (blank → primary trigger)
+1. **`sdd.md` Case Variables rows** — for category, type, default, sourceTrigger(s), sourceField(s). On `Category=In` rows, `sourceTriggers` is a single T-number selecting the bound trigger (blank → primary trigger)
 2. **`tasks/trigger-spec-cache.json`** — for each trigger's `caseShape.outputs[]` (un-minted), keyed by T-number. Written by trigger plugin at Step 6.1; see [`../../triggers/event/impl-json.md` § Step 8](../../triggers/event/impl-json.md) for the writer-side schema. Top-level keys are T-numbers (e.g., `T02`, `T03`); values have `context`, `inputs`, `outputs` from the trigger's `caseShape`, un-minted (no `var` / `id` / `elementId` synthesized).
 3. **`id-map.json`** — for `T<N> → trigger_xxxxxx` lookup when writing trigger.outputs[] and resolving an `In`-arg's bound trigger node (row's `sourceTriggers`; blank → `id-map["T02"].id`, the primary trigger)
 4. **`caseplan.json`** — to locate trigger nodes (by triggerId from id-map) and existing root variable arrays
@@ -121,7 +121,7 @@ For each trigger in `trigger-spec-cache.json`:
 | Spec output state | SDD reference | `triggerNode.outputs[]` write | `root.inputs[]` | `root.outputs[]` | `root.inputOutputs[]` |
 |---|---|---|---|---|---|
 | Not referenced by SDD | (no row) | `{name: <spec.name>, var: <spec.name>, type: <spec.type>, source: <spec.source>, value: <spec.name>}` — `type` and `source` come from the spec entry verbatim (e.g., `type: "jsonSchema"` + `source: "=response"`). **No `id`, no `elementId`** per FE auto-emit convention (`IntsvcActivityPropertiesUtils.tsx:288-302`). Plain-name auto-emit. | — | — | **Required** — `{id: <spec.name>, name: <spec.name>, type: <spec.type>, elementId: <triggerId>, body: <spec.body>}`. For `jsonSchema`-typed entries (e.g., `response`, `Error`), the companion holds the full body schema that the FE picker uses to discover sub-fields. Without it, sub-field picking is broken and the variable can't be selected in connector-task input bindings. |
-| Referenced as `Category=Variable` | row's `sourceField` path | `{name: <last segment of sourceField path>, var: <sdd-name>, type: <sdd-row.type>, source: "=<row.sourceField>", value: <sdd-name>}` (Pattern C wire). **No `id`, no `elementId`** — resolution flows through the companion in `root.inputOutputs[]`, not through this entry. `name` is the spec sub-field segment (e.g., `"Title"` when `sourceField: response.Title`) — matches FE convention where `name` is the display label of the source field. `source` is `=` prepended to the raw `sourceField` value from tasks.md; `type` comes from the SDD row, NOT the spec — author's chosen type wins. | — | — | `{id: <sdd-name>, name: <sdd-name>, type: <sdd-row.type>, elementId: "root", custom: true}` — companion with elementId="root" routes variable to Case Variables panel; `custom: true` marks it user-declared. |
+| Referenced as `Category=Variable` | row's `sourceField` path | `{name: <last segment of sourceField path>, var: <sdd-name>, type: <sdd-row.type>, source: "=<row.sourceField>", value: <sdd-name>}` (Pattern C wire). **No `id`, no `elementId`** — resolution flows through the companion in `root.inputOutputs[]`, not through this entry. `name` is the spec sub-field segment (e.g., `"Title"` when `sourceField: response.Title`) — matches FE convention where `name` is the display label of the source field. `source` is `=` prepended to the raw `sourceField` value from the SDD row; `type` comes from the SDD row, NOT the spec — author's chosen type wins. | — | — | `{id: <sdd-name>, name: <sdd-name>, type: <sdd-row.type>, elementId: "root", custom: true}` — companion with elementId="root" routes variable to Case Variables panel; `custom: true` marks it user-declared. |
 | Referenced as `Category=In` | **Skip here** — `Category=In` is dispatched in Loop B by Category, NEVER by spec-output name-match (even if an In-arg's Name happens to equal a top-level spec name). The bridge + slot + companion bind to the row's `sourceTriggers` trigger (blank → primary T02), not the trigger Loop A is iterating. See Loop B + § In argument. | — (emit nothing) | — | — | — |
 | Referenced as `Category=Out` | — | **REJECT** (direction mismatch — Out-args flow case→caller) | — | — | — |
 
@@ -156,7 +156,7 @@ Six entries total: 3 trigger outputs (no id) + 3 companions (with id — resolut
 
 ### Loop B — non-extraction rows (In / Out / pure-state Variable)
 
-For each variable T-entry in `tasks.md` that is **`Category=In`** (any `sourceTriggers` — single or blank), **`Category=Out`**, or a **`Category=Variable`** row with **no `sourceTrigger` / `sourceTriggers` field**:
+For each Case Variables row in `sdd.md` that is **`Category=In`** (any `sourceTriggers` — single or blank), **`Category=Out`**, or a **`Category=Variable`** row with **no `sourceTrigger` / `sourceTriggers` field**:
 
 > **`Category=In` always lands here** — even when it carries a `sourceTriggers` T-number. An In-arg names its bound trigger but extracts no payload field, so it is NEVER a Loop A (Pattern C) row. Only `Variable` rows with `sourceTrigger(s)` go to Loop A.
 
@@ -294,7 +294,7 @@ Three entries — formal slot + companion + bridge:
 
 SDD row: `Category=Out`. **Companion is ALWAYS emitted at write time** (per FE convention — `UnifiedBuildCaseDataManager.tsx:298-324` always writes the companion when an Out-arg is created). The BPMN packager's `collapseArgumentCompanions` (`CaseManagementRootConverterUtils.ts:211-237`) may collapse the companion at packaging time, but that's downstream of the skill.
 
-| SDD `Default` | Producer in tasks.md (via task's `->` Outputs row or `=` Updates row) | Runtime behavior |
+| SDD `Default` | Producer in the SDD (via task's `->` Outputs row or `=` Updates row) | Runtime behavior |
 |---|---|---|
 | empty | yes | Producer task fires → writes to `vars.<name>` → caller gets that value at case end. If producer fails to fire, caller gets `""` (the companion's empty default). |
 | present | yes | Producer fires → overwrites companion default. If producer skipped, companion default returned. |
@@ -364,13 +364,13 @@ All logged per [`../../logging/impl-json.md`](../../logging/impl-json.md).
 > | `Category=In` + non-empty `sourceFields` | Phase 2 | In extracts no payload field; SDD-internal |
 > | Same-Name pair (any column mismatch) | Phase 2 | Pure SDD consistency check; not re-validated in Phase 3 |
 > | Missing `Type` on In/Out row | Phase 2 | SDD-internal |
-> | `sourceTriggers` references nonexistent T-number | Phase 2 | tasks.md cross-reference, no spec needed |
+> | `sourceTriggers` references a nonexistent trigger | Phase 2 | SDD cross-reference, no spec needed |
 > | `sourceField` path missing in spec (spec drift) | Phase 3 | Needs spec data |
 > | Type mismatch SDD vs spec | Phase 3 | Needs spec data |
 > | Multi-trigger sourceTriggers/sourceFields T-number mismatch | Phase 3 | Cross-references spec cache for each T-number |
 > | Out-arg producer presence | Phase 3 (io-binding validator, end of phase) | Cross-references task outputs, which only exist after task plugins run |
 >
-> Phase 3 does NOT re-validate the Phase 2 structural checks — they are prerequisite-met by the time Phase 3 runs (Phase 2 rejects before tasks.md is finalized).
+> Phase 3 does NOT re-validate the Phase 2 structural checks — they are prerequisite-met by the time Phase 3 runs (Phase 2 rejects before the variables section is written).
 >
 > **`Category=In` on event triggers is ALLOWED** in v1 (per SDD contract). The previous rejection rule for Category=In on event triggers is removed — the structural emission for In (3-entry: formal slot + companion + bridge) is identical regardless of trigger type. For event triggers, the formal slot's `default` propagates through the bridge to the companion at trigger fire; there's no caller-override path, but the mechanics are valid. The bound trigger is the one named by `sourceTriggers` (blank → primary) and may be any type.
 
@@ -477,7 +477,7 @@ Connector condition rules (`rule.uipath.outputs[]`) participate in the case-vari
 
 The dispatcher logic lives in [io-binding/impl-json.md § Output Binding Shapes for Connector Condition Rules](../io-binding/impl-json.md#output-binding-shapes-for-connector-condition-rules) (the 3rd dispatch path, parallel to task dispatch). The condition plugins (`plugins/conditions/*/impl-json.md`) invoke it as the last step of their `wait-for-connector` recipe.
 
-Loop B (this file) handles the COMPANION emission — it scans `tasks.md` Case Variables rows agnostically of producer type. A `Category=Variable` row whose producer is a connector rule's `->` extract gets the same companion shape as one whose producer is a task's `->` extract. The producer (task plugin OR condition plugin) is responsible for writing the upstream `outputs[]` entry referencing the companion via `var: <caseVar.id>`.
+Loop B (this file) handles the COMPANION emission — it scans the SDD's Case Variables rows agnostically of producer type. A `Category=Variable` row whose producer is a connector rule's `->` extract gets the same companion shape as one whose producer is a task's `->` extract. The producer (task plugin OR condition plugin) is responsible for writing the upstream `outputs[]` entry referencing the companion via `var: <caseVar.id>`.
 
 > **Skip guard.** Rules with no `uipath.outputs[]` (stub placeholder — connector configuration unresolved) contribute no outputs to the global pool and no companions to Loop B — see [`connector-trigger-impl.md § Placeholder fallback`](../../../connector-trigger-impl.md#placeholder-fallback).