agent-enderun 1.10.4 → 1.11.1

package/templates/prompts/contract-design-recipe.md

@@ -0,0 +1,21 @@
+# 📜 Engineering Recipe: Contract-First Design
+
+This recipe governs the @architect agent's protocol for creating type-safe agreements between system layers.
+
+## 🏁 Phase 1: Requirement Alignment
+1.  **Analysis:** Read user requirements and Business Analyst (@analyst) reports.
+2.  **Scope Discovery:** Identify the domain objects, actions, and events required for the feature.
+
+## 📐 Phase 2: Technical Modeling
+1.  **Branded Types:** Define semantic IDs in `src/types/brands.ts` (e.g., `OrderId`, `ProductSKU`).
+2.  **Domain Models:** Create or update interfaces in `src/types/models.ts`. Ensure they extend `BaseEntity`.
+3.  **Constants:** Update `src/types/constants.ts` for enums and fixed state values.
+
+## 🔏 Phase 3: Hash Sealing
+1.  **Integrity Check:** Run `agent-enderun verify-contract` to check existing state.
+2.  **Commitment:** Run `agent-enderun update-contract` to generate new SHA-256 signatures for the updated types.
+3.  **Audit:** Verify that `contract.version.json` accurately reflects the new architecture.
+
+## 📡 Phase 4: Synchronization
+1.  **Distribution:** Ensure the updated `src/types` directory is correctly linked or copied to both Frontend and Backend projects.
+2.  **Verification:** Trigger @backend and @frontend agents to read the new contract and plan their implementations.

package/templates/prompts/db-management-recipe.md

@@ -0,0 +1,25 @@
+# 🗄️ Engineering Recipe: Database Management & Migrations
+
+This recipe governs the @database agent's protocol for schema creation, table modifications, and data integrity.
+
+## 📐 Phase 1: Contract-First Definition
+1.  **Type Mapping:** Define the new table or column in `src/types/models.ts` using Branded Types for IDs.
+2.  **Validation:** Ensure the interface extends `BaseEntity` (id, createdAt, updatedAt).
+
+## 🚀 Phase 2: Migration Generation
+1.  **Scripting:** Write a reversible migration (up/down) using the project's migration tool (e.g., Kysely or SQL).
+2.  **Atomic Changes:** One migration per logical feature. Never bundle unrelated schema changes.
+3.  **Naming:** Use timestamp-prefixed naming (e.g., `20240101_add_customers_table.ts`).
+
+## 🧱 Phase 3: Infrastructure Setup (If New DB)
+1.  **Initialization:** Verify the connection string in `.env`.
+2.  **Health Check:** Run `check_active_ports` to ensure the DB engine is reachable.
+
+## 🛠️ Phase 4: Implementation & Repository Update
+1.  **Repo Layer:** Create or update the Repository class to include the new query logic.
+2.  **Strict Mode:** Ensure no raw SQL is used; leverage the query builder exclusively.
+
+## ✅ Phase 5: Verification & Zero-Downtime Audit
+1.  **Dry Run:** If supported, dry-run the migration to check for locking issues.
+2.  **Validation:** Run `agent-enderun verify-contract` to ensure code and schema are synced.
+3.  **Handoff:** Update `PROJECT_MEMORY.md` with the new schema version.

package/templates/prompts/deployment-recipe.md

@@ -0,0 +1,23 @@
+# 🚀 Engineering Recipe: Infrastructure Deployment
+
+This recipe governs the @devops agent's protocol for safe, traceable, and reversible system rollouts.
+
+## 🏁 Phase 1: Pre-Deployment Environment Audit
+1.  **Integrity Check:** Run `agent-enderun check` to ensure all discipline rules are met.
+2.  **Health Scan:** Execute `get_system_health` and `check_active_ports` on the target environment.
+3.  **Config Sync:** Verify that all keys in `.env.example` are present in the target environment's secrets manager.
+
+## 🧱 Phase 2: Build & Validation
+1.  **Compilation:** Run `npm run build` and capture any stderr.
+2.  **Contract Verify:** Run `agent-enderun verify-contract` to ensure FE/BE synchronization.
+3.  **Test Suite:** Execute the full test battery. Failure in a single test blocks deployment.
+
+## 📡 Phase 3: Controlled Rollout
+1.  **Atomic Swap:** Deploy the new bundle/service using the project's orchestration scripts.
+2.  **Database Sync:** If migrations are pending, follow the `db-management-recipe.md` first.
+3.  **Log Monitoring:** Tail `logs/manager.json` for immediate post-deploy spikes in errors.
+
+## ✅ Phase 4: Post-Deploy & Rollback Readiness
+1.  **Observability:** Verify system metrics stabilize within 5 minutes.
+2.  **Traceability:** Record the deployment Trace ID and commit hash in `PROJECT_MEMORY.md`.
+3.  **Rollback Check:** Ensure the previous stable version is tagged and reachable in Git.

package/templates/prompts/new-feature-recipe.md

@@ -0,0 +1,19 @@
+# ✨ New Feature Development Recipe
+
+The "Nizam-ı Enderun" steps to follow when adding a new module or feature.
+
+## 1. Contract Design (Phase 1)
+- First, update the `contract.version.json` file and the relevant TypeScript types.
+- Do not start writing code without getting approval from `@architect`.
+
+## 2. Mock-Free Development (Phase 2)
+- Add the new feature to the correct directory under `apps/backend` or `apps/web`.
+- If database changes are required, coordinate with the `@database` agent.
+
+## 3. Responsive & i18n (Phase 3)
+- Use `{ base: '...', md: '...' }` responsive syntax in frontend developments.
+- Move all texts to the `locales/` directory immediately.
+
+## 4. Completion (Phase 4)
+- Ensure no TODOs remain using `get_project_gaps`.
+- Verify that you haven't created any new package pollution with `audit_dependencies`.

package/templates/prompts/performance-optimization-recipe.md

@@ -0,0 +1,23 @@
+# ⚡ Engineering Recipe: Performance Optimization
+
+This recipe governs the protocol for identifying and resolving system bottlenecks (Frontend, Backend, or Database).
+
+## 📊 Phase 1: Profiling & Bottleneck Identification
+1.  **Metric Collection:** Read `observability/metrics.json` or run `get_system_health`.
+2.  **Log Audit:** Scan `logs/manager.json` for slow actions or timeouts.
+3.  **Trace Analysis:** Use `TraceID` to follow a slow request through all layers.
+
+## 🧠 Phase 2: Root Cause Analysis
+1.  **SQL Audit:** Check for N+1 query patterns or missing indexes in `repository/` files.
+2.  **Algorithm Audit:** Scan for O(n²) loops or heavy synchronous operations.
+3.  **Frontend Audit:** Check for unnecessary re-renders or massive bundle sizes.
+
+## 🛠️ Phase 3: Surgical Optimization
+1.  **DB Level:** Add missing indexes or refactor complex joins.
+2.  **Logic Level:** Implement caching (e.g., Redis or in-memory) for frequent read operations.
+3.  **UI Level:** Apply memoization, virtualization (FlashList), or code-splitting.
+
+## ✅ Phase 4: Validation & Comparison
+1.  **Benchmarking:** Re-run the action and compare new metrics with the baseline.
+2.  **Regression Check:** Run `agent-enderun check` and existing tests to ensure logic is intact.
+3.  **Knowledge Update:** Record the optimization strategy in `knowledge/performance-history.md`.

package/templates/prompts/pull-request-template.md

@@ -0,0 +1,21 @@
+# 📦 Pull Request Title: [TRC-{TraceId}] Brief Description
+
+## 📝 Summary
+<!-- What did you change and why? -->
+
+## 🔗 Related Tasks
+- **Trace ID:** [Link to Trace/Task or ID]
+- **Issue:** [Link to issue if applicable]
+
+## 🛡️ Governance & Compliance Checklist
+- [ ] Code passes `npm run enderun:test`.
+- [ ] Code passes `npm run enderun:check` (Compliance Scanner).
+- [ ] No `any` type usage added.
+- [ ] No secrets or hardcoded API keys.
+- [ ] New functionality is registered in `src/modules/agents/definitions.ts` (if applicable).
+
+## 🧪 Testing Notes
+<!-- How did you verify the fix? -->
+
+## 🛠️ Risk Assessment
+<!-- Any potential side effects? -->

package/templates/prompts/refactoring-recipe.md

@@ -0,0 +1,21 @@
+# 🛠️ Surgical Refactoring Recipe
+
+This recipe defines how to modernize existing code without breaking other parts of the project.
+
+## 1. Reconnaissance
+- Use `grep_search` to find all references to the function to be refactored.
+- Understand the module's dependency graph with `get_project_map`.
+- Verify the baseline by running existing tests (`run_tests`).
+
+## 2. Planning (Strategy)
+- Break the change into small, atomic steps.
+- Define new types and interfaces first.
+
+## 3. Surgical Execution
+- **RULE:** Never delete a file completely. Only use `replace_text` or `batch_surgical_edit`.
+- Maintain type safety (ban on `any`) at every step.
+- Update `PROJECT_MEMORY.md` after every major change.
+
+## 4. Validation
+- Ensure no regressions occurred using `run_tests`.
+- Audit code quality with the `@quality` agent.

package/templates/prompts/security-audit-recipe.md

@@ -0,0 +1,20 @@
+# 🛡️ Engineering Recipe: Advanced Security Audit
+
+This recipe governs the @security agent's protocol for identifying and mitigating vulnerabilities within the Agent Enderun framework.
+
+## 🏁 Phase 1: Automated Reconnaissance
+1.  **Secret Scan:** Run `grep_search` for keywords: `apiKey`, `secret`, `password`, `token`, `private_key`.
+2.  **SQL Injection Audit:** Scan for `raw SQL` or template literals bypassing the query builder.
+3.  **Auth Check:** Verify that all sensitive routes have active `auth` guards and Role-Based Access Control (RBAC).
+
+## 🧠 Phase 2: Contextual Analysis
+1.  **Impact Mapping:** For every identified risk, read the surrounding code to determine if it's exposed to the public internet.
+2.  **Configuration Check:** Verify `.env.example` contains all required keys and no real secrets are committed to Git.
+
+## 🛠️ Phase 3: Surgical Mitigation
+1.  **Fix:** Use `replace_text` to move hardcoded secrets to `.env` or refactor raw SQL to Kysely.
+2.  **Sanitization:** Apply input validation using Zod schemas for all external data.
+
+## ✅ Phase 4: Verification & Logging
+1.  **Discipline Check:** Run `agent-enderun check` to ensure no new violations were introduced.
+2.  **Action Log:** Execute `log_agent_action` with a summary of found vs. fixed vulnerabilities.

package/templates/standards/architecture-standards.md

@@ -0,0 +1,23 @@
+# 📐 Corporate Architecture Standards (AL Framework)
+
+This project is developed in accordance with the "Nizam-ı Mimari" (Architectural Order) rules defined by Agent Enderun.
+
+## 1. Directory Structure (Monorepo Standard)
+- `apps/backend/`: Business logic, API, and database layers.
+- `apps/web/`: Frontend (React/Next.js) layer.
+- `packages/shared/`: Type definitions and helpers shared between Backend and Frontend.
+
+## 2. Layered Architecture
+All business logic must follow this hierarchy:
+1. **Routes/Controllers:** API entry points and request validation.
+2. **Services:** Where business logic is coordinated.
+3. **Repositories/Models:** Database access and raw data mutations.
+
+## 3. Type Safety and Contracts
+- The hash in the `contract.version.json` file must always match the active code.
+- The use of the `any` type is strictly forbidden.
+- All asynchronous operations must be wrapped in `try-catch` blocks and proper error management (ErrorHandler).
+
+## 4. AL (Agent Lifecycle) Phase Discipline
+- Development progresses sequentially from Phase 0 to Phase 4.
+- Application code (Phase 2) cannot be written before contracts are approved (Phase 1).

package/templates/standards/auth-standards.md

@@ -0,0 +1,125 @@
+# Authentication & Authorization Standards
+
+> JWT + bcrypt authentication and role-based access control for Fastify APIs.
+
+## Overview
+
+Enterprise-grade authentication system using JSON Web Tokens (JWT) for stateless authentication and bcrypt for secure password hashing.
+
+## Setup
+
+```bash
+# Required dependencies
+npm install bcrypt jsonwebtoken
+npm install -D @types/bcrypt @types/jsonwebtoken
+```
+
+## Token Management
+
+```typescript
+import jwt from "jsonwebtoken";
+
+const JWT_SECRET = process.env.JWT_SECRET || "change-me-in-production";
+const JWT_EXPIRES_IN = process.env.JWT_EXPIRES_IN || "24h";
+
+interface AuthPayload {
+  sub: string;     // User ID
+  email: string;   // User email
+  role: string;    // User role (ADMIN, DEVELOPER, VIEWER)
+  iat?: number;    // Issued at
+  exp?: number;    // Expires at
+}
+
+export function generateToken(payload: AuthPayload): string {
+    return jwt.sign(payload, JWT_SECRET, { expiresIn: JWT_EXPIRES_IN });
+}
+
+export function verifyToken(token: string): AuthPayload {
+    return jwt.verify(token, JWT_SECRET) as AuthPayload;
+}
+```
+
+## Middleware
+
+```typescript
+import type { FastifyRequest, FastifyReply } from "fastify";
+
+export async function authenticate(
+    request: FastifyRequest,
+    reply: FastifyReply,
+): Promise<void> {
+    const authHeader = request.headers.authorization;
+    if (!authHeader?.startsWith("Bearer ")) {
+        throw new UnauthorizedError("Missing authorization header");
+    }
+    const token = authHeader.slice(7);
+    const payload = verifyToken(token);
+    (request as any).user = payload;
+}
+
+export function requireRole(...roles: string[]) {
+    return async (request: FastifyRequest, reply: FastifyReply) => {
+        const user = (request as any).user as AuthPayload;
+        if (!user || !roles.includes(user.role)) {
+            throw new ForbiddenError("Insufficient permissions");
+        }
+    };
+}
+```
+
+## Password Security
+
+```typescript
+import bcrypt from "bcrypt";
+
+const SALT_ROUNDS = 12;
+
+// Hash password for storage
+export async function hashPassword(password: string): Promise<string> {
+    return bcrypt.hash(password, SALT_ROUNDS);
+}
+
+// Verify password against hash
+export async function verifyPassword(
+    password: string,
+    hash: string,
+): Promise<boolean> {
+    return bcrypt.compare(password, hash);
+}
+```
+
+## CRUD Governance Integration
+
+Admin-level mutations (user creation, role changes, schema modifications) **MUST** follow the CRUD Governance protocol:
+- Route through `@manager` for approval
+- Require human sign-off via `agent-enderun approve <traceId>`
+- Log all authorization decisions
+
+## API Endpoints
+
+| Method | Path | Auth Required | Role Required | Description |
+|--------|------|:------------:|:------------:|-------------|
+| POST | `/api/v1/auth/register` | No | No | Create new user |
+| POST | `/api/v1/auth/login` | No | No | Login & get token |
+| GET | `/api/v1/auth/me` | Yes | No | Get current user |
+| PUT | `/api/v1/auth/password` | Yes | No | Change password |
+
+## Environment Variables
+
+```bash
+JWT_SECRET=your-secret-key-at-least-32-chars-long
+JWT_EXPIRES_IN=24h
+```
+
+## Best Practices
+
+1. **Password Hashing**: Always use bcrypt with minimum 12 salt rounds
+2. **Token Expiry**: Use short-lived tokens (24h max). Implement refresh tokens for longer sessions
+3. **Secret Rotation**: Rotate JWT_SECRET periodically in production
+4. **Rate Limiting**: Apply rate limiting on login/register endpoints to prevent brute force
+5. **HTTPS Only**: Never transmit tokens over unencrypted connections
+6. **Password Strength**: Enforce minimum password requirements (8+ chars, mixed case, numbers)
+7. **Audit Logging**: Log all authentication attempts (success/failure) for security monitoring
+8. **No Plain Text**: Never log or store passwords in plain text
+9. **Token Storage**: Store tokens securely (httpOnly cookies for web, secure storage for mobile)
+10. **Role Hierarchy**: ADMIN > MANAGER > DEVELOPER > VIEWER — validate permissions at each level

package/templates/standards/crud-governance.md

@@ -0,0 +1,21 @@
+# 🏛️ Corporate CRUD and Governance Standards
+
+This document defines the strict rules applicable to data mutation and administrative operations in projects managed by the Agent Enderun army.
+
+## 1. High-Risk Operations
+The following operations are considered "High-Risk" and cannot be performed autonomously by specialist agents (@backend, @database, etc.):
+- Database schema changes (DDL).
+- Bulk data deletion or purging (Bulk Delete/Purge).
+- User authorization and role assignment systems.
+- Payment system (Billing) integrations.
+- PII (Personal Data) export.
+
+## 2. Approval Flow
+- When a specialist agent receives a high-risk operation request, they must reject the operation and report the status to `@manager`.
+- `@manager` analyzes the request and creates a task awaiting `managerApproval`.
+- The operation is held until a human overseer (Human-in-the-Loop) grants approval via the `agent-enderun approve [TraceID]` command.
+
+## 3. Data Discipline
+- **Branded Types:** All IDs (UserID, OrderID, etc.) must strictly follow the branded types format.
+- **Kysely Only:** Raw SQL queries are forbidden. Only the type-safe Kysely query builder may be used.
+- **Repository Pattern:** Database operations cannot be performed directly within controllers; they must pass through the service and repository layers.

package/templates/standards/deployment-standards.md

@@ -0,0 +1,21 @@
+# 🚀 Deployment and Release Standards
+
+This document outlines the protocols for deploying, updating, and rolling back services managed by Agent Enderun.
+
+## 1. Release Strategy
+- **Version Control:** All releases must follow Semantic Versioning (SemVer) and be tagged in Git with the format `vX.Y.Z`.
+- **Atomic Commits:** Each deployment must be linked to a specific Git commit, which itself must contain a `Trace ID` in the commit message.
+
+## 2. Deployment Workflow
+- **CI/CD Integration:** Every deployment must pass the `npm run enderun:test` and `npm run enderun:check` pipeline.
+- **Environment Isolation:** Deployments must use environment-specific configurations (.env.{env}) and never cross-pollinate variables.
+
+## 3. Rollback Procedures (The Hermes Safety Valve)
+- **Immediate Rollback:** If a deployment causes an escalation alert from an agent or a production failure, a rollback must be initiated within 5 minutes.
+- **Git Revert Strategy:** 
+    - Rollbacks are executed by checking out the previous stable tag (e.g., `git checkout v1.0.9`).
+    - A "Fix-Forward" approach is only allowed for P0 security patches; otherwise, "Revert-First" is the law.
+- **Database Safety:** 
+    - Every Migration script must strictly include a corresponding `down()` or `revert()` path.
+    - Database rollbacks must be tested in the staging environment before production execution.
+- **Post-Mortem Requirement:** Every rollback triggers an automatic `@manager` task to create a `docs/post-mortems/TRACE_ID.md` report.

package/templates/standards/frontend-standards.md

@@ -0,0 +1,37 @@
+# 🎨 Corporate Frontend and Responsive Standards
+
+This document defines the UI/UX standards for projects managed by Agent Enderun. All interfaces must comply with "Mobile-First", "Fluid Responsive", and "Cross-Device Adaptive" principles.
+
+## 1. Design System: Panda CSS & Tailwind Integration
+- **Zero UI Library:** Heavy external UI libraries like Ant Design or MUI are not used. All styles are written with type-safe **Panda CSS** or structured **Tailwind CSS**.
+- **Token Usage:** Colors, spacing, and font sizes must be managed via the `token()` function or standard CSS variables.
+- **Responsive Syntax:** Object-based responsive syntax is mandatory:
+  ```typescript
+  css({
+    width: { base: '100%', md: '50%', lg: '33.33%' },
+    padding: { base: '4', md: '8' }
+  })
+  ```
+
+## 2. Mobile-First and Fluid Design
+- **Mobile-First Approach:** Styles must always be written for the smallest screen size (`base`), then expanded to larger screens using `sm`, `md`, `lg`, `xl`, and `2xl` breakpoints.
+- **Fluid Grid & Flexbox:** Layouts should not be restricted by fixed widths. `flex-wrap` and CSS Grid (`grid-template-columns: repeat(auto-fit, minmax(280px, 1fr))`) are preferred.
+- **Fluid Typography:** Font sizes should scale dynamically based on screen width:
+  ```css
+  font-size: clamp(1rem, 2vw + 0.5rem, 2rem);
+  ```
+- **Container Bounds:** The main body of the page must have responsive padding and a maximum width limit (standard of `1280px` or `1440px`).
+
+## 3. Viewport Safety
+- **Overflow Guard:** Horizontal scrollbars are strictly forbidden. `box-sizing: border-box` must be applied to all elements, and widths must be restricted with `max-width: 100%`.
+- **Dynamic Viewport Units:** To avoid issues with mobile browser address bars, use `dvh` (Dynamic Viewport Height) and `dvw` instead of `vh` and `vw`.
+- **Touch Targets:** Clickable elements (buttons, links, inputs) on mobile devices must have a minimum size of `44px x 44px`.
+
+## 4. Component Governance
+- **Atomic Design:** UI components must be collected under `apps/web/src/components/ui/`.
+- **Page Isolation:** Reusable atomic components should be preferred over defining styles within page files.
+- **Image Optimization:** Use the `picture` tag or `srcset` for responsive images, and support `@2x` resolutions for retina displays. SVGs must always be scalable via `viewBox`.
+
+## 5. Accessibility and Performance
+- **WCAG AA:** All color contrasts and keyboard navigation structures must comply with WCAG AA standards.
+- **Lighthouse Score:** A score of 90+ for performance, accessibility, and SEO should be targeted for all pages.

package/templates/standards/github-actions-standards.md

@@ -0,0 +1,43 @@
+# CI/CD Pipeline Standards (GitHub Actions)
+
+> Automated quality gates and deployment pipelines.
+
+## Overview
+
+GitHub Actions CI/CD pipeline for automated testing, type-checking, and quality assurance.
+
+## Pipeline Structure
+
+```yaml
+name: CI/CD Pipeline
+on: [push, pull_request]
+
+jobs:
+  quality:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: actions/setup-node@v4
+        with: { node-version: '22' }
+      - run: npm ci
+      - run: npm run lint
+      - run: npm run typecheck
+      - run: npm test
+```
+
+## Quality Gates
+
+1. **TypeScript Check**: Zero type errors (`tsc --noEmit`)
+2. **Lint Check**: ESLint must pass with zero warnings
+3. **Unit Tests**: All tests must pass
+4. **Coverage**: Minimum 80% line coverage
+
+## Best Practices
+
+1. Run tests on every push and pull request
+2. Cache node_modules for faster builds
+3. Use matrix builds for multi-version testing
+4. Never deploy without passing quality gates
+5. Keep pipeline runs under 10 minutes
+
+> **Note**: Deployment is managed by the development team, not automated by this pipeline.

package/templates/standards/i18n-standards.md

@@ -0,0 +1,17 @@
+# 🌐 Corporate Multi-Language (i18n) Standards
+
+This document defines the localization and multi-language management rules for projects managed by Agent Enderun.
+
+## 1. Centralized Management
+- **Hardcoded Forbidden:** No text visible to the user shall be written directly into the code (JSX/HTML/TS).
+- **Locales Directory:** All languages are stored as JSON files under `apps/web/public/locales/` or `apps/web/src/locales/`.
+- **Key-Value Standard:** Meaningful and hierarchical keys are used (e.g., `common.buttons.save`, `errors.auth.invalid_password`).
+
+## 2. Technical Implementation
+- **i18next:** The `next-i18next` or `react-i18next` library is standard in projects.
+- **Dynamic Content:** i18n interpolation (`{{name}}`) must be used for text containing variables.
+- **Pluralization:** Singular/plural cases must be managed using the i18n library's own rules.
+
+## 3. Auditing
+- When the `@frontend` agent creates a new UI component, it automatically moves texts to the relevant JSON files.
+- Missing translation key (missing key) checks are performed by `@quality`.

package/templates/standards/kysely-standards.md

@@ -0,0 +1,47 @@
+# Kysely ORM Standards
+
+> Type-safe SQL query builder for TypeScript. Use for database operations.
+
+## Setup
+
+```typescript
+import { Kysely, SqliteDialect } from 'kysely';
+import Database from 'better-sqlite3';
+import type { DB } from './types';
+
+const dialect = new SqliteDialect({
+  database: new Database(process.env.DATABASE_PATH || './dev.db'),
+});
+
+export const db = new Kysely<DB>({ dialect });
+```
+
+## Table Definitions
+
+Define types in `src/database/kysely/types.ts`:
+
+```typescript
+export interface UsersTable {
+  id: string;
+  email: string;
+  full_name: string;
+  role: string;
+  password_hash: string;
+  created_at: string;
+  updated_at: string;
+  deleted_at: string | null;
+}
+
+export interface DB {
+  users: UsersTable;
+  customers: CustomersTable;
+}
+```
+
+## Best Practices
+
+1. Always use `where("deleted_at", "is", null)` for soft-delete
+2. Use `returningAll()` after insert/update
+3. Use `db.fn.countAll()` for pagination
+4. Keep types in sync with actual schema
+5. Use transactions for multi-step operations

package/templates/standards/llm-governance.md

@@ -0,0 +1,15 @@
+# 🤖 LLM Governance and Data Protection
+
+This document outlines the security and discipline rules for interacting with Large Language Models within Enderun-managed projects.
+
+## 1. Trust Zone
+- **Input Sanitization:** All user-provided data must be sanitized before being sent to an LLM context to prevent Prompt Injection attacks.
+- **PII Protection:** Absolutely no Personally Identifiable Information (PII) or customer-sensitive credentials should ever be included in prompts.
+
+## 2. Token Discipline
+- **Context Pruning:** Agents must proactively clear unnecessary context and follow the memory pruning protocol (`.enderun/memory/archive/`) to maintain prompt efficiency.
+- **Prompt Scoping:** Prompts should be scoped to the minimum required knowledge to prevent "Context Drift".
+
+## 3. Autonomous Behavior
+- **Human-in-the-Loop:** Any action marked as `ACTION` category requiring state mutation must trigger an approval flow.
+- **Escalation:** If an agent encounters an ambiguity that exceeds its capability (capability < 9), it must stop and escalate to `@manager`.

package/templates/standards/logging-and-secrets.md

@@ -0,0 +1,34 @@
+# 🪵 Corporate Logging and Secret Management (.env) Standards
+
+This document defines the logging discipline and sensitive data (secret) management rules for projects managed by the Agent Enderun army.
+
+## 1. Logging Discipline (Zero Console Policy)
+- **console.log Forbidden:** The use of `console.log`, `console.warn`, or `console.error` in production code is strictly forbidden.
+- **Enterprise Logger Usage:** All logging operations must be performed via the project's central logger system (`src/shared/logger.ts`).
+  ```typescript
+  import { logger } from "@/shared/logger";
+  
+  logger.info("User logged in", { userId: "..." });
+  logger.error("Database connection error", { error: "..." });
+  ```
+- **Log Levels:**
+  - `DEBUG`: Detailed technical information during development.
+  - `INFO`: Normal system flow (e.g., service started, task completed).
+  - `WARN`: Situations that are not errors but require attention.
+  - `ERROR`: Errors that do not break system operation but require investigation.
+  - `FATAL`: Critical errors that cause system crashes.
+
+## 2. Secret Management and .env Discipline
+- **Sensitive Data (Secrets):** API keys, database passwords, JWT secrets, and private keys are NEVER hardcoded into the code.
+- **.env Usage:** All sensitive data and environment-specific settings are managed via the `.env` file.
+- **.env.example:** An up-to-date `.env.example` file must always exist in the root directory of the project. This file should contain only the keys, not the actual values.
+- **Dynamic Checks:** Agents must verify the absence of a value in the `.env` file before application runtime.
+
+## 3. Security and PII (Personally Identifiable Information) Discipline
+- **Git Ignored:** The `.env` file must always be included in `.gitignore` and never committed to the source control system.
+- **Secret Masking:** Sensitive technical data such as passwords, credit card numbers, or API keys must never be written clearly in logs (they must be masked using `***` or similar).
+- **PII Governance (GDPR/KVKK):**
+    - Real user data (Emails, Phone Numbers, Full Names, National IDs) must NEVER be logged or stored in agent memories.
+    - If a task requires processing PII, use anonymized placeholders or unique hashes in logs.
+    - **@security** agent must audit any new log entry for potential PII leakage.
+- **Zero-Trust Memory:** Ajan hafızaları (PROJECT_MEMORY.md) asla gerçek müşteri verisi içermemelidir; sadece teknik meta-data ve mimari kararlar saklanmalıdır.

package/templates/standards/mobile-standards.md

@@ -0,0 +1,23 @@
+# 📱 Corporate Mobile Development Standards (React Native / Expo)
+
+This document defines the strict rules and performance standards in mobile application development processes.
+
+## 1. Technology Stack and Structure
+- **Framework:** Expo (Managed Workflow) and React Native.
+- **Styling:** `react-native-reanimated` and type-safe style objects or Tailwind (NativeWind).
+- **Navigation:** Expo Router (File-based navigation) and Safe Link structures.
+
+## 2. Design for Every Screen (Responsive Mobile Layout)
+- **Screen Resolution Independence:** Fixed `px` widths and heights should never be used. Instead, flexbox ratios, percentage widths, and dynamic values from the `useWindowDimensions` hook should be used.
+- **SafeArea Security:** All screen structures must be wrapped with `SafeAreaProvider` and `SafeAreaView` (or dynamic `insets` object) from `react-native-safe-area-context` to prevent collision with notched screens, status bars, and home indicators.
+- **Font Sizes and Accessibility:** To prevent text truncation or overflow when system font sizes are changed (Accessibility Font Scaling), `numberOfLines` / `ellipsizeMode` should be used in `Text` components or containers providing dynamic height should be designed.
+- **Orientation Adaptation:** Interfaces should be adaptable to both portrait and landscape usage scenarios; especially on tablets, double-column (Master-Detail) or Grid layouts should be adjusted based on dynamic screen aspect ratios.
+
+## 3. Performance and Fluidity
+- **Performant Lists:** To maintain performance in large data lists, `FlashList` (Shopify) must be used instead of `ScrollView` or `FlatList`.
+- **Image Resources:** Images should be cached with `expo-image`, WebP formats should be preferred for fast loading, and aspect ratios (`contentFit`) should be preserved when scaling.
+- **Touch Targets:** All touch interaction areas must be at least `44dp x 44dp`.
+
+## 4. Hardware and Offline Operation
+- **Permissions:** Sensitive permissions (location, camera, notifications) should only be requested when the feature is used, and the reason should be clearly shown to the user.
+- **Offline First:** Network requests should be cached with `React Query`; MMKV (or SQLite) should be used for local persistent storage.

package/templates/standards/observability-standards.md

@@ -0,0 +1,15 @@
+# 📊 Observability and Monitoring Standards
+
+This document defines the requirements for logging, tracing, and observability within Enderun-managed projects.
+
+## 1. Traceability
+- **Trace ID Enforcement:** Every single request, message, or task delegated between agents must include the active `Trace ID` in its metadata.
+- **Context Logging:** Logs must be structured in JSON format where possible, containing at least: `timestamp`, `level`, `agentName`, `traceId`, `action`, and `message`.
+
+## 2. Audit Trail
+- **High-Risk Actions:** All administrative or high-risk actions (e.g., DB changes, User role updates) must be recorded in `observability/audit_log.md` with a timestamp, actor agent, and outcome.
+- **Immutable Logs:** Audit logs should be appended only and never modified or deleted.
+
+## 3. Monitoring
+- **Health Checks:** Ajanlar periyodik olarak `get_system_health` aracını çağırmalıdır.
+- **Alerting:** Critical errors or timeouts must immediately trigger an `ALERT` message to the `@manager` agent for escalation.

package/templates/standards/performance-standards.md

@@ -0,0 +1,15 @@
+# 📈 Performance Monitoring Standards
+
+This document defines the metrics and monitoring requirements to ensure the Enderun Army operates at peak efficiency.
+
+## 1. Core Metrics
+- **Task Latency (Completion Time):** Time from task delegation (`PENDING`) to completion (`SUCCESS`) must be tracked.
+- **Token Consumption:** The total LLM tokens used per `Trace ID` must be logged and analyzed to identify inefficient prompts.
+- **Agent Error Rates:** The frequency of `FAILED` or `RETRY` statuses per agent must be monitored.
+
+## 2. Telemetry Implementation
+- **Standardized Logging:** Every task completion event must include the `Trace ID`, the duration (in milliseconds), and the tool/agent interaction summary.
+- **Performance Budgeting:** Each agent role has an estimated token budget. Budget overflows must be reported by the `@analyst` agent.
+
+## 3. Bottleneck Identification
+- **Critical Path Analysis:** Agents identified as bottlenecking the orchestration loop (frequent `WAITING` or `BLOCKED` states) must be reviewed for logic optimization.