agent-enderun 1.1.1 → 1.1.3

package/.enderun/knowledge/corporate-governance/high-risk-action-approval-flow-simulation.md

@@ -1,167 +0,0 @@
-# High-Risk Action Approval Flow Simulation
-
-**Purpose**: This simulation demonstrates the complete end-to-end flow of a high-risk administrative action in a corporate project, from the moment the user clicks the button in the UI until the action is executed and audited.
-
-**Scenario**: A company administrator wants to promote a regular user to SuperAdmin. This action is classified as high-risk.
-
----
-
-## Step 1 – User Triggers the Action (Frontend)
-
-**UI Context**: Admin dashboard → User list → “Promote to SuperAdmin” button next to a user named “Alice”.
-
-**User clicks the button.**
-
-**Frontend behavior** (as per `high-risk-security-modal-hermes-flow.md`):
-
-- Immediately opens a prominent, non-dismissible `HighRiskSecurityModal`.
-- Modal displays:
-  - Clear warning: “This action will grant full system privileges to the selected user.”
-  - Required “Reason” textarea.
-  - Buttons: “Cancel” and “Request Manager Approval via Hermes”.
-
-**User enters the reason**:  
-“Alice needs SuperAdmin access to handle critical production incidents during the migration period. Security team has reviewed and approved.”
-
-User clicks “Request Manager Approval via Hermes”.
-
----
-
-## Step 2 – Hermes Briefing to @manager
-
-**Frontend** constructs and sends a Hermes message to @manager:
-
-```json
-{
-  "type": "high_risk_approval_request",
-  "traceId": "TRACE-20260525-USER-PROMO-042",
-  "payload": {
-    "action": "PROMOTE_TO_SUPERADMIN",
-    "targetUserId": "user_0192",
-    "proposedBy": "admin_007",
-    "reason": "Alice needs SuperAdmin access to handle critical production incidents during the migration period. Security team has reviewed and approved."
-  }
-}
-```
-
-**@manager receives the briefing.**
-
-**@manager internal process** (as per corporate-governance knowledge):
-
-- Reads `high-risk-actions-managerapproval.md`
-- Reads `audit-logging-standard.md`
-- Assesses risk level (very high – SuperAdmin elevation)
-- Checks current project context and any existing policies
-
-**@manager response** (sent back via Hermes):
-
-```json
-{
-  "type": "high_risk_approval_response",
-  "traceId": "TRACE-20260525-USER-PROMO-042",
-  "status": "approved",
-  "managerApproval": {
-    "approvalId": "approval_88471",
-    "traceId": "TRACE-20260525-USER-PROMO-042",
-    "approvedBy": "manager",
-    "approvedAt": "2026-05-25T00:31:12Z",
-    "signature": "mgr-sig-20260525-88471",
-    "reason": "Approved for production incident handling during migration window. 30-day time-limited approval recommended."
-  }
-}
-```
-
----
-
-## Step 3 – Frontend Receives Approval and Dispatches Request
-
-**Frontend**:
-- Receives the signed `managerApproval` token.
-- Closes the security modal.
-- Shows temporary status: “Manager approval received. Executing action…”
-- Attaches the token to the API request:
-
-```ts
-const payload = {
-  userId: "user_0192" as UserID,
-  newRole: "SuperAdmin",
-  isHighRiskAdminAction: true,
-  managerApproval: {
-    approvalId: "approval_88471",
-    traceId: "TRACE-20260525-USER-PROMO-042",
-    approvedBy: "manager",
-    approvedAt: "2026-05-25T00:31:12Z",
-    signature: "mgr-sig-20260525-88471",
-    reason: "Approved for production incident handling during migration window. 30-day time-limited approval recommended."
-  }
-};
-
-await fetch(`/api/v1/users/${userId}/role`, {
-  method: "POST",
-  body: JSON.stringify(payload)
-});
-```
-
----
-
-## Step 4 – Backend Validation and Execution
-
-**@backend** receives the request.
-
-**Validation steps** (mandatory per `high-risk-actions-managerapproval.md` and `domain-error-handling-standard.md`):
-
-1. Checks `isHighRiskAdminAction === true`
-2. Validates presence and structure of `managerApproval`
-3. Verifies `managerApproval.approvedBy === "manager"`
-4. (In real system) Validates cryptographic signature or secure reference
-
-If any check fails → throws `HighRiskActionRequiresApprovalError`
-
-**Execution**:
-
-- Updates user role in database
-- Creates audit log entry (see `audit-logging-standard.md`):
-
-```ts
-await auditLogRepository.create({
-  traceId: "TRACE-20260525-USER-PROMO-042",
-  actorId: "admin_007" as UserID,
-  action: "USER_ROLE_ELEVATED_TO_SUPERADMIN",
-  targetId: "user_0192" as UserID,
-  beforeState: { role: "Admin" },
-  afterState: { role: "SuperAdmin" },
-  managerApprovalId: "approval_88471",
-  reason: "Approved for production incident handling during migration window..."
-});
-```
-
-- Returns success response with the used `approvalId`
-
----
-
-## Step 5 – Frontend Feedback and Audit Visibility
-
-**Frontend**:
-- Shows success message: “Alice has been promoted to SuperAdmin. Action recorded with approval ID: approval_88471”
-- (Optional but recommended) Shows link to view the audit trail entry for this action
-
-**Audit log entry** is now queryable by authorized personnel (themselves subject to high-risk approval if they want to view full details).
-
----
-
-## Key Governance Elements Demonstrated
-
-- User cannot bypass the security modal
-- Reason is mandatory and travels with the approval
-- @manager performs explicit risk assessment before issuing the token
-- Backend strictly validates the token before any state change
-- Full audit trail is created with reference to the approval
-- Trace ID connects the entire flow (UI → Hermes → Backend → Audit)
-
-This is the expected behavior for any high-risk action in a corporate project using Agent Enderun.
-
-**Anti-patterns shown as forbidden in this simulation**:
-- Frontend directly calling the API without the modal and approval
-- Backend executing the role change without validating `managerApproval`
-- Skipping audit logging for a privileged action
-- Re-using an old approval token without fresh @manager review

package/.enderun/knowledge/corporate-governance/high-risk-action-approval-flow.md

@@ -1,29 +0,0 @@
-# High-Risk Action Approval Protocol
-
-This protocol defines the non-negotiable process for executing high-risk operations (e.g., database schema changes, production environment configuration, user permission management, bulk data deletion) within the Agent Enderun framework.
-
-## 1. Scope Definition
-Any action that meets the following criteria is classified as "High-Risk":
-- Modifies production database schema.
-- Changes system-wide security policies or IAM permissions.
-- Triggers destructive data operations (bulk delete, purge).
-- Modifies production-level configuration files (e.g., `.env.prod`).
-
-## 2. Mandatory Approval Flow
-
-All high-risk actions MUST follow the "Three-Key" principle:
-
-1. **Initiation:** The requesting specialist agent MUST brief `@manager` using the `send_agent_message` Hermes protocol, explicitly stating the intent and risk.
-2. **Analysis:** `@manager` logs the intent to `.enderun/logs/manager.json` and updates `PROJECT_MEMORY.md` with a new Trace ID status: `PENDING_APPROVAL`.
-3. **Quality/Security Gate:** `@manager` delegates the task to `@quality` via Hermes with a `SECURITY_AND_IMPACT_AUDIT` category.
-   - `@quality` MUST run `analyze_procedural_continuity` and `security_audit_scan`.
-   - `@quality` MUST issue a formal `APPROVAL` or `REJECTION` Hermes message back to `@manager`.
-4. **Execution:** ONLY upon receiving an `APPROVAL` Hermes message, `@manager` is authorized to execute the action via internal tools.
-
-## 3. Tool Enforcement (MCP)
-- Specialists must NOT have direct MCP tool permissions for high-risk actions.
-- These tools MUST be wrapped in a decorator that forces the request through the `@manager` approval flow.
-
-## 4. Audit Trail (Non-Negotiable)
-- All steps must be recorded in `.enderun/logs/governance.json`.
-- Missing audit trails for any high-risk action constitute a "Critical Rule Violation" and trigger an automatic system-wide lock.

package/.enderun/knowledge/corporate-governance/high-risk-actions-managerapproval.md

@@ -1,76 +0,0 @@
-# High-Risk Administrative Actions & ManagerApproval Pattern
-
-**Applies to:** Any operation that changes user roles/permissions, system configuration, bulk data operations, or audit access.
-
-## Core Principle
-From ENDERUN.md Corporate CRUD Governance:
-> High-risk administrative operations are strictly under @manager control. Specialist agents must refuse and immediately redirect such requests to @manager.
-
-## Required Payload Shape
-Every high-risk request **must** include:
-
-```ts
-interface HighRiskActionPayload {
-  isHighRiskAdminAction: true;           // Explicit boolean flag
-  managerApproval: ManagerApproval;      // Cryptographically or procedurally signed token
-}
-
-interface ManagerApproval {
-  approvalId: ApprovalID;
-  traceId: TraceID;
-  approvedBy: 'manager';
-  approvedAt: string;                    // ISO-8601
-  signature: string;                     // In real systems: cryptographic signature or secure reference
-  reason: string;                        // Human-readable justification (mandatory)
-}
-```
-
-## Backend Enforcement Rules (@backend)
-1. If the action affects roles/permissions at Admin level or higher → treat as high-risk.
-2. Reject the request immediately (403) if either `isHighRiskAdminAction` or `managerApproval` is missing.
-3. Validate that `managerApproval.approvedBy === 'manager'`.
-4. Log the full approval token for audit.
-5. Never perform the state change before validation.
-
-## Frontend Requirements (@frontend)
-1. Any button or flow that can trigger a high-risk action must first open a **prominent, non-dismissible security modal**.
-2. The modal must:
-   - Clearly explain the risk and consequences.
-   - Require the user to enter a "reason".
-   - Only then initiate the Hermes briefing to @manager.
-3. The actual API call may only be made **after** a valid `managerApproval` token is returned from the briefing flow.
-
-## Hermes Coordination
-- @frontend → Hermes briefing to @manager with proposed action + reason.
-- @manager performs risk assessment and either:
-  - Issues a signed `managerApproval` token, or
-  - Rejects the request.
-- Only after receiving the token does the frontend dispatch the high-risk request to backend.
-
-## Concrete Payload Example (TypeScript)
-
-```ts
-// Request body for elevating a user to SuperAdmin
-interface PromoteToSuperAdminRequest {
-  userId: UserID;
-  newRole: 'SuperAdmin';
-  isHighRiskAdminAction: true;
-  managerApproval: {
-    approvalId: ApprovalID;
-    traceId: TraceID;
-    approvedBy: 'manager';
-    approvedAt: string;
-    signature: string;
-    reason: string;
-  };
-}
-```
-
-## Example High-Risk Actions (Non-Exhaustive)
-- Elevating any user to Admin or SuperAdmin
-- Resetting system-wide configuration
-- Bulk user deletion or data purge
-- Exporting full audit logs containing PII
-- Changing authentication providers or security policies
-
-This pattern is the foundation of trustworthy enterprise governance in Agent Enderun.

package/.enderun/knowledge/corporate-governance/high-risk-security-modal-hermes-flow.md

@@ -1,49 +0,0 @@
-# High-Risk Security Modal + Hermes Briefing Flow (Frontend Pattern)
-
-**Owner:** @frontend  
-**Related:** high-risk-actions-managerapproval.md
-
-## When to Use
-Any UI action that can result in a high-risk backend operation (see list in high-risk-actions document).
-
-## Required UI Behavior
-
-1. **Trigger Detection**
-   - The component must recognize that the intended action is high-risk (role elevation, bulk ops, etc.).
-
-2. **Security Modal (Mandatory)**
-   - Modal must be prominent (red/danger styling, large title "High-Risk Administrative Action").
-   - Must clearly state what is about to happen and the potential impact.
-   - Must contain a required free-text "Reason" field (this becomes part of the approval token).
-   - Must have clear "Cancel" and "Request Manager Approval" actions.
-   - Should not be dismissible by clicking outside while the request is in flight.
-
-3. **Hermes Briefing Flow**
-   - On "Request Manager Approval":
-     - Frontend sends a Hermes message to @manager containing:
-       - Proposed action
-       - Affected entities (e.g. userId)
-       - User-entered reason
-       - Current user context
-     - UI enters "Awaiting @manager approval" state (loading indicator + clear message).
-
-4. **Approval Reception**
-   - When @manager responds with a valid `managerApproval` token (via Hermes or secure channel), the frontend:
-     - Attaches the token to the request payload (`isHighRiskAdminAction: true`, `managerApproval`).
-     - Dispatches the actual API call.
-     - Shows success/failure feedback.
-
-5. **Audit & Traceability**
-   - The Trace ID from the approval must be visible or logged in the UI success state.
-   - The full approval reason must be recorded.
-
-## Anti-Patterns (Forbidden)
-- Performing the high-risk API call without the modal + reason.
-- Faking or locally generating the `managerApproval` object in the browser.
-- Hiding the risk from the user ("just click confirm").
-- Re-using old approval tokens.
-
-## Recommended Component Location
-`apps/web/src/components/ui/HighRiskSecurityModal.tsx` (or similar compound component).
-
-This pattern ensures that high-risk actions are never accidental and always carry a full audit trail through @manager.

package/.enderun/knowledge/corporate-governance/manager-first-30-days-guide.md

@@ -1,112 +0,0 @@
-# First 30 Days Corporate Project Management Guide (@manager)
-
-**Purpose**: A practical playbook for @manager covering the critical first 30 days of any new corporate/enterprise project. It combines the Scaffolding SOP, checklists, and briefings into a day-by-day and week-by-week operating rhythm.
-
----
-
-## Week 0 – Project Initiation (Days 1–3)
-
-### Day 1 – Governance Baseline
-- Deliver the **Governance Baseline Briefing** (use `governance-baseline-briefing-template.md`)
-- Walk the user through the **Corporate Project Kickoff Checklist**
-- Get explicit acknowledgment of the standards
-- Record the decision in `PROJECT_MEMORY.md`
-
-### Day 2 – Team Alignment
-- Brief all active agents using `corporate-project-scaffolding-sop.md`
-- Assign initial responsibilities:
-  - @backend: Type foundation
-  - @frontend: Type copies + modal skeleton
-  - @analyst: Contract verification process
-- Create the first Architecture Decision Record (ADR) for governance baseline
-
-### Day 3 – Foundation Kickoff
-- Officially start **Phase 1** (Contract Foundation)
-- Set up the first Hermes channels and trace ID convention
-
----
-
-## Week 1 – Foundation Layer
-
-**Primary Focus**: Contracts before code.
-
-**Key Activities**:
-- Ensure `branded-types-law.md` and core identifiers are implemented
-- `ManagerApproval` and `HighRiskActionPayload` are defined
-- `contract.version.json` is initialized
-- @frontend has matching type copies
-- First version of `domain-error-handling-standard.md` is in place
-
-**@manager Checkpoints** (end of Week 1):
-- [ ] All Phase 1 items from Kickoff Checklist completed
-- [ ] User has seen the type foundation
-- [ ] No feature implementation has started yet
-
----
-
-## Week 2 – High-Risk Infrastructure
-
-**Primary Focus**: Build the protection layer before any privileged features.
-
-**Key Activities**:
-- @backend designs high-risk validation logic
-- @frontend builds `HighRiskSecurityModal` + Hermes briefing hook
-- Audit logging strategy is defined
-- Reference: `high-risk-action-approval-flow-simulation.md`
-
-**@manager Checkpoints** (end of Week 2):
-- [ ] High-risk endpoint pattern approved
-- [ ] Security modal + Hermes flow reviewed
-- [ ] Audit logging approach signed off
-
----
-
-## Week 3 – First Real Features (Under Strict Governance)
-
-Only after Weeks 1–2 are complete:
-
-- Begin implementing the first non-privileged features using proper contracts and typed errors
-- First privileged feature may only start after infrastructure from Week 2 is approved
-- Use `backend-high-risk-endpoint-guide.md` and `frontend-high-risk-modal-guide.md` as implementation references
-
----
-
-## Week 4 – Reinforcement & Early Habits
-
-**Focus**: Make governance second nature.
-
-**Activities**:
-- Run the first **Contract Drift** simulation exercise with the team (`contract-drift-detection-simulation.md`)
-- Review the first audit logs of any privileged actions
-- Conduct a mid-project governance retrospective
-- Update `PROJECT_MEMORY.md` with lessons learned
-
----
-
-## Ongoing Rhythm (After Day 30)
-
-- Every new feature involving users, roles, permissions, or configuration → Re-read relevant governance files
-- Every contract change → @analyst verification + Hermes notification
-- Every high-risk action in production → Review the approval + audit trail
-- Monthly: Light governance health check using the Kickoff Checklist as a template
-
----
-
-## Anti-Patterns in the First 30 Days
-
-- Starting feature coding before governance baseline is acknowledged
-- Promising “we’ll add controls later”
-- Letting @backend or @frontend implement high-risk logic without @manager approval of the pattern
-- Skipping documentation of governance decisions
-
----
-
-## Reference Documents (Read in Order)
-
-1. `corporate-project-scaffolding-sop.md`
-2. `corporate-project-kickoff-checklist.md`
-3. `governance-baseline-briefing-template.md`
-4. `manager-first-three-briefings.md`
-5. `corporate-governance-playbook.md`
-
-This 30-day guide replaces ad-hoc project starts with a disciplined, repeatable process.

package/.enderun/knowledge/corporate-governance/manager-first-three-briefings.md

@@ -1,79 +0,0 @@
-# @manager – First Three Critical Briefings (Templates)
-
-This document provides ready-to-adapt briefing content that @manager should deliver in the early stages of any corporate/enterprise project.
-
----
-
-## Briefing 1: Governance Baseline (Day 0 / Project Kickoff)
-
-**Audience:** User + all active agents
-
-**Key Message:**
-
-Before we write a single line of feature code, we must lock in the governance foundation.
-
-We will follow these non-negotiable standards:
-- Branded Types for every identifier
-- High-risk actions protected by explicit `managerApproval` + Hermes flow
-- Contract-first development
-- Proper audit logging for all privileged operations
-- Typed Domain Errors instead of generic exceptions
-
-These rules exist to protect the project from technical debt, security holes, and audit failures at scale.
-
-I will personally enforce these standards in every briefing and delegation. If we encounter pressure to “skip governance for speed”, we will slow down instead.
-
-Do you accept these terms as the operating rules for this project?
-
----
-
-## Briefing 2: Contract & Type Foundation (After User Accepts Governance)
-
-**Audience:** @backend + @frontend + @analyst
-
-**Key Message:**
-
-We will now establish the single source of truth for all types.
-
-1. Create `apps/backend/src/types` with:
-   - Branded type utility
-   - Core identifiers (UserID, RoleID, ApprovalID, etc.)
-   - `ManagerApproval` and `HighRiskActionPayload`
-   - Initial domain entities and API contracts
-
-2. Initialize `contract.version.json`.
-
-3. @frontend will immediately create matching type copies.
-
-4. No routes, no components, and no database work may begin until this foundation is approved by me.
-
-@analyst will be responsible for detecting any future contract drift.
-
----
-
-## Briefing 3: High-Risk Infrastructure (Before Any Privileged Feature)
-
-**Audience:** @backend + @frontend
-
-**Key Message:**
-
-If this project will contain user/role management, configuration changes, or any privileged operations, we must build the governance infrastructure **before** implementing those features.
-
-Required deliverables:
-
-**@backend:**
-- High-risk endpoint validation logic that rejects requests missing `isHighRiskAdminAction` + valid `managerApproval`.
-- Audit logging integration for every privileged action (see audit-logging-standard.md).
-
-**@frontend:**
-- Reusable `HighRiskSecurityModal` component.
-- Hermes briefing flow that collects a reason and only then dispatches the approved request.
-
-Only after these two layers are in place and tested may we begin implementing actual privileged user stories.
-
----
-
-**Usage for @manager:**
-- Copy and adapt these briefings at the appropriate moments.
-- Always reference the exact knowledge files in `.agents/knowledge/corporate-governance/`.
-- Document the user’s and agents’ acknowledgments in `PROJECT_MEMORY.md`.

package/.enderun/knowledge/database_reference_guide.md

@@ -1,38 +0,0 @@
-# @database — Reference & Implementation Guide
-
-This guide contains detailed database architectural patterns, engine-specific tuning, and seeding standards for Agent Enderun projects. Reference this file via `read_file` only when designing schemas, tuning performance, or managing complex migrations.
-
----
-
-## 🏗️ Database Migration Standards (Mandatory)
-- **Tooling:** Kysely migrations only.
-- **Immutability:** Never modify an existing migration. Create a new one.
-- **Rollback:** Always include a `down` function.
-- **Naming:** `YYYYMMDD_action_description.ts`.
-
----
-
-## ⚙️ Performance Tuning & Multi-Engine Guidelines
-
-### 1. PostgreSQL Optimization
-- Use **BRIN** indexes for large time-series data.
-- Use **GIN** for JSONB and full-text search.
-- Configure `shared_buffers` and `effective_cache_size` based on system RAM.
-
-### 2. MySQL / MariaDB Optimization
-- Tune `innodb_buffer_pool_size`.
-- Use `EXPLAIN FORMAT=JSON` for detailed query plan analysis.
-
----
-
-## 📊 Seeding Standards
-- **Contract-Aware:** Seeds must match the Branded Types in the application.
-- **Realistic Data:** Use Faker or similar libraries to generate non-mock, production-quality data.
-- **Idempotency:** Seeding scripts should be runnable multiple times without duplication.
-
----
-
-## 🔍 Performance Audit
-- Analyze `EXPLAIN ANALYZE` reports.
-- Identify "Sequential Scans" on large tables and propose index coverage.
-- Monitor connection pool saturation.

package/.enderun/knowledge/devops_reference_guide.md

@@ -1,43 +0,0 @@
-# @devops — Infrastructure & Deployment Reference Guide
-
-Detailed CI/CD pipeline designs, deployment strategies, and rollback protocols. Reference this file when designing workflows or troubleshooting deployments.
-
----
-
-## 🏗️ CI/CD Pipeline Design (Standard)
-
-Standard stages for every project:
-1. **Lint & Type Check** — ESLint + TypeScript compiler.
-2. **Unit Tests** — Vitest.
-3. **Security Scan** — `security_audit_scan` tool.
-4. **Build** — `tsc` + bundler.
-5. **Health Check** — Post-deploy verification.
-
----
-
-## 🚀 Deployment Strategies
-
-### 1. Blue-Green Deployment
-- Preferred for stateful services.
-- Keep old version on standby for 30 minutes.
-
-### 2. Rolling Deployment
-- Preferred for stateless services.
-- Replace instances one by one with health checks.
-
----
-
-## 🛡️ Monitoring & Telemetry (Standard)
-- **Log Level:** `info/warn` in prod, `debug` in dev.
-- **Alerting:** Trigger alerts on 5xx errors or >85% memory usage.
-- **Key Metrics:** API latency, DB connection pool, CPU/Memory profiles.
-
----
-
-## 🔄 Rollback Protocol (Mandatory)
-Every deploy must have a documented rollback plan in `docs/`:
-```markdown
-- **Trigger:** Health failure or error spike.
-- **Steps:** [numbered steps]
-- **Time:** {N} minutes.
-```

package/.enderun/knowledge/documentation_ownership.md

@@ -1,53 +0,0 @@
-# Documentation Ownership Standard
-
-> **Trace ID:** 01HGT8J5E2N0W0W0W0W0W0W0W4  
-> **Status:** ACTIVE  
-> **Applicability:** All Agent Enderun Framework Components and Subagents
-
----
-
-## 🏛️ 1. Overview & Core Philosophy
-
-In a high-integrity agentic development environment, keeping a strict separation of concerns between the **Agent Enderun Framework** and the **User's Application Codebase** is critical. Documentation is no exception.
-
-This standard defines the boundary of where documentation can and must be written. Any deviation from this policy is treated as a major architectural governance violation and will be flagged immediately by `@manager`.
-
----
-
-## 🚫 2. The Framework Boundary
-
-To maintain portability and avoid cluttering the core framework directory, agents must strictly follow the directory permissions:
-
-1. **Framework Directories (`.enderun/` or `{{FRAMEWORK_DIR}}`)**:
-   - **Allowed**: Core system configurations, internal agent instructions, status metrics, and global, generic framework-level architectural patterns.
-   - **Strictly Prohibited**: Any user-project specific research, implementation details, API guides, component documentation, database schemas, or deployment instructions.
-
-2. **User Application Directories (e.g., `docs/`, `apps/`, `src/`)**:
-   - **Mandatory**: All project-specific architectural decisions (ADRs), layout specs, technical guides, system integration plans, API specifications, and research findings must be written **exclusively** into the user's own `docs/` directory.
-
-```mermaid
-graph TD
-    A[Agent Produces Documentation] --> B{Is it Framework Internal?}
-    B -->|Yes| C[Write to .enderun/knowledge/ or .enderun/agents/]
-    B -->|No - Project Specific| D[Write exclusively to user's docs/ directory]
-    C --> E[Enterprise Framework Knowledge Base]
-    D --> F[User Project Documentation Assets]
-```
-
----
-
-## 📝 3. User Project `docs/` Structure
-
-When producing user-facing documentation, agents must use a clean, logical structure inside the user's `docs/` directory:
-
-- `/docs/architecture/` — Architectural Decision Records (ADRs), system designs, database schemas.
-- `/docs/api/` — API route documentation, contract hashes, payload structures.
-- `/docs/guides/` — Developer onboarding, building, running, and troubleshooting the specific application.
-- `/docs/research/` — Third-party library evaluations, performance benchmarks, and exploration logs.
-
----
-
-## 🚨 4. Enforcement & Governance
-
-- **Zero-Tolerance Audit**: During any code review or check command (e.g., `agent-enderun check`), `@manager` or `@quality` will verify if any files have been erroneously created in `.enderun/knowledge/`.
-- **Auto-Correction**: Any violating file will be immediately moved to the appropriate user-project `docs/` directory, and a warning log carrying the active Trace ID will be raised.