feat(uipath-maestro-case): generate the bindings sidecar with the CLI, close the plain-Valid exit, and grade the strict SDD audit

skills/uipath-maestro-case/SKILL.md

@@ -50,8 +50,8 @@
 10. **Cross-task references.** Use `"Stage Name"."Task Name".output_name` and the common output-reference-ID algorithm in [`plugins/variables/io-binding/impl-json.md`](references/plugins/variables/io-binding/impl-json.md#output-reference-id-authoritative). Use the source output’s `.id`; only a custom `=` output without `.id` uses its verified root companion’s `.id`. Never use a reassigned output’s `.var`. Discover names with `uip maestro case spec` for connector tasks or `uip maestro case tasks describe` for non-connectors. In larger `=js:` expressions use `vars.$xref('Stage','Task','output')`, resolved at Step 11.5. See [references/bindings-and-expressions.md](references/bindings-and-expressions.md).
 11. **Build-review preference.** Capture once at journey start. Design handoff folds it into the Case Review Build options (`Build it — straight through` or `Build it — pause at the build preview`); provided SDD asks once after the roadmap. Non-interactive and resumed runs without a preference default to straight-through. At Phase 2→3, try `validate --skeleton-v2`; fall back once to legacy `--skeleton` only when the response explicitly says v2 is unknown/unsupported, typically invalid_argument/exit 3. Exit 3 alone is insufficient; real v2 failures are reported. Validation findings do not halt this advisory gate. Straight-through continues without prompting. Pause-at-preview follows [references/phased-execution.md](references/phased-execution.md): AskUserQuestion `Publish for review` / `Skip publish and continue` / `Abort`; on publish, refresh resources, upload with the required filter, print `DesignerUrl` before the follow-up, then ask `Continue to implementation` / `Abort`. Hard stops always remain at Phase 4 retry exhaustion, Phase 5, Phase 6, Phase 7, and any re-publish after a Phase 6 fix.
 12. **Never auto-debug or publish to Orchestrator.** `uip maestro case debug` executes real emails, messages, and API calls. Phase 7 (`case pack` → `solution pack` → `solution publish`) ships to the tenant. Each requires its own AskUserQuestion consent.
-13. **Artifact I/O.** For `caseplan.json`, `sdd.md`, `sdd.draft.md`, `tasks/registry-resolved.json`, `tasks/trigger-spec-cache.json`, `tasks/spec-cache.<elementId>.json`, `bindings_v2.json`, `id-map.json`, `entry-points.json`, and `build-issues.md`, use only your harness's file tools: `cat <file>` (or the Read tool, if the harness has one) to read, and Write / Edit (or `apply_patch`) to mutate. No Python, Node, jq, sed, awk, scripts, shell redirection, `tee`, `cp`, `mv`, `install`, or `rsync`; no helper scripts, including under `/tmp`, and no agent-authored script of any kind. **Exception — a read-only audit gate is allowed, not banned:** the planner's `audit_sdd.py` run over `sdd.md` writes nothing and only reports, so running it is always allowed. This rule exists to stop an artifact being AUTHORED or EDITED by script — never to stop it being CHECKED; the caseplan's own check is `uip maestro case validate --strict --sdd` (Rule 14). The `node -e ... fs.*` ban covers all file reads, including `~/.uip/case-resources/`; use `cat` (or Read) for cache lookup. If `caseplan.json` exceeds about 30KB, use the preview/detail cadence in [case-editing-operations.md](references/case-editing-operations.md), never a helper. Bash is allowed only for `cat`, UUID v4 generation without filesystem access, CLI metadata, validate, debug, and solution scaffold/upload. Prefixed IDs are chosen inline.
-14. **Runnable resources and sidecars.** Before Phase 4, run Step 12 Checks 7, 9, 11, and 12 even when publish, debug, or resource refresh is skipped. A non-null `selected` resource must not become a placeholder: retain `data.name` and `data.folderPath` with complete root bindings, project it into `bindings_v2.json.resources[]`, and make its `resourceKey` self-consistent with its own defaults, never a copied tenant identity/UUID. Checks 9/11 exempt connector nodes; Check 12 covers resolved connector tasks, event triggers, and `wait-for-connector` rules, which require spliced `caseShape.context` plus Connection/Folder root bindings, not degraded typeId/connectionId-only data. CLI validate on the default profile is insufficient: the closing validate at Phase 3 exit and in Phase 4 is `uip maestro case validate <caseplan.json> --strict --sdd sdd.md --output json` (`--sdd` implies `--strict` and audits completeness against the SDD; omit it only when no `sdd.md` exists), and a `Valid` without `"Profile": "strict"` does not close the build. **Version guard:** `--strict`/`--sdd` exist from CLI 1.202. Fall back to plain `validate` only when the response is `invalid_argument` naming `--strict` or `--sdd` as an unknown option (exit 3 alone is insufficient; a strict *failure* is never a reason to drop the flags). On fallback, record `strict profile unavailable on CLI <version>` in `build-issues.md` and in the completion report, and run Step 12 Checks 1–15 by hand. Repair and recheck mismatches; halt before Phase 4 if they remain. Repeat Check 7 before every `resources refresh`. Refresh before every upload or debug. Every `solution upload` uses `--output-filter "{Status: Status, Action: Action, SolutionId: SolutionId, DesignerUrl: DesignerUrl}"`; print the returned DesignerUrl and say whether `Action` was `Imported` or `Overwritten`.
+13. **Artifact I/O.** For `caseplan.json`, `sdd.md`, `sdd.draft.md`, `tasks/registry-resolved.json`, `tasks/trigger-spec-cache.json`, `tasks/spec-cache.<elementId>.json`, `id-map.json`, `entry-points.json`, and `build-issues.md`, use only your harness's file tools (`bindings_v2.json` is the exception: `uip maestro case bindings sync` generates it; never write it by hand): `cat <file>` (or the Read tool, if the harness has one) to read, and Write / Edit (or `apply_patch`) to mutate. No Python, Node, jq, sed, awk, scripts, shell redirection, `tee`, `cp`, `mv`, `install`, or `rsync`; no helper scripts, including under `/tmp`, and no agent-authored script of any kind. **Exception — a read-only audit gate is allowed, not banned:** the planner's `audit_sdd.py` run over `sdd.md` writes nothing and only reports, so running it is always allowed. This rule exists to stop an artifact being AUTHORED or EDITED by script — never to stop it being CHECKED; the caseplan's own check is `uip maestro case validate --strict --sdd` (Rule 14). The `node -e ... fs.*` ban covers all file reads, including `~/.uip/case-resources/`; use `cat` (or Read) for cache lookup. If `caseplan.json` exceeds about 30KB, use the preview/detail cadence in [case-editing-operations.md](references/case-editing-operations.md), never a helper. Bash is allowed only for `cat`, UUID v4 generation without filesystem access, CLI metadata, validate, `format`, `bindings sync`, debug, and solution scaffold/upload. Prefixed IDs are chosen inline. **Write `caseplan.json` pretty-printed — 2-space indentation, one key per line, no line over ~200 characters — from the T01 scaffold onward.** A compact plan cannot be patched by Edit/`apply_patch` (hunks need distinct context lines), and every observed `perl -pi`/`sed -i` violation of this rule started from a compact file. After every write of `caseplan.json`, run `uip maestro case format "<caseplan.json path>" --output json`: it rewrites the file pretty-printed in place, is idempotent (`Changed: false` on a second run), and refuses an unparseable file untouched — it is the only sanctioned reformat.
+14. **Runnable resources and sidecars.** Before Phase 4, run Step 12 Checks 7, 9, 11, and 12 even when publish, debug, or resource refresh is skipped. A non-null `selected` resource must not become a placeholder: retain `data.name` and `data.folderPath` with complete root bindings, regenerate the sidecar with `uip maestro case bindings sync`, and make its `resourceKey` self-consistent with its own defaults, never a copied tenant identity/UUID. Checks 9/11 exempt connector nodes; Check 12 covers resolved connector tasks, event triggers, and `wait-for-connector` rules, which require spliced `caseShape.context` plus Connection/Folder root bindings, not degraded typeId/connectionId-only data. CLI validate on the default profile is insufficient: the closing validate at Phase 3 exit and in Phase 4 is `uip maestro case validate <caseplan.json> --strict --sdd sdd.md --output json` (`--sdd` implies `--strict` and audits completeness against the SDD; omit it only when no `sdd.md` exists), and a `Valid` without `"Profile": "strict"` does not close the build. Section-end validates in Phases 2–3 use the plain profile (a half-built plan fails strict by design); the Phase 3 exit and every Phase 4 validate carry `--strict --sdd sdd.md`, and no plain-profile result after Phase 3 entry is ever quoted as a close. Run the strict validate alone — never chained with another validate in one command: two envelopes on one stdout get read as the first one. **Version guard:** `--strict`/`--sdd` exist from CLI 1.202. Fall back to plain `validate` only when the response is `invalid_argument` naming `--strict` or `--sdd` as an unknown option (exit 3 alone is insufficient; a strict *failure* is never a reason to drop the flags). On fallback, record `strict profile unavailable on CLI <version>` in `build-issues.md` and in the completion report, and run Step 12 Checks 1–15 by hand. Repair and recheck mismatches; halt before Phase 4 if they remain. Repeat Check 7 before every `resources refresh`. Refresh before every upload or debug. Every `solution upload` uses `--output-filter "{Status: Status, Action: Action, SolutionId: SolutionId, DesignerUrl: DesignerUrl}"`; print the returned DesignerUrl and say whether `Action` was `Imported` or `Overwritten`.
 15. **Handoff contract.** Invoke `uipath-planner`’s Case Design Lane in this conversation, never as a subagent. It owns design, resolution, review, and SDD writing; this skill resumes at solution initialization. User-facing language presents one continuous flow and never mentions the handoff. If unavailable, say so in one line, request `sdd.md` or an approved pasted design, and stop. Cross-product planning remains a plain-text suggestion to the planner. Apply the Rule 15 receipt spot-check before unobserved SDD reads.
 16. **Closed task types.** `caseplan.json` task `type` must be exactly one of: `process`, `agent`, `rpa`, `action`, `api-workflow`, `case-management`, `execute-connector-activity`, `wait-for-connector`, `wait-for-timer`. Never use plugin folder or CLI names, `external-agent`, `external-workflow`, `document-extraction`, `flow-process`, `wait-for-event`, or other invented values. The unsupported types remain unsupported. See [references/case-schema.md](references/case-schema.md) and the Plugin Index.
 17. **Empty lookup gate.** If the same-session ledger has a user `gateDecision`, execute it without asking again: `resolve-at-build` → placeholder; `create-during-build` → inline create; `pick:<name>` → bind it. A missing decision is a default deferral, not consent; run the full gate. For zero matches, use one batched AskUserQuestion grouped by `(name,type)` with: `Force pull and re-resolve`; `Use placeholders for all`; and, only when creatable resources exist and `registry --local` is supported, `Create missing resources inline`. Create only selected `agent` or `api-workflow` resources, invoking `uipath-agents` or `uipath-api-workflow`; never infer Create from SDD content. Other empty types remain placeholder-only. Selected resources with identical I/O may share one build; differing I/O splits later with the anchor retaining the name, and SDD updates require permission. See [registry-discovery.md § 1c](references/registry-discovery.md#1c--dedup-the-selected-builds-one-resource-per-name-and-type), [Create-on-Missing](references/registry-discovery.md#create-on-missing-build-and-rediscovery), and [§ MUST Confirm](references/registry-discovery.md#must-confirm-before-placeholder-fallback).

skills/uipath-maestro-case/references/bindings-and-expressions.md

@@ -21,7 +21,7 @@ When using the literal/expression mode, the `--value` string can start with one
 
 | Prefix | Meaning | Example |
 |--------|---------|---------|
-| `=metadata.` | Case metadata field — closed schema, see [case-schema.md § 1](case-schema.md#1-top-level--metadata). NOT for arbitrary SDD "Case Metadata" business fields (e.g. Priority) — those are case variables, use `=vars.<id>` | `=metadata.ExternalId` |
+| `=metadata.` | Runtime case metadata — exactly four fields: `FolderKey`, `ProcessKey`, `InstanceId`, `ExternalId`; anything else reads `undefined` at runtime. NOT for arbitrary SDD "Case Metadata" business fields (e.g. Priority) — those are case variables, use `=vars.<id>` | `=metadata.ExternalId` |
 | `=js:` | Inline JavaScript expression | `=js:new Date().toISOString()` |
 | `=vars.` | Case-level variable | `=vars.inbox_config` |
 | `=bindings.` | Resource binding (connection, queue, trigger) | `=bindings.slackConnection` |
@@ -96,7 +96,7 @@ A task output is `null` until its task runs — and stays null when its task is
 
 The lookup-path resolver has NO `=metadata.` branch — plain `=metadata.X` is NOT resolved at runtime. **Always wrap as `=js:metadata.X`** (or `=js:(metadata.X)` if the sink requires parens). The FE design-time picker may classify `=metadata.X` as "variable" type, but that's a UI hint, not a runtime contract.
 
-`metadata.X` is a **closed field set** — see [case-schema.md § 1](case-schema.md#1-top-level--metadata) for the full list (`caseIdentifier`, `slaRules`, `caseExitRules`, …) plus the platform-only runtime field `metadata.ExternalId`. It is NOT a namespace for arbitrary business data. A field the SDD's "Case Metadata" table lists for human-readability (e.g. `Priority`) is authored as a **case variable**, not a `metadata` key — reference it as `=js:vars.priority`, never `=js:metadata.priority` (which resolves to `undefined`).
+`metadata.X` in an expression is a **closed runtime field set** of exactly four: `metadata.FolderKey`, `metadata.ProcessKey`, `metadata.InstanceId`, `metadata.ExternalId`. The disk-schema `metadata` block in [case-schema.md § 1](case-schema.md#1-top-level--metadata) (`caseIdentifier`, `slaRules`, `caseExitRules`, …) is authoring configuration and is not readable from expressions. It is NOT a namespace for arbitrary business data. A field the SDD's "Case Metadata" table lists for human-readability (e.g. `Priority`) is authored as a **case variable**, not a `metadata` key — reference it as `=js:vars.priority`, never `=js:metadata.priority` (which resolves to `undefined`).
 
 ### Planner-emit form
 

skills/uipath-maestro-case/references/bindings-v2-sync.md

@@ -20,14 +20,17 @@
 
 ## § Regenerate bindings_v2.json
 
-After writing bindings to top-level `bindings[]`, regenerate `bindings_v2.json`. This file uses a **different format**: `caseplan.json` stores two entries per resource (one per property), `bindings_v2.json` stores one entry per resource with properties nested under `value`.
+After writing bindings to top-level `bindings[]`, run:
 
-### Procedure
+```bash
+uip maestro case bindings sync "<SolutionDir>/<ProjectName>/caseplan.json" --output json
+```
+
+It reads the root `bindings[]`, groups entries by `resourceKey`, and writes `bindings_v2.json` next to the plan (full overwrite). Response `Data`: `BindingsPath`, `ResourceCount`, `ConnectionCount`. **Never author or edit `bindings_v2.json` by hand** — a hand-written sidecar with the wrong field names is invisible to `solution resources refresh` and fails silently at deploy. If the installed CLI has no `bindings sync` command, derive the file from the shapes below as a last resort and say so in the completion report.
+
+### What the command emits
 
-1. Read top-level `bindings[]` from `caseplan.json`
-2. Group bindings by `resourceKey` — entries sharing the same key belong to one resource
-3. For each group, produce one resource entry using the shapes below
-4. Write the full file (always overwrite, never append) to `<SolutionDir>/<ProjectName>/bindings_v2.json`
+`caseplan.json` stores two entries per resource (one per property); `bindings_v2.json` stores one entry per resource with properties nested under `value`. Reference only — the shapes are here so Check 7 can be understood, not so they can be typed.
 
 ### Non-connector resource entry
 

skills/uipath-maestro-case/references/case-commands.md

@@ -61,7 +61,7 @@
 | `<ProjectName>` | **(required)** Project directory name. Created inside the current directory |
 
 <!--skill-flavor:cd-mandatory-note:start-->
 > **The `cd <SolutionDir>` is mandatory; `&&`-chaining after `uip solution init` does NOT satisfy it.** `solution init` makes `<SolutionDir>` a *child* of cwd, so `uip solution init X && uip maestro case init X` still runs `case init` outside the new solution — with the auto-scaffold consequences described below.
 <!--skill-flavor:cd-mandatory-note:end-->
 
 <!--skill-flavor:case-init-semantics:start-->
@@ -206,7 +206,6 @@
 ```bash
 uip maestro case validate <file> --strict --sdd sdd.md --output json
 uip maestro case validate <file> --strict --output json
-uip maestro case validate <file> --output json
 uip maestro case validate <file> --skeleton-v2 --output json
 uip maestro case validate <file> --skeleton --output json
 ```
@@ -231,6 +230,34 @@
 
 ---
 
+## uip maestro case format
+
+Rewrite `caseplan.json` pretty-printed in place (2-space indentation, one key per line). Run after every write of the plan; it is the only sanctioned reformat (Rule 13).
+
+```bash
+uip maestro case format <file> --output json
+```
+
+| Flag | Description |
+|------|-------------|
+| `<file>` | **(required)** Path to the case management JSON file |
+
+Output: `Data.Changed` — `true` when the file was rewritten, `false` when already formatted (idempotent). An unparseable file is refused and left untouched. Key order is preserved; a number re-renders in shortest form and a duplicate key collapses to its last occurrence, which is JSON round-trip behaviour and not corruption. Same verb family as `maestro flow format` and `maestro bpmn format`.
+
+---
+
+## uip maestro case bindings sync
+
+Derive `bindings_v2.json` from the plan's root `bindings[]` and write it next to the plan. Never author or edit the sidecar by hand.
+
+```bash
+uip maestro case bindings sync <caseplan.json> --output json
+```
+
+Output: `Code: CaseBindingsSync` with `Data.BindingsPath`, `Data.ResourceCount`, `Data.ConnectionCount`. `ResourceCount: 0` is still `Result: Success` — an empty sidecar is a faithful derivation of a plan that binds nothing, so the gate is `validate --strict` (`STRICT_BINDINGS_ABSENT`), not the sync result. See [bindings-v2-sync.md](bindings-v2-sync.md).
+
+---
+
 ## uip maestro case debug
 
 Debug a Case JSON file via a Studio Web debug session. **Requires `uip login`. Executes the case for real — sends emails, posts messages, calls APIs. Only run on explicit user consent.**

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

@@ -103,7 +103,7 @@ After splicing the spec subtree (`context` / `inputs` / `outputs` and their nest
 
 ### Step 5 — Mint `var` / `id` / `elementId` on inputs and outputs
 
-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).
+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). The target's `data.inputs` is the spliced `CaseShape.Inputs` — every envelope entry the spec returns, each with its `Body` object — never `[]`: a `wait-for-connector` or `execute-connector-activity` task with empty `inputs` passes validate and fails at runtime, and it has been the last miss on three otherwise-complete golden builds.
 
 Conventions (shared with activity):
 - **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`

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

@@ -86,7 +86,7 @@
     "objectName": "MailFolder",
     "lookupValue": "id",
     "lookupNames": ["displayName"],
     "discoverCommand": "uip is resources run list uipath-microsoft-outlook365 MailFolder --connection-id <id>"
 }
 ```
 
@@ -277,7 +277,7 @@
 
 ```jsonc
 {
-  "rule-type": "wait-for-connector",
+  "rule-type": "wait-for-connector",   // ledger field only; the caseplan rule object is keyed "rule"
   "type-id": "<uiPathActivityTypeId>",
   "connection-id": "<connection-id>",
   "connector-key": "<connector-key>",