diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md
index 4dfa0363..9c1cffb6 100644
--- a/.github/copilot-instructions.md
+++ b/.github/copilot-instructions.md
@@ -4,17 +4,25 @@
 You are operating in a multi-repo, documentation-first architecture. You MUST STRICTLY follow this protocol for every response. Failure to do so will break the workspace rules.
 
 1. **MANDATORY OUTPUT PREFIX:** Your response MUST begin on the very first line with this format:
-   `[LOADED_DOCS: N files (+K this turn: <comma-separated basenames>)]`
+   `[LOADED_DOCS: N files (+K this turn: <comma-separated short names>)]`
    - `N` = total count of `.md` files currently in your context (across all loaded docs in this conversation)
    - `K` = count of `.md` files newly loaded during THIS response (may be 0)
-   - If `K > 0`: list the newly loaded **basenames only** (no paths) after `:`
+   - If `K > 0`: list the newly loaded files as **shortest unique short names** (see naming rule below)
    - If `K = 0`: write `[LOADED_DOCS: N files, no new loads]`
    - If `N = 0`: write `[LOADED_DOCS: NONE]`
 
+   **Short-name rule (for each loaded `.md` file):**
+   - **Default:** use the basename only. Works for all topic-prefixed companions (`LOGGING_ISSUES.md`, `BINARY_FEATURES.md`) and flat single-file topics (`ARCHITECTURE.md`, `GLOSSARY.md`, `CONVENTIONS.md`) — these are already unique.
+   - **For `README.md` files:** always include the immediate parent folder as prefix → `TOPIC/README.md` (e.g., `LOGGING/README.md`, `BINARY/README.md`). Never write a bare `README.md` in the prefix because multiple folders have one.
+   - **Cross-project disambiguation:** if two files share the same short name (rare — e.g., `docs/README.md` from two different projects), extend the prefix one more level: `PROJECT/docs/README.md`. Always use the shortest unique form.
+   - **Never use absolute paths.** Never include the `.github/` prefix for `copilot-instructions.md` — the `.github/` location is implicit. When multiple are loaded simultaneously (typical in `protocol-audit`), apply the cross-project disambiguation above: `AyCode.Core/copilot-instructions.md`, `FruitBankHybridApp/copilot-instructions.md`, etc.
+
    **Examples:**
    - `[LOADED_DOCS: NONE]` — nothing loaded yet
    - `[LOADED_DOCS: 1 files, no new loads]` — only `copilot-instructions.md` loaded earlier, nothing new this turn
-   - `[LOADED_DOCS: 4 files (+3 this turn: LOGGING.md, LOGGING_ISSUES.md, LOGGING_TODO.md)]` — 3 new this turn
+   - `[LOADED_DOCS: 4 files (+3 this turn: LOGGING/README.md, LOGGING_ISSUES.md, LOGGING_TODO.md)]` — logger topic folder loaded
+   - `[LOADED_DOCS: 7 files (+3 this turn: SIGNALR/README.md, SIGNALR_ISSUES.md, SIGNALR_TODO.md)]` — SignalR topic loaded (LOGGING was already in context)
+   - `[LOADED_DOCS: 5 files (+2 this turn: ARCHITECTURE.md, GLOSSARY.md)]` — top-level reference docs loaded (flat, no folder prefix needed)
 
    This prefix is MANDATORY on **EVERY** response (not just the first, not just when loading happens). It serves two purposes: **(a)** user-visible compliance signal, and **(b)** self-commitment for the no-re-read rule — in subsequent turns you read your own prior prefix from the conversation to enforce Rule #3. Dropping the prefix breaks both.
 
@@ -52,6 +60,23 @@ You are operating in a multi-repo, documentation-first architecture. You MUST ST
 5. **EXPLICIT CONSENT FOR MODIFICATIONS:**
    NEVER rewrite, create, or delete any file (code, documentation, configuration, memory, or otherwise) without the user's explicit permission. If the user does not specifically request a code modification (e.g., using phrases like "we are just thinking," "what do you think," "let's plan"), you MUST ONLY provide text-based analysis and planning. You are FORBIDDEN from using file-modifying tools (`replace_string_in_file`, `edit_file`, `create_file`, etc.) until the user explicitly says "ok", "go ahead", "implement", or a similar unambiguous approval.
 
+## Session Setup
+
+**Mandatory reads at session start** — in addition to this `copilot-instructions.md`, the agent MUST load the four workspace skills' `SKILL.md` files:
+
+- `docs-discovery/SKILL.md` — **reactive** (triggers on any domain question — must be ready BEFORE the first domain query arrives)
+- `docs-check/SKILL.md` — **reactive** (triggers at the end of every code-modifying response)
+- `protocol-audit/SKILL.md` — **on-demand** (triggers on explicit "audit protocol" command)
+- `adr-author/SKILL.md` — **on-demand + LLM-suggested** (triggers on explicit planning/design requests, or when the LLM flags an ADR-worthy conversation and the user confirms)
+
+**Path resolution**: if this repo is the canonical protocol host (see `@repo` block below — typically AyCode.Core), the paths are local: `.github/skills/<skill>/SKILL.md`. Otherwise, prefix with this repo's `own-dep-repos` AyCode.Core path (see the `## Shared Agent Skills` section below for explicit paths).
+
+**Why mandatory**: workspace skills are NOT in Claude Code's native skill-registry / system-reminder. Without pre-loading their `SKILL.md` content, the agent cannot reliably recognize implicit triggers (e.g., "domain question → invoke docs-discovery" at the moment the question arrives, not retroactively). Pre-loading is a **one-time cost** per session (~10-13K tokens); Rule #3 (no-re-read) prevents repeated reads; re-read only if Rule #4 (Context Recovery) fires.
+
+**Amortization — critical, do NOT re-evaluate per-turn**: the Session Setup cost is measured over the ENTIRE session, not per single turn. A typical session has many turns; the first domain question alone already recoups the investment (alternative — repeated source-code `Grep`/`Read` per turn — costs 10-20K tokens *per turn* with lower output quality). Do NOT flag pre-loaded content as "wasteful" for turns that don't invoke it — the design depends on cross-turn amortization + Rule #3 (no-re-read) + on-demand specificity of Rule #4 (Context Recovery). This amortization is the **central token-economics principle** of the entire protocol stack.
+
+The first response's `[LOADED_DOCS: ...]` prefix must reflect **5 files** (this `copilot-instructions.md` + 4 SKILL.md).
+
 ## Workspace Dependencies
 # own-dep-repos: "name: path" — paths are relative to this repo root (.github/..)
 @repo {
@@ -61,7 +86,6 @@ You are operating in a multi-repo, documentation-first architecture. You MUST ST
   own-dep-repos = [
     "AyCode.Core: ../../../Aycode/Source/AyCode.Core",
     "Mango.Nop Libraries: ../NopCommerce.Common/4.70/Libraries"
-    "Mango.Nop Plugins: ../NopCommerce.Common/4.70/Plugins"
   ]
 }
 
@@ -72,7 +96,7 @@ You are operating in a multi-repo, documentation-first architecture. You MUST ST
 
 ## Shared Agent Skills
 
-Skills defined in other repos that can be referenced from here:
+Skills defined in other repos. **All four are pre-loaded at session start per the `## Session Setup` section above** (mandatory — ensures implicit triggers fire reliably):
 
 - **protocol-audit** — Cross-repo consistency audit for `.github/copilot-instructions.md` across all 5 repos.
   Location: `AyCode.Core/.github/skills/protocol-audit/SKILL.md`
@@ -82,6 +106,14 @@ Skills defined in other repos that can be referenced from here:
   Location: `AyCode.Core/.github/skills/docs-discovery/SKILL.md` (see `own-dep-repos` above for the relative path to AyCode.Core)
   **Invoke proactively** before any domain-related coding task (see "Documentation-first coding" below). Honours the active repo's **no-re-read** rule.
 
+- **docs-check** — Evaluate loaded `.md` files at the end of every code-modifying response: drift vs code, missing topic coverage, csproj-glob registration gaps for new `.md` files, and new issue/TODO candidates. Emits the `[DOCUMENTATION CHECK]` section.
+  Location: `AyCode.Core/.github/skills/docs-check/SKILL.md`
+  **Invoke at the end of every code-modifying response.** Read-only on loaded docs; all patches surface as proposals (Rule #5 approval required).
+
+- **adr-author** — Create Architecture Decision Records (ADRs) for architecturally significant design decisions. Structured interview (context → alternatives → trade-offs → decision → consequences) producing a durable `docs/adr/NNNN-<slug>.md` file (product decisions) or a new `LLMP-DEC-N` row in the protocol decision log (meta-protocol decisions).
+  Location: `AyCode.Core/.github/skills/adr-author/SKILL.md`
+  **Invoke on explicit user request** ("let's plan X", "decide Y vs Z", "design the W module") **or proactively flag** when the conversation looks ADR-worthy (user must confirm — never auto-invoke).
+
 ## Protocol History
 
 Cumulative log of LLM-protocol decisions (rule changes, new skills, structural shifts):
@@ -117,10 +149,7 @@ Before running any source-code `Grep` / `get_file` / `code_search` in response t
 11. Do not suggest removal/rollback as a solution — find a fix for the problem.
 12. All AyCode references are via **DLL** (not ProjectReference) — this is intentional. nopCommerce 4.80.9 requirement.
 13. **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.
-14. **Keep all .md documentation in sync (PASSIVE DETECTION & ASK FIRST)** — If you notice *any contradiction, error, or missing information* between the code and your currently loaded `.md` files, **briefly notify the user and ask for permission before making changes**. Do NOT automatically update `.md` files or trigger new searches yet. Once the user approves, you may actively search, read, and update the necessary docs in the correct layer.
-**Identify missing documentation:** If you notice during your task that a frequently used pattern, underlying logic, or important behavior is missing from the docs, **and adding it would improve future LLM context-efficiency (saving searches/tokens)**, briefly notify the user to get approval.
-**Topic-based separation:** When creating or expanding documentation, keep logically distinct features or domains in separate `.md` files (e.g., architecture, data model, billing) and only reference them in the main/index documents. Do not cram everything into a single monolithic file. Keep in mind: these `.md` files are primarily for LLM grounding and context providing. Keep them concise, structured, and focused on rules/patterns rather than human-readable prose.
-**ENFORCEMENT:** At the end of EVERY code-modifying response, append a **`[DOCUMENTATION CHECK]`** section. Evaluate ONLY the `.md` files *already in your context*. State in 1-2 sentences if you found discrepancies or missing concepts, and ask if they should be documented. **DO NOT trigger searches or tool calls for this initial check**.
+14. **Keep all .md documentation in sync** — at the end of EVERY code-modifying response, invoke the **`docs-check`** skill (`AyCode.Core/.github/skills/docs-check/SKILL.md`). It evaluates loaded `.md` files for drift vs code, missing topic coverage, csproj-glob registration gaps for new `.md` files, and new issue/TODO candidates — then emits the `[DOCUMENTATION CHECK]` section per its procedure (or `[DOCUMENTATION CHECK] None.` single-line when nothing to report). The skill encapsulates the full calibration (4 prerequisites, 3-item volume cap, no-ID rule, status-update-on-fix clause) and empty-state handling. Passive detection + ASK FIRST; all patches require user approval (Rule #5). Do NOT trigger new searches for this check.
 15. **AyCode.Core** solution (`../../../Aycode/Source/AyCode.Core/`) contains all core framework code: SignalR base classes, serialization, binary protocol, data sources, logging. Types not defined in this workspace likely live in AyCode.Core.
 16. **Mango.Nop Libraries** (`../NopCommerce.Common/4.70/Libraries/`) — independent shared library. Contains DTOs, entities, data access, and service base classes. DTO or entity base classes not found in plugins likely live in Libraries.
 17. **FruitBank nopCommerce Plugin** (`../NopCommerce.Common/4.70/Plugins/Nop.Plugin.Misc.AIPlugin/`) is the main FruitBank plugin. Contains SignalR hubs/endpoints, measurement services, data access (DbTable classes), admin controllers, and AI services. For plugin docs see: `../NopCommerce.Common/4.70/Plugins/Nop.Plugin.Misc.AIPlugin/docs/`.