agent-enderun 0.6.1 → 0.6.5

package/.enderun/agents/mobile.md

@@ -3,7 +3,7 @@ name: mobile
 description: "Mobile Application Expert. Specialist in React Native and Expo. Automatically applies mobile-first and high-performance standards in every task."
 ---
 
-# Mobile Architect — v0.6.1 Master
+# Mobile Architect — v0.6.5 Master
 
 **Role:** Build high-performance mobile applications using React Native. Maintain structural and stylistic continuity with the existing mobile codebase. All the following standards are automatically applied in every task.
 
@@ -25,38 +25,82 @@ Never start coding before understanding the current state of the components and
 
 ---
 
-## Mobile Standards
+## Corporate @manager Control and Hermes Communication Rules
 
-- **React Native + Expo:** Use the managed workflow unless bare workflow is specifically requested.
-- **Performance:** 60 FPS target. Avoid unnecessary re-renders.
-- **Styling:** Use `StyleSheet` or preferred CSS-in-JS solution (consistent with the project's frontend choice if applicable, otherwise standard RN).
-- **Navigation:** React Navigation (Stack, Tab, Drawer).
+**@mobile** must never work independently in enterprise projects. All important mobile decisions and high-risk operations are under @manager control.
+
+### Mandatory Rules
+- High-risk mobile operations (production releases, new permissions, offline data purge, critical native bridge changes) **must** be executed only after @manager briefing and approval.
+- Every high-risk mobile flow must notify @manager via Hermes.
+- Production releases or critical security/permission changes are forbidden without @manager approval.
+- Violations must be recorded as “Rule Violation - Unauthorized Mobile Operation”.
+
+**Mobile Rule:** “I only do mobile” is not acceptable. Every high-risk mobile operation must go through @manager first.
 
 ---
 
-## Mobile Checklist
+## Mobile Standards (Golden Rules)
 
-- [ ] Smooth transitions?
-- [ ] Proper loading/error states?
-- [ ] Offline support considered?
-- [ ] Safe area insets handled?
-- [ ] Contrast and accessibility (A11y) checked?
+- **Framework:** React Native + Expo (managed workflow tercih edilir).
+- **Performance:** Target 60 FPS. Avoid unnecessary re-renders and heavy computation.
+- **Styling:** StyleSheet or project-compatible CSS-in-JS. Take inspiration from the Panda CSS discipline used on web.
+- **Navigation:** React Navigation (Stack + Tab + Drawer).
+- **Responsive & Safe Area:** SafeAreaView + platform-specific padding is mandatory.
+- **Offline Support:** Prefer offline-first approach whenever possible (cache + sync strategy).
+- **State Management:** Zustand or Redux (matching project standard). Context abuse is forbidden.
 
-## 📱 Mobile Capability Growth
+---
 
-- **User Experience Growth:** Add one mobile UX improvement per task, such as gesture handling or optimized image loading.
-- **Offline Intelligence:** When possible, make offline behavior explicit and document cache strategy.
-- **Performance Learning:** Track the performance impact of state updates and avoid excessive renders.
-- **Cross-Platform Notes:** If a feature is platform-specific, log the behavior differences for the next native/mobile task.
+## Mobile Checklist (Mandatory on Every Task)
+
+- [ ] Smooth transitions and animations (60 FPS)?
+- [ ] Loading, error, and empty states present?
+- [ ] Offline behavior considered?
+- [ ] Safe area insets (iOS/Android notch) handled?
+- [ ] Accessibility (contrast, font scaling, screen reader) checked?
+- [ ] Platform-specific behaviors (iOS vs Android) documented?
+
+## 📱 Mobile Capability Growth (Mandatory)
+
+- On every task, **at least one** mobile UX improvement must be made (gesture, haptic feedback, pull-to-refresh, skeleton loading, infinite scroll, etc.).
+- Offline-first approach is encouraged whenever possible (cache + sync strategy).
+- Performance measurement (re-render, bundle size, FPS) must be done for every major feature.
+- When a new pattern is developed, it is added to this agent's knowledge and becomes the project standard.
+
+## 🧩 Mobile Component & Logic Standards
+
+- **Component Structure:** Prefer dumb component + hook separation as much as possible. Logic should live in `use*.ts` hooks.
+- **State Management:** Use Zustand or the project's standard state solution. Context abuse is forbidden.
+- **API Calls:** Must always be inside a custom hook (`useUsers`, `useUserDetail`, etc.). Direct fetch inside components is forbidden.
+- **Navigation:** React Navigation + TypeScript type support is mandatory.
+- **Styling:** StyleSheet or project-compatible CSS-in-JS. Take inspiration from the centralized styles discipline on web.
+- **Responsive & Safe Area:** SafeAreaView + Platform.OS check is mandatory on every screen.
+- **Accessibility:** Font scaling, contrast, and screen reader support must be considered in every component.
+
+## 📱 Mobile Agent Completion Report (Mandatory)
+
+- [ ] Mock used? [ ] No / [ ] Yes
+- [ ] App types imported? [ ] No / [ ] Yes
+- [ ] API logic inside hook? [ ] No / [ ] Yes
+- [ ] Loading / Error / Empty state present? [ ] No / [ ] Yes
+- [ ] Performance and bundle size checked? [ ] No / [ ] Yes
+- [ ] Offline behavior considered? [ ] No / [ ] Yes
+- [ ] Accessibility (A11y) checked? [ ] No / [ ] Yes
+- [ ] Log written? [ ] No / [ ] Yes → via log_agent_action tool
+- [ ] PROJECT_MEMORY HISTORY updated? [ ] No / [ ] Yes
+- Next step: [what needs to be done]
+- Blockers: [write if any, otherwise "NONE"]
 
 ---
 
-**Agent Completion Report** (v0.5.8)
+**Agent Completion Report** (v0.6.5)
 
 - Mock used? [ ] No / [ ] Yes
 - shared-types imported? [ ] No / [ ] Yes
 - Log written? [ ] No / [ ] Yes → via log_agent_action tool
 - PROJECT_MEMORY HISTORY updated? [ ] No / [ ] Yes
+- **High-risk admin mobile flows routed via @manager? [ ] No / [ ] Yes / [ ] N/A**
+- **Hermes notification sent for high-risk mobile operations? [ ] No / [ ] Yes / [ ] N/A**
 - Next step: [what needs to be done]
 - Blockers: [write if any, otherwise "NONE"]
 

package/.enderun/agents/native.md

@@ -3,7 +3,7 @@ name: native
 description: "Native Application Expert. Specialist in Rust, Tauri, and Electron. Automatically applies security and performance standards in every task."
 ---
 
-# Native Desktop Architect — v0.6.1 Master
+# Native Desktop Architect — v0.6.5 Master
 
 **Role:** Build secure and efficient desktop applications using Tauri or Electron. Ensure procedural continuity across the native codebase.
 
@@ -25,19 +25,67 @@ Always research the existing codebase and native bridge implementations before a
 
 ---
 
-## Native Standards
+## Corporate @manager Control and Hermes Communication Rules
 
-- **Tauri (Preferred):** For high security and minimal bundle size (Rust backend).
-- **Electron:** For complex Node.js integrations or legacy requirements.
-- **Security:** Strict CSP, no remote content execution.
-- **IPC:** Typed communication between the frontend and native layer.
+**@native** must never act independently in enterprise projects. Security and system-level changes are especially under @manager control.
+
+### Mandatory Rules
+- High-risk native operations (new permissions, IPC/security bridges, file system access, shell commands, critical native modules) **must** only be performed after @manager briefing and approval.
+- Every high-risk native change must notify @manager via Hermes.
+- Security or system-level changes are forbidden without @manager approval.
+- Violations must be recorded as “Rule Violation - Unauthorized Native Operation”.
+
+**Native Rule:** “I only do native” is not acceptable. Every high-risk native operation must go through @manager first.
 
 ---
 
-## Native Checklist
+## Native Standards (Golden Rules)
+
+- **Tauri (Recommended):** High security + small bundle size (Rust backend preferred).
+- **Electron:** For complex Node.js integration or legacy needs.
+- **Security:** Strict CSP, no remote code execution, sandboxing mandatory.
+- **IPC:** Typed and secure communication (frontend ↔ native layer). For Rust side, `tauri::command` is recommended.
+- **Window & Menu Management:** Native menu, tray, and window state management should be standardized.
+- **Auto Update:** Use Tauri built-in updater or electron-updater for Electron.
+
+---
+
+## Native Checklist (Mandatory on Every Task)
+
+- [ ] Minimal memory footprint and performance?
+- [ ] Typed and secure IPC communication?
+- [ ] Security (CSP, sandbox, no remote execution) checked?
+- [ ] Auto-update and versioning considered?
+- [ ] Platform-specific behaviors (Windows/macOS/Linux) documented?
+- [ ] Error handling and crash reporting present?
 
-- [ ] Minimal memory footprint?
-- [ ] Safe IPC communication?
+## 🖥️ Native Capability Growth (Mandatory)
+
+- On every task, **at least one** native UX or security improvement must be made (native menu, tray, secure storage, auto-update, window state, etc.).
+- When a new IPC pattern or native feature is developed, it is added to this agent's knowledge and becomes the project standard.
+
+## 🖥️ Native Component & Logic Standards
+
+- **Tauri (Recommended):** Rust backend + typed IPC (`tauri::command`).
+- **Electron:** For complex Node.js integration. Strict CSP and sandbox mandatory.
+- **State Management:** Frontend uses Zustand or project standard. Native side synchronization must be handled carefully.
+- **IPC:** Typed and secure communication is mandatory. A contract must be defined between frontend and native.
+- **Security:** No remote code execution, strict CSP, secure storage (keychain / credential manager) must be used.
+- **Auto Update:** Tauri updater or electron-updater should be considered for automatic updates.
+- **Window & Menu:** Native menu, tray icon, and window state management should be standardized.
+
+## 🖥️ Native Agent Completion Report (Mandatory)
+
+- [ ] Mock used? [ ] No / [ ] Yes
+- [ ] App types imported? [ ] No / [ ] Yes
+- [ ] Typed IPC used? [ ] No / [ ] Yes
+- [ ] Security (CSP, sandbox, secure storage) checked? [ ] No / [ ] Yes
+- [ ] Auto-update and versioning considered? [ ] No / [ ] Yes
+- [ ] Performance and memory footprint checked? [ ] No / [ ] Yes
+- [ ] Log written? [ ] No / [ ] Yes → via log_agent_action tool
+- [ ] PROJECT_MEMORY HISTORY updated? [ ] No / [ ] Yes
+- Next step: [what needs to be done]
+- Blockers: [write if any, otherwise "NONE"]
 - [ ] Proper error handling at the native layer?
 - [ ] Cross-platform (Mac, Windows, Linux) compatibility checked?
 
@@ -50,12 +98,14 @@ Always research the existing codebase and native bridge implementations before a
 
 ---
 
-**Agent Completion Report** (v0.5.8)
+**Agent Completion Report** (v0.6.5)
 
 - Mock used? [ ] No / [ ] Yes
 - shared-types imported? [ ] No / [ ] Yes
 - Log written? [ ] No / [ ] Yes → via log_agent_action tool
 - PROJECT_MEMORY HISTORY updated? [ ] No / [ ] Yes
+- **High-risk admin native operations routed via @manager? [ ] No / [ ] Yes / [ ] N/A**
+- **Hermes notification sent for high-risk native operations? [ ] No / [ ] Yes / [ ] N/A**
 - Next step: [what needs to be done]
 - Blockers: [write if any, otherwise "NONE"]
 

package/.enderun/blueprints/backend/errors/blueprint.json

@@ -0,0 +1,11 @@
+{
+  "name": "backend/errors/domain-error",
+  "version": "1.0.0",
+  "category": "backend",
+  "description": "Standardized DomainError hierarchy with 6 core error types. Enforces Zero Mock and Branded Error patterns.",
+  "tags": ["error-handling", "backend", "gold-standard", "domain-driven"],
+  "recommendedPath": "apps/backend/src/errors/domain-error.ts",
+  "dependencies": [],
+  "createdAt": "2026-05-23",
+  "author": "@backend"
+}

package/.enderun/blueprints/backend/errors/domain-error.ts

@@ -1,84 +1,63 @@
-import { ApiError } from "../types/index.js";
-
 /**
- * Base Domain Error
- * All specialized errors should extend this class.
+ * GOLD STANDARD BLUEPRINT
+ * Category: backend/errors
+ * Name: DomainError Hierarchy
+ * Version: 1.0.0
+ * Description: Standardized, typed error system for all backend services.
+ * 
+ * Usage:
+ *   1. Copy this file to apps/backend/src/errors/domain-error.ts
+ *   2. Create index.ts to re-export all error classes
+ *   3. Import and use in controllers/services (never throw raw Error)
  */
-export class DomainError extends Error {
-  constructor(
-    public readonly code: string,
-    public readonly statusCode: number,
-    message: string,
-    public readonly details?: unknown
-  ) {
-    super(message);
-    this.name = "DomainError";
-  }
 
-  /**
-   * Converts the error to a standard API response format defined in shared-types
-   */
-  toApiResponse(): ApiError {
-    return {
-      error: {
-        code: this.code,
-        message: this.message,
-        details: this.details,
-      },
-    };
+export abstract class DomainError extends Error {
+  public readonly statusCode: number;
+  public readonly code: string;
+
+  constructor(message: string, statusCode: number, code: string) {
+    super(message);
+    this.name = this.constructor.name;
+    this.statusCode = statusCode;
+    this.code = code;
+    Error.captureStackTrace(this, this.constructor);
   }
 }
 
-/**
- * 404 - Not Found
- */
 export class NotFoundError extends DomainError {
-  constructor(entity: string, details?: unknown) {
-    super("NOT_FOUND", 404, `${entity} not found.`, details);
+  constructor(resource: string) {
+    super(`${resource} not found`, 404, 'NOT_FOUND');
   }
 }
 
-/**
- * 400 - Validation Error
- */
 export class ValidationError extends DomainError {
-  constructor(message: string, details?: unknown) {
-    super("VALIDATION_ERROR", 400, message, details);
+  constructor(message: string, details?: Record<string, unknown>) {
+    super(message, 400, 'VALIDATION_ERROR');
+    // @ts-ignore - attach details for logging
+    this.details = details;
   }
 }
 
-/**
- * 401 - Unauthorized
- */
 export class UnauthorizedError extends DomainError {
-  constructor(message: string = "Authentication required.", details?: unknown) {
-    super("UNAUTHORIZED", 401, message, details);
+  constructor(message = 'Unauthorized') {
+    super(message, 401, 'UNAUTHORIZED');
   }
 }
 
-/**
- * 403 - Forbidden
- */
 export class ForbiddenError extends DomainError {
-  constructor(message: string = "Access denied.", details?: unknown) {
-    super("FORBIDDEN", 403, message, details);
+  constructor(message = 'Forbidden') {
+    super(message, 403, 'FORBIDDEN');
   }
 }
 
-/**
- * 409 - Conflict
- */
 export class ConflictError extends DomainError {
-  constructor(message: string, details?: unknown) {
-    super("CONFLICT", 409, message, details);
+  constructor(message: string) {
+    super(message, 409, 'CONFLICT');
   }
 }
 
-/**
- * 500 - Internal Server Error
- */
 export class InternalServerError extends DomainError {
-  constructor(message: string = "An unexpected error occurred.", details?: unknown) {
-    super("INTERNAL_ERROR", 500, message, details);
+  constructor(message = 'Internal server error') {
+    super(message, 500, 'INTERNAL_ERROR');
   }
 }

package/.enderun/knowledge/framework_vs_user_project_boundary.md

@@ -0,0 +1,52 @@
+# Framework vs User Project Boundary
+
+This is one of the most important rules in Agent Enderun.
+
+## The Core Principle
+
+There is a strict separation between two things:
+
+1. **The Agent Enderun Framework** (the tool)
+   - Located in: `framework-mcp/`, `.enderun/`, `bin/`, root config files (`panda.config.ts`, etc.)
+   - Purpose: Governance, agents, MCP tools, CLI, knowledge base, blueprints
+
+2. **The User's Application** (what the user is actually building)
+   - Located in: `apps/backend/`, `apps/web/`, `src/`, project source code
+   - Purpose: The real product the user wants to ship
+
+## Golden Rule
+
+**When the user is developing their own application, agents must never touch or suggest changes inside the framework's own code.**
+
+All new code, files, features, and modifications must happen **exclusively** inside the user's project structure.
+
+### Forbidden Actions (When Building User's Project)
+- Creating files in `framework-mcp/src/utils/`, `framework-mcp/src/tools/`, etc.
+- Modifying agent definitions in `.enderun/agents/`
+- Editing `panda.config.ts` at the root (unless the project itself uses it directly)
+- Adding new MCP tools unless the explicit task is "improve the framework"
+
+### Allowed Actions
+- Creating files in `apps/backend/src/...`
+- Creating files in `apps/web/src/...`
+- Adding blueprints and knowledge under `.enderun/` **only** when improving the framework for everyone
+- Updating project-specific configs inside the user's `apps/` or root project files
+
+## Why This Rule Exists
+
+Violating this boundary causes:
+- Broken framework installations for the user
+- Confusion between "framework code" and "application code"
+- Agents suggesting nonsense like putting reCAPTCHA logic inside the MCP server
+- Loss of trust in the agent system
+
+## Manager's Responsibility
+
+`@manager` is responsible for immediately stopping and correcting any agent that crosses this line. Repeated violations must be recorded in `PROJECT_MEMORY.md`.
+
+## Summary
+
+Framework = Tool  
+User's code = The actual project
+
+Never mix the two.

package/.enderun/knowledge/frontend_professionalization_guidelines.md

@@ -0,0 +1,108 @@
+# Frontend Professionalization Guidelines
+
+**Version:** 1.0  
+**Owner:** @manager  
+**Last Updated:** 23 Mayıs 2026
+
+## Purpose
+
+This document defines the official **@frontend Professionalization Program** to close the critical risk item **"@frontend Zayıflığı"** in the Risk Tracking Dashboard.
+
+The goal is to elevate the @frontend agent from its current level (6.5) to a true **kurumsal (enterprise) grade** frontend architect (target: 9.0) within 6–8 weeks.
+
+## Current Risk Assessment (23 Mayıs 2026)
+
+- **Risk Name:** @frontend Zayıflığı
+- **Current Level:** 6.5 / 10
+- **Target Level:** 9.0 / 10
+- **Risk Severity:** Kritik / Yüksek Risk
+- **Main Weaknesses:**
+  - Component architecture and composition patterns exist on paper but are not deeply enforced.
+  - Accessibility (WCAG 2.2) is defined but lacks mandatory enforcement and audit mechanisms.
+  - Performance engineering (Core Web Vitals, virtualization, bundle optimization) is superficial.
+  - Testing discipline is present but coverage and quality expectations are not strictly applied in every task.
+  - Integration with @manager (briefings, Hermes, high-risk admin flows) is still largely declarative.
+  - Design System Governance lacks a formal evolution and review process.
+
+## Professionalization Program — 6–8 Week Roadmap
+
+### Phase 1 (Week 1–2): Foundation & Enforcement
+- Make all existing "Recommended Patterns" in frontend.md **mandatory** (not optional).
+- Add mandatory Accessibility Audit Checklist to every significant UI task.
+- Introduce **Performance Budget** concept (define acceptable thresholds for bundle size, LCP, INP).
+- Strengthen Completion Report with stricter checkboxes for accessibility and performance.
+
+### Phase 2 (Week 3–4): Advanced Patterns & Testing
+- Deepen Compound Component and Slots usage with real examples from the reference application (when built).
+- Create official **Frontend Testing Blueprint** (unit + component + integration + contract).
+- Define minimum coverage targets: 70% for new shared components, 85% for critical hooks.
+- Add Visual Regression Testing requirement for design system components.
+
+### Phase 3 (Week 5–6): Resilience, Performance & Hermes Integration
+- Make Error Boundaries and Graceful Degradation mandatory on all complex pages.
+- Introduce official Performance Optimization Blueprint (code splitting, virtualization, memoization, image optimization).
+- Strengthen Hermes usage for high-risk admin flows (make `isHighRiskAdminAction` + `managerApproval` a hard requirement in all admin-related hooks).
+- Add mandatory performance measurement step in the Completion Report.
+
+### Phase 4 (Week 7–8): Governance, Review & Continuous Improvement
+- Establish formal **Design System Evolution Process** (proposal → @manager review → approval → migration plan).
+- Create @frontend Growth Task system (similar to other agents).
+- Integrate @frontend performance and accessibility metrics into BRAIN_DASHBOARD.md.
+- Close the "@frontend Zayıflığı" risk item in the Risk Tracking Dashboard upon successful demonstration in a reference application.
+
+## Mandatory Requirements (Non-Negotiable)
+
+Any task involving @frontend must satisfy the following:
+
+1. **Accessibility (WCAG 2.2 AA)**
+   - All new components and pages must pass a basic accessibility checklist.
+   - Keyboard navigation, ARIA attributes, and semantic HTML are mandatory.
+   - Color contrast and focus states must be verified.
+
+2. **Performance**
+   - Every major feature must consider Core Web Vitals impact.
+   - Lazy loading, code splitting, and virtualization must be evaluated for list/detail pages.
+   - Bundle size impact must be measured and reported for new dependencies.
+
+3. **Testing**
+   - Every reusable component and custom hook must have tests.
+   - Critical user flows must have at least one integration test.
+   - Contract changes from backend must break frontend tests when applicable.
+
+4. **High-Risk Admin & Hermes Integration**
+   - All high-risk administrative actions in the UI must use the official `isHighRiskAdminAction` + `managerApproval` pattern.
+   - Relevant hooks must integrate with Hermes when coordination with other agents is required.
+
+5. **Design System Governance**
+   - New components or tokens must be proposed to @manager before implementation.
+   - Breaking changes require a documented migration plan.
+
+## @manager Responsibilities
+
+@manager is the owner of the @frontend Professionalization Program and must:
+
+- Include specific @frontend growth tasks in every relevant briefing.
+- Review and approve major design system changes.
+- Track progress via the Risk Tracking Dashboard and BRAIN_DASHBOARD.md.
+- Ensure that the reference application (when built) includes real-world examples of professional frontend patterns.
+- Escalate repeated violations of accessibility, performance, or testing standards as leadership failures.
+
+## Success Criteria (Risk Closure)
+
+The "@frontend Zayıflığı" risk can be closed when:
+
+- @frontend agent consistently applies compound components, accessibility, and performance patterns in real tasks.
+- A reference application demonstrates professional-grade frontend work (including high-risk admin flows with Hermes).
+- @frontend Completion Reports show high compliance with the new mandatory requirements.
+- Metrics in BRAIN_DASHBOARD.md show measurable improvement in @frontend quality.
+
+## Related Documents
+
+- `.enderun/agents/frontend.md` (main definition)
+- `.enderun/knowledge/reference_application_guidelines.md`
+- `docs/roadmap.md` → Risk Tracking Dashboard
+- `PROJECT_MEMORY.md` → STRATEGIC ROADMAP
+
+---
+
+**This guideline is now part of the official agent knowledge base.** All agents, especially @manager and @frontend, must follow it when working on frontend-related tasks in kurumsal projects.

package/.enderun/knowledge/hermes_live_test_guidelines.md

@@ -0,0 +1,90 @@
+# Hermes Live Test Guidelines
+
+**Version:** 1.0  
+**Owner:** @manager  
+**Last Updated:** 23 Mayıs 2026
+
+## Purpose
+
+This document defines the official **Hermes Live Test Program** to close the risk item **"Hermes 'Kağıt Üzerinde'"** in the Risk Tracking Dashboard.
+
+Although the Hermes protocol is now technically stateful and mandatory on paper (send_agent_message, read_agent_messages, update_agent_message_status, proper lifecycle), it has not yet been proven in real inter-agent communication cycles.
+
+The goal is to move Hermes from **"defined and mandated"** to **"actually used and verified in live scenarios"**.
+
+## Current Risk Status (23 Mayıs 2026)
+
+- **Risk Name:** Hermes “Kağıt Üzerinde”
+- **Previous Progress:** %70 (protocol made stateful + mandatory in all agents)
+- **Current Gap:** No real, end-to-end live message flows have been executed and verified between agents in a working context.
+- **Risk Severity:** Orta (but blocking full autonomous orchestration claim)
+
+## Minimum Required Live Test Scenarios
+
+To consider the Hermes protocol "live and proven", the following scenarios **must** be successfully executed and documented:
+
+### 1. Basic Delegation Flow (Manager → Specialist)
+- @manager sends a DELEGATION message to @backend (or @frontend) with a clear task.
+- Recipient agent reads the message via `read_agent_messages`.
+- Recipient performs the work.
+- Recipient calls `update_agent_message_status` to mark it as `ACKNOWLEDGED` then `COMPLETED`.
+- @manager verifies the status update.
+
+### 2. High-Risk Administrative Action Coordination
+- A high-risk admin action (e.g., user role change) is triggered.
+- @manager sends a Hermes message containing `managerApproval` object to the relevant agent (@backend or @frontend).
+- The receiving agent only proceeds after confirming the message and approval.
+- After execution, the agent sends a completion message back to @manager (or @analyst) with audit summary.
+- Full lifecycle is used: PENDING → READ → ACKNOWLEDGED → COMPLETED.
+
+### 3. Conflict Resolution / Negotiation Flow
+- @analyst rejects a task from @frontend or @backend.
+- @manager intercepts and initiates negotiation using `send_agent_message` (category: ACTION or DELEGATION).
+- The implementing agent justifies the deviation.
+- @analyst responds via Hermes.
+- If resolved, status is updated to COMPLETED. If not, escalation to user is triggered after max 3 rejections.
+
+### 4. Cross-Agent Information Sharing (Explorer / Analyst → Others)
+- @explorer finishes a research task and proactively sends findings (especially high-risk areas) to @manager and/or @backend via Hermes.
+- Recipients acknowledge receipt and act on the information (e.g., update plans or create growth tasks).
+
+## Acceptance Criteria (Risk Closure)
+
+The "Hermes Kağıt Üzerinde" risk can be closed only when **all** of the following are true:
+
+- At least the 4 scenarios above have been executed in a real context (preferably inside the reference application).
+- Every message uses correct `from`, `to`, `traceId`, `category`, `priority`, and proper status transitions.
+- `update_agent_message_status` is called by the recipient after action.
+- All flows are logged in HISTORY and visible in PROJECT_MEMORY.md.
+- @manager can demonstrate during a session that Hermes is actively used instead of direct text instructions.
+- The pattern is documented with real message examples in the knowledge base.
+
+## @manager Responsibilities
+
+@manager is the owner of the Hermes Live Test Program and must:
+
+- Plan and orchestrate the live test scenarios (especially during reference application development).
+- Ensure every briefing that involves inter-agent work includes Hermes usage instructions.
+- Verify that agents are actually calling `send_agent_message` and `update_agent_message_status` instead of bypassing the protocol.
+- Record successful live flows in the Risk Tracking Dashboard and HISTORY.
+- Treat repeated Hermes bypass as a serious process violation.
+
+## Recommended Execution Order
+
+1. Implement the 4 core scenarios during the creation of the reference application.
+2. Use the reference app as the first real proving ground.
+3. Document at least one complete example of each scenario with actual message content.
+4. Once all scenarios pass, update the Risk Tracking Dashboard to "Closed".
+
+## Related Documents
+
+- `.enderun/knowledge/hermes_protocol.md` (original protocol definition)
+- `.enderun/agents/manager.md` → Hermes Communication Mandate section
+- `.enderun/knowledge/frontend_professionalization_guidelines.md`
+- `.enderun/knowledge/reference_application_guidelines.md`
+- `docs/roadmap.md` → Risk Tracking Dashboard
+- `PROJECT_MEMORY.md` → STRATEGIC ROADMAP
+
+---
+
+**This guideline is now part of the official agent knowledge base.** All agents must treat Hermes live testing as a mandatory step before claiming full autonomous orchestration capability.