agent-enderun 0.6.5 → 0.6.6

package/.enderun/knowledge/documentation_ownership.md

@@ -0,0 +1,122 @@
+# Documentation Ownership — Framework vs User Project
+
+**Version:** 1.0  
+**Owner:** @manager  
+**Created:** May 24, 2026  
+**Status:** Mandatory Framework Rule
+
+---
+
+## Purpose
+
+In large-scale enterprise projects, it is mandatory to establish clear **ownership** of documentation. Otherwise, framework rules blend with project-specific decisions, causing information noise and rendering the system unmanageable in the long term.
+
+## Core Rule (Mandatory)
+
+| Type | Where to Store? | Who is Responsible? | Description |
+|-----|------------------|--------------|----------|
+| **Framework Rules** | `.enderun/knowledge/` | Agent Enderun (all agents) | Mandatory standards and governance rules that all agents must follow |
+| **User Project Documentation** | User project's own `docs/` folder | @manager + relevant agents (especially @frontend, @backend, @analyst) | Project-specific decisions, implementation details, and patterns |
+
+### Clear Distinction
+
+- **Framework Rule Example:**  
+  “All user notifications, confirmations, and high-risk action feedback **must** be done exclusively through the Toaster.”
+
+- **User Project Decision Example:**  
+  “In this project, the `sonner` library will be used as the Toaster. A custom `ConfirmationToast` component will be developed for admin panel confirmations. Details: `docs/frontend/notifications.md`”
+
+---
+
+## Agent Responsibilities
+
+### General Rule (For All Agents)
+- If an agent generates a new pattern, decision, or standard for the user project, they are **mandated** to write this into the user's own documentation structure.
+- These documents are **never** written inside the `.enderun/` folder.
+
+### @frontend Special Responsibilities
+- Toaster implementation, approval flows, notification rules, component pattern decisions -> Written to `docs/frontend/` or `apps/web/docs/` in the user's project.
+- Documentation for high-risk admin UI flows must also reside in the user's project documentation.
+
+### @backend Special Responsibilities
+- API contract decisions, error handling patterns, audit log standards, migration strategies -> Written to `docs/backend/` or `docs/architecture/` in the user's project.
+
+### @analyst and @manager Responsibilities
+- @manager and @analyst audit the agents to ensure that project-specific documentation is written to the correct location.
+- They actively demand the creation of these documents when necessary.
+
+---
+
+## Recommended Folder Structure (For User Project)
+
+```
+docs/
+├── architecture/
+│   ├── decisions/               # ADRs
+│   ├── approval-flows.md        # managerApproval and high-risk workflows
+│   └── notification-strategy.md # Toaster + notification strategy
+├── frontend/
+│   ├── component-patterns.md
+│   ├── notifications.md         # Toaster implementation and rules
+│   └── forms.md
+├── backend/
+│   ├── error-handling.md
+│   └── audit-logging.md
+└── README.md
+```
+
+> **Note:** If the user project already uses a different documentation structure (e.g., `docs/arch/` or `docs/adr/`), the agents will adapt to that structure. The key requirement is that it must reside "inside the user project's own docs/ structure".
+
+---
+
+## Concrete Examples
+
+### Example 1: General Good vs Bad Approach
+
+**Bad Approach (Forbidden):**
+@explorer discovered a massive set of technical debt in a project. They wrote this into `.enderun/knowledge/technical_debt.md`.
+
+→ **Incorrect.** This information belongs to the user's project.
+
+**Good Approach (Correct):**
+After making the same discovery, @explorer wrote the findings into `docs/architecture/technical-debt.md` in the user's project and referenced the relevant team.
+
+---
+
+### Example 2: Good Example for @frontend
+
+@frontend designed a custom approval workflow for high-risk admin actions in an enterprise project.
+
+**Correct Behavior:**
+- Created a new component (`ConfirmationModal`).
+- Documented how to use this component and under what conditions it requires `managerApproval` in the `docs/frontend/approval-flows.md` file.
+- Placed details of the toaster implementation (which library, which variants, accessibility rules) inside `docs/frontend/notifications.md`.
+
+---
+
+### Example 3: Good Example for @backend
+
+@backend defined the audit log strategy and error handling patterns in a project.
+
+**Correct Behavior:**
+- Documented the audit log structure and which operations should be logged in `docs/backend/audit-logging.md`.
+- Detailed the `DomainError` hierarchy and its usage rules inside `docs/backend/error-handling.md`.
+- Did not just leave these decisions in code; they documented them professionally.
+
+---
+
+These examples demonstrate how agents should write project-specific decisions to the user's own documentation structure rather than polluting framework folders.
+
+---
+
+## Related Documents
+
+- `.enderun/knowledge/enterprise_frontend_adaptation.md` (especially sections 8.1 and 9)
+- `.enderun/agents/frontend.md`
+- `.enderun/agents/backend.md`
+- `.enderun/agents/analyst.md`
+- `ENDERUN.md` -> Framework vs User Project Boundary rule
+
+---
+
+**This document is one of the foundational rules for maintaining documentation discipline in large enterprise projects with Agent Enderun.**

package/.enderun/knowledge/documentation_ownership_status.md

@@ -0,0 +1,122 @@
+# Documentation Ownership — Implementation Status
+
+**Owner:** @manager  
+**Last Updated:** May 24, 2026  
+**Purpose:** Show the actual, system-wide implementation status of the Documentation Ownership rule (requiring user project documents to reside exclusively in the user's `docs/` folder).
+
+---
+
+## 1. General Maturity Level
+
+| Area | Score (10/10) | Comment |
+|------|--------------|---------|
+| Rule defined at constitutional level | 8.5 | Added to `ENDERUN.md` as a "Zero Tolerance" clause |
+| Quality of the central rule document | 9.0 | `documentation_ownership.md` is well-structured and contains concrete examples |
+| Presence of rule in agent definitions | 8.0 | Documented in all 8 agent prompts |
+| Auditability in Completion Reports | 7.5 | Present in most agents, but still weak in some |
+| Necessity in startup protocols | 6.0 | Actively referenced in only 3 agent startup flows |
+| Real enforcement | 4.5 | Strong on paper, but currently weak in practical enforcement |
+| **Overall System Maturity** | **7.2** | **Progressing well, but not yet fully "mature and coercive"** |
+
+---
+
+## 2. Detailed Agent Status (May 24, 2026)
+
+| Agent | Rule Text | Completion Report | Startup Protocol | Consistency | Note | Score |
+|------------|-------------|-------------------|-------------------|------------|-----|------|
+| **@manager** | Strong | Present | Present | Good | One of the best-performing agents | 8.5 |
+| **@frontend** | Very Strong | Clean | Present | Very Good | Most detailed and clean agent | 9.0 |
+| **@backend** | Strong | Present | Present | Good | Solid level | 8.0 |
+| **@analyst** | Mid-Good | Present | Partial | Medium | Included inside Memory Management | 6.5 |
+| **@explorer** | Good | Present | Present | Good | Referenced in Startup Protocol | 7.5 |
+| **@git** | Good | Present | None | Good | Newly added, reasonable | 7.0 |
+| **@mobile** | Basic | Present | None | Weak | Basic level only | 4.5 |
+| **@native** | Basic | Present | None | Weak | Basic level only | 4.5 |
+
+**Important Note:** The @mobile and @native agents represent the weakest links in this implementation.
+
+---
+
+## 3. Critical Files Status
+
+| File | Status | Evaluation |
+|-------|-------|---------------|
+| **ENDERUN.md** | Strong | Contains the "Zero Tolerance" clause |
+| **documentation_ownership.md** | Very Good | Central document is high quality with added examples |
+| **enterprise_project_adaptation.md** | Good | Referenced as a general rule |
+| **enterprise_frontend_adaptation.md** | Very Good | The most detailed and well-crafted document |
+| **enterprise_capabilities_reference.md** | Medium | Mentioned as a reference |
+| **@manager.md** | Good | Present in Mandatory References + Startup Protocol |
+| **frontend.md** | Very Good | Duplications cleaned up, the most mature agent |
+| **backend.md** | Good | Contains Startup Protocol + Completion Report |
+| **explorer.md** | Good | Referenced in the Startup Protocol |
+| **analyst.md** | Medium | Present only inside Memory Management |
+
+---
+
+## 4. Remaining Weak and Risky Areas
+
+### High-Risk Deficiencies
+
+1. **@mobile and @native Agents**  
+   - The rule only exists at a "basic" level. These agents could create significant inconsistencies when deployed on corporate projects.
+
+2. **Weakness in Session Startup Protocols**  
+   - The Session Startup Protocols for @analyst, @git, @mobile, and @native agents do not reference this central document.
+
+3. **Lack of Real-World Enforcement**  
+   - The rule is strong on paper, but @manager lacks a concrete mechanism to systematically audit this during turns.
+
+4. **Missing from "Mandatory References" Lists**  
+   - For several agents, this document is still not officially listed in their "Mandatory References" section.
+
+### Medium-Level Risks
+
+- Some Completion Report items are still written too generally.
+- The rule needs a stronger emphasis in "document-heavy" agents like @explorer and @analyst.
+
+---
+
+## 5. Completed vs. Remaining Work
+
+### Completed Tasks (May 24, 2026)
+
+- Rule added to `ENDERUN.md` (strong version)
+- Central document (`documentation_ownership.md`) created and enriched with examples
+- Rule text added to all 8 agent definitions
+- Control item added to 6 agent Completion Reports
+- References added to startup protocols for @manager, @frontend, @backend, and @explorer
+- Duplications cleaned up (especially in `frontend.md`)
+
+### Remaining High-Priority Work
+
+| Task | Priority | Difficulty | Owner |
+|----|---------|--------|-------|
+| Elevate @mobile and @native agents to match other agents | High | Medium | @manager |
+| Add references to @analyst, @git, @mobile, and @native Startup Protocols | High | Low | @manager |
+| Add to the "Mandatory References" list for all agents | High | Low | @manager |
+| Define a real-world enforcement/audit mechanism | High | High | @manager |
+| Enrich `documentation_ownership.md` with more examples | Medium | Low | @manager |
+| Add rule to the @manager audit checklist | High | Medium | @manager |
+
+---
+
+## 6. Recommended Next Steps (In Order of Priority)
+
+1. **Elevate @mobile and @native agents** to the same level as other agents on this standard (most urgent).
+2. Add references to Session Startup Protocols for the remaining agents.
+3. Integrate this rule into @manager's regular Authority Audit process.
+4. Enrich the `documentation_ownership.md` file with more real-world examples.
+5. Periodically update this report (after each major agent capability upgrade).
+
+---
+
+**Conclusion:**
+
+The Documentation Ownership rule is now **active in the system** and significantly reinforced. However, to reach **full maturity**, further work is required, particularly regarding the @mobile and @native agents and the establishment of concrete enforcement mechanisms.
+
+This status report should be used to track whether the rule remains strong in actual practice, not just on paper.
+
+---
+
+**Last Updated:** May 24, 2026 — @manager

package/.enderun/knowledge/enterprise_capabilities_reference.md

@@ -0,0 +1,149 @@
+# Agent Enderun — Enterprise / Large-Scale Project Capabilities Reference
+
+**Version:** v0.6.5+  
+**Owner:** @manager  
+**Last Updated:** May 24, 2026  
+**Status:** ACTIVE  
+**Related Decision:** D004 — Agent Capability First (May 23, 2026)
+
+---
+
+## 1. Purpose
+
+This document defines in a single reference point the current capabilities, mandatory rules, and known limitations of the **Agent Enderun** multi-agent system when operating inside **large-scale, complex, enterprise codebases with legacy software**.
+
+Objective: Enable any enterprise engineering team (or individual developer) entering the codebase to quickly understand Agent Enderun's realistic strengths and weaknesses.
+
+---
+
+## 2. Core Philosophy (Non-Negotiable Principle)
+
+> **"Shape yourself to the user's project."**
+
+- No agent shall impose its own reference architecture, folder layout, or technology preferences on the user's codebase.
+- The agent must first discover the existing system deeply (architecture, design system, team conventions, technical debt).
+- It must then adapt its code placements and styling patterns.
+- Only then may it propose low-risk, targeted improvements.
+
+This principle (D004) represents the operational backbone of all agent behaviors as of May 2026.
+
+---
+
+## 3. Current Live Capabilities (May 2026)
+
+### 3.1 Discovery and Adaptation
+- **Enterprise Project Discovery Protocol (EPDP)** — Mandatory steps executed before modifying any codebase (root detection, monorepo/polyrepo separation, type contract source of truth, tech stack mapping, domain and team ownership, risk inventory).
+- **Enterprise Frontend Adaptation Protocol (EFDP)** — Maps existing UI organization, design system, shared component location, and team processes. Includes a decision matrix for realistic enterprise scenarios (Tailwind, shadcn/ui, MUI, Panda CSS, packages/ui).
+- **Architecture Discovery Protocol (ADP)** — Analyzes entry points, domain logic, and API contracts.
+
+### 3.2 Management and Control
+- **@manager as Single Entry Point** — In enterprise projects, no user request or agent invocation goes directly to a specialist agent. @manager intercepts every turn, assesses risks, and distributes formal briefings.
+- **High-Risk Administrative Operations** — Operations involving user/permission management, bulk deletes, system config changes, audit log exports, or payment integrations are blocked without @manager approval + the formal `managerApproval` object.
+- **Manager Authority Audit & Enforcement** — A formal checklist and procedure for @manager to audit its own authority and correct specialist agent bypass attempts.
+
+### 3.3 Intelligence and Analysis (MCP Tools)
+- Codebase semantic search (`search_codebase`)
+- Deep dependency analysis and dependency graph generation
+- Contract integrity validation (`verify_api_contract`, `verify_contract_integrity`)
+- Database schema analysis and Mermaid ER diagram generation
+- AST-based security scanning (detecting hardcoded secrets, raw SQL, and unsafe patterns)
+- Blueprint-driven construction for reusing high-quality architectural patterns
+- Repository health check and semantic git commit generation
+
+### 3.4 Inter-Agent Coordination
+- **Hermes Messaging Protocol** — Formal messaging structure (timestamp, from/to, category, priority, traceId, content, status).
+- 4 messaging categories: ACTION, DELEGATION, INFO, ALERT.
+- Message lifecycle: Dispatch → Notification → Acknowledgment.
+
+### 3.5 Security, Risk, and Audit
+- Mandated Trace ID + audit log entry for every critical operation.
+- Automated memory and log updates via `log_agent_action` and `update_project_memory` tools.
+- Constitution compliance analysis.
+- Mandatory rollback plans for all high-risk administration actions.
+
+### 3.6 Memory and Continuity
+- `PROJECT_MEMORY.md` — Single Source of Truth (SSOT) structured with CURRENT STATUS, CRITICAL DECISIONS, ACTIVE TASKS, and HISTORY.
+- File lock mechanism to prevent race conditions during memory updates.
+- Mandatory, audited memory updates at the end of every user session.
+
+---
+
+## 4. Mandatory Protocols (Enterprise Standards)
+
+The following protocols are **non-negotiable** in enterprise-scale codebases:
+
+1. Enterprise Project Discovery Protocol (EPDP)
+2. Enterprise Frontend Adaptation Protocol (EFDP)
+3. Manager Authority Audit & Enforcement
+4. High-Risk Administrative Action Briefing + `managerApproval` generation
+5. Hermes Protocol (for all inter-agent delegations and communications)
+6. Zero Mock + Contract-First + Branded Types
+7. Framework vs User Project Boundary (agents only modify the user's project, never framework files under `.enderun/` or `framework-mcp/`)
+
+---
+
+## 5. Agent Maturity Levels (May 24, 2026)
+
+| Agent | Current | Target | Priority | Status Note |
+|------------|--------|--------|-----------|-----------------------------------------|
+| @manager | 8.0 | 9.5 | High | Authority Audit system is active |
+| @backend | 7.5 | 9.0 | High | Testing culture and resilience patterns are being hardened |
+| @frontend | 6.5 | 9.0 | Critical | 8-week Professionalization Program is active |
+| @analyst | 6.5 | 8.5 | Medium | Governance audit capabilities are being improved |
+| @explorer | 6.5 | 8.5 | Medium | Risk area reporting is mandatory |
+| @git | 6.0 | 8.0 | Medium | High-risk commit controls added |
+| @mobile | 2.0 | 8.0 | Low | Dormant (basic SOP in place) |
+| @native | 2.0 | 8.0 | Low | Dormant (basic SOP in place) |
+
+---
+
+## 6. Known Limits and Risks (Honest Assessment)
+
+- **Lack of Reference App** — A full round-trip has not yet been demonstrated in an active production-grade reference app (highest risk).
+- **Hermes Live Test Gap** — The protocol is defined on paper, but the 4 mandatory live scenarios have not been run between autonomous agents in production.
+- **Academy Performance Data** — Success rate, velocity, and quality metrics are currently simulated.
+- **Frontend Professionalization** | Practical experience is limited in complex legacy environments with mixed styling solutions.
+- **Long-Term Production Usage** — The system has not yet been proven in corporate codebases over months of active human-AI co-development.
+
+---
+
+## 7. Recommended Use-Cases in Large Projects
+
+### Documentation Ownership (Mandatory Rule)
+- Framework rules (e.g., "all notifications must use Toaster") → `.enderun/knowledge/`
+- User project documentation (implementation specs, modal details, project styling conventions) → **User project's own `docs/` folder**.
+- Agents must write project documentation into the user's `docs/` folder. Writing to `.enderun/` is forbidden.
+- Reference rule: `.enderun/knowledge/documentation_ownership.md`
+
+### Monorepo & Multi-Team Environments
+- @manager remains the single point of entry.
+- Domain-based delegation is enforced.
+- Separate Trace IDs and briefings are mandatory for each distinct domain.
+
+### Legacy & Mixed Tech Stack Projects
+- EPDP and EFDP **must** be executed as the very first step.
+- The existing design system (Tailwind, MUI, etc.) is accepted. Proposing a new styling solution is allowed only with written @manager approval.
+
+### Highly Regulated Environments (KVKK, GDPR, PCI, SOC2)
+- All high-risk administrative operations are restricted to @manager + human developer dual-approvals.
+- Audit logs are centralized, immutable, and exportable.
+
+---
+
+## 8. Related Documents (Mandatory Reading)
+
+- `.enderun/ENDERUN.md` — The Constitution
+- `.enderun/PROJECT_MEMORY.md` — Project Memory (SSOT)
+- `.enderun/knowledge/enterprise_project_adaptation.md`
+- `.enderun/knowledge/enterprise_frontend_adaptation.md`
+- `.enderun/knowledge/documentation_ownership.md` (Framework rules vs. user project docs boundary)
+- `.enderun/knowledge/manager_authority_audit_enforcement.md`
+- `.enderun/knowledge/hermes_protocol.md`
+- `docs/action-plan-2026.md`
+- `docs/roadmap.md`
+
+---
+
+*Note: This document reflects the realistically proven and enforceable capabilities of Agent Enderun as of May 2026, rather than its theoretical potentials. It will be updated as new milestones (reference app completion, Hermes live tests, long-term corporate usage) are successfully hit.*
+
+Last Updated: May 24, 2026 — @manager

package/.enderun/knowledge/enterprise_frontend_adaptation.md

@@ -0,0 +1,232 @@
+# Enterprise Frontend Adaptation Framework
+
+**Version:** 1.0  
+**Owner:** @manager  
+**Created:** May 24, 2026  
+**Purpose:** Elevate the @frontend agent to professional-grade maturity (9.0+) in large, complex, and legacy corporate projects. This document translates the "shape yourself to the user's project" (D004) principle into concrete, enforceable frontend rules.
+
+---
+
+## 1. Core Philosophy (Non-Negotiable Rules)
+
+The single greatest mistake in enterprise frontend development is imposing "our way" of doing things on an established system.
+
+**Supreme Rule for @frontend:**
+
+> **"Shape yourself to the user's existing project. Work within the established structure, maintain the existing quality thresholds, and respect the conventions of the active development teams."**
+
+This means:
+- If a project already uses Tailwind CSS + shadcn/ui, **do not** try to force the "Zero UI Library" rule.
+- If a project uses a feature-sliced or domain-driven folder layout, **do not** suddenly dictate placing all components in a flat `ui/` directory.
+- If a project is a massive monorepo and `packages/ui` already exists, **do not** blindly apply the "no shared package creation" rule; adapt to their setup with @manager oversight.
+- If the codebase is legacy, **do not** force a complete rewrite into modern compound component patterns.
+
+**The Primary Mission of @frontend:** Accept the reality of the existing system and build the **most professional, accessible, and performant** solutions possible within that specific context.
+
+---
+
+## 2. Enterprise Frontend Discovery Protocol (EFDP)
+
+When entering a new or unknown large corporate project, @frontend **must never** start writing code immediately. It must first execute the following discovery protocol.
+
+### 2.1 Architectural Discovery (Mandatory)
+
+- **Identify the existing UI organization pattern:**
+  - Feature-based (e.g., `/features/users`, `/features/orders`)
+  - Technical layer (e.g., `/components`, `/pages`, `/hooks`)
+  - Domain-driven
+  - Hybrid
+- **Locate where shared components reside:**
+  - `src/components/ui/`
+  - `packages/ui/`
+  - `libs/design-system/`
+  - Elsewhere?
+- **Detect design tokens and the styling system in use:**
+  - Panda CSS
+  - Tailwind CSS + custom configuration
+  - SCSS + design tokens
+  - CSS-in-JS (Emotion, styled-components)
+  - Other?
+- **Determine component library status:**
+  - No library (fully custom)
+  - Project-internal custom component sets
+  - Popular library usage (MUI, Ant Design, shadcn/ui, Chakra UI, etc.)
+  - In-house corporate design system
+
+### 2.2 Team and Process Discovery
+
+- Who actively maintains this frontend codebase? (Single team vs. multiple distinct teams?)
+- How are design system changes managed? (Is there an RFC process? How are reviews handled?)
+- Are there established accessibility and performance standards? (Is there a checklist or active performance budget?)
+- What is the testing culture? (Cypress, Playwright, Vitest + React Testing Library, or no tests?)
+
+### 2.3 Risks and Constraints Discovery
+
+- Which pages are performance-critical? (Dashboards, reporting panels, admin consoles?)
+- Where is PII and sensitive data displayed?
+- Is mobile responsiveness or native shell support (e.g., PWA, React Native shell) mandatory?
+- What are the legacy browser support requirements? (Old Safari, legacy corporate browsers, etc.)
+
+---
+
+## 3. Design System & Component Library Decision Matrix
+
+This matrix governs one of the most critical integration decisions in enterprise work:
+
+| Existing System | Mandatory @frontend Behavior | @manager Approval Required? |
+|-----------------|-----------------------------|-----------------------------|
+| No design system | Scaffolds the 8-10 core components (Button, Input, Modal, Table, Card, etc.) using Panda or the existing styling engine | No (Initial bootstrap) |
+| Project-internal `components/ui` exists | **Reuse** existing components, write new components in the same directories using identical patterns | No |
+| `packages/ui` or `libs/design-system` exists | Accept this package as the **primary source of truth**. Propose additions to this package only with @manager approval | Yes (Written approval) |
+| Popular library in use (MUI, AntD, shadcn) | Do not suggest "re-writing it". **Accept** the library and write thin, accessible wrappers on top | Yes (Major architectural decision) |
+| Tailwind + shadcn/ui combination | Flexible Zero UI Policy. Work smoothly within the established Tailwind/shadcn ecosystem | Yes (Written approval) |
+
+**Golden Rule:** Never adopt a "this project was designed incorrectly, we must fix it" attitude. Focus on adding value to the existing investment.
+
+---
+
+## 4. Incremental Adoption in Legacy & Large Codebases
+
+Most enterprise codebases contain legacy modules. @frontend must follow these rules strictly:
+
+### 4.1 Incremental Migration Rules
+
+- **Never** propose "rewriting the entire UI".
+- When writing a new feature or page:
+  - Reuse existing components where possible.
+  - If a new component is mandatory, position it as the **new standard** (designed to slowly phase out legacy ones).
+- If a massive page is being redesigned, modernize it **piece by piece** (Strangler Fig Pattern).
+- Never independently undertake dropping legacy components. This requires an explicit @manager briefing + a migration plan.
+
+### 4.2 "Modern Islands" Strategy
+
+Every high-quality, accessible component or hook you write serves as a "modern island" in that project. Over time, other developers adopt these patterns. This is the most effective and lowest-risk modernization strategy.
+
+---
+
+## 5. Data-Heavy Enterprise UI Standards
+
+The most complex areas in enterprise apps are dashboards, admin panels, complex forms, and massive data tables.
+
+### Mandatory Standards
+
+- **Tables:** Always evaluate virtualization (TanStack Table + react-window or similar). Virtualization is mandatory if displaying 50+ rows.
+- **Forms:** For complex forms (10+ fields), a form state management library (react-hook-form + zod is recommended) must be used. Manual state management is forbidden.
+- **Dashboards:**
+  - Progressive loading, streaming, or Suspense is mandatory for heavy data-fetching panels.
+  - Each widget must independently manage its loading and error states.
+- **Admin Panels:** High-risk actions must integrate a confirmation modal and @manager approval workflows (as defined in agent protocols).
+
+---
+
+## 6. Performance and Accessibility in the Enterprise Context
+
+### Performance
+
+- Bundle size analysis must be executed for every major new feature.
+- Code splitting (route-level + component-level dynamic imports) is mandatory in large-scale apps.
+- Image optimization and proper font loading must be evaluated in every project.
+- Core Web Vitals targets (LCP < 2.5s, INP < 200ms, CLS < 0.1) serve as the benchmark; projects set realistic budgets.
+
+### Accessibility (WCAG 2.2 AA)
+
+- Keyboard navigation and focus trap management are heavily checked in complex UI layers (modals, slide-out drawers, custom dropdowns).
+- ARIA usage is verified for correctness, not just presence (no ARIA is better than bad ARIA).
+- Color contrast ratios and touch target minimums (44x44px) are non-negotiable.
+
+---
+
+## 7. Testing in Large Corporate Projects
+
+Testing discipline is critical because the ripple effect of changes in large projects is vast.
+
+**Mandatory Rules:**
+- Component tests must be written for every newly introduced shared component.
+- Integration tests must be written for critical admin and financial checkout flows.
+- Visual regression testing (e.g., Chromatic, Percy) must be evaluated at the design system level if budget and processes exist.
+- Automated gates must flag contract breaking changes immediately when frontend tests fail.
+
+---
+
+## 8. Enterprise RED LINES for @frontend
+
+The following actions are **strictly forbidden**:
+
+- Writing code in your own custom style while ignoring the project's existing design system or component library.
+- Proposing or creating a new `packages/ui` or `libs/design-system` in a monorepo without explicit @manager approval.
+- Initiating a massive migration in a legacy codebase to "modernize everything" without prior authorization.
+- Criticizing or dismissing a working, established UI library (MUI, AntD, etc.) as "bad" or "legacy".
+- Exposing high-risk admin actions on the UI without hooking them to @manager briefings and approval checks.
+
+### 8.1 User Notification & Feedback Standards (Mandatory Toaster)
+
+User feedback must be **centralized and consistent** in enterprise environments.
+
+**Mandatory Rule:**
+- All user notifications (success, error, warning, info), confirmation dialogues, high-risk warnings, and `managerApproval` status feedback **must** be routed exclusively through the Toaster.
+- Using `window.alert()`, `window.confirm()`, or custom non-toaster alert components is **strictly forbidden**.
+- In high-risk workflows, inform users with clear, accessible, and consistent toaster messages.
+- The toaster implementation must comply with accessibility guidelines (correct ARIA live regions, keyboard support).
+
+---
+
+## 9. Documentation Ownership: Framework vs. User Project
+
+Documentation ownership must remain absolutely clear in large projects:
+
+### Framework Documentation (Agent Enderun)
+- Location: `.enderun/knowledge/`
+- Content: **Mandatory rules**, patterns, and governance standards that all agents must follow across any project.
+- Examples:
+  - Notification Toaster requirement
+  - Zero UI Library policy definitions
+  - `managerApproval` workflow guidelines
+  - Enterprise Frontend Adaptation rules
+
+### User Project Documentation
+
+The user's application must maintain its own technical decisions, folder conventions, and style rules **within its own folder structure**.
+
+**Mandatory Rule:**
+- @frontend (and all other agents) must write all documents generated for the user's project (architecture decisions, toaster setup, modal details, component patterns, etc.) **directly into the user project's own `docs/` folder**.
+- These documents are **never** written inside `.enderun/` (neither `.enderun/docs/` nor `.enderun/knowledge/`).
+
+**Recommended Locations (Inside the User Project):**
+- General architecture decisions and ADRs → `docs/` (project root)
+- Frontend-specific guidelines and patterns → `docs/frontend/` or `apps/web/docs/`
+- Backend-specific standards → `docs/backend/`
+- Project toaster integration details and confirmation modal specs → `docs/frontend/notifications.md` or `docs/architecture/approval-flows.md`
+
+**Key Boundary Distinction:**
+- **Framework Rules** (e.g., “All notifications must use the Toaster,” “High-risk actions require `managerApproval`”) → `.enderun/knowledge/`
+- **User Project Implementation** (e.g., which toaster library is installed, how custom modals are built, approval flows layout) → User project's own `docs/` directory
+
+**Agent Responsibility:**
+@frontend must actively generate and maintain these project-specific docs within the user's `docs/` folder. A professional agent delivers not just code, but sustainable, well-documented systems.
+
+---
+
+## 10. Enforcement and Responsibility
+
+- This framework will be integrated directly into `frontend.md` and enforced as **mandatory**.
+- If @frontend fails to comply with these rules, the task is marked as "incomplete".
+- @manager, @analyst, and @explorer actively audit compliance.
+- For every major task, @frontend must submit the "Enterprise Adaptation Checklist".
+
+---
+
+## 11. Maturity Roadmap
+
+Enforcing this framework systematically increases @frontend's corporate readiness score:
+- Initial: 6.5/10
+- Target (Post-integration & testing): 9.0/10
+
+**Next Actions:**
+1. Integrate this framework directly into `.enderun/agents/frontend.md` as core instructions.
+2. Align `frontend_professionalization_guidelines.md` with these directives.
+3. Establish the Enterprise Frontend Adaptation Checklist.
+4. Log progress in the Risk Tracking Dashboard under "@frontend Weakness".
+
+---
+
+**This framework is the cornerstone of @frontend's transition to a truly professional, enterprise-ready agent.**