agent-enderun 0.7.1 → 0.7.5

package/.antigravitycli/knowledge/deployment_checklist.md

@@ -1,133 +0,0 @@
-# Enterprise Deployment Standard Operating Procedure (DevOps SOP)
-
-**Version:** v0.6.6 | **Ownership:** Human Devs & @manager Oversight
-
-This document is the **Standard Operating Procedure (SOP)** designed to ensure that deliverables produced by AI agents are deployed to production securely, with zero-downtime, and zero-errors by human engineers. Agents generate deliverables based on this guide, and humans execute these steps manually and sequentially.
-
----
-
-## 📋 DEPLOYMENT MATRIX AND APPROVAL CHAIN
-
-| Deployment Phase | Owner | Auditor | Criticality Level | Mandatory Approval |
-| :--- | :--- | :--- | :--- | :--- |
-| **Staging (Test)** | Human Developer | `@analyst` | Low | `@analyst` (AST & Contract MATCH) |
-| **Production (Live)** | Human Engineer (DevOps) | `@manager` | Critical | `@manager` (Trace Approval) + Human CTO |
-
----
-
-## 🔍 PHASE 1: PRE-DEPLOYMENT VALIDATION
-
-Before deciding to deploy to production, verify the following steps in your local environment or CI/CD interface.
-
-### 1.1 Contract and Type Integrity Testing
-Trigger the MCP tools to verify that there is no drift in the backend and frontend types generated by the agents:
-*   [ ] **Contract Integrity Scan:** Run the `verify_api_contract` tool and verify that the output is `MATCH`.
-*   [ ] **Frontend Compatibility Scan:** Run the `validate_frontend_api_contract` tool to ensure frontend hooks align perfectly with backend API contracts.
-
-### 1.2 Quality and Test Gate Control
-Run the following commands to audit test coverage:
-```bash
-# Run backend tests and verify coverage
-npm run test --workspace=backend -- --coverage
-# Run frontend tests and verify coverage
-npm run test --workspace=web -- --coverage
-```
-*   [ ] **Unit & Integration Coverage:** Verify that coverage for critical paths (Auth, Payments, RBAC) is **%85+** and overall codebase coverage is **%75+**.
-*   [ ] **Linter & Biome/ESLint:** Confirm there are zero build or styling errors: `npm run lint`.
-
-### 1.3 Static Security Scanning (SecOps)
-Run static security rules locally or in the remote repository:
-*   [ ] **Secret Scan:** Confirm that there are no hardcoded API keys, private keys, or passwords outside of `.env.production`.
-*   [ ] **AST Security Check:** Run the `security_audit_scan` or `analyze_constitution_compliance` tool to report any occurrences of the `any` type or unsafe `innerHTML` usage.
-
----
-
-## 🗄️ PHASE 2: DATABASE MIGRATION MANAGEMENT
-
-Schema changes (DDL/DML) on production databases are the highest-risk infrastructure operations. Apply the **Expand and Contract** strategy to prevent downtime.
-
-### 2.1 Backward Compatibility and Schema Transition Steps
-*   [ ] **Breaking Change Check:** Never perform destructive operations like dropping columns or changing data types in a single deployment. First, add the new column (Expand), mark the old column as deprecated, migrate the data, and drop the old column in a subsequent deployment (Contract).
-*   [ ] **Dry Run:** Test migration files on a local test database or an isolated staging DB:
-    ```bash
-    npm run db:migrate -- --dry-run
-    ```
-*   [ ] **Backup (Cold/Hot Backup):** Take an instantaneous snapshot of the live database right before running the migration.
-
----
-
-## 📦 PHASE 3: BUILD & BUNDLE BUDGET
-
-Build and audit the production package to verify that the application does not exceed performance budgets.
-
-### 3.1 Frontend Package Analysis
-```bash
-npm run build --workspace=web
-```
-*   [ ] **Bundle Budget Audit:** Verify that the initial load bundle size (Gzipped) is **< 250KB** and no single chunk size exceeds **50KB**.
-*   [ ] **CLS & A11y Protection:** Check that image and dynamic component dimensions are reserved with CSS to prevent Cumulative Layout Shift (CLS) during page load.
-
----
-
-## 🚀 PHASE 4: DEPLOYMENT EXECUTION
-
-Zero-Downtime deployment steps to be followed during the manual deployment by human engineers.
-
-```mermaid
-sequenceDiagram
-  autonumber
-  actor Human as Human DevOps (Yusuf)
-  participant DB as PostgreSQL (Production)
-  participant Old as Live Server (V1)
-  participant New as New Server (V2)
-  participant LB as Load Balancer / Nginx
-
-  Human->>DB: 1. db:migrate (Backward Compatible)
-  Human->>New: 2. Boot V2 Code (Invisible)
-  Note over New: Waiting for Health Check (/health)
-  New->>New: 3. Warm-Up & Connection Tests
-  Human->>LB: 4. Switch Traffic to V2 (Rolling Update)
-  LB->>Old: 5. Disconnect V1 Connections (Graceful Shutdown)
-  Human->>Old: 6. Terminate / Archive Old Server
-```
-
-### 4.1 Step-by-Step Live Deployment Guide
-1.  **Environment Variables:** Confirm that the `.env.production` file is up-to-date and encrypted (stored in Secret Manager) on the target server.
-2.  **Database Migration:** Execute migrations before servers receive traffic:
-    ```bash
-    npm run db:migrate
-    ```
-3.  **Trigger Rolling Update:** Boot the new version (V2) but do not route traffic to it yet.
-4.  **Warm-Up & Health Check:** Route requests to the `/health` endpoint of the new servers to confirm a successful `200 OK` response and verify database pool health.
-5.  **Traffic Routing (Nginx/LB Switch):** Gradually route traffic to V2 servers via the Load Balancer.
-6.  **Graceful Shutdown:** Wait **30 seconds** for old servers (V1) to complete active requests (Graceful Shutdown), then shut down V1 servers.
-
----
-
-## 📊 PHASE 5: POST-DEPLOYMENT MONITORING
-
-Keep monitoring dashboards open for the first **15 minutes** after going live.
-
-*   [ ] **Log Stream (Pino JSON):** Confirm there is no accumulation of `fatal` or `error` level logs on the server logs.
-*   [ ] **SSL & DNS Health:** Verify the validity period of the `https://` protocol and the SSL certificate (confirming at least 30 days remaining) via the browser.
-*   [ ] **Error Rate:** Observe that the `5xx` error rate remains below **%0.1** of total incoming requests.
-
----
-
-## 🚨 PHASE 6: EMERGENCY ROLLBACK PROCEDURE
-
-If a critical error (Memory leak, >1% 5xx errors, DB deadlock) is detected post-deployment, apply the following **60-Second Emergency Rollback** steps without panic.
-
-### 6.1 Emergency Rollback Steps (Max 60 Seconds)
-1.  **Switch Traffic:** Instantly redirect traffic back to the previous stable release (V1 servers) via the Load Balancer / Nginx.
-2.  **Migration Rollback:** If there is a critical, backward-incompatible database error, rollback the migration:
-    ```bash
-    npm run db:rollback
-    ```
-    *(Note: Since schemas are designed to be backward-compatible, in most cases rolling back the code version is sufficient without needing a DB rollback.)*
-3.  **Audit and Trace Logging:** Boot the faulty version on an isolated debug port and inspect logs. Prepare a post-mortem report linked with the `Trace ID` to report the issue to `@manager`.
-
----
-
-### Procedure Verification Declaration
-> ⚠️ **Engineering Note:** Any downtime caused by skipping steps in this guide will be considered an internal process violation. A history entry (HISTORY) must be added to `PROJECT_MEMORY.md` after every successful deployment, including the `@manager` approval.

package/.antigravitycli/knowledge/documentation_ownership.md

@@ -1,122 +0,0 @@
-# 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** | `.antigravitycli/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 `.antigravitycli/` 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 `.antigravitycli/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
-
-- `.antigravitycli/knowledge/enterprise_frontend_adaptation.md` (especially sections 8.1 and 9)
-- `.antigravitycli/agents/frontend.md`
-- `.antigravitycli/agents/backend.md`
-- `.antigravitycli/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/.antigravitycli/knowledge/documentation_ownership_status.md

@@ -1,122 +0,0 @@
-# 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/.antigravitycli/knowledge/enterprise_capabilities_reference.md

@@ -1,149 +0,0 @@
-# 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 `.antigravitycli/` 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") → `.antigravitycli/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 `.antigravitycli/` is forbidden.
-- Reference rule: `.antigravitycli/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)
-
-- `.antigravitycli/ENDERUN.md` — The Constitution
-- `.antigravitycli/PROJECT_MEMORY.md` — Project Memory (SSOT)
-- `.antigravitycli/knowledge/enterprise_project_adaptation.md`
-- `.antigravitycli/knowledge/enterprise_frontend_adaptation.md`
-- `.antigravitycli/knowledge/documentation_ownership.md` (Framework rules vs. user project docs boundary)
-- `.antigravitycli/knowledge/manager_authority_audit_enforcement.md`
-- `.antigravitycli/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