@uipath/skills 1.195.0

package/skills/uipath-planner/references/non-pdd-lane-guide.md

@@ -0,0 +1,184 @@
+# Non-PDD Lane Guide
+
+When the planner is invoked without an SDD (the entry guard found no `## Planner Handoff` marker, or the user picked "Other context" at the entry guard prompt), it runs Lane B — elicit preferences, detect project type, write a plan, hand off to specialists. This guide covers Lane B end-to-end.
+
+> Lane B is appropriate for non-trivial UiPath requests without a PDD: ambiguous tasks, multi-skill orchestration, project-type detection from the filesystem. For trivial single-skill tasks, the main agent should load the specialist directly without the planner.
+
+## Step 1 — Upfront elicitation (batched)
+
+Bundle every unresolved question from the table below into **one** `AskUserQuestion` call. Do not ask one at a time; do not split across turns. If a question is already resolved from the user's request, omit it from the batch. If **all** are resolved, do not call `AskUserQuestion` at all and record the inferred values in the plan header with a one-line note in Decisions & Trade-offs.
+
+### Skip-rules table (apply before building the batch)
+
+| Question | Skip when | Default if skipped |
+|---|---|---|
+| Q1 Generation approach | Request is simple and well-defined; the user is modifying an existing automation; or the task is single-skill single-step. | `simultaneous` |
+| Q2 Execution autonomy | Explore-first mode (the approval gate at plan time already scopes autonomy). | `autonomous` |
+| Q3 Project type fallback | Project type resolves via explicit naming, keyword signals, or filesystem (Step 3) — see "Project type" below. | `RPA workflow (XAML)` |
+| Q5 Solution scope (Flow only) | Plan does not load `uipath-maestro-flow`; OR the user already stated intent (e.g., "upload to Studio Web", "keep it local", "just build it"); OR the plan contains no generation skill. | Omit `Solution scope` field from the plan header entirely. |
+
+The batch contains only the questions that survive the skip rules. Build the `AskUserQuestion` call as one tool invocation with one `questions` array entry per surviving item.
+
+### Question 1 — Generation approach
+
+> How would you like me to work?
+>
+> 1. **Explore first, then plan** — analyze the project and requirements, run non-mutating discovery, then present a plan for approval before any project changes *(recommended for non-trivial requests)*
+> 2. **Explore, plan, and execute simultaneously** — emit the plan as text and the main agent starts executing right away
+
+**If "explore first, then plan":**
+- You may run non-mutating discovery: `uip rpa analyze`, `uip rpa get-errors`, reading `project.json`.
+- Do NOT run commands that mutate the project (create files, register targets, install packages) — those belong to execution.
+- After Steps 2–4, call `EnterPlanMode` with the plan. User approves → `ExitPlanMode`.
+
+**If "explore, plan, and execute simultaneously":**
+- Emit the plan as text in Step 5. The main agent loads the first specialist skill immediately and follows that skill's own workflow.
+- Do NOT call `EnterPlanMode`.
+
+### Question 2 — Execution autonomy
+
+> Once execution starts, how should I handle ambiguity or scope concerns?
+>
+> 1. **Autonomous to completion** *(recommended)* — follow the plan end-to-end without stopping for confirmation. Specialist skills handle their own pause points (auth failure, UI capture limits, etc.).
+> 2. **Interactive** — pause and confirm on structural decisions, scope concerns, or side-effect actions during execution.
+
+Record the answer in the plan header as `Execution autonomy: autonomous | interactive`. Specialist skills read this field at runtime — in autonomous mode they do NOT re-ask decisions the plan already makes.
+
+### Project type — infer first, ask only if vague
+
+Resolve project type without asking when possible. Stop at the first match:
+
+1. **User explicitly named a mode** ("xaml workflow", "coded workflow", "C# workflow", ".cs file", "low-code") → honor it. Record `Project type: XAML` or `Project type: C# coded` in the plan header.
+2. **Keyword signals** (look for these in the user's request, but do not echo them as labels) →
+   - "agent", "AI agent", "agentic", "LLM", "LangGraph", "LlamaIndex", "OpenAI Agents" → **AI Agent**
+   - "flow", "orchestrate multiple automations", `.flow` → **Flow**
+   - "web app", "app", "React", "Angular", "Vue", `.uipath/` → **Application**
+3. **Filesystem signals** (Step 3) → route per the Step 3 table.
+4. **Default** → **RPA workflow (XAML)**. Covers ~95% of UiPath work — UI automation, form-fill, Excel / email / file ops.
+
+If the request is genuinely vague ("I want to build something with UiPath") AND no keyword or filesystem signals apply, **add Q3 to the Step 1 batch** — do not fire it as a separate `AskUserQuestion` call:
+
+> Q3 — What kind of project should I scaffold?
+>
+> 1. **RPA workflow** — UI automation, Excel / email / file work *(recommended — covers ~95% of UiPath work)*
+> 2. **AI Agent** — autonomous agent that reasons with an LLM and calls tools
+> 3. **Flow** — visual node-based orchestration connecting multiple automations
+> 4. **Application** — custom UI deployed as a UiPath App
+
+If the user picks **RPA workflow**, record `Project type: XAML` and move on. **Never follow up with "XAML or C#?"** — that authoring-mode decision belongs to `uipath-rpa`, not the planner. Coded mode is set only when the user independently says "coded workflow" or ".cs file" (which rule 1 above already honors); never as a follow-up.
+
+### Question 5 — Solution scope (Flow projects only)
+
+**Include this question in the Step 1 batch only when the plan loads `uipath-maestro-flow`.** For RPA / AI Agent / Application plans, omit the question entirely **and omit the `Solution scope` field from the plan header** — no other specialist reads it.
+
+> Where should this Flow solution live?
+>
+> 1. **SW solution** — build and iterate in Studio Web.
+> 2. **Local solution** — build and iterate locally in VSCode.
+
+Record the answer in the plan header as `Solution scope: SW | local`. `uipath-maestro-flow` reads this field at runtime to decide whether to publish at the end.
+
+**Skip Q5** (and omit the field from the header) when:
+
+- The plan does not load `uipath-maestro-flow`.
+- The user's request already states the intent (e.g., "upload to Studio Web", "keep it local", "just build it") — record directly.
+- The plan contains no generation skill (pure diagnostics, pure `uipath-platform` ops, pure read-only work).
+
+### Default — Expression language
+
+Always use **VB.NET** for XAML workflows. Note this in the plan. Do not ask.
+
+## Step 2 — Detect multi-skill requests
+
+Before filesystem detection (Step 3), check whether the request matches a multi-skill pattern. Multi-skill requests usually combine "build" + "deploy", "build" + "verify", or one product depending on another.
+
+See [multi-skill-patterns-guide.md](multi-skill-patterns-guide.md) for the 6 named patterns. If the request matches one, emit a multi-skill plan in that pattern's order. Otherwise, treat it as single-skill and proceed to Step 3.
+
+## Step 3 — Filesystem detection (single-skill requests)
+
+> **Check first:** if the request mentions deploy / publish / Orchestrator alongside a clear domain, it likely needs a multi-skill plan from Step 2.
+
+Probe the project context:
+
+```bash
+echo "=== CWD ===" && ls -1 project.json *.cs *.xaml *.py pyproject.toml flow_files/*.flow .uipath/ app.config.json .venv/ 2>/dev/null; \
+echo "=== PARENT ===" && ls -1 ../project.json ../*.cs ../*.xaml ../pyproject.toml 2>/dev/null; \
+echo "=== FRAMEWORK ===" && cat project.json 2>/dev/null | grep -o '"targetFramework"[^,}]*' || echo "targetFramework: not found"; \
+echo "=== DONE ==="
+```
+
+| Filesystem signal | Plan skill |
+|---|---|
+| `.xaml` AND/OR `.cs` files + `project.json` | `uipath-rpa` |
+| `flow_files/*.flow` | `uipath-maestro-flow` |
+| `.uipath/` or `app.config.json` | `uipath-coded-apps` |
+| `.venv/` AND `pyproject.toml` with uipath dependency | `uipath-agents` |
+| `project.json` only (no `.cs`/`.xaml`) | `uipath-rpa` |
+
+**Multiple signals?** Go back to Step 2 and emit a multi-skill plan.
+
+**No signals?** Use Step 1 answers. If still undetermined, plan with best available info and note the assumption.
+
+## Step 4 — UI element targeting (only when the plan includes UI automation)
+
+If the plan loads `uipath-rpa` for a workflow that clicks, types into, or reads elements in a desktop or browser app, ask the three UI questions in **one batched** `AskUserQuestion` call (see [pdd-driven-lane-guide.md → Step 5](pdd-driven-lane-guide.md#step-5--ui-element-targeting-only-when-9-contains-ui-applications) for the exact wording — same questions, same skip rules apply). Skip any question already resolved from the user's request.
+
+Skip the entire batch for non-UI plans (pure data processing, API calls, agent-only, flow-only).
+
+Record the answers in the plan header. The handoff is informational — `uipath-rpa` does not read the plan file; it runs its own target-configuration flow when invoked. The plan-header fields exist so the human reviewer and the main agent retain the decisions in context.
+
+## Step 5 — Write the plan
+
+Compose `<feature>.md` per the schema in [plan-and-tasks-format.md → Non-PDD lane](plan-and-tasks-format.md#non-pdd-lane-featuremd). Plan body holds the task list with the same task row schema as Lane A.
+
+### Self-review before saving
+
+1. **Coverage** — every requirement appears in at least one task.
+2. **Placeholder scan** — no "TBD", "TODO", "as needed", "if appropriate", "similar to".
+3. **Skill order** — correct specialist per task; skills load in the right order (e.g., RPA before platform deploy; testing before deploy).
+4. **Validation gaps** — every generation task ends with a `Validate:` compile / build / lint check.
+5. **Testing task present** — a dedicated `Testing (MANDATORY)` task exists for every generation skill in the plan. Routes to the specialist's testing references — does not describe the procedure.
+6. **No internal-flow leakage** — the plan does not duplicate steps from any specialist's own references.
+7. **Anti-hallucination rule** appended to every Skill prompt.
+
+Fix issues before saving.
+
+### Save location
+
+Save as `YYYY-MM-DD-<feature-name>.md`:
+
+- **Project directory exists** (`project.json`, `flow_files/`, `.uipath/`, or `pyproject.toml`) → save to `docs/plans/` within the project. Create the directory if needed.
+- **No project directory** → save to `./plans/` (relative to the current working directory). Create the directory if needed.
+
+### Resume handling
+
+If a plan file already exists at the target path, ask the user via `AskUserQuestion`:
+
+> A plan file already exists at `<path>`. How should I proceed?
+>
+> 1. **Continue with the current plan** *(recommended)* — pick up where you left off; checkbox state preserved
+> 2. **Regenerate from the current request** — discard the current plan and rebuild
+
+Option 1: read existing plan → recreate live `TaskCreate` calls with status preserved → done.
+Option 2: parse the request fresh, run identity-matching against the old file (preserve completed work), write the new plan, emit live tasks. Same regenerate algorithm as Lane A — see [plan-and-tasks-format.md → Regenerate logic](plan-and-tasks-format.md#regenerate-logic-pdd-driven-lane-only).
+
+## Step 6 — Present the plan
+
+- **Explore first, then plan:** call `EnterPlanMode` with the plan content. User approves → `ExitPlanMode` → emit live `TaskCreate` calls.
+- **Explore, plan, and execute simultaneously:** emit the plan as text. Then immediately emit live `TaskCreate` calls. Main agent starts executing.
+
+## Lane B budget
+
+Step 1 is **always one batched call** (Q1 + Q2 + optional Q3 in a single `AskUserQuestion`); Step 4 is one batched call when the plan has UI automation; resume adds one. The realistic floor is 0 calls and the realistic ceiling is 3.
+
+| Scenario | `AskUserQuestion` calls |
+|---|---|
+| Simple single-skill, simultaneous, all signals clear, no UI | **0** (Step 1 fully resolved from context, no UI batch) |
+| Non-trivial, no UI automation | **1** (Step 1 batched) |
+| Non-trivial, with UI automation | **2** (Step 1 batched + Step 4 UI batch) |
+| Vague request, with UI automation | **2** (Step 1 batched — Q3 is part of the same batch — + Step 4 UI batch) |
+| Resume scenario | **+1** (continue/regenerate) |
+| Realistic maximum | **3** |
+| Hard cap (Critical Rule 3) | **5** |
+
+The 5-call hard cap is defined in the planner's Critical Rules. If batching collapses the elicitation correctly, you should never approach it.

package/skills/uipath-planner/references/pdd-driven-lane-guide.md

@@ -0,0 +1,168 @@
+# PDD-driven Lane Guide
+
+When the planner detects a Solution Design Document (SDD) at entry, it runs Lane A — read the SDD, derive tasks, hand off to specialists. This guide covers Lane A end-to-end.
+
+> Lane A is reached from the entry guard when the input file contains the marker heading `## Planner Handoff` (the load-bearing detection contract from `uipath-solution`). See SKILL.md for the entry guard logic.
+
+## Step 1 — Read the SDD's Planner Handoff header
+
+The header appears immediately after `## Document History` in every SDD. Read these 6 fields:
+
+| Field | What the planner does with it |
+|---|---|
+| **Execution autonomy** | `interactive` → enter plan mode for task review before execution. `autonomous` → emit live tasks directly. |
+| **SDD scope** | `single-product` → one SDD file owns one task list. `solution` → one solution-overview SDD plus one per-project SDD; tasks span all projects. |
+| **Project list section** | Tells the planner where to find the unified project list (e.g., `§10` for RPA, `§3 + §7` for Flow, `Project Inventory` for solution overview). |
+| **Tasks file** | Where to write `<process>-tasks.md`. Solution-design proposes a path; planner respects it. |
+| **Generated by** | `uipath-solution v<VERSION>`. Used in the summary output to tell the user the SDD's provenance. |
+| **Generation date** | `YYYY-MM-DD`. Shown to the user in the summary. |
+
+**Missing or malformed fields:** default `Execution autonomy` to `interactive` (safer), default `SDD scope` to `single-product`, infer `Project list section` from the template type, default `Tasks file` to `<sdd-basename-without-sdd>-tasks.md`. **Track each defaulted field** in a session-local list — Step 8 surfaces them in the user-facing summary so the human reviewer can correct the SDD before tasks are emitted. Do not silently swallow the defaults.
+
+## Step 2 — Check for an existing tasks.md
+
+If the file at `Tasks file` already exists (resume scenario), ask the user via `AskUserQuestion`:
+
+> A task list already exists at `<tasks-file>`. How should I proceed?
+>
+> 1. **Continue with the current task list** *(recommended)* — pick up where you left off; checkbox state preserved
+> 2. **Regenerate from the SDD** — discard the current task list and rebuild from the SDD; checkbox state lost (or preserved per identity matching, see [plan-and-tasks-format.md → Regenerate logic](plan-and-tasks-format.md#regenerate-logic-pdd-driven-lane-only))
+
+- **Choice 1:** read the existing tasks.md → recreate live `TaskCreate` calls with status preserved → no SDD re-parsing needed → done.
+- **Choice 2:** parse the SDD fresh, run identity-matching against the old file (preserve completed work), write the new tasks.md, emit live tasks. See [plan-and-tasks-format.md](plan-and-tasks-format.md) for the regenerate algorithm and archive-footer format.
+
+If the file does not exist (first run), proceed to Step 3.
+
+## Step 3 — Parse the SDD project list
+
+Read the section named in the `Project list section` header field. The project list is the canonical source for tasks — every project becomes a subset of tasks routed to the appropriate specialist.
+
+Common section locations per template:
+
+| Template | Project list location |
+|---|---|
+| RPA single project | §11 Project Structure (workflow inventory) |
+| RPA Master Project | §10 Master Project Architecture (sub-project list) + §11 Workflow Inventory per sub-project |
+| Flow | §3 Nodes Inventory + §7 Integrated Components |
+| Case | §15 Project Structure + §14 Integrated Components |
+| Agent | §9 Project Structure + §3 Tools |
+| Coded App | §10 Project Structure + §9 Integrated Components |
+| API Workflow | §10 Project Structure + §5 Connectors |
+| Solution overview | Project Inventory section + Cross-Project Data Flow section |
+
+Extract per project:
+
+- Project name (used for the `Identity` tuple)
+- Product (RPA / Flow / Case / Agent / Coded App / API Workflow)
+- Sub-type (for RPA: Process / Library / Test Automation)
+- Role (Dispatcher / Performer / Reporting / Library / Test / etc.)
+- Framework (Sequence / REFramework, for RPA)
+- Input / Output queues (for Master Project sub-projects)
+- Workflows / nodes / tools / pages / steps within the project
+
+## Step 4 — Pick the multi-skill pattern
+
+Based on the project list, pick the matching pattern from [multi-skill-patterns-guide.md](multi-skill-patterns-guide.md):
+
+| SDD shape | Pattern |
+|---|---|
+| Single RPA project, no deploy hint in §16 | Pattern 1 (simplified — drop deploy steps) |
+| Single RPA project, §16 specifies Orchestrator deploy | Pattern 1 |
+| RPA Master Project | Pattern 1 per sub-project, integrated via shared queues; cross-project deploy via `uipath-solution` (single `.uipx`) |
+| Flow with §7 Integrated Components that reference unbuilt resources | Pattern 2 |
+| Flow whose §7 integrated components are pre-existing | Pattern 3 |
+| Agent with RPA tools in §3 Tools | Pattern 7 |
+| Coded App | Coded App build + `uipath-solution` deploy + testing (when wrapped in `.uipx`); otherwise `uipath-coded-apps` self-deploys |
+| API Workflow | API Workflow build + `uipath-solution` publish + testing |
+| Solution scope | Compose patterns per project, sequenced by cross-product integration order (dependencies before dependents) |
+
+## Step 5 — UI element targeting (only when §9 contains UI applications)
+
+If the SDD's §9 Application Inventory contains web / desktop / Citrix applications AND the plan loads `uipath-rpa` for a workflow that interacts with them, ask the Step 4 UI batch as a single `AskUserQuestion` call (3 questions, batched):
+
+> *Question 1 — App type:* What kind of application are we automating?
+> 1. Web / browser app
+> 2. Desktop app
+> 3. Citrix / remote session
+>
+> *Question 2 — Targeting approach:* How should I handle the UI elements?
+> 1. **I build it, you review it** *(recommended)*
+> 2. **You indicate each element** in Studio's Selector editor
+>
+> *Question 3 — App state:* Is the app open on your machine?
+> 1. **Yes, it's open and ready**
+> 2. **No, I'll open it first** — tell me when ready
+> 3. **Skip discovery for now** — scaffold with placeholder selectors
+
+Skip individual questions per the rules:
+
+- **Skip Q1** if §9 names the app kind explicitly (web / desktop / Citrix in the Interface column).
+- **Skip Q2** only if the user explicitly asked for one targeting approach.
+- **Skip Q3** if the user already stated the app is running, not yet open, or asked to skip discovery.
+
+Skip the entire batch if the plan does not include UI automation (pure data-processing, API-only, agent-only, flow-only).
+
+Record the answers in the tasks.md header for traceability and for the implementation specialists to consume.
+
+## Step 6 — Derive tasks
+
+Walk the project list. For each project, emit task rows per the matched pattern. Use the schema in [plan-and-tasks-format.md](plan-and-tasks-format.md). Key rules:
+
+1. **One task per discrete deliverable.** A workflow file → one task. An Orchestrator queue → one task. An asset → one task.
+2. **Identity tuple is stable.** `<skill>:<project>:<subject>`. Use kebab-case or PascalCase consistent with the SDD's naming.
+3. **Skill prompt references SDD sections explicitly.** "Implement `Process/CalculateTotal.xaml` per §11 row #3 of `<sdd-path>`. Use exact data field names from §5."
+4. **Anti-hallucination rule appended verbatim** to every Skill prompt.
+5. **Blocked-by edges** capture the dependency order — leaf resources before consumers, build before testing, testing before deploy.
+6. **Mandatory testing task per generation skill.** Inserted between generation tasks and any deploy task.
+
+## Step 7 — Write tasks.md
+
+Compose the file using the schema in [plan-and-tasks-format.md](plan-and-tasks-format.md). Header lists Source SDD, SDD scope, Execution autonomy, Generation date. Body is the task list. If regenerating, append the Archive footer for removed tasks.
+
+## Step 8 — Plan-mode review (interactive autonomy only)
+
+If `Execution autonomy: interactive`, call `EnterPlanMode` with the full tasks.md content. Wait for user approval.
+
+- Approval criteria: any response without specific change requests. "Looks good", "ok", "proceed", "yes", or a topic change all count as approval.
+- If the user requests specific changes, incorporate them and re-present (max 3 revisions; after that, proceed with the latest).
+- On approval → `ExitPlanMode` → Step 9.
+
+If `Execution autonomy: autonomous`, skip plan mode. Output a summary instead:
+
+```
+Generated <tasks-file>: <N> tasks.
+Skills involved: uipath-rpa, uipath-platform, …
+Starting execution autonomously.
+```
+
+**If Step 1 defaulted any handoff fields**, append a "Defaulted handoff fields" line to the summary listing each field and the value used:
+
+```
+Defaulted handoff fields: Execution autonomy → interactive, Tasks file → <inferred-name>.
+Review the SDD's `## Planner Handoff` table and re-run if any of these are wrong.
+```
+
+In `Execution autonomy: interactive` mode, prepend the same "Defaulted handoff fields" block (when applicable) to the `EnterPlanMode` payload so the reviewer sees it at approval time.
+
+## Step 9 — Emit live tasks
+
+Emit `TaskCreate` calls one per task row, respecting the row order. After all tasks are created, emit `TaskUpdate` calls with `addBlockedBy` to set up dependencies.
+
+Apply Rule G-8: if any TaskCreate or TaskUpdate fails, log a single warning, continue without live tasks, and do not retry. The tasks.md file is the authoritative deliverable.
+
+## Step 10 — Hand off
+
+The planner's job is done. The main agent reads the live tasks (via TaskList) and walks them in dependency order, loading the appropriate specialist for each. As tasks complete, the planner — invoked again by the main agent on TaskUpdate events, or whenever it next runs in this project — refreshes the corresponding checkbox in tasks.md (`[ ]` → `[~]` → `[x]`) so that future sessions see current state.
+
+> Implementation note: the planner does not directly observe TaskUpdate events. The "refresh tasks.md from live tasks" responsibility lives in the main agent's session loop, not in this skill. This skill writes the file once and trusts the agent to keep it in sync. On next entry to Lane A, the planner re-reads the file and proceeds.
+
+## Lane A budget
+
+| Scenario | `AskUserQuestion` calls |
+|---|---|
+| First run, no UI apps in §9 | **0** (plan-mode review uses EnterPlanMode, not AskUserQuestion) |
+| First run, UI apps in §9 | **1** (Step 4 batched UI questions, only when at least one of Q1/Q2/Q3 is unresolved) |
+| Resume run (existing tasks.md) | **1** (continue / regenerate) — plus 0-1 for UI batch if unresolved |
+| Maximum | **2** under any realistic scenario |
+
+This stays well within the 5-call budget defined in the planner's Critical Rules.

package/skills/uipath-planner/references/plan-and-tasks-format.md

@@ -0,0 +1,228 @@
+# Plan and Tasks Format
+
+Format spec for the planner's two output artifacts:
+
+- `<feature>.md` — non-PDD lane plan file (combines lightweight architecture notes + task list)
+- `<process>-tasks.md` — PDD-driven lane task file (task list only; architecture lives in the SDD)
+
+Both share the same task row schema. The difference is the prelude — `<feature>.md` carries an architecture summary; `<process>-tasks.md` does not (the SDD is the architecture).
+
+## Header schema
+
+### Non-PDD lane (`<feature>.md`)
+
+```markdown
+# <Feature Name> Implementation Plan
+
+**Goal:** <one sentence summarizing what the automation does>
+**Source:** None — planned from user request
+**Project type:** <XAML / C# coded / AI Agent / Flow / Application>
+**Expression language:** VB.NET (XAML only; N/A for coded / AI Agent / Flow / Application)
+**Approach:** <explore-first / simultaneous>
+**Execution autonomy:** <autonomous / interactive>
+**App type:** <web / desktop / citrix / N/A>
+**App state:** <open-and-ready / user-will-open / skip-discovery / N/A>
+**UI targeting:** <agent-builds-you-review / user-indicates / N/A>
+**Solution scope:** <SW | local>  <!-- Flow plans only; omit this line entirely for non-Flow plans -->
+
+## Understanding
+
+<2–4 sentences: interpretation of the request, key inputs and outputs, assumptions
+or ambiguities resolved during elicitation.>
+
+## Decisions & Trade-offs
+
+- Why this project type
+- Why specific skills are loaded in this order
+- Trade-offs and risks
+
+## Stop conditions
+
+<Only populate when `Execution autonomy` is `autonomous`. List the concrete hard blockers that MUST interrupt execution — everything else is handled without asking the user. Examples:
+- Authentication fails and cannot be recovered without user credentials
+- The target application is unresponsive after a reasonable retry window
+- A UI element cannot be captured reliably after 3 selector-improvement attempts
+- The plan references a file, package, or resource that does not exist and cannot be created
+- A pre-existing record would block idempotent execution and cleanup is ambiguous
+
+In `interactive` mode this section is optional — the user is available to resolve ambiguity as it arises.
+
+"Scope feels large", "many tool calls used", "natural pause point", and "partial result looks usable" are NOT stop conditions. If it is not in this list, the executor continues.>
+```
+
+### PDD-driven lane (`<process>-tasks.md`)
+
+```markdown
+# <Process Name> — Implementation Tasks
+
+**Source SDD:** `<process>-sdd.md`
+**SDD scope:** <single-product / solution>
+**Execution autonomy:** <autonomous / interactive>
+**Generation date:** <YYYY-MM-DD>
+
+> Tasks below are derived from the SDD. The SDD remains the architectural source of truth.
+> When `Execution autonomy: interactive`, the planner enters plan mode for review before execution.
+```
+
+## Task row schema
+
+Every task — in both file types — uses this exact structure. The fields below are load-bearing for the regenerate-with-preservation flow (see "Regenerate logic" below).
+
+```markdown
+## Task T<N> — <skill-name> — <short description>
+
+**Identity:** `<skill>:<project>:<subject>`
+**Status:** [ ] pending  *(or [~] in_progress / [x] completed / [!] blocked)*
+**Completed:** <YYYY-MM-DD by agent|human>  *(only present when Status = [x])*
+**Blocked by:** <T1, T2 / none>
+**Skill prompt:**
+
+> <Imperative prompt that activates the specialist skill. Include exact SDD section
+>  references when in PDD-driven lane. End with the anti-hallucination rule.>
+
+- [ ] <concrete sub-step: action + file paths / activity names / commands>
+- [ ] <concrete sub-step: expected outcome or verification>
+- [ ] **Validate:** <compile / build / lint / run check>
+```
+
+### Field rules
+
+| Field | Required | Notes |
+|---|---|---|
+| `Task T<N>` | yes | Sequential within the file. Renumber on regeneration. |
+| `<skill-name>` | yes | One of `uipath-rpa`, `uipath-platform`, `uipath-solution`, `uipath-agents`, `uipath-coded-apps`, `uipath-maestro-flow`, `uipath-maestro-case`, `uipath-human-in-the-loop`, `uipath-test`. The planner emits this skill in the live `TaskCreate` call. |
+| `Identity` | yes | Stable tuple `<skill>:<project>:<subject>`. Used to match tasks across regenerations. **Parsing rule:** split on the first two colons only; `<subject>` may itself contain colons (typed-resource form `<kind>:<name>` for platform resources). Examples: `rpa:VendorInvoice_Performer:Process/CalculateTotal.xaml` (file-path subject), `platform:VendorInvoice:queue:VendorQueue` (typed-resource subject = `queue:VendorQueue`), `agents:InvoiceClassifier:tools/extract_amount.py` (file-path subject), `rpa:VendorInvoice:testing` (single-token subject). |
+| `Status` | yes | One of `[ ]` pending, `[~]` in_progress, `[x]` completed, `[!]` blocked. |
+| `Completed` | only when `[x]` | `YYYY-MM-DD by agent` or `YYYY-MM-DD by human`. The planner sets `agent` when its TaskUpdate flips the checkbox; `human` only when the user manually edits the file. |
+| `Blocked by` | yes | Comma-separated task IDs, or `none`. Drives the live `addBlockedBy` calls. |
+| `Skill prompt` | yes | Imperative prompt the planner pastes into the TaskCreate `description`. Must end with the anti-hallucination rule (below). |
+| Sub-steps | yes | Concrete, checkable actions. One clear action per checkbox. No "TBD", no "as needed". |
+| `Validate:` sub-step | yes | Every generation task ends with a build/lint/compile check. |
+
+## Anti-hallucination rule (mandatory in every Skill prompt)
+
+Append this exact line to every `Skill prompt` block, with the SDD path filled in for PDD-driven lane:
+
+```
+Use values, mappings, and structure exactly as documented in the SDD at <sdd-path>. Do not infer or guess.
+```
+
+For non-PDD lane, the prompt references the plan file:
+
+```
+Use values, mappings, and structure exactly as documented in this plan. Do not infer or guess.
+```
+
+## Testing task is mandatory
+
+Every plan with a generation skill (`uipath-rpa`, `uipath-maestro-flow`, `uipath-agents`, `uipath-coded-apps`) gets a dedicated Testing task per generation skill, placed immediately after that skill's generation tasks and **before** any deploy task (`uipath-solution` for `.uipx`-bundled solutions; `uipath-platform` for non-solution Orchestrator ops).
+
+```markdown
+## Task T<N> — <generation-skill> — Testing (MANDATORY)
+
+**Identity:** `<skill>:<project>:testing`
+**Status:** [ ] pending
+**Blocked by:** <generation task IDs>
+**Skill prompt:**
+
+> Load <generation-skill> and run its testing workflow end-to-end. Always thorough:
+> happy path + edge cases + error scenarios + (for Master Projects) end-to-end pipeline tests.
+> See that skill's testing references for commands, test-case authoring, and best practices.
+> Do not describe the testing procedure here — the specialist owns it.
+
+- [ ] Run testing workflow per <generation-skill>'s testing reference
+- [ ] **Validate:** all tests pass; record results
+```
+
+## Regenerate logic (PDD-driven lane only)
+
+When the user picks "Regenerate from the SDD" on the planner's resume question, preserve completed work via identity matching.
+
+### Algorithm
+
+```
+1. Read old <process>-tasks.md → list of (identity_tuple, status, completed_by, completed_date)
+2. Parse the (possibly updated) SDD → list of new tasks with identities
+3. For each new task:
+   - Match against old tasks by identity_tuple
+   - matched & old status == [x] completed → preserve as completed (carry over Completed line)
+   - matched & old status == [~] in_progress → preserve as in_progress
+   - matched & old status == [ ] pending → keep pending (no change)
+   - unmatched (new in SDD) → pending
+4. Old tasks unmatched in new SDD → write to "Archive" footer (see below)
+5. Renumber tasks T1..TN in the new order
+6. Write the new <process>-tasks.md
+7. Show user a summary diff (preserved counts, added, archived)
+8. Emit live TaskCreate calls per the new tasks.md
+```
+
+### Archive footer format
+
+When the new SDD removes tasks that existed in the old plan, append them to a section at the bottom of the file:
+
+```markdown
+---
+
+## Archive — Tasks removed from plan
+
+| Old ID | Identity | Status before removal | Removed on |
+|---|---|---|---|
+| T7 | `rpa:VendorInvoice_OldReporting:Main.xaml` | [x] completed | <YYYY-MM-DD> |
+
+> These tasks existed in a previous version of this file but are no longer in the SDD.
+> Completed work is not deleted — historical record only.
+```
+
+### Summary message
+
+After regeneration, output a one-block summary:
+
+```
+Regenerated <process>-tasks.md from SDD.
+- 4 tasks preserved as completed
+- 1 task preserved as in_progress
+- 3 tasks unchanged pending
+- 2 tasks added (new in SDD)
+- 1 task archived (removed from SDD)
+- SDD content may have changed since completed tasks ran. Sanity-check those
+  implementations against the current SDD before continuing.
+```
+
+## TaskCreate / TaskUpdate mapping
+
+The planner emits live tasks that mirror the file. Mapping rules:
+
+| File field | Live task field |
+|---|---|
+| `Task T<N> — <skill> — <description>` | `subject` = `<skill> — <description>` |
+| `Status: [ ] pending` | initial status `pending` |
+| `Status: [~] in_progress` | status `in_progress` |
+| `Status: [x] completed` | status `completed` |
+| `Identity:` | `metadata.identity` (so future runs can match) |
+| `Skill prompt:` | `description` (verbatim, including anti-hallucination rule) |
+| `Blocked by:` | `addBlockedBy` (after all tasks are created) |
+| `Completed:` | `metadata.completed_by`, `metadata.completed_date` |
+
+**Rule G-8 applies (inherited from solution-design):** if any TaskCreate or TaskUpdate fails, log a single warning, continue without live tasks, and do not retry. The markdown plan / tasks file is the authoritative deliverable.
+
+## Plan-mode integration
+
+Both files are valid `EnterPlanMode` payloads.
+
+- **Non-PDD lane explore-first:** call `EnterPlanMode` with the full `<feature>.md` content. User approves → `ExitPlanMode` → emit live `TaskCreate` calls.
+- **PDD-driven lane interactive:** call `EnterPlanMode` with the full `<process>-tasks.md` content. User approves → `ExitPlanMode` → emit live `TaskCreate` calls.
+- **Non-PDD lane simultaneous / PDD-driven autonomous:** skip `EnterPlanMode`. Emit the file as text, then immediately emit live `TaskCreate` calls.
+
+## Quality rules (applied during self-review before saving)
+
+1. **No placeholders.** Every sub-step has concrete details. Never "TBD", "as needed", "similar to Task N".
+2. **Granular sub-steps.** One clear action per step.
+3. **Checkbox syntax.** `- [ ]` on every sub-step.
+4. **Identity tuple is stable and unique** within the file.
+5. **Every generation task ends with a `Validate:` sub-step.**
+6. **Every generation skill has a dedicated Testing task** placed before any deploy task. Testing is mandatory — never a `Validate:` sub-step substitute.
+7. **Anti-hallucination rule** appended to every Skill prompt.
+8. **Skill order is correct** — RPA before platform deploy; integrated components before consumers; testing before deploy.
+9. **No specialist-internal flow leakage.** The plan says WHICH skill to load and IN WHAT ORDER. It does NOT describe the skill's internal flow (target-configuration, OR registration, XAML authoring pipelines, auth flows, testing procedures). Each specialist's own docs own those details.
+10. **Autonomous plans MUST include a populated Stop conditions section.** Without concrete stop items, downstream specialists have no way to distinguish "keep going" from "ask the user" and will default to asking — defeating autonomous mode. Populate with hard blockers realistic for this specific plan (auth, app state, element-capture limits, missing resources); never leave a generic placeholder.
+11. **Solution scope field is Flow-only.** Include `**Solution scope:** <SW | local>` in the plan header only when the plan loads `uipath-maestro-flow`. Omit the line entirely for RPA / AI Agent / Application plans — no other specialist reads it.