# AyCode.Blazor — Domain Rules

# own-dep-repos: "name: path" — paths are relative to this repo root (.github/..)
@repo {
  name = "AyCode.Blazor"
  type = "framework"
  layer = 1
  own-dep-repos = ["AyCode.Core: ../AyCode.Core"]
}

> This is the **single source of truth** for Blazor/MAUI UI domain rules. Do not duplicate these elsewhere.
> For core framework rules see: `../AyCode.Core/.github/copilot-instructions.md`
> For detailed docs see: `README.md` → `docs/`
> External repos in `own-dep-repos` are fully accessible — read their source code, docs, and `.github/copilot-instructions.md` freely when you need type definitions, base classes, or context. Do not limit yourself to the current workspace.

## DevExpress Components
1. **DevExpress Blazor 25.1.3** — always use `DxGrid`, `DxFormLayout`, etc. Do NOT mix with generic Blazor component libraries.
2. **Grid system** uses `AcSignalRDataSource` for real-time data — grids fetch data via SignalR, not REST.
3. **CardView components** wrap DevExpress grids with card-style layout for mobile-friendly display.

## Architecture
4. **Blazor.Components** is the main UI library — both Blazor Server and MAUI Hybrid consume it.
5. **Blazor.Models** = shared view models (client + server). **Blazor.Models.Server** = server-only scaffolding.
6. **MAUI.Core** targets Android (API 33+), iOS (15.0+), Windows (10.0.19041+) via platform folders.
7. **Controllers** project is scaffolding — do not add business logic here.

## Serialization in UI
8. SignalR uses **AcBinaryHubProtocol** (custom binary) — not the default JSON protocol.
9. Grid filters use **AcExpressionNode** serialization — LINQ expressions are serialized and sent to server.

## Conventions
10. Do not suggest removal/rollback as a solution — find a fix for the problem.
11. All DLL references to AyCode.Core projects are via `DllReference` (not ProjectReference) — this is intentional, required for build isolation and nopCommerce plugin compatibility in consuming projects.
12. **No redundant code** — before writing new logic, check whether similar methods already exist in the current context. Reuse or extract shared logic into smaller methods rather than duplicating.
13. **Keep all .md files in sync** — when you modify code and you know which .md file documents it, update that .md file too. If you notice a contradiction between code and an .md file, automatically update the .md to match the code (code is the source of truth). When fixing a reference, check other .md files that may share the same broken reference. If the root cause is at a lower layer, fix it there first. During code review, if you find useful behavior or conventions not yet documented, briefly suggest what to document and where — but do not add new content without approval.
14. **Documentation layering** — write `.md` documentation at the **defining layer** (where the code lives). Higher-layer `.md` files reference the base docs (e.g. `see AyCode.Core/docs/SIGNALR.md`) and document only project-specific overrides or extensions. Never duplicate base-layer descriptions in consumer-level docs.
15. **Do not re-read .md files** already in your context window. They only change if you modify them yourself (new content is already in context) or if the developer tells you they changed — in that case re-read them once.

## Related Solutions
15. **AyCode.Core** solution (`../AyCode.Core/AyCode.Core.sln`) contains all core framework code (SignalR, serialization, data sources, base classes, interfaces). Types referenced in this Blazor solution but not defined here (e.g. `AcSignalRDataSource`, `AcBinaryHubProtocol`, `IId<TId>`, `AcObservableCollection`, `AcLoggerBase`) likely live in AyCode.Core.
16. For AyCode.Core domain rules see: `../AyCode.Core/.github/copilot-instructions.md`