docs: rename architecture overview path

Author: KSemenenko

README.md

@@ -72,7 +72,7 @@ Anything that materially affects development, verification, or operation belongs
 
 A typical MCAF repo keeps durable docs under `docs/`:
 
-- `docs/Architecture/` — global map and module boundaries
+- `docs/Architecture.md` — global map and module boundaries
 - `docs/Features/` — behaviour specs and testable flows
 - `docs/ADR/` — architecture decisions and trade-offs
 - `docs/Testing/` — test strategy and environments
@@ -121,9 +121,9 @@ Every `mcaf-dotnet*` tool skill should include a `Bootstrap When Missing` sectio
 ### 2.5 Context Rules
 
 - All durable engineering context lives in the repository.
-- The project has a current `docs/Architecture/Overview.md`.
+- The project has a current `docs/Architecture.md`.
 - Humans and agents start from the architecture map, not repo-wide scanning.
-- `docs/Architecture/Overview.md` contains Mermaid diagrams for system/module boundaries, interfaces/contracts, and key types for the active area.
+- `docs/Architecture.md` contains Mermaid diagrams for system/module boundaries, interfaces/contracts, and key types for the active area.
 - Feature docs under `docs/Features/` contain at least one Mermaid diagram for the main flow.
 - ADRs under `docs/ADR/` contain at least one Mermaid diagram for the decision and affected boundaries.
 - Multi-project solutions use root plus project-local `AGENTS.md` files.

TUTORIAL.md

@@ -293,5 +293,5 @@ Use a prompt like this:
 Analyze this solution and customize the root AGENTS.md.
 If this is a multi-project solution, create project-local AGENTS.md files in each project root.
 Then identify which MCAF skills apply to each project and document them in the local AGENTS files.
-Finally, update docs/Architecture/Overview.md so agents can scope work without repo-wide scanning.
+Finally, update docs/Architecture.md so agents can scope work without repo-wide scanning.
 ```

docs/templates/AGENTS.md

@@ -155,8 +155,8 @@ Local `AGENTS.md` files may tighten these values, but they must not loosen them
 
 ### Task Delivery
 
-- Start from `docs/Architecture/Overview.md` and the nearest local `AGENTS.md`.
-- Treat `docs/Architecture/Overview.md` as the architecture map for every non-trivial task.
+- Start from `docs/Architecture.md` and the nearest local `AGENTS.md`.
+- Treat `docs/Architecture.md` as the architecture map for every non-trivial task.
 - If the overview is missing, stale, or diagram-free, update it before implementation.
 - Define scope before coding:
   - in scope
@@ -206,8 +206,8 @@ Local `AGENTS.md` files may tighten these values, but they must not loosen them
 ### Documentation
 
 - All durable docs live in `docs/` (or `.wiki/` if the repo already uses it).
-- `docs/Architecture/Overview.md` is the required global map and the first stop for agents.
-- `docs/Architecture/Overview.md` MUST contain Mermaid diagrams for:
+- `docs/Architecture.md` is the required global map and the first stop for agents.
+- `docs/Architecture.md` MUST contain Mermaid diagrams for:
   - system or module boundaries
   - interfaces or contracts between boundaries
   - key classes or types for the changed area

skills/mcaf-adr-writing/SKILL.md

@@ -25,7 +25,7 @@ compatibility: "Requires repository write access; produces Markdown ADRs with Me
 
 ## Inputs
 
-- `docs/Architecture/Overview.md`
+- `docs/Architecture.md`
 - related feature docs
 - the nearest `AGENTS.md`
 - current constraints, options, and risks
@@ -47,7 +47,7 @@ compatibility: "Requires repository write access; produces Markdown ADRs with Me
    - trade-offs and consequences
    - implementation plan
 4. Add diagrams only when they remove ambiguity.
-5. Link the ADR to affected feature docs and `docs/Architecture/Overview.md`.
+5. Link the ADR to affected feature docs and `docs/Architecture.md`.
 
 ## Deliver
 

skills/mcaf-adr-writing/references/ADR-FORMATS.md

@@ -119,7 +119,7 @@ Key points:
 - Feature docs to update:
 - Testing docs to update:
 - Architecture docs to update:
-- `docs/Architecture/Overview.md` updates (what must change):
+- `docs/Architecture.md` updates (what must change):
 - Notes for `AGENTS.md` (new rules/patterns):
 
 ---
@@ -181,7 +181,7 @@ Key points:
 - [ ] Status reflects real state (`Proposed`, `Accepted`, `Rejected`, `Superseded`).
 - [ ] Links to related features, tests, and ADRs are filled in.
 - [ ] Diagram section contains at least one Mermaid diagram.
-- [ ] `docs/Architecture/Overview.md` updated if module boundaries or interactions changed.
+- [ ] `docs/Architecture.md` updated if module boundaries or interactions changed.
 ````
 
 ---

skills/mcaf-adr-writing/references/adr-template.md

@@ -120,7 +120,7 @@ This section is mandatory.
 - Feature docs to update:  
 - Testing docs to update:  
 - Architecture docs to update:  
-- `docs/Architecture/Overview.md` updates (what must change):  
+- `docs/Architecture.md` updates (what must change):  
 - Notes for `AGENTS.md` (new rules/patterns):
 
 ---
@@ -198,4 +198,4 @@ This section is mandatory: describe how to prove the decision (tests + commands)
 - [ ] Testing methodology is filled in with positive, negative, and edge flows plus pass criteria.
 - [ ] New or updated automated tests exist for the changed behaviour.
 - [ ] All relevant tests are green and coverage did not fall below baseline.
-- [ ] `docs/Architecture/Overview.md` updated if module boundaries or interactions changed.
+- [ ] `docs/Architecture.md` updated if module boundaries or interactions changed.

skills/mcaf-architecture-overview/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: mcaf-architecture-overview
-description: "Create or update `docs/Architecture/Overview.md` as the global architecture map for a solution. Use when bootstrapping a repo, onboarding, or changing modules, boundaries, or contracts. Keep it navigational and use `references/overview-template.md` for scaffolding."
+description: "Create or update `docs/Architecture.md` as the global architecture map for a solution. Use when bootstrapping a repo, onboarding, or changing modules, boundaries, or contracts. Keep it navigational and use `references/overview-template.md` for scaffolding."
 compatibility: "Requires repository write access; produces Markdown docs with Mermaid diagrams."
 ---
 
@@ -37,7 +37,7 @@ compatibility: "Requires repository write access; produces Markdown docs with Me
 
 ## Workflow
 
-1. Start from the current `docs/Architecture/Overview.md`; if it is missing, scaffold it from `references/overview-template.md`.
+1. Start from the current `docs/Architecture.md`; if it is missing, scaffold it from `references/overview-template.md`.
 2. Build a short navigational overview:
    - system or module map
    - key boundaries and contracts
@@ -49,7 +49,7 @@ compatibility: "Requires repository write access; produces Markdown docs with Me
 
 ## Deliver
 
-- `docs/Architecture/Overview.md`
+- `docs/Architecture.md`
 - a short architecture map that routes the reader to deeper docs
 
 ## Validate

skills/mcaf-architecture-overview/references/overview-template.md

@@ -1,6 +1,6 @@
 # Architecture Overview
 
-> TEMPLATE ONLY — remove this note and replace all placeholder text before saving as a real `docs/Architecture/Overview.md`.
+> TEMPLATE ONLY — remove this note and replace all placeholder text before saving as a real `docs/Architecture.md`.
 
 Goal: in ~5 minutes, understand **what exists**, **where it lives**, and **how modules interact**.
 
@@ -30,7 +30,7 @@ Single source of truth: keep this doc navigational and coarse (diagrams + links)
 > Diagrams are for humans and AI agents. They must be self-describing.  
 > Model real blocks/modules/interfaces and **key** classes/types (not every file). Add dependencies only if they exist.  
 > Every diagram element must be anchored via real, clickable Markdown links in the indexes below (feature docs, ADRs, code paths, entry-point files).  
-> From `docs/Architecture/Overview.md`, code links usually start with `../../` (two levels up to repo root).  
+> From `docs/Architecture.md`, code links usually start with `../` (one level up to repo root).  
 > If a diagram becomes a messy “spaghetti graph”, it is incorrect: split by boundary and keep each diagram readable.  
 > Remove this note in the real doc.
 
@@ -89,17 +89,17 @@ classDiagram
 
 ### 3.1 Modules (diagram nodes)
 
-- `ModuleName` — code: [path/to/module/](../../path/to/module/); entry points: [path/to/entrypoint](../../path/to/entrypoint); docs: [docs/Features/...](../Features/...) / [docs/ADR/...](../ADR/...)
+- `ModuleName` — code: [path/to/module/](../path/to/module/); entry points: [path/to/entrypoint](../path/to/entrypoint); docs: [docs/Features/...](./Features/...) / [docs/ADR/...](./ADR/...)
 
 ### 3.2 Interfaces / contracts (diagram edges)
 
-- `ContractName` (HTTP/event/queue/interface) — source of truth: [path/to/api-or-contract](../../path/to/api-or-contract); producer/caller: ModuleA; consumer: ModuleB; docs: [docs/ADR/...](../ADR/...)
+- `ContractName` (HTTP/event/queue/interface) — source of truth: [path/to/api-or-contract](../path/to/api-or-contract); producer/caller: ModuleA; consumer: ModuleB; docs: [docs/ADR/...](./ADR/...)
 
 ### 3.3 Key classes / types (optional, high-signal only)
 
 > Include only cross-module/public types that matter for understanding and safe change (usually <= 10–20). Do not list internal implementation classes.
 
-- `TypeName` (class/interface/DTO/event) — defined in: [path/to/TypeName](../../path/to/TypeName); used by: ModuleA / ModuleB
+- `TypeName` (class/interface/DTO/event) — defined in: [path/to/TypeName](../path/to/TypeName); used by: ModuleA / ModuleB
 
 ## 4) Dependency rules (must be explicit)
 
@@ -113,10 +113,10 @@ classDiagram
 - Link ADRs that define boundaries, dependencies, and cross-cutting patterns.  
 - Keep this section link-based. Detailed flows belong in feature docs / ADRs, not in the overview.
 
-- [docs/ADR/ADR-XXXX-some-decision.md](../ADR/ADR-XXXX-some-decision.md) — what it decides, and what it impacts
+- [docs/ADR/ADR-XXXX-some-decision.md](./ADR/ADR-XXXX-some-decision.md) — what it decides, and what it impacts
 
 ## 6) Where to go next
 
-- Decisions: [docs/ADR/](../ADR/)  
-- Behaviour specs: [docs/Features/](../Features/)  
-- How to run + verify: [docs/Development/](../Development/), [docs/Testing/](../Testing/)
+- Decisions: [docs/ADR/](./ADR/)  
+- Behaviour specs: [docs/Features/](./Features/)  
+- How to run + verify: [docs/Development/](./Development/), [docs/Testing/](./Testing/)

skills/mcaf-feature-spec/SKILL.md

@@ -25,7 +25,7 @@ compatibility: "Requires repository write access; produces Markdown docs with Me
 
 ## Inputs
 
-- `docs/Architecture/Overview.md`
+- `docs/Architecture.md`
 - the nearest `AGENTS.md`
 - current user flows, business rules, and acceptance expectations
 

skills/mcaf-feature-spec/references/feature-template.md

@@ -3,7 +3,7 @@
 > TEMPLATE ONLY — remove this note and replace all placeholder text before saving as a real feature doc under `docs/Features/`.
 
 Links:  
-Architecture: `docs/Architecture/Overview.md`  
+Architecture: `docs/Architecture.md`  
 Modules:  
 ADRs: `docs/ADR/...`  
 
@@ -187,6 +187,6 @@ Include this section only if it applies to this feature; otherwise remove it.
 
 - ADRs: `docs/ADR/...`  
 - API: `docs/API/...`  
-- Architecture: `docs/Architecture/...`  
+- Architecture: `docs/Architecture.md`  
 - Testing: `docs/Testing/...`  
 - Code: modules / namespaces