atabey 0.0.1

package/templates/standards/observability-standards.md

@@ -0,0 +1,29 @@
+# 📊 Observability and Monitoring Standards
+
+This document defines the requirements for logging, tracing, metrics, and alerting within Atabey-managed projects, following the "three pillars" model (logs, metrics, traces).
+
+## 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`.
+- **Correlation Across Boundaries:** When a task spans backend, frontend, and database work, the same `Trace ID` must propagate end-to-end so a single workflow can be reconstructed.
+- **Span Discipline (App Runtime):** Production services should emit OpenTelemetry-compatible spans for inbound requests, outbound calls, and DB queries, propagating `traceparent` headers.
+
+## 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.
+- **Tamper Evidence:** Audit entries for compliance-sensitive actions should include the prior entry reference (chained) so deletions are detectable.
+
+## 3. Log Levels and Hygiene
+- **Level Discipline:** `ERROR` = actionable failure; `WARN` = degraded but recovered; `INFO` = lifecycle events; `DEBUG` = development only, disabled in production by default.
+- **No Secrets in Logs:** PII, tokens, and credentials must never be logged. Redact with a central sanitizer before emit.
+- **Cardinality Control:** Do not log unbounded high-cardinality values (raw user input, full payloads) at `INFO`.
+
+## 4. Metrics (RED / USE)
+- **RED for services:** Track Rate, Errors, and Duration for every endpoint.
+- **USE for resources:** Track Utilization, Saturation, and Errors for CPU, memory, and connection pools.
+- **SLOs:** Each critical service declares an SLO (e.g., 99.9% availability, p95 < 300ms) with an error budget that gates risky deploys.
+
+## 5. Monitoring and Alerting
+- **Health Checks:** Agents must periodically invoke the `get_system_health` tool; services expose a `/health` (liveness) and `/ready` (readiness) endpoint.
+- **Alerting:** Critical errors or timeouts must immediately trigger an `ALERT` message to the `@manager` agent for escalation.
+- **Actionable Alerts Only:** Every alert must map to a documented runbook; symptom-based alerts (SLO burn) are preferred over noisy cause-based alerts.

package/templates/standards/performance-standards.md

@@ -0,0 +1,29 @@
+# 📈 Performance Monitoring Standards
+
+This document defines the metrics, budgets, and monitoring requirements to ensure the Atabey Army — and the applications it produces — operate at peak efficiency.
+
+## 1. Orchestration Core Metrics
+- **Task Latency (Completion Time):** Time from task delegation (`PENDING`) to completion (`SUCCESS`) must be tracked per `Trace ID`. Target p95 < 1 orchestration loop cycle.
+- **Token Consumption:** The total LLM tokens used per `Trace ID` must be logged and analyzed to identify inefficient prompts. Report any single task exceeding 2x its role budget.
+- **Agent Error Rates:** The frequency of `FAILED` or `RETRY` statuses per agent must be monitored. A `@agent` exceeding a 15% retry rate over 20 tasks must be flagged for prompt review.
+- **Lock Contention:** Track Hermes message-lock acquisition wait time. Sustained waits > 5s indicate orchestration contention.
+
+## 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.
+- **Sampling:** High-frequency tool calls (search, read) may be sampled at 10% for telemetry to avoid log flooding, but every state-mutating action is logged at 100%.
+
+## 3. Bottleneck Identification
+- **Critical Path Analysis:** Agents identified as bottlenecking the orchestration loop (frequent `WAITING` or `BLOCKED` states) must be reviewed for logic optimization.
+- **Hotspot Reports:** `@analyst` produces a weekly hotspot summary identifying the top 3 slowest agents and the top 3 most token-expensive task types.
+
+## 4. Application Runtime Performance (Delivered Product)
+The applications the army builds must also meet runtime budgets:
+- **Web Vitals:** LCP < 2.5s, INP < 200ms, CLS < 0.1 on the 75th percentile of real users.
+- **API Latency:** Server p95 response time < 300ms for read endpoints, < 800ms for write endpoints under nominal load.
+- **Database:** No N+1 query patterns. Every list endpoint must be paginated; queries on non-indexed columns in hot paths are forbidden.
+- **Bundle Budget:** Initial JS payload (gzipped) < 200KB for the critical route; enforce code-splitting for routes beyond the entry shell.
+- **Caching:** Cacheable responses must declare explicit `Cache-Control`; server-side data fetching uses a documented TTL strategy.
+
+## 5. Regression Gate
+- Performance budgets are enforced in CI. A change that regresses a tracked metric beyond its threshold blocks merge until `@manager` approves an explicit exception with a `Trace ID`.

package/templates/standards/pino-standards.md

@@ -0,0 +1,46 @@
+# Logging Standards
+
+> Structured logging with Pino for Node.js applications.
+
+## Overview
+
+Pino is a fast, low-overhead structured logger. All logs must be in JSON format for production.
+
+## Setup
+
+```bash
+npm install pino
+npm install -D pino-pretty
+```
+
+## Configuration
+
+```typescript
+import { pino } from "pino";
+
+const logger = pino({
+    transport: process.env.NODE_ENV === "development"
+        ? { target: "pino-pretty", options: { colorize: true, translateTime: "HH:MM:ss Z" } }
+        : undefined,
+    level: process.env.LOG_LEVEL || "info",
+});
+
+export { logger };
+```
+
+## Usage
+
+```typescript
+logger.info("Server started on port 4000");
+logger.error({ err }, "Failed to connect to database");
+logger.warn({ userId, action: "rate_limit" }, "Rate limit exceeded");
+logger.debug({ query, params }, "Executing database query");
+```
+
+## Best Practices
+
+1. Always pass Error objects as first argument: `logger.error({ err }, "msg")`
+2. Use structured context objects instead of string interpolation
+3. Never log sensitive data (passwords, tokens, PII)
+4. Use child loggers for request-scoped logging
+5. Set appropriate log levels (debug for dev, info for prod)

package/templates/standards/playwright-standards.md

@@ -0,0 +1,54 @@
+# E2E Testing Standards (Playwright)
+
+> End-to-end testing for web applications.
+
+## Overview
+
+Playwright provides cross-browser E2E testing with auto-waiting and network interception.
+
+## Setup
+
+```bash
+npm install -D @playwright/test
+npx playwright install
+```
+
+## Test Structure
+
+```
+e2e/
+├── auth.spec.ts          # Login/logout flows
+├── customers.spec.ts     # Customer CRUD flows
+├── navigation.spec.ts    # Navigation & routing
+└── fixtures/
+    └── auth.fixture.ts   # Authenticated test context
+```
+
+## Example Test
+
+```typescript
+import { test, expect } from "@playwright/test";
+
+test("user can login and see dashboard", async ({ page }) => {
+    await page.goto("/login");
+    await page.fill("[name=email]", "admin@example.com");
+    await page.fill("[name=password]", "password123");
+    await page.click("button[type=submit]");
+    await expect(page.locator("text=Dashboard")).toBeVisible();
+});
+
+test("admin can view customers list", async ({ page }) => {
+    await page.goto("/customers");
+    await expect(page.locator("table")).toBeVisible();
+    await expect(page.locator("text=Northwind")).toBeVisible();
+});
+```
+
+## Best Practices
+
+1. Test critical user flows (login, CRUD, navigation)
+2. Use page objects for reusable test actions
+3. Run tests in CI pipeline on every push
+4. Use fixtures for authenticated test contexts
+5. Keep tests independent — no shared state
+6. Use data-testid attributes for reliable selectors

package/templates/standards/quality-standards.md

@@ -0,0 +1,32 @@
+# ⚖️ Corporate Code Quality and Discipline (Linting & Standards)
+
+This document defines the technical discipline rules that all code produced by the Agent Atabey army must comply with. The goal is zero errors, maximum readability, and sustainability.
+
+## 1. TypeScript Discipline
+- **Strict Mode:** `strict: true` is mandatory in all projects.
+- **No Explicit Any:** The use of `any` is strictly forbidden. `unknown` should be used for uncertain types and verified with type guards.
+- **Exhaustive Checks:** All cases must be checked (exhaustive) in `switch-case` structures, or safety must be provided with the `never` type.
+
+## 2. ESLint and Static Analysis (AST Enforced)
+- **Real-Time AST Audits:** Every file mutation by an agent is scanned via **Abstract Syntax Tree (AST)** analysis. Prohibited patterns (`any`, `console.log`) are blocked at the protocol level.
+- **Zero Warnings:** No ESLint warnings or errors can exist in the codebase.
+- **Naming Conventions:**
+  - Variables and functions: `camelCase`
+  - Classes and Types: `PascalCase`
+  - Constants: `UPPER_SNAKE_CASE`
+  - File names: `kebab-case`
+- **Imports:** Unused imports should be automatically cleaned, and the import order should be regular.
+
+## 3. Formatting (Prettier)
+- **Consistency:** Uniform formatting is mandatory in all files.
+- **Indentation:** 4 spaces.
+- **Quotes:** Use of double quotes (`"`).
+- **Semicolons:** Each statement must end with a semicolon (`;`).
+
+## 4. Error Handling
+- **No Silent Failures:** Empty `catch` blocks are forbidden. Every error must at least be logged or passed to the upper layer.
+- **Custom Errors:** Project-specific `AppError` classes should be used for business logic errors.
+
+## 5. Audit Loop
+- **Pre-commit:** `npm run lint` and `npm run type-check` must be run before code is committed.
+- **@quality Audit:** All changes are audited by the `@quality` agent according to these standards.

package/templates/standards/react-query-standards.md

@@ -0,0 +1,72 @@
+# React Query (TanStack Query) Standards
+
+> Server state management for React applications.
+
+## Overview
+
+React Query handles server state: caching, background refetching, optimistic updates, and pagination.
+
+## Setup
+
+```bash
+npm install @tanstack/react-query
+```
+
+## Provider Setup
+
+```tsx
+import { QueryClient, QueryClientProvider } from "@tanstack/react-query";
+
+const queryClient = new QueryClient({
+    defaultOptions: {
+        queries: {
+            staleTime: 1000 * 60 * 5,
+            retry: 2,
+            refetchOnWindowFocus: false,
+        },
+    },
+});
+
+export function Providers({ children }: { children: React.ReactNode }) {
+    return (
+        <QueryClientProvider client={queryClient}>
+            {children}
+        </QueryClientProvider>
+    );
+}
+```
+
+## Hook Pattern
+
+```tsx
+import { useQuery, useMutation, useQueryClient } from "@tanstack/react-query";
+
+// Fetch
+export function useCustomers(page = 1) {
+    return useQuery({
+        queryKey: ["customers", { page }],
+        queryFn: () => fetch(`/api/v1/customers?page=${page}`).then(r => r.json()),
+    });
+}
+
+// Mutation with cache invalidation
+export function useCreateCustomer() {
+    const queryClient = useQueryClient();
+    return useMutation({
+        mutationFn: (data) => fetch("/api/v1/customers", {
+            method: "POST",
+            body: JSON.stringify(data),
+        }).then(r => r.json()),
+        onSuccess: () => queryClient.invalidateQueries({ queryKey: ["customers"] }),
+    });
+}
+```
+
+## Best Practices
+
+1. Use query keys as arrays: `["resource", params]`
+2. Set appropriate stale times based on data volatility
+3. Use `onMutate` for optimistic updates
+4. Keep API calls in dedicated hooks
+5. Use `enabled` option for dependent queries
+6. Implement error boundaries for query errors

package/templates/standards/react-router-standards.md

@@ -0,0 +1,62 @@
+# React Router Standards
+
+> Client-side routing for React applications.
+
+## Overview
+
+React Router v7 provides declarative routing with nested layouts, loaders, and actions.
+
+## Setup
+
+```bash
+npm install react-router-dom
+```
+
+## Basic Setup
+
+```tsx
+import { createBrowserRouter, RouterProvider } from "react-router-dom";
+
+const router = createBrowserRouter([
+    {
+        path: "/",
+        element: <Layout />,
+        children: [
+            { index: true, element: <Dashboard /> },
+            { path: "customers", element: <Customers /> },
+            { path: "customers/:id", element: <CustomerDetail /> },
+            { path: "users", element: <Users /> },
+            { path: "settings", element: <Settings /> },
+        ],
+    },
+]);
+
+export function App() {
+    return <RouterProvider router={router} />;
+}
+```
+
+## Protected Routes
+
+```tsx
+function ProtectedRoute({ children, roles }: { children: React.ReactNode; roles?: string[] }) {
+    const { user } = useAuth();
+
+    if (!user) return <Navigate to="/login" replace />;
+    if (roles && !roles.includes(user.role)) return <Navigate to="/" replace />;
+
+    return <>{children}</>;
+}
+
+// Usage in router
+{ path: "admin", element: <ProtectedRoute roles={["ADMIN"]}><AdminPanel /></ProtectedRoute> }
+```
+
+## Best Practices
+
+1. Use nested routes for consistent layouts
+2. Implement lazy loading with `React.lazy()` for route splitting
+3. Use route loaders for data fetching
+4. Protect admin routes with role-based guards
+5. Keep routes organized in a single configuration
+6. Use `useNavigate` for programmatic navigation

package/templates/standards/security-audit-standards.md

@@ -0,0 +1,33 @@
+# 🛡️ Security Audit Standards
+
+This document defines the security audit procedures required for all Agent Atabey-managed projects to ensure a "Defense-in-Depth" posture, aligned with OWASP ASVS and the OWASP Top 10.
+
+## 1. Automated Vulnerability Scanning
+- **Dependency Audit:** All projects must execute `npm audit` within the CI/CD pipeline. Any high/critical vulnerability must block deployment.
+- **Static Analysis (SAST):** Use `eslint-plugin-security` to detect potential vulnerabilities (e.g., insecure crypto, command injection risks) in the codebase.
+- **Secret Scanning:** Run a secret scanner (e.g., gitleaks) on every commit; a detected secret blocks the pipeline and triggers rotation.
+- **SCA & SBOM:** Maintain a Software Bill of Materials. Pin dependency versions with a committed lockfile; forbid floating ranges in production manifests.
+
+## 2. Agent Governance (Prompt Security)
+- **Prompt Sanitization:** All user-provided inputs must pass through `src/cli/utils/string.ts` sanitizers before being injected into system prompts.
+- **Tool Allowlist:** Agents must only have access to a strictly defined, minimal toolset required for their role.
+- **Approval Flow:** Any agent requesting an action that modifies persistent state (File write, DB mutation) must be routed through the `@manager` approval gate.
+- **Path Confinement:** File-system tools must reject path traversal (`..`) and operate only within the project root (`safePath` enforcement).
+
+## 3. Application Security Review (OWASP Top 10)
+Every audit must explicitly verify:
+- **Access Control (A01):** Authorization checked server-side on every protected resource; no reliance on client-side hiding. RLS enforced at the database tier.
+- **Injection (A03):** Parameterized/type-safe queries only (Kysely); no string-concatenated SQL or shell.
+- **Insecure Design (A04):** Threat model documented for new high-risk features before implementation.
+- **Auth Failures (A07):** Strong password/credential policy, session expiry, brute-force rate limiting, secure cookie flags.
+- **SSRF (A10):** Outbound requests to user-controlled URLs are validated against an allowlist.
+
+## 4. Secret Management
+- **Environment Isolation:** No secrets in code. Use `.env` files exclusively.
+- **CI/CD Secrets:** Production secrets must be managed via GitHub Secrets/Action Variables, never committed to the repository.
+- **Rotation:** Secrets have a documented rotation policy; a leaked secret is rotated immediately and the incident logged in the audit trail.
+
+## 5. Audit Cadence and Reporting
+- **Frequency:** Automated scans run on every PR; a full manual review by `@security` is required before any release tagged `vX.Y.0` and after any high-risk change.
+- **Findings Ledger:** Every finding is recorded with severity (Critical/High/Medium/Low), a `Trace ID`, owner, and remediation status. Critical/High findings block release.
+- **Penetration Testing:** High-risk surfaces (auth, billing, PII export) receive a focused pen-test before going to production.

package/templates/standards/security-standards.md

@@ -0,0 +1,21 @@
+# 🛡️ Corporate Security and Data Protection Standards
+
+This document defines the security protocols and data protection standards for projects managed by Agent Atabey.
+
+## 1. Database Security (RLS)
+- **Row Level Security (RLS):** All user data must be protected with RLS policies. A user cannot access another user's data except through a permission protocol approved by `@manager`.
+- **SQL Injection:** Raw SQL queries are strictly forbidden (Kysely mandatory).
+- **Encryption at Rest:** Sensitive data (PII) must be stored encrypted in the database.
+
+## 2. Authentication and Authorization
+- **JWT / Session:** Only secure authentication methods approved by the `@security` agent are used.
+- **Role Based Access Control (RBAC):** Authorization schemes must be managed centrally under `apps/backend/src/security/roles.ts`.
+
+## 3. API Security
+- **CORS:** Only allowed domains can access the API.
+- **Rate Limiting:** Rate limiting must be applied for all API endpoints.
+- **Input Validation:** All inputs (request body, params) must be strictly validated with Zod or a similar library.
+
+## 4. Secret Management
+- **No Hardcoded Secrets:** API keys, passwords, or secret keys can never be stored in the code.
+- **.env Discipline:** All secret variables must be managed via the `.env` file, and this file must never be pushed to git.

package/templates/standards/swagger-standards.md

@@ -0,0 +1,50 @@
+# API Documentation Standards
+
+> OpenAPI/Swagger documentation for Fastify APIs.
+
+## Overview
+
+Auto-generated API documentation using @fastify/swagger and @fastify/swagger-ui.
+
+## Setup
+
+```bash
+npm install @fastify/swagger @fastify/swagger-ui
+```
+
+## Configuration
+
+```typescript
+import swagger from "@fastify/swagger";
+import swaggerUi from "@fastify/swagger-ui";
+
+await app.register(swagger, {
+    openapi: {
+        info: {
+            title: "API Name",
+            version: "1.0.0",
+            description: "Enterprise API documentation",
+        },
+        servers: [{ url: process.env.API_URL || "http://localhost:4000" }],
+        components: {
+            securitySchemes: {
+                bearerAuth: {
+                    type: "http",
+                    scheme: "bearer",
+                    bearerFormat: "JWT",
+                },
+            },
+        },
+    },
+});
+
+await app.register(swaggerUi, { routePrefix: "/docs" });
+```
+
+## Best Practices
+
+1. Define all request/response schemas using Zod or TypeBox
+2. Group routes by tags (Users, Customers, Reports)
+3. Include error responses in schema definitions
+4. Version your API (e.g., /api/v1/, /api/v2/)
+5. Keep documentation up to date with code changes

package/templates/standards/tailwind-standards.md

@@ -0,0 +1,29 @@
+# 🌊 Corporate Tailwind CSS Standards
+
+This document defines the rules required to maintain code quality and design discipline in projects using Tailwind CSS.
+
+## 1. Design Discipline and Constraints
+- **No Arbitrary Values:** The use of arbitrary values like `h-[123px]` or `bg-[#fafafa]` is forbidden. All values must be fed from the theme in `tailwind.config.ts`.
+- **Design Tokens:** Colors, spacing, radii, shadows, and typography are defined once as theme tokens. Components consume tokens, never raw hex/px.
+- **Utility-First, Not Utility-Only:** Class structures that become too complex should be managed with `@apply` or by dividing them into components (Atomic Design).
+- **Prettier Plugin:** `prettier-plugin-tailwindcss` must be used for class ordering.
+
+## 2. Responsive and Mobile-First
+- **Mobile-First:** Styles should be written for mobile first, then expanded with `sm:`, `md:`, and `lg:` prefixes.
+- **Consistency:** Consistent breakpoint usage across the project (standard Tailwind breakpoints) is mandatory.
+- **Container Queries:** Prefer container queries for component-level responsiveness where the component can appear in varying layout widths.
+
+## 3. Clean Code and Organization
+- **Clean Templates:** If there are more than 10 Tailwind classes in HTML/JSX, these classes should be organized with tools like `cva` (Class Variance Authority) or `clsx`/`tailwind-merge`.
+- **Component Isolation:** UI components must be collected under `apps/web/src/components/ui/`, and each component must contain its own Tailwind classes.
+- **No Conflicting Classes:** Use `tailwind-merge` to deduplicate conflicting utilities when composing variants.
+
+## 4. Theming and Dark Mode
+- **Semantic Color Roles:** Use semantic names (`bg-surface`, `text-muted`, `border-default`) mapped to tokens, enabling theme swaps without touching markup.
+- **Dark Mode:** Implement via the `dark:` variant driven by a class strategy, validated for contrast in both themes.
+
+## 5. Performance and Accessibility
+- **JIT Mode:** Just-in-Time mode should always be used; the `content` glob must be accurate so unused styles are purged.
+- **Contrast:** WCAG AA standards must be complied with when choosing theme colors (≥ 4.5:1 for body text, ≥ 3:1 for large text and UI components).
+- **Focus States:** Never remove focus outlines without providing a visible, accessible alternative (`focus-visible:` rings).
+- **Reduced Motion:** Respect `prefers-reduced-motion` for animations and transitions.

package/templates/standards/testing-standards.md

@@ -0,0 +1,31 @@
+# 🧪 Corporate Testing Standards
+
+This document defines the testing discipline and scope rules for projects managed by Agent Atabey. Code quality must be ensured with automated tests.
+
+## 1. Test Pyramid and Strategy
+- **Unit Tests:** Written for the smallest parts of business logic. Must be fast and isolated.
+- **Integration Tests:** Audits the compatibility of services with the database or external APIs.
+- **E2E Tests:** Simulates critical user flows (Login, Checkout, etc.) in a real browser environment.
+
+## 2. Writing Rules and Naming
+- **Framework:** Vitest (Unit/Integration) and Playwright (E2E) are standard.
+- **File Naming:** The `[module-name].test.ts` format is used.
+- **Pattern (Given-When-Then):**
+  ```typescript
+  it("should create a user when valid data is provided", async () => {
+    // Given
+    const userData = { ... };
+    // When
+    const result = await userService.create(userData);
+    // Then
+    expect(result.id).toBeDefined();
+  });
+  ```
+
+## 3. Scope and Success Criteria
+- **Critical Path Coverage:** Auth, Payment, and Data Mutation processes must have 100% test coverage.
+- **Zero Mock Policy (Internal):** Real contracts and test databases should be used between internal project services instead of mocks. External services (Stripe, Twilio, etc.) can be mocked.
+
+## 4. Auditing
+- The `@quality` agent verifies that the relevant test file is updated in each new function.
+- Code that does not pass tests (`npm run test`) is never approved.

package/templates/standards/token-economy.md

@@ -0,0 +1,27 @@
+# 🪙 Token Economy & Context Management Standards
+
+This document defines the strict context management and token cost optimization rules for Agent Atabey projects. All agents must follow these mandates to minimize LLM usage costs and prevent context drift.
+
+## 1. Search Before Reading (Mandatory)
+* **Rule:** Never execute a full directory listing (`list_dir`) recursively or read an entire file (`read_file`) without searching first.
+* **Method:** Use `grep_search` to find the exact line number of interest. Then, read only the surrounding lines (e.g. ±20 lines) using `view_file` with `StartLine` and `EndLine`.
+* **Cost Impact:** Prevents thousands of unnecessary input tokens from being loaded into context.
+
+## 2. Surgical Modifications
+* **Rule:** Do not write or replace whole files unless they are very small (<50 lines).
+* **Method:** Use targeted text replacement tools (`replace_text`, `patch_file`, `replace_file_content`, `multi_replace_file_content`) to apply edits to specific lines only.
+* **Cost Impact:** Reduces output token generation by up to 95%, keeping LLM responses fast and cost-effective.
+
+## 3. Output Conciseness
+* **Rule:** Keep explanations and logs to the absolute minimum required.
+* **Method:** Do not output verbose comments, intermediate thinking logs, or redundant progress messages. Avoid repeating what the code does; explain only the "why" if non-obvious.
+* **Cost Impact:** Saves output tokens in CLI streams and communication queues.
+
+## 4. Context Compaction & Memory Pruning
+* **Rule:** Do not carry the entire history of the development session.
+* **Method:** Before initiating a task, retrieve only the active state via `get_memory_insights` or by reading `PROJECT_MEMORY.md`. Archive completed tasks and older logs in `.atabey/memory/archive/`.
+* **Cost Impact:** Keeps the prompt context window clean and prevents performance degradation due to long-context attention dilution.
+
+## 5. No Blind Coding & Stopping Gates
+* **Rule:** Halt execution and ask the user for clarification if a task requires reading more than 5 large files without producing a clear search match.
+* **Method:** Do not guess the structure or keep querying the filesystem repeatedly. Report the block to `@manager` and wait.

package/templates/standards/typeorm-standards.md

@@ -0,0 +1,49 @@
+# TypeORM Standards
+
+> Full-featured ORM with decorator-based entity definitions.
+
+## Setup
+
+```typescript
+import { DataSource } from "typeorm";
+
+export const AppDataSource = new DataSource({
+    type: "sqlite",
+    database: process.env.DATABASE_PATH || "./dev.db",
+    synchronize: process.env.NODE_ENV === "development",
+    logging: process.env.NODE_ENV === "development",
+    entities: ["src/database/typeorm/entities/*.ts"],
+    migrations: ["src/database/typeorm/migrations/*.ts"],
+});
+```
+
+## Entity Pattern
+
+```typescript
+import { Entity, PrimaryColumn, Column, CreateDateColumn, UpdateDateColumn, DeleteDateColumn } from "typeorm";
+
+@Entity("users")
+export class UserEntity {
+    @PrimaryColumn()
+    id!: string;
+    @Column({ unique: true })
+    email!: string;
+    @Column()
+    fullName!: string;
+    @Column({ default: "VIEWER" })
+    role!: string;
+    @CreateDateColumn()
+    createdAt!: Date;
+    @UpdateDateColumn()
+    updatedAt!: Date;
+    @DeleteDateColumn()
+    deletedAt?: Date;
+}
+```
+
+## Best Practices
+1. Use `@DeleteDateColumn()` for soft deletes
+2. Set `synchronize: false` in production
+3. Use `@ManyToOne` / `@OneToMany` for relations
+4. Import `reflect-metadata` at entry point
+5. Generate migrations, don't rely on synchronize