agent-enderun 0.6.1 → 0.6.6

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.**

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/framework_vs_user_project_boundary.md

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

@@ -0,0 +1,111 @@
+# 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 **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 @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) — Capability First (Post-D004)
+
+The "@frontend Weakness" risk can be closed when:
+
+- @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 + 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.