Prevent NullReferenceException in LayoutButton

.config/dotnet-tools.json

@@ -24,7 +24,7 @@
       "rollForward": false
     },
     "microsoft.dotnet.xharness.cli": {
-      "version": "11.0.0-prerelease.26107.1",
+      "version": "11.0.0-prerelease.26229.1",
       "commands": [
         "xharness"
       ],

.github/copilot-instructions.md

@@ -101,6 +101,22 @@ When referencing or triggering CI pipelines, use these current pipeline names:
 
 **⚠️ Old pipeline names** (e.g., `MAUI-UITests-public`, `MAUI-public`) are **outdated** and should NOT be used. Always use the names above.
 
+### Investigating CI Failures
+
+**🚨 ALWAYS use the `azdo-build-investigator` skill when investigating CI failures or assessing merge readiness.** Its instructions direct you to invoke the `ci-analysis` skill first for the core investigation workflow, then apply MAUI-specific corrections (correct pipeline names, XHarness quirks, binlog guidance).
+
+Do NOT default to manually querying AzDO APIs or rely solely on `gh pr checks` pass/fail counts.
+
+**When to use it:**
+- "How does CI look?" / "Is CI green?" / "Can we merge?"
+- "What's failing?" / "Are these known failures?"
+- "Is this PR safe to merge?" / "Any CI concerns?"
+- After any PR push to verify the build
+
+**Verifying specific tests:** When asked "did test X pass?" or "did the new test run?", query the **actual AzDO test results** — do NOT infer whether a test ran by inspecting code attributes. Class-level traits, base class categories, and assembly-level attributes can all cause a test to run even when the method itself has no visible category. Check the evidence, not the code.
+
+**Anti-pattern:** Writing ad-hoc scripts to parse AzDO build timelines. The skills handle Helix work item details, known issue cross-referencing, and test result aggregation that manual approaches miss.
+
 ### Gradle / Maven Dependency Failures (CFSClean)
 
 The official CI build uses CFSClean network isolation which blocks `repo.maven.apache.org`. All Gradle/Maven dependencies resolve through the `dotnet-public-maven` Azure Artifacts feed.
@@ -309,11 +325,6 @@ Skills are modular capabilities that can be invoked directly or used by agents.
    - **Two modes**: Verify failure only (test creation) or full verification (test + fix)
    - **Used by**: After creating tests, before considering PR complete
 
-9. **pr-build-status** (`.github/skills/pr-build-status/SKILL.md`)
-   - **Purpose**: Retrieves Azure DevOps build information for PRs (build IDs, stage status, failed jobs)
-   - **Trigger phrases**: "check build for PR #XXXXX", "why did PR build fail", "get build status"
-   - **Used by**: When investigating CI failures
-
 10. **run-integration-tests** (`.github/skills/run-integration-tests/SKILL.md`)
    - **Purpose**: Build, pack, and run .NET MAUI integration tests locally
    - **Trigger phrases**: "run integration tests", "test templates locally", "run macOSTemplates tests", "run RunOniOS tests"

.github/pr-review/pr-preflight.md

@@ -12,6 +12,7 @@
 4. **Classify files** — separate fix files from test files, identify test type (UI / Device / Unit)
 5. **Document edge cases** — from comments mentioning "what about...", "does this work with..."
 6. **Record PR's fix** in Fix Candidates table (pending validation)
+7. **Identify impacted UI test categories** — analyze which UI controls could be affected by this PR (see below)
 
 ```bash
 # Fetch PR metadata
@@ -35,15 +36,43 @@ gh pr view XXXXX --json comments --jq '.comments[] | select(.body | contains("Fi
 
 ---
 
-## Part B: Code Review (Step 7)
+## Step 7: Identify Impacted UI Test Categories
+
+After classifying files, determine which UI test categories could be affected by the PR changes. This enables targeted UI test runs instead of running the full matrix (~2h).
+
+**How to identify categories:**
+1. Look at the **controls modified** in the PR (e.g., changes to `Button` handler → `Button` category)
+2. Consider **indirect impacts** (e.g., a layout change could affect `Layout`, `CollectionView`, `ListView`)
+3. Check the **issue description** for mentions of specific controls
+4. Consider **platform-specific impacts** (e.g., iOS SafeArea changes → `SafeAreaEdges`)
+
+**Available categories:**
+Read the canonical list from [`src/Controls/tests/TestCases.Shared.Tests/UITestCategories.cs`](../../src/Controls/tests/TestCases.Shared.Tests/UITestCategories.cs) — every `public const string` value in that file is a valid category. Only use category names defined there; AI-suggested names that aren't in the file will be filtered out by `detect-ui-test-categories.ps1` to avoid creating empty matrix jobs.
+
+**Output file:**
+```bash
+mkdir -p CustomAgentLogsTmp/PRState/{PRNumber}/PRAgent/uitests
+```
+
+Write `ai-categories.md`:
+```markdown
+Button — PR modifies ButtonHandler click event logic
+Layout — Changes to StackLayout could affect child arrangement
+```
+
+One category per line, followed by ` — ` and a brief justification. Write `NONE` if the PR has no UI impact (e.g., docs-only, build scripts, backend-only changes).
+
+---
+
+## Part B: Code Review (Step 8)
 
 > **Purpose:** Perform deep code analysis using the `code-review` skill to surface correctness issues, safety concerns, and MAUI convention violations BEFORE Try-Fix explores alternatives. These findings guide Try-Fix models toward higher-quality fixes.
 
-> **🚨 Independence-first requirement:** Step 7 MUST be invoked as a **separate sub-agent** (via the `task` tool with `agent_type: "general-purpose"`) so the code-review skill can form its assessment from the code BEFORE reading any PR narrative. The sub-agent receives ONLY the PR number — not the context gathered in Part A. This prevents anchoring bias.
+> **🚨 Independence-first requirement:** Step 8 MUST be invoked as a **separate sub-agent** (via the `task` tool with `agent_type: "general-purpose"`) so the code-review skill can form its assessment from the code BEFORE reading any PR narrative. The sub-agent receives ONLY the PR number — not the context gathered in Part A. This prevents anchoring bias.
 >
-> **Validation constraint:** The Step 7 prompt MUST NOT contain issue titles, root-cause descriptions, bug summaries, or any Part A content — only `PR #XXXXX`. If you find yourself adding context "to help" the sub-agent, you are violating independence-first.
+> **Validation constraint:** The Step 8 prompt MUST NOT contain issue titles, root-cause descriptions, bug summaries, or any Part A content — only `PR #XXXXX`. If you find yourself adding context "to help" the sub-agent, you are violating independence-first.
 
-7. **Invoke the code-review skill as a sub-agent:**
+8. **Invoke the code-review skill as a sub-agent:**
 
    Use the `task` tool to launch a separate agent. The prompt MUST NOT contain issue titles, root-cause descriptions, or any Part A context — only the PR number.
 
@@ -69,7 +98,7 @@ gh pr view XXXXX --json comments --jq '.comments[] | select(.body | contains("Fi
    5. Check CI status
    6. Blast radius, failure-mode probing, and verdict
 
-**If Step 7 fails, times out, or returns malformed output:**
+**If Step 8 fails, times out, or returns malformed output:**
 - Write `pre-flight/code-review.md` with: `## Code Review: SKIPPED\n\nReason: {failure description}`
 - Set verdict to `SKIPPED` in the Code Review Summary section of `content.md`
 - Omit `hints` from Try-Fix prompts (the `hints` field becomes optional when code review is unavailable)