Add Mango.Nop.Core docs: architecture, conventions, rules

Added Mango.Nop.Core section to copilot-instructions.md detailing workspace dependencies, framework-first design, and separation from plugin logic. Introduced ARCHITECTURE.md to define framework vs. consumer boundaries, entity mirroring, and DTO parameterization. Added CONVENTIONS.md to formalize placement rules, naming conventions, and anti-patterns, referencing AyCode.Core for shared doctrine.

Mango.Nop.Core/.github/copilot-instructions.md

@@ -0,0 +1,54 @@
+# Mango.Nop.Core — Domain Rules
+
+## Workspace Dependencies
+
+@repo {
+  name = "Mango.Nop.Core"
+  type = "framework"
+  layer = 2
+  own-dep-repos = ["AyCode.Core: ../../../../../../../Aycode/Source/AyCode.Core"]
+}
+
+> Domain framework for NopCommerce plugins. Built on Layer 0 (AyCode.Core), consumed by Layer 3 (specific plugin apps, plural and unknown).
+
+> **AI Agent Protocol:** This repo follows the AI Agent Core Protocol defined in AyCode.Core. Same rules apply: `[LOADED_DOCS]` prefix, docs-before-code, no-re-read policy, context recovery on compaction, explicit consent for modifications. Full protocol: AyCode.Core's `.github/copilot-instructions.md` (see @repo path above).
+
+## Framework-First Design Principle
+
+🛑 **This repo is framework (Layer 2 — Domain framework), not a consumer application.** Provides base types for NopCommerce plugin development. Consumers = specific plugin projects (plural, unknown).
+
+**Before writing code, ask:**
+1. Generic (reusable across any NopCommerce plugin)? → belongs HERE
+2. Plugin-specific (business logic, specific entities, plugin names)? → NOT HERE
+3. Same pattern in 2+ plugins? → promote to framework
+
+**Hard rules:**
+- ❌ No plugin names or business-specific terms in code, identifiers, namespaces, or docs
+- ❌ No framework → plugin references
+- ✅ Abstract/virtual base classes — plugins derive/override
+- ✅ Generic DTOs / extensions / interfaces for cross-plugin reuse
+- ✅ Mirror NopCommerce entities without a hard runtime dependency on Nop
+
+**Nop-plugin-framework-specific emphasis:**
+- `NopDependencies/` mirrors NopCommerce entity classes (same namespace as originals) — stays generic, no plugin-specific logic
+- DTOs use type parameters for consumer entity types (e.g. `MgOrderDto<TOrderItemDto, TProductDto>`) — never hardcode concrete plugin types
+- Zero runtime NopCommerce dependency — plugin apps bring their own Nop runtime
+- Any plugin-specific logic (domain rules, business-specific entities) stays in the plugin, not here
+
+Framework design = **"write the base first, derive the specific later"**.
+
+Full doctrine: AyCode.Core's `.github/copilot-instructions.md#framework-first-design-principle` and `docs/ARCHITECTURE.md#framework-vs-consumer-boundary`.
+
+## Related Documentation
+
+| Document | Topic |
+|---|---|
+| `docs/ARCHITECTURE.md` | Layer position, Nop-framework-specific architecture notes |
+| `docs/CONVENTIONS.md` | Framework-first placement + Nop-specific naming |
+| `docs/DTOS.md` | DTO system — two mapping strategies, all DTO types |
+| `docs/NOP_DEPENDENCIES.md` | Mirror pattern for NopCommerce entities |
+| `README.md` | Folder structure, entity hierarchy, key types index |
+
+## Related Solutions
+
+Types referenced here but not defined may live in AyCode.Core or AyCode.Blazor (see @repo path above for AyCode.Core; AyCode.Blazor is at sibling path).

Mango.Nop.Core/docs/ARCHITECTURE.md

@@ -0,0 +1,44 @@
+# Architecture
+
+## Framework vs. Consumer Boundary
+
+This solution is **Layer 2 — Domain framework** (NopCommerce-plugin base). Built on Layer 0 (AyCode.Core), consumed by Layer 3 (specific plugin apps, plural and unknown). Full doctrine: AyCode.Core's `docs/ARCHITECTURE.md#framework-vs-consumer-boundary`.
+
+### Layer position
+
+```
+Layer 0 — AyCode.Core              universal primitives (serializers, logging, entities)
+Layer 2 — Mango.Nop.Core           this solution — NopCommerce-plugin domain framework
+Layer 3 — Consumer plugin apps     specific plugin projects with business logic
+```
+
+### Nop-plugin-framework-specific notes
+
+- **`NopDependencies/`** mirrors NopCommerce entity classes under the original Nop namespaces — no runtime Nop dependency, compile-time type parity only
+- **DTOs** use type parameters for consumer entity types (e.g. `MgOrderDto<TOrderItemDto, TProductDto>`) — concrete types are provided by plugin projects
+- **Entity hierarchy**: `Nop.Core.BaseEntity` (mirrored) → `MgEntityBase` → generic DTOs/entities parameterized for consumers
+- **`Logger` / `ILogger`** extend AyCode logging (`AcLoggerBase`) — plugin projects may subclass again if business-specific writers are needed
+- **Zero runtime Nop dependency** — plugin apps bring their own Nop runtime
+
+### What belongs here vs. in a plugin
+
+**Yes, framework:**
+- NopCommerce entity mirrors (for cross-plugin type sharing)
+- Generic DTOs with type parameters
+- Shared interfaces and extensions for NopCommerce domain entities
+- Logger base with AyCode integration
+
+**No, plugin only:**
+- Plugin-specific business logic
+- Plugin-named types (`XxxPlugin`, `XxxService` where Xxx is a specific product)
+- Hardcoded plugin configuration, tenant, or product IDs
+
+## Related Documents
+
+| Topic | Document |
+|---|---|
+| Framework-first doctrine (full) | `../../../../../../../Aycode/Source/AyCode.Core/docs/ARCHITECTURE.md#framework-vs-consumer-boundary` |
+| Placement rules, anti-patterns | `CONVENTIONS.md#framework-first-placement` |
+| DTO system and GenericAttribute typed access | `DTOS.md` |
+| NopDependencies mirror pattern | `NOP_DEPENDENCIES.md` |
+| Folder structure and key types index | `../README.md` |

Mango.Nop.Core/docs/CONVENTIONS.md

@@ -0,0 +1,24 @@
+# Conventions
+
+For core framework conventions (Ac prefix, naming patterns, Session/Transaction, etc.) see AyCode.Core's `docs/CONVENTIONS.md`.
+
+## Framework-First Placement
+
+Follow the doctrine in AyCode.Core's `docs/CONVENTIONS.md#framework-first-placement`. Same verdict table and hard rules apply.
+
+**Nop-plugin-framework-specific additions:**
+- `NopDependencies/` mirror classes stay in their original Nop namespaces — don't rename, don't add plugin-specific fields
+- DTOs parameterize via type arguments, not concrete plugin types
+- Any plugin-specific business logic belongs in the plugin project, not here
+- Adding a new shared DTO: ensure it is useful for 2+ plugin projects (otherwise keep in the single plugin)
+
+## Naming
+
+- **`Mg` prefix**: for Mango-framework-level types (e.g. `MgEntityBase`, `MgOrderDto`, `MgProductDto`)
+- **`IMg` prefix**: for Mango-framework-level interfaces (e.g. `IMgModelDtoBase`, `IMgSoftRemoveEntity`)
+- **No prefix**: for NopCommerce entity mirrors in `NopDependencies/` — they stay in Nop namespace, same name as upstream
+
+## See Also
+
+- Core framework naming (`Ac` / `IAc` prefixes), patterns, serialization conventions: AyCode.Core's `docs/CONVENTIONS.md`
+- Framework-first verdict table (full): AyCode.Core's `docs/CONVENTIONS.md#framework-first-placement`