agent-enderun 1.1.1 → 1.1.3

package/.enderun/knowledge/eslint-standards.md

@@ -1,63 +0,0 @@
-# ESLint & Code Quality Standards
-
-**Version**: 1.0  
-**Status**: MANDATORY  
-**Scope**: All TypeScript and JavaScript projects under Agent Enderun.
-
----
-
-## 🏛️ Foundational Rules (Zero Tolerance)
-
-Every line of code must pass these standards. Violation is considered a "Governance Breach".
-
-### 1. The `any` Prohibition
-- **Rule**: Use of the `any` type is strictly forbidden.
-- **Why**: Bypasses the type system and introduces hidden bugs.
-- **Action**: Use `unknown`, generics, or define a concrete `interface`/`type`.
-
-### 2. The `console.log` Ban
-- **Rule**: `console.log`, `console.warn`, and `console.error` are forbidden in application code.
-- **Why**: Pollutes production logs and leaks information.
-- **Action**: Use a structured logging utility or the project's internal logger.
-
-### 3. Branded Types Law
-- **Rule**: All identifiers (IDs) must be "Branded Types".
-- **Why**: Prevents accidental mixing of different ID types (e.g., passing a UserID where a ProjectID is expected).
-- **Example**: `export type UserID = Brand<string, "UserID">;`
-
----
-
-## 🏗️ Architectural Compliance
-
-### 1. Contract-First Development
-- All API routes and shared data structures must be defined in the `types/` folder before implementation.
-- `apps/backend/contract.version.json` must be updated on every contract change.
-
-### 2. Domain-Driven Structure
-- Keep logic within its respective domain. Avoid cross-domain leakage.
-- Controllers should only handle routing and validation; business logic belongs in Services/Repositories.
-
-### 3. Async/Await Excellence
-- Always use `try/catch` blocks for asynchronous operations.
-- Never leave a promise unhandled.
-
----
-
-## 💅 Styling & Naming
-
-- **Naming**: Use camelCase for variables/functions, PascalCase for classes/types, and kebab-case for files.
-- **Comments**: Only comment *why* something is complex. Do not describe *what* the code does (the code should be self-descriptive).
-- **Imports**: Always use explicit file extensions in imports (e.g., `import { foo } from "./foo.js";`) to comply with ESM standards.
-
----
-
-## 🛠️ Tooling
-
-Agents must run the following command to verify compliance:
-`agent-enderun check:lint`
-
-If a file fails linting, agents are authorized to use `eslint --fix` but must manually review the changes to ensure logic is preserved.
-
----
-
-**Failure to comply with these standards will result in a PHASE_ROLLBACK.**

package/.enderun/knowledge/evaluation_engine.md

@@ -1,26 +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 evaluation, planning, or quality gates.
-- Prefer search or targeted reads over full inclusion in every context.
-- Not core to CLI runtime, init scaffolding, or mandatory every-session knowledge.
-
----
-
-# ⚖️ Evaluation Engine (evaluation_engine.md)
-
-This document defines the post-task evaluation process. After every major task (Trace ID completion), the Commander must audit the output.
-
-## 🎯 Evaluation Criteria
-
-1. **Constitutional Compliance:** Did the agent follow `ENDERUN.md` and `SECURITY.md`? (Weight: 40%)
-2. **Surgical Quality:** Was `replace_text` used correctly? Were placeholders avoided? (Weight: 20%)
-3. **Traceability:** Are all logs and memory updates completed? (Weight: 20%)
-4. **Efficiency:** Was the task completed with minimal tool calls? (Weight: 20%)
-
-## 📈 Scoring
-- **9.0 - 10:** Excellent. Move to `DONE`.
-- **7.0 - 8.9:** Passing. Note minor improvements in `LESSONS_LEARNED.md`.
-- **< 7.0:** Failed. Rollback and re-brief.

package/.enderun/knowledge/explorer_reference_guide.md

@@ -1,34 +0,0 @@
-# @explorer — Research & Discovery Reference Guide
-
-Standard procedures for codebase mapping, legacy system conversion, and architecture intelligence. Reference this file when performing deep research or onboarding new projects.
-
----
-
-## 🔄 Legacy Conversion Algorithm (Standard)
-
-1.  **Architecture Mapping:** Use `analyze_dependencies` for coupling analysis.
-2.  **Gap Analysis:** Document structural deviations from `ENDERUN.md`.
-3.  **Bridge Building:** Map existing DTOs to a new app-local `types` directory.
-4.  **Refactor Blueprint:** Provide a plan for "Hot Spot" modules using Branded Types.
-
----
-
-## 🔍 Research & Intelligence Standards
-
-### 1. Common UI Mapping (CRITICAL)
-Before frontend tasks, scan `apps/web/src/components/ui/` and list available components for @frontend.
-
-### 2. Architecture Discovery
-- Use `generate_dependency_graph` for module relationships.
-- Use `analyze_database_schema` for Mermaid ER diagrams.
-- Use `analyze_codebase_intelligence` for complexity analysis.
-
-### 3. Impact Zone Analysis
-Always identify the "Impact Zone" before suggesting modifications to avoid side effects.
-
----
-
-## 🧭 Agent Skill Development
-- Capture recurring patterns and store them as actionable guidance.
-- Track decisions that worked vs regressions to improve heuristics.
-- Propose coaching notes for other agents when gaps are found.

package/.enderun/knowledge/framework_vs_user_project_boundary.md

@@ -1,52 +0,0 @@
-# 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

@@ -1,108 +0,0 @@
-# Frontend Professionalization Guidelines
-
-**Version:** 1.0  
-**Owner:** @manager  
-**Last Updated:** 23 May 2026
-
-## Purpose
-
-This document defines the official **@frontend Professionalization Program** to close the critical risk item **"@frontend Weakness"** 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 2026)
-
-- **Risk Name:** @frontend Weakness
-- **Current Level:** 6.5 / 10
-- **Target Level:** 9.0 / 10
-- **Risk Severity:** Critical / High 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 Weakness" 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 Weakness" 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/frontend_reference_guide.md

@@ -1,64 +0,0 @@
-# @frontend — Reference & Implementation Guide
-
-This guide contains detailed architectural patterns, UI standards, and code structures for Agent Enderun projects. Reference this file via `read_file` only when building new components, pages, or complex UI logic.
-
----
-
-## 📐 Responsive & Fluid Design Standards
-
-- **Mobile-First (320px):** Always write base styles for mobile and use `stack` (vertical) as default.
-- **Breakpoint Hygiene:** Use Panda CSS responsive objects (e.g., `sm`, `md`, `lg`).
-- **Fluidity via Tokens:** Use `clamp()` or fluid spacing tokens for typography and gaps.
-- **Grid Stability:** Prefer `grid` for complex layouts.
-
----
-
-## 🏗️ Standard UI Component Patterns (Mandatory)
-
-### 1. Button
-- Variants: primary, secondary, danger, ghost.
-- focus-ring and transition are mandatory.
-
-### 2. Input
-- Red focus ring for error state.
-- Gray background when disabled.
-
-### 3. Card
-- Border + shadow-sm combination.
-- Responsive internal spacing.
-
-### 4. Modal
-- Overlay + centered content.
-- Standard close button.
-
----
-
-## ⚡ Proactive Engineering (Mandatory)
-- **Loading States:** Skeletons or spinners for all async operations.
-- **Empty States:** Clear messaging for no data.
-- **Error UI:** Graceful handling of backend errors.
-
----
-
-## 🔗 Hook-Based API Architecture (Mandatory)
-
-### 1. useListPage
-For list pages with pagination and search.
-
-### 2. useDetailPage
-For detail pages with fetch/update/delete.
-
-### 3. useFormPage
-For form state management and validation.
-
----
-
-## 🎨 Theme & Semantic Design System
-- Radius: `md (6px)`, `lg (8px)`, `xl (12px)`.
-- Typography: Inter (default font), Outfit (for titles).
-
----
-
-## 🧩 Frontend Capability Expansion
-- **Design System Coverage:** Identify missing tokens.
-- **A11y Growth:** Add keyboard support and contrast checks.

package/.enderun/knowledge/git_reference_guide.md

@@ -1,51 +0,0 @@
-# @git — Version Control Reference Guide
-
-Detailed commit strategies, branching models, and repository health check procedures. Reference this file when performing major merges, releases, or cleaning up history.
-
----
-
-## 🛠️ Git Discipline Protocol
-
-### 1. Commit Message Format
-Every message MUST follow this pattern:
-`[{{TRACE_ID}}] <type>(<scope>): <description>`
-
-- **Types:**
-    - `feat`: New feature.
-    - `fix`: Bug fix.
-    - `docs`: Documentation only.
-    - `refactor`: Code change that neither fixes a bug nor adds a feature.
-    - `test`: Adding missing tests or correcting existing tests.
-    - `chore`: Updates to build process, dependencies, etc.
-    - `arch`: Architectural changes or contract updates.
-
-### 2. Branching Strategy
-- **Main/Master:** Production-ready code only.
-- **Feature Branches:** `feat/{{TRACE_ID}}-description`
-- **Fix Branches:** `fix/{{TRACE_ID}}-description`
-
----
-
-## 🚀 Standard Operating Procedure (SOP)
-
-### Step 1: Repository Status & Health Audit
-1. Run `git status`.
-2. **Health Check (Mandatory):** Run `npx agent-enderun check` to verify compilation.
-3. **Constitution Compliance:** Run `analyze_constitution_compliance` on staged files.
-
-### Step 2: Atomic Committing
-1. Stage files: `git add <files>`.
-2. Verify Trace ID.
-3. Use `generate_semantic_commit_message` for a structured message.
-4. Commit: `git commit -m "[message]"`.
-
-### Step 3: Phase Snapshots
-At the end of a Phase:
-1. Tag: `git tag -a v{{VERSION}}-phase{{X}} -m "Phase Completion Snapshot"`.
-
----
-
-## 🧭 Git Skill Growth
-- Identify missing release documentation or tags.
-- Suggest precise commit scopes (`arch`, `docs`, `test`).
-- Recommend cleanup for stale feature branches.

package/.enderun/knowledge/hermes_live_test_guidelines.md

@@ -1,90 +0,0 @@
-# Hermes Live Test Guidelines
-
-**Version:** 1.0  
-**Owner:** @manager  
-**Last Updated:** 23 May 2026
-
-## Purpose
-
-This document defines the official **Hermes Live Test Program** to close the risk item **"Hermes 'On Paper'"** 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 2026)
-
-- **Risk Name:** Hermes “On Paper”
-- **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 On Paper" 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.

package/.enderun/knowledge/hermes_protocol.md

@@ -1,59 +0,0 @@
-# 📡 Hermes Messaging Protocol
-
-The Hermes protocol defines the standardized way for Agent Enderun specialized agents to communicate, delegate tasks, and share state updates.
-
----
-
-## 🏗️ Message Structure
-
-Every message sent via `send_agent_message` must follow this conceptual structure (enforced by the MCP tool):
-
-```json
-{
-  "timestamp": "ISO-8601",
-  "from": "@agent_name",
-  "to": "@agent_name",
-  "category": "ACTION | DELEGATION | INFO | ALERT",
-  "priority": "LOW | MEDIUM | HIGH | URGENT",
-  "traceId": "ULID",
-  "content": "Message content",
-  "status": "PENDING | READ | ACKNOWLEDGED | COMPLETED"
-}
-```
-
----
-
-## 📂 Message Categories
-
-| Category | Usage | Expectation |
-| :--- | :--- | :--- |
-| **ACTION** | Requesting a specific action (e.g., "Run security scan"). | Must be acknowledged and logged in `STATUS.md`. |
-| **DELEGATION** | Handing off a sub-task (e.g., "@backend, create the schema"). | Becomes the primary task for the recipient. |
-| **INFO** | Sharing architectural decisions or updates. | No direct action required, but must be read. |
-| **ALERT** | Critical blockers or security violations. | Immediate attention required by `@manager`. |
-
----
-
-## 🚦 Priority Levels
-
-- **URGENT:** Must be handled in the current turn.
-- **HIGH:** Top of the queue for the next turn.
-- **MEDIUM:** Standard task priority (Default).
-- **LOW:** Non-critical background updates.
-
----
-
-## 🔄 Lifecycle Protocol
-
-1.  **Dispatch:** Agent calls `send_agent_message`. Message is saved in `.enderun/messages/recipient.json`.
-2.  **Notification:** The recipient agent checks their inbox during their turn via `read_agent_messages`.
-3.  **Acknowledgment:** For `ACTION` or `DELEGATION`, the recipient should send an `INFO` message back once started or completed.
-4.  **Logging:** All critical communications must be summarized in the agent's log file (`.enderun/logs/agent.json`).
-
----
-
-## 🛡️ Hermes Safety Rules
-
-- **No circular delegation:** Agent A cannot delegate X to Agent B if B delegated Y (a dependency of X) to A.
-- **Trace ID Integrity:** Every message MUST include a valid `traceId` from `PROJECT_MEMORY.md`.
-- **Atomic Content:** One message per specific intent. Avoid monolithic "do everything" messages.

package/.enderun/knowledge/legacy_onboarding.md

@@ -1,18 +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 legacy migration, explorer tasks, or onboarding planning.
-- Prefer search or targeted reads over full inclusion in every context.
-- Not core to CLI runtime, init scaffolding, or mandatory every-session knowledge.
-
----
-
-# Legacy Onboarding Strategy
-
-When ingesting a legacy codebase:
-1. Run `agent-enderun explorer:graph` to map the architecture.
-2. Identify "Hot Spots" via `explorer:audit`.
-3. Wrap core modules in tests before refactoring.
-4. Gradually introduce Branded Types.

package/.enderun/knowledge/lessons-learned.md

@@ -1,14 +0,0 @@
-# Lessons Learned - Agent Enderun
-
-This repository stores the collective intelligence of the Agent Army. Every failure is analyzed, and a corresponding "Prevention Rule" is established here.
-
-## Structure of a Lesson
-- **Trace ID:** The original task chain ID.
-- **Agent:** The agent responsible for the failure.
-- **Root Cause:** Deep analysis of why the failure occurred.
-- **Solution:** How the failure was resolved.
-- **Prevention Rule:** A mandatory rule added to the agent's Core Rules or `ENDERUN.md` to prevent recurrence.
-
-## Archive
-
-*(No lessons learned yet. System is in pristine state.)*