refactor(rules): split wpf.md into index + references

Co-Authored-By: Claude Haiku 4.5 <noreply@anthropic.com>

shared/rules/wpf/references/mvvm-and-binding.md

@@ -0,0 +1,60 @@
+## MVVM
+
+* Keep ViewModels focused on presentation state and commands.
+* Do not put UI element references into ViewModels.
+* Do not access `Window`, `UserControl`, `DispatcherObject` or visual tree elements from ViewModels.
+* Avoid direct navigation, dialogs or message boxes from ViewModels without an abstraction when testability matters.
+* Prefer explicit application services for navigation, dialogs and external interactions.
+* Keep domain logic outside ViewModels.
+* Do not use ViewModels as general-purpose service containers.
+* Keep ViewModel dependencies minimal.
+* Prefer immutable or readonly state where practical.
+* Avoid duplicated derived state.
+* Keep state transitions predictable.
+
+## Data Binding
+
+* Prefer data binding over manual UI synchronization.
+* Use strongly typed properties.
+* Use appropriate binding modes.
+* Prefer `OneWay` when two-way updates are not required.
+* Use `TwoWay` only when the UI must modify the source.
+* Avoid unnecessary `UpdateSourceTrigger=PropertyChanged` for expensive operations.
+* Keep binding paths simple and stable.
+* Avoid deeply nested binding paths.
+* Do not hide broken bindings.
+* Treat binding errors as real defects.
+* Use `FallbackValue` and `TargetNullValue` only when they reflect intended behavior.
+* Avoid excessive converters.
+* Prefer exposing correctly shaped state from the ViewModel over complex converter logic.
+* Avoid `MultiBinding` when simpler state modeling is clearer.
+* Do not put business logic into converters.
+
+## Property Change Notifications
+
+* Implement property change notifications consistently.
+* Avoid raising `PropertyChanged` unnecessarily.
+* Raise notifications only when values actually change.
+* Keep dependent property notifications explicit.
+* Avoid hidden notification chains that are difficult to reason about.
+* Prefer reusable base implementations only when they reduce duplication without obscuring behavior.
+* Do not use reflection-based notification mechanisms unless there is a concrete benefit.
+
+## Dependency Properties
+
+* Use dependency properties only when WPF property-system behavior is required.
+* Do not use dependency properties as a replacement for normal CLR properties.
+* Keep metadata and callbacks lightweight.
+* Avoid expensive work in property-changed callbacks.
+* Avoid callbacks with hidden side effects.
+* Validate or coerce values only when the control contract requires it.
+* Do not expose mutable default values in dependency property metadata.
+
+## Attached Properties and Behaviors
+
+* Use attached properties and behaviors for reusable view-specific behavior.
+* Do not use them to hide business logic.
+* Keep behaviors focused and predictable.
+* Clean up event handlers when behaviors are detached.
+* Avoid global attached-property state.
+* Prefer explicit behavior over complex XAML hacks.