@uipath/skills 1.195.0

package/skills/uipath-solution/references/design/package-selection-guide.md

@@ -0,0 +1,182 @@
+# Package Selection Guide
+
+Load this guide whenever an SDD section needs to list dependencies — typically §14 Packages in the RPA template, the Packages subsection of the Case template, or the Tool Packages table in the Agent template. Use it to infer packages from the Application Inventory (§9 in the RPA template) and from the process steps.
+
+Two things this guide disambiguates:
+
+1. **NuGet packages vs Integration Service connectors.** They solve overlapping problems but live in different places. See [Integration Service Connectors vs NuGet Packages](#integration-service-connectors-vs-nuget-packages).
+2. **Per-product dependency managers.** RPA/Case use NuGet. Coded Apps use **npm** (not NuGet). Agents declare C# tool packages (subset of NuGet). API Workflows use Integration Service connector references, not packages. See [Per-Product Dependency Manager](#per-product-dependency-manager).
+
+## Core Packages (always include for RPA)
+
+| Package | Purpose | Required |
+|---|---|---|
+| `UiPath.System.Activities` | Core activities: data tables, files, Orchestrator, workflow operators | Yes — every RPA project |
+| `UiPath.UIAutomation.Activities` | UI automation (web, desktop) | Yes if §9 contains any UI application |
+| `UiPath.Testing.Activities` | Assertions, VerifyExpression, VerifyControlAttribute | Yes for RPA Test Automation sub-type |
+
+## Application Type → Package Matrix
+
+Use this matrix to infer packages from §9 Application Inventory. Match on the **Interface** and **Access Method** columns. If an application matches multiple rows, install all listed packages.
+
+### Email
+
+| Access Method in §9 | Package(s) | Required Assets | Common Pitfalls |
+|---|---|---|---|
+| IMAP | `UiPath.Mail.Activities` | Credential asset (username + app password); server host + port as text assets | Do not default to O365 — check PDD for protocol. IMAP needs app password, not user password, on 2FA accounts. |
+| POP3 | `UiPath.Mail.Activities` | Credential asset; host + port | Rarely used — prefer IMAP or Graph API if available. |
+| Exchange / EWS | `UiPath.Mail.Activities` | Credential asset; EWS URL | Being deprecated by Microsoft — confirm the tenant still allows EWS. |
+| O365 Graph API | `UiPath.MicrosoftOffice365.Activities` | App registration client ID + tenant ID (text assets); certificate or secret (credential asset) | Different activity set from `UiPath.Mail.Activities`. Requires admin consent for mail scopes. |
+| Gmail API | `UiPath.GSuite.Activities` | OAuth client JSON (credential asset) | Integration Service alternative exists — prefer the connector unless the PDD requires specific activity packages. |
+
+### Microsoft Office files
+
+| File Type | Package | Notes |
+|---|---|---|
+| Excel (.xlsx, .xlsm, .xlsb) | `UiPath.Excel.Activities` | Modern "Use Excel File" activities preferred over classic. |
+| Excel via Office 365 / OneDrive | `UiPath.MicrosoftOffice365.Activities` | Same package as O365 mail. |
+| Word | `UiPath.Word.Activities` | |
+| PowerPoint | `UiPath.Presentations.Activities` | |
+
+### Document Understanding
+
+| Scenario | Packages | Notes |
+|---|---|---|
+| PDF text extraction (digital PDFs) | `UiPath.PDF.Activities` | No OCR required. |
+| PDF OCR / scanned documents | `UiPath.PDF.Activities` + `UiPath.IntelligentOCR.Activities` | OCR engine is a separate dependency. |
+| Document Understanding framework (classify → extract → validate) | `UiPath.IntelligentOCR.Activities` + `UiPath.DocumentUnderstanding.ML.Activities` | Required for Taxonomy Manager + Data Extraction Scope. |
+| Action Centre validation for DU | `UiPath.Persistence.Activities` + `UiPath.FormActivityLibrary` | Needed for `WaitForFormTaskAndResume` on DU validation tasks. |
+
+### SaaS platforms (non–Integration Service path)
+
+| Platform | Package | Use When |
+|---|---|---|
+| SAP GUI | `UiPath.SAP.BAPI.Activities` | BAPI function calls (RFC). |
+| SAP Fiori (web) | `UiPath.UIAutomation.Activities` | UI automation — no SAP package. |
+| Salesforce (native activities) | `UiPath.Salesforce.Activities` | Only when Integration Service is not available. Prefer the connector. |
+| ServiceNow | `UiPath.ServiceNow.Activities` | Only when Integration Service is not available. |
+| Workday | `UiPath.Workday.Activities` | Only when Integration Service is not available. |
+
+> For any of the above, if the PDD mentions "Integration Service" or a preconfigured connector slug, skip the NuGet package — see the next section.
+
+### Web, API, and integration primitives
+
+| Scenario | Package | Notes |
+|---|---|---|
+| Generic REST calls (HTTP verbs, headers, auth) | `UiPath.WebAPI.Activities` | `HTTPRequest` / `NetHTTPRequest` activity. |
+| Web UI automation | `UiPath.UIAutomation.Activities` | Same package as desktop UI. |
+| Modern browsers (Edge, Chrome, Firefox) via Selenium | `UiPath.UIAutomationModern.Activities` | If using the modern experience. Studio installs alongside UIAutomation. |
+| Terminal / mainframe (3270, 5250, VT) | `UiPath.Terminal.Activities` | |
+| FTP / SFTP | `UiPath.FTP.Activities` | |
+
+### Database
+
+| Scenario | Package | Notes |
+|---|---|---|
+| SQL Server, Oracle, MySQL, PostgreSQL | `UiPath.Database.Activities` | Uses ODBC/OLEDB under the hood. Connection string asset recommended. |
+| NoSQL (Mongo, Cosmos) | `UiPath.WebAPI.Activities` via REST | No first-party NoSQL package — call the REST API. |
+
+### Orchestrator and persistence
+
+| Scenario | Package | Notes |
+|---|---|---|
+| Queue items, assets, storage buckets, processes | `UiPath.System.Activities` | Core package — no extra install. |
+| Long-running workflows, Form Tasks, External Tasks | `UiPath.Persistence.Activities` | Required for `CreateFormTask`, `WaitForFormTaskAndResume`, `CreateExternalTask`. |
+| Form Tasks with form.io forms | `UiPath.Persistence.Activities` + `UiPath.FormActivityLibrary` | Both required. |
+
+### Credentials and security
+
+| Scenario | Package | Notes |
+|---|---|---|
+| Robot-scoped credential retrieval (`GetRobotCredential`, `GetRobotAsset`) | `UiPath.System.Activities` | Core — already installed. |
+| Credential Provider integrations (CyberArk, HashiCorp, Azure Key Vault) | Configured in Orchestrator — no package | Robot fetches credentials via Orchestrator's credential store. |
+
+## Integration Service Connectors vs NuGet Packages
+
+These two mechanisms both provide access to third-party systems, but they are **not interchangeable**. Pick the right one for each application, and declare it in the right place.
+
+### Decision
+
+1. If Orchestrator has a configured **Integration Service** connection for the target system AND the PDD does not require specific native-package activities → use the **Integration Service connector**.
+2. Otherwise → use the matching **NuGet package**.
+3. If both paths are listed in §9 for the same application, pick Integration Service for the primary path and note the NuGet package as a fallback in §14.
+
+### Side-by-side
+
+| Aspect | Integration Service Connector | NuGet Package |
+|---|---|---|
+| Where it's configured | Orchestrator → Integration Service → Connections | Project's `project.json` dependencies |
+| How it's referenced | Slug (e.g., `salesforce`, `service-now`, `gmail`) in the Integration Service activity | `Using` namespace + activity from the installed package |
+| Authentication | Stored in the Connection (OAuth, API key) | Credential asset + in-workflow auth logic |
+| Deployment | No per-robot install — lives in Orchestrator | Packaged into the .nupkg and pulled on the robot |
+| Runtime dependency | Robot must have the Integration Service activity package installed (`UiPath.IntegrationService.Activities`), which is a single dependency regardless of how many connectors are used | One package per third-party system |
+| Listed in SDD where | §9 Access Method as `Integration Service — <CONNECTOR_SLUG>` | §14 Packages table |
+
+### Do not
+
+- **Do not** list the connector slug in §14 Packages. Slugs are not NuGet packages.
+- **Do not** install `UiPath.Salesforce.Activities` when the design uses the Salesforce Integration Service connector — they are parallel paths, not complementary.
+- **Do not** assume every Orchestrator instance has Integration Service enabled. Confirm during Phase 1 scoping; default to the NuGet package path if in doubt.
+
+### Example — Salesforce via Integration Service
+
+§9 Application Inventory row:
+
+| # | Application | Interface | Access Method | Role | Interaction Pattern |
+|---|---|---|---|---|---|
+| 3 | Salesforce | API | `Integration Service — salesforce` | Target | Write |
+
+§14 Packages — add only the Integration Service host package, not `UiPath.Salesforce.Activities`:
+
+| Package | Version | Purpose |
+|---|---|---|
+| `UiPath.IntegrationService.Activities` | Latest | Runtime host for Integration Service connector activities |
+
+### Example — Salesforce via NuGet native package
+
+§9 Application Inventory row:
+
+| # | Application | Interface | Access Method | Role | Interaction Pattern |
+|---|---|---|---|---|---|
+| 3 | Salesforce | API | OAuth 2.0 direct (native package) | Target | Write |
+
+§14 Packages:
+
+| Package | Version | Purpose |
+|---|---|---|
+| `UiPath.Salesforce.Activities` | Latest | Native Salesforce activities — used because Integration Service connector not available in this tenant |
+
+## Per-Product Dependency Manager
+
+SDD templates across the 6 products use different dependency mechanisms. List dependencies under the correct mechanism; do not cross them.
+
+| Product | Dependency Manager | Where Declared in SDD | Notes |
+|---|---|---|---|
+| RPA (Process, Library, Test Automation) | NuGet | §14 Packages table | Covered by this guide. |
+| Case Management | NuGet | Packages subsection in the Case template | Case-specific packages: `UiPath.Persistence.Activities`, `UiPath.FormActivityLibrary` for HITL tasks. |
+| Maestro Flow | Connector references + RPA step packages | Integrated Components section | Flow itself has no packages. Each RPA step called from the flow uses the RPA template's §14. |
+| Agents | C# tool packages (subset of NuGet) | Tool Packages table in the Agent template | Declare only packages whose activities are wrapped as Agent tools. |
+| Coded Apps | **npm** (not NuGet) | Dependencies subsection in the Coded App template | Use `package.json` semantics. Do not list NuGet packages. |
+| API Workflows | Integration Service connector references | Connectors section in the API Workflow template | API Workflows are hosted in Orchestrator — no package file. |
+
+## Selection Checklist
+
+Before finalising a Packages table:
+
+1. Every application in §9 has at least one matching package OR an Integration Service connector row.
+2. Core packages (`UiPath.System.Activities`; `UiPath.UIAutomation.Activities` if any UI) are present.
+3. Every PDD step with "download", "attach", "send email" has an email package.
+4. Every PDD step with "extract from PDF", "read invoice" has the DU / PDF packages.
+5. Every PDD step with "approval", "action centre", "long-running" has `UiPath.Persistence.Activities`.
+6. No Integration Service connector slug is listed in §14 by mistake.
+7. For Master Project: a separate §14 table per sub-project. A Dispatcher that only downloads email does not need Excel packages.
+8. For Coded App: the dependency list uses npm package names (e.g., `@uipath/apps-sdk`), not NuGet.
+
+## Pitfalls
+
+1. **Guessing package versions.** Default to `Latest` in SDDs. Version resolution happens at build time (`uip` / Studio) — the SDD should not pin versions unless the PDD explicitly requires a specific feature gate.
+2. **Listing `UiPath.Mail.Activities` and `UiPath.MicrosoftOffice365.Activities` together "just in case".** They provide overlapping activities and will confuse implementers. Pick one per email access method.
+3. **Mixing IntegrationService slug names with NuGet package names.** The slug `salesforce` is not a package; the package is `UiPath.Salesforce.Activities`.
+4. **Forgetting `UiPath.Persistence.Activities` for HITL.** Any workflow using `WaitForFormTaskAndResume`, `CreateFormTask`, or `CreateExternalTask` needs it. The Persistence package also requires `supportsPersistence: true` in `project.json` — call out in §14.
+5. **Listing NuGet packages for Coded App dependencies.** Coded Apps are TypeScript/React — the dependency manager is npm, and the template has a separate section.
+6. **Omitting Testing packages in RPA Test Automation sub-type.** Test Automation projects require `UiPath.Testing.Activities` for assertions; omitting it breaks Test Manager integration.

package/skills/uipath-solution/references/design/pdd-analysis-guide.md

@@ -0,0 +1,265 @@
+# PDD Analysis Guide
+
+How to extract structured information from Process Design Documents in any format.
+
+## Supported Input Formats
+
+| Format | How to Read | Notes |
+|---|---|---|
+| PDF | Use the Read tool with `pages` parameter. Read in chunks of up to 20 pages. | Screenshots are visible as images — see "Handling Screenshots" below. |
+| Word (.docx) | Read the file directly. | Tables may render differently — verify structure. |
+| Markdown | Read the file directly. | Easiest format — structure is already parseable. |
+| Pasted text | Process from the conversation context. | Ask the user to paste section by section if the PDD is large. |
+
+## Handling Screenshots
+
+When you encounter screenshots in the PDD:
+
+1. **Note** the application name and screen shown.
+2. **Extract** visible field names, button labels, and navigation elements — these become data field references and process step descriptions.
+3. **Do NOT extract** selectors, XPath, CSS, coordinates, colors, or visual layout details — these are determined at development time, not from static images.
+4. **Reference** the screenshot content in the relevant process step's "Remarks" field if useful.
+5. **DO extract concrete data values** shown in the screenshot — sample IDs, names, dates, expected outputs, error messages. These are oracles for the test strategy, not selectors. See "Extract Canonical Examples" below.
+
+## Extract Canonical Examples
+
+**Mandatory step. Run this on every PDD before falling back to `[SME REVIEW]` for test data.** PDDs almost always carry concrete example values somewhere — most agents miss them because the values live in screenshots, inline strings, or example tables rather than in a dedicated "Test Data" section.
+
+### Where to look
+
+Scan every one of these surfaces for concrete values:
+
+| Surface | What to look for | Example signals |
+|---|---|---|
+| **Screenshots of input data** | Sample IDs, names, codes, dates, free-form values shown filled into a form or list | `PRO1037`, `Jeanine Frederick`, `Romania`, `01/15/2024` |
+| **Screenshots of expected output** | Hash values, computed outputs, status fields, post-state values | `bde2c5964a3cfbc9b839aef9aa2a2764829d5497` (SHA1), `Confirmed`, `Approved` |
+| **Inline strings in step descriptions** | Quoted literals — anything inside backticks, double quotes, or single quotes that names a value rather than a column | `"the value 'WI5' in the Type column"`, `'PRO1037'` |
+| **Example tables in the Appendix** | Rows where each cell is a concrete value rather than a placeholder | `Vendor: ACME`, `Amount: 1250.00`, `Currency: EUR` |
+| **Validation rule examples** | Concrete inputs paired with expected pass/fail outcomes | `Hash must be 40 lowercase hex chars; e.g., bde2c5964a3...` |
+| **"For example" callouts in prose** | Sentences like "for example, ID PRO1037 produces hash X" | `e.g.`, `for example`, `such as` |
+| **Error message screenshots** | Verbatim error strings the automation must match | `"Hash mismatch — expected ..., got ..."` |
+
+### What to extract
+
+For every concrete value found, capture:
+
+| Field | Description |
+|---|---|
+| **Source location** | PDD page or section (e.g., "page 9 screenshot, Login screen") |
+| **Data role** | Input / Expected output / Validation rule / Error message |
+| **Field name** | Maps to a field in §5 Data Definitions |
+| **Value** | The literal value, quoted exactly as it appears in the PDD |
+
+### Where to write the extracted values
+
+Write the canonical examples into the SDD's §17 Testing Strategy → Canonical Test Case table. Use the field/value rows of that table to capture the input set, and add a separate Expected Output subsection for the output values. The values feed:
+
+- **§4 Business Rule test oracles** — every business rule with a concrete example becomes a test assertion using these values (e.g., `BR-04: SHA1(input) == '<canonical hash>'`).
+- **§17 Happy Path Assertions** — the canonical case is the first row of happy-path tests.
+- **§17 Output validation tests** — the canonical output value is the oracle for output-format regex checks (see template §4 prompt block).
+
+### Canonical examples are NOT `[SME REVIEW]` items
+
+A canonical example present anywhere in the PDD is **fact**, not user-supplied data. Do not mark it as `[SME REVIEW]`. The `[SME REVIEW]` fallback applies only when:
+
+- The entire PDD has been scanned (all screenshots, all tables, all step descriptions, all appendices) AND
+- No concrete value can be derived for the field.
+
+If scanning finds at least one concrete value, treat it as the canonical case — the gap-detection row "Test data / canonical case" only fires when extraction returns empty.
+
+### Output writing checklist
+
+Before declaring Phase 1 extraction complete:
+
+- [ ] Every screenshot has been visually inspected for concrete values (not just labels and buttons).
+- [ ] Every inline-quoted string in step descriptions has been captured.
+- [ ] Every example table in the PDD body or appendix has been read row by row.
+- [ ] At least one canonical input set + expected output is recorded for the §17 Canonical Test Case (or the `[SME REVIEW]` fallback applies because the PDD genuinely has no examples).
+- [ ] Hash / regex / format-shaped values are paired with the BR they validate (e.g., "SHA1 output: `bde2c596...`" → BR-04 SHA1 format rule).
+
+## Reading Strategy
+
+PDD templates vary — section numbers and names differ across organizations. Use the Table of Contents to identify where each topic lives, then read in this priority order:
+
+1. **Start with the Table of Contents** (usually in the first few pages of a PDF). This reveals the PDD structure and tells you which sections exist.
+2. **Read the Process Overview first.** This gives you the high-level picture: what the process does, how often, how many items, how many apps.
+3. **Read the Detailed Process Steps next.** This is the core — every step the robot needs to perform.
+4. **Read Exception and Error sections.** These define the failure modes.
+5. **Read Application Details and Credentials last.** These are supporting information.
+
+## Extraction Rules by PDD Topic
+
+PDD section numbers below are typical but not guaranteed. Match by topic name, not number.
+
+### Introduction
+
+Extract:
+- **Process name** — the official name used in the PDD title and overview
+- **Objective** — what the automation achieves (faster processing, error reduction, etc.)
+- **Department/function** — who owns the process
+- **Key contacts** — SME / Process Owner, Solution Architect, Business Analyst, Developer(s), Project Manager (only roles the PDD explicitly names). **Destination:** §1 Delivery Team table in the RPA SDD. Omit rows for roles the PDD does not name; do not invent.
+- **Master project / process full name** — if the PDD names the Master Project explicitly (e.g., a "Process Full Name" cell such as `PurchaseOrders_DataExtraction`), capture it verbatim. **This literal name becomes the project-name prefix** used in Level 2.5 sub-project naming — it overrides any PascalCase short-name derived from the process title.
+
+Watch for:
+- The PDD may describe the project initiative context (e.g., "part of a larger digital transformation"). Capture this as context but do not let it expand the SDD scope.
+
+### Process Overview
+
+Extract into a structured table:
+- Process full name
+- Function and department
+- Short description (operation, activity, outcome)
+- Required roles
+- Schedule (frequency, business hours)
+- Volume (items per day, peak periods)
+- Average handling time (manual vs. automated target)
+- FTE count
+- Exception rate estimate
+- Input data description
+- Output data description
+
+Watch for:
+- **In scope vs. out of scope** — these define the SDD boundary. Anything out of scope must not appear in the workflow inventory.
+- Vague volume descriptions like "7-15 items" — capture the range, use the upper bound for capacity planning.
+
+### Detailed Process Map
+
+Extract:
+- **Step numbering scheme** — usually 1.1, 1.2, ..., 1.5.A, 1.5.B, etc.
+- **High-level flow** — the sequence of major steps
+- **Loop boundaries** — where the per-item processing starts and ends
+- **Decision points** — any branching logic in the flow
+
+Watch for:
+- The process map may be a flowchart image. Read the image to understand the flow, then verify against the detailed process steps section.
+- Some PDDs use swimlane diagrams showing which application each step uses. This is valuable for the application scope mapping.
+
+### Detailed Process Steps
+
+This is the most important section. For each step, extract:
+
+| Field | Description |
+|---|---|
+| Step number | The PDD's numbering (1.1, 1.5.A, etc.) |
+| Action description | What the robot does in this step |
+| Application | Which application is used |
+| Expected result | What should be true after the step completes |
+| Remarks | Error handling notes, edge cases, business rules |
+
+Watch for:
+- **Embedded business rules** — rules are often buried in the "Remarks" column or in step descriptions rather than in a dedicated section. Extract and number them (BR-01, BR-02, etc.).
+- **Data field references** — step descriptions mention specific field names, variable names, or data values. Collect these for the data model definitions.
+- **Value mappings** — when a step says "map X to Y" or shows a conversion table, capture the full mapping.
+- **Implicit ordering constraints** — some steps must happen before others but the PDD doesn't explicitly say so. Note these for the workflow decomposition.
+
+### Business Exceptions
+
+Extract into a table:
+
+| Field | Description |
+|---|---|
+| Exception ID | B1, B2, etc. (assign IDs if the PDD doesn't) |
+| Exception name | Short descriptive name |
+| Trigger step | Which process step encounters this exception |
+| Trigger condition | How to detect the exception (parameters, UI state, data condition) |
+| Action | What the robot must do (skip, retry, escalate, notify) |
+
+Watch for:
+- PDDs often have a "catch-all" row: "for any other exception, send email to X". Preserve this as the default handler.
+- Some exceptions are actually business rules in disguise (e.g., "amount over threshold" is both an exception and a rule). Cross-reference with extracted business rules.
+
+### System Errors
+
+Extract into a table with the same structure as business exceptions, plus:
+
+| Field | Description |
+|---|---|
+| Severity | If specified (Sev-1, Sev-2, etc.) |
+| Retry policy | Number of retries, backoff strategy |
+
+Watch for:
+- If the PDD has only generic errors ("application unresponsive — retry 2 times"), expand with `[DEFAULT]` entries for common system errors: selector not found, browser crash, network timeout, credential expiry.
+
+### Application Details
+
+Extract into a table:
+
+| Field | Description |
+|---|---|
+| Application name | Official name and version |
+| Language | System language |
+| Login method | How authentication works |
+| Interface type | Web, desktop, terminal, API |
+| Access method | Browser type, URL, application path |
+| Comments | Special behaviors, routing, SPA details |
+
+Watch for:
+- URLs may be environment-specific (localhost for dev, internal DNS for prod). Note both if available.
+- SPA details (hash routing, pushState) affect how the robot navigates. Capture these.
+- **Email protocol** — when email is an application, extract the protocol signal: IMAP, Exchange/EWS, O365 Graph API, POP3, SMTP. Look for keywords like "IMAP", "Exchange", "O365", "Graph API", "dedicated mailbox". If not specified, mark as `[SME REVIEW]` — do not default to O365.
+- **FTP/SFTP** — note whether the PDD specifies FTP, SFTP, or cloud storage (S3, Azure Blob). Capture host/path if mentioned.
+
+### Development Details
+
+Extract:
+- **Prerequisites** — UiPath Studio version, packages, screen resolution, test environment setup
+- **Credentials** — asset names, types, values (training only), notes
+- **Password policies** — rotation, complexity, storage requirements
+
+Watch for:
+- Training credentials that should not be hardcoded in the automation. Note them as Orchestrator assets.
+
+### Appendix
+
+Extract:
+- **Canonical test data** — apply the "Extract Canonical Examples" procedure above. The appendix is one of several surfaces; also scan screenshots, inline strings, and example tables elsewhere in the PDD.
+- **Selector references** — if provided (rare in traditional PDDs, common in agent-ready PDDs)
+- **Value mapping tables** — additional mappings not covered in the detailed process steps
+
+### Reporting Requirements
+
+Extract:
+- **Report type** — Excel, email summary, dashboard data, PDF
+- **Report frequency** — real-time, daily, weekly, per-run
+- **Report content** — what data appears in the report (success counts, error details, processing times, item-level outcomes)
+- **Report recipients** — who receives the report
+- **Monitoring tool** — where the report is visualized (Excel, Power BI, Orchestrator Insights, custom dashboard)
+
+Watch for:
+- Reporting requirements are often in a separate section or table near the end of the PDD. They are easy to miss.
+- If the PDD mentions reporting, this is a signal for a dedicated Reporting project in the project decomposition decision (see [RPA Product Guide](rpa-product-guide.md#level-25-part-a--rpa-decomposition-signals) Level 2.5 Part A).
+- If the PDD has no reporting section but mentions logging or monitoring, mark reporting as `[DEFAULT]` — Orchestrator logs only.
+
+### Project Decomposition Signals
+
+While extracting data, watch for signals that indicate the process should be split into multiple projects. These feed into Level 2.5 Part A of the [RPA Product Guide](rpa-product-guide.md#level-25-part-a--rpa-decomposition-signals):
+
+1. **Distinct processing stages** — does the process have clearly separate phases (e.g., "collect emails" → "extract data" → "generate output")? Note stage boundaries.
+2. **Per-item transactional processing** — are items processed independently where one failure should not block others? Note where per-item processing starts/ends.
+3. **Document Understanding with human validation** — does the process use DU extraction followed by Action Centre / human review? This is a common split point.
+4. **Multiple output channels** — does the process produce output to multiple unrelated systems (e.g., XML to MQ + files to FTP + report to email)?
+5. **Reporting** — does the PDD specify reporting requirements? This often warrants a dedicated project.
+6. **Queue mentions** — does the PDD mention queues, batches, or "items to process"? This suggests queue-based architecture.
+
+Capture these signals as a structured list in your internal model. They will be used during product selection.
+
+## Gap Detection Checklist
+
+After extraction, verify these items exist. Flag missing ones:
+
+| Item | If Missing |
+|---|---|
+| Business exceptions section | `[DEFAULT]` — create placeholder rows for common exceptions based on application types (invalid credentials, malformed input data, missing required fields, data validation failure). Mark each as `[DEFAULT]`. |
+| System errors section | `[DEFAULT]` — create placeholder rows for common infrastructure errors (application unresponsive, element not found, timeout, unhandled exception). Mark each as `[DEFAULT]`. |
+| Process schedule/frequency | `[DEFAULT]` — assume on-demand trigger |
+| Volume/throughput | `[SME REVIEW]` — needed for capacity planning |
+| Retry counts on errors | `[DEFAULT]` — 3 retries with exponential backoff |
+| Element/activity timeouts | `[DEFAULT]` — 30s page loads, 10s element waits |
+| Max items per run | `[DEFAULT]` — 50 items safety cap |
+| Notification recipients for errors | `[SME REVIEW]` — needed for error escalation |
+| Amount/value thresholds | `[SME REVIEW]` — business decision |
+| Data retention requirements | `[SME REVIEW]` — compliance decision |
+| Credential rotation policy | `[DEFAULT]` — assume Orchestrator asset management |
+| Test data / canonical case | Run "Extract Canonical Examples" first. Only mark `[SME REVIEW]` if scanning every screenshot, every inline-quoted string, and every example table genuinely returns zero concrete values. Most PDDs carry at least one example. |
+| Reporting requirements | `[DEFAULT]` — Orchestrator logs only (no dedicated report) |
+| Email protocol (when email is used) | `[SME REVIEW]` — needed for package selection (IMAP vs O365 vs Exchange) |