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

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

@@ -20,7 +20,7 @@ If sdd.md describes a simple stage-to-stage flow within the same case, do not us
 | `folder-path` | Selected registry `folders[0].fullyQualifiedName` | Binds to `data.folderPath`; use the SDD `Folder Path` only as a concrete lookup hint. `<UNRESOLVED>` means name-only discovery. |
 | `task-type-id` | Registry resolution (below) | `entityKey` in `caseManagement-index.json`; mirrors sdd.md `Resource Identity` when already resolved. |
 | `inputs` | sdd.md task data mapping | Passed as case-instance inputs to the sub-case |
-| `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). |
+| `outputs` | sdd.md task Outputs + `tasks describe` schema | Follow the shared [I/O-binding output-list contract](../../variables/io-binding/planning.md#canonical-output-list). |
 | `runOnlyOnce` | sdd.md (default `false`) | Re-entry behavior comes from the SDD, not the task type. |
 | `isRequired` | sdd.md (default `true`) | |
 
@@ -36,26 +36,30 @@ Case-management lookups stay in `caseManagement-index.json` — never adopt a sa
 
 ## Unresolved Fallback
 
-Mark `<UNRESOLVED: case "<name>" in folder "<folder>" not found in caseManagement-index.json>`, using the preserved sdd.md `Child Case` name even when folder/identity are unresolved. Omit `inputs:` and `outputs:`; capture intended wiring in a fenced ```` ```text ```` code block (not `#` prefixed — it renders as markdown H1). Execution creates a placeholder task — see [placeholder-tasks.md](../../../placeholder-tasks.md). Note: if the referenced sub-case has not been deployed yet, it will not appear in the registry — the user must deploy it before the parent case can reference it.
-
-## tasks.md Entry Format
-
-```markdown
-## T<n>: Add case-management task "<display-name>" to "<stage>"
-- taskTypeId: <entityKey>
-- name: "<child-case-name>"
-- 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: case "<name>" in folder "<folder>" not found in caseManagement-index.json>`, using the preserved sdd.md `Child Case` name even when folder/identity are unresolved. 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). Note: if the referenced sub-case has not been deployed yet, it will not appear in the registry — the user must deploy it before the parent case can reference it.
+
+## 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": "case-management",
+  "cacheFile": "caseManagement-index.json",
+  "searchQuery": "<name the SDD used to seed the lookup>",
+  "matches": [],
+  "selected": {},
+  "name": "<child-case-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/connector-activity/impl-json.md

@@ -4,11 +4,11 @@
 
 > **Phase split.** Runs across both phases. Phase 2 writes `data.typeId` + `data.connectionId` only — no `case spec` call in Phase 2. Phase 3 calls `case spec --input-details` once, reads the populated `caseShape`, and mints the task. See [`../../../phased-execution.md`](../../../phased-execution.md).
 
-Fetch the populated connector task scaffold via `uip maestro case spec --input-details`, then drop it into `caseplan.json`. Field discovery and reference resolution are done during [planning](planning.md) — implementation reads resolved values from `tasks.md` and threads them through the spec call.
+Fetch the populated connector task scaffold via `uip maestro case spec --input-details`, then drop it into `caseplan.json`. Field discovery and reference resolution are done during [planning](planning.md) — implementation reads resolved values from `registry-resolved.json` and threads them through the spec call.
 
 ## Prerequisites from Planning
 
-The `tasks.md` entry provides:
+The SDD row provides:
 
 | Field | Example |
 |---|---|
@@ -23,23 +23,23 @@ The `tasks.md` entry provides:
 
 ## Configuration Workflow
 
-### Step 1 — Build `--input-details` JSON from tasks.md
+### Step 1 — Build `--input-details` JSON from the resolved entry
 
 **Filter preflight:** run Step 4 for any top-level `filter:` before Step 2.
 
-Construct the input-details object from `tasks.md`, rewriting every value containing a reference to its canonical sink form (connector body fields use `=js:(<expr>)`):
+Construct the input-details object from `registry-resolved.json`, rewriting every value containing a reference to its canonical sink form (connector body fields use `=js:(<expr>)`):
 
 ```jsonc
 {
-    // bodyParameters from tasks.md input-values.bodyParameters (dotted keys preserved;
+    // bodyParameters from the resolved input-values.bodyParameters (dotted keys preserved;
     // each value rewritten to canonical form per Step 1.a)
     "bodyParameters": "<input-values.bodyParameters with values rewritten>",
-    // queryParameters from tasks.md input-values.queryParameters (same rewrite rule)
+    // queryParameters from the resolved input-values.queryParameters (same rewrite rule)
     "queryParameters": "<input-values.queryParameters with values rewritten>",
-    // pathParameters from tasks.md input-values.pathParameters (same rewrite rule)
+    // pathParameters from the resolved input-values.pathParameters (same rewrite rule)
     "pathParameters":  "<input-values.pathParameters with values rewritten>",
-    // filter — FilterTree object from tasks.md (or omit when not authored)
-    "filter": "<filter from tasks.md or omit>"
+    // filter — FilterTree object from registry-resolved.json (or omit when not authored)
+    "filter": "<filter from registry-resolved.json or omit>"
 }
 ```
 
@@ -51,7 +51,7 @@ Full input-details contract: [`case-spec-input-details.md`](../../../case-spec-i
 
 Connector body sinks (`bodyParameters`, `queryParameters`, `pathParameters`) require `=js:(...)` wrap for every reference. Resolve cross-task refs first, then apply the wrap:
 
-| Value in tasks.md | Value passed to CLI |
+| Value in the SDD | Value passed to CLI |
 |---|---|
 | `"=vars.X"` | `"=js:(vars.X)"` |
 | `"=metadata.X"` | `"=js:(metadata.X)"` |
@@ -67,24 +67,32 @@ Full per-sink rule and FE source-of-truth: [bindings-and-expressions.md § Canon
 
 Before passing `bodyParameters` to the CLI, scan for keys containing literal `[*]`. Halt if any are present — the binding is malformed.
 
-The `[*]` in `inputs.bodyFields[].name` is **schema notation** (JSONPath-style "array of") for documentation only — NOT a valid input key. Array-of-object body fields MUST be expressed in tasks.md `input-values.bodyParameters` as real JSON arrays under the parent name (see [`planning.md` § Array-of-object body fields](planning.md)). The planner is responsible for emitting the correct shape; this step is a safety net.
+The `[*]` in `inputs.bodyFields[].name` is **schema notation** (JSONPath-style "array of") for documentation only — NOT a valid input key. Array-of-object body fields MUST be expressed in `input-values.bodyParameters` as real JSON arrays under the parent name (see [`planning.md` § Array-of-object body fields](planning.md)). The planner is responsible for emitting the correct shape; this step is a safety net.
 
 **Halt condition.** If any `bodyParameters` key contains literal `[*]`, halt with explicit error:
 ```
 ERROR: bodyParameters key '<key>' contains literal '[*]'.
         Spec field was: <spec field name>. Expected: '<parent>' with a real JSON array value.
-        Fix in tasks.md input-values.bodyParameters; do NOT pass [*] keys to the CLI.
+        Fix in the resolved input-values.bodyParameters; do NOT pass [*] keys to the CLI.
 ```
 
 The CLI accepts the literal `field[*]` key (well-formed JSON) and validate passes, but runtime APIs reject with HTTP 400 `UnableToDeserializePostBody`. The check repeats as a post-write verification — see [Step 8 Post-Write Verification](#post-write-verification) item #12.
 
+#### Step 1.c — Copy `input-values` verbatim; the escaping is already done (MANDATORY)
+
+`registry-resolved.json` is JSON and its `input-values` is a real JSON object, so a `=js:` value in it already carries `\\n` where the JavaScript needs `\n`. This step is JSON to JSON: **copy it byte for byte and re-escape nothing.** Adding a level here writes `\\\\n`, which reaches the runtime as a literal backslash-n printed in the message body — wrong output with no error anywhere. Dropping a level writes `\n`, which JSON decodes to a raw line break and faults the element with `Invalid or unexpected token`.
+
+The one place a level is added is planning, where the sdd.md cell becomes ledger JSON: [`planning.md` § 8 Build input-values](planning.md#8-build-input-values).
+
+**Pass the payload single-quoted.** Bash strips one backslash level inside double quotes, so `--input-details "…\\n…"` delivers `\n` and reintroduces the fault. Single quotes pass it through unchanged.
+
 ### Step 2 — Run `case spec` with input-details
 
 ```bash
 uip maestro case spec --type activity \
   --activity-type-id "<type-id>" \
   --connection-id "<connection-id>" \
-  --input-details "<json from Step 1>" \
+  --input-details '<json from Step 1>' \
   --output json
 ```
 
@@ -118,7 +126,7 @@ This is a hard gate — do NOT proceed to write the task until every required fi
 
 ### Step 4 — FilterBuilder detection (when planning authored a filter)
 
-When `tasks.md` carries a `filter:` object, the activity's operation must declare a `FilterBuilder` design parameter. The CLI rejects the filter at configure time when no FilterBuilder param exists; the planning step 7 should already have caught this by checking `spec.filter` presence, but verify here as a safety net.
+When the resolved entry carries a `filter` object, the activity's operation must declare a `FilterBuilder` design parameter. The CLI rejects the filter at configure time when no FilterBuilder param exists; the planning step 7 should already have caught this by checking `spec.filter` presence, but verify here as a safety net.
 
 - `spec.filter` present (with `builder: "ceql"` and `fields[]`) → CEQL filter is supported. Pass the structured tree under `--input-details.filter`. The CLI compiles it into both halves of the contract: the runtime CEQL string at `caseShape.inputs[name="queryParameters"].body.<filterParamName>` AND the design-time tree under `essentialConfiguration.savedFilterTrees.<filterParamName>` (inside the `=jsonString:` blob in `caseShape.context[name="metadata"].body.activityPropertyConfiguration.configuration`).
 - **Do NOT pass raw CEQL under `queryParameters` for a FilterBuilder operation.** Plain filter fields are normal native-syntax inputs, not authored FilterTrees.
@@ -128,7 +136,7 @@ If `spec.filter` is undefined, a top-level `filter:` is malformed. Repair it bef
 
 1. Find the matching plain query/body field and retain its sink.
 2. Copy the exact native value from the SDD Inputs row (or same-session confirmed model); never derive it from the FilterTree.
-3. In the same T-entry, remove `filter:`, add the value to the declared `input-values` sink, preserve siblings, then restart Step 1.
+3. In the same resolved entry, remove `filter:`, add the value to the declared `input-values` sink, preserve siblings, then restart Step 1.
 
 If the field or exact value is unavailable or ambiguous, halt and ask; non-interactive runs report a blocker. Never drop the requirement or invent downstream filtering.
 
@@ -176,7 +184,7 @@ For each entry in `caseShape.inputs[]`:
 - `elementId` = the task's elementId
 
 For each entry in `caseShape.outputs[]`:
-- Same fields, plus the **dedup rule**: `caseShape.outputs[]` returns generic names like `response` and `error` for every connector task. When multiple connector tasks exist in the same case, these collide. Apply the [uniqueness rule](../../variables/global-vars/impl-json.md#uniqueness-rule): collect all existing output `var` values across every task already in `caseplan.json`; if a `var` already exists, append a counter suffix starting at 2 (e.g., `response` → `response2`, `error` → `error2`). Update `var`, `id`, `value`, and `target` (as `=<new var>`) with the suffixed name. `name`, `displayName`, and `source` stay unchanged.
+- For an entry the SDD does not reference — neither as a bare name nor as the first segment of a `->` path — auto-mint it: `id` = `camelCase(name)`, `var` = same as `id`, `elementId` = the task's elementId. **NOT** the `v` + 8 form the inputs use above. An entry the SDD does reference is emitted by the Output binding step below; do not auto-mint it here. Plus the **dedup rule**: `caseShape.outputs[]` returns generic names like `response` and `error` for every connector task. When multiple connector tasks exist in the same case, these collide. Apply the [uniqueness rule](../../variables/global-vars/impl-json.md#uniqueness-rule): collect all existing output `var` values across every task already in `caseplan.json`; if a `var` already exists, append a counter suffix starting at 2 (e.g., `response` → `response2`, `error` → `error2`). Update `var`, `id`, `value`, and `target` (as `=<new var>`) with the suffixed name. `name`, `displayName`, and `source` stay unchanged.
 
 **Output binding.** Apply [io-binding/impl-json.md § Output Binding Shapes](../../variables/io-binding/impl-json.md#output-binding-shapes). The Step 0 schema for this plugin is `caseShape.outputs[]` from `case spec` (Step 2 above). The dedup rule above applies first; output binding consumes the deduped names.
 
@@ -199,10 +207,10 @@ Generate the task skeleton:
 {
   "id": "<taskId>",
   "type": "execute-connector-activity",
-  "displayName": "<display-name from tasks.md>",
+  "displayName": "<display name from sdd.md>",
   "elementId": "<stageId>-<taskId>",
-  "isRequired": "<from tasks.md, default true>",
-  "shouldRunOnlyOnce": "<from tasks.md runOnlyOnce, default false>",
+  "isRequired": "<from sdd.md Required, default true>",
+  "shouldRunOnlyOnce": "<from sdd.md Run Only Once, default false>",
   "data": {
     "serviceType": "Intsvc.ActivityExecution",
     "context": "<caseShape.context — placeholders substituted in Step 6>",
@@ -236,8 +244,8 @@ Full rule + rationale: [connector-trigger-impl.md § Normalize key casing](../..
 
 Read [bindings/impl-json.md § Full binding shape — connector tasks](../../variables/bindings/impl-json.md) for the canonical 7-field shape on each entry (all required — omitting any causes Studio Web render failure). Per-task value sources:
 
-- `<connection-id>` (drives `resourceKey` on both bindings + ConnectionBinding `default`): from this task's `tasks.md` entry
-- `<connectorKey>` (drives ConnectionBinding templated `name`): from `tasks.md`
+- `<connection-id>` (drives `resourceKey` on both bindings + ConnectionBinding `default`): from this task's `registry-resolved.json` entry
+- `<connectorKey>` (drives ConnectionBinding templated `name`): from `registry-resolved.json`
 - `<folderKey>` (FolderKey binding `default`): from `spec.connection.folderKey` in Step 2 response. **Omit the FolderKey binding entirely when this value is null** (matches `binding-builder.ts:73-83`).
 - Binding IDs `<connBindingId>` / `<folderBindingId>` come from Step 5.
 
@@ -275,7 +283,7 @@ All issues appended to the shared issue list per [logging/impl-json.md](../../lo
 10. At Phase 3 exit, [implementation.md § Step 12 Check 12](../../../implementation.md#step-12--end-of-phase-3-validator-pass) re-asserts 3–8 across every connector node
 11. `bindings_v2.json` `resources` array matches top-level `bindings[]` after the deferred sync
 12. **No literal `[*]` keys in `data.inputs[name="body"].body` (or any input body).** Scan recursively (JSON.stringify + regex `"[^"]*\\[\\*\\][^"]*"\\s*:`). If any key contains literal `[*]`, halt — Step 1.b translation was skipped or incomplete. The body MUST use real arrays under parent names (e.g., `"toRecipients": [{...}]`), never `"toRecipients[*]": {...}`. Validate passes regardless; runtime APIs reject with HTTP 400.
-13. **Lossless inputs (HARD GATE).** Every `tasks.md input-values` field must appear unchanged in the matching `data.inputs[].body`; a top-level `filter:` also requires `spec.filter` and successful compilation. Otherwise halt and repair—never warn and continue.
+13. **Lossless inputs (HARD GATE).** Every resolved `input-values` field must appear unchanged in the matching `data.inputs[].body`; a top-level `filter:` also requires `spec.filter` and successful compilation. Otherwise halt and repair—never warn and continue.
 14. **No PascalCase keys remain (HARD GATE).** Scan the written task's `data.context` / `data.inputs` / `data.outputs` for any capital-first `"Xxx…":` key — every one must have been re-cased in Step 8.a. `validate` does NOT catch content-level leftovers (a Pascal or missing `multipartParameters` passes validate and fails at runtime).
 
 ## What NOT to Do

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

@@ -14,7 +14,7 @@ For **case-level event triggers** (outside any stage), use [`plugins/triggers/ev
 
 ## Resolution Pipeline
 
-Run these steps during planning. Each step feeds into the `tasks.md` entry.
+Run these steps during planning. Each step feeds into the resolved entry.
 
 ### 1. Find the connector in TypeCache
 
@@ -87,7 +87,7 @@ Check `inputs.{bodyFields, pathParameters, queryParameters}` for entries with a
 
 Run the `discoverCommand` exactly as given. Match the sdd.md value to `lookupNames[0]` in the results. Use the resolved `lookupValue` (the id) in `input-values`.
 
-> **Reference IDs are connection-scoped.** Resolve every reference field freshly against the current `--connection-id`, immediately before writing tasks.md. Never reuse an ID resolved against a different connection — silent runtime fault. Full mechanism: [/uipath:uipath-platform — reference-resolution.md § Reference IDs Are Connection-Scoped (CRITICAL)](../../../../../uipath-platform/references/integration-service/reference-resolution.md#reference-ids-are-connection-scoped-critical).
+> **Reference IDs are connection-scoped.** Resolve every reference field freshly against the current `--connection-id`, immediately before writing the resolved entry. Never reuse an ID resolved against a different connection — silent runtime fault. Full mechanism: [/uipath:uipath-platform — reference-resolution.md § Reference IDs Are Connection-Scoped (CRITICAL)](../../../../../uipath-platform/references/integration-service/reference-resolution.md#reference-ids-are-connection-scoped-critical).
 
 > **Paginate when looking up by name.** `run list` returns one page (up to 1000 items); check `Data.Pagination.HasMore` + `Data.Pagination.NextPageToken`. Re-run with `--query "nextPage=<NextPageToken>"` until found or `HasMore` is `"false"`. Short-circuit on first match.
 
@@ -95,7 +95,7 @@ If a reference cannot be resolved, **AskUserQuestion** with the candidates (drop
 
 ### 5. Validate required fields (HARD GATE)
 
-This is a hard gate — do NOT proceed to writing tasks.md until every required field has a value.
+This is a hard gate — do NOT proceed to writing the resolved entry until every required field has a value.
 
 1. Collect every `inputs.*[?required]` entry from the spec output (across `bodyFields`, `pathParameters`, `queryParameters`).
 2. For each, check whether sdd.md names a value (literal, variable reference, or cross-task output).
@@ -121,7 +121,7 @@ Values can be:
 - **Pre-wrapped operator expressions** — `=js:(vars.amount > 5000)` (already canonical — pass-through)
 - **Cross-task refs** — `<- "Stage"."Task".output` (impl resolves through the common [output-reference-ID algorithm](../../variables/io-binding/impl-json.md#output-reference-id-authoritative) to `=vars.<outputReferenceId>`, then wraps)
 
-> **tasks.md carries SDD-natural form.** The implementation step (Step 9.7 of connector-activity impl) rewrites every reference to its canonical sink form when constructing `--input-details`. Connector body sinks use `=js:(<expr>)`. Full rule: [bindings-and-expressions.md § Canonical form per sink](../../../bindings-and-expressions.md#canonical-form-per-sink).
+> **The SDD carries natural form.** The implementation step (Step 9.7 of connector-activity impl) rewrites every reference to its canonical sink form when constructing `--input-details`. Connector body sinks use `=js:(<expr>)`. Full rule: [bindings-and-expressions.md § Canonical form per sink](../../../bindings-and-expressions.md#canonical-form-per-sink).
 
 ### 7. Optional — author a server-side filter
 
@@ -129,7 +129,7 @@ If `spec.filter` exists, author a FilterTree. Otherwise map an SDD filter only t
 
 Filter tree shape, operator table, anti-patterns, worked examples: [/uipath:uipath-platform — Filter Trees (CEQL)](../../../../../uipath-platform/references/integration-service/activities.md#filter-trees-ceql). Same shape applies to triggers (compiler differs — JMESPath instead of CEQL).
 
-The filter tree goes into `tasks.md` under `filter:` as a literal JSON object — Phase 3 passes it to `case spec --input-details`. Do NOT pass a raw CEQL string under `queryParameters.where` (or whichever connector-specific name) when authoring a filter — case-tool rejects this at configure time, and the round-trip from Studio Web breaks.
+The filter tree goes into `registry-resolved.json` under `filter` as a literal JSON object — Phase 3 passes it to `case spec --input-details`. Do NOT pass a raw CEQL string under `queryParameters.where` (or whichever connector-specific name) when authoring a filter — case-tool rejects this at configure time, and the round-trip from Studio Web breaks.
 
 ### 8. Build input-values
 
@@ -145,13 +145,25 @@ Using the mapped fields from Step 6, build the `input-values` JSON with dot-path
 
 Dotted keys (`message.body.content`) get nested into structured objects via `nestDottedKeys` at Phase 3 mint time — the planner just records the dotted form.
 
+**A `=js:` value gains one escape level here, and only here (MANDATORY).** The sdd.md cell holds JavaScript **source**, so a line break in it is already the two characters `\` and `n`. `input-values` is JSON, where that backslash needs one more: write `\\n`. Copy the cell character-for-character and JSON decodes `\n` back to a raw line break, which is a `SyntaxError` inside a `'` or `"` literal and faults the element on its first evaluation. Every later hop is JSON to JSON and re-escapes nothing.
+
+| carrier | the literal text it holds |
+|---|---|
+| sdd.md cell | `\n` |
+| `input-values` in `registry-resolved.json` | `\\n` |
+| `--input-details` JSON | `\\n` |
+| `caseplan.json` on disk | `\\n` |
+| the JavaScript the runtime parses | `\n` |
+
+`uip maestro case validate` returns `Valid` either way and the packer copies the broken form into the `.bpmn` unchanged, so nothing before the run reports it. A raw line break is legal inside a backtick template literal and between operands; only a `'` or `"` literal breaks.
+
 #### Array-of-object body fields — SDD authors business shape; planner translates to wire shape
 
 When `inputs.bodyFields[].name` contains `[*]` (e.g. `toRecipients[*].emailAddress.address`, `attachments[*]`, `blocks[*].text`), the `[*]` is **schema notation** meaning "array of" — borrowed from JSONPath. The SDD describes the input at a **business level**; the planner translates to wire shape using the spec's flat field-name metadata.
 
 **Translation algorithm.** Group spec body fields by parent (the prefix before `[*]`). For each parent:
 
-| Spec — fields with `[*]` for this parent | SDD value form | Planner output (wire shape into `tasks.md input-values.bodyParameters[<parent>]`) |
+| Spec — fields with `[*]` for this parent | SDD value form | Planner output (wire shape into `input-values.bodyParameters[<parent>]`) |
 |---|---|---|
 | Exactly one sub-field `<parent>[*].<leaf>` of `dataType: <T>` | List of scalars matching `<T>` (e.g. `["a@x", "b@y"]`) | `[nestUnder(<leaf>, v) for v in sdd_value]` — each scalar becomes `{<leaf nested>: v}` |
 | One or more sub-fields | List of objects already matching the element shape (e.g. `[{"emailAddress":{"address":"a@x"}}]`) | Pass through unchanged |
@@ -167,7 +179,7 @@ Spec exposes `toRecipients[*].emailAddress.address` (one sub-field, dataType `st
 | bccRecipients | Array of string | ["b@x", "c@x"]    |
 ```
 
-Planner emits to `tasks.md input-values.bodyParameters`:
+Resolution emits to `input-values.bodyParameters`:
 
 ```json
 {
@@ -178,29 +190,33 @@ Planner emits to `tasks.md input-values.bodyParameters`:
 
 **Never** emit a key with literal `[*]` in `bodyParameters`. The CLI accepts it (well-formed JSON) and validate passes; runtime APIs (Microsoft Graph, Slack, etc.) reject with HTTP 400 `UnableToDeserializePostBody`. Pre-input scan in [`impl-json.md` § Step 1.b](impl-json.md#step-1b--array-of-object-body-fields-pre-input-scan-mandatory) halts on any literal `[*]` key.
 
-## tasks.md Entry Format
-
-Populate `outputs:` using the shared [I/O-binding output-list contract](../../variables/io-binding/planning.md#canonical-tasksmd-output-list).
-
-```markdown
-## T<n>: Add connector-activity task "<display-name>" to "<stage>"
-- type-id: <uiPathActivityTypeId>
-- connection-id: <connection-uuid>
-- connector-key: <connectorKey>
-- object-name: <objectName>
-- input-values: {"bodyParameters":{...},"queryParameters":{...},"pathParameters":{...}}
-- filter: {"groupOperator":"And","index":0,"uuId":null,"filters":[{"id":"Status","operator":"Equals","value":{"isLiteral":true,"rawString":"\"Active\"","value":"Active"},"uiId":null}]}
-- outputs:                            # optional; omit only when the SDD declares none
-  - <SDD output row, copied verbatim>
-- 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>
-- verify: tasks.md `input-values` covers every `inputs.*[?required]` from the lean spec across `bodyFields`, `queryParameters`, `pathParameters` — see Step 5 above.
+## Fields to Resolve
+
+Ledger entry in `tasks/registry-resolved.json` — Rule 9's keys plus the resolved connector fields:
+
+```json
+{
+  "stage": "<stage>",
+  "task": "<display-name>",
+  "taskType": "connector-activity",
+  "cacheFile": "typecache-activities-index.json",
+  "searchQuery": "<activity display name>",
+  "matches": [],
+  "selected": {},
+  "type-id": "<uiPathActivityTypeId>",
+  "connection-id": "<connection-uuid>",
+  "connector-key": "<connectorKey>",
+  "object-name": "<objectName>",
+  "input-values": { "bodyParameters": {}, "queryParameters": {}, "pathParameters": {} },
+  "filter": { "groupOperator": "And", "index": 0, "uuId": null, "filters": [{ "id": "Status", "operator": "Equals", "value": { "isLiteral": true, "rawString": "\"Active\"", "value": "Active" }, "uiId": null }] },
+  "rationale": "<why this activity and connection were selected>"
+}
 ```
 
+`input-values` and `filter` are real JSON objects, not strings — Phase 2 reads them back verbatim into `--input-details`. Before leaving this step, confirm the resolved `input-values` covers every `inputs.*[?required]` from the lean spec across `bodyFields`, `queryParameters`, and `pathParameters` (Step 5 above).
+
+Output bindings are **not** recorded here: they come from the SDD Outputs table through the shared [I/O-binding output-list contract](../../variables/io-binding/planning.md#canonical-output-list), which is a reasoning form and never written to disk. Required, run-only-once, activation mode, entry rule, and lane likewise stay in `sdd.md` ([planning.md § Step 4](../../../planning.md)).
+
 `filter:` is optional and present only when the operation supports CEQL (i.e. `spec.filter` was non-null in step 7).
 
 ## Unresolved Fallback

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

@@ -4,13 +4,13 @@
 
 > **Phase split.** Runs across both phases. Phase 2 writes `data.typeId` + `data.connectionId` only — no `case spec` call in Phase 2. Phase 3 calls `case spec --type trigger --input-details` once, reads the populated `caseShape`, substitutes placeholders, and mints the task. See [`../../../phased-execution.md`](../../../phased-execution.md).
 
-Fetch the populated trigger task scaffold via `uip maestro case spec --type trigger --input-details`, then drop it into `caseplan.json` as a `wait-for-connector` task. Field discovery and reference resolution are done during [planning](planning.md) — implementation reads resolved values from `tasks.md` and threads them through the spec call.
+Fetch the populated trigger task scaffold via `uip maestro case spec --type trigger --input-details`, then drop it into `caseplan.json` as a `wait-for-connector` task. Field discovery and reference resolution are done during [planning](planning.md) — implementation reads resolved values from `registry-resolved.json` and threads them through the spec call.
 
 For shared CLI invocation, placeholder substitution, anti-patterns, and the canonical form for filter expressions with variable references, see [connector-trigger-impl.md](../../../connector-trigger-impl.md). For the per-sink canonical-form table covering all expression-syntax decisions in this skill, see [bindings-and-expressions.md § Canonical form per sink](../../../bindings-and-expressions.md#canonical-form-per-sink). This doc covers only the **task-specific** parts.
 
 ## Prerequisites from Planning
 
-The `tasks.md` entry provides:
+The SDD row provides:
 
 | Field | Example |
 |---|---|
@@ -27,16 +27,16 @@ The `tasks.md` entry provides:
 
 ## Configuration Workflow
 
-### 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 from tasks.md input-values.eventParameters (or omit when absent)
+    // eventParameters from the resolved entry's input-values.eventParameters (or omit when absent)
     "eventParameters": "<input-values.eventParameters or omit>",
-    // filter — FilterTree object from tasks.md (or omit when not authored)
-    "filter": "<filter from tasks.md or omit>"
+    // filter — FilterTree object from registry-resolved.json (or omit when not authored)
+    "filter": "<filter from registry-resolved.json or omit>"
 }
 ```
 
@@ -84,10 +84,10 @@ For each entry in `caseShape.outputs[]`: same fields, **plus the dedup rule** pe
 {
   "id": "<taskId>",
   "type": "wait-for-connector",
-  "displayName": "<display-name from tasks.md>",
+  "displayName": "<display name from sdd.md>",
   "elementId": "<stageId>-<taskId>",
-  "isRequired": "<from tasks.md, default true>",
-  "shouldRunOnlyOnce": "<from tasks.md runOnlyOnce, default false>",
+  "isRequired": "<from sdd.md Required, default true>",
+  "shouldRunOnlyOnce": "<from sdd.md Run Only Once, default false>",
   "data": {
     "serviceType": "Intsvc.WaitForEvent",
     "context": "<caseShape.context — placeholders substituted in Step 5>",

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

@@ -22,31 +22,35 @@ Distinguish from:
 
 Follow the pipeline in [connector-trigger-planning.md § Planning Pipeline](../../../connector-trigger-planning.md#planning-pipeline). All steps are identical for both in-stage triggers and case-level event triggers.
 
-## tasks.md Entry Format
-
-Populate `outputs:` using the shared [I/O-binding output-list contract](../../variables/io-binding/planning.md#canonical-tasksmd-output-list).
-
-```markdown
-## T<n>: Add connector-trigger task "<display-name>" to "<stage>"
-- type-id: <uiPathActivityTypeId>
-- connection-id: <connection-uuid>
-- connector-key: <connectorKey>
-- object-name: <objectName>
-- event-operation: <eventOperation>
-- event-mode: <polling|webhooks>
-- input-values: {"eventParameters": {"parentFolderId": "AAMkADNm..."}}
-- filter: {"groupOperator":"And","index":0,"uuId":null,"filters":[{"id":"subject","operator":"Contains","value":{"isLiteral":true,"rawString":"\"urgent\"","value":"urgent"},"uiId":null}]}
-- outputs:                            # optional; omit only when the SDD declares none
-  - <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
+## Fields to Resolve
+
+Ledger entry in `tasks/registry-resolved.json` — Rule 9's keys plus the resolved connector fields:
+
+```json
+{
+  "stage": "<stage>",
+  "task": "<display-name>",
+  "taskType": "connector-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>"
+}
 ```
 
+`event-mode` is `polling` or `webhooks`; `input-values` and `filter` are real JSON objects, not strings.
+
+Output bindings are **not** recorded here: they come from the SDD Outputs table through the shared [I/O-binding output-list contract](../../variables/io-binding/planning.md#canonical-output-list), which is a reasoning form and never written to disk. Required, run-only-once, activation mode (`event-triggered`), entry rule (`wait-for-connector`), and lane likewise 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.

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

@@ -11,13 +11,13 @@ Declare to the builder **only the fields the case wires**. Per wired field:
 - **Wired to a typed Case Variable** — output `O -> var` (the `->` extract operator) or input bound `=vars.<v>` → **required, type pinned** from the variable's `Type` (SDD Case Variables table; the only planning-authoritative type source).
 - **Wired but type not knowable at planning** — cross-task ref (`<- "Stage"."Task".out`), literal, or `=metadata.*` → **required, name only**; the builder picks the type that best fits the field's purpose. Reconciled at verify (the consumer's real type, known at implementation).
 - **Unwired** — the case neither stores the output into a var nor feeds/consumes the field → **omit from the contract**; the builder free-styles whatever the resource's purpose needs.
-- **`=`-computed output row** (`<caseVar> = <expr>` — set / compute / copy, per [io-binding planning § SDD Outputs projection](../variables/io-binding/planning.md#sdd-outputs-table-to-tasksmd-projection-mandatory)) → **not a resource output**: the case computes it at task completion, the resource never emits it → **exclude from the contract**. Only `->` extract rows are resource outputs.
+- **`=`-computed output row** (`<caseVar> = <expr>` — set / compute / copy, per [io-binding planning § SDD Outputs projection](../variables/io-binding/planning.md#sdd-outputs-table-to-caseplan-projection-mandatory)) → **not a resource output**: the case computes it at task completion, the resource never emits it → **exclude from the contract**. Only `->` extract rows are resource outputs.
 
-No field-name heuristic, no silent `string` default. The case vocabulary (`string`/`integer`/`float`/`double`/`boolean`/`datetime`/`date`/`jsonSchema`/`file`) is passed through; mapping it onto the type's native I/O schema is the type skill's concern.
+No field-name heuristic, no silent `string` default. The case vocabulary (`string`/`number`/`integer`/`float`/`double`/`boolean`/`datetime`/`date`/`jsonSchema`/`file`) is passed through **verbatim — never normalised onto a near-equivalent**; mapping it onto the type's native I/O schema is the type skill's concern.
 
 **Deduped builds** ([registry-discovery.md § 1c](../../registry-discovery.md#1c--dedup-the-selected-builds-one-resource-per-name-and-type)): when § 1c merged several create-selected tasks into ONE resource, their wirings are identical by construction (§ 1c merges only on matching I/O) — compute the contract from any one of them.
 
-> **Projection is not normalization.** The pinned builder contract contains resource field names/types only; it does not replace the case binding rows. After the sibling is built, copy each original SDD Outputs row into `tasks.md` with its operator and destination unchanged. In particular, a pinned output named `greeting` from `greeting -> greeting` must remain `greeting -> greeting`, not collapse to bare `greeting` merely because the resource field and case variable share a name.
+> **Projection is not normalization.** The pinned builder contract contains resource field names/types only; it does not replace the case binding rows. After the sibling is built, copy each original SDD Outputs row into the projected output list with its operator and destination unchanged. In particular, a pinned output named `greeting` from `greeting -> greeting` must remain `greeting -> greeting`, not collapse to bare `greeting` merely because the resource field and case variable share a name.
 
 ## Step 1b — Compose the Purpose from the SDD
 

package/skills/uipath-maestro-case/references/plugins/tasks/process/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.
 
 ## Procedure
@@ -33,7 +33,7 @@
 uip maestro case tasks describe --type process --id "<entityKey>" --output json
 ```
 
-Fallback: planning-captured schema from tasks.md. If unavailable, placeholder per [placeholder-tasks.md](../../../placeholder-tasks.md).
+Fallback: planning-captured schema from `registry-resolved.json`. If unavailable, placeholder per [placeholder-tasks.md](../../../placeholder-tasks.md).
 
 **Step 1 — Root-level bindings:**
 
@@ -41,7 +41,7 @@ Read [bindings/impl-json.md § Full binding shape — non-connector tasks](../..
 
 - `resource`: `"process"`
 - `resourceSubType`: `"ProcessOrchestration"`
-- `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/process/planning.md

@@ -21,7 +21,7 @@ For RPA robot tasks specifically, prefer [rpa](../rpa/planning.md). For Coded wo
 | `folder-path` | Resolved registry `folders[0].fullyQualifiedName` (NOT the sdd.md "Folder") | This is the binding's `folderPath` default — Orchestrator starts the job here at runtime. The sdd.md "Folder" only seeds the registry lookup; it may be a parent/truncated path. See [§ Registry Resolution](#registry-resolution). |
 | `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). |
+| `outputs` | sdd.md task Outputs + `tasks describe` schema | Follow the shared [I/O-binding output-list contract](../../variables/io-binding/planning.md#canonical-output-list). |
 | `runOnlyOnce` | sdd.md (default `false`) | Re-entry behavior comes from the SDD, not the task type.  |
 | `isRequired` | sdd.md (default `true`) |  |
 
@@ -33,36 +33,39 @@ For RPA robot tasks specifically, prefer [rpa](../rpa/planning.md). For Coded wo
 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.
-6. **Discover inputs/outputs:** after resolving the `entityKey`, fetch the input/output schema via `tasks describe` — see [bindings-and-expressions.md § Discovering output names](../../../bindings-and-expressions.md). Record input names/types and validate outputs using the shared [I/O-binding output-list contract](../../variables/io-binding/planning.md#canonical-tasksmd-output-list). Unrecognized inputs in sdd.md → ask the user (**AskUserQuestion** with matching field names + "Something else").
+6. **Discover inputs/outputs:** after resolving the `entityKey`, fetch the input/output schema via `tasks describe` — see [bindings-and-expressions.md § Discovering output names](../../../bindings-and-expressions.md). Record input names/types and validate outputs using the shared [I/O-binding output-list contract](../../variables/io-binding/planning.md#canonical-output-list). Unrecognized inputs in sdd.md → ask the user (**AskUserQuestion** with matching field names + "Something else").
 
 ## Unresolved Fallback
 
 If no match is found across both cache files after `registry pull`:
 
 - Mark the task line: `<UNRESOLVED: process "<name>" in folder "<folder>" not found in registry>`
-- Omit `inputs:` and `outputs:`; capture intended wiring in a fenced ```` ```text ```` code block (not `#` prefixed — it renders as markdown H1).
+- Omit the resolved-schema keys `inputs` / `outputs`; capture the intended wiring in the entry's `wiringNotes` string array.
 - Continue planning for remaining tasks.
 - Execution creates a placeholder task (empty `data: {}`, no bindings). See [placeholder-tasks.md](../../../placeholder-tasks.md).
 
-## tasks.md Entry Format
-
-```markdown
-## T<n>: Add process task "<display-name>" to "<stage>"
-- name: "<resource-name>"
-- taskTypeId: <entityKey>
-- folder-path: "<folder>"
-- inputs:
-  - <input_name> = "<literal-or-expression>"
-  - <input_name> <- "<Stage>"."<Task>".<output>
-- 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
+## 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": "process",
+  "cacheFile": "processOrchestration-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 -->