@toyako/hive 1.0.0

package/docs/v2.0-architecture-proposal.md

@@ -0,0 +1,684 @@
+# Agent Hive v1.0 Architecture Proposal
+
+> Date: 2026-06-06
+> Status: Draft
+> Author: Hermes Agent (Subagent)
+> Based on: v1.1 STABLE codebase + 10 boundary questions
+
+---
+
+## Executive Summary
+
+v1.1 is a **single-chain orchestrator**: Broker → Executor → Reviewer → Done.
+v1.0 transforms Agent Hive into a **graph-based multi-agent collaboration system** where multiple agent runtimes (Codex, Claude, Hermes, OpenClaw) can collaborate, negotiate, and delegate work in arbitrary topologies.
+
+The key metaphor shift:
+- v1.1: A **pipeline** (linear)
+- v1.0: A **mesh** (graph-based, with routing intelligence)
+
+---
+
+## Question 1: v1.0 Core Objective
+
+**Enable multiple AI agent runtimes to collaborate on complex tasks through a graph-based message routing system, while maintaining v1.1's reliability guarantees.**
+
+Specific goals:
+1. **Multi-Agent Collaboration**: A task can involve 3+ agents in arbitrary topologies (Planner → Executor → Reviewer, or Frontend → Backend → QA)
+2. **Dynamic Routing**: The Broker can route messages based on agent capabilities, not just hardcoded links
+3. **Conversation Protocol**: Agents can have multi-turn conversations, not just execute-then-review
+4. **Backward Compatibility**: v1.1 single-chain workflows still work unchanged
+5. **Pluggable Runtimes**: Any new agent runtime can be added via adapter interface
+
+Non-goals (deferred):
+- Secret Vault (v1.0)
+- WebUI dashboard (v1.0+)
+- Distributed deployment across machines (v1.0)
+
+---
+
+## Question 2: Agent vs Runtime Relationship
+
+### Definitions
+
+| Concept | Definition | Example |
+|---------|-----------|---------|
+| **Runtime** | A concrete AI execution environment with a binary/API | `codex`, `claude`, `hermes`, `openclaw` |
+| **Agent** | A logical role assigned to a Runtime with specific capabilities | `executor-codex`, `reviewer-claude`, `planner-hermes` |
+| **Adapter** | The bridge code that translates Mesh protocol ↔ Runtime CLI/API | `CodexAdapter`, `ClaudeAdapter` |
+
+### Relationship Model
+
+```
+Runtime (1) ──── (N) Agent
+```
+
+One Runtime can serve multiple Agent roles. For example:
+- `claude` Runtime can be both `code-reviewer` Agent and `architecture-advisor` Agent
+- `codex` Runtime can be both `frontend-coder` Agent and `backend-coder` Agent
+
+### Registry Design
+
+```typescript
+interface RuntimeEntry {
+  id: string;                    // "codex", "claude", "hermes"
+  binary: string;                // path to binary
+  adapter: AgentAdapter;         // the adapter instance
+  capabilities: string[];        // ["coding", "review", "architecture"]
+  healthy: boolean;
+  installed: boolean;
+}
+
+interface AgentProfile {
+  id: string;                    // "planner", "executor-1", "reviewer-main"
+  runtimeId: string;             // references RuntimeEntry.id
+  role: AgentRole;               // "planner" | "executor" | "reviewer" | "coordinator" | "custom"
+  systemPrompt?: string;         // optional role-specific prompt
+  maxConcurrency: number;        // how many tasks this agent handles simultaneously
+  status: "idle" | "busy" | "offline";
+}
+```
+
+This separation allows:
+- Same runtime to wear different hats
+- Agent-specific configuration (prompts, concurrency)
+- Clean scaling: add more executor agents on same runtime
+
+---
+
+## Question 3: Agent Relationship Graph Design
+
+### v1.1 Limitation
+`reportsTo` is a simple tree: each agent reports to exactly one parent. This is too rigid.
+
+### v1.0: Directed Capability Graph
+
+```typescript
+interface GraphEdge {
+  from: string;          // agent profile id
+  to: string;            // agent profile id
+  relation: EdgeRelation;
+  condition?: string;    // optional routing condition
+  weight: number;        // routing priority (higher = preferred)
+}
+
+type EdgeRelation =
+  | "delegates"      // A delegates work to B
+  | "reviews"        // A reviews B's output
+  | "provides"       // A provides data/context to B
+  | "escalates"      // A escalates failures to B
+  | "collaborates"   // A and B work together on same task
+  | "approves";      // A must approve B's output before it's final
+```
+
+### Graph Storage
+
+Persisted to `.agent-hive/graph.json`:
+```json
+{
+  "agents": {
+    "planner": { "runtimeId": "hermes", "role": "planner" },
+    "executor-codex": { "runtimeId": "codex", "role": "executor" },
+    "executor-claude": { "runtimeId": "claude", "role": "executor" },
+    "reviewer": { "runtimeId": "claude", "role": "reviewer" }
+  },
+  "edges": [
+    { "from": "planner", "to": "executor-codex", "relation": "delegates", "weight": 10 },
+    { "from": "planner", "to": "executor-claude", "relation": "delegates", "weight": 5 },
+    { "from": "executor-codex", "to": "reviewer", "relation": "reviews", "weight": 10 },
+    { "from": "reviewer", "to": "executor-codex", "relation": "escalates", "weight": 10 }
+  ]
+}
+```
+
+### Built-in Topology Templates
+
+```typescript
+// Pre-built templates for common patterns
+const TEMPLATES = {
+  "simple-chain":  // v1.1 compatible: Executor → Reviewer
+  "plan-execute-review":  // Planner → Executor → Reviewer
+  "fan-out-review":  // Executor → [Reviewer1, Reviewer2, Reviewer3] (majority vote)
+  "pipeline":  // Agent1 → Agent2 → Agent3 → ... (sequential pipeline)
+  "peer-review":  // AgentA ↔ AgentB (mutual review)
+};
+```
+
+---
+
+## Question 4: Message Routing Design
+
+### v1.1 Limitation
+Messages go directly from→to. No routing intelligence.
+
+### v1.0: Broker-Router with Routing Table
+
+All messages still pass through Broker (architecture principle), but routing is now intelligent.
+
+```typescript
+interface MessageEnvelope {
+  id: string;
+  taskId: string;
+  conversationId: string;    // NEW: groups related messages
+  from: string;
+  to: string;               // can be agent id OR capability tag
+  type: MessageType;
+  payload: any;
+  metadata: {
+    hopCount: number;        // prevents infinite loops
+    maxHops: number;         // configurable per task
+    replyTo?: string;        // for request-reply patterns
+    deadline?: number;       // message TTL
+    priority: number;        // 0-10
+  };
+  timestamp: number;
+}
+```
+
+### Routing Resolution
+
+When `to` is a capability tag (e.g., `"cap:coding"`), the Router resolves it:
+
+```typescript
+class MessageRouter {
+  resolve(to: string, graph: AgentGraph): string {
+    // 1. Direct agent id: return as-is
+    if (graph.hasAgent(to)) return to;
+
+    // 2. Capability tag: find best agent
+    if (to.startsWith("cap:")) {
+      const cap = to.slice(4);
+      const candidates = graph.agentsWithCapability(cap);
+      return this.selectBest(candidates); // by weight, health, load
+    }
+
+    // 3. Role tag: find by role
+    if (to.startsWith("role:")) {
+      const role = to.slice(5);
+      return graph.agentWithRole(role);
+    }
+
+    throw new Error(`Cannot resolve: ${to}`);
+  }
+}
+```
+
+### Routing Rules (persistent)
+
+```json
+{
+  "rules": [
+    {
+      "match": { "type": "REVIEW", "from.role": "executor" },
+      "route": { "to": "role:reviewer" },
+      "priority": 100
+    },
+    {
+      "match": { "type": "DELEGATE", "from.role": "planner" },
+      "route": { "to": "cap:coding" },
+      "priority": 50
+    }
+  ]
+}
+```
+
+---
+
+## Question 5: Mixed Runtime Support (Claude / Codex / OpenClaw / Hermes)
+
+### Adapter Interface (Enhanced)
+
+```typescript
+interface AgentAdapter {
+  // Identity
+  name: string;                          // "codex", "claude", "hermes", "openclaw"
+  role: AgentRole;
+  capabilities: string[];
+  version: string;                       // NEW: adapter version
+
+  // Lifecycle
+  detect(): Promise<boolean>;
+  health(): Promise<boolean>;
+
+  // Execution (required)
+  execute(task: Task, instruction?: string): Promise<AgentResult>;
+
+  // Review (optional - not all runtimes can review)
+  review?(task: Task): Promise<ReviewResult>;
+
+  // NEW: Conversation mode (optional - for multi-turn)
+  converse?(messages: MessageEnvelope[]): Promise<MessageEnvelope>;
+
+  // NEW: Capability query
+  supportsFeature?(feature: string): boolean;
+}
+```
+
+### Runtime Registry
+
+Adapters are discovered via a registry pattern:
+
+```typescript
+// Built-in adapters (always available)
+const BUILTIN = [CodexAdapter, ClaudeAdapter, MockCodexAdapter, MockClaudeAdapter];
+
+// Plugin adapters (loaded from .agent-hive/plugins/)
+// Any .js file that exports { name, createAdapter() }
+```
+
+### Runtime-Specific Configuration
+
+```json
+// .agent-hive/runtimes.json
+{
+  "codex": {
+    "binary": "codex",
+    "args": ["exec", "--skip-git-repo-check", "--ephemeral"],
+    "timeout": 600000,
+    "features": ["coding", "refactor", "test"]
+  },
+  "claude": {
+    "binary": "claude",
+    "args": ["-p", "...", "--dangerously-skip-permissions"],
+    "timeout": 600000,
+    "features": ["coding", "review", "architecture"]
+  },
+  "hermes": {
+    "endpoint": "http://localhost:8080",
+    "apiKey": "${HERMES_API_KEY}",
+    "features": ["planning", "coordination", "reasoning"]
+  },
+  "openclaw": {
+    "binary": "openclaw",
+    "features": ["coding", "test"]
+  }
+}
+```
+
+---
+
+## Question 6: Preventing Infinite Loops
+
+### Multi-Layer Defense
+
+**Layer 1: Hop Count (Message Level)**
+```typescript
+// In MessageEnvelope
+metadata: {
+  hopCount: number;    // incremented at each routing step
+  maxHops: number;     // default: 10, configurable per task
+}
+// If hopCount > maxHops → message dropped, error logged
+```
+
+**Layer 2: Cycle Detection (Graph Level)**
+```typescript
+class GraphValidator {
+  // Detect cycles in the routing graph at build time
+  detectCycles(graph: AgentGraph): CycleReport;
+
+  // Warn if reviews→escalates→reviews creates tight loops
+  detectReviewLoops(graph: AgentGraph): LoopReport[];
+}
+```
+
+**Layer 3: Deduplication (Task Level)**
+```typescript
+// Track message fingerprints per task
+// If same (from, to, type, payload-hash) seen within window → block
+class MessageDeduplicator {
+  private seen: Map<string, number> = new Map(); // fingerprint → timestamp
+  private windowMs = 30_000; // 30s dedup window
+
+  isDuplicate(msg: MessageEnvelope): boolean;
+}
+```
+
+**Layer 4: Time Budget (Task Level)**
+```typescript
+interface TaskTimeBudget {
+  totalMs: number;           // hard limit for entire task
+  perAgentMs: number;        // limit per agent invocation
+  reviewCycleMs: number;     // limit for one review cycle
+}
+// If any budget exceeded → force-fail, log, notify
+```
+
+**Layer 5: Circuit Breaker (Agent Level)**
+```typescript
+class CircuitBreaker {
+  // If agent fails N times in M minutes → mark as OPEN (skip)
+  // After cooldown → HALF_OPEN (try one request)
+  // If success → CLOSED (normal)
+  private failures: Map<string, number[]> = new Map(); // agentId → timestamps
+  private threshold = 5;
+  private windowMs = 300_000; // 5 minutes
+  private cooldownMs = 60_000; // 1 minute
+
+  isOpen(agentId: string): boolean;
+  recordFailure(agentId: string): void;
+  recordSuccess(agentId: string): void;
+}
+```
+
+---
+
+## Question 7: Preventing Reviewer↔Executor Deadlock
+
+### The Problem
+Reviewer says FAIL → Executor revises → Reviewer says FAIL again → loop until maxRevision.
+
+This is actually **handled in v1.1** via `maxRevision`. But v1.0 adds more sophistication:
+
+### Solution 1: Escalation Path
+```typescript
+// When review fails maxRevision times, escalate instead of dying
+interface EscalationPolicy {
+  onMaxRevisionReached: "fail" | "escalate" | "accept-with-warnings" | "human-review";
+  escalateTo?: string;  // agent id for escalation
+}
+```
+
+### Solution 2: Review Quality Gate
+```typescript
+// If reviewer's score is monotonically decreasing across revisions → 
+// the revision is making things worse → break the cycle
+class ReviewAnalyzer {
+  isProgressing(history: RevisionRecord[]): boolean {
+    // Check if scores are trending upward
+    // If not → signal "stuck" to Broker
+  }
+}
+```
+
+### Solution 3: Reviewer Agreement (Multi-Reviewer)
+```typescript
+// If 2+ reviewers disagree → use third reviewer or escalate
+interface ReviewConsensus {
+  minReviewers: number;        // default: 1
+  consensusStrategy: "unanimous" | "majority" | "best-score";
+  onDisagreement: "escalate" | "third-reviewer" | "highest-score";
+}
+```
+
+### Solution 4: Structured Revision Feedback
+```typescript
+// v1.1: issues is just string[]
+// v1.0: structured feedback with expected changes
+interface StructuredReview extends ReviewResult {
+  decision: "PASS" | "FAIL";
+  score: number;
+  issues: ReviewIssue[];
+  suggestions: RevisionSuggestion[];  // NEW: specific fix instructions
+  context: string;                     // NEW: what was reviewed
+}
+
+interface ReviewIssue {
+  severity: "critical" | "major" | "minor" | "info";
+  category: "logic" | "style" | "performance" | "security" | "test";
+  description: string;
+  file?: string;
+  line?: number;
+  suggestedFix?: string;
+}
+```
+
+This gives the executor much clearer revision instructions, reducing the chance of repeated failures.
+
+---
+
+## Question 8: Secret Vault — v1.0 or v1.0?
+
+### Answer: **v1.0**
+
+**Reasoning:**
+- Secret Vault is a **cross-cutting concern** that affects all adapters
+- v1.0's focus is on **graph-based collaboration** — adding secret management dilutes scope
+- Current approach (environment variables + `--dangerously-skip-permissions`) works for development
+- Secret Vault requires careful security design that deserves dedicated attention
+
+### v1.0 Prep: Secret-Aware Adapter Interface
+```typescript
+interface AgentAdapter {
+  // ... existing methods ...
+  
+  // NEW: v1.0 adds the hook, v1.0 implements the vault
+  getRequiredSecrets?(): string[];  // ["OPENAI_API_KEY", "ANTHROPIC_API_KEY"]
+}
+```
+
+### v1.0 Scope
+- Encrypted `.agent-hive/secrets.enc` file
+- Per-agent secret scoping
+- Secret rotation
+- Audit log for secret access
+
+---
+
+## Question 9: WebUI — v1.0 or Later?
+
+### Answer: **v1.0 (minor release after v1.0)**
+
+**Reasoning:**
+- WebUI is a **presentation layer** that doesn't affect core architecture
+- v1.0 should nail the core graph + routing + multi-agent first
+- CLI is sufficient for developer workflow
+- WebUI can be added as a separate package (`@agent-hive/webui`)
+
+### v1.0 Prep: API Surface
+```typescript
+// v1.0 exposes a programmatic API that WebUI can consume later
+export class MeshAPI {
+  getAgents(): AgentProfile[];
+  getGraph(): AgentGraph;
+  getTasks(): Task[];
+  getTaskHistory(taskId: string): RevisionRecord[];
+  getMessageLog(taskId: string): MessageEnvelope[];
+  getHealth(): HealthReport;
+}
+```
+
+### v1.0 WebUI Scope
+- Real-time graph visualization (D3.js / Cytoscape)
+- Task status dashboard
+- Message flow viewer
+- Agent health monitor
+- WebSocket for live updates
+
+---
+
+## Question 10: Minimum Viable v1.0
+
+### Core Modules (Must-Have)
+
+| Module | Description | Status |
+|--------|-------------|--------|
+| **AgentGraph** | Graph data structure + persistence | NEW |
+| **MessageRouter** | Intelligent message routing | NEW (replaces simple TaskRouter) |
+| **ConversationManager** | Multi-turn conversation tracking | NEW |
+| **WorkflowMachine v2** | Extended state machine for graph workflows | UPGRADE |
+| **Broker v2** | Enhanced broker with graph awareness | UPGRADE |
+| **CircuitBreaker** | Agent failure protection | NEW |
+| **HopCounter** | Infinite loop prevention | NEW |
+
+### Extended Modules (Nice-to-Have)
+
+| Module | Description | Status |
+|--------|-------------|--------|
+| **TopologyTemplates** | Pre-built graph templates | NEW |
+| **ReviewConsensus** | Multi-reviewer agreement | NEW |
+| **EscalationPolicy** | Smart failure escalation | NEW |
+| **GraphValidator** | Cycle detection + validation | NEW |
+| **MetricsCollector** | Agent performance metrics | NEW |
+
+### Backward Compatibility
+
+v1.1 CLI commands must still work:
+- `agent-hive init` → creates `.agent-hive/` (v1.0 adds `graph.json`, `conversations/`)
+- `agent-hive detect` → registers runtimes (v1.0 also creates default agent profiles)
+- `agent-hive link` → works as before (v1.0 creates graph edges)
+- `agent-hive task` → works as before (v1.0 auto-selects routing)
+- `agent-hive run` → works as before (v1.0 uses graph routing internally)
+
+### Migration Path
+
+```
+v1.1 state:  .agent-hive/agents.json (with reportsTo)
+               ↓
+v1.0 reads:  Converts reportsTo → graph edges automatically
+               ↓
+v1.0 state:  .agent-hive/graph.json (full graph)
+               .agent-hive/conversations/ (conversation logs)
+```
+
+---
+
+## Architecture Diagram
+
+```
+┌─────────────────────────────────────────────────────────┐
+│                    Agent Hive v1.0                       │
+│                                                         │
+│  ┌──────────┐    ┌──────────────┐    ┌───────────────┐  │
+│  │   CLI    │───▶│   Broker v2  │◀───│  MeshAPI      │  │
+│  └──────────┘    └──────┬───────┘    └───────────────┘  │
+│                         │                               │
+│         ┌───────────────┼───────────────┐               │
+│         ▼               ▼               ▼               │
+│  ┌────────────┐  ┌─────────────┐  ┌──────────────┐     │
+│  │ AgentGraph │  │  Message    │  │ Conversation │     │
+│  │            │  │  Router     │  │ Manager      │     │
+│  └─────┬──────┘  └──────┬──────┘  └──────┬───────┘     │
+│        │                │                │              │
+│        ▼                ▼                ▼              │
+│  ┌─────────────────────────────────────────────┐       │
+│  │           Workflow Machine v2                │       │
+│  │  (xstate: supports multi-agent states)      │       │
+│  └──────────────────────┬──────────────────────┘       │
+│                         │                               │
+│  ┌──────────────────────┼──────────────────────┐       │
+│  │         Adapter Layer (pluggable)            │       │
+│  │                                              │       │
+│  │  ┌─────────┐ ┌─────────┐ ┌───────┐ ┌─────┐ │       │
+│  │  │  Codex  │ │  Claude │ │ Hermes│ │OpenCl│ │       │
+│  │  │ Adapter │ │ Adapter │ │Adapter│ │awAdap│ │       │
+│  │  └─────────┘ └─────────┘ └───────┘ └─────┘ │       │
+│  └──────────────────────────────────────────────┘       │
+│                                                         │
+│  ┌──────────────────────────────────────────────┐       │
+│  │              Safety Layer                     │       │
+│  │  CircuitBreaker │ HopCounter │ Deduplicator  │       │
+│  │  TimeBudget     │ GraphValidator              │       │
+│  └──────────────────────────────────────────────┘       │
+│                                                         │
+│  ┌──────────────────────────────────────────────┐       │
+│  │           Persistence (.agent-hive/)          │       │
+│  │  graph.json │ tasks/ │ conversations/         │       │
+│  │  messages/  │ history/ │ runtimes.json        │       │
+│  └──────────────────────────────────────────────┘       │
+└─────────────────────────────────────────────────────────┘
+```
+
+---
+
+## File Structure (v1.0)
+
+```
+src/
+├── broker/
+│   ├── Broker.ts              # UPGRADED: graph-aware orchestration
+│   ├── AgentRegistry.ts       # UPGRADED: runtime + agent profile separation
+│   ├── TaskRouter.ts          # KEPT for v1.1 compat
+│   ├── MessageBus.ts          # UPGRADED: envelope with metadata
+│   └── MessageRouter.ts       # NEW: intelligent routing
+├── graph/
+│   ├── AgentGraph.ts          # NEW: graph data structure
+│   ├── GraphValidator.ts      # NEW: cycle detection
+│   └── TopologyTemplates.ts   # NEW: pre-built templates
+├── conversation/
+│   ├── ConversationManager.ts # NEW: multi-turn tracking
+│   └── Conversation.ts        # NEW: single conversation model
+├── safety/
+│   ├── CircuitBreaker.ts      # NEW: agent failure protection
+│   ├── HopCounter.ts          # NEW: loop prevention
+│   ├── MessageDeduplicator.ts # NEW: dedup
+│   └── TimeBudget.ts          # NEW: time limits
+├── adapters/
+│   ├── CodexAdapter.ts        # KEPT
+│   ├── ClaudeAdapter.ts       # KEPT
+│   ├── MockCodexAdapter.ts    # KEPT
+│   ├── MockClaudeAdapter.ts   # KEPT
+│   ├── HermesAdapter.ts       # NEW
+│   └── OpenClawAdapter.ts     # NEW (stub)
+├── workflow/
+│   └── WorkflowMachine.ts     # UPGRADED: multi-agent states
+├── commands/
+│   ├── cli.ts                 # UPGRADED: new commands
+│   ├── demo.ts                # KEPT
+│   └── test-*.ts              # KEPT + new tests
+├── types/
+│   └── index.ts               # UPGRADED: new types
+├── utils/
+│   ├── TaskQueue.ts           # KEPT
+│   ├── RevisionHistory.ts     # KEPT
+│   ├── OutputNormalizer.ts    # KEPT
+│   ├── logger.ts              # KEPT
+│   └── uuid.ts                # KEPT
+├── api/
+│   └── MeshAPI.ts             # NEW: programmatic API
+├── prompts/
+│   ├── revision.txt           # KEPT
+│   └── reviewer.txt           # KEPT
+└── config/
+    └── runtime.json           # UPGRADED: multi-runtime config
+```
+
+---
+
+## Implementation Roadmap
+
+### Phase 1: Core Graph (Week 1)
+- [ ] `AgentGraph` data structure + persistence
+- [ ] `MessageRouter` with capability resolution
+- [ ] Enhanced `MessageEnvelope` with metadata
+- [ ] `HopCounter` and `MessageDeduplicator`
+- [ ] v1.1 migration (reportsTo → graph edges)
+
+### Phase 2: Multi-Agent Workflow (Week 2)
+- [ ] `ConversationManager`
+- [ ] `WorkflowMachine` v2 with multi-agent states
+- [ ] `Broker` v2 integration
+- [ ] `CircuitBreaker` and `TimeBudget`
+- [ ] Backward compatibility tests
+
+### Phase 3: Extended Features (Week 3)
+- [ ] `TopologyTemplates`
+- [ ] `GraphValidator` (cycle detection)
+- [ ] `EscalationPolicy`
+- [ ] `ReviewConsensus` (basic)
+- [ ] New CLI commands (`mesh graph`, `mesh route`, `mesh conversation`)
+
+### Phase 4: Polish & Docs (Week 4)
+- [ ] `MeshAPI` surface
+- [ ] `HermesAdapter`, `OpenClawAdapter` stubs
+- [ ] Stress tests for graph workflows
+- [ ] Documentation update
+- [ ] v1.0 release
+
+---
+
+## Decision Log
+
+| # | Decision | Rationale |
+|---|----------|-----------|
+| D1 | Broker remains single center | Architecture principle: all messages through Broker |
+| D2 | Graph is optional (v1.1 still works) | Backward compatibility |
+| D3 | Capability-based routing is default | More flexible than hardcoded links |
+| D4 | Secret Vault → v1.0 | Scope control |
+| D5 | WebUI → v1.0 | Core first, UI later |
+| D6 | xstate stays for workflow | Proven in v1.1, well-typed |
+| D7 | File-based persistence continues | Simple, debuggable, no DB dependency |
+| D8 | Conversation is new primitive | Enables multi-turn, not just execute→review |
+
+---
+
+*End of Architecture Proposal*