[tylerkron]

refs #327 — not merging, for review.

What was wrong

ChannelsPanePrototype.axaml (the desktop Channels tab) declared no x:DataType, so all 81 of its bindings resolved by reflection: 72 attribute bindings plus the 9 <Binding> children of its 4 MultiBindings, counted by parsing the XAML (not grepping it). Rename or delete a member on ChannelsPaneViewModel, ChannelTileViewModel, IChannel or IStreamingDevice and a tile would render blank, or a drawer control would stop responding, while every head still built green.

The fix

Scope	Declared or inferred	Type
root	declared, with x:CompileBindings="True"	ChannelsPaneViewModel
ChannelTileTemplate (keyed, in UserControl.Resources)	declared	ChannelTileViewModel
the tile's 3 hops (IsLoggingActive, ToggleChannelCommand, OpenSettingsCommand) via $parent[UserControl].DataContext	inferred, no cast needed	ChannelsPaneViewModel
device-name chip ItemTemplate	inferred from ConnectedDeviceNames	string
palette ItemTemplate	declared	IBrush
its 2 hops (SelectedChannel.ChannelColorBrush, SetColorCommand) via $parent[UserControl]	inferred	ChannelsPaneViewModel
SwatchButton's ControlTemplate (Background="{Binding}")	declared	IBrush

Why each declaration is there:

• The tile template is required. A resource-dictionary DataTemplate infers nothing. With the declaration removed, the build fails with 14 AVLN2000s on XamlPseudoType. All three lists that use the template (AnalogInputs, DigitalInputs, DigitalOutputs) are ObservableCollection<ChannelTileViewModel>.
• The palette template and the swatch ControlTemplate compile without their declarations today, because the bindings inside them have no member path (<Binding/> and {Binding}). They are declared anyway because both would otherwise be typed wrongly. Palette is an array, and an array infers nothing. A ControlTemplate is not a new scope, so it would type-check against the root's ChannelsPaneViewModel, but at runtime its DataContext is the palette entry. The type is IBrush, not Brush. ChannelsPaneViewModel has using Brush = Avalonia.Media.IBrush;, so Palette is really an IBrush[] holding ImmutableSolidColorBrushes. My first draft declared Brush (the abstract Avalonia class). That compiled and was wrong, and I caught it only by reading the view-model's usings.

IChannel gains string ScaleExpressionError { get; }. Without it, the drawer's error label (SelectedChannel.ScaleExpressionError, where SelectedChannel is typed IChannel) is AVLN2000. This is not a runtime bug fix. On main the reflection binding resolves against the concrete AbstractChannel, which has always had the member, so the label worked. The interface simply didn't declare it. The hunk is byte-identical to the one in #392 (ChannelsMobileView), which needs the same member for the same reason. So the two PRs should merge in either order without a conflict in that file. AbstractChannel is the only IChannel implementer in the repo.

What DataContext each scope holds at runtime (read, not observed)

The one host is MainWindow.axaml's Channels tab: <ContentControl Content="{Binding}"> whose ContentTemplate holds <prototype:ChannelsPanePrototype/>. So the pane first inherits the window's DaqifiViewModel. Its code-behind then swaps in its own view-model in OnLoaded (if (DataContext is not ChannelsPaneViewModel) DataContext = new ChannelsPaneViewModel();) and nulls it in OnUnloaded. HeadlessBench builds a ChannelsPaneViewModel directly and never this view. ChannelsPaneViewModel is the only type these bindings are written for.

The one runtime difference: SelectedDevice.PwmFrequencyHz before OnLoaded (re-checked by a shepherd, 2026-09-18). Between the pane attaching and OnLoaded firing, the pane holds the window's DaqifiViewModel on the first visit and null on later visits (#397 measured this on the Devices pane, which has the same host and the same swap). On main, the reflection binding SelectedDevice.PwmFrequencyHz resolved against DaqifiViewModel.SelectedDevice during that window. It is the only root path whose name also exists on DaqifiViewModel. DaqifiViewModel.IsLoggingActive is an explicit interface implementation, so reflection never saw it. On this branch the compiled binding rejects the mismatched type and the box stays blank. This is not a regression, because main was showing the wrong data there:

• DaqifiViewModel.SelectedDevice is the Devices pane's selection. This pane's SelectedDevice is a different property. OnLoaded creates a fresh ChannelsPaneViewModel whose SelectedDevice is null and whose IsSettingsOpen is false. It is set only by OpenSettings, which runs when the user clicks a tile's cog, to the device that owns that channel (FindOwningDevice), and it is cleared again by CloseSettings. So once the swap happens, both main and this branch show a blank box inside a closed drawer. The value never comes back after OnLoaded.
• It lasted one to two frames, 16–37 ms by Devices pane paints one or two frames with the settings drawer forced open on every tab visit (pre-OnLoaded DataContext) #397's measurement, and only on the first visit to Channels. Later visits carry null, so main is blank there too. It also needs a device to be selected in Devices at that moment. The drawer is visible in that frame only because a failed IsSettingsOpen binding leaves IsVisible at its default true, on both main and this branch. That is Devices pane paints one or two frames with the settings drawer forced open on every tab visit (pre-OnLoaded DataContext) #397's defect, and this PR neither causes nor fixes it.
• No write-back was possible. The binding is UpdateSourceTrigger=LostFocus, and nothing can take focus within that frame.

This conclusion is read from the code plus #397's frame measurement. I did not capture a frame of the Channels pane myself.

Verification

• One-build positive control on main. I put a typo in the root scope (HasConnectedDeviceQ), a typo in the tile template (TileBackgroundQ) and a bogus property (BogusPropertyQ on the root Grid) in the same build. The result was exactly 1 error: the property AVLN2000 at (336,10). The compiler read the file and said nothing about either typo, which is the defect this PR closes.

• Branch, one typo per scope, all 11 in one build from a fresh edit. Result: 11 AVLN2000s, each naming the right type:

  • ChannelsPaneViewModel via the tile's $parent hop (151), at the root (350), and via the palette's $parent hop (638)
  • ChannelTileViewModel (153)
  • IChannel through the tile's Channel. (177), through a MultiBinding child (650), and through SelectedChannel. (787)
  • IBrush in the swatch ControlTemplate (299) and in the palette template (629)
  • string in the chip template (404)
  • IStreamingDevice through SelectedDevice. (768)

• Swatch ControlTemplate runtime-type control (shepherd, 2026-09-18, one build from a fresh edit). At runtime the template's Border gets its DataContext from the swatch Button. The Button sets no DataContext and no Content, so that DataContext is the palette item: an ImmutableSolidColorBrush from Palette, which is an IBrush[]. The type that must be checked is therefore IBrush. In one build, next to {Binding} I added Tag="{Binding OpacityQ}" (a typo) and Opacity="{Binding Opacity}" (a member of IBrush but not of ChannelsPaneViewModel). The result was exactly 1 AVLN2000: 'OpacityQ' on type 'Avalonia.Media.IBrush' at (300,29). Opacity was accepted. Then, from another fresh edit, I removed the template's x:DataType="IBrush". The result was 2 errors, both naming ChannelsPaneViewModel, one for OpacityQ and one for the valid Opacity. So without the declaration the template type-checks against the wrong type, and the declaration is what makes it correct. I reverted the edit afterwards, and the clean build exited 0.

• Declaration-necessity control. I dropped all three inner declarations in one build. The result was 14 AVLN2000 on XamlPseudoType, all in the tile template. The two IBrush declarations are not needed to compile, as stated above.

• Test: ChannelsPanePrototypeBindingTests, 28 lines, using only existing BindingFacts helpers (AssertRootDeclares ×2, AssertNoEscapeHatch). I ran two mutations against it:

  • Deleting the root x:CompileBindings line fails the CompileBindings row (1/3 red).
  • Adding x:CompileBindings = 'False' on the palette template fails the escape-hatch row (1/3 red).

• Build gate is green: desktop, iOS restore, and iOS Release iossimulator-arm64 (the iOS leg was incremental). dotnet test passes 996/996.

• Rendering: tools/parity-audit/run.sh --check-baseline, run alone (load avg ~1.5, no other capture running), gave 39/39 in one run. The denominator is git show origin/main:tools/parity-audit/baselines/macos-arm64.sha256 | wc -l = 39. desktop-3-channels and desktop-min-3-channels are byte-identical to main's baseline. Those screens show the no-device state, so they exercise the root scope and the empty-state gate. The tiles, the settings drawer, the palette and the swatch were not rendered; the compiler controls above cover them.

• Warnings: delta 0, taken from CI's own logs at both ends: main 642caef, run 35377977069, against this head 4b13ea8, run 35394779286. These are all-project totals per job from cold CI builds:

  • Desktop-on-macOS 169 → 169
  • iOS 170 → 170
  • Android 175 → 175
  • Library+Desktop+capture 169 → 169

  The distinct (file, line, code) warning sets are identical for every job. CI tests went 993 → 996.

Coordination

• fix(#327): ChannelsMobileView's 76 bindings were all on reflection — two declared templates, three cast hops, and a drawer label bound to a member IChannel never had #392 (ChannelsMobileView) carries the identical IChannel hunk; see above.
• ChannelScalingExpressionTests.The_scaling_error_label_shows_the_reason_on_both_heads has a comment saying neither view declares an x:DataType, and fix(#327): ChannelsMobileView's 76 bindings were all on reflection — two declared templates, three cast hops, and a drawer label bound to a member IChannel never had #392 rewrites it to say the desktop view still doesn't. I left that file alone to avoid a conflict with fix(#327): ChannelsMobileView's 76 bindings were all on reflection — two declared templates, three cast hops, and a drawer label bound to a member IChannel never had #392. Whichever PR lands second should correct the comment. The test itself still passes, because its AssertBinds literal is unchanged.

Diffstat: +55 / −6 across 3 files (+28 test, +20/−6 view, +7 interface).

🤖 Generated with Claude Code

[tylerkron]

/agentic_review

[qodo-code-review]

PR Summary by Qodo

Compile Channels pane bindings and expose channel scale errors

🐞 Bug fix 🧪 Tests 🕐 20-40 Minutes

AI Description

• Compile all 81 Channels pane bindings against explicit root and template data types.
• Expose scale-expression errors through IChannel for typed drawer bindings.
• Guard compiled-binding declarations and prohibit reflection escape hatches.

Diagram

graph TD
  Tests["Binding tests"] -->|validates declarations| View["Channels pane"] -->|root bindings| RootVM["Channels VM"] -->|selected channel| Channel["IChannel"]
  View -->|item scope| TileTemplate["Tile template"] -->|typed bindings| TileVM["Tile VM"]
  View -->|palette scope| PaletteTemplates["Palette templates"] -->|typed bindings| Brush["IBrush"]

Loading

High-Level Assessment

The scoped approach is appropriate: explicit root and template types make binding failures compile-time errors without changing binding behavior across unrelated views. Enabling compiled bindings project-wide was considered but would broaden risk substantially and should remain a separate migration.

Files changed (3) +55 / -6

Bug fix (2) +27 / -6

IChannel.csExpose scale-expression errors on IChannel +7/-0

Expose scale-expression errors on IChannel

• Adds the read-only ScaleExpressionError contract already provided by AbstractChannel. This lets the compiled settings-drawer binding resolve through the SelectedChannel interface type.

Daqifi.Avalonia/Daqifi.Desktop/Channel/IChannel.cs

ChannelsPanePrototype.axamlEnable typed compiled bindings throughout the Channels pane +20/-6

Enable typed compiled bindings throughout the Channels pane

• Declares ChannelsPaneViewModel as the root binding type and enables compiled bindings. It explicitly types the keyed channel-tile template as ChannelTileViewModel and both palette-related template scopes as IBrush, allowing all 81 bindings to be compiler-checked.

Daqifi.Avalonia/Daqifi.Desktop/View/Prototype/ChannelsPanePrototype.axaml

Tests (1) +28 / -0

ChannelsPanePrototypeBindingTests.csGuard Channels pane compiled-binding configuration +28/-0

Guard Channels pane compiled-binding configuration

• Adds parsed-XAML tests verifying the root ChannelsPaneViewModel data type and compiled-binding flag. It also prevents nested escape hatches from silently restoring reflection bindings.

Daqifi.Avalonia.Tests/Views/ChannelsPanePrototypeBindingTests.cs

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0)

Great, no issues found!

Qodo reviewed your code and found no material issues that require review

Tip of the day

💡 Did you know, you can type 'qodo, fix this' on a finding and the fix lands right on your PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Previous reviews

Review updated until commit 4b13ea8 ⚖️ Balanced

Results up to commit 4b13ea8 ⚖️ Balanced

No changes from previous review

[tylerkron]

/agentic_review

[qodo-code-review]

Code review by qodo was updated up to the latest commit 4b13ea8

[tylerkron]

Qodo-clean, CI green — ready for review. Two Qodo rounds on head 4b13ea8, both graded Balanced with 0 findings. Each was confirmed to have fired after its trigger, and after each I waited 3+ minutes and re-checked: 0 Qodo threads. CI run 35394779286 on that same SHA is green on all heads, including Android and iOS. Not merging.

[tylerkron]

/agentic_review

[qodo-code-review]

Code review by qodo was updated up to the latest commit 4b13ea8

[tylerkron]

N-way merge check: all seven open #327-family PRs together (built locally from the #394 shepherd, nothing pushed)

Set: main 642caef + #387 (259a829) + #389 (808752a) + #390 (a7c89ec) + #391 (4370e80) + #392 (01764b9) + #393 (f1599e0) + #394 (4b13ea8).

• Merges clean in both orders. Order A: test(#327): one dialog-DataContext guard — the shared helper follows new+DataContext, DuplicateDeviceDialog's 412-line copy goes (−369) #387, fix(#327): LoggedSessionsMobileView's 51 bindings were all on reflection — one declared scope, two inferred, three $parent hops #389, fix(#327): ProfilesMobileView's 70 bindings were all on reflection — one declared scope, five inferred, one $parent hop #391, fix(#327): ChannelsMobileView's 76 bindings were all on reflection — two declared templates, three cast hops, and a drawer label bound to a member IChannel never had #392, fix(#327): ProfilesPane's 76 bindings were all on reflection — one declared scope, five inferred, three $parent hops #393, fix(#327): ChannelsPanePrototype's 81 bindings were all on reflection — three declared templates, and a drawer label bound to a member IChannel never declared #394, then fix(#327): DevicesMobileView's 65 bindings were all on reflection — one declared scope, one inferred, and nothing constructs the view yet #390. Order B: fix(#327): ChannelsPanePrototype's 81 bindings were all on reflection — three declared templates, and a drawer label bound to a member IChannel never declared #394 first, then fix(#327): DevicesMobileView's 65 bindings were all on reflection — one declared scope, one inferred, and nothing constructs the view yet #390, fix(#327): ProfilesPane's 76 bindings were all on reflection — one declared scope, five inferred, three $parent hops #393, fix(#327): ChannelsMobileView's 76 bindings were all on reflection — two declared templates, three cast hops, and a drawer label bound to a member IChannel never had #392, fix(#327): ProfilesMobileView's 70 bindings were all on reflection — one declared scope, five inferred, one $parent hop #391, fix(#327): LoggedSessionsMobileView's 51 bindings were all on reflection — one declared scope, two inferred, three $parent hops #389, test(#327): one dialog-DataContext guard — the shared helper follows new+DataContext, DuplicateDeviceDialog's 412-line copy goes (−369) #387. There were no conflicts, and both orders produce the same tree, 0903bf1.

• fix(#327): ChannelsMobileView's 76 bindings were all on reflection — two declared templates, three cast hops, and a drawer label bound to a member IChannel never had #392 and fix(#327): ChannelsPanePrototype's 81 bindings were all on reflection — three declared templates, and a drawer label bound to a member IChannel never declared #394 do not collide on IChannel. The ScaleExpressionError hunks are byte-identical: same position, same doc comment, and the same blob transition 7a0d6f0..c63a719 on both sides. The merged IChannel.cs declares the member exactly once, and the build has no CS0102. The merge order is free. Neither PR needs a change.

• Build gate on the merged tree:

  • desktop: 0 errors, 169 warnings
  • iOS Release iossimulator-arm64: 0 errors, 170 warnings

  Both warning totals match main's cold CI totals (run 35377977069), so the delta is 0. No lock file drifted. Android is not built locally; CI covers it.

• Tests: 1011/1011 pass. That reconciles exactly: 993 on main (run 35377977069), plus 0 from test(#327): one dialog-DataContext guard — the shared helper follows new+DataContext, DuplicateDeviceDialog's 412-line copy goes (−369) #387, plus 3 from each of fix(#327): LoggedSessionsMobileView's 51 bindings were all on reflection — one declared scope, two inferred, three $parent hops #389, fix(#327): DevicesMobileView's 65 bindings were all on reflection — one declared scope, one inferred, and nothing constructs the view yet #390, fix(#327): ProfilesMobileView's 70 bindings were all on reflection — one declared scope, five inferred, one $parent hop #391, fix(#327): ChannelsMobileView's 76 bindings were all on reflection — two declared templates, three cast hops, and a drawer label bound to a member IChannel never had #392, fix(#327): ProfilesPane's 76 bindings were all on reflection — one declared scope, five inferred, three $parent hops #393 and fix(#327): ChannelsPanePrototype's 81 bindings were all on reflection — three declared templates, and a drawer label bound to a member IChannel never declared #394. Each delta is read from that PR's own CI log. test(#327): one dialog-DataContext guard — the shared helper follows new+DataContext, DuplicateDeviceDialog's 412-line copy goes (−369) #387's delta of 0 is measured against its base, 25df7b8 (989 → 989).

• Stale green: test(#327): one dialog-DataContext guard — the shared helper follows new+DataContext, DuplicateDeviceDialog's 412-line copy goes (−369) #387's CI run (35376229626) merged into 25df7b8, which predates fix(#327): LiveGraphPane's 40 bindings were all on reflection — a tracker scope the compiler can't infer, one hop it can't follow #386 / 642caef. The other six PRs' runs all merged into current main 642caef. For test(#327): one dialog-DataContext guard — the shared helper follows new+DataContext, DuplicateDeviceDialog's 412-line copy goes (−369) #387 against today's main, this local build is the only evidence.

• Prose left for after the merge, not a merge defect: once fix(#327): ChannelsMobileView's 76 bindings were all on reflection — two declared templates, three cast hops, and a drawer label bound to a member IChannel never had #392 and fix(#327): ChannelsPanePrototype's 81 bindings were all on reflection — three declared templates, and a drawer label bound to a member IChannel never declared #394 have both landed, the comment in ChannelScalingExpressionTests.The_scaling_error_label_shows_the_reason_on_both_heads still says "The desktop view declares no x:DataType". That stops being true when fix(#327): ChannelsPanePrototype's 81 bindings were all on reflection — three declared templates, and a drawer label bound to a member IChannel never declared #394 lands. The test still passes. fix(#327): ChannelsPanePrototype's 81 bindings were all on reflection — three declared templates, and a drawer label bound to a member IChannel never declared #394's body already discloses this. Whichever PR lands second, or a one-line follow-up, should reword it.

[tylerkron]

Shepherd: Qodo-clean, CI green, ready for review. CI run 35394779286 is green on 4b13ea8, which is the current head (it checked out Merge 4b13ea8 into 642caef, today's main). I fired an independent round at 21:23:10Z on that unchanged head. It ran rather than being refused: the summary updated at 21:25:22Z, anchored on 4b13ea8, with 0 bugs, 0 rule violations and 0 requirement gaps. After a 200 s settle I re-checked both surfaces: still 0, and 0 qodo threads, with the author filter validated as 3 on control #196. The standing grade is Balanced, from the builder's round on this head. The new render shows no grade of its own. I also checked by hand: the host route and DataContext for each scope (MainWindow's tab hands DaqifiViewModel and OnLoaded swaps in ChannelsPaneViewModel), and the tile, palette and swatch template types against the VM (ObservableCollection x3, IBrush[] Palette, ObservableCollection device names). All 5 undeclared ControlTemplates carry no {Binding}. Parsing the XAML gives 81 bindings (72 markup + 9 element), matching the body. I pushed nothing and edited nothing in the body.

[tylerkron]

9-way merge build, 2026-09-18 (sweep via #396's shepherd). I merged main 642caef with #387 259a829, #389 808752a, #390 a7c89ec, #391 4370e80, #392 01764b9, #393 f1599e0, #394 4b13ea8, #395 9a0bfa4 and #396 8f4f29e on a throwaway branch. Nothing was pushed.

• Merge: a clean octopus merge with no conflicts. Forward and reverse order give the same tree, 94b85fe. The earlier sweep's 7-way tree 0903bf1 (test(#327): one dialog-DataContext guard — the shared helper follows new+DataContext, DuplicateDeviceDialog's 412-line copy goes (−369) #387–fix(#327): ChannelsPanePrototype's 81 bindings were all on reflection — three declared templates, and a drawer label bound to a member IChannel never declared #394) reproduces exactly.
• Shared file: fix(#327): ChannelsMobileView's 76 bindings were all on reflection — two declared templates, three cast hops, and a drawer label bound to a member IChannel never had #392 and fix(#327): ChannelsPanePrototype's 81 bindings were all on reflection — three declared templates, and a drawer label bound to a member IChannel never declared #394 both add IChannel.ScaleExpressionError. Both produce the byte-identical blob c63a719, so git takes it once and there is no duplicate member. No other file is touched by two PRs. chore(deps): Bump the minor-and-patch group with 17 updates #363 (dependabot) is not included.
• Build: desktop exit 0 (0 errors, 169 warnings, the same as main's CI). iOS restore and iOS Release iossimulator-arm64 --no-restore exit 0. No lock-file drift. Android was not built locally.
• Tests: 1018/1018. That reconciles exactly as 993 (main CI) + 0 (test(#327): one dialog-DataContext guard — the shared helper follows new+DataContext, DuplicateDeviceDialog's 412-line copy goes (−369) #387: 989 on its base 25df7b8, whose own count is 989) + 3 each for fix(#327): LoggedSessionsMobileView's 51 bindings were all on reflection — one declared scope, two inferred, three $parent hops #389, fix(#327): DevicesMobileView's 65 bindings were all on reflection — one declared scope, one inferred, and nothing constructs the view yet #390, fix(#327): ProfilesMobileView's 70 bindings were all on reflection — one declared scope, five inferred, one $parent hop #391, fix(#327): ChannelsMobileView's 76 bindings were all on reflection — two declared templates, three cast hops, and a drawer label bound to a member IChannel never had #392, fix(#327): ProfilesPane's 76 bindings were all on reflection — one declared scope, five inferred, three $parent hops #393, fix(#327): ChannelsPanePrototype's 81 bindings were all on reflection — three declared templates, and a drawer label bound to a member IChannel never declared #394 and fix(#327): DevicesPanePrototype's 83 bindings were all on reflection — one declared scope, one DataType-typed tile template #395 + 4 (fix(#327): LoggedDataPanePrototype's 102 bindings were all on reflection — root scope, two declared template scopes, two existing item scopes #396).
• CI bases: every PR's latest run merged into 642caef except test(#327): one dialog-DataContext guard — the shared helper follows new+DataContext, DuplicateDeviceDialog's 412-line copy goes (−369) #387's, which merged into 25df7b8. This build covers test(#327): one dialog-DataContext guard — the shared helper follows new+DataContext, DuplicateDeviceDialog's 412-line copy goes (−369) #387 on top of fix(#327): LiveGraphPane's 40 bindings were all on reflection — a tracker scope the compiler can't infer, one hop it can't follow #386.
• Qodo threads: 0 unresolved on all nine. The control is fix(logging): a half-finished Delete All left a table-less database, and the next logging toggle killed the app #196: 3 qodo threads, 0 unresolved.

[tylerkron]

/agentic_review

[qodo-code-review]

Code review by qodo was updated up to the latest commit 4b13ea8

[tylerkron]

Sweep (13-way merge build): all 13 PRs are clean together on main 642caef

Covered: #387 259a829, #389 808752a, #390 a7c89ec, #391 4370e80, #392 01764b9, #393 f1599e0, #394 4b13ea8, #395 9a0bfa4, #396 8f4f29e, #398 8e2bb7e, #399 df20ae1, #400 c810ddf, #401 998da59.

Per PR: every head matches its ready note. Every PR is MERGEABLE/CLEAN, and its Build run on that exact SHA passed. No PR has an unresolved qodo review thread. I validated the thread-author filter against #196 first: it finds 3 qodo threads there, as expected. None of the green runs are stale: the last workflow change on main is 94fcac3 (09-08), older than all of them.

• CI base: 12 of the 13 CI runs merged into 642caef. test(#327): one dialog-DataContext guard — the shared helper follows new+DataContext, DuplicateDeviceDialog's 412-line copy goes (−369) #387 is the exception. Its run merged into 25df7b8, one commit behind, because fix(#327): LiveGraphPane's 40 bindings were all on reflection — a tracker scope the compiler can't infer, one hop it can't follow #386 landed on main afterwards. The merge build below covers that gap.

Merge build: I merged 642caef ← 387, 389–396 first, as a checkpoint. It produced tree 94b85fe, the same tree the previous sweep reported, so that result now holds up. Adding #398, #399, #400 and #401 gave tree b0f2033. Merging all 13 in reverse order gives the same b0f2033. Neither order had a text conflict.

• Desktop build: exit 0.
• iOS Release build (iossimulator-arm64, --no-restore): exit 0.
• Tests: 1039/1039 passed. No lock-file drift.

Test count reconciles exactly: 993 on main + #387 0 + #389–#394 +3 each (+18) + #395 +3 + #396 +4 + #398 +13 + #399 0 + #400 +8 + #401 0 = 1039. Each delta comes from that PR's own CI total minus its base's total. For #387 that is 989 − 989 on 25df7b8.

Cross-PR hazards checked:

• Same thing added twice: fix(#327): ChannelsMobileView's 76 bindings were all on reflection — two declared templates, three cast hops, and a drawer label bound to a member IChannel never had #392 and fix(#327): ChannelsPanePrototype's 81 bindings were all on reflection — three declared templates, and a drawer label bound to a member IChannel never declared #394 both add IChannel.ScaleExpressionError. Their hunks are byte-identical (same blob c63a719), so git merges them as one change. This is the only file two PRs share. No new top-level type name appears in more than one PR.
• chore(warning-zero): CS0067 x2 — the two never-raised events get empty accessors, not a delegate field nobody invokes #399 (CS0067, production change): none of the other 12 diffs mentions DeviceRemoved, MessageReceived, NoOpDeviceWatcher or BootloaderSessionStreamingDeviceAdapter. So no open PR raises or subscribes to the events it gives empty accessors.
• test: nine private IAppLogger fakes → one RecordingAppLogger (net −240, test code only) #401 (shared RecordingAppLogger): none of the other 12 PRs edits any of its 9 files, and none adds a type called RecordingAppLogger. test(coverage-gap): pin DiskSpaceMonitorCoordinator — the class that decides whether a full disk stops your session (13 cases, 12/12 mutants killed) #398 adds its own private sealed class RecordingLogger : IAppLogger, nested inside the test class. That cannot clash, and the build confirms it. It is simply one more private fake that a later clean-up could fold into RecordingAppLogger. It does not block either PR.
• Repo-wide scanning guard: test(#327): one dialog-DataContext guard — the shared helper follows new+DataContext, DuplicateDeviceDialog's 412-line copy goes (−369) #387's BindingFacts guard scans Daqifi.Avalonia/**/*.cs. chore(warning-zero): CS0067 x2 — the two never-raised events get empty accessors, not a delegate field nobody invokes #399 is the only PR here that changes production .cs, and fix(#327): LiveGraphPane's 40 bindings were all on reflection — a tracker scope the compiler can't infer, one hop it can't follow #386 is the commit that landed after test(#327): one dialog-DataContext guard — the shared helper follows new+DataContext, DuplicateDeviceDialog's 412-line copy goes (−369) #387's CI. The guard passes in the merged test run under both merge orders.
• Removed members: chore(warning-zero): CS0067 x2 — the two never-raised events get empty accessors, not a delegate field nobody invokes #399 replaces 2 event fields with accessor events (same public signature). test: nine private IAppLogger fakes → one RecordingAppLogger (net −240, test code only) #401 removes only private nested fakes. test(#327): one dialog-DataContext guard — the shared helper follows new+DataContext, DuplicateDeviceDialog's 412-line copy goes (−369) #387 removes 1 test method. The 13-way build compiles with all of them.

No merge was performed and nothing was pushed to any PR branch.