[tylerkron]

Part of #327. Part of #336 — not Closes: one of the two sites #336 names is still
unfixed, for the reason given under “Second change” below.

MainWindow.axaml is the desktop shell — the toolbar, the notification badge, the tab strip, the
busy overlay, the three flyouts and the settings drawer. Every one of its 32 bindings resolved by
reflection at run time, because the window declared neither x:DataType nor x:CompileBindings. A
renamed, moved or deleted view-model member left the markup naming something that no longer existed,
and nothing in either head's build could see it.

What that bought us, concretely. A failed binding does not blank the control — it leaves the
target property at its default, and IsVisible defaults to true. Eight of the 32 bindings
here feed IsVisible, and five of those gate a whole surface: the settings drawer, the busy overlay
and the three flyouts. A typo in any of the five did not hide that surface, it pinned it
permanently open over the running app — and desktop, iOS and every test stayed green. The other
three would have shown the notification badge with no count, the debug console button to every user,
and the config-recovery banner on every launch.

Two attributes on the root make all 32 the compiler's business. No behaviour change, no pixels moved.
Diff is +365 / -10 across 4 files: 44 lines of markup (2 attributes + 1 xmlns + a comment), 261
lines of new tests, and 60 lines of corrected documentation.

The measurement

Ten deliberate typos, one at a time, each built on origin/main and on this branch:

#	shape	on origin/main	on this branch
1	the Window's own Height	0 Error(s), no diagnostic	AVLN2000 on DaqifiViewModel
2	toolbar ToggleButton.IsChecked	0 Error(s), no diagnostic	AVLN2000 on DaqifiViewModel
3	notification badge, through a StaticResource converter	0 Error(s), no diagnostic	AVLN2000 on DaqifiViewModel
4	<Binding Path=/> child of the SplitView MultiBinding	0 Error(s), no diagnostic	AVLN2000 on DaqifiViewModel
5	second segment of AppSettings.HasRecoveryNotice	0 Error(s), no diagnostic	AVLN2000 on DaqifiViewModel
6	first segment of AppSettings.IsCommaDelimiter	0 Error(s), no diagnostic	AVLN2000 on DaqifiViewModel
7	settings scrim Command	0 Error(s), no diagnostic	AVLN2000 on DaqifiViewModel
8	tab strip SelectedIndex	0 Error(s), no diagnostic	AVLN2000 on DaqifiViewModel
9	flyout IsVisible	0 Error(s), no diagnostic	AVLN2000 on DaqifiViewModel
10	busy overlay, with a FallbackValue	0 Error(s), no diagnostic	AVLN2000 on DaqifiViewModel

Positive control on the main side, because ten silences are otherwise indistinguishable from a
skipped or stale compile: a bogus CLR property (MinWidthZZZ) in the same tag is
AVLN2000: Unable to resolve suitable regular or attached property MinWidthZZZ on type … MainWindow.
The file was being compiled on every one of those ten runs; it simply had nothing to say about the
bindings. Every source write in the harness is followed by a touch, so no result is a stale
assembly.

There is one binding scope in this view (the root), and the control reached it from ten different
binding shapes, including the two the earlier PRs had not exercised: a MultiBinding child element,
which x:CompileBindings does cover, and a binding routed through a converter.

No dead bindings. All 32 resolve against DaqifiViewModel — nothing here was already broken.

Escape hatches: zero

x:CompileBindings="False": 0. {ReflectionBinding}: 0. Counted by parsing, and now pinned
by a test, so this view cannot come to read as protected while half of it has opted out. (The nine
{TemplateBinding}s in the ControlThemes are a different mechanism and are unaffected either way.)

The five DataTemplates deliberately declare nothing

This is the shape #327's corrected rule says infers nothing, and it is the reason I picked this view.
Measured here on Avalonia 12.1:

• a binding inside a ContentControl.ContentTemplate with a correct member name is
  AVLN2000 … on type 'XamlX.TypeSystem.XamlPseudoType' — unscoped, not mistyped;
• that holds even though Content="{Binding}" gives the compiler the DataContext type
  statically, and it holds with Content="{Binding AppSettings}" too. The inference does not follow
  the Content binding at all. This is a stronger result than fix(#327): DeviceLogsView's 35 bindings were all on reflection — two attributes, six scopes, five of them inferred #335's, which only had the
  Content-typed-object case;
• with an explicit x:DataType="vm:DaqifiViewModel" the template compiles, and a typo in it is
  AVLN2000 on DaqifiViewModel. The declaration is genuinely load-bearing for this shape.

All five templates hold a bare pane element and bind nothing, so they compile today and a
declaration would be pure decoration — while a stale one would be worse than none, since an
explicit x:DataType overrides and keeps compiling after the Content beside it is repointed. They
are left undeclared, and the view comments say what to add if anyone binds in one.

I also re-derived the inference half independently, on MobileShellView (a different view and a
different shape) rather than taking #335's report on trust — deleting both template x:DataTypes
there: correct members still build clean; {Binding IsSelectedZZZ} is AVLN2000 on ChannelToggle,
the same type the deleted attribute named; and {Binding ShowDeviceList} — a view-model member — is
also AVLN2000 on ChannelToggle. It never falls back to the ancestor scope. That is the
measurement behind the #336 fix below.

Tests: 5 guards, each proven to fail on its own mutation

New class MainWindowBindingTests (+261 lines), named for this view so it cannot collide with #335's
DeviceLogsViewBindingTests. Member names are not asserted — the compiler owns all 32 at once.
Each guard was mutated and re-run, and each mutation still builds, so none of them is duplicating
the compiler:

guard	mutation	result
root declarations	delete x:CompileBindings from the tag, leave the literal in the comment	fails ✔ (builds green)
declared scope vs real DataContext	code-behind stops assigning DaqifiViewModel verbatim	fails ✔ (builds green)
pane opens for exactly its flyouts	drop one flyout from the MultiBinding	fails ✔ (builds green)
pane opens for exactly its flyouts	move a flyout out of SplitView.Pane, binding untouched	fails ✔ (builds green)
Content="{Binding}" on the five tab hosts	delete it from one host	fails ✔ (builds green)
no escape hatch	switch one binding to {ReflectionBinding}	fails ✔ (builds green)

Two of those are worth a word:

• Content="{Binding}" reads like a no-op and is not. It is the only thing putting
  DaqifiViewModel into each pane's DataContext. LiveGraphPane and LoggedDataPanePrototype have
  no view model of their own, so deleting it renders those two tabs blank — while the other three,
  which replace their own DataContext on attach, keep working, which is exactly what makes the
  deletion look safe when someone tries it.
• The three flyouts share one SplitView pane, opened by a MultiBinding OR-ing the same three
  booleans their IsVisibles use. Drop one and that flyout is unreachable (visible inside a pane that
  never opens); add one and the pane slides out empty. Both compile. Compared as a set, since the OR
  is commutative.

I removed a sixth guard I had written first ("every template that binds declares a scope"): for
this shape the build already fails, so it could never fail on its own, and it would have fired
wrongly on a ListBox.ItemTemplate added later, which correctly needs no declaration. Its content
is now a comment where it belongs.

Qodo round 2 found a real hole in the flyout guard: it collected flyouts window-wide, so moving
one out of SplitView.Pane left both compared sets identical and the test passed while the pane
still ORed a boolean for a flyout it no longer displayed. Fixed in b1677bc — the flyout side is now
read out of the pane subtree and a stray flyout fails first. I re-ran the whole mutation matrix
after that change rather than only the new case, since narrowing an assertion for a reviewer is
exactly when something else quietly stops failing; all five earlier mutations still fail. The same
fix also made the path extraction tolerate {Binding X, Mode=OneWay}, which it had been rejecting.

Second change: #336, the "inherited scope" wording

BindingFacts.AssertTemplateScopedTo's failure message and doc comment said an undeclared
DataTemplate's bindings "resolve against an inherited scope rather than the item". Measured, that
never happens — they resolve against an inferred scope, or against nothing at all (XamlPseudoType,
a build error). Corrected in the message and the doc, with the ordered rule, the shapes that infer,
and the reason not to add declarations by reflex.

#336 names DeviceLogsViewBindingTests as the second site. When this PR was written that file was
not on main yet, so it was left to #335 — that is no longer true. #335 merged as d6e37e1, and
the merge of main into this branch (5a88aa2) brought the file here, so the wrong wording is live on
main today in DeviceLogsViewBindingTests.Every_data_template_sits_inside_the_list_whose_items_it_renders
(both the doc comment and the assertion message). It is deliberately not patched here: that would be
a comment-only commit onto a settled, Qodo-clean, CI-green head, and it is not this view's file.
#336 therefore stays open; the remaining sites are enumerated in a comment on it.

The same wrong wording is on main twice more in MobileShellViewBindingTests, so it is fixed
there too, cited to my own measurement above. Docs and assertion-message text only — no guard
behaviour changes. #335 did not touch BindingFacts.cs, so the merge of main brought no collision
there.

Verification

• dotnet build desktop: 0 errors. dotnet build iOS Release/iossimulator-arm64 after a
  no-RID restore: 0 errors. dotnet test: 872 passed, 0 failed (7 of them new) on the current
  head 5a88aa2, which is CI's own figure. The 834 first written here was the count at b1677bc,
  before main was merged in; main at 664d01c runs 865, so the +7 is unchanged. Re-run in
  full after the round-2 fix, not just the changed test.
• Warnings: 175 → 175, no change — measured with --no-incremental on both sides, because an
  incremental build here reports 155 and "155 vs 155" would read exactly like a clean result. Both
  absolute totals are non-zero. By unique warning line the denominators are first-party 114 → 114
  and all-project union (incl. vendored third_party/oxyplot-avalonia) 122 → 122.
• No lock file touched — git status --short -- '**/packages.lock.json' is empty; the iOS restore
  was run without -r.
• The Android head cannot be built on this Mac; CI covers it. Not claimed as verified here.
• No screenshot attached: this changes no rendered pixel, and CI settles that rather than leaving it
  asserted. The macOS desktop job on this head runs the capture harness five times, captures all 39
  screens byte-identically across the five runs, and matches every one against the committed
  tools/parity-audit/baselines/macos-arm64.sha256 — 39/39, with the denominator equal to that
  manifest's own line count. Nine of those 39 are this window (desktop-1..9, including the settings
  drawer and each of the three flyouts open) and nine more are the same window at minimum size. A
  capture delta here would itself be the finding; there is none.

What remains on #327

20 first-party views after this one. #327's table counts MainWindow.axaml at 29; the real figure
is 32, because the table counts {Binding occurrences and the three <Binding Path=/> children of
the MultiBinding have no such text — so the table undercounts every view that uses a MultiBinding.
By the table's own accounting, 770 bindings are left.

The four View/Prototype/* files (~295 bindings) are still the open question: whether they are
reachable at all, which is a bigger question than whether they are checked. Note that
LoggedDataPanePrototype and LiveGraphPane are not dead — they are two of the five tabs this
window hosts, and this PR pins the binding that feeds them.

🤖 Generated with Claude Code

[tylerkron]

Review focus, since this PR is net-additive by design (44 lines of markup comment + 2 attributes, 220 lines of new tests, 60 lines of corrected doc text — no code removed):

1. Is the negative control actually load-bearing? Ten typos one at a time, each silent on main and AVLN2000 on this branch, plus a positive control proving the file was compiled. If any of the ten is reachable some other way, or the positive control does not do what I claim, that is the finding.
2. Are the five guards vacuous? I mutated each and checked the mutation still builds — a guard whose mutation breaks the build is the compiler's job. I deleted a sixth guard for exactly that reason. Please check I did not miss one, particularly The_pane_opens_for_exactly_the_flyouts_it_holds, which compares sets by string-munging {Binding X}.
3. The five undeclared DataTemplates. I argue a declaration there would be decoration today and a hazard later (explicit x:DataType overrides). If you think the five should be declared anyway, say so — it is the one judgement call in the diff.
4. Counts. Every number in the body is derived (32 bindings, 8 IsVisible, 0 escape hatches, 175→175 warnings on forced full rebuilds of both sides). Please check them against the diff rather than taking them from the prose.

[tylerkron]

/agentic_review

[qodo-code-review]

PR Summary by Qodo

Compile-check MainWindow bindings and guard shell wiring

🐞 Bug fix 🧪 Tests 📝 Documentation 🕐 20-40 Minutes

AI Description

• Compile-check all 32 MainWindow bindings against DaqifiViewModel.
• Guard flyout visibility, pane opening, tab context propagation, and reflection escape hatches.
• Correct documentation about Avalonia DataTemplate scope inference.

Diagram

graph TD
  CB["MainWindow Code Behind"] -->|assigns| VM["DaqifiViewModel"] -->|typed scope| XAML["MainWindow XAML"] -->|compiles paths| COMP["XAML Compiler"] -->|reports AVLN2000| BUILD["Application Build"]
  TESTS["Binding Tests"] -->|parses structure| XAML
  TESTS -->|verifies assignment| CB

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Enable compiled bindings project-wide

• ➕ Protects every Avalonia view without per-view opt-in
• ➕ Prevents future views from silently using reflection bindings
• ➖ Creates a much broader migration and review scope
• ➖ May expose failures in views lacking valid binding scopes
• ➖ Reduces the ability to roll out and verify compiled bindings incrementally

Recommendation: Keep the PR's view-scoped rollout. It removes the immediate MainWindow risk with explicit regression coverage while avoiding unrelated binding failures; project-wide compiled bindings can follow as a separately measured migration.

Files changed (4) +324 / -10

Bug fix (1) +44 / -0

MainWindow.axamlEnable compiled bindings for the desktop shell +44/-0

Enable compiled bindings for the desktop shell

• Declares DaqifiViewModel as MainWindow's binding scope and enables compiled bindings, making all 32 paths build-time checked. Documents visibility failure risks, ContentControl template behavior, and the load-bearing tab Content bindings.

Daqifi.Avalonia/Daqifi.Desktop/MainWindow.axaml

Tests (1) +220 / -0

MainWindowBindingTests.csAdd structural regression tests for MainWindow bindings +220/-0

Add structural regression tests for MainWindow bindings

• Adds tests that preserve the compiled-binding declarations, verify the declared type matches the assigned DataContext, and reject reflection-binding escape hatches. It also guards flyout-to-pane visibility pairing and the five tab hosts' DataContext propagation.

Daqifi.Avalonia.Tests/Views/MainWindowBindingTests.cs

Documentation (2) +60 / -10

BindingFacts.csCorrect DataTemplate scope-inference guidance +36/-4

Correct DataTemplate scope-inference guidance

• Clarifies that undeclared templates use an inferred item scope where supported or XamlPseudoType otherwise, never an inherited ancestor scope. Assertion diagnostics now communicate the same behavior.

Daqifi.Avalonia.Tests/BindingFacts.cs

MobileShellViewBindingTests.csCorrect MobileShell template-scope documentation +24/-6

Correct MobileShell template-scope documentation

• Replaces the inherited-scope explanation with measured Avalonia 12.1 item-type inference behavior. Test comments and failure messages now accurately describe inferred and absent template scopes.

Daqifi.Avalonia.Tests/Views/MobileShellViewBindingTests.cs

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. A moved flyout escapes its guard ✓ Resolved 🐞 Bug ⚙ Maintainability

Description

The_pane_opens_for_exactly_the_flyouts_it_holds gathers every window descendant whose name ends in
Flyout instead of limiting the query to SplitView.Pane. Moving one of the three controls outside
the pane leaves both compared binding sets unchanged, so the new regression test passes even though
that control is no longer displayed by the pane it allegedly belongs to.

Code

Daqifi.Avalonia.Tests/Views/MainWindowBindingTests.cs[R152-153]

+        var flyouts = root.Descendants()
+            .Where(element => element.Name.LocalName.EndsWith("Flyout", StringComparison.Ordinal))

Relevance

●●● Strong

The test’s stated invariant requires pane-scoped discovery; accepted precedent favors structurally
scoped XML assertions.

PR-#325
PR-#322

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The test starts flyout discovery at the document root, while the actual host boundary is the
SplitView.Pane element containing only the three pane controls. Consequently, control location is
absent from the relationship being asserted.

Daqifi.Avalonia.Tests/Views/MainWindowBindingTests.cs[145-159]
Daqifi.Avalonia/Daqifi.Desktop/MainWindow.axaml[333-352]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The pane/flyout regression test searches the entire window for flyout controls, so it can pass after a flyout is moved outside the `SplitView.Pane` it is meant to validate.

## Issue Context
The production markup places all three flyouts under `SplitView.Pane`. The test should derive its flyout binding set from that pane subtree rather than from every descendant of the window.

## Fix Focus Areas
- Daqifi.Avalonia.Tests/Views/MainWindowBindingTests.cs[145-159]
- Daqifi.Avalonia/Daqifi.Desktop/MainWindow.axaml[333-352]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

✅ Cross-repo context — repo relationships

Review mode: 🚀 Fast: This is a localized test-only refinement of one binding-structure assertion, with limited blast radius and no security, API, schema, or runtime behavior changes.

Tip of the day

💡 Did you know, you can enable the Remediation agent and Qodo fixes findings in a dedicated fix PR

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

[tylerkron]

/agentic_review

[qodo-code-review]

Code review by qodo was updated up to the latest commit ca49135

[tylerkron]

/agentic_review

[qodo-code-review]

Code review by qodo was updated up to the latest commit b1677bc

[tylerkron]

/agentic_review

[qodo-code-review]

Code review by qodo was updated up to the latest commit b1677bc

[tylerkron]

Shepherd pass on 5a88aa2 — one real finding (fixed in the body, not in a commit), everything else re-derived and holds

Nothing pushed, so the head is still 5a88aa2a1f395532c9cf253456ec326ce08444bb and the CI green below
is the run on that exact SHA. Body edits only, which move no commit.

The finding: Closes #336 would have closed #336 with one of its two named sites still wrong

The body said DeviceLogsViewBindingTests "arrives with #335 and is not on main, so it is left to
that PR." True when written; false now. #335 merged as d6e37e1 at 00:32 on 09-09, and the merge
of main into this branch (5a88aa2, 14:23) brought the file here. The wrong "inherited scope"
wording is live on main in
DeviceLogsViewBindingTests.Every_data_template_sits_inside_the_list_whose_items_it_renders, in both
the doc comment (:135) and the assertion message (:148) — precisely the method #336's body quotes.
There is a third occurrence in ConnectionDialogDiscoveryBindingTests.cs:67 that #336 does not name.

Deliberately not patched on this branch: it is a comment-only change to another view's test file,
and pushing it would move the head off a settled review and a green CI run for no behaviour change.
Instead Closes #336 is now Part of #336, and #336 carries a comment enumerating the three
remaining occurrences — #336 (comment).

Other body corrections (also free — no SHA move)

• dotnet test: 834 → 872. 834 was the count at b1677bc, before main was merged in. CI on
  5a88aa2 reports Passed: 872; CI on main 664d01c reports 865. The +7 the body claims is
  exactly right, and 7 is also what the new file adds by parse (2 theory cases + 3 facts + 2 theory
  cases).
• The visual disclosure, closed by looking rather than repeated. Added what CI actually did: the
  macOS desktop job on this head ran the capture harness 5×, got 39/39 screens byte-identical
  across runs, and matched every one against the committed
  tools/parity-audit/baselines/macos-arm64.sha256. The denominator equals that manifest's own line
  count (39), so this is not an N/N over a short list. Nine of the 39 screens are this window
  (desktop-1..9 — including desktop-6-settings-drawer, desktop-7-notifications-flyout,
  desktop-8-livegraph-settings-flyout, desktop-9-summary-flyout) and nine more are the same window
  at minimum size. So "no pixel moved" and "all five gated surfaces still render" are both measured,
  not asserted. No PNG attached: a picture of unchanged UI is not evidence.

Re-derived independently, on this checkout — the numbers hold

claim	re-derived	how
32 bindings	✅ 29 attribute-syntax + 3 <Binding Path=/> children of the MultiBinding	XML parse, not a {Binding grep (the grep says 31 — 29 real plus 2 inside the comment)
8 feed IsVisible, 5 gate a surface	✅	parse: the three flyouts, the busy overlay, the settings drawer; the other three are the debug button, the badge and the recovery banner
escape hatches: 0	✅ x:CompileBindings="False" 0, {ReflectionBinding} 0, exactly one x:DataType (the root)	parse + raw-text scan; the 9 {TemplateBinding}s are in the ControlThemes and are a different mechanism
+365 / -10 across 4 files; 44 markup / 261 test / 60 doc	✅	git diff --numstat origin/main...HEAD: 44/0, 261/0, 36/4, 24/6
warnings 175 → 175	✅	CI's own cold, all-project totals at both ends: b9bbe2b (this PR's merge base) 175, 5a88aa2 175, main 664d01c 175. My local incremental build reported 155, exactly the trap the body flags
20 views / 770 bindings left on #327	✅ self-consistent	799 − 29 by the table's own accounting, as labelled

The positive control, re-derived rather than trusted

Not the whole ten-typo matrix — but one typo in the shape earlier PRs had not exercised, plus both
halves of the control, one change at a time, ~/.dotnet/dotnet build of the desktop head each time:

state	change	result
this branch	<Binding Path="IsLogSummaryOpenZZZ"/> — a MultiBinding child element	AVLN2000: Unable to resolve property or method of name 'IsLogSummaryOpenZZZ' on type 'Daqifi.Desktop.ViewModels.DaqifiViewModel'
root declarations deleted (= main's state for this file)	same typo	0 Error(s), no diagnostic naming the file
root declarations deleted	MinWidthZZZ="720" on the Window tag	AVLN2000: Unable to resolve suitable regular or attached property MinWidthZZZ on type Daqifi.Avalonia:Daqifi.Desktop.MainWindow

The third row is the one that matters: it proves the silence in row 2 was a real compile of this file,
not a skipped or stale one. So the MultiBinding child — the shape {Binding greps cannot see and
that #327's table undercounts — really is covered, and really was not.

And the rejected alternative, tested rather than repeated

The body's design rests on a negative claim ("a ContentControl.ContentTemplate infers nothing, even
with Content="{Binding}" beside it"), which is also why the sixth guard was removed. So I put a
correct member name inside one of the five templates:

<prototype:LiveGraphPane IsVisible="{Binding IsBusy}"/>

→ AVLN2000: Unable to resolve property or method of name 'IsBusy' on type 'XamlX.TypeSystem.XamlPseudoType'

Confirmed on a different view and a different shape from the ones #335 and #327's comment measured.
The five undeclared templates therefore cannot hide a broken binding — any binding added to one is a
hard build error — and the removed "every template that binds declares a scope" guard genuinely could
never have failed. Leaving them undeclared is right, and #327's corrected rule (an explicit
x:DataType overrides, so a plausible-but-wrong one is worse than none) is not contradicted
anywhere in this diff. The working tree was restored and git status is clean; nothing above was
committed.

CI

gh pr checks 338: all 7 green on 5a88aa2 (run 34363288184, head_sha = the current head). The
run was created 2026-09-09T14:23:30Z and main has since taken #355 and #360 — but those touch
App.axaml.cs, Services/MacApplicationMenu.cs and docs only, and this PR touches four entirely
different files, so the sets are disjoint and the PR still reads MERGEABLE. Verification here is
CI's on 5a88aa2, read out of the job logs, not a local re-run of the gate: no code changed, so
re-deriving it locally would buy nothing and take a build lock off a builder who needs it.

Firing my own Qodo round next — the three on record are the builder's, and Qodo is not deterministic
across rounds on the same commit.

[tylerkron]

/agentic_review

[tylerkron]

/agentic_review

[qodo-code-review]

No code changes since the last review — review skipped

[tylerkron]

Qodo-clean, CI green on 5a88aa2a1f395532c9cf253456ec326ce08444bb — ready for review

The rounds I fired, and what Qodo did with them

I fired two /agentic_review rounds of my own on the current head (the three on record were the
builder's, and Qodo is not deterministic across rounds on the same commit). Qodo declined both,
each within ~10 s, with the same body:

No code changes since the last review — review skipped

So this is an honest disclosure rather than a "two clean graded rounds" claim: on this head Qodo will
not re-run, and a second graded round is mechanically unreachable without manufacturing a commit —
which I am not going to do to provoke one. Both surfaces re-checked after a 3-minute settle, and both
are empty:

• summary comment: 🐞 Bugs (0), 📘 Rule violations (0), 🔗 Cross-repo conflicts (0), anchored to
  5a88aa2 (updated_at 2026-09-09T14:23:37Z, the merge commit's own re-render);
• reviewThreads via GraphQL: 1 qodo thread total, 0 unresolved. (Query validated against the
  control PR fix(logging): a half-finished Delete All left a table-less database, and the next logging toggle killed the app #196, which returns 3 when isResolved is ignored, so it is not silently matching
  nothing on the qodo-code-review vs qodo-code-review[bot] login split.)

The grade on this head is 🚀 Fast, and its stated rationale describes the b1677bc delta ("a
localized test-only refinement of one binding-structure assertion"). Since Qodo grades only the last
push's delta, a deeper grade is unreachable here — so I hand-reviewed that delta instead of re-running
for a grade that cannot improve.

Hand-review of the last delta (ca49135..b1677bc) — no blocking finding

• Except(inPane) relies on XElement's default reference equality, and both sequences are drawn
  from the same parsed document, so the stray set is computed correctly rather than by value.
• Assert.DoesNotContain(paneOpen, path => path.Length == 0) is what stops the ?? string.Empty from
  turning a <Binding> with no Path= into a silent empty member name that could match nothing and
  still compare equal — worth noting because that ?? is what the round-2 diff introduced.
• BoundVisibilityPath's regex genuinely fixes what the old .Replace("{Binding ", "").TrimEnd('}')
  broke: {Binding X, Mode=OneWay} used to extract X, Mode=OneWay and fail the set comparison for
  the wrong reason.
• Two accepted limits, both deliberate and both loud rather than silent: Assert.Equal(3, inPane.Count)
  fails on a legitimately-added fourth flyout (forces a reviewer), and the regex tolerates a converter
  in a flyout's IsVisible while comparing only the member name — a polarity-inverting converter would
  not be caught. There are none today. Neither is worth a commit onto a settled head.

And the merge commit, checked for silent loss

git diff b1677bc 5a88aa2 -- <the PR's four files> is empty: the merge of main brought only
main's changes and altered nothing of this PR's own. It did bring 25 changed lines of
DaqifiViewModel.cs — and since the head compiles green, all 32 bindings still resolve against the
post-merge view model, which is the first time this PR's own guarantee has actually been exercised by
an unrelated change.

CI

All 7 checks pass on run 34363288184, whose head_sha is the current head. main has since
taken #355 and #360, which touch App.axaml.cs, Services/MacApplicationMenu.cs and docs — disjoint
from this PR's four files, and the PR still reads MERGEABLE. Verification here is CI's on
5a88aa2, read out of the job logs (warnings, test counts and the baseline comparison all quoted
from them), not a local re-run of the gate: nothing was pushed, so a local gate would buy no new
information and would take a build lock off a builder who needs it. The only local builds I ran were
the four control experiments in the note above; the working tree was restored and git status is
clean.

One correction landed in the body rather than in a commit: Closes #336 → Part of #336, because
#335 has merged and the second site #336 names is now live on main. Details in the note above and in
#336.