From afeac67a4e6de708cb40da86989a47158335e5de Mon Sep 17 00:00:00 2001 From: "song.zhao" Date: Thu, 30 Apr 2026 16:50:02 -0700 Subject: [PATCH] docs(maestro-case): split validate + ship into dedicated Phase 4 + 5 Agents occasionally skipped debug + validate after Phase 2b's "Full validate" step because the post-build prompt was framed as optional and buried at the tail of the detail-build phase. Promote validate and ship to their own named phases so they cannot be silently skipped, and add Rule 14 to enforce the always-runs contract. - Rename Phase 2a -> Phase 2 (skeleton), Phase 2b -> Phase 3 (detail) - New Phase 4 (Validate) - full validate; agent fixes failures via direct caseplan.json edits (no Phase 3 plugin re-runs), cap 3 retries - New Phase 5 (Ship) - mandatory hard-stop AskUserQuestion loop with debug + publish; debug retry policy added (3 retries) - 17 plugin/reference docs renamed to use the new phase names Co-Authored-By: Claude Opus 4.7 (1M context) --- skills/uipath-maestro-case/SKILL.md | 39 ++-- .../references/bindings-v2-sync.md | 4 +- .../references/case-commands.md | 2 +- .../references/implementation.md | 95 ++++++---- .../references/phased-execution.md | 168 +++++++++++++----- .../case-exit-conditions/impl-json.md | 2 +- .../stage-entry-conditions/impl-json.md | 2 +- .../stage-exit-conditions/impl-json.md | 2 +- .../task-entry-conditions/impl-json.md | 2 +- .../references/plugins/sla/impl-json.md | 2 +- .../plugins/tasks/action/impl-json.md | 4 +- .../plugins/tasks/agent/impl-json.md | 4 +- .../plugins/tasks/api-workflow/impl-json.md | 4 +- .../tasks/case-management/impl-json.md | 4 +- .../tasks/connector-activity/impl-json.md | 2 +- .../tasks/connector-trigger/impl-json.md | 2 +- .../plugins/tasks/process/impl-json.md | 4 +- .../references/plugins/tasks/rpa/impl-json.md | 4 +- .../plugins/tasks/wait-for-timer/impl-json.md | 2 +- .../plugins/variables/io-binding/impl-json.md | 2 +- 20 files changed, 240 insertions(+), 110 deletions(-) diff --git a/skills/uipath-maestro-case/SKILL.md b/skills/uipath-maestro-case/SKILL.md index 1a99c47f6..5b7494e34 100644 --- a/skills/uipath-maestro-case/SKILL.md +++ b/skills/uipath-maestro-case/SKILL.md @@ -33,14 +33,15 @@ Builds UiPath Case Management definitions from `sdd.md`. Generates `tasks.md` pl 7. **Unresolved resource → skeleton, never fabricate IDs.** Keep `` markers in `tasks.md`. Skeleton **task**: node with `type` + `displayName` + structural fields, `data: {}`; conditions still reference the TaskId. Skeleton **event trigger**: node with render fields + `data.uipath: { serviceType: "Intsvc.EventTrigger" }` only (no other `data.uipath` keys); `entry-points.json` entry appended; trigger-edge to first stage created. See [references/skeleton-tasks.md](references/skeleton-tasks.md) and [references/plugins/triggers/event/impl-json.md § Skeleton fallback](references/plugins/triggers/event/impl-json.md). 8. **Persist every registry resolution to `registry-resolved.json`** — search query, all matches, selected result, rationale. 9. **Cross-task refs:** `"Stage Name"."Task Name".output_name` in planning, resolve to `=vars.` at execution by reading source's `var` field. Discover output names via `uip maestro case tasks describe` — never fabricate. See [references/bindings-and-expressions.md](references/bindings-and-expressions.md) and [`plugins/variables/io-binding/impl-json.md`](references/plugins/variables/io-binding/impl-json.md). -10. **HARD STOP between Phase 2a and Phase 2b — unconditional, every run.** Run informational `validate` (no `--mode`), surface counts, present AskUserQuestion: `Publish for review` / `Skip publish and continue` / `Abort`. Do NOT halt on Phase 2a validate errors — unbound inputs/missing conditions/missing SLA expected. Never skip prompt for auto mode, non-interactive mode, prior approval. If harness forbids prompts, halt with error. **On `Publish for review`: print `DesignerUrl` as plain-text output BEFORE invoking the second AskUserQuestion — never embed URL only inside the question body.** Full contract in [`references/phased-execution.md`](references/phased-execution.md). +10. **HARD STOP between Phase 2 and Phase 3 — unconditional, every run.** Run informational `validate` (no `--mode`), surface counts, present AskUserQuestion: `Publish for review` / `Skip publish and continue` / `Abort`. Do NOT halt on Phase 2 validate errors — unbound inputs/missing conditions/missing SLA expected. Never skip prompt for auto mode, non-interactive mode, prior approval. If harness forbids prompts, halt with error. **On `Publish for review`: print `DesignerUrl` as plain-text output BEFORE invoking the second AskUserQuestion — never embed URL only inside the question body.** Full contract in [`references/phased-execution.md`](references/phased-execution.md). 11. **Never run `uip maestro case debug` automatically.** Executes case for real — emails, messages, API calls. Explicit user consent only. 12. **`caseplan.json` mutations: Read + Write/Edit only.** No `python`, `node`, `jq`, `sed`, `awk`, or scripts that open/parse/modify/save the file. Bash subprocesses OK for stdout-only helpers (e.g., id generation), CLI metadata fetches, validate, debug, and solution scaffold/upload. See [references/case-editing-operations.md § Tool usage](references/case-editing-operations.md#tool-usage--mandatory). 13. **Always run `uip solution resource refresh` before `uip solution upload` or `uip maestro case debug`** — syncs resources from `bindings_v2.json` so Studio Web can resolve connector dependencies. +14. **Phase 4 (Validate) and Phase 5 (Ship) are mandatory — never skip.** Phase 4's full validate ALWAYS runs after Phase 3 completes. Phase 5's ship prompt (AskUserQuestion: `Run debug session` / `Publish to Studio Web` / `Done` / `Something else`) ALWAYS runs after Phase 4 succeeds, with the same prompt-discipline as Rule 10 — never skip for auto mode, non-interactive mode, or prior approval. The skill does not exit until the user selects `Done` from the Phase 5 prompt. Full contract in [`references/phased-execution.md`](references/phased-execution.md). ## Workflow -Three hard stops: **Planning** (sdd.md → tasks.md) → approve → **Phase 2a** (skeleton) → publish-for-review stop → **Phase 2b** (detail) → post-build. +Five phases, three hard stops: **Phase 1 Planning** (sdd.md → tasks.md) → approve → **Phase 2 Skeleton** → publish-for-review stop → **Phase 3 Detail** → **Phase 4 Validate** → **Phase 5 Ship** (mandatory prompt loop until `Done`). ### Phase 1 — Planning @@ -51,7 +52,7 @@ Read [references/planning.md](references/planning.md). Produces: HARD STOP: AskUserQuestion approval. Loop on `Request changes`. -### Phase 2a — Skeleton build +### Phase 2 — Skeleton build Read [references/implementation.md](references/implementation.md) + [references/phased-execution.md](references/phased-execution.md). Builds structural shape only: @@ -61,9 +62,9 @@ Read [references/implementation.md](references/implementation.md) + [references/ 4. Stages (Step 7), edges (Step 8) 5. Tasks — shape only (Step 9): non-connector with full `data.inputs[]` schema + empty values; connector with `typeId` + `connectionId` only (no `is describe`); unresolved as skeletons per Rule 7 6. Informational validate (Step 9.5.1) — do NOT halt on errors/warnings -7. **HARD STOP** (Step 9.5.2–9.5.5): `Publish for review` / `Skip publish and continue` / `Abort`. On `Publish`: `uip solution resource refresh --output json` then `uip solution upload`, print DesignerUrl, AskUserQuestion: `Continue to phase 2b` / `Abort`. On `Abort`: dump `build-issues.md`, exit (no cleanup). +7. **HARD STOP** (Step 9.5.2–9.5.5): `Publish for review` / `Skip publish and continue` / `Abort`. On `Publish`: `uip solution resource refresh --output json` then `uip solution upload`, print DesignerUrl, AskUserQuestion: `Continue to phase 3` / `Abort`. On `Abort`: dump `build-issues.md`, exit (no cleanup). -### Phase 2b — Detail build +### Phase 3 — Detail build Re-read `tasks.md` AND `caseplan.json` (Step 9.6). Then: @@ -71,9 +72,27 @@ Re-read `tasks.md` AND `caseplan.json` (Step 9.6). Then: 2. I/O binding all task classes (Step 9.8) — per [`plugins/variables/io-binding/impl-json.md`](references/plugins/variables/io-binding/impl-json.md) 3. Conditions all 4 scopes (Step 10) 4. SLA + escalation (Step 11) -5. Full validate (Step 12). Retry up to 3×; on 3rd failure AskUserQuestion: `Retry with fix` / `Pause for manual edit` / `Abort` -6. Dump `build-issues.md` (Step 12.1) -7. Post-build loop (Step 13) — AskUserQuestion until `Done` + +Phase 3 ends after Step 11. Do NOT validate, debug, or publish here — those are Phase 4 / Phase 5. + +### Phase 4 — Validate + +Always runs after Phase 3. Mandatory. + +1. Full validate (Step 12) — `uip maestro case validate` (no `--mode` flag). +2. On failure: agent triages errors and **directly edits `caseplan.json`** to fix them — do not re-run Phase 3 steps. Re-validate. Cap at 3 retries. +3. On 3rd failure: AskUserQuestion `Retry with fix` / `Pause for manual edit` / `Abort`. +4. Dump `build-issues.md` (Step 12.1). + +### Phase 5 — Ship + +Always runs after Phase 4 success. Mandatory user-gated loop. + +1. Report results (Step 13) — case path, build summary, validation status, skeletons, missing connections. +2. **HARD STOP — unconditional, every run.** AskUserQuestion: `Run debug session` / `Publish to Studio Web` / `Done` / `Something else`. Same prompt-discipline as Rule 10 — never skip for auto mode, non-interactive mode, prior approval. +3. On `Run debug session` (Step 14) — execute case, stream results. On debug error: agent triages from error message, directly edits `caseplan.json` to fix, re-runs debug. Cap at 3 retries; on 3rd failure surface the error to the user via AskUserQuestion `Retry` / `Pause for manual edit` / `Abort`. +4. On `Publish to Studio Web` (Step 15) — `uip solution resource refresh` + `uip solution upload`. Share returned DesignerUrl. +5. After debug or publish completes, return to the prompt. Loop until `Done`. ## Reference Navigation @@ -81,7 +100,7 @@ Re-read `tasks.md` AND `caseplan.json` (Step 9.6). Then: |---|---| | Plan tasks from sdd.md | [references/planning.md](references/planning.md) | | Execute tasks.md into a case | [references/implementation.md](references/implementation.md) | -| Phase 2a/2b split + hard stop contract | [references/phased-execution.md](references/phased-execution.md) | +| Phase contracts + hard stops + failure handling | [references/phased-execution.md](references/phased-execution.md) | | Edit caseplan.json directly | [references/case-editing-operations.md](references/case-editing-operations.md) | | Case JSON schema | [references/case-schema.md](references/case-schema.md) | | Surviving CLI commands (registry, validate, debug, runtime) | [references/case-commands.md](references/case-commands.md) | @@ -139,7 +158,7 @@ Re-read `tasks.md` AND `caseplan.json` (Step 9.6). Then: ## Anti-patterns - **Do NOT leave stages without an inbound edge.** Orphaned and unreachable. Every stage needs ≥1 inbound edge from Trigger or another stage. -- **Do NOT validate after each T-entry.** Intermediate states expected invalid. Run `validate` once at end of Phase 2a (informational) and once at end of Phase 2b (authoritative). +- **Do NOT validate after each T-entry.** Intermediate states expected invalid. Run `validate` once at end of Phase 2 (informational) and once in Phase 4 (authoritative). - **Do NOT batch multiple T-entries into one JSON write.** Each T-entry: own Read → mutate → Write cycle. Composing large in-memory JSON across stages/edges/tasks hides intermediate state, breaks review. - **Do NOT place multiple tasks in same lane.** FE renders same-lane tasks stacked — unreadable. Each task own `lane` index in `stageNode.data.tasks[laneIndex][]`. Lane is layout only, no execution semantics. - **Do NOT edit `content/*.bpmn`.** Auto-generated, will be overwritten. Edit `content/*.json` only. diff --git a/skills/uipath-maestro-case/references/bindings-v2-sync.md b/skills/uipath-maestro-case/references/bindings-v2-sync.md index 3c388a0d1..cc905ff26 100644 --- a/skills/uipath-maestro-case/references/bindings-v2-sync.md +++ b/skills/uipath-maestro-case/references/bindings-v2-sync.md @@ -8,8 +8,8 @@ Shared procedure for keeping `bindings_v2.json` in sync after any plugin writes Run at these two points only: -1. **End of Phase 2a Step 9** (after all non-connector tasks written) — covers all process/agent/rpa/action/api-workflow/case-management bindings -2. **End of Phase 2b Step 9.7** (after all connector tasks populated) — adds Connection bindings + populates IS cache +1. **End of Phase 2 Step 9** (after all non-connector tasks written) — covers all process/agent/rpa/action/api-workflow/case-management bindings +2. **End of Phase 3 Step 9.7** (after all connector tasks populated) — adds Connection bindings + populates IS cache Individual task plugins write root bindings to `caseplan.json` per-task as normal. The batch regeneration reads the full `root.data.uipath.bindings[]` once and converts everything in one pass. diff --git a/skills/uipath-maestro-case/references/case-commands.md b/skills/uipath-maestro-case/references/case-commands.md index 304c3581e..c64c3a833 100644 --- a/skills/uipath-maestro-case/references/case-commands.md +++ b/skills/uipath-maestro-case/references/case-commands.md @@ -138,7 +138,7 @@ uip maestro case debug --log-level debug --output json ## uip maestro case tasks describe -Read-only metadata fetch for a task type's input/output schema. Used during planning + Phase 2b execution to discover the per-resource schema. +Read-only metadata fetch for a task type's input/output schema. Used during planning + Phase 3 execution to discover the per-resource schema. ```bash uip maestro case tasks describe --type --id --output json diff --git a/skills/uipath-maestro-case/references/implementation.md b/skills/uipath-maestro-case/references/implementation.md index 1e5812f29..2fbb42e7c 100644 --- a/skills/uipath-maestro-case/references/implementation.md +++ b/skills/uipath-maestro-case/references/implementation.md @@ -1,12 +1,12 @@ # Implementation Phase: tasks.md → caseplan.json -Execute the approved `tasks.md` plan, building `caseplan.json` via direct JSON edits per plugin. Validate, then optionally debug or publish. +Execute the approved `tasks.md` plan, building `caseplan.json` via direct JSON edits per plugin. Validate (Phase 4), then ship via the user-gated debug / publish loop (Phase 5). > **Prerequisite:** The user must have explicitly approved `tasks.md` from the [Planning Phase](planning.md) before starting. > > **Input:** `tasks/tasks.md` — the complete handoff artifact. -> **Two sub-phases with a hard stop.** Execution is split into **Phase 2a** (skeleton build — structural nodes only) and **Phase 2b** (detail build — values, conditions, SLA). Between them, an **AskUserQuestion** hard stop lets the user optionally publish the skeleton to Studio Web for visual review before committing to detail work. Read [phased-execution.md](phased-execution.md) for the phase contract, informational Phase 2a validate, hard-stop prompt, re-entry protocol, and abort semantics. The step numbering below marks the phase boundary. +> **Four post-planning phases with hard stops.** Execution is split into **Phase 2** (skeleton build — structural nodes only), **Phase 3** (detail build — values, conditions, SLA), **Phase 4** (full validate, with agent-driven direct fixes on failure), and **Phase 5** (mandatory ship loop — debug + publish). Between Phase 2 and Phase 3, an **AskUserQuestion** hard stop lets the user optionally publish the skeleton to Studio Web for visual review before committing to detail work. After Phase 4 validates, Phase 5 enters another mandatory AskUserQuestion loop. Read [phased-execution.md](phased-execution.md) for the phase contracts, informational Phase 2 validate, hard-stop prompts, re-entry protocol, and abort semantics. The step numbering below marks the phase boundaries. ## Per-plugin execution @@ -30,7 +30,7 @@ Every plugin uses direct JSON writes via its `impl-json.md`. Cross-cutting mecha ## Issue Log — Initialize Before Step 6 -Before any build step, initialize an empty issue list **in the agent's reasoning** (not as a file, not via subprocess). All plugins append to this shared list during execution. Dump to `tasks/build-issues.md` via the Write tool after Step 12. See [`plugins/logging/impl-json.md`](plugins/logging/impl-json.md) for the entry format, severity levels, and file schema. +Before any build step, initialize an empty issue list **in the agent's reasoning** (not as a file, not via subprocess). All plugins append to this shared list during execution. Dump to `tasks/build-issues.md` via the Write tool in Phase 4 (after validate succeeds). See [`plugins/logging/impl-json.md`](plugins/logging/impl-json.md) for the entry format, severity levels, and file schema. ```text # pseudocode — kept in the agent's reasoning, not on disk @@ -39,9 +39,9 @@ issues = [] # shared across all steps --- -# Phase 2a — Skeleton build (Steps 6 – 9.5) +# Phase 2 — Skeleton build (Steps 6 – 9.5) -Steps 6 through 9.5 build the structural skeleton: solution, project, root case, global variables, stages, edges, triggers, and tasks without value binding. Full contract in [phased-execution.md § Phase 2a](phased-execution.md). +Steps 6 through 9.5 build the structural skeleton: solution, project, root case, global variables, stages, edges, triggers, and tasks without value binding. Full contract in [phased-execution.md § Phase 2](phased-execution.md). ## Step 6 — Create the Case project structure @@ -80,19 +80,19 @@ For each edge in `tasks.md §4.5`, execute per [`plugins/edges/impl-json.md`](pl For multi-trigger cases, add the additional triggers first via the appropriate trigger plugin, then wire their IDs as edge sources. -## Step 9 — Add tasks (Phase 2a shape) +## Step 9 — Add tasks (Phase 2 shape) -For each task entry in `tasks.md §4.6`, open the matching plugin's `impl-json.md`. **Capture the `TaskId`** — cross-task references and conditions in Phase 2b need it. +For each task entry in `tasks.md §4.6`, open the matching plugin's `impl-json.md`. **Capture the `TaskId`** — cross-task references and conditions in Phase 3 need it. -**Phase 2a writes task shape but defers value binding to Phase 2b.** Per-class shape: +**Phase 2 writes task shape but defers value binding to Phase 3.** Per-class shape: -| Task class | Phase 2a `data` content | +| Task class | Phase 2 `data` content | |---|---| | Non-connector (`process`, `agent`, `rpa`, `action`, `api-workflow`, `case-management`, `wait-for-timer`) | Full `data.inputs[]` schema from `uip maestro case tasks describe --type --id `. Each input's `value` is `""`. Outputs populated per plugin. | -| Connector (`connector-activity`, `connector-trigger`) | `data.typeId` + `data.connectionId` set. `data.inputs` omitted. **Do NOT call `is resources describe` / `is triggers describe` in 2a** — schema discovery happens in Phase 2b. | +| Connector (`connector-activity`, `connector-trigger`) | `data.typeId` + `data.connectionId` set. `data.inputs` omitted. **Do NOT call `is resources describe` / `is triggers describe` in Phase 2** — schema discovery happens in Phase 3. | | Unresolved (any class) | Skeleton task per Step 9.1 — empty `data: {}` plus action-only extras. | -**Do NOT bind input `value` fields in Step 9.** All literals, expressions, and cross-task references are written in Phase 2b Step 9.6 per [`plugins/variables/io-binding/impl-json.md`](plugins/variables/io-binding/impl-json.md). +**Do NOT bind input `value` fields in Step 9.** All literals, expressions, and cross-task references are written in Phase 3 Step 9.6 per [`plugins/variables/io-binding/impl-json.md`](plugins/variables/io-binding/impl-json.md). **Pass `lane: ` on every task** (or the plugin's equivalent JSON field), incrementing per task within a stage (starting at 0). Lane is a FE layout coordinate; it does not affect execution. @@ -115,7 +115,7 @@ After all non-connector tasks are written (Step 9), regenerate `bindings_v2.json ## Step 9.5 — Skeleton-mode validate + HARD STOP -End of Phase 2a. Full contract (summary content, prompt options, publish branch, abort cleanup, continue branch) in [phased-execution.md § Hard stop](phased-execution.md). This section is a bridge — do NOT duplicate that contract here. +End of Phase 2. Full contract (summary content, prompt options, publish branch, abort cleanup, continue branch) in [phased-execution.md § Hard stop](phased-execution.md). This section is a bridge — do NOT duplicate that contract here. 1. Run informational validate (regular, no `--mode` flag): @@ -123,28 +123,28 @@ End of Phase 2a. Full contract (summary content, prompt options, publish branch, uip maestro case validate "" --output json ``` - **Do NOT halt on errors or warnings.** Phase 2a output is expected invalid (unbound inputs, missing conditions, missing SLA — all filled in Phase 2b). Capture error + warning counts for the summary; do not attempt to classify "expected" vs "unexpected" errors. + **Do NOT halt on errors or warnings.** Phase 2 output is expected invalid (unbound inputs, missing conditions, missing SLA — all filled in Phase 3). Capture error + warning counts for the summary; do not attempt to classify "expected" vs "unexpected" errors. 2. Print the hard-stop summary, including the captured validate counts ([phased-execution.md § Summary content](phased-execution.md)). -3. Execute the hard-stop prompt + branches per [phased-execution.md § Prompt](phased-execution.md) and following sections. Unconditional — SKILL.md Rule #24. +3. Execute the hard-stop prompt + branches per [phased-execution.md § Prompt](phased-execution.md) and following sections. Unconditional — SKILL.md Rule #10. -On continue (either `Skip publish and continue` or `Continue to phase 2b` after publish): proceed to Step 9.6. +On continue (either `Skip publish and continue` or `Continue to phase 3` after publish): proceed to Step 9.6. --- -# Phase 2b — Detail build (Steps 9.6 – 13) +# Phase 3 — Detail build (Steps 9.6 – 11) -Steps 9.6 onwards wire connector task schemas, input/output values, conditions, and SLA. Full contract in [phased-execution.md § Phase 2b](phased-execution.md). +Steps 9.6 through 11 wire connector task schemas, input/output values, conditions, and SLA. Full contract in [phased-execution.md § Phase 3](phased-execution.md). -## Step 9.6 — Phase 2b re-entry +## Step 9.6 — Phase 3 re-entry -Before any 2b mutation: +Before any Phase 3 mutation: 1. **Re-read `tasks.md`** — per Rule 6 of `SKILL.md`. -2. **Re-read `caseplan.json`** — rebuild name → ID maps from the authoritative artifact. See [phased-execution.md § Phase 2b re-entry protocol](phased-execution.md) for which fields to index. +2. **Re-read `caseplan.json`** — rebuild name → ID maps from the authoritative artifact. See [phased-execution.md § Phase 3 re-entry protocol](phased-execution.md) for which fields to index. -Never trust in-memory maps from Phase 2a without re-reading `caseplan.json` — context may be compacted across the hard stop. +Never trust in-memory maps from Phase 2 without re-reading `caseplan.json` — context may be compacted across the hard stop. ## Step 9.7 — Connector task detail @@ -182,17 +182,25 @@ For each condition in `tasks.md §4.7`, open the matching plugin's `impl-json.md Group `tasks.md §4.8` entries by target (root or stage), then compose and write the full `slaRules[]` array per target in a single mutation per [`plugins/sla/impl-json.md`](plugins/sla/impl-json.md). Supports per-conditional-rule escalations, ExceptionStage SLA, and multi-recipient single rules. +Phase 3 ends after Step 11. Proceed to Phase 4. + +--- + +# Phase 4 — Validate (Step 12) + +Always runs after Phase 3 completes. Mandatory. Full contract in [phased-execution.md § Phase 4](phased-execution.md). + ## Step 12 — Full validate -End of Phase 2b mutations. Run full-mode validate (no `--mode` flag): +Run full-mode validate (no `--mode` flag): ```bash uip maestro case validate --output json ``` -On success: `{ Result: "Success", Code: "CaseValidate", Data: { File, Status: "Valid" } }` — proceed to Step 13. +On success: `{ Result: "Success", Code: "CaseValidate", Data: { File, Status: "Valid" } }` — proceed to Step 12.1. -On failure: output lists `[error]` and `[warning]` entries with path and message. Fix the reported issues (usually via a targeted re-run of the earlier step) and re-run `validate`. +On failure: output lists `[error]` and `[warning]` entries with path and message. **Triage from the validate output and directly edit `caseplan.json` to fix.** Do NOT re-run Phase 3 plugin steps — the agent has enough context (the validate error + the existing file) to make targeted fixes (add a missing condition rule, correct a binding expression, fix a malformed SLA target). Re-validate after each fix. **Retry policy.** Up to 3 validation retries per session. After the 3rd failure, halt and ask the user with **AskUserQuestion**: show the remaining errors and options — `Retry with fix`, `Pause for manual edit`, `Abort`. @@ -200,32 +208,44 @@ On failure: output lists `[error]` and `[warning]` entries with path and message Write the issue list to `tasks/build-issues.md` per [`plugins/logging/impl-json.md`](plugins/logging/impl-json.md), grouped by plugin with a summary index. This file is the source of truth for the completion report. Write it even if zero issues were logged (confirms a clean build). -## Step 13 — Post-build prompt +Phase 4 ends after Step 12.1. Proceed to Phase 5. + +--- + +# Phase 5 — Ship (Steps 13 – 15) -Once validation passes, report results then ask user what to do next. +Always runs after Phase 4 success. Mandatory user-gated loop. Full contract in [phased-execution.md § Phase 5](phased-execution.md). + +## Step 13 — Mandatory ship prompt + +Once validation passes, report results then enter the mandatory ship prompt loop. ### Report fields 1. File path of `caseplan.json` 2. What was built — summary of stages, edges, tasks, conditions, SLA -3. Validation status — `validate` pass/fail + remaining errors +3. Validation status — `validate` pass + retry count 4. Skeleton tasks + unresolved resources — list every skeleton (TaskId, type, display-name, stage) + external resource user must register (task-type-id / connection-id) + wiring-notes from `tasks.md`. See [skeleton-tasks.md](skeleton-tasks.md). 5. Missing connections — connector tasks needing IS connections that don't exist yet +### Hard-stop prompt + +**Unconditional, every run.** Same prompt-discipline as the Phase 2 → 3 hard stop. Never skip for auto mode, non-interactive mode, or prior approval. If the harness refuses interactive prompts, halt with an explicit error rather than proceeding silently. + Use **AskUserQuestion** with options: - `Run debug session` — proceed to Step 14. - `Publish to Studio Web` — proceed to Step 15. -- `Done` — exit. +- `Done` — exit the skill. - `Something else` — free-form prompt. -After debug or publish completes, return to this prompt so the user can chain the other action (e.g., debug first, then publish). Exit when the user selects `Done`. +After debug or publish completes, return to this prompt so the user can chain the other action (e.g., debug first, then publish). Exit only when the user selects `Done`. For further authoring changes (add a task, tweak a condition, etc.), the user updates `sdd.md` and re-runs the skill from Phase 1 — this skill does not offer in-place incremental edits. -## Step 14 — Optional: Debug session +## Step 14 — Debug session -> Debug executes the case for real — it will send emails, post messages, call APIs, write to databases. Only run debug when the user explicitly asks. Never run it automatically. +> **Run only on explicit user selection of `Run debug session` in Step 13.** Debug executes the case for real — it will send emails, post messages, call APIs, write to databases. Never run automatically. ```bash uip maestro case debug "//" --log-level debug --output json @@ -233,14 +253,23 @@ uip maestro case debug "//" --log-level de Requires `uip login`. Uploads to Studio Web, runs in Orchestrator, streams results. -## Step 15 — Optional: Publish to Studio Web +**On debug error** — `case debug` returns error messages (runtime exception, missing connection, bad input value, etc.). Triage from the error, **directly edit `caseplan.json` to fix** (same approach as Step 12 — agent has enough context to make targeted fixes), and re-run debug. + +**Retry policy.** Up to 3 debug retries per session. After the 3rd failure, surface the remaining error to the user via **AskUserQuestion**: `Retry`, `Pause for manual edit`, `Abort`. + +After debug success, return to the Step 13 prompt. + +## Step 15 — Publish to Studio Web **Default publish target.** Uploads the case to Studio Web for visualization and editing. ```bash +uip solution resource refresh "" --output json uip solution upload "" --output json ``` -Accepts the solution directory (the folder containing the `.uipx`) directly — no intermediate bundling step. `upload` pushes to Studio Web — share the returned URL with the user. +`upload` accepts the solution directory (the folder containing the `.uipx`) directly — no intermediate bundling step. Share the returned `DesignerUrl` with the user. > **Do NOT run `uip maestro case pack` + `uip solution publish` unless the user explicitly asks for Orchestrator deployment.** That path puts the case directly into Orchestrator, bypassing Studio Web. Default is always Studio Web. + +After publish success, return to the Step 13 prompt. diff --git a/skills/uipath-maestro-case/references/phased-execution.md b/skills/uipath-maestro-case/references/phased-execution.md index 511d8587a..aff192eba 100644 --- a/skills/uipath-maestro-case/references/phased-execution.md +++ b/skills/uipath-maestro-case/references/phased-execution.md @@ -1,24 +1,27 @@ -# Phased Execution: Phase 2a → Hard Stop → Phase 2b +# Phased Execution: Five Phases -Authoritative reference for the two-phase implementation flow. Read before executing any T-entry from an approved `tasks.md`. +Authoritative reference for the five-phase implementation flow. Read before executing any T-entry from an approved `tasks.md`. -> **Relationship to other docs.** This document defines the phase boundary. Per-plugin execution detail lives in `plugins//impl-json.md`. Per-step ordering and file-system mutations live in [implementation.md](implementation.md). +> **Relationship to other docs.** This document defines the phase contracts. Per-plugin execution detail lives in `plugins//impl-json.md`. Per-step ordering and file-system mutations live in [implementation.md](implementation.md). -## Why two phases +## Why phased execution -After `tasks.md` is approved, the skill does **not** build the full case in one pass. It first builds a **skeleton** — enough structure for the user to review the case graph visually in Studio Web — then hard-stops for approval before wiring the detail (I/O values, conditions, SLA). +After `tasks.md` is approved, the skill does **not** build the full case in one pass. It first builds a **skeleton** — enough structure for the user to review the case graph visually in Studio Web — then hard-stops for approval before wiring the detail (I/O values, conditions, SLA). After the detail is written, validation runs as its own phase, and shipping (debug + publish) runs as its own user-gated phase. -This gives the user a review checkpoint on the shape of the case before the agent commits to detail work that is costly to redo. +This split gives the user a review checkpoint on the shape of the case before the agent commits to detail work that is costly to redo, and ensures validate + ship can never be silently skipped. ## Phase boundaries -| Phase | What gets built | Output | +| Phase | What gets built / done | Output | |---|---|---| -| **2a — Skeleton build** | Solution + project, root case, global variables, stages, edges, triggers (full), tasks (name + type, no value binding), skeleton tasks for unresolved | `caseplan.json` emitted; validate run for info only (expected to report unbound inputs / missing conditions / missing SLA) | -| **Hard stop** | User reviews via Studio Web (optional), then approves / aborts | User choice captured via AskUserQuestion | -| **2b — Detail build** | Connector task schemas, task I/O value binding, conditions (all 4 scopes), SLA + escalation | `caseplan.json` passes full validation | +| **1 — Planning** | sdd.md → `tasks.md` + `registry-resolved.json` | Approved `tasks.md` | +| **2 — Skeleton build** | Solution + project, root case, global variables, stages, edges, triggers (full), tasks (name + type, no value binding), skeleton tasks for unresolved | `caseplan.json` emitted; informational validate run (expected to report unbound inputs / missing conditions / missing SLA) | +| **Hard stop (2 → 3)** | User reviews via Studio Web (optional), then approves / aborts | User choice captured via AskUserQuestion | +| **3 — Detail build** | Connector task schemas, task I/O value binding, conditions (all 4 scopes), SLA + escalation | `caseplan.json` ready for validation | +| **4 — Validate** | Authoritative full validate; agent fixes errors via direct `caseplan.json` edits and re-validates (cap 3 retries); dump `build-issues.md` | `caseplan.json` passes full validation | +| **5 — Ship** | Mandatory hard-stop AskUserQuestion loop: `Run debug session` / `Publish to Studio Web` / `Done` / `Something else`. Debug + publish are options inside the loop, not separate phases. | User exits via `Done` | -## Phase 2a — What gets written +## Phase 2 — What gets written ### Structural nodes (full detail) @@ -31,43 +34,43 @@ This gives the user a review checkpoint on the shape of the case before the agen ### Tasks (shape depends on resolution state + task class) -| Task class | Resolved resources | Phase 2a shape | +| Task class | Resolved resources | Phase 2 shape | |---|---|---| | 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 populated per plugin. | -| Connector (`connector-activity`, `connector-trigger`) | `type-id` + `connection-id` resolved | `data` contains `type-id` and `connection-id` only. `data.inputs` omitted or empty. **No `is resources describe` / `is triggers describe` call in 2a** — schema discovery is deferred to 2b. | +| Connector (`connector-activity`, `connector-trigger`) | `type-id` + `connection-id` resolved | `data` contains `type-id` and `connection-id` only. `data.inputs` omitted or empty. **No `is resources describe` / `is triggers describe` call in Phase 2** — schema discovery is deferred to Phase 3. | | Any task | Unresolved (`` in `tasks.md`) | Skeleton task per Rule 7 of `SKILL.md` — empty `data: {}` (plus `data.taskTitle` / `data.priority` / `data.recipient` for `action`). Marker preserved. See [skeleton-tasks.md](skeleton-tasks.md). | -### What does NOT get written in Phase 2a +### What does NOT get written in Phase 2 - Task input `value` bindings (literals, expressions, cross-task references). - Connector task input/output schemas. - Conditions of any scope (stage-entry, stage-exit, task-entry, case-exit). - SLA rules (default, conditional) and escalation rules. -## Phase 2a informational validate +## Phase 2 informational validate -At the end of Phase 2a, run regular validate: +At the end of Phase 2, run regular validate: ```bash uip maestro case validate "" --output json ``` -**This call is informational only — do NOT halt on errors or warnings.** Phase 2a state is expected to be invalid: unbound required input values, missing condition rules, missing terminal exit, missing secondary-stage exit conditions, missing SLA. All of those are resolved in Phase 2b. +**This call is informational only — do NOT halt on errors or warnings.** Phase 2 state is expected to be invalid: unbound required input values, missing condition rules, missing terminal exit, missing secondary-stage exit conditions, missing SLA. All of those are resolved in Phase 3. Capture the error and warning counts (and optionally the first few messages) and include them in the hard-stop summary. The user decides whether the skeleton is worth publishing/continuing, or whether something looks off and they want to `Abort` for inspection. **Do not parse the validate output for "expected" vs "unexpected" errors.** The skill does not try to classify validation errors at this boundary — if the user sees something that looks like a true structural bug (dangling edge, missing trigger, duplicate names), they choose `Abort` and fix it before re-running. Simpler, no false negatives from misclassification. -## Hard stop +## Hard stop (Phase 2 → Phase 3) -**Unconditional.** Present a summary, then prompt the user via AskUserQuestion. The prompt is MANDATORY on every run — auto mode, non-interactive mode, and prior blanket approval do NOT bypass it. The only valid transition from Phase 2a to Phase 2b is a user response to this AskUserQuestion. If the harness refuses interactive prompts, halt with an explicit error rather than proceeding silently. +**Unconditional.** Present a summary, then prompt the user via AskUserQuestion. The prompt is MANDATORY on every run — auto mode, non-interactive mode, and prior blanket approval do NOT bypass it. The only valid transition from Phase 2 to Phase 3 is a user response to this AskUserQuestion. If the harness refuses interactive prompts, halt with an explicit error rather than proceeding silently. ### Summary content Print before the prompt: 1. Counts: stages / primary stages / exception stages / edges / triggers / tasks total / skeleton tasks / unresolved resources. -2. Validate result (informational): ` errors, warnings` — call out that Phase 2a state is expected invalid (unbound inputs / missing conditions / missing SLA are all filled in Phase 2b). Surfacing the counts is enough; do not dump the full error list unless the user asks. +2. Validate result (informational): ` errors, warnings` — call out that Phase 2 state is expected invalid (unbound inputs / missing conditions / missing SLA are all filled in Phase 3). Surfacing the counts is enough; do not dump the full error list unless the user asks. 3. Paths: `caseplan.json`, `tasks.md`, `registry-resolved.json`. Do not enumerate every task. Studio Web visualization fills that role after publish. @@ -77,7 +80,7 @@ Do not enumerate every task. Studio Web visualization fills that role after publ Use **AskUserQuestion** with three options: - `Publish for review` — upload skeleton to Studio Web for visual review. -- `Skip publish and continue` — proceed directly to Phase 2b. +- `Skip publish and continue` — proceed directly to Phase 3. - `Abort` — stop the skill; leave artifacts in place. ### On `Publish for review` @@ -87,15 +90,15 @@ Use **AskUserQuestion** with three options: 3. **MUST emit DesignerUrl as plain-text output to the user BEFORE invoking AskUserQuestion**, on its own line: `Skeleton published. Review at: ` Never bundle the URL only into the question body — some renderers display the question before the surrounding prose, leaving the user without the URL until after they answer. -4. Only after the URL line has been emitted, invoke **AskUserQuestion** (second prompt): `Continue to phase 2b` / `Abort`. +4. Only after the URL line has been emitted, invoke **AskUserQuestion** (second prompt): `Continue to phase 3` / `Abort`. If `DesignerUrl` is missing from the response, dump the full upload response to `tasks/upload-response.json`, print that path, and continue to the prompt — the user can recover the URL from the file. -Do not warn the user about Studio Web edits being overwritten. Phase 2b's final Step 13 prompt re-publishes the completed case, which overwrites any volatile review-time edits with the final local state. The user can compare Studio Web state before and after Phase 2b to spot any edits they want to preserve. +Do not warn the user about Studio Web edits being overwritten. Phase 5's publish action re-publishes the completed case, which overwrites any volatile review-time edits with the final local state. The user can compare Studio Web state before and after Phase 3 to spot any edits they want to preserve. ### On `Skip publish and continue` -Proceed directly to Phase 2b. +Proceed directly to Phase 3. ### On `Abort` @@ -105,21 +108,21 @@ Proceed directly to Phase 2b. Do **not** delete any artifacts. The user may want to inspect them, or re-run the skill later (which regenerates `tasks.md` from scratch per Rule 5). -## Phase 2b re-entry protocol +## Phase 3 re-entry protocol -Phase 2b begins after the user selects `Continue to phase 2b` (or `Skip publish and continue`). Before executing any 2b step: +Phase 3 begins after the user selects `Continue to phase 3` (or `Skip publish and continue`). Before executing any Phase 3 step: 1. **Re-read `tasks.md`** — per Rule 6. The declarative plan is the handoff. -2. **Re-read `caseplan.json`** — the authoritative source of all IDs generated in Phase 2a: +2. **Re-read `caseplan.json`** — the 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`). - Trigger ID (from `schema.nodes[]` where `type === "case-management:Trigger"`). - Task name → TaskId per stage (from `schema.nodes[].data.tasks[][]`). - Variable name → `var` ID (from `root.data.uipath.variables.{inputs,outputs,inputOutputs}`). 3. Optionally cross-check against `id-map.json` if the JSON-strategy plugins wrote one. `caseplan.json` is the source of truth; `id-map.json` is a speed-up. -Never trust in-memory maps from Phase 2a without re-reading `caseplan.json` — context may be compacted across the hard stop. +Never trust in-memory maps from Phase 2 without re-reading `caseplan.json` — context may be compacted across the hard stop. -## Phase 2b — Execution order +## Phase 3 — Execution order After re-entry: @@ -128,18 +131,94 @@ After re-entry: 3. **Conditions** — per-scope plugin `impl-json.md`: - Stage entry conditions - Stage exit conditions - - Task entry conditions (depends on TaskIds from Phase 2a) + - Task entry conditions (depends on TaskIds from Phase 2) - 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. **Full validate** — `uip maestro case validate "" --output json` (no `--mode` flag; defaults to full). Retry policy per `SKILL.md` Anti-patterns ("Do NOT validate after each command"): validate once after full Phase 2b build; up to 3 retries. -6. **Dump `build-issues.md`** per [`plugins/logging/impl-json.md`](plugins/logging/impl-json.md). -7. **Post-build prompt** — existing Step 13 from [implementation.md](implementation.md): `Run debug session` / `Publish to Studio Web` / `Done` / `Something else`. + +Phase 3 ends after step 4. Do **not** validate, debug, or publish here — those are Phase 4 / Phase 5. + +## Phase 4 — Validate + +Always runs after Phase 3 completes. Mandatory. + +### Step order + +1. **Full validate** — `uip maestro case validate "" --output json` (no `--mode` flag; defaults to full). +2. **On failure**: agent reads the `[error]` / `[warning]` entries (each has a path + message), triages, and **directly edits `caseplan.json` to fix them**. Do **not** re-run Phase 3 plugin steps — the agent has enough context from the validate output and the existing file to make targeted fixes (e.g., add a missing condition rule, correct a binding expression, fix a malformed SLA target). Re-validate. Repeat up to 3 retries. +3. **On 3rd failure**: AskUserQuestion with the remaining errors and options — `Retry with fix` / `Pause for manual edit` / `Abort`. +4. **Dump `build-issues.md`** per [`plugins/logging/impl-json.md`](plugins/logging/impl-json.md). Write even if zero issues were logged (confirms a clean build). + +### Why direct edits, not plugin re-runs + +The agent has full context of the case at this point — it has the `tasks.md`, the assembled `caseplan.json`, and the validate error message. Fixing a single condition node, binding expression, or SLA rule via direct JSON edit is faster and more surgical than re-invoking a plugin's `impl-json.md` recipe. Plugin recipes are designed for greenfield writes, not error-driven repairs. + +### Failure recovery options + +- **`Retry with fix`** — user provides a hint or correction; agent applies it and re-validates. Counter resets. +- **`Pause for manual edit`** — user edits `caseplan.json` manually outside the skill; agent re-validates when the user resumes. +- **`Abort`** — dump `build-issues.md`, print paths, exit. Same cleanup as the Phase 2 → 3 hard-stop abort. + +## Phase 5 — Ship + +Always runs after Phase 4 success. Mandatory user-gated loop. + +### Report + +Before the prompt, report: + +1. File path of `caseplan.json`. +2. What was built — summary of stages, edges, tasks, conditions, SLA. +3. Validation status — `validate` pass + retry count. +4. Skeleton tasks + unresolved resources — list every skeleton (TaskId, type, display-name, stage) + external resource user must register (task-type-id / connection-id) + wiring-notes from `tasks.md`. See [skeleton-tasks.md](skeleton-tasks.md). +5. Missing connections — connector tasks needing IS connections that don't exist yet. + +### Hard-stop prompt + +**Unconditional.** Same prompt-discipline as the Phase 2 → 3 hard stop — never skip for auto mode, non-interactive mode, or prior approval. If the harness refuses interactive prompts, halt with an explicit error rather than proceeding silently. + +Use **AskUserQuestion** with options: + +- `Run debug session` — proceed to debug action. +- `Publish to Studio Web` — proceed to publish action. +- `Done` — exit the skill. +- `Something else` — free-form prompt. + +After debug or publish completes, return to this prompt so the user can chain the other action (e.g., debug first, then publish). Exit only when the user selects `Done`. + +### Debug action + +```bash +uip maestro case debug "//" --log-level debug --output json +``` + +> **Run only on explicit user selection of `Run debug session`.** Debug executes the case for real — sends emails, posts messages, calls APIs, writes to databases. + +Requires `uip login`. Uploads to Studio Web, runs in Orchestrator, streams results. + +**On debug error**: `case debug` returns error messages (runtime exception, missing connection, bad input value, etc.). Agent triages from the error, **directly edits `caseplan.json` to fix** (same approach as Phase 4 — agent has enough context to make targeted fixes), and re-runs debug. Cap at 3 retries. + +**On 3rd debug failure**: surface the error to the user via AskUserQuestion `Retry` / `Pause for manual edit` / `Abort`. Same recovery semantics as Phase 4. + +After debug success, return to the Phase 5 hard-stop prompt. + +### Publish action + +```bash +uip solution resource refresh "" --output json +uip solution upload "" --output json +``` + +**Default publish target is Studio Web.** Accepts the solution directory directly — no intermediate bundling step. Share the returned `DesignerUrl` with the user. + +> **Do NOT run `uip maestro case pack` + `uip solution publish` unless the user explicitly asks for Orchestrator deployment.** That path puts the case directly into Orchestrator, bypassing Studio Web. + +After publish success, return to the Phase 5 hard-stop prompt. ## Skeleton tasks — unchanged semantics -Skeleton tasks (empty `data: {}` for unresolved resources) behave the same in both phases. Phase 2a creates them; Phase 2b does **not** upgrade them to typed tasks — upgrading requires the user to register the missing resource externally. See [skeleton-tasks.md](skeleton-tasks.md). +Skeleton tasks (empty `data: {}` for unresolved resources) behave the same in both build phases. Phase 2 creates them; Phase 3 does **not** upgrade them to typed tasks — upgrading requires the user to register the missing resource externally. See [skeleton-tasks.md](skeleton-tasks.md). -Phase 2b still wires skeleton TaskIds into: +Phase 3 still wires skeleton TaskIds into: - Task-entry conditions that reference the skeleton. - Stage-exit `selected-tasks-completed` rules that include the skeleton. @@ -147,21 +226,24 @@ It does **not** write `data.inputs` / `data.outputs` for skeletons. Input bindin ## Abort semantics -Abort can occur at either hard-stop prompt: +Abort can occur at any of these prompts: -- `Abort` at the first prompt (`Publish for review` / `Skip` / `Abort`). -- `Abort` at the second prompt (`Continue to phase 2b` / `Abort`) after publishing. +- Phase 2 → 3 hard stop, first prompt: `Publish for review` / `Skip` / `Abort`. +- Phase 2 → 3 hard stop, second prompt: `Continue to phase 3` / `Abort` (after publishing). +- Phase 4 retry exhaustion prompt: `Retry with fix` / `Pause for manual edit` / `Abort`. +- Phase 5 debug retry exhaustion prompt: `Retry` / `Pause for manual edit` / `Abort`. -Both follow the same cleanup: +All follow the same cleanup: 1. Dump `build-issues.md`. -2. Print paths. +2. Print paths of `caseplan.json`, `tasks.md`, `registry-resolved.json`, and the solution directory. 3. Exit. No artifact deletion. No rollback. The user owns the partial state. ## Out of scope -- **Re-ingesting Studio Web edits.** If the user edits the published skeleton in Studio Web during review, those edits are not round-tripped back into local `caseplan.json`. Phase 2b writes on top of local state; the final Step 13 re-publish overwrites Studio Web with the completed local build. -- **Resuming an aborted session.** Re-running the skill regenerates `tasks.md` from scratch (Rule 5) and re-executes both phases from Phase 2a Step 1. -- **A dedicated skeleton validation mode.** The skill does not depend on a `--mode skeleton` CLI flag. Regular `uip maestro case validate` runs at end of Phase 2a for informational output only; expected Phase 2a errors are not filtered or classified here. +- **Re-ingesting Studio Web edits.** If the user edits the published skeleton in Studio Web during review, those edits are not round-tripped back into local `caseplan.json`. Phase 3 writes on top of local state; the Phase 5 publish overwrites Studio Web with the completed local build. +- **Resuming an aborted session.** Re-running the skill regenerates `tasks.md` from scratch (Rule 5) and re-executes all phases from Phase 2 Step 1. +- **A dedicated skeleton validation mode.** The skill does not depend on a `--mode skeleton` CLI flag. Regular `uip maestro case validate` runs at end of Phase 2 for informational output only; expected Phase 2 errors are not filtered or classified here. +- **Back-edges from Phases 1–3.** Phases 1 through 3 are forward-only. Failures within them follow each plugin's graceful-degradation contract (log to issue list, continue), not back-edges to earlier phases. Only Phase 4 and Phase 5 have failure recovery loops, and those recover via direct `caseplan.json` edits, not by re-running earlier phases' plugin steps. diff --git a/skills/uipath-maestro-case/references/plugins/conditions/case-exit-conditions/impl-json.md b/skills/uipath-maestro-case/references/plugins/conditions/case-exit-conditions/impl-json.md index 0d7e63130..0de8d912a 100644 --- a/skills/uipath-maestro-case/references/plugins/conditions/case-exit-conditions/impl-json.md +++ b/skills/uipath-maestro-case/references/plugins/conditions/case-exit-conditions/impl-json.md @@ -1,6 +1,6 @@ # case-exit-conditions — Implementation (Direct JSON Write) -> **Phase split.** Phase 2b only. Phase 2a does not write conditions. See [`../../../phased-execution.md`](../../../phased-execution.md). +> **Phase split.** Phase 3 only. Phase 2 does not write conditions. See [`../../../phased-execution.md`](../../../phased-execution.md). Write the case-exit condition directly into the `root` object's `caseExitConditions[]` array in `caseplan.json`. No CLI command needed. diff --git a/skills/uipath-maestro-case/references/plugins/conditions/stage-entry-conditions/impl-json.md b/skills/uipath-maestro-case/references/plugins/conditions/stage-entry-conditions/impl-json.md index 82c73ed82..cde8259b8 100644 --- a/skills/uipath-maestro-case/references/plugins/conditions/stage-entry-conditions/impl-json.md +++ b/skills/uipath-maestro-case/references/plugins/conditions/stage-entry-conditions/impl-json.md @@ -1,6 +1,6 @@ # stage-entry-conditions — Implementation (Direct JSON Write) -> **Phase split.** Phase 2b only. Phase 2a does not write conditions. See [`../../../phased-execution.md`](../../../phased-execution.md). +> **Phase split.** Phase 3 only. Phase 2 does not write conditions. See [`../../../phased-execution.md`](../../../phased-execution.md). Write the stage-entry condition directly to the target stage's `data.entryConditions[]`. No CLI command needed. diff --git a/skills/uipath-maestro-case/references/plugins/conditions/stage-exit-conditions/impl-json.md b/skills/uipath-maestro-case/references/plugins/conditions/stage-exit-conditions/impl-json.md index 1ad12b002..a1afc6048 100644 --- a/skills/uipath-maestro-case/references/plugins/conditions/stage-exit-conditions/impl-json.md +++ b/skills/uipath-maestro-case/references/plugins/conditions/stage-exit-conditions/impl-json.md @@ -1,6 +1,6 @@ # stage-exit-conditions — Implementation (Direct JSON Write) -> **Phase split.** Phase 2b only. Phase 2a does not write conditions. See [`../../../phased-execution.md`](../../../phased-execution.md). +> **Phase split.** Phase 3 only. Phase 2 does not write conditions. See [`../../../phased-execution.md`](../../../phased-execution.md). Write the stage-exit condition directly to the target stage's `data.exitConditions[]`. No CLI command needed. diff --git a/skills/uipath-maestro-case/references/plugins/conditions/task-entry-conditions/impl-json.md b/skills/uipath-maestro-case/references/plugins/conditions/task-entry-conditions/impl-json.md index cb3aefa07..57189b75d 100644 --- a/skills/uipath-maestro-case/references/plugins/conditions/task-entry-conditions/impl-json.md +++ b/skills/uipath-maestro-case/references/plugins/conditions/task-entry-conditions/impl-json.md @@ -1,6 +1,6 @@ # task-entry-conditions — Implementation (Direct JSON Write) -> **Phase split.** Phase 2b only. Phase 2a does not write conditions. See [`../../../phased-execution.md`](../../../phased-execution.md). +> **Phase split.** Phase 3 only. Phase 2 does not write conditions. See [`../../../phased-execution.md`](../../../phased-execution.md). Write the task-entry condition directly to the target task's `entryConditions[]`. No CLI command needed. diff --git a/skills/uipath-maestro-case/references/plugins/sla/impl-json.md b/skills/uipath-maestro-case/references/plugins/sla/impl-json.md index 46f9aae63..41aa51d21 100644 --- a/skills/uipath-maestro-case/references/plugins/sla/impl-json.md +++ b/skills/uipath-maestro-case/references/plugins/sla/impl-json.md @@ -4,7 +4,7 @@ direct-json: supported # sla — JSON Implementation -> **Phase split.** Phase 2b only. Phase 2a does not write SLA or escalation rules. See [`../../phased-execution.md`](../../phased-execution.md). +> **Phase split.** Phase 3 only. Phase 2 does not write SLA or escalation rules. See [`../../phased-execution.md`](../../phased-execution.md). Cross-cutting direct-JSON rules live in [`case-editing-operations.md`](../../case-editing-operations.md). diff --git a/skills/uipath-maestro-case/references/plugins/tasks/action/impl-json.md b/skills/uipath-maestro-case/references/plugins/tasks/action/impl-json.md index 992bef09a..0e1934b52 100644 --- a/skills/uipath-maestro-case/references/plugins/tasks/action/impl-json.md +++ b/skills/uipath-maestro-case/references/plugins/tasks/action/impl-json.md @@ -1,6 +1,6 @@ # action task — Implementation (Direct JSON Write) -> **Phase split.** Phase 2a writes shape with empty input values. Phase 2b binds values per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). See [phased-execution.md](../../../phased-execution.md). +> **Phase split.** Phase 2 writes shape with empty input values. Phase 3 binds values per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). See [phased-execution.md](../../../phased-execution.md). ## Task JSON Shape @@ -70,7 +70,7 @@ Both share `resourceKey` = `.`. ID: `b` + 8 chars. Deduplicate 4. Write `data.inputs[]` / `data.outputs[]` from Step 0 schema. Each input: `{ name, type, id, var, elementId, value: "" }`. Each output: `{ name, type, id, var, value, source, target, elementId }`. 5. Append to target stage's `tasks[laneIndex][]` -> Entry conditions added in Step 10. Input value bindings in Phase 2b per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). +> Entry conditions added in Step 10. Input value bindings in Phase 3 per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). ## Post-Write Verification diff --git a/skills/uipath-maestro-case/references/plugins/tasks/agent/impl-json.md b/skills/uipath-maestro-case/references/plugins/tasks/agent/impl-json.md index 6f9d621e3..0da4d691e 100644 --- a/skills/uipath-maestro-case/references/plugins/tasks/agent/impl-json.md +++ b/skills/uipath-maestro-case/references/plugins/tasks/agent/impl-json.md @@ -1,6 +1,6 @@ # agent task — Implementation (Direct JSON Write) -> **Phase split.** Phase 2a writes shape with empty input values. Phase 2b binds values per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). See [phased-execution.md](../../../phased-execution.md). +> **Phase split.** Phase 2 writes shape with empty input values. Phase 3 binds values per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). See [phased-execution.md](../../../phased-execution.md). ## Task JSON Shape @@ -54,7 +54,7 @@ Both share `resourceKey` = `.`. ID: `b` + 8 chars. Deduplicate 3. Write `data.inputs[]` / `data.outputs[]` from Step 0 schema. Each input: `{ name, type, id, var, elementId, value: "" }`. Each output: `{ name, type, id, var, value, source, target, elementId }`. 4. Append to target stage's `tasks[laneIndex][]` -> Entry conditions added in Step 10. Input value bindings in Phase 2b per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). +> Entry conditions added in Step 10. Input value bindings in Phase 3 per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). ## Post-Write Verification diff --git a/skills/uipath-maestro-case/references/plugins/tasks/api-workflow/impl-json.md b/skills/uipath-maestro-case/references/plugins/tasks/api-workflow/impl-json.md index 6b51942db..c7ccff3ce 100644 --- a/skills/uipath-maestro-case/references/plugins/tasks/api-workflow/impl-json.md +++ b/skills/uipath-maestro-case/references/plugins/tasks/api-workflow/impl-json.md @@ -1,6 +1,6 @@ # api-workflow task — Implementation (Direct JSON Write) -> **Phase split.** Phase 2a writes shape with empty input values. Phase 2b binds values per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). See [phased-execution.md](../../../phased-execution.md). +> **Phase split.** Phase 2 writes shape with empty input values. Phase 3 binds values per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). See [phased-execution.md](../../../phased-execution.md). ## Task JSON Shape @@ -52,7 +52,7 @@ Both share `resourceKey` = `.`. ID: `b` + 8 chars. Deduplicate 3. Write `data.inputs[]` / `data.outputs[]` from Step 0 schema. Each input: `{ name, type, id, var, elementId, value: "" }`. Each output: `{ name, type, id, var, value, source, target, elementId }`. 4. Append to target stage's `tasks[laneIndex][]` -> Entry conditions added in Step 10. Input value bindings in Phase 2b per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). +> Entry conditions added in Step 10. Input value bindings in Phase 3 per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). ## Post-Write Verification diff --git a/skills/uipath-maestro-case/references/plugins/tasks/case-management/impl-json.md b/skills/uipath-maestro-case/references/plugins/tasks/case-management/impl-json.md index 6e7910f64..88bbf6dd7 100644 --- a/skills/uipath-maestro-case/references/plugins/tasks/case-management/impl-json.md +++ b/skills/uipath-maestro-case/references/plugins/tasks/case-management/impl-json.md @@ -1,6 +1,6 @@ # case-management task — Implementation (Direct JSON Write) -> **Phase split.** Phase 2a writes shape with empty input values. Phase 2b binds values per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). See [phased-execution.md](../../../phased-execution.md). +> **Phase split.** Phase 2 writes shape with empty input values. Phase 3 binds values per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). See [phased-execution.md](../../../phased-execution.md). ## Task JSON Shape @@ -53,7 +53,7 @@ Both share `resourceKey` = `.`. ID: `b` + 8 chars. Deduplicate 4. Write `data.inputs[]` / `data.outputs[]` from Step 0 schema. Each input: `{ name, type, id, var, elementId, value: "" }`. Each output: `{ name, type, id, var, value, source, target, elementId }`. 5. Append to target stage's `tasks[laneIndex][]` -> Entry conditions added in Step 10. Input value bindings in Phase 2b per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). +> Entry conditions added in Step 10. Input value bindings in Phase 3 per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). ## Post-Write Verification diff --git a/skills/uipath-maestro-case/references/plugins/tasks/connector-activity/impl-json.md b/skills/uipath-maestro-case/references/plugins/tasks/connector-activity/impl-json.md index ca3f5595d..f5196ed38 100644 --- a/skills/uipath-maestro-case/references/plugins/tasks/connector-activity/impl-json.md +++ b/skills/uipath-maestro-case/references/plugins/tasks/connector-activity/impl-json.md @@ -1,6 +1,6 @@ # connector-activity task — Implementation (Direct JSON Write) -> **Phase split.** Runs across both phases. Phase 2a writes `data.type-id` + `data.connection-id` only; **do NOT call `is resources describe` in 2a**. Phase 2b runs `is resources describe`, writes `data.inputs[]` / `data.outputs[]` schema, then binds values. See [`../../../phased-execution.md`](../../../phased-execution.md). +> **Phase split.** Runs across both phases. Phase 2 writes `data.type-id` + `data.connection-id` only; **do NOT call `is resources describe` in Phase 2**. Phase 3 runs `is resources describe`, writes `data.inputs[]` / `data.outputs[]` schema, then binds values. See [`../../../phased-execution.md`](../../../phased-execution.md). Fetch connector metadata via CLI, then write the task directly into `caseplan.json`. Field discovery and reference resolution are done during [planning](planning.md) — implementation reads resolved values from `tasks.md`. diff --git a/skills/uipath-maestro-case/references/plugins/tasks/connector-trigger/impl-json.md b/skills/uipath-maestro-case/references/plugins/tasks/connector-trigger/impl-json.md index e9c2c218e..a495f0e9b 100644 --- a/skills/uipath-maestro-case/references/plugins/tasks/connector-trigger/impl-json.md +++ b/skills/uipath-maestro-case/references/plugins/tasks/connector-trigger/impl-json.md @@ -1,6 +1,6 @@ # connector-trigger task — Implementation (Direct JSON Write) -> **Phase split.** Runs across both phases. Phase 2a writes `data.type-id` + `data.connection-id` only; **do NOT call `is triggers describe` in 2a**. Phase 2b runs `is triggers describe`, writes `data.inputs[]` / `data.outputs[]` schema, then binds values. See [`../../../phased-execution.md`](../../../phased-execution.md). +> **Phase split.** Runs across both phases. Phase 2 writes `data.type-id` + `data.connection-id` only; **do NOT call `is triggers describe` in Phase 2**. Phase 3 runs `is triggers describe`, writes `data.inputs[]` / `data.outputs[]` schema, then binds values. See [`../../../phased-execution.md`](../../../phased-execution.md). Write a `wait-for-connector` task directly into `caseplan.json`. Field discovery and reference resolution are done during [planning](planning.md). diff --git a/skills/uipath-maestro-case/references/plugins/tasks/process/impl-json.md b/skills/uipath-maestro-case/references/plugins/tasks/process/impl-json.md index fe78a60ae..82c31d603 100644 --- a/skills/uipath-maestro-case/references/plugins/tasks/process/impl-json.md +++ b/skills/uipath-maestro-case/references/plugins/tasks/process/impl-json.md @@ -1,6 +1,6 @@ # process task — Implementation (Direct JSON Write) -> **Phase split.** Phase 2a writes shape with empty input values. Phase 2b binds values per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). See [phased-execution.md](../../../phased-execution.md). +> **Phase split.** Phase 2 writes shape with empty input values. Phase 3 binds values per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). See [phased-execution.md](../../../phased-execution.md). ## Task JSON Shape @@ -52,7 +52,7 @@ Both share `resourceKey` = `.`. ID: `b` + 8 chars. Deduplicate 3. Write `data.inputs[]` / `data.outputs[]` from Step 0 schema. Each input: `{ name, type, id, var, elementId, value: "" }`. Each output: `{ name, type, id, var, value, source, target, elementId }`. 4. Append to target stage's `tasks[laneIndex][]` -> Entry conditions added in Step 10. Input value bindings in Phase 2b per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). +> Entry conditions added in Step 10. Input value bindings in Phase 3 per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). ## Post-Write Verification diff --git a/skills/uipath-maestro-case/references/plugins/tasks/rpa/impl-json.md b/skills/uipath-maestro-case/references/plugins/tasks/rpa/impl-json.md index 48a91da17..c46690ec1 100644 --- a/skills/uipath-maestro-case/references/plugins/tasks/rpa/impl-json.md +++ b/skills/uipath-maestro-case/references/plugins/tasks/rpa/impl-json.md @@ -1,6 +1,6 @@ # rpa task — Implementation (Direct JSON Write) -> **Phase split.** Phase 2a writes shape with empty input values. Phase 2b binds values per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). See [phased-execution.md](../../../phased-execution.md). +> **Phase split.** Phase 2 writes shape with empty input values. Phase 3 binds values per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). See [phased-execution.md](../../../phased-execution.md). ## Task JSON Shape @@ -53,7 +53,7 @@ Both share `resourceKey` = `.`. ID: `b` + 8 chars. Deduplicate 3. Write `data.inputs[]` / `data.outputs[]` from Step 0 schema. Each input: `{ name, type, id, var, elementId, value: "" }`. Each output: `{ name, type, id, var, value, source, target, elementId }`. 4. Append to target stage's `tasks[laneIndex][]` -> Entry conditions added in Step 10. Input value bindings in Phase 2b per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). +> Entry conditions added in Step 10. Input value bindings in Phase 3 per [io-binding/impl-json.md](../../variables/io-binding/impl-json.md). ## Post-Write Verification diff --git a/skills/uipath-maestro-case/references/plugins/tasks/wait-for-timer/impl-json.md b/skills/uipath-maestro-case/references/plugins/tasks/wait-for-timer/impl-json.md index 7d374c0ca..0c69b76f1 100644 --- a/skills/uipath-maestro-case/references/plugins/tasks/wait-for-timer/impl-json.md +++ b/skills/uipath-maestro-case/references/plugins/tasks/wait-for-timer/impl-json.md @@ -1,6 +1,6 @@ # wait-for-timer task — Implementation (Direct JSON Write) -> **Phase split.** Written in Phase 2a only. The timer task has no variable inputs to bind — `timerType` + duration come from `tasks.md` planning. Phase 2b does not revisit this plugin. See [`../../../phased-execution.md`](../../../phased-execution.md). +> **Phase split.** Written in Phase 2 only. The timer task has no variable inputs to bind — `timerType` + duration come from `tasks.md` planning. Phase 3 does not revisit this plugin. See [`../../../phased-execution.md`](../../../phased-execution.md). Write the timer task directly to `caseplan.json`. No CLI command needed. diff --git a/skills/uipath-maestro-case/references/plugins/variables/io-binding/impl-json.md b/skills/uipath-maestro-case/references/plugins/variables/io-binding/impl-json.md index c7c596f1b..8e09e911e 100644 --- a/skills/uipath-maestro-case/references/plugins/variables/io-binding/impl-json.md +++ b/skills/uipath-maestro-case/references/plugins/variables/io-binding/impl-json.md @@ -1,6 +1,6 @@ # I/O Binding — Implementation -> **Phase split.** Phase 2b only (Step 9.8). Phase 2a writes task shape (schema with empty `value` fields) but does not bind values. See [`../../../phased-execution.md`](../../../phased-execution.md). +> **Phase split.** Phase 3 only (Step 9.8). Phase 2 writes task shape (schema with empty `value` fields) but does not bind values. See [`../../../phased-execution.md`](../../../phased-execution.md). Wire task inputs by editing `caseplan.json` directly. Runs after all tasks are created and enriched (Step 9) and after global variable + output wiring is complete.