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

package/skills/uipath-maestro-case/references/connector-integration.md

@@ -56,7 +56,7 @@ Output: `{ Entry, Config, Connections }` where:
    - **`Connections` non-empty** → list connections by `name` **plus a "Create a new connection" option** (an existing connection may not fit the intent).
    - **`Connections` empty** → offer **Create a new connection** / **Skip (defer)**.
 3. **Create chosen** → create the connection, then continue to Step 3 with the returned `ConnectionId`. Procedure — background `is connections create`, capture `ConnectionId`, headless fallback: [§ Creating a Connection](#creating-a-connection).
-4. **Skip / create declined or failed / non-interactive run** → mark the task `<UNRESOLVED: no IS connection for <connectorKey>>` in `tasks.md` and omit `input-values:`. Execution writes a placeholder connector task — `type` + `displayName` + `data: {}`, no `data.typeId` / `data.connectionId` keys. Note it in the completion report. See [placeholder-tasks.md](placeholder-tasks.md). A failed `is connections create` MUST route here after surfacing the error (§ Creating a Connection step 4) — **planning continues to a placeholder, it never stalls.**
+4. **Skip / create declined or failed / non-interactive run** → mark the task `<UNRESOLVED: no IS connection for <connectorKey>>` in `tasks/registry-resolved.json` and omit its `input-values` key. Execution writes a placeholder connector task — `type` + `displayName` + `data: {}`, no `data.typeId` / `data.connectionId` keys. Note it in the completion report. See [placeholder-tasks.md](placeholder-tasks.md). A failed `is connections create` MUST route here after surfacing the error (§ Creating a Connection step 4) — **planning continues to a placeholder, it never stalls.**
 
 #### Creating a Connection
 
@@ -75,7 +75,7 @@ uip is connections create "<connector-key>" --output json
 4. **On failure — surface and re-prompt, never stall.** The create failed if the command **exits non-zero**, the JSON `Result` is `"Failure"`, or no `Data.ConnectionId` is returned (e.g. OAuth denied/failed, browser closed, connector misconfigured). On auth failure the command **exits** (verified: exit 1) — it does not hang. Do NOT silently proceed and do NOT leave planning incomplete:
    1. Show the user the failure `Message` (and `Instructions` if present) verbatim — do not invent a cause. Example: `{ "Result": "Failure", "Message": "Authentication failed", "Instructions": "Check credentials and try again." }`.
    2. Re-prompt via **AskUserQuestion**: **Retry create** (re-run `is connections create`) / **Skip (defer)**.
-   3. On **Skip**, or after a repeated failure, fall to Selection rule 4 — mark `<UNRESOLVED>`, emit the placeholder, and **finish writing `tasks.md`** so planning completes.
+   3. On **Skip**, or after a repeated failure, fall to Selection rule 4 — mark `<UNRESOLVED>`, emit the placeholder, and **finish writing `registry-resolved.json`** so resolution completes.
 
 **Headless / no-browser fallback** (CI, remote sandbox, no display) — the agent cannot complete browser OAuth. Either ask the user to run `! uip is connections create "<connector-key>" --output json` in their own terminal and paste back the `ConnectionId`, or run with `--no-wait` to get the pending authorization URL, surface it, and poll until `State: Enabled`.
 
@@ -133,7 +133,7 @@ Each `inputs.*` entry with a `reference` carries a pre-built `discoverCommand`:
 
 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 / minting the spec. 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 `registry-resolved.json` / minting the spec. 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.
 
@@ -167,20 +167,29 @@ Tree shape, operator table, anti-patterns, "How to build" guide, worked examples
 
 ---
 
-## Output Contract to Tasks.md
-
-Record the resolved values in `tasks.md` under the task entry:
-
-```markdown
-## T25: Add connector-activity task "Create Jira Issue" to "Triage"
-- type-id: 718fdc36-73a8-3607-8604-ddef95bb9967
-- connection-id: 7622a703-5d85-4b55-849b-6c02315b9e6e
-- connector-key: uipath-atlassian-jira
-- object-name: issue
-- input-values: {"bodyParameters":{"fields.project.key":"PROJ","fields.issuetype.id":"10004"}}
-- filter: {"groupOperator":"And","filters":[{"id":"Status","operator":"Equals","value":{"isLiteral":true,"rawString":"\"Open\"","value":"Open"},"uiId":null}]}
+## Output Contract to `registry-resolved.json`
+
+Record the resolved values on the task's ledger entry, alongside Rule 9's keys (`stage`, `task`, `taskType`, `cacheFile`, `searchQuery`, `matches`, `selected`, `rationale`):
+
+```json
+{
+  "stage": "Triage",
+  "task": "Create Jira Issue",
+  "taskType": "connector-activity",
+  "type-id": "718fdc36-73a8-3607-8604-ddef95bb9967",
+  "connection-id": "7622a703-5d85-4b55-849b-6c02315b9e6e",
+  "connector-key": "uipath-atlassian-jira",
+  "object-name": "issue",
+  "input-values": { "bodyParameters": { "fields.project.key": "PROJ", "fields.issuetype.id": "10004" } },
+  "filter": {
+    "groupOperator": "And",
+    "filters": [
+      { "id": "Status", "operator": "Equals", "value": { "isLiteral": true, "rawString": "\"Open\"", "value": "Open" }, "uiId": null }
+    ]
+  }
+}
 ```
 
-Also record in `registry-resolved.json`: search query, matched entry, selected connection, connector metadata, and (when surfaced) `spec.diagnostics.fallbacks[]`.
+`input-values` and `filter` are real JSON objects, not strings — Phase 2 reads them back verbatim into `--input-details` ([connector-activity/impl-json.md § Step 1](plugins/tasks/connector-activity/impl-json.md)). Also record the selected connection, connector metadata, and (when surfaced) `spec.diagnostics.fallbacks[]`.
 
 <!-- END: connector-integration.md -->

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

@@ -2,7 +2,7 @@
 
 Shared **write** logic for connector-based triggers: the single `case spec --input-details` call, binding-ID mint, `caseShape.context` splice + placeholder substitution, the connector-bound condition-rule target, the placeholder stub, and root bindings.
 
-Planning — TypeCache lookup, connection pick, spec discovery, reference resolution, the required-param gate, SDD mapping, and input-values + filter authoring — is in the companion [connector-trigger-planning.md](connector-trigger-planning.md), which also holds the `tasks.md` field list this file reads from.
+Planning — TypeCache lookup, connection pick, spec discovery, reference resolution, the required-param gate, SDD mapping, and input-values + filter authoring — is in the companion [connector-trigger-planning.md](connector-trigger-planning.md), which also holds the `registry-resolved.json` field list this file reads from.
 
 Used by three:
 - [connector-trigger task](plugins/tasks/connector-trigger/impl-json.md) — in-stage `wait-for-connector` task (target: `task.data`)
@@ -15,16 +15,16 @@ Used by three:
 
 > **Each connector trigger runs its own `case spec`.** Even when two triggers share the same `connection-id`, `caseShape` is task-shape-specific (different `objectName`, `eventOperation`, `inputs`, `outputs`). Never reuse another task's spec output.
 
-### 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 the trigger's `registry-resolved.json` entry:
 
 ```jsonc
 {
-    // eventParameters from tasks.md input-values.eventParameters (or omit when no event params authored)
+    // eventParameters from the resolved entry's input-values.eventParameters (or omit when no event params authored)
     "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 the resolved entry (or omit when not authored)
+    "filter": "<filter from the resolved entry or omit>"
 }
 ```
 
@@ -106,8 +106,8 @@ After splicing the spec subtree (`context` / `inputs` / `outputs` and their nest
 Per-plugin: each plugin's `impl-json.md` mints these onto `caseShape.inputs[]` / `caseShape.outputs[]` and writes them to its target shape (task vs trigger node).
 
 Conventions (shared with activity):
-- `var` = `v` + 8 alphanumeric chars (unique across the case — see [global-vars/impl-json.md § Uniqueness Rule](plugins/variables/global-vars/impl-json.md#uniqueness-rule))
-- `id` = same as `var`
+- **Inputs:** `var` = `v` + 8 alphanumeric chars (unique across the case — see [global-vars/impl-json.md § Uniqueness Rule](plugins/variables/global-vars/impl-json.md#uniqueness-rule)); `id` = same as `var`
+- **Outputs:** name-based, not `v` + 8 — `id` = `camelCase(name)`, `var` = same as `id`, and only for an entry the SDD does not reference. Entries it does reference are emitted by [io-binding/impl-json.md § Output Binding Shapes](plugins/variables/io-binding/impl-json.md#output-binding-shapes)
 - `elementId` = the task's elementId (in-stage `wait-for-connector` task), the trigger node's id (case-level event trigger), or `<ownerNodeId>-<ruleId>` (connector-bound condition rule — see [§ Target: connector-bound condition rule](#target-connector-bound-condition-rule))
 
 For **outputs** apply the dedup rule: collect existing output `var` values across every task / trigger / **connector-bound condition rule** already in `caseplan.json`; if a `var` already exists (e.g. `response`, `error` collide across multiple connector tasks / triggers / rules), append a counter starting at 2 (`response2`, `error2`). Update `var`, `id`, `value`, `target` (when present); keep `name`, `displayName`, `source` unchanged. **Rule outputs participate in the same global pool** — the dedup must walk condition `rules[][].uipath.outputs[]` across all 4 condition scopes (stage-entry / stage-exit / case-exit / task-entry, case-exit rules living under `metadata.caseExitRules`) in **both directions**: when a rule mints outputs, dedupe against tasks + triggers + rules; when a task / trigger mints outputs, dedupe against existing rule outputs. See [global-vars/impl-json.md § Uniqueness Rule](plugins/variables/global-vars/impl-json.md#uniqueness-rule) for the full enumeration.
@@ -141,7 +141,7 @@ The same stub therefore has two lifetimes: temporary for a resolved connector aw
 
 ### Procedure (Phase 3)
 
-1. Resolve the connector in planning exactly as the task does — [connector-trigger-planning.md § Planning Pipeline](connector-trigger-planning.md#planning-pipeline). The condition plugin's `planning.md` records the same fields (`type-id` (activity-type-id), `connector-key`, `connection-id`, `object-name`, `event-operation`, `event-mode`, `input-values`, optional `filter`) — T-entry layout: [connector-trigger-planning.md § tasks.md fields](connector-trigger-planning.md#tasksmd-fields-planning). **Event parameters and filter accept `=vars.X` / `=js:` expressions exactly like the task** — they compile into `rule.uipath.context` / filter via `case spec --type trigger --input-details` (`input-values` + filter). Only the literal request `body` input is value-less (an event sends no body).
+1. Resolve the connector in planning exactly as the task does — [connector-trigger-planning.md § Planning Pipeline](connector-trigger-planning.md#planning-pipeline). The condition plugin's `planning.md` records the same fields (`type-id` (activity-type-id), `connector-key`, `connection-id`, `object-name`, `event-operation`, `event-mode`, `input-values`, optional `filter`) — resolved-entry layout: [connector-trigger-planning.md § registry-resolved.json fields](connector-trigger-planning.md#registry-resolvedjson-fields-resolution). **Event parameters and filter accept `=vars.X` / `=js:` expressions exactly like the task** — they compile into `rule.uipath.context` / filter via `case spec --type trigger --input-details` (`input-values` + filter). Only the literal request `body` input is value-less (an event sends no body).
 2. Run `case spec --type trigger --input-details` ([§ Phase 3 Implementation](#phase-3-implementation--single-cli-call)) to mint the populated `caseShape`.
 3. Substitute `{{CONN_BINDING_ID}}` / `{{FOLDER_BINDING_ID}}` in `caseShape.context` ([§ Step 4](#step-4--substitute-placeholders-in-caseshapecontext)). If the caseShape carries a `{{TRIGGER_REGISTRATION_KEY}}` entry (event-parameter connectors only), substitute it exactly as the task does ([§ Step 3](#step-3--mint-binding-ids-and-when-applicable-trigger-registration-key)) — there is no rule-specific variant.
 4. Mint `var` / `id` / `elementId` on `caseShape.inputs[]` / `outputs[]` ([§ Step 5](#step-5--mint-var--id--elementid-on-inputs-and-outputs)), with `elementId = <ownerNodeId>-<ruleId>`. Apply the output dedup rule.
@@ -162,7 +162,7 @@ The same stub therefore has two lifetimes: temporary for a resolved connector aw
 }
 ```
 
-5b. If the T-entry has `outputs:`, dispatch `rule.uipath.outputs[]` per [io-binding/impl-json.md § Output Binding Shapes for Connector Condition Rules](plugins/variables/io-binding/impl-json.md#output-binding-shapes-for-connector-condition-rules) — rewrite each already-minted output entry per its `->` / `=` operator. Skip when the rule has no `uipath.outputs[]` (stub placeholder — the stub always emits `uipath`, but with empty `outputs[]`).
+5b. If the resolved entry has outputs, dispatch `rule.uipath.outputs[]` per [io-binding/impl-json.md § Output Binding Shapes for Connector Condition Rules](plugins/variables/io-binding/impl-json.md#output-binding-shapes-for-connector-condition-rules) — rewrite each already-minted output entry per its `->` / `=` operator. Skip when the rule has no `uipath.outputs[]` (stub placeholder — the stub always emits `uipath`, but with empty `outputs[]`).
 
 6. Append root bindings (ConnectionId + FolderKey) and run the deferred Step 10.5 `bindings_v2` sync — identical to the task ([§ Root-level bindings](#root-level-bindings)).
 
@@ -193,11 +193,11 @@ Emit a **stub `uipath`**, never a bare rule. The stub is the minimum shape accep
     "outputs": [],
     "bindings": []
   },
-  "conditionExpression": "<carry from the T-entry if present>"
+  "conditionExpression": "<carry from the SDD row if present>"
 }
 ```
 
-This stub is a **deliberate mock**. While temporary, it is simply Phase 2 build state. If it remains after Phase 3, Studio Web flags it and the rule **fails at debug/run**. A remaining stub has no real outputs, Connection/Folder bindings, IS-cache entry, or rule-specific `bindings_v2` resource. Stamp unresolved `tasks.md` entries with Rule 8 markers, log them, and list them in the completion report as **"replace the `placeholder` connector values before debug / publish-to-run."** Upgrade later by re-running the [§ Procedure](#procedure-phase-3).
+This stub is a **deliberate mock**. While temporary, it is simply Phase 2 build state. If it remains after Phase 3, Studio Web flags it and the rule **fails at debug/run**. A remaining stub has no real outputs, Connection/Folder bindings, IS-cache entry, or rule-specific `bindings_v2` resource. Stamp unresolved `registry-resolved.json` entries with Rule 8 markers, log them, and list them in the completion report as **"replace the `placeholder` connector values before debug / publish-to-run."** Upgrade later by re-running the [§ Procedure](#procedure-phase-3).
 
 ---
 
@@ -205,8 +205,8 @@ This stub is a **deliberate mock**. While temporary, it is simply Phase 2 build
 
 Read [bindings/impl-json.md § Full binding shape — connector tasks](plugins/variables/bindings/impl-json.md) for the canonical 7-field shape on each entry (all required — omitting any causes Studio Web render failure). Per-trigger value sources:
 
-- `<connection-id>` (drives `resourceKey` on both bindings + ConnectionBinding `default`): from this trigger's `tasks.md` entry
-- `<connectorKey>` (drives ConnectionBinding templated `name`): from `tasks.md`
+- `<connection-id>` (drives `resourceKey` on both bindings + ConnectionBinding `default`): from this trigger'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`).
 
 Dedup per [§ Deduplication](plugins/variables/bindings/impl-json.md). Source-of-truth code: `binding-builder.ts` in `uipcli-case-validate/packages/case-tool/src/utils/`.
@@ -224,7 +224,7 @@ After writing root bindings, populate IS connection cache per [bindings-v2-sync.
 - **Do NOT leave spec PascalCase keys in the finished node — and do NOT re-case by retyping.** The write is PascalCase-verbatim (pass 1); the re-case is per-key `Edit` with `replace_all` (`"Name":` → `"name":`, pass 2). Retyping the subtree to change casing is the memory-reconstruction failure above wearing a different hat. See [§ Normalize key casing](#normalize-key-casing-pascalcase--camelcase).
 - **Do NOT use `CuratedTrigger` or `Intsvc.Trigger` activityType.** The CLI overrides to `CuratedWaitFor` (in-stage task) or emits the trigger shape directly. Trust the CLI's `essentialConfiguration` value.
 - **Do NOT hand-write JMESPath filter expressions.** Build a structured filter tree and pass it under `--input-details.filter`; the CLI compiles all three sinks.
-- **Do NOT use `filterExpression` as a `--input-details` input.** The CLI rejects raw `filterExpression` strings (MST-8802). Pass the structured tree only.
+- **Do NOT use `filterExpression` as a `--input-details` input.** The CLI rejects raw `filterExpression` strings. Pass the structured tree only.
 - **Do NOT pass `ceqlExpression` for triggers** — that's the activity-side rejection key. Triggers compile to JMESPath via the `filter` tree.
 - **Do NOT duplicate a required event-param value in the freeform `filter` tree.** The CLI AND-joins required event params into the filter expression automatically (see [planning § Mandatory-filter contract](connector-trigger-planning.md#mandatory-filter-contract-required-event-params)); duplicating the clause double-applies it and narrows event matching to a strict subset of intended events. Set required event-param values via `eventParameters` ONLY.
 - **Never reuse a reference ID from a prior case or session.** Reference IDs (mailbox folders, Slack channels, Jira projects) are scoped to the authenticated account behind each connection. Always resolve fresh via `uip is resources run list` against the current `--connection-id`. See [/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).

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

@@ -1,6 +1,6 @@
 # Connector Trigger — Shared Planning Pipeline
 
-Shared **planning** logic for connector-based triggers: TypeCache lookup, connection pick, `case spec` discovery, reference resolution, the required-param gate, SDD mapping, and input-values + filter authoring. It ends at `tasks.md`.
+Shared **planning** logic for connector-based triggers: TypeCache lookup, connection pick, `case spec` discovery, reference resolution, the required-param gate, SDD mapping, and input-values + filter authoring. It ends at `tasks/registry-resolved.json`.
 
 > **This file is half the contract.** Every JSON shape written to `caseplan.json` — the populated `caseShape` splice, placeholder substitution, binding-ID mint, the connector-bound condition-rule block, the placeholder stub, and root bindings — lives in the companion [connector-trigger-impl.md](connector-trigger-impl.md). Planning alone never produces a runnable connector node.
 
@@ -70,7 +70,7 @@ The response carries everything the planning phase needs:
 |---|---|
 | `inputs.eventParameters[]` | Trigger event params with `name`, `dataType`, `required`, `description`, optional `defaultValue` / `enum` / `reference`. The `required` flag drives the [Mandatory-filter contract](#mandatory-filter-contract-required-event-params) in Step 7 |
 | `outputs.responseFields[]` | Response shape (incoming event payload). `[?responseCurated]` are FE-broken-out outputs, `[?primaryKey]` are id fields |
-| `operation.eventMode` | `"polling"` or `"webhooks"` — authoritative source for `event-mode` in `tasks.md` |
+| `operation.eventMode` | `"polling"` or `"webhooks"` — authoritative source for `event-mode` in `registry-resolved.json` |
 | `filter` | `undefined` when the trigger does NOT support server-side filtering. Present when it does, with `builder: "jmes"` and `fields[]` listing every searchable field |
 | `references[]` | Cross-references for any event params with lookups. Each entry carries a pre-built `discoverCommand` runnable string |
 | `diagnostics.fetched` / `fallbacks` | Surface fallbacks to the user when meaningful |
@@ -92,7 +92,7 @@ Check `inputs.eventParameters[]` for entries with a `reference` object. Each car
 
 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.
 
@@ -100,7 +100,7 @@ If a reference cannot be resolved, **AskUserQuestion** with the candidates (drop
 
 ### 5. Validate required event parameters (HARD GATE)
 
-This is a hard gate — do NOT proceed to writing tasks.md until every required event parameter has a value.
+This is a hard gate — do NOT proceed to writing the resolved entry until every required event parameter has a value.
 
 1. Collect every `inputs.eventParameters[?required]` entry from the spec output.
 2. For each, check whether sdd.md names a value (literal, resolved reference id, or — in `filter:` only — a `=vars.X` runtime reference; impl compiles this to `` =js:`...${vars.X}...` `` template-literal form when writing `body.filters.expression`, see § Dynamic variable limitation).
@@ -130,9 +130,9 @@ If an SDD input matches an `eventParameters` field name, it's an event parameter
 
 `groupOperator` accepts both string (`"And"` / `"Or"`) and numeric (`0` / `1`) — the case-tool normalizes string→numeric before threading to the SDK. Use either form; the platform examples use string.
 
-The filter tree goes into `tasks.md` under `filter:` as a literal JSON object — Phase 3 passes it to `case spec --input-details.filter`. The CLI compiles it into all three trigger filter sinks (see § Trigger filter sinks below).
+The filter tree goes into `registry-resolved.json` under `filter` as a literal JSON object — Phase 3 passes it to `case spec --input-details.filter`. The CLI compiles it into all three trigger filter sinks (see § Trigger filter sinks below).
 
-No filter (trigger fires on all events): omit `filter` from the tasks.md entry entirely.
+No filter (trigger fires on all events): omit `filter` from the resolved entry entirely.
 
 #### Mandatory-filter contract (REQUIRED event params)
 
@@ -144,7 +144,7 @@ The CLI derives a "mandatory-filter expression" from **required** event-param va
 Worked example. Required param `parentFolderId` + a freeform `subject` filter:
 
 ```jsonc
-// tasks.md authored shape
+// registry-resolved.json authored shape
 {
     "input-values": { "eventParameters": { "parentFolderId": "AAMkAD..." } },
     "filter": {
@@ -169,7 +169,7 @@ After the Phase 3 `case spec --input-details` call, both filter sinks contain th
 
 The CLI's filter compiler only accepts `isLiteral: true` clauses in the FilterTree (`case-spec-input-details.md § WorkflowValue`). When a filter requires runtime case variable references, the impl step writes the canonical FE template-literal form into `body.filters.expression` (and `activityPropertyConfiguration.filterExpression`) directly post-CLI, and leaves `essentialConfiguration.filter` as `null`. This is a known SDK limitation shared with flow-tool.
 
-**Planner-side authoring contract.** When translating an SDD filter clause to the `tasks.md` FilterTree, the planner classifies each clause by value shape:
+**Resolution-side authoring contract.** When translating an SDD filter clause to the FilterTree, classify each clause by value shape:
 
 | SDD clause value | Encoded as `WorkflowValue` |
 |---|---|
@@ -189,7 +189,7 @@ Example (SDD with mixed literal + var-bearing clauses):
 filter: subject contains =vars.urgentKeyword AND from contains "VIP"
 ```
 
-Planner emits to `tasks.md`:
+Resolution emits to `registry-resolved.json`:
 
 ```json
 {
@@ -220,7 +220,7 @@ Impl composes (after CLI processes the literal-only subset):
 - Outer wrap: `` =js:`...` `` — JS prefix + template-literal backticks. The template literal evaluates at runtime to a JMESPath string.
 - Sub-clauses each wrapped in parens for operator-precedence grouping.
 - References appear as `${vars.X}` / `${metadata.X}` / `${bindings.X}` template-literal interpolations — NOT as `=vars.X` / `=metadata.X` (plain prefix doesn't get evaluated inside the body sink). All `=js:<ref>` forms get the same transformation via FE's `wrapJsVariablesInTemplateLiteral` (`IntsvcCommonUtils.ts:251-258`).
-- For each `=<prefix>.X` reference in the SDD/tasks.md filter, the impl emits `${<prefix>.X}` inside the appropriate JMESPath clause.
+- For each `=<prefix>.X` reference in the SDD/resolved filter, the impl emits `${<prefix>.X}` inside the appropriate JMESPath clause.
 
 > **String-operand quoting (mandatory).** FE's `wrapJsVariablesInTemplateLiteral` does pure substitution — `=js:vars.X` → `${vars.X}` with NO surrounding quotes added (regex at `IntsvcCommonUtils.ts:257`; behavior confirmed by `IntsvcActivityConfigurationUtils.test.ts:986` → `:996`, which asserts the substituted output is unquoted). For JMESPath string operands (`contains(field, <string>)`, `field == '<string>'`), the impl MUST emit single quotes around the `${vars.X}` substitution. For numeric / boolean / JMESPath-literal-backtick operands, no surrounding quotes. Examples:
 >
@@ -271,27 +271,30 @@ The expression is duplicated in two non-config sinks because both have load-bear
 
 ---
 
-## tasks.md fields (planning)
-
-A connector-bound rule's condition T-entry records these (alongside the scope's normal fields):
-
-```markdown
-- rule-type: wait-for-connector
-- type-id: "<uiPathActivityTypeId>"
-- connection-id: "<connection-id>"
-- connector-key: "<connector-key>"
-- object-name: "<object>"
-- event-operation: "<EVENT_OP>"
-- event-mode: "polling"               # or "webhooks"
-- input-values: { "eventParameters": { ... } }   # resolved IDs; omit when none
-- filter: { ... }                     # optional FilterTree; omit when none
-- condition-expression: "=js:vars.X..."  # optional gate on case state — NOT the event payload
-- outputs:                            # optional — bind rule outputs to case variables
-  - "<schemaField> -> <caseVar>"      # extract — rule's response field to case variable
-  - "<caseVar> = <expression>"        # assign — literal / =js: expression / =vars.X
+## registry-resolved.json fields (resolution)
+
+A connector-bound rule's condition element records these on its ledger entry (alongside the scope's normal fields):
+
+```jsonc
+{
+  "rule-type": "wait-for-connector",
+  "type-id": "<uiPathActivityTypeId>",
+  "connection-id": "<connection-id>",
+  "connector-key": "<connector-key>",
+  "object-name": "<object>",
+  "event-operation": "<EVENT_OP>",
+  "event-mode": "polling",                          // or "webhooks"
+  "input-values": { "eventParameters": {} },        // resolved IDs; omit key when none
+  "filter": {},                                     // optional FilterTree object; omit key when none
+  "condition-expression": "=js:vars.X...",          // optional gate on case state — NOT the event payload
+  "outputs": [                                      // optional — bind rule outputs to case variables
+    "<schemaField> -> <caseVar>",                   // extract — rule's response field to case variable
+    "<caseVar> = <expression>"                      // assign — literal / =js: expression / =vars.X
+  ]
+}
 ```
 
-The `outputs:` block (optional) binds the rule's `response` / `Error` to case variables — same `->` / `=` operator semantics as a connector task. Full shapes + dispatcher: [io-binding/impl-json.md § Output Binding Shapes for Connector Condition Rules](plugins/variables/io-binding/impl-json.md#output-binding-shapes-for-connector-condition-rules).
+`input-values` and `filter` are real JSON objects, not strings. The `outputs` array (optional) binds the rule's `response` / `Error` to case variables — same `->` / `=` operator semantics as a connector task. Full shapes + dispatcher: [io-binding/impl-json.md § Output Binding Shapes for Connector Condition Rules](plugins/variables/io-binding/impl-json.md#output-binding-shapes-for-connector-condition-rules).
 
 ---
 

package/skills/uipath-maestro-case/references/entry-points-sync.md

@@ -70,6 +70,7 @@ Keyed by `var.name`. Branch on `var.type`:
 |---|---|---|---|
 | `string` | `{ "type": "string" }` | yes | yes |
 | `integer` | `{ "type": "integer" }` | yes | yes |
+| `number` | `{ "type": "number" }` | yes | yes |
 | `boolean` | `{ "type": "boolean" }` | yes | yes |
 | `float` | `{ "type": "number", "format": "float" }` | yes | yes |
 | `double` | `{ "type": "number", "format": "double" }` | yes | yes |
@@ -89,7 +90,7 @@ Keyed by `var.name`. Branch on `var.type`:
   3. else `getTypeAndFormatForType(var.subType)` if `subType` is a primitive,
   4. else `{}`.
 
-> The current case-variable type enum ([`global-vars/planning.md` § Types](plugins/variables/global-vars/planning.md)) is `string | integer | float | double | boolean | datetime | date | jsonSchema | file` — no `array` or `time`. Those two rows are ported from the FE for fidelity/future-proofing; today array-shaped data arrives as `jsonSchema` with an array body (handled by the jsonSchema branch).
+> The current case-variable type enum ([`global-vars/planning.md` § Types](plugins/variables/global-vars/planning.md)) is `string | number | integer | float | double | boolean | datetime | date | jsonSchema | file` — no `array` or `time`. Those two rows are ported from the FE for fidelity/future-proofing; today array-shaped data arrives as `jsonSchema` with an array body (handled by the jsonSchema branch).
 
 ### `rewriteJobAttachmentRefs` (nested JobAttachment rewrite)
 

package/skills/uipath-maestro-case/references/evals/evals.json

@@ -4,37 +4,37 @@
         {
             "id": 1,
             "prompt": "I have an sdd.md and spec.json for a loan approval case. Generate the implementation tasks from these spec files so I can build it.",
-            "expected_output": "Skill triggers, produces a tasks.md with ordered task entries covering case creation, stages, tasks, and conditions, then stops before Phase 2 because the request is plan-only",
+            "expected_output": "Skill triggers, resolves resources into tasks/registry-resolved.json covering the SDD's stages, tasks, and conditions, then stops before Phase 2 because the request is plan-only",
             "expectations": [
                 "The case-management skill was triggered",
                 "References uip maestro case registry pull for upfront caching",
-                "Produces a tasks.md file with numbered task sections (T01, T02, etc.)",
+                "Produces a tasks/registry-resolved.json ledger with one entry per resolvable SDD resource",
                 "Includes registry lookups to resolve taskTypeIds",
                 "Generates a registry-resolved.json for audit",
-                "Stops after tasks.md without creating a solution or caseplan because the request asks only for implementation tasks"
+                "Stops after resolution without creating a solution or caseplan because the request asks only for implementation tasks"
             ]
         },
         {
             "id": 2,
             "prompt": "Break down my case spec into implementation tasks. The spec files are at ./specs/sdd.md and ./specs/spec.json",
-            "expected_output": "Skill triggers, reads both spec files, resolves registry lookups, generates tasks.md, and stops before Phase 2 because the request is plan-only",
+            "expected_output": "Skill triggers, reads both spec files, resolves registry lookups into tasks/registry-resolved.json, and stops before Phase 2 because the request is plan-only",
             "expectations": [
                 "The case-management skill was triggered",
                 "Reads both sdd.md and spec.json from the provided paths",
                 "Uses the component_type mapping to determine registry search types",
-                "Produces a tasks/ folder with tasks.md",
-                "Stops after tasks.md without creating a solution or caseplan because the request asks only for an implementation-task breakdown"
+                "Produces a tasks/ folder with registry-resolved.json",
+                "Stops after resolution without creating a solution or caseplan because the request asks only for an implementation-task breakdown"
             ]
         },
         {
             "id": 3,
             "prompt": "Convert this case specification into a step-by-step plan and build the case",
-            "expected_output": "Skill triggers, produces an actionable tasks.md, then auto-proceeds to write caseplan.json directly via the matching plugins without a Phase 1 approval prompt",
+            "expected_output": "Skill triggers, resolves resources, then auto-proceeds to write caseplan.json directly from the SDD via the matching plugins without a Phase 1 approval prompt",
             "expectations": [
                 "The case-management skill was triggered",
-                "Produces tasks.md with declarative task entries (no shell commands in tasks.md)",
+                "Produces tasks/registry-resolved.json with one entry per resolved resource",
                 "Cross-references use human-readable format like Stage.Task.field",
-                "Auto-proceeds from tasks.md into the build without asking for Phase 1 approval",
+                "Auto-proceeds from resolution into the build without asking for Phase 1 approval",
                 "Writes caseplan.json directly via plugin impl-json.md recipes"
             ]
         },
@@ -175,13 +175,13 @@
     {
       "id": 14,
       "prompt": "Design a supplier application case. Withdrawal can arrive from the supplier portal at any point. Each phase warns handlers at 70% of its SLA and, on breach, interrupts into an escalation lane that creates an operations-lead task and sends the supplier a delay note. The case has a 15-day SLA whose breach interrupts into a director-review lane before closure. In Supplier Setup, verify identity, then set the supplier record, then invite the supplier. Preserve why every stage kind, task type, activation/sequence, SLA, and routing choice was made in the SDD and implementation plan.",
-      "expected_output": "Skill models global withdrawal/SLA events as interrupting secondary-stage entries, preserves explicit sequential work with runs-sequentially, and carries durable design rationale into tasks.md",
+      "expected_output": "Skill models global withdrawal/SLA events as interrupting secondary-stage entries, preserves explicit sequential work with runs-sequentially, and carries durable design rationale into caseplan.json",
       "expectations": [
         "Withdrawal is one interrupting secondary stage entered by the supplier-portal wait-for-connector event; the skill does not repeat withdrawal tasks or exits on every primary stage",
         "The 70% at-risk warning is an SLA escalation notification; phase/case breach work uses sla-status-change entry rules on interrupting secondary stages that reference the intended SLA rules (a breach references the SLA alone; only an at-risk rule also names an escalation)",
         "The explicitly ordered Supplier Setup tasks each use runs-sequentially, are not emitted as parallel current-stage-entered tasks, and are laid out as consecutive single-task data.tasks sets rather than one parallel inner array",
         "The SDD stores design rationale for stage kind/routing, task type/activation/sequencing, and SLA behavior instead of leaving the reasons only in chat",
-        "tasks.md preserves the SDD rationale on the matching stage, task, condition, and SLA T-entries"
+        "caseplan.json preserves the SDD rationale on the matching stage, task, condition, and SLA elements"
       ]
     }
   ]