agent-enderun 0.6.5 → 0.6.7

package/.enderun/knowledge/enterprise_project_adaptation.md

@@ -0,0 +1,168 @@
+# Enterprise Project Adaptation Framework
+
+**Version:** 1.0  
+**Owner:** @manager  
+**Created:** 23 May 2026  
+**Purpose:** Teach all agents how to intelligently enter, analyze, and operate inside **any** large, complex, real-world corporate project — without assuming a specific folder structure, tech stack, or architecture.
+
+---
+
+## Core Philosophy (Non-Negotiable)
+
+In enterprise environments, the user's project is **sacred**.
+
+We never impose a reference structure (monorepo, specific framework, specific folder layout).
+
+Instead, every agent must:
+
+1. **Discover first** — deeply understand the existing system before suggesting or creating anything.
+2. **Adapt second** — shape all decisions, file placement, patterns, and governance according to what already exists.
+3. **Improve third** — only after proving deep respect for the current reality, propose targeted, low-risk improvements.
+
+"Shape yourself according to the user's project" is the supreme rule.
+
+---
+
+## 1. Enterprise Project Discovery Protocol (EPDP)
+
+When entering a new or unknown large corporate project, **@manager must run the full EPDP** before any delegation. This extends the existing Architecture Discovery Protocol (ADP).
+
+### Phase 1 — Entry & Boundary Detection
+- Identify the true project root(s) (there may be multiple services, multiple repos, or a massive monorepo).
+- Detect monorepo vs polyrepo vs multi-app structure.
+- Locate the "System of Record" for types/contracts (sometimes in a separate `packages/types`, `shared/contracts`, or even a different repo).
+- Map the actual tech stack by evidence, not assumption:
+  - Backend: Look for `package.json`, `go.mod`, `Cargo.toml`, `pom.xml`, Fastify/Express/Nest, Spring, .NET, etc.
+  - Frontend: React/Vue/Angular/Svelte + build tool + styling solution (Panda, Tailwind, SCSS, etc.).
+  - Mobile: React Native, Flutter, native iOS/Android.
+- Find the dominant patterns already in use (Repository, Service, CQRS, Clean Architecture, Feature-Sliced, etc.).
+
+### Phase 2 — Domain & Team Mapping
+- Identify major business domains (User, Billing, Inventory, HR, etc.).
+- Map which teams/agents own which domains (critical for large organizations).
+- Locate existing governance mechanisms (if any): approval processes, code review rules, architecture decision records (ADRs), RFC process.
+
+### Phase 3 — Risk & Constraint Inventory
+- Compliance requirements (KVKK/GDPR, PCI, SOC2, ISO, sector-specific).
+- Performance & scale characteristics (expected RPS, data volume, real-time needs).
+- Legacy debt hotspots (old services, big-ball-of-mud modules, deprecated tech).
+- Security boundary (what is public, internal, highly sensitive).
+- Data residency and PII handling rules.
+
+### Phase 4 — Contract & Type Reality
+- Find where the "source of truth" for API contracts and domain types actually lives.
+- Determine if the project is already contract-first, or if types are duplicated and drifting.
+- Identify the real versioning strategy (or lack thereof).
+
+---
+
+## 2. Dynamic Code Placement Decision Framework
+
+This is the most critical capability for large projects.
+
+**Rule:** Never decide file placement based on "what we like" or "what the reference app does".
+
+Always answer these questions in order:
+
+1. **Where does similar code already live?**
+   - Search for existing controllers/services/repositories in the same domain.
+   - Follow the existing pattern 100% unless there is a documented reason to change.
+
+2. **What is the project's established "feature vs technical" split?**
+   - Some projects organize by feature (`/users`, `/orders`).
+   - Some organize by technical layer (`/controllers`, `/services`, `/repositories`).
+   - Some use domain-driven packages.
+   - The agent **must** detect the dominant style and match it.
+
+3. **Where do cross-cutting concerns live?**
+   - Logging, error handling, validation, auth middleware, audit logging.
+   - Respect the existing location and extension points.
+
+4. **Where should new high-risk administrative logic live?**
+   - In large organizations this is often a dedicated "admin" or "governance" module with extra review gates.
+   - Never mix it with normal business CRUD.
+
+5. **When is it acceptable to introduce a new pattern or directory?**
+   - Only when the existing structure cannot reasonably accommodate the requirement.
+   - Must be approved by @manager + documented as an Architecture Decision.
+
+---
+
+## 3. Adaptation Rules for Different Project Maturities
+
+| Project Type                  | Agent Behavior                                                                 | Risk Level |
+|-------------------------------|----------------------------------------------------------------------------------|------------|
+| Green-field / small team      | Can propose modern clean patterns more aggressively                              | Low        |
+| Large legacy monolith         | Extremely conservative. Improve only in small, isolated, well-tested slices.     | Very High  |
+| Multi-team microservices      | Must respect service ownership boundaries. Never touch another team's service without explicit cross-team approval. | Critical |
+| Regulated enterprise (finance, health, gov) | Every change must consider compliance audit trail from day one.                 | Critical |
+| Long-lived brown-field        | First 3-5 sessions should be **only discovery and documentation**. No code.     | High       |
+
+---
+
+## 4. Long-Term Knowledge Building per Project
+
+For any serious corporate engagement, agents must maintain project-specific knowledge that survives sessions:
+
+- `project-specific/` folder inside the framework directory (or user's `.enderun-local/` if they want it in their repo).
+- Record:
+  - Actual architecture decisions made
+  - Team ownership map
+  - Hotspots and anti-patterns discovered
+  - Compliance constraints
+  - "How we do X in this project" conventions
+
+This knowledge becomes more valuable than the general framework knowledge over time.
+
+---
+
+## 5. Manager's Special Responsibility in Large Enterprises
+
+@manager must treat every new large corporate project as a **governance engagement**, not a coding task.
+
+Before writing any code:
+
+- Produce an "Enterprise Context Report" (using the EPDP above).
+- Define the "Minimum Viable Governance Surface" for this engagement.
+- Decide which agents are allowed to touch which domains.
+- Establish the Hermes communication rules between agents for this specific project.
+- Document the "Single Source of Truth" for types and decisions.
+
+Only after this report is accepted (by user or by @manager's own authority audit) may specialist agents be briefed.
+
+---
+
+## 6. Anti-Patterns to Avoid in Enterprise Projects
+
+- Assuming the project is (or should be) a clean monorepo with `apps/backend` + `apps/web`.
+- Creating new top-level directories (`packages/`, `libs/`, `shared/`) without deep analysis.
+- Applying "our reference" patterns (branded types in a specific way, specific folder names) if the project already has a different but working convention.
+- Underestimating the political and process complexity in large organizations.
+
+---
+
+## Enforcement
+
+Any agent that starts suggesting or creating files before completing the Enterprise Project Discovery Protocol on a new large codebase will be considered in violation of D004.
+
+@manager is responsible for immediately correcting and logging such behavior.
+
+---
+
+## Documentation Ownership (Mandatory Rule)
+
+In large-scale enterprise projects, documentation ownership must remain absolutely clear:
+
+- **Framework rules** (mandatory standards) → `.enderun/knowledge/`
+- **User project documentation** (implementation specs, patterns, decisions, toaster/approval workflows, etc.) → **User project's own `docs/` folder**
+
+**Mandatory for all agents:**
+Any document generated for the user's project (research findings, recommendations, architectural decisions, etc.) must be written directly into the user project's own `docs/` directory. Writing these files inside `.enderun/` is strictly forbidden.
+
+Detailed rule: `.enderun/knowledge/documentation_ownership.md`
+
+---
+
+**This document is now part of the permanent constitution.**
+
+All agents must internalize it before working on any project larger than a simple prototype.

package/.enderun/knowledge/frontend_professionalization_guidelines.md

@@ -2,20 +2,20 @@
 
 **Version:** 1.0  
 **Owner:** @manager  
-**Last Updated:** 23 Mayıs 2026
+**Last Updated:** 23 May 2026
 
 ## Purpose
 
-This document defines the official **@frontend Professionalization Program** to close the critical risk item **"@frontend Zayıflığı"** in the Risk Tracking Dashboard.
+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.
+The goal is to elevate the @frontend agent from its current level (6.5) to a true **enterprise-grade** frontend architect (target: 9.0) within 6–8 weeks.
 
-## Current Risk Assessment (23 Mayıs 2026)
+## Current Risk Assessment (23 May 2026)
 
-- **Risk Name:** @frontend Zayıflığı
+- **Risk Name:** @frontend Weakness
 - **Current Level:** 6.5 / 10
 - **Target Level:** 9.0 / 10
-- **Risk Severity:** Kritik / Yüksek Risk
+- **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.
@@ -48,7 +48,7 @@ The goal is to elevate the @frontend agent from its current level (6.5) to a tru
 - 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.
+- Close the "@frontend Weakness" risk item in the Risk Tracking Dashboard upon successful demonstration in a reference application.
 
 ## Mandatory Requirements (Non-Negotiable)
 
@@ -84,25 +84,28 @@ Any task involving @frontend must satisfy the following:
 - 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.
+- Ensure that @frontend strictly follows the Enterprise Adaptation rules in all user projects (see `enterprise_frontend_adaptation.md`).
+- Escalate repeated violations of accessibility, performance, testing, or D004 adaptation standards as leadership failures.
 
-## Success Criteria (Risk Closure)
+## Success Criteria (Risk Closure) — Capability First (Post-D004)
 
-The "@frontend Zayıflığı" risk can be closed when:
+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.
+- @frontend agent consistently applies compound components, accessibility (WCAG 2.2), performance budgets, **Panda CSS as the primary styling system**, and proper testing in **real user projects**.
+- @frontend demonstrates mastery of the Enterprise Frontend Adaptation Framework (`enterprise_frontend_adaptation.md`) — correctly discovering the project and intelligently choosing Panda CSS when possible, while respecting strong existing systems when necessary.
+- Completion Reports show high compliance with both professional patterns **and** the Enterprise Adaptation section, including explicit Panda CSS usage.
+- Measurable improvement is visible in BRAIN_DASHBOARD.md and actual project outcomes over multiple engagements.
+- @frontend no longer proposes blind "ideal" structures and instead intelligently shapes itself to whatever architecture the user already has.
 
 ## Related Documents
 
-- `.enderun/agents/frontend.md` (main definition)
-- `.enderun/knowledge/reference_application_guidelines.md`
+- `.enderun/agents/frontend.md` (main definition + Enterprise Adaptation section)
+- `.enderun/knowledge/enterprise_frontend_adaptation.md` (primary reference for large projects)
 - `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.
+
+**Update Note (24 May 2026):** Success criteria shifted from "prove in reference app" to "prove through consistent, context-aware performance in real enterprise projects" following Decision D004.

package/.enderun/knowledge/frontend_real_battle_test_protocol.md

@@ -0,0 +1,162 @@
+# @frontend Real Battle Test Protocol
+
+**Version:** 1.0  
+**Owner:** @manager  
+**Created:** May 24, 2026  
+**Purpose:** Test, measure, and mature the @frontend agent's new Enterprise Adaptation + Panda CSS rules in real-world corporate projects.
+
+---
+
+## 1. Goal and Scope
+
+This protocol is designed to validate the @frontend agent's theoretical improvements (defined in `enterprise_frontend_adaptation.md` and `frontend.md` updates) in **real battle conditions**.
+
+**Objectives:**
+- Move @frontend from a theoretical 8.0 maturity level to a battle-tested 9.0+ level.
+- Measure how well the agent adapts to diverse corporate contexts.
+- Rapidly identify weaknesses and refine agent prompts and knowledge bases.
+
+---
+
+## 2. Core Principles (Mandatory During Testing)
+
+The following principles **must** be enforced during every real battle test:
+
+1. **D004 - Shaped by User Project Structure** is the supreme priority rule.
+2. **Panda CSS** is the **non-negotiable** styling standard *only for new greenfield developments and isolated components where it does not clash with the host project*.
+   - **Critical Exception Logic:** Under D004 precedence, if a project already has a powerful established styling system (e.g., Tailwind CSS, MUI, styled-components) and setting up Panda CSS would cause build-time complexities, duplicate bundle size overhead, or runtime conflicts, the agent **must not** force Panda CSS. Respect the existing styling patterns.
+3. **Enterprise Frontend Discovery Protocol (EFDP)** must be executed before writing any code.
+4. **Automated Validation Gates:** Do not rely on static "gut-feel" for accessibility or performance.
+   - For accessibility (WCAG 2.2 AA), use static analysis (`eslint-plugin-jsx-a11y`) or component unit tests via `axe-core`.
+   - For performance, verify bundle size impact and prevent unnecessary re-renders using proper state dependency hooks (`useMemo`, `useCallback`, `React.memo`).
+5. **No Self-Assessment Bias:** While @frontend proposes its self-evaluation score (1-10), the final score and approval **must** be audited, adjusted, and validated by `@analyst` (QA) and `@manager` (CTO) to prevent over-optimism.
+6. **Documentation Ownership Compliance:**
+   - Any agent-level general learnings and capability updates belong in `.enderun/knowledge/` or prompt files.
+   - Any project-specific decisions, component architecture documentation, and styling conventions **must** be written directly into the **user project's own `docs/` folder** (never in `.enderun/`), strictly adhering to `documentation_ownership.md`.
+
+---
+
+## 3. Test Categories (Real Battle Scenarios)
+
+Testing must be executed across at least **4 different** scenarios selected from the following categories:
+
+| # | Test Category | Description | Mandatory Panda CSS? | Mandatory EFDP? | Priority |
+|---|---|---|---|---|---|
+| 1 | Greenfield / New Project | Starting from scratch or very minimal existing code. | Yes | Yes | High |
+| 2 | Mid-Large Monorepo (Panda) | Large corporate project already using Panda CSS. | Yes | Yes | High |
+| 3 | Legacy + Different Styling | Tailwind, shadcn/ui, MUI, or custom CSS established. | No (Use Matrix) | Yes | High |
+| 4 | Data-Heavy Dashboard / Admin | Complex tables, forms, high-frequency data streams. | Case-by-case | Yes | High |
+| 5 | Design System Integration | Integrating into a user's pre-existing, strong design system. | No (Use Matrix) | Yes | Medium |
+| 6 | Incremental Migration | Adding new modern components to an old legacy codebase. | Yes (only new parts) | Yes | Medium |
+| 7 | Multi-Team Corporate | Multiple frontend teams with strict file/module ownership. | Case-by-case | Yes | Medium |
+
+---
+
+## 4. Mandatory Process Per Test Session
+
+Each test session must follow these steps in sequential order:
+
+1. **Discovery Phase**
+   - Run the complete EFDP (architecture, design system, component organization, team rules, risks).
+   - Log discovery findings in `PROJECT_MEMORY.md` or a dedicated local project doc.
+2. **Decision Phase**
+   - Apply the Design System Decision Matrix.
+   - Explicitly document the choice: Panda CSS or existing project styling (with solid rationales).
+3. **Implementation Phase**
+   - Strictly follow composition patterns (compound components, render props), accessibility guidelines, performance budgets, and high-risk administrative approval rules.
+4. **Automated Verification Phase**
+   - Execute tests, linter checks, accessibility tests, and inspect bundle sizes.
+5. **Evaluation Phase**
+   - @frontend proposes its own self-evaluation score (1-10) using the rubric below.
+   - `@analyst` performs a strict QA audit, reviews automated test outcomes, and determines the final score.
+6. **Knowledge Extraction & Documentation**
+   - Write general agent capability improvements to `.enderun/knowledge/` (e.g., updates to `enterprise_frontend_adaptation.md`).
+   - Write project-specific styling and component implementation docs directly to the user's `docs/` folder.
+
+---
+
+## 5. Evaluation Framework
+
+Self-evaluation and @analyst audits are scored on a 1-10 scale based on three key pillars:
+
+### Technical Quality (40%)
+- Component Architecture & Composition
+- Accessibility (WCAG 2.2 AA) backed by Axe-core/ESLint
+- Performance & bundle budget compliance
+- Testing quality and coverage
+- Error handling & resilience
+
+### Enterprise Adaptation (40%)
+- Accuracy and depth of initial EFDP discovery
+- Soundness of Design System Matrix decisions (especially concerning Panda CSS exception logic)
+- Strict compliance with legacy patterns and styling conventions
+- Respect for team ownership and boundaries
+
+### Process & Governance (20%)
+- Completion Report quality and objective truthfulness
+- Precise knowledge extraction and adherence to the Documentation Ownership rule
+- Compliance with @manager briefings and high-risk approval workflows
+- General professionalism and communication
+
+**Total Score = Technical (40%) + Adaptation (40%) + Process (20%)**
+
+### Evaluation Thresholds
+
+| Total Score | Outcome | Action Required |
+|-------------|---------|-----------------|
+| 9.0+ | Perfect Fit | Keep rules and prompts as-is. |
+| 8.0 - 8.9 | Good (Minor Gaps) | Suggest small prompt/knowledge tweaks. |
+| 7.0 - 7.9 | Acceptable but Needs Improvement | Plan significant upgrades to capability files. |
+| < 7.0 | Weak | Halt further tests; immediately revise agent prompts and knowledge. |
+
+---
+
+## 6. Documentation Requirements
+
+Each test session must be documented with the following information:
+
+- Project category and size.
+- Core discovery findings (EFDP).
+- Styling decisions and justification.
+- Complete and audited Completion Report.
+- Initial self-score vs. final `@analyst` audited score (with rationale).
+- Challenges encountered and how they were resolved.
+- Actionable recommendations for improving the @frontend agent.
+
+These records must be maintained in `PROJECT_MEMORY.md` and/or a dedicated `frontend_battle_log.md` inside the user project's `docs/` directory.
+
+---
+
+## 7. Success Criteria (Risk Closure)
+
+The "@frontend Weakness" risk item in the Risk Tracking Dashboard can be officially closed only when:
+
+- At least **4 different categories** of real battle tests are executed and documented.
+- The average final audited score across all tests is **8.5+** (with at least 3 tests scoring 8.5 or higher).
+- Zero instances of "Self-Assessment Bias" go uncorrected by `@analyst`.
+- Demonstrated real-world value is added to the user's project (not just theoretical correctness).
+- Explicit approval is given by both `@analyst` and `@manager`.
+
+---
+
+## 8. Continuous Improvement Loop
+
+Every 2-3 test runs:
+1. Identify recurring agent weaknesses and gaps.
+2. Update `.enderun/knowledge/enterprise_frontend_adaptation.md` and/or `.enderun/agents/frontend.md`.
+3. Test updated instructions in subsequent test sessions.
+4. Record progress in the Risk Tracking Dashboard and `PROJECT_MEMORY.md`.
+
+---
+
+## 9. Responsibilities
+
+- **@frontend:** Strictly follow all protocols, propose objective scores, and document implementation.
+- **@analyst:** Audit completion reports, verify metrical performance/accessibility, and issue the final score.
+- **@manager:** Orchestrate tests, manage risk dashboards, and sign off on agent maturity upgrades.
+
+---
+
+**This protocol is the official "battlefield" validation matrix for Agent Enderun's @frontend capability.**
+
+*Ready for execution upon manager approval.*

package/.enderun/knowledge/hermes_live_test_guidelines.md

@@ -2,19 +2,19 @@
 
 **Version:** 1.0  
 **Owner:** @manager  
-**Last Updated:** 23 Mayıs 2026
+**Last Updated:** 23 May 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.
+This document defines the official **Hermes Live Test Program** to close the risk item **"Hermes 'Defined 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ıs 2026)
+## Current Risk Status (23 May 2026)
 
-- **Risk Name:** Hermes “Kağıt Üzerinde”
+- **Risk Name:** Hermes “Defined 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)
@@ -50,7 +50,7 @@ To consider the Hermes protocol "live and proven", the following scenarios **mus
 
 ## Acceptance Criteria (Risk Closure)
 
-The "Hermes Kağıt Üzerinde" risk can be closed only when **all** of the following are true:
+The "Hermes Defined 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.

package/.enderun/knowledge/manager_authority_audit_enforcement.md

@@ -2,7 +2,7 @@
 
 **Version:** 1.0  
 **Owner:** @manager  
-**Last Updated:** 23 Mayıs 2026
+**Last Updated:** 23 May 2026
 
 ## Purpose
 
@@ -12,14 +12,14 @@ Even though strong rules exist in individual agent files, without a systematic a
 
 ## Why This Is Necessary
 
-From the agent control audit (23 Mayıs 2026):
+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 "Tek Giriş Noktası" and "Sıfır Tolerans" principles lose effectiveness.
+Without regular auditing and clear enforcement, the "Single Entry Point" and "Zero Tolerance" principles lose effectiveness.
 
 ## Core Principles
 
@@ -77,10 +77,10 @@ When a violation is detected, @manager must apply the following in order:
 
 This authority system directly supports the closure of multiple risks:
 
-- Referans Uygulama Yokluğu
-- @frontend Zayıflığı
-- Hermes “Kağıt Üzerinde”
-- Gerçek Kullanım Eksikliği
+- No Production-Grade Reference Application
+- @frontend Weakness
+- Hermes “Defined on Paper”
+- Lack of Real Usage Data
 
 Every time a reference application or major task is executed, @manager must run an Authority Audit and record findings.
 
@@ -92,7 +92,7 @@ Every time a reference application or major task is executed, @manager must run
 
 ## Related Documents
 
-- `.enderun/agents/manager.md` → Kurumsal Proje İçin @manager Zorunlu Davranış Kuralları + Hermes Communication Mandate
+- `.enderun/agents/manager.md` → @manager Mandatory Behavior 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`

package/.enderun/knowledge/project_scaffold_guidelines.md

@@ -2,7 +2,7 @@
 
 **Version:** 1.0  
 **Owner:** @manager  
-**Last Updated:** 23 Mayıs 2026
+**Last Updated:** 23 May 2026
 
 ## Purpose
 
@@ -14,8 +14,8 @@ The goal is to move from "empty `apps/` folder" to a **minimal but meaningful pr
 
 @manager should initiate a project scaffold in the following cases:
 
-- The Risk Tracking Dashboard shows **"Referans Uygulama Yokluğu"** as a top-priority open risk.
-- The team needs a concrete starting point to validate governance rules (especially Kurumsal CRUD Yönetişimi and Hermes).
+- The Risk Tracking Dashboard shows **"No Production-Grade 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.
 
@@ -74,7 +74,7 @@ Any project scaffold created with Agent Enderun **must** include at least the fo
 - 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 "Referans Uygulama Yokluğu".
+- After successful completion, update the Risk Tracking Dashboard to reflect progress on "No Production-Grade Reference Application".
 
 ## Success Criteria
 

package/.enderun/knowledge/reference_application_guidelines.md

@@ -2,7 +2,7 @@
 
 **Version:** 1.0  
 **Owner:** @manager  
-**Last Updated:** 23 Mayıs 2026
+**Last Updated:** 23 May 2026
 
 ## Purpose
 
@@ -14,8 +14,8 @@ The goal of a reference application is to **prove** that Agent Enderun’s gover
 
 @manager should initiate a reference application in the following situations:
 
-- The Risk Tracking Dashboard shows **"Referans Uygulama Yokluğu"** as a top-priority open risk.
-- The team needs to validate that new governance rules (especially Kurumsal CRUD Yönetişimi and Hermes) work end-to-end.
+- The Risk Tracking Dashboard shows **"No Production-Grade 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.
 
@@ -38,7 +38,7 @@ Any reference application **must** demonstrate the following:
    - 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. **Kurumsal Yönetişim Compliance**
+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
 
@@ -73,7 +73,7 @@ This scope is small enough to build quickly but rich enough to prove the most cr
 
 - 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 "Referans Uygulama Yokluğu" risk, it may be archived or replaced with a cleaner example.
+- After the reference application successfully closes the "No Production-Grade 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
@@ -81,7 +81,7 @@ This scope is small enough to build quickly but rich enough to prove the most cr
 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 "Referans Uygulama Yokluğu" as **Closed**
+2. Mark "No Production-Grade 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/`
 

package/.enderun/logs/manager.json

@@ -0,0 +1,23 @@
+[
+  {
+    "timestamp": "2026-05-24T08:38:00.000Z",
+    "agent": "@manager",
+    "action": "ORCHESTRATE",
+    "requestId": "01JK5V3A4B5C6D7E8F9G0H1J2K",
+    "status": "SUCCESS",
+    "summary": "Resolved MCP server TypeScript compilation errors, linked the root CLI globally via npm link, and bumped the framework package versions from 0.6.6 to 0.6.7 across both agent-enderun and kentim directories.",
+    "files": [
+      "/Users/ybekar/Desktop/Projeler/agent-enderun/framework-mcp/src/tools/index.ts",
+      "/Users/ybekar/Desktop/Projeler/kentim/framework-mcp/src/tools/index.ts",
+      "/Users/ybekar/Desktop/Projeler/agent-enderun/package.json",
+      "/Users/ybekar/Desktop/Projeler/agent-enderun/framework-mcp/package.json",
+      "/Users/ybekar/Desktop/Projeler/kentim/package.json",
+      "/Users/ybekar/Desktop/Projeler/kentim/framework-mcp/package.json"
+    ],
+    "details": {
+      "typeFix": "Strongly typed allHandlers in tools/index.ts to avoid the forbidden any type while resolving TS2345.",
+      "linking": "Executed npm link globally to expose the agent-enderun CLI command.",
+      "versionBump": "Upgraded all references from 0.6.6 to 0.6.7 across configuration and dependency fields."
+    }
+  }
+]