agent-enderun 1.1.1 → 1.1.3

package/.enderun/knowledge/manager_authority_audit_enforcement.md

@@ -1,104 +0,0 @@
-# Manager Authority Audit & Enforcement Guidelines
-
-**Version:** 1.0  
-**Owner:** @manager  
-**Last Updated:** 23 May 2026
-
-## Purpose
-
-This document establishes a formal **Manager Authority Audit & Enforcement System** to ensure that @manager maintains unbreakable centralized control over all specialist agents in kurumsal (enterprise) projects.
-
-Even though strong rules exist in individual agent files, without a systematic audit and enforcement mechanism, control can degrade over time. This guide turns @manager authority from "declared on paper" into "auditable and enforceable in practice."
-
-## Why This Is Necessary
-
-From the agent control audit (23 May 2026):
-
-- @backend, @frontend, @analyst, and @explorer have partial governance rules, but enforcement is inconsistent.
-- @git, @mobile, and @native have almost no @manager control defined.
-- Hermes usage and High-Risk Admin compliance are still largely declarative in many agents.
-- Memory Discipline and briefing requirements are frequently bypassed in practice.
-
-Without regular auditing and clear enforcement, the "Single Point of Authority" and "Zero Tolerance" principles lose effectiveness.
-
-## Core Principles
-
-1. **@manager is the Single Source of Authority** — No specialist agent may act on user requests, high-risk operations, or cross-agent coordination without explicit @manager briefing and oversight.
-2. **Audit Before Trust** — @manager must periodically verify that every agent is actually following the authority rules, not just claiming to follow them.
-3. **Zero Tolerance for Bypass** — Any detected bypass (direct agent addressing, Hermes bypass, unauthorized high-risk actions, skipped briefings) must be logged as a Rule Violation and corrected immediately.
-4. **Enforcement is @manager’s Responsibility** — Other agents do not self-police @manager authority. Only @manager can audit and enforce.
-
-## Manager Authority Audit Checklist (Mandatory Every 1–2 Weeks)
-
-@manager must run this audit regularly and record results in `PROJECT_MEMORY.md` under a dedicated section.
-
-### 1. Entry Point Control
-- [ ] Did every user message in the last period first go through @manager?
-- [ ] Were there any cases where a specialist agent responded directly without briefing?
-- [ ] Were direct calls to @backend / @frontend / @analyst etc. immediately intercepted?
-
-### 2. Hermes Protocol Compliance
-- [ ] Are all inter-agent communications using `send_agent_message` + proper `from`/`to`/`traceId`?
-- [ ] Are recipients consistently calling `update_agent_message_status` after acting?
-- [ ] Are there any cases of agents giving instructions to each other without Hermes?
-
-### 3. High-Risk Administrative Actions
-- [ ] Were all high-risk operations (user/permission management, purge, system config, RBAC, etc.) preceded by explicit @manager briefing and `managerApproval`?
-- [ ] Was the full audit trail (previousState + newState + Trace ID + actor) written?
-
-### 4. Memory & Logging Discipline
-- [ ] Did every agent call both `update_project_memory` and `log_agent_action` at the end of their sessions?
-- [ ] Did @manager perform the Memory Audit responsibility for other agents?
-
-### 5. Briefing Quality & Enforcement
-- [ ] Did every task distributed by @manager include clear risk assessment, continuity requirements, and success criteria?
-- [ ] Were growth tasks assigned to agents showing repeated weaknesses?
-
-### 6. Agent-Specific Control Gaps
-- [ ] @backend: High-risk endpoints and Hermes usage verified?
-- [ ] @frontend: High-risk admin UI patterns + Hermes integration verified?
-- [ ] @analyst: QA gate enforcement and escalation to @manager verified?
-- [ ] @explorer: Proactive risk reporting via Hermes verified?
-- [ ] @git: High-risk commits only with @manager approval?
-- [ ] @mobile / @native: Any work done without @manager briefing?
-
-## Enforcement Mechanisms
-
-When a violation is detected, @manager must apply the following in order:
-
-1. **Immediate Correction** — Stop the violating action and redirect through proper channels.
-2. **Violation Logging** — Record in `PROJECT_MEMORY.md` HISTORY as:
-   - “Rule Violation - [Type]” (e.g., “Hermes Bypass”, “Unauthorized High-Risk Action”, “Direct Agent Response”)
-3. **Agent Coaching** — Assign a targeted growth task to the violating agent.
-4. **Escalation (if repeated)** — Temporarily restrict the agent’s scope or require stricter briefings.
-5. **User Notification** (only when necessary) — Inform the user that a process violation occurred and was corrected.
-
-## Integration with Risk Tracking Dashboard
-
-This authority system directly supports the closure of multiple risks:
-
-- Lack of Reference Application
-- @frontend Weakness
-- Hermes “On Paper”
-- Lack of Real-world Usage
-
-Every time a reference application or major task is executed, @manager must run an Authority Audit and record findings.
-
-## Recommended Cadence
-
-- **Light Audit**: Every session (quick mental check + log if violation seen)
-- **Full Authority Audit**: At least once per week or at the end of every major phase/task
-- **Deep Audit**: Before closing any risk item in the Risk Tracking Dashboard
-
-## Related Documents
-
-- `.enderun/agents/manager.md` → Mandatory @manager Behavioral Rules for Enterprise Projects + Hermes Communication Mandate
-- `.enderun/knowledge/hermes_live_test_guidelines.md`
-- `.enderun/knowledge/frontend_professionalization_guidelines.md`
-- `.enderun/knowledge/reference_application_guidelines.md`
-- `docs/roadmap.md` → Risk Tracking Dashboard
-- `PROJECT_MEMORY.md` → STRATEGIC ROADMAP + HISTORY
-
----
-
-**This guideline is now part of the official agent knowledge base.** @manager must treat Authority Auditing and Enforcement as a core leadership responsibility, not an optional activity.

package/.enderun/knowledge/manager_reference_guide.md

@@ -1,55 +0,0 @@
-# @manager — Governance & Orchestration Reference Guide
-
-This guide contains detailed governance protocols, phase transition requirements, and conflict resolution strategies for Agent Enderun projects. Reference this file when planning architectures, managing multi-agent workflows, or auditing project progress.
-
----
-
-## 👑 BRAIN ORCHESTRATION (Memory-First)
-- **Master SSOT:** Refer to `PROJECT_MEMORY.md` in every session.
-- **Critical Decisions:** Check the `CRITICAL DECISIONS` table before any orchestration.
-- **Procedural Continuity:** Ensure all assigned tasks mandate agents to follow existing code patterns.
-
----
-
-## 🪖 v1.0 AGENT ARMY ORCHESTRATION HANDOFF PROTOCOL
-1. Write the high-level plan + Trace ID into `PROJECT_MEMORY.md`.
-2. Call `create_task_dag` with breakdown, domain tags, and priorities.
-3. Use `assign_agent_to_task` (capability-aware assignment).
-4. Send formal Hermes briefing: "Execute DAG for Trace {{traceId}}."
-5. Monitor via `get_army_health_dashboard` and `read_agent_messages`.
-
----
-
-## 🔁 AUTONOMOUS CONFLICT RESOLUTION PROTOCOL
-1. **Intercept:** @manager intercepts failures (e.g., @quality rejection).
-2. **Negotiate:** Instruct agents to negotiate via `send_agent_message`.
-3. **Review:** @quality evaluates justifications.
-4. **Escalate:** If negotiation fails 3 times, log "QA Deadlock" and ask the User.
-
----
-
-## Phase Gate Checklist (Summary)
-
-### PHASE_0 → PHASE_1 (Scaffolding)
-- [ ] `tech-stack.md` approved.
-- [ ] Profile selected (Lightweight vs Full).
-
-### PHASE_1 → PHASE_2 (Architecture)
-- [ ] `shared-types` approved.
-- [ ] `contract.version.json` created and hash verified.
-
-### PHASE_2 → PHASE_3 (Implementation)
-- [ ] Core features delivered with unit tests.
-- [ ] Procedural Continuity verified.
-
-### PHASE_3 → PHASE_4 (Quality)
-- [ ] Integration tests passed with real DB.
-- [ ] Zero Mock and Zero UI Library policies verified.
-
----
-
-## 🕵️ Governance & Audit Oversight
-- **Branded Types Law:** Strictly enforce across all domain logic.
-- **Domain Error Standard:** Ensure all agents use the standardized hierarchy.
-- **Memory Audit:** Verify all agents performed end-of-turn memory updates.
-- **Root Cause Analysis:** For rejections, update `lessons-learned.md`.

package/.enderun/knowledge/mobile_reference_guide.md

@@ -1,35 +0,0 @@
-# @mobile — Cross-Platform Mobile Reference Guide
-
-Detailed mobile standards, UX guidelines, and component patterns for React Native/Expo. Reference this file when building screens or complex mobile logic.
-
----
-
-## 📱 Mobile Standards (Golden Rules)
-- **Framework:** React Native + Expo (managed workflow).
-- **Performance:** Target 60 FPS. Avoid unnecessary re-renders.
-- **Styling:** StyleSheet or Panda-inspired CSS-in-JS.
-- **Navigation:** React Navigation (Stack + Tab + Drawer).
-- **Safe Area:** SafeAreaView is mandatory on every screen.
-
----
-
-## 🏗️ Standard Mobile Patterns
-- **API Calls:** Use custom hooks (`useUsers`, etc.). No direct fetch in components.
-- **State:** Zustand or project standard.
-- **Logic:** Separation of UI (component) and Logic (custom hook).
-
----
-
-## ✅ Mobile Checklist (Mandatory)
-- [ ] Smooth transitions (60 FPS)?
-- [ ] Loading, error, and empty states present?
-- [ ] Offline behavior considered?
-- [ ] Accessibility (contrast, font scaling) checked?
-- [ ] Platform-specific (iOS/Android) behaviors handled?
-
----
-
-## 📱 Mobile Capability Growth
-- Add at least one UX improvement (haptic, gesture, skeleton) per task.
-- Measure and record FPS and bundle size for major features.
-- Build components as atomic and reusable units.

package/.enderun/knowledge/native_reference_guide.md

@@ -1,34 +0,0 @@
-# @native — Native Desktop Reference Guide
-
-Detailed native standards, security hardening, and IPC protocols for Tauri/Electron. Reference this file when building native features or bridge logic.
-
----
-
-## 🖥️ Native Standards (Golden Rules)
-- **Tauri (Recommended):** Rust backend + typed IPC (`tauri::command`).
-- **Electron:** Strict CSP and sandbox mandatory.
-- **Security:** No remote code execution. Secure storage (Keychain) mandatory.
-- **Auto Update:** Use Tauri updater or electron-updater.
-
----
-
-## 🏗️ Native Component & Logic Standards
-- **IPC:** Typed and secure communication contract between frontend and native.
-- **Window Management:** Standardized native menu, tray icon, and window state.
-- **Performance:** Minimal memory footprint is a priority.
-
----
-
-## ✅ Native Checklist (Mandatory)
-- [ ] Typed and secure IPC used?
-- [ ] Security (CSP, sandbox) checked?
-- [ ] Auto-update and versioning considered?
-- [ ] Platform-specific (Mac/Win/Linux) behaviors handled?
-- [ ] Error handling at native layer present?
-
----
-
-## 🧩 Native Capability Growth
-- Add at least one security hardening or native UX feature per task.
-- Document platform-specific constraints in PROJECT_MEMORY.
-- Measure and record native bridge performance.

package/.enderun/knowledge/project_scaffold_guidelines.md

@@ -1,110 +0,0 @@
-**📌 Low-Usage Reference Material**
-
-This file is maintained as reference-only for the 12-agent army.
-
-Per `.enderun/knowledge/token_economy_and_memory.md`:
-- Load on-demand only when relevant for scaffolding SOPs, reference apps, or Phase 1/2 planning.
-- Prefer search or targeted reads over full inclusion in every context.
-- Not core to CLI runtime, init scaffolding, or mandatory every-session knowledge.
-
----
-
-# Project Scaffold Guidelines
-
-**Version:** 1.0  
-**Owner:** @manager  
-**Last Updated:** 23 May 2026
-
-## Purpose
-
-This document defines the official process and standards for **creating a project scaffold** (initial folder and file structure) inside the `apps/` directory.
-
-The goal is to move from "empty `apps/` folder" to a **minimal but meaningful project structure** that demonstrates Agent Enderun’s core principles in practice.
-
-## When to Create a Project Scaffold
-
-@manager should initiate a project scaffold in the following cases:
-
-- The Risk Tracking Dashboard shows **"Lack of Reference Application"** as a top-priority open risk.
-- The team needs a concrete starting point to validate governance rules (especially Corporate CRUD Governance and Hermes).
-- A new major capability needs to be proven before being used in client projects.
-- During the early stages of Phase 1 or Phase 2 when moving from theory to real implementation.
-
-## Minimum Required Structure (Mandatory)
-
-Any project scaffold created with Agent Enderun **must** include at least the following:
-
-### Backend Structure (`apps/backend/`)
-- `src/types/` → Branded types, models, API types
-- `src/controllers/`
-- `src/services/`
-- `src/repositories/`
-- `src/routes/`
-- `src/errors/` → DomainError hierarchy
-- `src/utils/`
-- `package.json`, `tsconfig.json`
-
-### Frontend Structure (`apps/web/`)
-- `src/types/`
-- `src/hooks/` → useListPage, useDetailPage, useFormPage, admin action hooks
-- `src/components/ui/` → Shared components
-- `src/pages/`
-- `src/utils/`
-- `package.json`, `tsconfig.json`, `vite.config.ts`
-
-### Mandatory Principles to Demonstrate
-1. **Contract-First** — Types defined first in `src/types/`
-2. **Branded Types** — All IDs must be branded (e.g. `UserID`)
-3. **Normal CRUD** — At least one entity with full create/read/update/delete
-4. **One High-Risk Administrative Action** — Example: user role change with `managerApproval` + full audit
-5. **Hermes Protocol Usage** — At least one real inter-agent message flow
-6. **Audit Logging** — Every mutation must produce before/after state with Trace ID
-
-## @manager Responsibilities
-
-- Decide when a project scaffold is needed based on the Risk Tracking Dashboard.
-- Create a formal briefing that defines the scope of the scaffold.
-- Ensure the structure follows the guidelines in this document.
-- Assign clear responsibilities to @backend and @frontend.
-- After the scaffold is created, run an **Authority Audit** to verify compliance.
-- Update the Risk Tracking Dashboard and `PROJECT_MEMORY.md` when the scaffold is accepted.
-
-## Agent Responsibilities During Scaffolding
-
-| Agent     | Responsibility |
-|-----------|----------------|
-| **@manager** | Owns the process, creates briefing, ensures governance |
-| **@backend** | Creates backend structure + at least 1 normal CRUD + 1 high-risk admin endpoint |
-| **@frontend** | Creates frontend structure using official blueprints + high-risk admin UI pattern |
-| **@analyst** | Reviews the scaffold for governance compliance |
-| **@explorer** | Can be used for dependency analysis if the structure grows |
-
-## Rules
-
-- Never create a project scaffold without an explicit @manager briefing.
-- The scaffold must respect the **Framework vs User Project Boundary** (only work inside `apps/`).
-- The scaffold is **temporary and educational** — it is meant to prove concepts, not to become a full product.
-- All high-risk operations in the scaffold must follow the `managerApproval` + Hermes + audit pattern.
-- After successful completion, update the Risk Tracking Dashboard to reflect progress on "Lack of Reference Application".
-
-## Success Criteria
-
-A project scaffold is considered successful when:
-
-- The minimum folder structure (backend + web) is created.
-- At least one normal CRUD flow and one high-risk admin operation exist.
-- Hermes is used in at least one real message flow.
-- The structure follows Contract-First + Branded Types.
-- An Authority Audit has been performed and recorded.
-
-## Related Documents
-
-- `.enderun/knowledge/reference_application_guidelines.md`
-- `.enderun/knowledge/frontend_professionalization_guidelines.md`
-- `.enderun/knowledge/hermes_live_test_guidelines.md`
-- `.enderun/knowledge/manager_authority_audit_enforcement.md`
-- `docs/roadmap.md` → Risk Tracking Dashboard
-
----
-
-**This guideline is now part of the official agent knowledge base.** All agents must follow it when the creation of a project scaffold or reference application is discussed.

package/.enderun/knowledge/quality_reference_guide.md

@@ -1,42 +0,0 @@
-# @quality — Unified Quality & Security Reference Guide
-
-Detailed QA protocols, security auditing standards, and compliance checklists. Reference this file during phase transitions, code reviews, and security audits.
-
----
-
-## 🔍 QA & Audit Protocols
-
-### 1. API Contract Audit (Mandatory Gate)
-- Run `verify_contract_integrity` to check for hash mismatches.
-- Verify modular type imports.
-
-### 2. Procedural Continuity Audit
-- Use `analyze_procedural_continuity` to enforce Branded Types and Domain Errors.
-
-### 3. Security Auditing
-- Run `security_audit_scan` (secrets, raw SQL).
-- Run `analyze_constitution_compliance` (No `any`, Zero Mock).
-- Categorize findings: CRITICAL, HIGH, MEDIUM, LOW.
-
----
-
-## 📋 Code Review Checklist (Mandatory)
-- [ ] **Constitution:** Does the code follow all mandates?
-- [ ] **Contract:** Are types imported from the app's local types directory?
-- [ ] **DB Integrity:** No Raw SQL usage? (Kysely only).
-- [ ] **Test Integrity:** Are unit/integration tests included?
-- [ ] **UI Standards:** Is it mobile-first with zero native dialogs?
-
----
-
-## 🧪 Testing Standards (Mandatory)
-1. **Unit Tests:** Mandatory for all business logic and services.
-2. **Integration Tests:** Required for API endpoints (Zero Mock Policy).
-3. **Coverage Target:** Aim for >80% coverage in core packages.
-
----
-
-## 🛡️ Security Scanning Standards
-1. **No Raw SQL:** Prevent SQL injection via Kysely.
-2. **Secrets:** No hardcoded credentials.
-3. **Audit:** Run `agent-enderun check:security` before finalization.

package/.enderun/knowledge/reference_application_guidelines.md

@@ -1,101 +0,0 @@
-**📌 Low-Usage Reference Material**
-
-This file is maintained as reference-only for the 12-agent army.
-
-Per `.enderun/knowledge/token_economy_and_memory.md`:
-- Load on-demand only when relevant for reference app guidelines or corporate scaffolding examples.
-- Prefer search or targeted reads over full inclusion in every context.
-- Not core to CLI runtime, init scaffolding, or mandatory every-session knowledge.
-
----
-
-# Reference Application Guidelines
-
-**Version:** 1.0  
-**Owner:** @manager  
-**Last Updated:** 23 May 2026
-
-## Purpose
-
-This document defines the official process and standards for creating a **Reference Application** (also called "showcase" or "demo app") inside the `apps/` directory.
-
-The goal of a reference application is to **prove** that Agent Enderun’s governance, patterns, and tools actually work in a real project — not just on paper.
-
-## When to Create a Reference Application
-
-@manager should initiate a reference application in the following situations:
-
-- The Risk Tracking Dashboard shows **"Lack of Reference Application"** as a top-priority open risk.
-- The team needs to validate that new governance rules (especially Corporate CRUD Governance and Hermes) work end-to-end.
-- A new major capability (e.g., advanced Hermes flows, complex admin patterns) needs to be demonstrated before being trusted in client projects.
-- During Phase 1 or early Phase 2 when moving from theory to practice.
-
-## Mandatory Requirements (Non-Negotiable)
-
-Any reference application **must** demonstrate the following:
-
-1. **Contract-First Development**
-   - All types defined first in `apps/backend/src/types/`
-   - `contract.version.json` maintained and verified
-
-2. **Branded Types**
-   - All IDs must be branded (e.g., `UserID`, `OrderID`)
-
-3. **Normal CRUD + One High-Risk Administrative Action**
-   - At least one standard domain entity with full CRUD
-   - At least one high-risk admin operation (e.g., role change, bulk delete, system config) that strictly follows the `managerApproval` + audit pattern
-
-4. **Hermes Protocol Usage**
-   - At least one real inter-agent message flow (e.g., @backend → @analyst or @manager → @backend)
-   - Proper use of `send_agent_message` + `update_agent_message_status`
-
-5. **Corporate Governance Compliance**
-   - All high-risk actions must go through @manager briefing and approval
-   - Full audit logging with Trace ID, previousState/newState, and actor
-
-6. **Framework Boundary Respect**
-   - All code lives strictly inside `apps/`
-   - No modifications to `framework-mcp/`, `.enderun/agents/`, or root framework files
-
-7. **Professional Standards**
-   - Error handling with DomainError hierarchy
-   - Structured logging with Trace ID
-   - Proper validation and rate limiting on sensitive endpoints
-
-## Recommended Minimal Scope (Example)
-
-A good starting reference application can be a **User Management** system with:
-
-- Backend: Users (normal CRUD) + Admin role change (high-risk)
-- Frontend: User list + detail + role change form (using official frontend blueprints)
-- One Hermes message from backend to @analyst after role change
-
-This scope is small enough to build quickly but rich enough to prove the most critical governance rules.
-
-## Agent Responsibilities
-
-- **@manager**: Owns the decision to start, creates the briefing, ensures governance compliance, updates Risk Tracking Dashboard and PROJECT_MEMORY.
-- **@backend**: Implements backend with correct patterns and Hermes integration.
-- **@frontend**: Uses official frontend blueprints and high-risk admin action patterns.
-- **@analyst**: Reviews governance compliance and helps close the risk item.
-- **@explorer**: Can be used for dependency analysis if the reference app grows.
-
-## Rules
-
-- Never create a reference application without an explicit @manager briefing.
-- The reference app is **temporary and educational** — it is not a product.
-- After the reference application successfully closes the "Lack of Reference Application" risk, it may be archived or replaced with a cleaner example.
-- All work must be logged in HISTORY and the Risk Tracking Dashboard must be updated.
-
-## Updating Risk Status
-
-When a reference application is completed and accepted:
-
-1. Update the Risk Tracking Dashboard in both `docs/roadmap.md` and `PROJECT_MEMORY.md`
-2. Mark "Lack of Reference Application" as **Closed**
-3. Record the achievement in the HISTORY section of PROJECT_MEMORY.md
-4. Optionally create a short "Reference Application Walkthrough" under `docs/`
-
----
-
-**This guideline is now part of the official agent knowledge base.** All agents must follow it when the creation of a reference application is discussed.

package/.enderun/knowledge/responsive_design_standards.md

@@ -1,27 +0,0 @@
-# Responsive Design Standards
-
-To ensure cross-screen compatibility and prevent "design drift", all UI components must follow these standards.
-
-## 1. Grid & Flex Patterns
-- **Base:** Vertical stack for mobile (`flexDirection: "column"`).
-- **Responsive:** Transition to horizontal or multi-column grid at `md` (768px) or `lg` (1024px) breakpoints.
-- **Container:** Use a standard max-width container for desktop to prevent layouts from stretching too wide.
-
-## 2. Fluid Typography & Spacing
-- Use `clamp()` for font sizes that need to scale.
-- Example: `fontSize: "clamp(1rem, 5vw, 2rem)"`.
-- Use Panda CSS tokens for spacing (`gap`, `padding`, `margin`) to maintain rhythm.
-
-## 3. Preservation of State
-- When updating a component, keep the existing `useState`, `useEffect`, and `props` interfaces intact.
-- Do not remove existing `data-` attributes or accessibility roles.
-
-## 4. Breakpoint Reference
-| Token | Min Width | Target Device |
-| :--- | :--- | :--- |
-| base | 0px | Mobile |
-| sm | 640px | Large Mobile / Small Tablet |
-| md | 768px | Tablet |
-| lg | 1024px | Desktop |
-| xl | 1280px | Large Desktop |
-| 2xl | 1536px | Ultra-wide |

package/.enderun/knowledge/router_logic.md

@@ -1,29 +0,0 @@
-# 🚦 Task Routing & Delegation Logic (router_logic.md)
-
-This document defines how the **Commander** (Gemini/Claude) should analyze incoming requests and route them to the correct **Capabilities** (Architect, Implementer, Researcher, etc.).
-
-## 🧩 Routing Algorithm
-
-### Step 1: Intent Analysis
-- **Goal:** Determine if the request is an *Inquiry* (Information) or a *Directive* (Action).
-- **Scope:** Is it a system-wide change or a local fix?
-
-### Step 2: Role Assignment
-- **Architecture/Refactoring:** -> Route to **Architect Capability**.
-- **Research/Trends:** -> Route to **Researcher Capability**.
-- **Coding/UI/Testing:** -> Route to **Implementer Capability**.
-- **Infrastructure/Deploy:** -> Route to **Operations Capability**.
-
-### Step 3: Tool Capability Gate & Governance Board
-- Verify if the assigned agent has the required `permittedTools` for the task.
-- **High-Risk Action Protocol (Enterprise 2.1):** 
-  - Any action involving `deploy_production`, `delete_critical_file`, or `bulk_db_mutation` is considered **High-Risk**.
-  - **Multi-Sig Approval Required:** Commander cannot execute these alone. Must obtain a "Sign-off" from **Architect** and **Security** agents in the Hermes channel first.
-  - Final execution is logged in `.enderun/observability/AUDIT_LOG.md`.
-
-## 🤝 Coordination Flow
-1. **Commander** creates a DAG (Directed Acyclic Graph) of sub-tasks.
-2. **Router** assigns each task to a specialist.
-3. Specialists execute and report back to the **Architect** for review.
-4. **Architect** approves and notifies the **Commander**.
-5. **Commander** presents the final result to the User.

package/.enderun/knowledge/security_reference_guide.md

@@ -1,35 +0,0 @@
-# @security — Security & Cryptography Reference Guide
-
-Detailed authentication controls, Row Level Security (RLS) policies, secrets management, and cryptographic requirements. Reference this file during security reviews, API hardening, and credential audits.
-
----
-
-## 🛡️ Security Governance Protocols
-
-### 1. Row Level Security (RLS) Enforcements
-- All client-facing database tables must activate RLS.
-- Database access schemas must prevent bypass queries.
-
-### 2. Zero Hardcoded Credentials Policy
-- Never store API keys, tokens, client secrets, or private keys in the code.
-- Retrieve all secrets from secure environment variables or a sealed vault.
-
-### 3. CSP and CORS Auditing
-- Verify that Content Security Policies (CSP) are strongly locked down.
-- Ensure CORS configurations only whitelist verified origins and reject wildcards (`*`).
-
----
-
-## 📋 Security Verification Checklist (Mandatory)
-- [ ] **RLS Integrity:** Are RLS rules active on all postgres tables?
-- [ ] **Secrets Leaks:** Did we search for keywords like `key`, `password`, `token` in plain strings?
-- [ ] **Sanitization:** Are all user inputs sanitized to prevent XSS or SQL injection?
-- [ ] **Access Logs:** Do all security-critical operations write audit logs?
-- [ ] **CSP Rules:** Are CSP domains strictly whitelisted?
-
----
-
-## 🔒 Cryptography Standards
-1. **Password Hashing:** Always use Argon2id or bcrypt with strong work factors.
-2. **Encryption at Rest:** Ensure database storage and confidential payloads are encrypted.
-3. **Transport Security:** Enforce TLS 1.3 across all communication layers.