From da11df53848b21627581f15e7afebc0fc1247574 Mon Sep 17 00:00:00 2001 From: Loretta Date: Mon, 30 Mar 2026 10:15:46 +0200 Subject: [PATCH] Clarify and expand copilot-instructions conventions - Clarified DllReference usage for AyCode.Core projects, noting its necessity for build isolation and nopCommerce plugin compatibility. - Reworded redundancy guideline to stress checking for and reusing existing methods before adding new logic. - Expanded .md file sync rule: update relevant docs when code changes, resolve contradictions in favor of code, and address shared broken references; during review, suggest (not add) new documentation for useful behaviors. - Rephrased AyCode.Core solution description for clarity regarding type locations. --- .github/copilot-instructions.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index a8d60ae..3120a55 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -27,11 +27,11 @@ ## 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. -12. **No redundant code** — before writing new logic, search for existing methods. Reuse or extract shared logic into smaller methods rather than duplicating. -13. **Keep all .md files in sync** — when you modify code, update any affected .md file in the same area. If you already read an .md file during your work and notice it contradicts the current code, fix the discrepancy — but do NOT proactively scan or open .md files just to check for issues. +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. ## Related Solutions -15. **AyCode.Core** solution (`../AyCode.Core/AyCode.Core.sln`) contains all core framework code (SignalR, serialization, data sources, base classes, interfaces). When a type is referenced in this Blazor solution but not defined here (e.g. `AcSignalRDataSource`, `AcBinaryHubProtocol`, `IId`, `AcObservableCollection`, `AcLoggerBase`), look it up in AyCode.Core source. +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`, `AcObservableCollection`, `AcLoggerBase`) likely live in AyCode.Core. 16. For AyCode.Core domain rules see: `../AyCode.Core/.github/copilot-instructions.md`