docs: update readme

docs/content/architecture/architecture.md

@@ -69,7 +69,7 @@ graph TB
 
 ## Layered Architecture
 
-The platform follows a **clean/hexagonal architecture** with clear separation of concerns across layers.
+The platform follows a **hexagonal architecture** with clear separation of concerns across layers.
 
 ```mermaid
 graph TD

docs/content/index.md

@@ -63,7 +63,7 @@ Detailed task definitions for each epic are available in the [Stories section](s
 
 ## Key Principles
 
-- **Clean/Hexagonal Architecture**: Clear separation between core and plugins
+- **Hexagonal Architecture**: Clear separation between core and plugins
 - **Microservices Architecture**: Each module is an independent service from day one
 - **Plugin-First Design**: Extensible architecture supporting static and dynamic modules
 - **Security-by-Design**: Built-in authentication, authorization, and audit capabilities

docs/content/plan.md

@@ -13,7 +13,7 @@ This plan breaks down the implementation into **8 epics**, each with specific de
 **Total Estimated Timeline:** 8-12 weeks (depending on team size and parallelization)
 
 **Key Principles:**
-- **Clean/Hexagonal Architecture** with clear separation between `pkg/` (interfaces) and `internal/` (implementations)
+- **Hexagonal Architecture** with clear separation between `pkg/` (interfaces) and `internal/` (implementations)
 - **Dependency Injection** using `uber-go/fx` for lifecycle management
 - **Microservices Architecture** - each module is an independent service from day one
 - **Service Client Interfaces** - all inter-service communication via gRPC/HTTP

docs/content/playbook.md

@@ -5,7 +5,7 @@
 
 | Principle | Go‑specific rationale | Enforcement Technique |
 |-----------|-----------------------|------------------------|
-| **Clean / Hexagonal Architecture** | Go’s package‑level visibility (`internal/`) naturally creates a *boundary* between core and plug‑ins. | Keep all **domain** code in `internal/domain`, expose only **interfaces** in `pkg/`. |
+| **Hexagonal Architecture** | Go’s package‑level visibility (`internal/`) naturally creates a *boundary* between core and plug‑ins. | Keep all **domain** code in `internal/domain`, expose only **interfaces** in `pkg/`. |
 | **Dependency Injection (DI) via Constructors** | Go avoids reflection‑heavy containers; compile‑time wiring is preferred. | Use **uber‑go/fx** (runtime graph) *or* **uber‑go/dig** for optional runtime DI. For a lighter weight solution, use plain **constructor injection** with a small **registry**. |
 | **Modular Monolith → Micro‑service‑ready** | A single binary is cheap in Go; later you can extract modules into separate services without breaking APIs. | Each module lives in its own Go **module** (`go.mod`) under `./modules/*`. The core loads them via the **Go plugin** system *or* static registration (preferred for CI stability). |
 | **Plugin‑first design** | Go’s `plugin` package allows runtime loading of compiled `.so` files (Linux/macOS). | Provide an **IModule** interface and a **loader** that discovers `*.so` files (or compiled‑in modules for CI). |