@uipath/skills 1.197.2 → 1.198.0-preview.21

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

@@ -0,0 +1,204 @@
+# entry-points.json Input/Output Refresh
+
+Refresh `entry-points.json` `entryPoints[].input` / `.output` JSON-Schemas from the declared case In/Out arguments. The entry-point `input`/`output` is the case's external-caller contract — the typed arguments another process/case passes in and reads back.
+
+Trigger plugins scaffold ([`plugins/case/impl-json.md`](plugins/case/impl-json.md)) and append ([`plugins/triggers/*/impl-json.md`](plugins/triggers/manual/impl-json.md)) each entry with **empty** `input`/`output` (`{ "type": "object", "properties": {} }`) at Step 6.1 — variables don't exist yet. This step back-fills them once variables are declared. No trigger-plugin change: empty-at-emit is correct.
+
+> **This is a direct port of the Studio Web canvas transformation.** Source: `PO.Frontend/src/utils/PackagingUtil.ts` — `getEntryPoints()`, `getEntryPointJsonSchemaForVariable()`, `getTypeAndFormatForType()`, and the `JOB_ATTACHMENTS_DEFINITION` constant; variable extraction in `src/services/uipath/variables/VariableUtil.ts` (`getVariablesDefinedInRootUiPath`). The FE runs this on every canvas save and (since PR #6062, `always save canvas file on canvas load`) on first load, regenerating `entry-points.json` from the case variables. The skill produces the same file directly.
+
+## When to Run
+
+**Phase 2 Step 6.3** — immediately after Step 6.2 (variable declaration). One run. Both prerequisites complete:
+
+- all `entryPoints[]` entries exist (Step 6.1 triggers),
+- all In/Out formal args exist (Step 6.2 variables Loop B).
+
+In/Out formal args (`variables.inputs[]` / `outputs[]`) are final at 6.2 — Phase 3 never adds or renames them (the uniqueness rule suffixes `var`/`id`, never `name`, and this step keys on `name`). Running at 6.3 keeps the Phase-2 publish-for-review artifact correct.
+
+Re-run on regenerate-from-scratch (Rule 6). Idempotent — full recompute, never append.
+
+**Check 6** (end of Phase 3, [`implementation.md` § Step 12](implementation.md)) re-verifies parity as cheap insurance.
+
+## Source → target
+
+| Entry-point field | Source (`getEntryPoints`) | Scope |
+|---|---|---|
+| `input` | `variables.inputs[]` | only In-args whose `elementId` == THIS entry's trigger id (= `filePath` after `#`) |
+| `output` | `variables.outputs[]` | ALL Out-args → every entry |
+
+NOT projected: `variables.inputOutputs[]` root state and trigger-payload `Variable`s. Only formal In/Out args reach the contract.
+
+**Out-arg field sourcing.** The FE reads `default`/`required`/`body` directly off the in-memory output Variable. On disk those fields are split: `variables.outputs[]` carries only `{id,name,type,var}`; the matching `inputOutputs[]` companion (same `name`, `elementId:"root"`) carries `default`/`required`/`body`. So treat each Out-arg as its `outputs[]` entry **merged with its `inputOutputs[]` companion** (matched by `name`). In-args need no merge — `variables.inputs[]` already carries `default`/`required`/`body`.
+
+## Procedure
+
+1. Read `caseplan.json` (`variables.inputs[]`, `variables.outputs[]`, `variables.inputOutputs[]`) and `entry-points.json`.
+2. For each entry in `entryPoints[]`:
+   - `triggerId` = `filePath` substring after the last `#`.
+   - `entry.input`  = projectSchema(`inputs[]` where `elementId === triggerId`).
+   - `entry.output` = projectSchema(Out-args from all `outputs[]`, each merged with its companion).
+   - Preserve `filePath`, `uniqueId`, `type`, `displayName` verbatim. `displayName` is FE-derived (`getElementLabel`) but the trigger plugin already set it — the refresh does NOT recompute it, only the `input`/`output`. Mint NO `uniqueId` (`uniqueId` == the BPMN start-event `entryPointId` GUID; a pure refresh keeps it).
+   - `isTransactionRoot: true` is emitted by the FE only when `root.data.isTransactionRoot` is set. The case skill does not set it today; if a future entry carries it, preserve it — never strip.
+3. Preserve top-level `$schema`, `$id`. Write the whole file with **4-space indent** (matches the trigger recipe — no whitespace churn).
+
+> **FE entry set ≡ existing `entryPoints[]`.** `getEntryPoints` emits an entry only for a BPMN start event that (a) has an `entryPointId` and (b) is not inside a `bpmn:SubProcess`. In the skill these map 1:1 to the entries the trigger plugin already created (each case trigger is a top-level start event with a minted `uniqueId`/`entryPointId`). So iterating existing `entryPoints[]` is equivalent — the refresh creates none and drops none. (Case triggers are never inside a subprocess, so the SubProcess guard never excludes one.)
+
+Never append `entryPoints[]` entries here — entries are owned by the trigger plugins (Step 6.1).
+
+### projectSchema(vars) → schema object
+
+Mirrors `getEntryPointJsonSchemaForVariable`:
+
+- **Empty set** (`vars.length === 0`) → `{ "type": "object", "properties": {} }`. No `required`, no `definitions`. (This is exactly the scaffold/trigger empty shape — correct when a trigger has no In-args, or a case has no Out-args.)
+- **Non-empty** →
+
+```json
+{ "type": "object", "properties": { /* one per var, source order */ }, "required": [ /* see below */ ], "definitions": { /* only if needed */ } }
+```
+
+Object key order: `type`, `properties`, `required`, then `definitions`.
+
+- **`properties`** — one entry per var, in source-array order, keyed by `var.name` (NOT `id`/`var`). Body per the type rules below.
+- **`required`** — `var.name` for every var with `required === true`, in source order (`variables.filter(v => v.required)`). **No type exclusion** — `jsonSchema`/`file`/etc. all qualify. The FE UI permits marking any start-event **input** required regardless of type (`canMarkRequired = isStartEvent && variableType === "input"`, `InputOutputVariablesAddNewDialog.tsx:148`), and `required` is preserved through every serialization stage for all types (no per-type branch; repo round-trip test `xml-serialization.test.ts:2657`). Confirmed against a re-saved `test_in_out` FE export: `input.required` = `["test_date","test_file","test_json"]` — the `jsonSchema` var `test_json` **is** included. (An earlier export of the same case omitted it only because `entry-points.json` hadn't been regenerated after `test_json` was marked required — the staleness PR #6062 addresses; re-saving produced the correct array.) Include every `.required` var, regardless of type.
+- **`definitions`** — present only when a `file`-typed var, or a `jsonSchema`/`array` body that contained a JobAttachment schema, was projected (the `shouldAddJobAttachmentsDefinition` flag). Value = the constant `JOB_ATTACHMENTS_DEFINITION` block below.
+
+### Per-variable property body
+
+Keyed by `var.name`. Branch on `var.type`:
+
+| `type` | property body | `title` | `default` |
+|---|---|---|---|
+| `string` | `{ "type": "string" }` | yes | yes |
+| `integer` | `{ "type": "integer" }` | yes | yes |
+| `boolean` | `{ "type": "boolean" }` | yes | yes |
+| `float` | `{ "type": "number", "format": "float" }` | yes | yes |
+| `double` | `{ "type": "number", "format": "double" }` | yes | yes |
+| `date` | `{ "type": "string", "format": "date" }` | yes | yes |
+| `datetime` | `{ "type": "string", "format": "date-time" }` | yes | yes |
+| `time` | `{ "type": "string", "format": "time" }` | yes | yes |
+| `file` | `{ "$ref": "#/definitions/job-attachment" }` | no | no |
+| `jsonSchema` | inlined body (see below) | no | no |
+| `array` | `{ "type": "array", "items": <items>, "title": <name> }` (see below) | yes | no |
+
+- **scalar / date / datetime / time / float / double** (the `getTypeAndFormatForType` path) — emit `{ <type>, <format?> }`, then append `"title": <var.name>` (always), then `"default": <var.default>` **only when `var.default` is truthy** (verbatim string — never coerced; `""`/absent → omit). Property body key order: `type`, `format`, `title`, `default`. **Fallback:** any `type` not matched above (i.e. not double/float/date/datetime/time and not file/jsonSchema/array) falls through to bare `{ "type": <rawType> }` — string/integer/boolean today, and any future enum value degrades to `{type}` rather than failing.
+- **`file`** — `{ "$ref": "#/definitions/job-attachment" }` only. Sets the definitions flag. No `title`/`default`.
+- **`jsonSchema`** — `body = var.body ?? var._jsonSchema`. **Fallback:** if `body` is null/absent, or (when a string) fails `JSON.parse`, the property is `{}` (empty object — no schema, no title/default). Otherwise: parse if string, delete its `$schema` key, run `rewriteJobAttachmentRefs`, inline the result. No `title`/`default`.
+- **`array`** — `{ "type":"array", "items": <items>, "title": <var.name> }` (title always; no default). `body = var.body` parsed if string (unparseable → `{}`, so `body?.items` is absent and resolution falls to `subType`). `<items>` =
+  1. `rewriteJobAttachmentRefs(body.items)` if `body?.items` exists,
+  2. else `{ "$ref": "#/definitions/job-attachment" }` if `var.subType` is `file`/`octet-stream` (sets definitions flag),
+  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).
+
+### `rewriteJobAttachmentRefs` (nested JobAttachment rewrite)
+
+Used by the `jsonSchema` and `array` branches to normalize a file embedded inside a schema. Walk the schema node:
+
+- Non-object / null → returned unchanged.
+- A node carrying `"x-uipath-resource-kind": "JobAttachment"` → replaced with `{ "$ref": "#/definitions/job-attachment" }`; sets the definitions flag.
+- A node already equal to `{ "$ref": "#/definitions/job-attachment" }` → kept; sets the flag (counts as a match).
+- Object/array → recurse into children, **except** the `definitions` and `$defs` keys, which are left as-authored (no recursion). If no descendant matched, the original node is returned unchanged (identity preserved).
+
+So a `jsonSchema`/`array` body whose items or properties include a JobAttachment schema gets those occurrences rewritten to `$ref` and triggers the input/output-level `definitions` block — same mechanism as a top-level `file` var.
+
+### `JOB_ATTACHMENTS_DEFINITION` (constant)
+
+Emit verbatim. Note the inner quotes in `MimeType.description` — reproduce exactly (this matches the FE constant; a divergent `description` triggers FE re-save drift):
+
+```json
+{
+    "job-attachment": {
+        "type": "object",
+        "properties": {
+            "ID": { "type": "string", "description": "Orchestrator attachment key" },
+            "FullName": { "type": "string", "description": "File name" },
+            "MimeType": { "type": "string", "description": "The MIME type of the content, such as \"application/json\" or \"image/png" },
+            "Metadata": { "type": "object", "description": "Dictionary<string, string> of metadata", "additionalProperties": { "type": "string" } }
+        },
+        "required": ["ID"],
+        "x-uipath-resource-kind": "JobAttachment"
+    }
+}
+```
+
+Fixed constant — NOT sourced from the file var's `body` (the FE emits it even when the var carries no `body`).
+
+## FE branch coverage (audit)
+
+Every conditional in the FE source (`PackagingUtil.ts`) and where this doc handles it:
+
+| FE function / branch | Handled |
+|---|---|
+| `getEntryPoints`: start event **has** `entryPointId` | → one entry (≡ existing `entryPoints[]`) |
+| `getEntryPoints`: **no** `entryPointId` | → no entry (skill never creates an entry without a minted `uniqueId`) |
+| `getEntryPoints`: start event inside `bpmn:SubProcess` | → skipped (N/A — case triggers are top-level) |
+| `getEntryPoints`: `displayName` truthy / falsy | preserved as-is (not recomputed) |
+| `getEntryPoints`: `isTransactionRoot` set / unset | preserved if present; skill doesn't set it |
+| `getEntryPoints`: input scoped `elementId === startNode.id`; output = all | Source → target |
+| `getEntryPointJsonSchemaForVariable`: empty var set | `{type:object,properties:{}}` — no `required`/`definitions` |
+| …non-empty | `properties` + `required` (+ `definitions` if flagged) |
+| …`required = vars.filter(v=>v.required)` | required rule — no type exclusion |
+| per-var: `jsonSchema` body present | inline (strip `$schema`, rewrite) |
+| per-var: `jsonSchema` body null / unparseable | property `{}` |
+| per-var: `file` | `$ref` + definitions flag |
+| per-var: `array` (4 item fallbacks) | array bullet |
+| per-var: scalar / date / datetime / time / float / double | scalar bullet + type table |
+| per-var: type not matched anywhere | bare `{type:<raw>}` passthrough |
+| `getTypeAndFormatForType`: double/float, date, datetime, time, else | type table |
+| `rewriteJobAttachmentRefs`: non-object, JobAttachment, existing `$ref`, recurse (skip `definitions`/`$defs`), no-match identity | `rewriteJobAttachmentRefs` subsection |
+| `default` emitted iff `variable.default` truthy (verbatim) | scalar bullet |
+| Out-arg `default`/`required`/`body` from companion | Out-arg field sourcing |
+
+## Check 6 — Entry-point schema parity (Step 12 validator)
+
+Non-HALT. For each entry in `entryPoints[]` (`triggerId` = `filePath` after `#`):
+
+1. `input` == projectSchema(`inputs[]` where `elementId == triggerId`); `output` == projectSchema(Out-args). Compare keys, type/format mapping, `$ref` for `file`, inlined body for `jsonSchema`, `title`/`default` presence, the empty-set `{type,properties:{}}` (no `required`) shape, and `definitions` presence.
+2. `required` == names of all vars with `required === true` (no type exclusion).
+3. **Uniqueness guard** — `filePath` `#`-fragments unique across `entryPoints[]`. The trigger append is blind — a re-run duplicates an entry; the refresh propagates schemas to duplicates but cannot dedup (that is trigger-plugin identity).
+4. **Orphan guard** — every `inputs[].elementId` matches some entry's trigger fragment (an orphaned In-arg projects into no entry and silently vanishes from the contract).
+
+On a (1)/(2) mismatch → re-run the Procedure (deterministic recompute), re-check once. On a (3)/(4) finding or still-divergent (1)/(2) → log to `## Open Items for User` in `tasks/build-issues.md`, continue. Never HALT (build-with-best policy, [`implementation.md` § Step 12](implementation.md)).
+
+## Worked example
+
+`variables.inputs[]` (all `elementId: trigger_1`): `test_date` (datetime, default `"2029-10-12"`, `required:true`), `test_arrary` (jsonSchema, body `{"$schema":…,"type":"array","items":{"type":"string"}}`), `test_default` (float, default `"12.0"`), `test_date_time` (datetime, default `""`), `test_file` (file, `required:true`), `test_json` (jsonSchema, body `{"$schema":…,"type":"object","properties":{…},"required":[]}`, `required:true`). `variables.outputs[]`: `test_out` (double); its `inputOutputs[]` companion default `"1.3"`.
+
+Entry `/content/caseplan.json.bpmn#trigger_1`:
+
+```json
+"input": {
+    "type": "object",
+    "properties": {
+        "test_date": { "type": "string", "format": "date-time", "title": "test_date", "default": "2029-10-12" },
+        "test_arrary": { "type": "array", "items": { "type": "string" } },
+        "test_default": { "type": "number", "format": "float", "title": "test_default", "default": "12.0" },
+        "test_date_time": { "type": "string", "format": "date-time", "title": "test_date_time" },
+        "test_file": { "$ref": "#/definitions/job-attachment" },
+        "test_json": { "type": "object", "properties": { "test": { "type": "string" }, "newProperty2": { "type": "boolean" } }, "required": [] }
+    },
+    "required": ["test_date", "test_file", "test_json"],
+    "definitions": { "job-attachment": { "...": "constant block above" } }
+},
+"output": {
+    "type": "object",
+    "properties": {
+        "test_out": { "type": "number", "format": "double", "title": "test_out", "default": "1.3" }
+    },
+    "required": []
+}
+```
+
+Notes: `test_arrary`/`test_json` inline their body minus `$schema` (no `title`/`default`). `test_file` → `$ref`, and triggers the `input`-level `definitions` block. `test_date_time`'s empty default is omitted. `test_json` (jsonSchema, `required:true`) **is** included in `input.required` — confirmed against a re-saved `test_in_out` FE export (`["test_date","test_file","test_json"]`).
+
+## Multi-trigger distribution (confirmed)
+
+A `test_in_out` re-saved with two triggers — `trigger_1` (primary) and `StartEvent_Trigger_OkGfLw` (Trigger 2) — produces **two** entries, confirming the scoping rule from a real FE export:
+
+| entry (`filePath#`) | `input.properties` (scoped by `elementId`) | `output.properties` (all) |
+|---|---|---|
+| `trigger_1` | trigger_1's In-args (`test_date` … `test_intput_t1_bool`) | `test_out`, `test_out_t2` |
+| `StartEvent_Trigger_OkGfLw` | **only `test_t2_in_var`** | `test_out`, `test_out_t2` |
+
+Each entry's `input` carries only the In-args whose `elementId` is that trigger; **every** entry carries **all** Out-args. An In-arg bound to a trigger with no entry — e.g. one still pointing at a `preview-node-id` ghost node (an uncommitted canvas preview that leaked into `caseplan.json`) — matches no entry and is silently dropped from the contract; the `elementId` filter skips it (Check 6's orphan guard catches it).

package/skills/uipath-maestro-case/references/implementation.md

@@ -2,6 +2,8 @@
 
 Execute approved `tasks.md` plan, building `caseplan.json` via direct JSON edits per plugin. Validate, then optionally debug and publish. Five phases: **Phase 2 Prototyping** → **Phase 3 Implementation** → **Phase 4 Validate** → **Phase 5 Debug** → **Phase 6 Publish**.
 
+> **Editing an existing case?** Targeted edits to an existing `caseplan.json` skip this execution pipeline — see [brownfield.md](brownfield.md).
+
 > **Prerequisite:** User must have explicitly approved `tasks.md` from [Phase 1 Planning](planning.md) before starting.
 >
 > **Input:** `tasks/tasks.md` — the complete handoff artifact.
@@ -61,10 +63,11 @@ Before Step 6, seed TodoWrite with the section-level items below. Mark each `in_
 1. Scaffold solution + project + root case (Step 6)
 2. Add triggers (Step 6.1)
 3. Declare variables + arguments (Step 6.2)
-4. Add stages (Step 7)
-5. Write task shapes (Step 9)
-6. Regenerate bindings_v2.json (Step 9.4)
-7. Skeleton validate + hard stop (Step 9.5)
+4. Refresh entry-points.json input/output (Step 6.3)
+5. Add stages (Step 7)
+6. Write task shapes (Step 9)
+7. Regenerate bindings_v2.json (Step 9.4)
+8. Skeleton validate + hard stop (Step 9.5)
 
 (No edge step — edges are retired; stage transitions are condition-driven and written in Phase 3 Step 10.)
 
@@ -80,7 +83,7 @@ Steps 6 through 9.5 build structural skeleton: solution, project, root case, glo
 
 The case file must live inside a solution + project. The case plugin owns project scaffolding **and** the root caseplan write. Solution setup and project registration are the only CLI calls:
 
-1. **Step 6.0 (CLI)** — `uip solution init <SolutionName>` — creates the solution directory + `.uipx`.
+1. **Step 6.0 (CLI)** — `uip solution init <SolutionName>` — creates the solution directory + `.uipx`. **Idempotent w.r.t. a Phase 1 Create:** if the Rule 17 **Create** flow already scaffolded the solution in Phase 1 (per [registry-discovery.md § Create-on-Missing → 0 Prerequisite](registry-discovery.md#create-on-missing-build-and-rediscovery)), the `.uipx` already exists — **skip this call iff that exact `<SolutionDir>/<SolutionName>.uipx` is present** (same canonical name + working-root location — [plugins/case/planning.md § Naming](plugins/case/planning.md#project-structure-prerequisites)). Re-running `init` over an existing solution errors, and a differently-named or -located `init` would fork the solution.
 2. **T01 (plugin)** — execute [`plugins/case/impl-json.md`](plugins/case/impl-json.md) in full:
    - § Scaffold writes 5 boilerplate files (`project.uiproj`, `operate.json`, `entry-points.json`, `bindings_v2.json`, `package-descriptor.json`) directly into `<SolutionDir>/<ProjectName>/`.
    - § Write caseplan.json writes the root skeleton (`root` + empty `nodes: []` + empty `edges: []`).
@@ -95,12 +98,16 @@ For each trigger T-entry in `tasks.md §4.3`, open the matching plugin's `impl-j
 - Manual / Timer / Event (resolved) → `plugins/triggers/<type>/impl-json.md` §3
 - Event (UNRESOLVED) → [`plugins/triggers/event/impl-json.md` § Placeholder fallback](plugins/triggers/event/impl-json.md) — node still written; case stays reachable
 
-Each plugin writes one node to `caseplan.json.nodes[]` and appends one entry to `entry-points.json.entryPoints[]` atomically. Capture every `TriggerId` for Step 6.2 (In-arg `elementId`).
+Each plugin writes one node to `caseplan.json.nodes[]` and appends one entry to `entry-points.json.entryPoints[]` atomically. Capture every `TriggerId` for Step 6.2 — an In-arg's `elementId` resolves to `id-map[<sourceTriggers T-number>].id`, or the primary trigger (T02) when its `sourceTriggers` is blank.
 
 ## Step 6.2 — Declare global variables and arguments
 
 For each variable/argument T-entry from `tasks.md §4.2.1`, write entries directly into `caseplan.json` per [`plugins/variables/global-vars/impl-json.md`](plugins/variables/global-vars/impl-json.md). This step populates top-level `variables` (inputs, outputs, inputOutputs) and trigger output mappings. Execute these before adding stages — downstream tasks and conditions reference variables via `=vars.<id>`.
 
+## Step 6.3 — Refresh entry-points.json input/output
+
+After Step 6.2, project the declared In/Out arguments onto every `entry-points.json` entry's `input`/`output` schema per [entry-points-sync.md](entry-points-sync.md). Triggers (Step 6.1) scaffold each entry with empty `input`/`output` because variables don't exist yet; this back-fills them. Prerequisites — all entries (Step 6.1) + all In/Out args (Step 6.2) — are complete here, and In/Out formal args never change in Phase 3, so the file is correct from the Phase-2 publish branch onward. Idempotent — re-run on regenerate. Verified by Step 12 Check 6.
+
 ## Step 7 — Add stages
 
 For each stage in `tasks.md §4.4`, execute per [`plugins/stages/impl-json.md`](plugins/stages/impl-json.md). **Capture the generated `StageId` for every stage** into the name → ID map (and into `id-map.json`) — downstream tasks, conditions, and SLA all reference it.
@@ -115,7 +122,7 @@ For multi-trigger cases, add the additional triggers via the appropriate trigger
 
 ## Step 9 — Add tasks (Phase 2 shape, gather-then-write)
 
-**Phase A — gather.** For each non-connector task in `tasks.md §4.6`, run `uip maestro case tasks describe --type <type> --id <entityKey> --output json` and collect the input schema in reasoning. Connector tasks (`connector-activity`, `connector-trigger`) skip the gather — `case spec` defers to Phase 3 Step 9.7. Unresolved tasks skip too — they become placeholders per Step 9.1.
+**Phase A — gather.** For each non-connector task in `tasks.md §4.6`, run `uip maestro case tasks describe --type <type> --id <entityKey> --output json` and collect the input schema in reasoning. Connector tasks (`connector-activity`, `connector-trigger`) skip the gather — `case spec` defers to Phase 3 Step 9.7. Unresolved tasks skip too — they become placeholders per Step 9.1. **Inline-built siblings (agent / api-workflow, Rule 17 Create) also skip the gather** — they were resolved + bound in Phase 1 with I/O read from the sibling's on-disk `entry-points.json`; their `taskTypeId` is a local audit-only key with no tenant resource, so tenant `tasks describe` does not apply. See the per-type Built-inline notes: [`plugins/tasks/agent/impl-json.md`](plugins/tasks/agent/impl-json.md), [`plugins/tasks/api-workflow/impl-json.md`](plugins/tasks/api-workflow/impl-json.md).
 
 **Phase B — batched write.** One Read of `caseplan.json`. Then one Edit per task in §4.6 order, appending the task node to its stage's `data.tasks` lane per the matching plugin's `impl-json.md`. **Capture each `TaskId`** — cross-task references and conditions in Phase 3 need it. Skip the re-Read between sibling Edits. One validate at section end.
 
@@ -246,7 +253,7 @@ Skip the re-Read between sibling Edits. One validate at section end. Per-scope c
 
 ## Step 11 — SLA and escalation (per-target Edit batch)
 
-One Read of `caseplan.json` at Step 11 entry. Group `tasks.md §4.8` entries by target (root or stage). For each target, one Edit replacing that target's full `slaRules[]` array per [`plugins/sla/impl-json.md`](plugins/sla/impl-json.md). Skip the re-Read between sibling Edits. Supports per-conditional-rule escalations, ExceptionStage SLA, and multi-recipient single rules. One validate at section end.
+One Read of `caseplan.json` at Step 11 entry. Group `tasks.md §4.8` entries by target (root or stage). For each target, one Edit replacing that target's full `slaRules[]` array per [`plugins/sla/impl-json.md`](plugins/sla/impl-json.md). Skip the re-Read between sibling Edits. Supports per-conditional-rule escalations, secondary-stage SLA, and multi-recipient single rules. One validate at section end.
 
 ## Step 11.5 — Resolve in-expression `vars.$xref` markers (whole-file pass)
 
@@ -256,7 +263,7 @@ Runs after bindings (9.8), conditions (10), and SLA (11) — when every task / t
 
 > **Algorithm reference:** the per-check pseudocode + AskUserQuestion prompt templates + skill-response-per-pick details all live in [`plugins/variables/io-binding/impl-json.md § Binding Procedure`](plugins/variables/io-binding/impl-json.md#binding-procedure). This step is the orchestration hook; that doc is the algorithm. When in doubt, follow the impl-json doc.
 
-After all value bindings (Step 9.8), conditions (Step 10), SLA (Step 11), and marker resolution (Step 11.5) are written, invoke the end-of-Phase-3 validator — Checks 1, 2, 3, 4, 5.
+After all value bindings (Step 9.8), conditions (Step 10), SLA (Step 11), and marker resolution (Step 11.5) are written, invoke the end-of-Phase-3 validator — Checks 1, 2, 3, 4, 5, 6.
 
 - **Check 1** — Resolve every `=vars.X` reference against `variables.{inputs, inputOutputs}[].id`. Scan all task input `value` fields, entry/exit condition expressions (stage and task), case-exit and trigger rule expressions, SLA expressions, and `=js:` expressions anywhere they appear. On unresolved → **AskUserQuestion** offering: (a) name the intended variable, (b) remove the reference, (c) continue with best-effort emit (entry logged under Open Items, runtime returns undefined).
 - **Check 2 — Out-arg producer presence** — For every formal Out-arg in `variables.outputs[]`, verify the producer/Default situation per [`io-binding/impl-json.md` § Check 2](plugins/variables/io-binding/impl-json.md):
@@ -266,6 +273,7 @@ After all value bindings (Step 9.8), conditions (Step 10), SLA (Step 11), and ma
 - **Check 3** — Type mismatch between `=vars.X` reference and consumer slot → log WARN inline (non-blocking; string coercion is runtime-tolerant).
 - **Check 4 — No surviving `$xref` markers** — Scan every string value in `caseplan.json` for the literal `$xref(`. Step 11.5 resolves all; any survivor means its name-triple failed (typo'd stage / task / output) — the same class of failure as a Check 1 unresolved `=vars.X`, so it gets the same interactive remediation. On unresolved → **AskUserQuestion** (present the outputs that DO exist on the named task as candidates): (a) name the intended source output — skill rewrites the triple, re-resolves, substitutes `vars.<var>`; (b) edit the SDD expression + re-run the Phase 1 dispatcher (when the output genuinely doesn't exist); (c) continue with best-effort emit (token left unsubstituted, entry logged under Open Items; `vars.$xref(...)` throws at runtime until fixed). Detail: [`io-binding/impl-json.md` § Check 4](plugins/variables/io-binding/impl-json.md).
 - **Check 5 — Resolved-resource I/O completeness** — For each task with a persisted contract in `tasks/registry-resolved.json`, verify every **required** declared input has a bound `value` and every extract output `Field` exists in the resolved output contract. An upstream-output-fed input (`=vars.<var>` / resolved `$xref`) counts as bound with NO §1.5 row. On unbound-required-input or phantom-output-field → **AskUserQuestion**: (a) bind / re-point, (b) `<UNRESOLVED>`+review-item / drop row, (c) continue with best-effort emit (entry logged under Open Items; runtime null until fixed). Tasks with no contract (placeholder / `<UNRESOLVED>`) are skipped. Detail: [`io-binding/impl-json.md` § Check 5](plugins/variables/io-binding/impl-json.md#check-5--resolved-resource-io-completeness).
+- **Check 6 — Entry-point schema parity** — Verify every `entry-points.json` entry's `input`/`output` matches the In/Out args projected at Step 6.3 (keys, type mapping, `required`, `file`/`jsonSchema` shapes), plus unique `filePath` fragments and no orphaned `inputs[].elementId`. **Non-interactive:** on mismatch re-run the Step 6.3 refresh once; if still divergent (or a uniqueness/orphan finding) log to `## Open Items for User` and continue. No AskUserQuestion. Algorithm: [`entry-points-sync.md § Check 6`](entry-points-sync.md#check-6--entry-point-schema-parity-step-12-validator).
 
 **Build-with-best policy:** for any user pick of "continue with best-effort emit" on a Check 1, Check 2, Check 4, or Check 5 AskUserQuestion, append a `## Open Items for User` entry to `tasks/build-issues.md` and proceed to Phase 4. AskUserQuestion is the surface; build-with-best is the escape. The skill conservatively emits what it has; Phase 4 validate stays green (structural validity is intact); runtime concerns are listed for pre-publish review.
 
@@ -313,6 +321,8 @@ When a debug or process run fails, read **[troubleshooting-guide.md](troubleshoo
 2. **Fixable outside `caseplan.json`** (missing/expired connection, unregistered task type, missing Orchestrator asset, permissions): halt agent edits. Report exact resource + remediation steps to user via **AskUserQuestion** with options — `Resource fixed, re-run debug`, `Abort`.
 3. **Inconclusive** (no actionable cause): proceed to next round per retry policy.
 
+> **Known by-design debug fault:** an inline-built api-workflow sibling's task failing with incident `170007` ("job's associated process could not be found") under `case debug` is expected — debug does not provision Api siblings (agent siblings do resolve). Do not spend troubleshoot rounds on it; runtime verification needs a full solution deploy, offered via AskUserQuestion per [phased-execution.md § Debug notes](phased-execution.md#debug-notes) (the contract owner).
+
 **Retry policy.** Up to 3 troubleshoot → fix → debug rounds per failed run. Each round must add new context (different element ID, broader scope, fallback command) or apply different fix — do not repeat identical commands or re-apply same fix. Track round count.
 
 **Per-round timeout.** If debug run exceeds 10 minutes wall-clock, treat round as inconclusive and advance to next round (counts toward 3-round limit). Advisory — do not hard-kill subprocess; classify by elapsed time and move on.

package/skills/uipath-maestro-case/references/phase-0-interview.md

@@ -130,7 +130,7 @@ Skip a dimension's prompt only when Listen already captured it verbatim at high
 | 5 | Decisions / gates | `Where does someone approve / decline / escalate?` Each gate → an `action` task with buttons, or a routing exit. | task buttons, exits |
 | 6 | Data per stage | `What information is collected or produced at each step?` | §1.5 variables |
 | 7 | Trigger & exit | `What kicks this off, and what does 'done' look like?` Trigger type is Always-Ask the moment a portal / form / schedule / event is named. | §1.3, §1.4 |
-| 8 | Exceptions / escalations | `What goes wrong, and how is it handled?` Each handler → a secondary (exception) stage — see [sdd-generation-rules.md § Mental model](sdd-generation-rules.md#mental-model-stages-secondary-stages-tasks). | exception stages |
+| 8 | Exceptions / escalations | `What goes wrong, and how is it handled?` Each handler → a secondary (exception) stage — see [sdd-generation-rules.md § Mental model](sdd-generation-rules.md#mental-model-stages-secondary-stages-tasks). | secondary stages |
 | 9 | SLA / timing | Only when the user mentioned timing. `How long should <stage / case> take?` | §1.2, stage SLA |
 
 Each row is a single-question prompt by default. Collapse only the safe-to-default rows (4 persona descriptions, 9 SLA when timing was never raised) into the one allowed §Batched prompt. Trigger type (7), task type on ambiguous verbs (3), and case exit (7) stay single-question — they are Always-Ask.
@@ -167,7 +167,7 @@ One AskUserQuestion with up to 4 `multiSelect: true` rows for fields whose value
 |---|---|
 | Case-level description (Section 1.1) | `—` (Phase 1 leaves blank) |
 | Persona descriptions (Section 3) | `—` |
-| Exception-stage descriptions | `—` |
+| Secondary-stage descriptions | `—` |
 | Optional `conditionExpression` cells in Entry / Exit rows | `—` (no IF filter) |
 | Optional `Business Calendar` cell on timers | `—` (use 24×7) |
 | Optional task SLA on `action` tasks | `—` (inherits case SLA) |
@@ -190,6 +190,7 @@ Use sparingly — at most one batched prompt in the whole interview. Each row de
 | Field | Why never default |
 |---|---|
 | Trigger type when ANY external system, portal, form, schedule, signup, or inbound event is mentioned | `Timer` / `Connector Event` change generation path. "Vendor signs up" → portal/event, NOT Manual. |
+| Trigger type when a tenant case-entity / data-object record-created start is mentioned | This is an event trigger with the named object as Source. Missing tenant provisioning is handled later as an unresolved placeholder, not by downgrading to Manual. |
 | Task type on ambiguous verbs (`review`, `approve`, `check`, `validate`, `process`, `assess`, `sign off`, `decide`) | `action` (HITL) vs `agent` (LLM) generate different shapes. The verb alone is not enough. |
 | Task type when a **compliance trigger phrase** is in the transcript (ECOA, NCQA, HIPAA, SOC 2, FCRA, FINRA, "licensed X", "fiduciary review", etc.) AND user proposed non-`action` | Tier 2 of the authority hierarchy forces `action`; do not silently accept user's stated type. See [sdd-generation-rules.md § Task-type override priority](sdd-generation-rules.md#task-type-override-priority). |
 | Case exit condition | Wrong exit traps the case open or closes prematurely. |
@@ -207,6 +208,7 @@ These thoughts mean STOP and use AskUserQuestion before continuing:
 | Thought | Reality |
 |---|---|
 | "I'm confident enough about the trigger." | Trigger ≠ Manual the moment a portal, form, schedule, or external system is mentioned. Always-Ask. |
+| "The named data object might not exist in this tenant, so Manual is safer." | Preserve the object as an event trigger. Unresolved resources become placeholders during planning/build. |
 | "The user said 'review' — probably an `action` task." | `review` is on the Always-Ask list. Ask. |
 | "User said 'I'll fix it later' — defaulting is sanctioned." | User-permission to default ≠ permission to skip Ask. Rule 2 locks the file post-Approve. Wrong defaults survive. |
 | "User is in a hurry, don't burn turns." | One Ask costs 30s. One wrong default costs a Phase 4 retry loop. Ask. |
@@ -242,7 +244,7 @@ Classification of each reply:
 After Sketch + Ask close out, count from `sdd.draft.md`:
 
 - Stages, Tasks total, Distinct integrations, Distinct personas, `case-management` tasks (child cases).
-- Exception stages — counted but never triggers redirect.
+- Secondary stages — counted but never triggers redirect.
 
 Breach any quantitative cap → §Soft redirect.
 
@@ -263,10 +265,10 @@ Run `uip maestro case registry pull` first if cache absent. See [registry-discov
 |---|---|---|
 | `execute-connector-activity` | connector `typeId` + operation (`typecache-activities-index.json`) | a registered IS **connection** (`connectionId`) for that connector |
 | `wait-for-connector` | connector-trigger `typeId` (`typecache-triggers-index.json`) | an IS connection for the inbound event |
-| `agent` | `agentId` (`agent-index.json`) | the agent is **deployed** |
+| `agent` | `agentId` (`agent-index.json`) | the agent is **deployed** — or built inline at the Phase 1 Rule 17 Create gate (in-solution sibling) |
 | `action` (human task / HITL) | `actionAppId` (`action-apps-index.json`) when a deployed Action App matches | else `<UNRESOLVED>` + Rule-8 placeholder — inline JSON-schema authoring is NOT supported by the action plugin |
 | `process` / `rpa` | `processOrchestrationId` (`process-index.json` / `processOrchestration-index.json`) | the process is **published** |
-| `api-workflow` | `apiWorkflowId` (`api-index.json`) | the API workflow is **deployed** |
+| `api-workflow` | `apiWorkflowId` (`api-index.json`) | the API workflow is **deployed** — or built inline at the Phase 1 Rule 17 Create gate (in-solution sibling) |
 | `case-management` | child case (`caseManagement-index.json`) | the child case is **published** |
 
 A *type* match with **no live instance** still ships `<UNRESOLVED>` + a `high` review item — never fabricate IDs (SKILL.md Rule 8). (A connector type can exist in the catalog while the tenant has zero connections — that is still `<UNRESOLVED>`.)
@@ -302,10 +304,10 @@ Per-task AskUserQuestion (4 options max). **When candidate matches differ by fol
 |---|---|
 | `<top match — name · folder · version · type>` | Record selection (incl. chosen folder). |
 | `<second match — name · folder · version · type>` (if available) | Record selection (incl. chosen folder). |
-| `Placeholder — resolve later` | Keep `<UNRESOLVED>` on `taskTypeId` / `typeId` / `connectionId`. Phase 1 emits placeholder task per Rule 8. |
+| `Placeholder — resolve later` | Keep `<UNRESOLVED>` on `taskTypeId` / `typeId` / `connectionId`. Phase 1 emits placeholder task per Rule 8. **For an `agent` or `api-workflow`,** Phase 1's Rule 17 gate additionally offers to build it inline as an in-solution sibling ([registry-discovery.md § Create-on-Missing](registry-discovery.md#create-on-missing-build-and-rediscovery)) — a no-match resource of these kinds need not stay manual. |
 | `Something else` | Free-text re-search keyword, retry. |
 
-**Empty registry match** across bucket C → AskUserQuestion `Force pull and re-resolve` / `Skip and use placeholders` (Rule 17), applied per batch, not per task. When the user picks `Skip and use placeholders`, every unresolved task emits a high-severity review item per [sdd-generation-rules.md § Review items](sdd-generation-rules.md#review-items).
+**Empty registry match** across bucket C → AskUserQuestion `Force pull and re-resolve` / `Skip and use placeholders` — plus, when ≥1 still-empty is an `agent` or `api-workflow` AND the CLI supports `registry --local`, `Create the missing resource(s) inline` (build as in-solution siblings; see [registry-discovery.md § Create-on-Missing](registry-discovery.md#create-on-missing-build-and-rediscovery)) — per Rule 17, applied per batch, not per task. When the user picks `Skip and use placeholders`, every unresolved task emits a high-severity review item per [sdd-generation-rules.md § Review items](sdd-generation-rules.md#review-items).
 
 #### Schema discovery — pull each resolved task's I/O contract
 
@@ -461,7 +463,7 @@ Hard quantitative caps. Breach triggers §Soft redirect (not hard refuse).
 | Distinct personas | > 3 |
 | Child cases (`case-management` tasks) | ≥ 1 |
 
-**Exception stages are NOT a threshold.** They may appear freely.
+**Secondary stages are NOT a threshold.** They may appear freely.
 
 ## Soft redirect
 

package/skills/uipath-maestro-case/references/phased-execution.md

@@ -2,6 +2,8 @@
 
 Authoritative reference for the post-planning execution flow. Read before executing any T-entry from an approved `tasks.md`.
 
+> **Editing an existing case?** Targeted edits to an existing `caseplan.json` skip these phases — see [brownfield.md](brownfield.md).
+
 > **Relationship to other docs.** This document defines phase boundaries and hard-stop contracts. Per-plugin execution detail lives in `plugins/<name>/impl-json.md`. Per-step ordering and file-system mutations live in [implementation.md](implementation.md).
 
 ## Downstream CLI compatibility
@@ -43,6 +45,7 @@ Each hard stop gives user review checkpoint before agent commits to costly downs
 - Stages — all StageIds generated and captured.
 - Edges — none authored; `schema.edges` stays `[]`. Stage transitions are condition-driven (written in Phase 3).
 - Triggers — fully built. Trigger output mappings written (they reference global variables, which already exist).
+- Entry-points input/output — `entry-points.json` `input`/`output` schemas refreshed from the declared In/Out arguments (Step 6.3, per [entry-points-sync.md](entry-points-sync.md)). Makes the Phase-2 publish-for-review contract correct; idempotent.
 
 ### Tasks (shape depends on resolution state + task class)
 
@@ -51,6 +54,7 @@ Each hard stop gives user review checkpoint before agent commits to costly downs
 | Non-connector (`process`, `agent`, `rpa`, `action`, `api-workflow`, `case-management`, `wait-for-timer`) | `task-type-id` resolved | Full `data.inputs[]` schema written (from `uip maestro case tasks describe`). Each input's `value` field is empty (`""`). Outputs and task-specific scalar fields (e.g. `action`'s `taskTitle`/`priority`/`recipient`/`labels`) populated per plugin — these are final at Step 2; only input `value`s defer to Phase 3. |
 | Connector (`connector-activity`, `connector-trigger`) | `type-id` + `connection-id` resolved | `data.typeId` + `data.connectionId` set. `data.inputs` omitted or empty. **No `case spec` call in Phase 2** — schema discovery is deferred to Phase 3. |
 | Any task | Unresolved (`<UNRESOLVED: …>` in `tasks.md`) | Placeholder task per Rule 8 of `SKILL.md` — empty `data: {}` (plus `data.taskTitle` / `data.priority` / `data.recipient` for `action`). Marker preserved. See [placeholder-tasks.md](placeholder-tasks.md). |
+| `agent` / `api-workflow` built inline | Built + bound in Phase 1 at the Rule 17 gate | **Not a placeholder** — fully resolved task (name+folder binding, `resourceKey="solution_folder.<name>"`, **`folderPath` binding `default` = `""`** — co-located runtime folder; `solution_folder` stays only in `resourceKey`). Phase 2 treats it like any resolved resource. See [registry-discovery.md § Create-on-Missing](registry-discovery.md#create-on-missing-build-and-rediscovery). |
 
 ### What does NOT get written in Phase 2
 
@@ -79,7 +83,7 @@ uip maestro case validate "<caseplan.json path>" --skeleton --output json
 
 Print before prompt:
 
-1. Counts: stages / primary stages / exception stages / triggers / tasks total / placeholder tasks / unresolved resources.
+1. Counts: stages / primary stages / secondary stages / triggers / tasks total / placeholder tasks / unresolved resources.
 2. Validate result (placeholder-profile): `<N> errors, <M> warnings` — remaining errors are structural (unreachable/orphan stage, missing trigger, duplicate names) and actionable. Surfacing counts is enough; do not dump full error list unless user asks.
 3. Paths: `caseplan.json`, `tasks.md`, `registry-resolved.json`.
 
@@ -126,7 +130,7 @@ Phase 3 begins after user selects `Continue to phase 3` (or `Skip publish and co
 
 1. **Re-read `tasks.md`** — per Rule 7. Declarative plan is the handoff.
 2. **Re-read `caseplan.json`** — authoritative source of all IDs generated in Phase 2:
-   - Stage name → StageId (from `schema.nodes[]` where `type === "case-management:Stage"` or `"case-management:ExceptionStage"`, keyed on `data.label`).
+   - Stage name → StageId (from `schema.nodes[]` where `type === "case-management:Stage"`, keyed on `data.label`; secondary stages are the same type with `data.stageType === "secondary"`).
    - Trigger ID (from `schema.nodes[]` where `type === "case-management:Trigger"`).
    - Task name → TaskId per stage (from `schema.nodes[<stage>].data.tasks[][]`).
    - Variable name → `var` ID (from top-level `variables.{inputs,outputs,inputOutputs}`).
@@ -147,7 +151,7 @@ After re-entry:
    - Case exit conditions
 4. **SLA + escalation** — per [`plugins/sla/impl-json.md`](plugins/sla/impl-json.md). Group `tasks.md §4.8` by target (root or stage); write full `slaRules[]` in one mutation per target.
 5. **In-expression marker resolution** — per [`plugins/variables/io-binding/impl-json.md § In-Expression Marker Resolution`](plugins/variables/io-binding/impl-json.md). After all outputs are minted/deduped and bindings/conditions/SLA are written, resolve every `vars.$xref('Stage','Task','output')` marker in `caseplan.json` to bare `vars.<var>` in one sink-blind whole-file pass (input payloads, conditions, SLA, connector bodies). Unresolved triple → ERROR.
-6. **End-of-Phase-3 validator pass** — per [`implementation.md § Step 12`](implementation.md). Run Checks 1-5 (=vars.X resolution, Q10 II Out-arg producer presence, type mismatch, surviving `$xref` markers, resolved-resource I/O completeness). AskUserQuestion for unresolved references (incl. `$xref` markers), pure orphan Out-args, and unbound required inputs / phantom output fields; option (c)/(d) "continue with best-effort emit" preserves forward progress. Never HALT.
+6. **End-of-Phase-3 validator pass** — per [`implementation.md § Step 12`](implementation.md). Run Checks 1-6 (=vars.X resolution, Out-arg producer presence, type mismatch, surviving `$xref` markers, resolved-resource I/O completeness, entry-point schema parity). AskUserQuestion for unresolved references (incl. `$xref` markers), pure orphan Out-args, and unbound required inputs / phantom output fields; option (c)/(d) "continue with best-effort emit" preserves forward progress. Check 6 is non-interactive (auto re-run, else log). Never HALT.
 
 Phase 3 produces a `caseplan.json` that should pass authoritative validation. No hard stop on Phase 3 exit — agent proceeds directly to Phase 4.
 
@@ -195,13 +199,14 @@ After debug completes, return to Phase 5 prompt so user can re-run or move on. P
 1. File path of `caseplan.json`.
 2. What was built — summary of stages, tasks, conditions, SLA.
 3. Validation status — `validate` pass / remaining warnings.
-4. Placeholder tasks + unresolved resources — list every placeholder (TaskId, type, display-name, stage) + external resource user must register (task-type-id / connection-id) + wiring-notes from `tasks.md`. See [placeholder-tasks.md](placeholder-tasks.md).
+4. Placeholder tasks + unresolved resources — list every placeholder (TaskId, type, display-name, stage) + external resource user must register (task-type-id / connection-id) + wiring-notes from `tasks.md`. Also list **agents / API workflows built inline** (built as in-solution siblings, already bound) and any **built but unreferenced** (reject case) separately — they need no user action. See [placeholder-tasks.md § Completion-Report Shape](placeholder-tasks.md#completion-report-shape).
 5. Missing connections — connector tasks needing IS connections that don't exist yet.
 
 ### Debug notes
 
 - `uip solution resources refresh` MUST run before debug — syncs resources from `bindings_v2.json` so Studio Web can resolve connector dependencies (Rule 14).
 - Debug verifies the build actually runs end-to-end before the user commits to a publish. If debug surfaces a fixable issue, see [Step 13a — Troubleshoot failed case](implementation.md#step-13a--troubleshoot-failed-case) and re-run.
+- **Inline-built api-workflow siblings are NOT provisioned by `case debug`** — that task faults with incident `170007` ("job's associated process could not be found") by design; agent siblings do resolve in debug. Verifying that task's runtime needs a full solution deploy (`uip solution pack` → `uip solution publish` → `uip solution deploy run`) — an Orchestrator install, so **offer it via AskUserQuestion, never run it unprompted** (options — `Run full solution deploy` / `Skip (mark debug-unverifiable)`; the Phase 6 no-deploy default applies); if declined, report the task as debug-unverifiable and continue. See [api-workflow/planning.md § Creating an API workflow inline](plugins/tasks/api-workflow/planning.md#creating-an-api-workflow-inline).
 
 ## Phase 6 — Publish
 
@@ -222,6 +227,8 @@ For further authoring changes (add task, tweak condition, etc.), user updates `s
 
 Placeholder tasks (empty `data: {}` for unresolved resources) behave the same in all phases. Phase 2 creates them; Phase 3 does **not** upgrade them to typed tasks — upgrading requires user to register missing resource externally. See [placeholder-tasks.md](placeholder-tasks.md).
 
+> **Agents / API workflows built inline are not placeholders.** When the user picks **Create** at the Rule 17 gate, Phase 1 builds the resource (a side effect — spawns a sub-agent invoking `uipath-agents` / `uipath-api-workflow`, registers the sibling, binds it) so it enters Phase 2 as a fully resolved task. Phase 3 never upgrades it (nothing to upgrade). Only resources the user declined/skipped or whose build failed become placeholders. See [registry-discovery.md § Create-on-Missing](registry-discovery.md#create-on-missing-build-and-rediscovery).
+
 Phase 3 still wires placeholder TaskIds into:
 - Task-entry conditions that reference the placeholder.
 - Stage-exit `selected-tasks-completed` rules that include the placeholder.

package/skills/uipath-maestro-case/references/placeholder-tasks.md

@@ -115,6 +115,8 @@ These are **expected** and do not block the build. Errors only appear when cross
 
 ## Upgrade Procedure — Placeholder → Full Task
 
+> **Built-inline agents / API workflows are not placeholders.** An `agent` or `api-workflow` the user chose to **Create** at the Rule 17 gate is built and bound during planning ([registry-discovery.md § Create-on-Missing](registry-discovery.md#create-on-missing-build-and-rediscovery)) — it enters Phase 2 as a fully resolved task, never a placeholder, and skips this procedure. This procedure covers creatable resources the user **declined/skipped or whose build failed** (their recovery is the same as any other unresolved kind — register the real resource, below), plus every other unresolved kind.
+
 When the user has registered the real resource:
 
 ### 1. Re-pull the registry
@@ -127,7 +129,7 @@ uip maestro case registry pull --force
 
 ### 2. Resolve the task-type-id
 
-Read the relevant cache file directly per [registry-discovery.md](registry-discovery.md) — e.g., `process-index.json` for processes, `action-apps-index.json` for action apps.
+Read the relevant cache file directly per [registry-discovery.md](registry-discovery.md) — e.g., `process-index.json` for processes, `action-apps-index.json` for action apps. For a **manually-built in-solution sibling** (agent or api-workflow), find it offline by name with `uip maestro case registry search "<name>" --type <agent|api> --local --output json` (`agent` for an agent sibling, `api` for an api-workflow sibling; select the exact-name `Data.Resources[].Resource` entry; use `search` — `get --local` matches only the opaque `entityKey`, not the name). Its `Resource.EntityKey` is an opaque derived key (not the `.uipx` `Projects[].Id`), audit-only; the node binds by name+folder. Read the sibling's I/O field names from its raw `entry-points.json` (the `--output json` keys are PascalCased). For an **api-workflow sibling**, read its I/O per the fallback chain in [api-workflow/planning.md § Registry Resolution](plugins/tasks/api-workflow/planning.md#registry-resolution) — flat `entryPoints[0].input.properties` → `input.schema.document.properties` wrapper → `Workflow.json` root schemas when the entry-point I/O is `null`; note any fallback in the report.
 
 ### 3. Fetch the schema
 
@@ -185,7 +187,24 @@ When the build finishes with placeholders, the skill's completion report must li
 - **Custom IS connectors** (N): U Submit (GetSubmission), U Place (SubmitPlannedMarkets), …
 ```
 
-The user uses this list to drive external resource creation, then runs the upgrade procedure.
+When agents / API workflows were **built inline** at the gate, list them separately — they are resolved, not placeholders:
+
+```
+### Agents / API workflows built inline (N)
+
+| Stage | Task | Resource | Status |
+|-------|------|----------|--------|
+| Triage | Classify PO | Classify PO (agent) | built as in-solution sibling via uipath-agents; bound via --local |
+| Enrich | Fetch Rates | RateFetcher (api-workflow) | built as in-solution sibling via uipath-api-workflow; bound via --local |
+
+### Built but not referenced (reject case)
+
+| Resource | Note |
+|----------|------|
+| Sentiment (agent) | built sibling on disk; task dropped from plan — reuse or remove manually |
+```
+
+The user uses the placeholder/external lists to drive external resource creation, then runs the upgrade procedure; the "built inline" list is informational (already wired).
 
 ## Anti-Patterns
 
@@ -193,3 +212,6 @@ The user uses this list to drive external resource creation, then runs the upgra
 - **Do NOT partially bind inputs on a placeholder.** A placeholder has no `data.inputs[]` to edit — the io-binding plugin logs a `SKIPPED` entry and moves on. Half-bound placeholders are harder to upgrade than bare ones.
 - **Do NOT skip task-entry conditions on placeholders.** Conditions are structural; they work on the TaskId and must be created so the workflow order is visible in review.
 - **Do NOT create placeholders for timer tasks.** Timers have no registry dependency — use the full `wait-for-timer` plugin.
+- **Do NOT create a placeholder for an agent or API workflow the user chose to build inline.** It is built + bound during planning ([registry-discovery.md § Create-on-Missing](registry-discovery.md#create-on-missing-build-and-rediscovery)) — a resolved task, not a placeholder.
+- **Do NOT build an agent or API workflow from SDD content alone.** Inline create runs only for resources the user explicitly selected at the Rule 17 gate. The built resource is an in-solution **sibling** that co-deploys with the case — never a separate tenant publish.
+- **Invoking `uipath-agents` / `uipath-api-workflow` for the inline build is sanctioned** — it is not a violation of the "don't auto-invoke other skills" anti-pattern, which still applies to every non-creatable kind (regular RPA process, action, connectors, agentic process) and to `uipath-planner`.

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

@@ -2,13 +2,15 @@
 
 Generate reviewable task plan (`tasks.md`) from design document (`sdd.md`). Discovers registry resources, resolves task type IDs, produces declarative specification that downstream execution phases (Phase 2 Prototyping → Phase 3 Implementation → Phase 4 Validate → Phase 5 Debug → Phase 6 Publish) consume via direct JSON writes to `caseplan.json`. See [implementation.md](implementation.md) for execution detail and [phased-execution.md](phased-execution.md) for phase contracts.
 
+> **Editing an existing case?** Targeted edits to an existing `caseplan.json` skip this planning pipeline — see [brownfield.md](brownfield.md).
+
 > **Output:** `tasks/tasks.md` + `tasks/registry-resolved.json` in the same directory as the sdd.md file. When SLA escalations are present, also `tasks/recipients-resolved.json` — see [`plugins/sla/planning.md` § Identity Resolution](plugins/sla/planning.md#identity-resolution).
 >
 > **Exit gate:** User must explicitly approve `tasks.md` before Phase 2 begins.
 
 > **Per-node-type detail lives in plugins.** This document covers the cross-cutting planning workflow. For how to fill fields for a specific node, consult the relevant plugin:
 > - Root case → `plugins/case/planning.md`
-> - Stages (regular / exception) → `plugins/stages/planning.md`
+> - Stages (primary / secondary) → `plugins/stages/planning.md`
 > - Tasks → `plugins/tasks/<type>/planning.md`
 > - Triggers → `plugins/triggers/<type>/planning.md`
 > - Conditions → `plugins/conditions/<scope>/planning.md`
@@ -96,6 +98,8 @@ For every task, trigger, and condition in the sdd.md:
 | `wait-for-connector` | `plugins/tasks/connector-trigger/` |
 | `wait-for-timer` | `plugins/tasks/wait-for-timer/` |
 
+> **`agent` & `api-workflow` — create-on-missing.** Both kinds can be built inline at the Rule 17 gate — flow in [§ 3.4](#34-unresolved-resources); type specifics: [agent](plugins/tasks/agent/planning.md#creating-an-agent-inline) / [api-workflow](plugins/tasks/api-workflow/planning.md#creating-an-api-workflow-inline). All other kinds (regular RPA `process`, action, connectors, agentic process) use the §3.4 placeholder path.
+
 ### 3.2 Trigger Type catalog (case-level)
 
 | sdd.md description | Plugin |
@@ -121,6 +125,8 @@ When a resource cannot be resolved (registry gap and no cache match, or missing
 
 > **Missing connection — offer to create first.** A missing/empty IS connection is not immediately "unresolved". The connector pipeline offers to create one via `uip is connections create` ([connector-integration.md § Step 2](connector-integration.md), [connector-trigger-common.md § Resolve the connection](connector-trigger-common.md#2-resolve-the-connection)). Only after the user **declines** or creation fails does the connection become `<UNRESOLVED>` and fall through to the steps below.
 
+> **Missing agent or API workflow — offer to create first.** A missing `agent` (no `agent-index.json` match) or `api-workflow` (no `api-index.json` match) is not immediately "unresolved". At the Rule 17 empty-lookup gate the skill offers to build it as an in-solution sibling — it spawns a sub-agent that invokes `uipath-agents` (agent) / `uipath-api-workflow` (API workflow), then rediscovers + binds via `registry --local` ([registry-discovery.md § Create-on-Missing](registry-discovery.md#create-on-missing-build-and-rediscovery); specifics in [agent/planning.md § Creating an Agent inline](plugins/tasks/agent/planning.md#creating-an-agent-inline) / [api-workflow/planning.md § Creating an API workflow inline](plugins/tasks/api-workflow/planning.md#creating-an-api-workflow-inline)). Only after the user **declines**/skips, the build fails, or the CLI lacks `registry --local` does it become `<UNRESOLVED>` and fall through to the steps below. Other kinds (regular RPA process, action, connectors, agentic process) have no inline-create path — they fall straight through.
+
 Otherwise:
 
 1. Mark the line in `tasks.md` with `<UNRESOLVED: <reason>>` in the `taskTypeId` / `typeId` / `connectionId` slot.
@@ -250,9 +256,9 @@ Do **not** collapse the unresolved trigger into a note on T02 or omit it entirel
 
 ### 4.4 Create stages
 
-Title format: `Create stage "<name>"` or `Create exception stage "<name>"`
+Title format: `Create stage "<name>"` or `Create secondary stage "<name>"`
 
-One task per stage. Consult [`plugins/stages/planning.md`](plugins/stages/planning.md) for required fields and the `stage` vs `exception` (a.k.a. secondary) decision. Basic properties only — SLA and escalation come later (§4.7).
+One task per stage. Consult [`plugins/stages/planning.md`](plugins/stages/planning.md) for required fields and the `stage` vs `secondary` decision. Basic properties only — SLA and escalation come later (§4.7).
 
 ### 4.5 Edges — not authored (RETIRED)
 

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

@@ -77,4 +77,6 @@ The case file lives inside a solution + project structure. After T01 completes,
 
 Planning-phase contract: T01 emits all 5 scaffold files + `caseplan.json` inside `<SolutionDir>/<ProjectName>/`. CLI `uip solution init` and `uip solution project add` bookend T01 as Step 6.0 and Step 6.0b.
 
+**Naming (canonical) — the solution identity is derived ONCE and reused by every step that scaffolds or references the solution.** `<SolutionName>` = the case Name (SDD §1 Metadata), sanitized to a valid directory name; `<SolutionDir>` = `<workingRoot>/<SolutionName>` (the working root adjacent to `sdd.md`). **Step 6.0 AND the Rule-17 Create prerequisite ([registry-discovery.md § Create-on-Missing → 0](../../registry-discovery.md#create-on-missing-build-and-rediscovery)) MUST derive `<SolutionName>` + `<SolutionDir>` identically** — so a solution scaffolded early by a Phase-1 Create is the *same* `.uipx` Step 6.0 then finds and skips. A divergent name or location forks the solution: the built agent sibling registers in one `.uipx`, the case project lands in another, and the case cannot resolve its own agent at runtime. (`<ProjectName>` is T01's to choose under `<SolutionDir>/`.)
+
 See [implementation.md Step 6](../../implementation.md) for the authoritative 3-step execution sequence.

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

@@ -31,7 +31,7 @@ Record every `T<n> → esc_xxxxxx` in `id-map.json` under `{kind: "escalation",
 
 - `target: "root"` → **`metadata.slaRules`** (top-level `metadata` block — there is no `root` key on disk)
 - `target: "<stage-name>"` → locate node by `data.label === <stage-name>`; write to `node.data.slaRules`
-- Accepted node types: `case-management:Stage` and `case-management:ExceptionStage`.
+- Accepted node types: `case-management:Stage` (a secondary/exception stage is the same node with `data.stageType === "secondary"`).
 - If the stage node isn't found, halt and AskUserQuestion with candidate stage labels + "Something else".
 
 ## Recipe — one target