agent-enderun 0.7.2 → 0.8.0

package/.antigravitycli/knowledge/enterprise_frontend_adaptation.md

@@ -1,232 +0,0 @@
-# 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: `.antigravitycli/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 `.antigravitycli/` (neither `.antigravitycli/docs/` nor `.antigravitycli/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`”) → `.antigravitycli/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 `.antigravitycli/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/.antigravitycli/knowledge/enterprise_project_adaptation.md

@@ -1,168 +0,0 @@
-# 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) → `.antigravitycli/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 `.antigravitycli/` is strictly forbidden.
-
-Detailed rule: `.antigravitycli/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/.antigravitycli/knowledge/frontend_real_battle_test_protocol.md

@@ -1,162 +0,0 @@
-# @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 `.antigravitycli/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 `.antigravitycli/`), 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 `.antigravitycli/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 `.antigravitycli/knowledge/enterprise_frontend_adaptation.md` and/or `.antigravitycli/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/antigravity.md

@@ -1,15 +0,0 @@
-# Agent Enderun — Antigravity Adapter
-
-This file is the entry point for Antigravity CLI. The project's "Supreme Law" and all instructions are located in the following file:
-
-👉 **[.agents/ENDERUN.md](.agents/ENDERUN.md)**
-
-### 🤖 AGENT DIRECTIVE
-You are ALWAYS operating as `@manager` (Team-Lead) by default — on every message, every turn. The user does NOT need to type `@manager`. Typing a specific agent (e.g. `@backend`) explicitly will override this and activate that specialist role directly. You are responsible for analysis and delegation.
-
-⚠️ **CRITICAL STARTUP REQUIREMENT:**
-At the start of every new session/conversation or first turn, before you perform any task or respond to the user:
-1. You **MUST** read `.agents/PROJECT_MEMORY.md` immediately (using the `read_project_memory` tool or the most specific file viewing tool) to restore the project's state, active phase, Trace ID, and recent history.
-2. You **MUST** read `.agents/agents/manager/agent.json` (or the specialist's JSON file in `.agents/agents/{agent_name}/agent.json` if explicitly overridden) to load your role-specific rules, workflows, and checklists.
-
-Please read the Supreme Law thoroughly before taking any action.

package/docs/architecture/decisions/README.md

@@ -1,31 +0,0 @@
-# Architecture Decision Records (ADRs)
-
-Use this directory to store all major architectural and technical choices made during the development of your corporate applications. Storing decisions as markdown-based ADRs creates a strong institutional memory, allowing future developers and AI agents to quickly understand the rationale behind the system's design.
-
----
-
-## 📝 ADR Template
-
-Every new ADR must follow this exact format:
-
-```markdown
-# ADR [ID]: [Title of Decision]
-
-**Date:** YYYY-MM-DD  
-**Status:** [Proposed | Approved | Superseded | Retired]  
-**Author:** [Agent Name | Developer Name]  
-
-## Context
-Provide brief background details regarding the problem we are solving, technical constraints, and why a decision is necessary.
-
-## Decision
-Detail the chosen path, technologies, patterns, or libraries being adopted.
-
-## Consequences
-Outline the positive, negative, and neutral impacts of this decision on the codebase, performance, and maintenance.
-```
-
----
-
-> [!IMPORTANT]
-> **Traceability:** Every ADR must include the active **Trace ID** under which it was generated to maintain 100% development accountability.

package/docs/architecture/notification-strategy.md

@@ -1,38 +0,0 @@
-# Notification Strategy & Toast Patterns
-
-This document defines the central notification patterns for all web applications, ensuring consistent, responsive, and highly accessible user feedback.
-
----
-
-## 🎨 Toast Design Tokens
-
-All notifications must be categorized under these specific fütüristik statuses:
-
-- **SUCCESS (Emerald Green):** For completed asynchronous actions.
-- **ERROR (Ruby Red):** For blocked operations or aborted transactions.
-- **INFO (Neon Blue):** For background jobs and non-blocking events.
-- **WARNING (Amber Orange):** For dangerous or high-risk state mutations.
-
----
-
-## 💻 Technical Integration (Sonner Toaster)
-
-The frontend applications must use the custom Sonner Toaster wrapped in a highly accessible container:
-
-```tsx
-import { toast } from "sonner";
-
-// Standard Success Toast
-toast.success("User role updated successfully.", {
-  description: "Trace ID: 01JK5V3A4B5...",
-  action: {
-    label: "Undo",
-    onClick: () => handleRollback()
-  }
-});
-```
-
----
-
-> [!TIP]
-> **Accessibility:** Every toast notification must carry an explicit `role="alert"` or `role="status"` attribute to ensure compatible screen-reader audio feedback.