AyCode.Blazor/.github/copilot-instructions.md

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