<!-- Please let the below note in for people that find this PR -->
> [!NOTE]
> Are you waiting for the changes in this PR to be merged?
> It would be very helpful if you could [test the resulting
artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from
this PR and let us know in a comment if this change resolves your issue.
Thank you!

# XAML C# Expressions

Write C# expressions directly in XAML — no more converters, no more
boilerplate.

## ⚠️ Experimental Feature

This is an **experimental preview feature** for .NET 11. The API and
syntax may change before release.

### How to Enable

Add to your project file:

```xml
<PropertyGroup>
    <EnablePreviewFeatures>true</EnablePreviewFeatures>
</PropertyGroup>
```

Without this flag, using C# expression syntax results in error
**MAUIX2012**.

### Requirements

- SourceGen mode (default in .NET 11)
- `x:DataType` attribute on your page/view

## Example

```xml
<ContentPage x:DataType="local:ProductViewModel">
    
    <!-- Simple binding -->
    <Label Text="{ProductName}" />
    
    <!-- String interpolation -->
    <Label Text="{$'{Quantity}x {ProductName}'}" />
    
    <!-- Calculations -->
    <Label Text="{$'Total: ${Price * Quantity:F2}'}" />
    
    <!-- Boolean negation (no converter needed!) -->
    <Label IsVisible="{!IsLoading}" />
    
    <!-- Boolean expressions (no MultiBinding needed!) -->
    <Button Text="Submit" 
            IsEnabled="{HasAccount &amp;&amp; AgreedToTerms}" />
    
    <!-- Inline event handlers (no code-behind needed!) -->
    <Button Text="{$'Clicked {ClickCount} times'}" 
            Clicked="{(s, e) => ClickCount++}" />
    
    <!-- Ternary expressions -->
    <Label Text="{IsVip ? 'Gold Member' : 'Standard'}" />
    
</ContentPage>
```

## Syntax Highlights

Some of the supported expressions (see [full
spec](https://github.com/dotnet/maui/blob/dev/stdelc/xaml%2Bcode-clean/docs/specs/XamlCSharpExpressions.md)
for complete reference):

| Feature | Syntax | Example |
|---------|--------|---------|
| Property binding | `{Property}` | `{Username}` |
| Nested property | `{A.B}` | `{User.DisplayName}` |
| String interpolation | `{$'..{x}..'}` | `{$'Hello {Name}!'}` |
| Boolean negation | `{!Bool}` | `{!IsHidden}` |
| Boolean AND/OR | `{A && B}` | `{IsLoaded &amp;&amp; HasData}` |
| Arithmetic | `{A * B}` | `{Price * Quantity}` |
| Ternary | `{c ? a : b}` | `{IsVip ? 'Gold' : 'Standard'}` |
| Null-coalesce | `{a ?? b}` | `{Title ?? 'Untitled'}` |
| Lambda events | `{(s, e) => ...}` | `{(s, e) => Count++}` |
| Local method | `{Method()}` | `{GetDisplayText()}` |
| Static member | `{Type.Member}` | `{DateTime.Now}` |

## What's NOT Supported

- Async lambdas (`{async (s, e) => ...}`) — use regular methods
- Parameterless lambdas (`{() => ...}`) — must include `(s, e)`
- XamlC or Runtime inflation — SourceGen only

## Resources

- **Sample App**:
[MauiXamlCsharpSample](https://github.com/jfversluis/MauiXamlCsharpSample)
by Gerald Versluis
- **Full Spec**:
[docs/specs/XamlCSharpExpressions.md](https://github.com/dotnet/maui/blob/dev/stdelc/xaml%2Bcode-clean/docs/specs/XamlCSharpExpressions.md)

…3861)

<!-- Please let the below note in for people that find this PR -->
> [!NOTE]
> Are you waiting for the changes in this PR to be merged?
> It would be very helpful if you could [test the resulting
artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from
this PR and let us know in a comment if this change resolves your issue.
Thank you!

## Summary

Enhances the `pr-finalize` skill with a **two-phase workflow** that
includes code review, and adds critical safety rules preventing agents
from approving or blocking PRs.

### What This PR Does

1. **Adds Phase 2: Code Review** - After verifying title/description,
the skill now performs a code review for best practices
2. **Adds critical safety rule** - Agents must NEVER use `--approve` or
`--request-changes` flags
3. **Keeps skill focused** - Users can invoke with different models
themselves if they want multi-model coverage

---

## Commits

### 1. `2ad480c77d` - Add multi-model code review to pr-finalize skill

**Original commit** that added the code review phase to pr-finalize.

### 2. `71eb8c2216` - Add critical rule: agents must NEVER
approve/request-changes on PRs

**Why:** AI agents should never make approval decisions on PRs. That's a
human responsibility.

**Changes:**
- Added prominent `🚨 CRITICAL` warning section at top of skill
- Added CRITICAL note to `copilot-instructions.md`
- Only `gh pr review --comment` is allowed

### 3. `335be127cb` - Simplify pr-finalize: remove multi-model
orchestration, keep code review

**Why:** After review, decided that multi-model orchestration should be
user-controlled, not built into the skill. Users can invoke pr-finalize
with different models themselves if they want multi-model coverage.

**Changes:**
- Removed 5-model orchestration logic (model table, parallel execution,
consensus synthesis)
- Renamed "Multi-Model Code Review" → "Code Review"
- Fixed contradiction: removed `--approve`/`--request-changes` examples
that conflicted with the NEVER rule
- Kept the code review focus areas and output format
- Reduced skill from 422 → 373 lines

---

## The Two-Phase Workflow

### Phase 1: Title & Description Review
- Verify PR metadata matches actual implementation
- Check for required NOTE block
- Ensure title is searchable and informative

### Phase 2: Code Review
- Review code for best practices
- Focus on: code quality, error handling, performance, platform
concerns, breaking changes
- Post findings as **comment only** (never approve/request-changes)

---

## Key Safety Rule

```markdown
## 🚨 CRITICAL: NEVER Approve or Request Changes

**AI agents must NEVER use `--approve` or `--request-changes` flags.**

| Action | Allowed? | Why |
|--------|----------|-----|
| `gh pr review --approve` | ❌ **NEVER** | Approval is a human decision |
| `gh pr review --request-changes` | ❌ **NEVER** | Blocking PRs is a human decision |
| `gh pr review --comment` | ✅ **OK** | Findings for human review |
```

---

## Files Changed

| File | Changes |
|------|---------|
| `.github/skills/pr-finalize/SKILL.md` | Added Phase 2 code review,
safety rules, simplified orchestration |
| `.github/copilot-instructions.md` | Updated skill description, added
CRITICAL note |

---

## Why Not Multi-Model Orchestration?

The original approach had the skill orchestrate 5 different AI models in
parallel. This was removed because:

1. **User control** - Users can invoke pr-finalize with `model`
parameter themselves
2. **Simplicity** - Skill focuses on *what* to review, not *how* to
orchestrate
3. **Flexibility** - Users choose when multi-model is worth the cost
4. **Avoids contradictions** - Original had consensus logic that
conflicted with "never approve" rule

---

## Issues Fixed

N/A - Enhancement to agent workflow

---------

Co-authored-by: Jakub Florkowski <kubaflo123@gmail.com>

<!-- Please let the below note in for people that find this PR -->
> [!NOTE]
> Are you waiting for the changes in this PR to be merged?
> It would be very helpful if you could [test the resulting
artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from
this PR and let us know in a comment if this change resolves your issue.
Thank you!

## Description

Fixes iOS integration test failures that have been occurring since Jan
23, 2026 on the `main` branch.

### Root Cause

When launching iOS apps via XHarness/mlaunch, a race condition occurs
where the simulator reports as "booted" but is still internally in the
"Booting" state. This causes app launch to fail with:

```
An error was encountered processing the command (domain=com.apple.CoreSimulator.SimError, code=405):
Unable to lookup in current state: Booting

error HE0042: Could not launch the app on the device: simctl returned exit code 149
```

### Fix

This PR adds a `WaitForBootComplete()` method to the `Simulator` class
which uses `simctl bootstatus` to block until the simulator is fully
booted before attempting to run tests. The `IOSSimulatorFixture` now
calls this method after launching the simulator.

### Affected Tests

- `RunOniOS_MauiDebug`
- `RunOniOS_MauiRelease`
- `RunOniOS_MauiReleaseTrimFull`
- `RunOniOS_BlazorDebug`
- `RunOniOS_BlazorRelease`
- `RunOniOS_MauiNativeAOT`

### Changes

- Added `Simulator.WaitForBootComplete()` method in `Apple/Simulator.cs`
- Updated `IOSSimulatorFixture` constructor to call
`WaitForBootComplete()` after `Launch()`

<!-- Please let the below note in for people that find this PR -->
> [!NOTE]
> Are you waiting for the changes in this PR to be merged?
> It would be very helpful if you could [test the resulting
artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from
this PR and let us know in a comment if this change resolves your issue.
Thank you!

### Description of Change

The Android integration tests (`RunOnAndroid`) were failing with "Failed
to launch Test AVD" because the emulator was being launched in every
test's constructor instead of once in the shared fixture.

**Root Cause:**
The `AndroidTemplateTests` constructor was calling
`LaunchAndWaitForAvd()` for each test, which caused:
1. Multiple attempts to launch the same emulator 
2. Possible race conditions between tests
3. Each test waiting 600 seconds for an emulator that may have already
failed to boot in a previous test

**Fix:**
Moved the emulator launch from the test constructor to
`AndroidEmulatorFixture` constructor (one-time setup), matching how
`IOSSimulatorFixture` handles the simulator.

The collection fixture now:
1. Accepts SDK licenses
2. Installs the AVD
3. **Launches and waits for the emulator to boot (NEW)**

Individual tests no longer attempt to launch the emulator - they use the
already-running emulator from the shared fixture.

### Issues Fixed
Fixes Android integration test failures on CI

<!-- Please let the below note in for people that find this PR -->
> [!NOTE]
> Are you waiting for the changes in this PR to be merged?
> It would be very helpful if you could [test the resulting
artifacts](https://github.com/dotnet/maui/wiki/Testing-PR-Builds) from
this PR and let us know in a comment if this change resolves your issue.
Thank you!

## Description

Fixes an issue where `eng/build.ps1` always exited with code 0
regardless of whether the underlying build succeeded or failed. This
caused Azure Pipelines to show steps as "succeeded" even when they
failed.

### Problem

When running `./build.cmd -build` (without `-restore`), if the .NET SDK
is not found, the script would:
1. Print "Unable to find dotnet with SDK version..."
2. Call `ExitWithExitCode 1` in `tools.ps1`
3. But `eng/build.ps1` would still exit with 0 (line 146: `exit 0`)

This caused Azure Pipelines to show the step as green/succeeded when it
should have been red/failed.

### Fix

- Capture `$LASTEXITCODE` after `Invoke-Expression` call to
`common/build.ps1`
- Use the captured exit code instead of always exiting 0

### Testing

This fix was identified while investigating Windows Helix device test
failures where the "Build the MSBuild Tasks" step was showing as
succeeded but had actually failed to find the SDK.

Build with the issue:
https://dev.azure.com/dnceng-public/public/_build/results?buildId=1279950