feat(uipath-troubleshoot): add If-condition NRE + KeyNotFound coverage + tests

[Stefan-Virgil]

Stacked on #1780 (feat/troubleshoot-assign-runtime-exceptions). Base will be retargeted to main and the branch rebased once #1780 merges — it depends on key-not-found-exception.md, which #1780 introduces.

What

Extends uipath-troubleshoot runtime-exception coverage to faults thrown while resolving a System.Activities If Condition expression — for the two exceptions requested: System.NullReferenceException and System.Collections.Generic.KeyNotFoundException.

Playbooks (extended, not duplicated — DRY)

Both exceptions already have per-exception playbooks. Rather than add redundant files, this adds an If / While Condition fault origin to each:

• references/runtime-exceptions/playbooks/null-reference-exception.md
• references/runtime-exceptions/playbooks/key-not-found-exception.md

Each notes the key nuance: the condition resolves before either branch runs, so the fault is in the If itself, not in a Then/Else activity.

Tests (tests/tasks/uipath-troubleshoot/runtime-exceptions/<scenario>/)

Two faithful-replay e2e diagnose scenarios where an If Condition throws:

Scenario	If Condition modeled
if-null-reference-exception	If status.ToString() == "yes" with status null
if-key-not-found-exception	If config["FeatureEnabled"] == "true" with the key absent

Each ships README, RESOLUTION, task.yaml, mock OR fixtures (folders + Faulted jobs get with the at If "…" stack + error logs), and a process/ snapshot. Graded on skill_triggered + llm_judge vs RESOLUTION.md.

Validation — coder-eval

experiments/default.yaml, --repeats 3 -j 3. 6 / 6 SUCCESS @ weighted_score 1.0.

Scenario	00	01	02
if-null-reference-exception	✅ 1.0	✅ 1.0	✅ 1.0
if-key-not-found-exception	✅ 1.0	✅ 1.0	✅ 1.0

Manifest verifier: 0 invalid / 0 parse errors. /lint-task: OK.

🤖 Generated with Claude Code

[github-actions]

Claude finished @Stefan-Virgil's task in 2m 18s —— View job

---

PR Review: feat(uipath-troubleshoot): add If-condition NRE + KeyNotFound coverage + tests

• Read review criteria and project conventions
• Run diff against base branch
• Read existing PR conversation
• Review playbook changes
• Review test scenarios (if-null-reference-exception)
• Review test scenarios (if-key-not-found-exception)
• Check cross-skill references, links, secrets
• Post final review

---

Summary

Extends the uipath-troubleshoot runtime-exception playbooks with If/While condition fault origins for NullReferenceException and KeyNotFoundException, and adds two faithful-replay e2e test scenarios. The approach is DRY — one bullet added to each existing playbook rather than new files. Tests follow the canonical task shape.

Change-by-Change Review

1. skills/uipath-troubleshoot/references/runtime-exceptions/playbooks/null-reference-exception.md (+1 line)

OK

Adds an If / While / Retry Scope Condition fault origin to the "What can cause it" list. Well-written, includes the key nuance (condition resolves before either branch runs), and includes concrete examples. Correctly placed alongside the existing cause bullets.

2. skills/uipath-troubleshoot/references/runtime-exceptions/playbooks/key-not-found-exception.md (+1 line)

OK

Same pattern — adds an If / While Condition fault origin. Omits Retry Scope (reasonable: a retry predicate is unlikely to index a dictionary). Good.

3. tests/tasks/uipath-troubleshoot/runtime-exceptions/if-null-reference-exception/task.yaml

Severity: Medium — copy-paste description says "Assign"

Line 4: faulted with System.NullReferenceException thrown from an Assign expression — should say "thrown from an If Condition expression" (or similar). The scenario models an If condition fault, not an Assign. This doesn't affect test execution but misleads anyone reading the task description.

Fix this →

4. tests/tasks/uipath-troubleshoot/runtime-exceptions/if-key-not-found-exception/task.yaml

Severity: Medium — same copy-paste description says "Assign"

Line 4: same issue — thrown from an Assign expression should reference If Condition.

Fix this →

5. tests/tasks/uipath-troubleshoot/runtime-exceptions/if-null-reference-exception/fixtures/mocks/responses/manifest.json

Severity: Low — stale doc strings

Two copy-paste artifacts from the Assign scenarios:

• Line 3: _doc says "Assign-originated" → should be "If-Condition-originated"
• Line 32: expected_calls[1].description says "the stack frame pointing at Main.xaml / the Assign" → should say "/ the If"

These are _doc / description strings with no functional impact, but they're misleading.

6. tests/tasks/uipath-troubleshoot/runtime-exceptions/if-key-not-found-exception/fixtures/mocks/responses/manifest.json

Severity: Low — same stale doc strings

Lines 3 and 32: same "Assign-originated" and "the Assign" leftovers as the sibling scenario.

7. Mock fixtures (job-get, job-logs, folders-list) — both scenarios

OK

The actual mock data is correct: stack traces reference If "Check Status Is Yes" and If "Check Feature Enabled", process names match (EligibilityRouter, FeatureToggleGate), job keys are consistent across all fixture files, and the FolderKey values reference the Shared folder correctly.

8. process/Main.xaml — both scenarios

OK

Realistic UiPath XAML that correctly models each fault: NRE scenario assigns null to status then calls status.ToString() in the If condition; KNF scenario builds a dictionary with only "Environment" key then indexes "FeatureEnabled" in the If condition. Both are minimal and clear.

9. process/project.json + process/project.uiproj — both scenarios

OK

Standard UiPath project files. Project names match the ReleaseName in mock data. No secrets or personal paths.

10. README.md + RESOLUTION.md — both scenarios

OK

READMEs clearly explain what the original session uncovered and how the test reproduces it. RESOLUTIONs provide detailed root cause, evidence, immediate fix, and an investigation-summary hypothesis table. Both correctly emphasize the key nuance: condition resolution precedes branch execution.

What's Missing

Nothing identified. The PR correctly extends existing playbooks (DRY), follows the canonical success-criteria shape (skill_triggered + llm_judge only), uses the correct tags (e2e, not smoke), and no CODEOWNERS change is needed (existing skill path).

Area Ratings

Area	Status	Notes
Frontmatter	N/A	No SKILL.md changes
E2E Tests	Issue	6 stale "Assign" references in task descriptions + manifest doc strings (Medium/Low)
Skill Body	OK	Playbook additions are minimal, accurate, and well-placed
References & Assets	OK	All fixture files internally consistent
Repo Hygiene	OK	No secrets, no cross-skill deps, scoped changes

Issues for Manual Review

• The NRE playbook bullet adds Retry Scope alongside If/While, but the KNF playbook omits Retry Scope. This seems intentional (retry predicates are unlikely to index a dictionary) — worth confirming it's a deliberate design choice rather than an oversight.

Conclusion

Clean PR with a well-executed DRY approach. The only real issue is 6 copy-paste "Assign" leftovers in task descriptions and manifest doc strings across 4 files — these should say "If Condition" instead. The mock fixtures, XAML, RESOLUTIONs, and playbook additions are all correct and internally consistent. Recommend fixing the stale descriptions before merge.

[github-actions]

Claude finished @Stefan-Virgil's task in 2m 42s —— View job

---

Coder-eval task lint (advisory)

2 task YAMLs changed; verdict counts: 0 Critical, 0 High, 0 Medium, 2 Low, 0 OK.

Rubric: .claude/commands/lint-task.md. This check is advisory and never blocks merge.

Evidence of passing run

• ✅ Author confirms passing run: "experiments/default.yaml, --repeats 3 -j 3. 6 / 6 SUCCESS @ weighted_score 1.0." — per-scenario results table included.

Per-task lint

tests/tasks/uipath-troubleshoot/runtime-exceptions/if-key-not-found-exception/task.yaml — verdict: Low (theme-captured; see Theme 1)

tests/tasks/uipath-troubleshoot/runtime-exceptions/if-null-reference-exception/task.yaml — verdict: Low (theme-captured; see Theme 1)

Within-PR duplicates

• No duplicate clusters detected. Both tasks share the troubleshoot scaffold but exercise materially distinct exceptions (KeyNotFoundException vs NullReferenceException) from If Condition expressions, with different RESOLUTION.md root causes, different mock fixtures, and different XAML processes.

Themes

• Theme 1 (Low) — Description says "Assign expression", should say "If Condition". Both new task.yaml files have description: (line 3-6) stating the exception was "thrown from an Assign expression", but the scenarios model faults thrown while resolving an If activity Condition expression. README.md, RESOLUTION.md, and mock fixtures (Info field in jobs-get JSON) all correctly reference If activities. Copy-paste artifact from the Assign-based siblings on the base branch. Suggested fix: change "thrown from an Assign expression" → "thrown while resolving an If Condition expression" in both task.yaml description fields. Fix this →

Conclusion

• ⚠ 2 task(s) have issues, max severity Low. Advisory only — not blocking merge.

---

[Stefan-Virgil]

Addressed the Theme 1 (Low) finding in 36da442: both task.yaml description: fields now read "thrown while resolving an If Condition expression" instead of "…from an Assign expression" (a copy-paste artifact from the Assign-based siblings). README/RESOLUTION/mock fixtures already referenced If correctly.

Description-only metadata change — no impact on mock dispatch, prompt, or success criteria, so the 6/6 @ 1.0 validation stands (no re-run needed).