@uipath/skills 1.199.0 → 1.200.0

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

@@ -98,7 +98,7 @@ For each entry in `caseShape.outputs[]`: same fields, **plus the dedup rule** pe
 }
 ```
 
-Append the task to the target stage's `data.tasks` structure in its planned order. Lane placement is structural/layout state; it does not express sequencing. Add `runs-sequentially` to the task's entry conditions when the frontend toggle is selected.
+Append the task to the target stage's `data.tasks` structure using `activation-mode` + `entry-rule`, not `lane` alone. Strict `sequential` tasks append as new single-task inner arrays in planned order. `parallel-after-predecessor` siblings share the planned same next inner array even though their entry rule is `runs-sequentially`. Adhoc, event-driven, fan-in, conditional-gate, and standalone tasks get their own single-task inner array. Only `activation-mode: parallel` or `parallel-after-predecessor` tasks with explicit same-lane intent and rationale may share an inner array. Add `runs-sequentially` to the task's entry conditions when the frontend toggle or ordered task-set rule is selected; if `lane` conflicts with mode, mode wins.
 
 ### Step 8 — Append root-level bindings
 

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

@@ -40,6 +40,8 @@ Populate `outputs:` using the shared [I/O-binding output-list contract](../../va
   - <SDD output row, copied verbatim>
 - isRequired: true
 - runOnlyOnce: false
+- activation-mode: event-triggered   # required; normally event-triggered for a connector event wait
+- entry-rule: wait-for-connector   # required; must pair with activation-mode — see ../../conditions/task-entry-conditions/planning.md
 - order: after T<m>
 - lane: <n>
 - verify: Confirm task created with correct event parameters

package/skills/uipath-maestro-case/references/plugins/tasks/create-inline-common.md

@@ -36,7 +36,7 @@ Rules:
 
 ## Step 3 — Binding invariants
 
-After the sibling is built, registered, and verified (orchestration §), bind the task by name+folder: two bindings `resource:"process"`, `resourceSubType` per the table below, shared `resourceKey="solution_folder.<Name>"`; `name` default `<Name>`, **`folderPath` default `""` (empty string)**. The sibling ships **inside** the solution `.uipx` (registered as a sibling project), so it co-deploys with the case when the solution is published (Phase 6 `uip solution upload`); it is **not** published separately to the tenant.
+After the sibling is built, registered, and verified (orchestration §), bind the task by name+folder: two bindings `resource:"process"`, `resourceSubType` per the table below, shared `resourceKey="solution_folder.<Name>"`; `name` default `<Name>`, **`folderPath` default `""` (empty string)**. The sibling ships **inside** the solution `.uipx` (registered as a sibling project), so it co-deploys with the case when the solution is published (Phase 5 `uip solution upload`); it is **not** published separately to the tenant.
 
 | Type | `resourceSubType` |
 |------|-------------------|

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

@@ -11,7 +11,7 @@
   "displayName": "Run KYC",
   "elementId": "Stage_aB3kL9-t8GQTYo8O",
   "isRequired": true,
-  "shouldRunOnlyOnce": true,
+  "shouldRunOnlyOnce": false,
   "data": {
     "name": "=bindings.bG0SraLpg",
     "folderPath": "=bindings.bH1iJK2lm",
@@ -22,6 +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.
 - `data.name` / `data.folderPath` MUST be `=bindings.<id>` references — never literals.
 
 ## Procedure
@@ -51,7 +52,7 @@ Dedup per [§ Deduplication](../../variables/bindings/impl-json.md).
 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][]`
+4. Append to the target stage's `data.tasks` structure using `activation-mode` + `entry-rule`, not `lane` alone. Strict `sequential` tasks append as new single-task inner arrays in planned order. `parallel-after-predecessor` siblings share the planned same next inner array even though their entry rule is `runs-sequentially`. Adhoc, event-driven, fan-in, conditional-gate, and standalone tasks get their own single-task inner array. Only `activation-mode: parallel` or `parallel-after-predecessor` tasks with explicit same-lane intent and rationale may share `tasks[laneIndex][]`; if `lane` conflicts with mode, mode wins.
 
 > Entry conditions added in Step 10. Input value bindings in Phase 3 per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md).
 

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

@@ -22,14 +22,14 @@ For RPA robot tasks specifically, prefer [rpa](../rpa/planning.md). For Coded wo
 | `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` | sdd.md task Outputs + `tasks describe` schema | Follow the shared [I/O-binding output-list contract](../../variables/io-binding/planning.md#canonical-tasksmd-output-list). |
-| `runOnlyOnce` | sdd.md (default `true`) |  |
+| `runOnlyOnce` | sdd.md (default `false`) | Re-entry behavior comes from the SDD, not the task type.  |
 | `isRequired` | sdd.md (default `true`) |  |
 
 ## Registry Resolution
 
-1. **Primary cache file:** `process-index.json` for `PROCESS`, `processOrchestration-index.json` for `AGENTIC_PROCESS`.
+1. **Primary cache file:** `processOrchestration-index.json` for both `PROCESS` and `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.
+3. **Cross-type fallback — mandatory before unresolved fallback.** If the primary cache file has no exact match, query the *other* process cache with the same name and folder hint before recording `selected: null`, asking the empty-lookup question, or writing a placeholder. Therefore a `PROCESS` or `AGENTIC_PROCESS` miss in `processOrchestration-index.json` **MUST** be followed by a `process-index.json` lookup. The sdd.md label is not authoritative: a runnable process can be registered under either index. When the fallback matches, use that entry's `entityKey`, `name`, and full folder path, then continue to schema discovery — do not preserve the primary miss as an unresolved task.
 4. **Match priority:** exact name + exact folder > exact name, multiple folders (pick matching) > exact name only > no match.
 5. **`folder-path` = the SELECTED entry's `folders[0].fullyQualifiedName`** (not the sdd.md "Folder" — see the field table above). Fall back to the sdd.md folder only when there is no registry match (Unresolved path).
 5a. **`name` = the SELECTED entry's `name`** (not the sdd.md name — the Orchestrator release name is what Orchestrator uses at runtime; it may differ from the package/project name). Record this as the `name` binding default; `resourceKey = <folder-path>.<name>`. Fall back to the sdd.md name only when there is no registry match.
@@ -56,8 +56,10 @@ If no match is found across both cache files after `registry pull`:
   - <input_name> <- "<Stage>"."<Task>".<output>
 - outputs:
   - <SDD output row, copied verbatim>
-- runOnlyOnce: true
+- 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

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

@@ -11,7 +11,7 @@
   "displayName": "Extract Invoice Data",
   "elementId": "Stage_aB3kL9-tQ2pVx7Lm",
   "isRequired": true,
-  "shouldRunOnlyOnce": true,
+  "shouldRunOnlyOnce": false,
   "data": {
     "name": "=bindings.bG0SraLpg",
     "folderPath": "=bindings.bH1iJK2lm",
@@ -22,6 +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.
 - `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.
 
@@ -52,7 +53,7 @@ Dedup per [§ Deduplication](../../variables/bindings/impl-json.md).
 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][]`
+4. Append to the target stage's `data.tasks` structure using `activation-mode` + `entry-rule`, not `lane` alone. Strict `sequential` tasks append as new single-task inner arrays in planned order. `parallel-after-predecessor` siblings share the planned same next inner array even though their entry rule is `runs-sequentially`. Adhoc, event-driven, fan-in, conditional-gate, and standalone tasks get their own single-task inner array. Only `activation-mode: parallel` or `parallel-after-predecessor` tasks with explicit same-lane intent and rationale may share `tasks[laneIndex][]`; if `lane` conflicts with mode, mode wins.
 
 > Entry conditions added in Step 10. Input value bindings in Phase 3 per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md).
 

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

@@ -20,7 +20,7 @@ Same shape as [process/planning.md](../process/planning.md):
 | `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) |
-| `runOnlyOnce`, `isRequired` | from sdd.md |
+| `runOnlyOnce`, `isRequired` | from sdd.md (`runOnlyOnce` defaults false if omitted; do not infer true from task type) |
 
 ## Registry Resolution
 
@@ -47,8 +47,10 @@ Mark `<UNRESOLVED: rpa "<name>" in folder "<folder>" not found in registry>`. Om
   - <input_name> = "<value>"
 - outputs:
   - <SDD output row, copied verbatim>
-- runOnlyOnce: true
+- 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

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

@@ -15,7 +15,7 @@ Write the timer task directly to `caseplan.json`. No CLI command needed.
   "displayName": "Approval Escalation Timer",
   "elementId": "Stage_aB3kL9-tWm4Vx9Tp",
   "isRequired": false,
-  "shouldRunOnlyOnce": true,
+  "shouldRunOnlyOnce": false,
   "skipCondition": "=js:vars.skipReview === true",
   "data": {
     "timerType": "timeDuration",
@@ -24,6 +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.
 > **`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
@@ -32,7 +33,7 @@ Write the timer task directly to `caseplan.json`. No CLI command needed.
 
 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)
+3. Write the task with `"data": {}` to the target stage's `data.tasks` structure using the common placement contract: strict sequential timers get their own single-task inner array, `parallel-after-predecessor` timers share the planned same next inner array even though their entry rule is `runs-sequentially`, adhoc/event-driven/fan-in/conditional-gate/standalone timers get their own single-task inner array, and only explicitly parallel or parallel-after-predecessor timers may share an inner array.
 
 ```json
 {
@@ -41,7 +42,7 @@ Write the timer task directly to `caseplan.json`. No CLI command needed.
   "displayName": "Approval Escalation Timer",
   "elementId": "Stage_aB3kL9-tWm4Vx9Tp",
   "isRequired": false,
-  "shouldRunOnlyOnce": true,
+  "shouldRunOnlyOnce": false,
   "data": {}
 }
 ```

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

@@ -23,6 +23,7 @@ Distinguish from:
 | 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`) | |
+| `runOnlyOnce` | sdd.md (default `false`) | Re-entry behavior comes from the SDD, not the task type. |
 
 ## Registry Resolution
 
@@ -64,6 +65,9 @@ Ambiguous phrasing → **AskUserQuestion** with 2–3 candidate interpretations
 - repeat: 5                       # optional
 - time-cycle: R/PT1H              # optional (overrides above)
 - isRequired: true
+- 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

@@ -4,7 +4,7 @@ Configure the case-level event trigger by writing directly into the trigger node
 
 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.
 
-> **Layout-strip (Rule 18).** Omit `position`, `style`, `measured`, `width`, `height`, `zIndex` from the trigger node. Keep `data.parentElement`, `data.isInvalidDropTarget`, `data.isPendingParent`, `data.label`, `data.description`, `data.uipath`.
+> **Layout-strip (Rule 18).** Omit `position`, `style`, `measured`, `width`, `height`, `zIndex` from the trigger node. Keep `data.parentElement`, `data.isInvalidDropTarget`, `data.isPendingParent`, `data.typeVersion`, `data.display`, `data.description`, `data.inputs`.
 
 ## Prerequisites from Planning
 
@@ -53,7 +53,7 @@ For each entry in `caseShape.inputs[]` (these are trigger configuration: `eventP
 - `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.
+> **`caseShape.outputs[]` are NOT minted here.** Under B's redesign, all writes to `triggerNode.data.inputs.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
 
@@ -69,8 +69,9 @@ Set the trigger's display name from `tasks.md`. Record `T<N> → trigger_xxxxxx`
 
 ```json
 {
-  "label": "<display-name>",
-  "uipath": {
+  "typeVersion": "1.0.0",
+  "display": { "label": "<display-name>" },
+  "inputs": {
     "serviceType": "Intsvc.EventTrigger",
     "context": "<caseShape.context — placeholders substituted in Step 5>",
     "inputs":  "<caseShape.inputs  — var/id minted in Step 6; NO elementId>",
@@ -80,7 +81,8 @@ Set the trigger's display name from `tasks.md`. Record `T<N> → trigger_xxxxxx`
 }
 ```
 
-> `outputs: []` is initialized empty. The variables plugin populates it in Phase 3 Step 6.2 using the sidecar from Step 8 below.
+> Since v24 all trigger runtime config lives under `data.inputs` (the old `data.uipath` bag flattened in). The event trigger's CONFIG-input array is therefore `data.inputs.inputs`, its outputs `data.inputs.outputs`, its context `data.inputs.context`.
+> `data.inputs.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
 
@@ -128,17 +130,18 @@ When the T-entry carries `<UNRESOLVED>` on `type-id`, `connection-id`, or `conne
 ```json
 {
   "id": "<trigger_xxxxxx>",
-  "type": "case-management:Trigger",
+  "type": "uipath.case.trigger",
   "data": {
     "parentElement": { "id": "root", "type": "case-management:root" },
-    "label": "<display-name>",
     "description": "<description from sdd.md>",
-    "uipath": { "serviceType": "Intsvc.EventTrigger" }
+    "typeVersion": "1.0.0",
+    "display": { "label": "<display-name>" },
+    "inputs": { "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.
+`data.inputs` 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-append-to-entrypoints). No trigger-edge is created (Rule 20) — the first stage's `case-entered` entry condition starts the case. No root bindings, no `inputOutputs[]` entries from this trigger.
 
@@ -162,13 +165,13 @@ 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.
+1. `data.inputs.serviceType` is `"Intsvc.EventTrigger"` (not `WaitForEvent` or `CuratedTrigger`).
+2. **Fully configured** (all under `data.inputs`): `context[]`, `inputs[]` (CONFIG inputs only — no `elementId`), `outputs[]` (empty array — populated later by variables plugin Step 6.2), and `bindings[] = []` all present per §7b. `data.typeVersion` is `"1.0.0"`; `data.display.label` set.
 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}}`).
+5. **Placeholder:** all four `data.inputs` 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.inputs.context[name="metadata"].body.activityPropertyConfiguration.configuration` is a `=jsonString:…` string (CLI-produced; do not modify).
+7. When the trigger has event parameters: `data.inputs.context[name="metadata"].body.bindings[Property].metadata.ParentResourceKey` is `EventTrigger.<eventTriggerKey>` (substituted from `EventTrigger.{{TRIGGER_REGISTRATION_KEY}}`).
 8. `schema.edges` stays `[]` (Rule 20) — no edge from this trigger.
 9. `entry-points.json` has a matching entry referencing the trigger node ID.
 

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

@@ -51,7 +51,7 @@ Two entry paths: **Scenario A** — connector not found in TypeCache ([connector
 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).
+- **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.
 - 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

@@ -6,13 +6,13 @@ direct-json: supported
 
 Cross-cutting direct-JSON rules live in [`case-editing-operations.md`](../../../case-editing-operations.md).
 
-> **Layout-strip (Rule 18).** Omit `position`, `style`, `measured`, `width`, `height`, `zIndex` from the trigger node. Keep `data.parentElement`, `data.isInvalidDropTarget`, `data.isPendingParent`, `data.label`, `data.description`, `data.uipath`.
+> **Layout-strip (Rule 18).** Omit `position`, `style`, `measured`, `width`, `height`, `zIndex` from the trigger node. Keep `data.parentElement`, `data.isInvalidDropTarget`, `data.isPendingParent`, `data.typeVersion`, `data.display`, `data.description`.
 
 ## 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`.
+1. Append a `uipath.case.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.
@@ -48,7 +48,7 @@ Record `T<n> → trigger_xxxxxx` in `id-map.json` for downstream cross-reference
 If the T-entry does not supply `display-name`:
 
 ```text
-existingTriggers = schema.nodes.filter(n => n.type === "case-management:Trigger")
+existingTriggers = schema.nodes.filter(n => n.type === "uipath.case.trigger")
 displayName = `Trigger ${existingTriggers.length + 1}`
 ```
 
@@ -61,16 +61,18 @@ Append (not prepend) the trigger node:
 ```json
 {
   "id": "<trigger_XXXXXX>",
-  "type": "case-management:Trigger",
+  "type": "uipath.case.trigger",
   "data": {
     "parentElement": { "id": "root", "type": "case-management:root" },
-    "label": "<displayName>",
-    "description": "<description from sdd.md or LLM-inferred>"
+    "description": "<description from sdd.md or LLM-inferred>",
+    "typeVersion": "1.0.0",
+    "display": { "label": "<displayName>" },
+    "inputs": { "serviceType": "None" }
   }
 }
 ```
 
-**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.
+**`data.inputs.serviceType` is `"None"` for manual triggers.** Older schemas may omit `inputs` entirely — both forms are valid when reading. Always emit `"inputs": {"serviceType": "None"}` when writing.
 
 ## Recipe — `entry-points.json` (append to `entryPoints`)
 
@@ -107,11 +109,12 @@ If the second write fails, the `caseplan.json` mutation must be rolled back to a
 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[].type === "uipath.case.trigger"`.
+- `nodes[].data.display.label` matches the resolved `displayName`.
 - `nodes[].data.description` is present and non-empty (direct-JSON-write divergence — always emitted).
+- `nodes[].data.typeVersion === "1.0.0"`.
 - `nodes[].data.parentElement` always present. No `position`, `style`, `measured`, `width`, `height`, `zIndex` at the node level (Rule 18).
-- `nodes[].data.uipath` is **absent** (manual triggers have no `uipath` key).
+- `nodes[].data.inputs.serviceType === "None"` (or `inputs` absent in older schemas — both are valid).
 - **`schema.edges` is still `[]`** (Rule 20) — the trigger connects to nothing; the case starts via the first stage's `case-entered` entry condition. If an edge was authored, remove it before proceeding.
 - `entry-points.json.entryPoints` contains a new entry with `filePath` ending in `#<trigger_XXXXXX>` and `displayName === <displayName>`.
 

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

@@ -6,7 +6,7 @@ direct-json: supported
 
 Cross-cutting direct-JSON rules live in [`case-editing-operations.md`](../../../case-editing-operations.md).
 
-> **Layout-strip (Rule 18).** Omit `position`, `style`, `measured`, `width`, `height`, `zIndex` from the trigger node. Keep `data.parentElement` (when applicable per Case A vs B below), `data.isInvalidDropTarget`, `data.isPendingParent`, `data.label`, `data.description`, `data.uipath`.
+> **Layout-strip (Rule 18).** Omit `position`, `style`, `measured`, `width`, `height`, `zIndex` from the trigger node. Keep `data.parentElement` (when applicable per Case A vs B below), `data.isInvalidDropTarget`, `data.isPendingParent`, `data.typeVersion`, `data.display`, `data.description`, `data.inputs`.
 
 ## Purpose
 
@@ -25,7 +25,7 @@ Add a scheduled trigger to a case. Adapts shape to whether any Trigger node alre
 Count existing Trigger nodes in `schema.nodes` **before** writing:
 
 ```text
-existingTriggers = schema.nodes.filter(n => n.type === "case-management:Trigger")
+existingTriggers = schema.nodes.filter(n => n.type === "uipath.case.trigger")
 ```
 
 ### Case A — zero existing triggers (first-trigger path)
@@ -35,12 +35,13 @@ Emit the canonical first-trigger shape with the timer `uipath` block:
 ```json
 {
   "id": "trigger_1",
-  "type": "case-management:Trigger",
+  "type": "uipath.case.trigger",
   "data": {
-    "label": "<displayName or \"Trigger 1\">",
     "description": "<description from sdd.md or LLM-inferred>",
-    "uipath": {
-      "serviceType": "Intsvc.TimerTrigger",
+    "typeVersion": "1.0.0",
+    "display": { "label": "<displayName or \"Trigger 1\">" },
+    "inputs": {
+      "serviceType": "timer",
       "timerType": "timeCycle",
       "timeCycle": "<timeCycle from tasks.md>"
     }
@@ -57,13 +58,14 @@ Emit a secondary trigger with `data.parentElement` included:
 ```json
 {
   "id": "trigger_<6-rand>",
-  "type": "case-management:Trigger",
+  "type": "uipath.case.trigger",
   "data": {
     "parentElement": { "id": "root", "type": "case-management:root" },
-    "label": "<displayName or \"Trigger <N>\">",
     "description": "<description from sdd.md or LLM-inferred>",
-    "uipath": {
-      "serviceType": "Intsvc.TimerTrigger",
+    "typeVersion": "1.0.0",
+    "display": { "label": "<displayName or \"Trigger <N>\">" },
+    "inputs": {
+      "serviceType": "timer",
       "timerType": "timeCycle",
       "timeCycle": "<timeCycle from tasks.md>"
     }
@@ -82,13 +84,13 @@ Locate `entry-points.json` adjacent to `caseplan.json` (same directory). Append
   "type": "CaseManagement",
   "input":  { "type": "object", "properties": {} },
   "output": { "type": "object", "properties": {} },
-  "displayName": "<same as node.data.label>"
+  "displayName": "<same as node.data.display.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).
+- `displayName` matches `node.data.display.label` (including the `Trigger <N>` default if `displayName` absent).
 - Leave this entry's `input`/`output` schemas (the `entry-points.json` fields above — not the trigger node's I/O) empty here — Step 6.3 back-fills them from the case's In/Out args ([entry-points-sync.md](../../../entry-points-sync.md)).
 
 **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.
@@ -105,13 +107,13 @@ Record `T<n> → <triggerId>` in `id-map.json` for downstream cross-reference
 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
+- `node.data.inputs.serviceType == "timer"`
+- `node.data.inputs.timerType == "timeCycle"`
+- `node.data.inputs.timeCycle` is byte-identical to the input string
 - Node has NO `position`, `style`, `measured`, `width`, `height`, `zIndex` (Rule 18 layout-strip)
 - Case A: no `data.parentElement`. Case B: `data.parentElement == {id: "root", type: "case-management:root"}`
 - **`schema.edges` is still `[]`** (Rule 20) — the trigger connects to nothing; the case starts via the first stage's `case-entered` entry condition. If an edge was authored, remove it before proceeding.
-- `entry-points.json.entryPoints` has a new entry with `filePath` containing the new `triggerId` and `displayName` matching `node.data.label`
+- `entry-points.json.entryPoints` has a new entry with `filePath` containing the new `triggerId` and `displayName` matching `node.data.display.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

@@ -71,7 +71,7 @@ When the sdd.md phrasing is ambiguous (missing start time, timezone, repeat coun
 - 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
+- verify: node added to schema.nodes with data.inputs.serviceType == timer; 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).
+`sdd-intent` is reviewer-only prose — the execution phase ignores it. `timeCycle` is the canonical executable field, written directly into `node.data.inputs.timeCycle` per [`impl-json.md`](impl-json.md).

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

@@ -6,7 +6,7 @@ Top-level binding creation. Referenced by **all** task plugins — non-connector
 
 ## Destination
 
-Bindings live at top-level `bindings[]` in `caseplan.json` (no `root` wrapper, no `data.uipath`).
+Bindings live at top-level `bindings[]` in `caseplan.json` (no `root` wrapper, no `data.inputs`).
 
 ## What Bindings Are
 

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

@@ -33,7 +33,7 @@ return allVariables.find(v => v.id === variableId);
 | `variables.outputs[]` *(top level)* | YES (the formal entry) | But its `var` points elsewhere — see Out-arg shape below |
 | `task.data.outputs[]` | YES if `id` present | Bare outputs self-declare with `id === var`; reassigned outputs may have a collision-safe `id` while `var` points to the target Case variable |
 | `task.data.inputs[]` | YES — by random `id` | Picker-invisible; used for the In-arg formal slot |
-| `triggerNode.data.uipath.outputs[]` | YES if `id` present; **NO if only `var` (no `id`)** | Pattern A entries (`id === var`) self-resolve; Pattern C entries (`var` only) require a companion in `root.inputOutputs[]` |
+| `triggerNode.data.inputs.outputs[]` | YES if `id` present; **NO if only `var` (no `id`)** | Pattern A entries (`id === var`) self-resolve; Pattern C entries (`var` only) require a companion in `root.inputOutputs[]` |
 
 **"Companion" = the paired `inputOutputs[]` entry whose `id` matches the lookup name.** Required for trigger outputs that lack `id`; load-bearing for Out-args with a `Default` value; optional when the producer (task output) already self-declares.
 
@@ -46,7 +46,7 @@ Under the B refactor, this plugin is **the sole owner** of:
 | `variables.inputs[]` *(top level)* | Yes |
 | `variables.outputs[]` *(top level)* | Yes |
 | `variables.inputOutputs[]` *(top level)* | Yes |
-| `triggerNode.data.uipath.outputs[]` | **Yes** — sole owner under B (was co-mutated with trigger plugin in previous design) |
+| `triggerNode.data.inputs.outputs[]` | **Yes** — sole owner under B (was co-mutated with trigger plugin in previous design) |
 | `task.data.outputs[]` | No — task plugins self-declare; this plugin's writes never touch them |
 | `task.data.inputs[].value` | No — io-binding owns this |
 | top-level `bindings[]` | No — connector / trigger plugins own resource bindings |
@@ -58,7 +58,7 @@ Under the B refactor, this plugin is **the sole owner** of:
 | In argument inputs | `variables.inputs[]` *(top level)* |
 | Out argument outputs | `variables.outputs[]` *(top level)* |
 | All internal variables | `variables.inputOutputs[]` *(top level)* |
-| Trigger output mappings | `nodes[<triggerIndex>].data.uipath.outputs[]` |
+| Trigger output mappings | `nodes[<triggerIndex>].data.inputs.outputs[]` |
 
 ## Uniqueness Rule
 
@@ -83,7 +83,7 @@ Build the uniqueness pool from EVERY `var` / `id` currently in `caseplan.json`.
 |---|---|---|
 | Root variables | top-level `variables.{inputs,outputs,inputOutputs}[]` | The canonical case-variable namespace |
 | Task outputs | `nodes[<stage>].data.tasks[<lane>][].data.outputs[]` (for every task) | Self-declared task outputs |
-| Trigger outputs | `nodes[<trigger>].data.uipath.outputs[]` (for every trigger node) | Plain-name auto-emit + Pattern C wires |
+| Trigger outputs | `nodes[<trigger>].data.inputs.outputs[]` (for every trigger node) | Plain-name auto-emit + Pattern C wires |
 | **Stage entry / exit rule outputs** | `nodes[<stage>].data.entryConditions[].rules[][].uipath.outputs[]` AND `nodes[<stage>].data.exitConditions[].rules[][].uipath.outputs[]` | Connector-bound condition rules — outputs minted under `elementId = <stageId>-<ruleId>` |
 | **Case-exit rule outputs** | `metadata.caseExitRules[].rules[][].uipath.outputs[]` | Connector-bound case-exit rules — outputs minted under `elementId = root-<ruleId>` |
 | **Task-entry rule outputs** | `nodes[<stage>].data.tasks[<lane>][].entryConditions[].rules[][].uipath.outputs[]` (for every task) | Connector-bound task-entry rules — outputs minted under `elementId = <stageId>-<ruleId>` |
@@ -98,6 +98,8 @@ In/Out-arg formal slots (`variables.inputs[].id`, `variables.outputs[].id`) MUST
 
 Rationale: the formal In-arg slot id surfaces in the case BPMN as `<uipath:input id="...">` and is dot-referenced via `=vars.<id>` (the bridge, § In argument). A prefix-less random id can lead with a digit → BPMN parser rejects it (`illegal ID <5AinMKBDm>`); C# identifier + XML NCName rules require a leading letter/underscore. Companion ids (`inputOutputs[].id`) keep the human-readable name (`applicantName`) and are already letter-leading — only the random formal-slot id needs the `v` prefix.
 
+**Anti-pattern:** do not copy the companion's readable name into the formal slot id (e.g. `variables.inputs[].id: "applicantName"`). That satisfies the companion's naming convention but violates the formal slot's mint-as-`v`+8-chars requirement — the two ids are deliberately different values, not the same value written twice.
+
 ## 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)
@@ -190,7 +192,7 @@ No trigger.outputs[] write, no root.inputs[] / outputs[] writes.
 SDD row: `Category=Variable`, `sourceTriggers: T02`, `sourceFields: response.subject`.
 
 ```json
-// triggerNode.data.uipath.outputs[]  (the trigger plugin's caseplan node — written by THIS plugin under B)
+// triggerNode.data.inputs.outputs[]  (the trigger plugin's caseplan node — written by THIS plugin under B)
 { "name": "subject", "var": "calendarTitle",
   "source": "=response.subject", "type": "string", "value": "calendarTitle" }
 // No `id`, no `elementId` — FE auto-emit convention. `name` is the last segment of sourceField path.
@@ -228,9 +230,9 @@ Resolver doesn't care that two trigger entries write to the same `vars.caseStart
 
 SDD row: `Category=In`, optional `sourceTriggers: T<N>` (a single T-number selecting the bound trigger; blank → primary trigger T02). `sourceFields` is empty for In rows. **Works on any trigger type — manual, timer, or event.** For event triggers, the bridge mechanics are identical; the formal slot's `default` propagates to the companion at trigger fire (no caller-override path since events have no API caller, but the structural emission is the same).
 
-**Trigger resolution.** `<triggerId>` in the entries below = `id-map.json[T<N>].id` for the trigger named by `sourceTriggers`; blank `sourceTriggers` → `id-map["T02"].id` (the primary trigger). Entries 1 (formal slot) and 2 (companion) carry it as `elementId`; entry 3 (bridge) is written on that same trigger node's `data.uipath.outputs[]`. `sourceFields` is not consulted for In.
+**Trigger resolution.** `<triggerId>` in the entries below = `id-map.json[T<N>].id` for the trigger named by `sourceTriggers`; blank `sourceTriggers` → `id-map["T02"].id` (the primary trigger). Entries 1 (formal slot) and 2 (companion) carry it as `elementId`; entry 3 (bridge) is written on that same trigger node's `data.inputs.outputs[]`. `sourceFields` is not consulted for In.
 
-> **Bare manual bound trigger:** a manual trigger has no `data.uipath` key (its signature — see [`../../triggers/manual/impl-json.md`](../../triggers/manual/impl-json.md)). When the bound trigger is manual (the common case — the primary trigger is usually manual), create `data.uipath = { "outputs": [] }` on that node before appending the bridge. Do NOT add a `serviceType` — its absence is what keeps the trigger manual.
+> **Bare manual bound trigger:** a manual trigger has no `data.inputs` key (its signature — see [`../../triggers/manual/impl-json.md`](../../triggers/manual/impl-json.md)). When the bound trigger is manual (the common case — the primary trigger is usually manual), create `data.inputs = { "outputs": [] }` on that node before appending the bridge. Do NOT add a `serviceType` — its absence is what keeps the trigger manual.
 
 Three entries — formal slot + companion + bridge:
 
@@ -243,14 +245,14 @@ Three entries — formal slot + companion + bridge:
 { "id": "applicantName", "name": "applicantName", "type": "string",
   "elementId": "<triggerId>" }
 
-// 3. triggerNode.data.uipath.outputs[]  — bridge from formal slot to companion
+// 3. triggerNode.data.inputs.outputs[]  — bridge from formal slot to companion
 { "name": "applicantName", "type": "string", "source": "=vars.v<random8>", "var": "applicantName" }
 // No `id`, no `elementId` on bridge — FE convention. `type` matches the SDD row's Type column.
 ```
 
 **Why three entries instead of one?** The runtime resolver (`VariablesService.findVariableByVariableId`) is a single string-equality find on `Variable.id`. The caller (or trigger fire for event triggers) writes the formal-arg's value into `vars.v<random8>` at trigger fire (because `inputs[].id` is `v<random8>`); downstream code wants to read it as `=vars.applicantName` (because that's the readable name). There is no automatic forwarding between the two slots — the bridge entry on `triggerNode.outputs[]` executes the copy at fire time: `source: "=vars.v<random8>"` reads the formal slot, `var: "applicantName"` writes to the companion's slot. Without the bridge, `=vars.applicantName` resolves to undefined. The companion's `inputOutputs[]` entry alone declares the *name* in the namespace, but holds no *value* because nobody writes to it.
 
-> **Placeholder trigger interaction:** if the **bound trigger** (the one named by `sourceTriggers`, or the primary trigger when blank) is a placeholder (any type), write entries 1 + 2 only; skip the bridge (entry 3) — the placeholder has no `data.uipath.outputs` array. The placeholder trigger never fires, so the bridge would never execute anyway. **Consequence:** at runtime `vars.<name>` (the companion slot) is undefined — the `default` on the `inputs[]` formal slot does NOT propagate to the companion without the bridge. This is expected: a placeholder case is structurally incomplete and not meant to run until the trigger is resolved. Re-generate from scratch (Rule 6) after the trigger resolves to get the working bridge.
+> **Placeholder trigger interaction:** if the **bound trigger** (the one named by `sourceTriggers`, or the primary trigger when blank) is a placeholder (any type), write entries 1 + 2 only; skip the bridge (entry 3) — the placeholder has no `data.inputs.outputs` array. The placeholder trigger never fires, so the bridge would never execute anyway. **Consequence:** at runtime `vars.<name>` (the companion slot) is undefined — the `default` on the `inputs[]` formal slot does NOT propagate to the companion without the bridge. This is expected: a placeholder case is structurally incomplete and not meant to run until the trigger is resolved. Re-generate from scratch (Rule 6) after the trigger resolves to get the working bridge.
 
 **File-type In-arg carve-out:** when `type === "file"`:
 - Formal slot (entry 1) MUST add `body: <FILE_TYPE_JSON_SCHEMA>` (see [`## file type`](#file-type)) — drives entry-points.json `$ref: "#/definitions/job-attachment"` at packaging

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

@@ -46,7 +46,7 @@ For each top-level Step 0 entry, check whether tasks.md references it either as
 
 - **`<sdd-field-path> -> <sdd-name>`** (extract) → reassign-shape. Let `baseId = camelCase(leaf segment)` and allocate `id` per the global [uniqueness rule](../global-vars/impl-json.md#uniqueness-rule), including its controlled equal-name alias. Emit `{name: <resolved name>, type: <resolved descriptor's type>, id: <allocated id>, var: "<sdd-name>", originalVar: <allocated id>, value: "<sdd-name>", source: "=<sdd-field-path>", target: "=<allocated id>", elementId: "<stage-task>"}`. `<resolved name>` is the top-level schema display name for a top-level path; for a nested path it is the leaf display name when present, otherwise the exact final path segment. **`source` is the SDD's left-side string with `=` prefix, verbatim.** **`type` is required on every emitted output — FE rejects entries without it.** **`originalVar` is load-bearing and mirrors the allocated `id`** — it records the output slot before reassignment and tells FE's `mutateRootVariables` (`VariableMutationUtils.ts:135`) to skip root-mirroring, preserving the case-Variable companion across FE edits. Example: if another task already owns `id: "aPIOutput1"`, `APIOutput1 -> renamedResult` emits `id: "aPIOutput12"`, `target: "=aPIOutput12"`, `var: "renamedResult"`, and `originalVar: "aPIOutput12"`.
 - **Bare `<name>`** (no operator) → auto-mint shape: `{name, type: <Step 0 entry's type>, id: <camelCase(name)>, var: <id>, value: <id>, source: <Step 0 entry's source verbatim>, target: "=<id>", elementId}`. No `originalVar`. Used for top-level Step 0 entries the SDD doesn't alias.
-- **`<sdd-name> = <expression>`** (set / compute / copy) → Scenario E shape: `{name: "<sdd-name>", custom: true, var: "<sdd-name>", value: "<expression>", source: "<same as value>", target: "", body: "", type: <case var's type>, elementId: "root"}`. **No `id`**, no `originalVar`. NO root mirror — FE's `isUpdateExistingOutput` filter at `VariableMutationUtils.ts:49-64` skips it. For a quoted string literal, treat the quotes as SDD delimiters: `status = "InReview"` emits JSON `"value": "InReview", "source": "InReview"` — never embed the delimiters as payload (`"value": "\"InReview\""`).
+- **`<sdd-name> = <expression>`** (set / compute / copy) → Scenario E shape: `{name: "<sdd-name>", custom: true, var: "<sdd-name>", value: "<expression>", source: "<same as value>", target: "", body: "", type: <case var's type>, elementId: "root"}`. **No `id`**, no `originalVar`. NO root mirror — FE's `isUpdateExistingOutput` filter at `VariableMutationUtils.ts:49-64` skips it. Canonicalize `=metadata.X` to `=js:metadata.X` in both `value` and `source`; retain the SDD-natural form in `tasks.md`. For a quoted string literal, treat the quotes as SDD delimiters: `status = "InReview"` emits JSON `"value": "InReview", "source": "InReview"` — never embed the delimiters as payload (`"value": "\"InReview\""`).
 - **Schema fields with no SDD reference** → fall back to auto-mint shape (`var` = camelCased schema name). Connector plugins additionally apply the [uniqueness rule](../global-vars/impl-json.md#uniqueness-rule) dedup-suffix on collision (e.g., `response` → `response2`).
 
 **Equal-name extract dispatch.** Dispatch by the explicit operator before comparing names; equal operands select the reassign shape, never the bare auto-mint branch. Apply the global [controlled-alias rule](../global-vars/impl-json.md#uniqueness-rule). With no unrelated collision, `greeting -> greeting` emits `id`, `var`, `originalVar`, and `value` as `"greeting"`, with `source: "=greeting"` and `target: "=greeting"`. `originalVar` distinguishes reassignment from a bare output and keeps the predeclared root companion intact during frontend synchronization; the linked allocator owns any required suffixing.
@@ -179,6 +179,10 @@ Also scan `=vars.X` references in:
 
 Same resolution rule applies — these are read-side consumers of the variable namespace.
 
+### Check 1.5 — Custom-output metadata expressions are canonical
+
+For every `custom: true` output, reject `value` or `source` beginning with `=metadata.`; emit `=js:metadata.<field>` in both properties instead.
+
 ### Check 2 — Out-arg producer presence
 
 For every entry in top-level `variables.outputs[]` (formal Out-arg entries), the entry's `var` field is a POINTER to the variable slot that should hold the value at case end. Per the always-emit-companion rule, the companion in `variables.inputOutputs[]` is always present; its `default` field is empty when SDD didn't declare a Default.
@@ -213,7 +217,7 @@ for entry in root.outputs[]:
   has_bare_name_producer   = exists in tasks.md any task's T-entry with an `outputs:` line `- <name>` (bare, no operator) where camelCase(name) == var
   has_any_producer         = has_extraction_producer || has_assignment_producer || has_bare_name_producer
 
-  producer_task_unresolved = the tasks.md-declared producer task is a Rule 17 placeholder (look up the task in caseplan.json by displayName; check `node.data.uipath` is empty `{}`)
+  producer_task_unresolved = the tasks.md-declared producer task is a Rule 17 placeholder (look up the task in caseplan.json by displayName; check `node.data.inputs` is empty `{}`)
 
   if has_companion_default:
       # Companion default guarantees a value; producer is optional bonus