code-ai-installer 2.4.1 → 3.0.0

package/.agents/skills/adr-log/SKILL.md

@@ -1,369 +0,0 @@
----
-name: adr-log
-description: Зафиксировать ключевые архитектурные решения (ADR) с trade-offs — Pros/Cons/Alternatives/Decision, статусом и датой.
----
-
-# Skill: ADR Log
-
-Формат и примеры для Architectural Decision Records.
-
-**Разделы:**
-1. [Когда создавать ADR](#1-когда)
-2. [Формат (обязательный)](#2-формат)
-3. [Naming Convention](#3-naming)
-4. [Примеры ADR](#4-примеры)
-5. [Decision Matrix](#5-decision-matrix)
-6. [Lifecycle](#6-lifecycle)
-7. [Anti-patterns](#7-anti-patterns)
-
----
-
-## 1. Когда создавать ADR
-
-Создавай ADR для **каждого нетривиального выбора** — если через 6 месяцев кто-то спросит "почему так?":
-
-| Категория | Примеры |
-|-----------|---------|
-| **Database** | Выбор СУБД, embed vs reference, sharding strategy |
-| **Auth** | JWT vs sessions, cookie vs header, OAuth flow |
-| **API Design** | REST vs GraphQL, versioning, error format |
-| **Architecture** | Monolith vs microservices, layering, module boundaries |
-| **Infrastructure** | Docker vs K8s, CDN, reverse proxy, HTTPS strategy |
-| **Integration** | Wix SDK choice, payment provider, email service |
-| **State** | Zustand vs Redux vs Context, server state (React Query) |
-| **Styling** | CSS Modules vs Tailwind vs styled-components |
-| **Testing** | Test runner, coverage thresholds, mock strategy |
-| **Error handling** | Error format, retry policy, circuit breaker |
-
----
-
-## 2. Формат (обязательный)
-
-```markdown
-# ADR-XXX: <Краткое название решения>
-
-## Status
-Proposed | Accepted | Deprecated | Superseded by ADR-YYY
-
-## Date
-YYYY-MM-DD
-
-## Context
-<Почему это нужно? Какие ограничения? Что болит?>
-- Текущая ситуация
-- Требования / constraints
-- Что произойдёт если не решить
-
-## Decision
-<Что выбрали и как именно будем делать>
-
-## Consequences
-
-### Positive
-- ...
-- ...
-
-### Negative
-- ...
-- ...
-
-### Risks
-- ... (и как митигируем)
-
-## Alternatives Considered
-
-### Option A: <название>
-- ✅ Pros: ...
-- ❌ Cons: ...
-- 💡 Why rejected: ...
-
-### Option B: <название>
-- ✅ Pros: ...
-- ❌ Cons: ...
-- 💡 Why rejected: ...
-
-## References
-- PRD section / UX Spec / ticket
-- External docs / articles
-- Related ADRs: ADR-XXX
-```
-
----
-
-## 3. Naming Convention
-
-| Правило | Пример |
-|---------|--------|
-| Номер: 3-значный, с ведущими нулями | ADR-001, ADR-042 |
-| Название: action + object | "Use MongoDB as primary database" |
-| Файл: `ADR-XXX-kebab-case.md` | `ADR-001-use-mongodb.md` |
-| Директория: `docs/architecture/adr/` | — |
-| Хронологический порядок | Новые ADR = следующий номер |
-
----
-
-## 4. Примеры ADR
-
-### ADR-001: Use MongoDB as primary database
-
-```markdown
-# ADR-001: Use MongoDB as primary database
-
-## Status
-Accepted
-
-## Date
-2025-06-15
-
-## Context
-The application needs persistent storage for tenants, settings,
-and products. Requirements:
-- Flexible schema (settings structure varies per configuration)
-- Low operational overhead (small team)
-- Good Node.js ecosystem support
-- No complex joins needed (data is per-tenant)
-
-## Decision
-Use MongoDB 7 with Mongoose ODM.
-- Single database, collections: tenants, settings, products
-- Hosted via Docker (dev) / MongoDB Atlas (production)
-
-## Consequences
-
-### Positive
-- Flexible schema fits varying template settings
-- Excellent Mongoose ecosystem (validators, middleware, lean queries)
-- Easy Docker setup for local development
-- Native JSON — minimal serialization overhead
-
-### Negative
-- No ACID transactions across collections (need replica set)
-- No joins — must denormalize or do application-level joins
-- Schema discipline required (strict mode + Zod validation)
-
-### Risks
-- Schema drift without validation → mitigated by strict: 'throw'
-- 16MB document limit → mitigated by reference strategy for unbounded arrays
-
-## Alternatives Considered
-
-### Option A: PostgreSQL
-- ✅ ACID, complex queries, strong typing
-- ❌ Schema migrations more complex for flexible settings
-- ❌ JSON column less ergonomic than native MongoDB documents
-- 💡 Overkill for current use case (no joins, no complex queries)
-
-### Option B: SQLite
-- ✅ Zero infrastructure, file-based
-- ❌ No concurrent writes in Docker
-- ❌ No production scaling path
-- 💡 Too limiting for multi-service architecture
-
-## References
-- PRD: Data requirements section
-- Related: ADR-002 (Mongoose strict mode)
-```
-
----
-
-### ADR-018: Use Wix ImageViewer for dashboard images
-
-```markdown
-# ADR-018: Use Wix ImageViewer for dashboard images
-
-## Status
-Accepted
-
-## Date
-2025-12-20
-
-## Context
-Dashboard needs to display template preview images.
-The app runs inside Wix iframe where standard <img> tags may have
-CORS issues with Wix media URLs (wixstatic.com).
-
-## Decision
-Use WDS (Wix Design System) ImageViewer component for all
-dashboard images instead of native <img> tags.
-
-## Consequences
-
-### Positive
-- Handles Wix media URLs natively (no CORS issues)
-- Consistent with Wix design system (visual parity)
-- Built-in loading states and error handling
-
-### Negative
-- Dependency on WDS component library
-- Different API than standard <img> (onLoad, src format)
-
-## Alternatives Considered
-
-### Option A: Native <img> with proxy
-- ✅ Simple, no dependency
-- ❌ CORS errors with wixstatic.com
-- ❌ Need custom proxy endpoint
-- 💡 Unnecessary complexity
-
-## References
-- Bug: Dashboard images not loading (blank src)
-- Wix Design System docs: ImageViewer component
-```
-
----
-
-### ADR-019: CSS overflow containment for popup templates
-
-```markdown
-# ADR-019: CSS overflow containment for popup
-
-## Status
-Accepted
-
-## Date
-2025-12-20
-
-## Context
-Popup templates render inside Wix embedded script.
-CSS overflow from popup elements leaks outside the container,
-causing scrollbars on the Wix page.
-
-## Decision
-Apply containment strategy:
-1. `overflow: hidden` on popup container
-2. `contain: layout style` on root widget element
-3. `box-sizing: border-box` on all popup children
-
-## Consequences
-
-### Positive
-- No visual leaking outside container
-- No unexpected scrollbars on host page
-- Each template isolated
-
-### Negative
-- Must test each template for clipping issues
-- Shadow effects near edges may be cut off
-
-## Alternatives Considered
-
-### Option A: Shadow DOM
-- ✅ Complete style isolation
-- ❌ Complex to implement for dynamic templates
-- ❌ Limited shadow DOM support for legacy browsers
-- 💡 Overkill for current 3-template scope
-
-## References
-- Bug: Scrollbar appearing on Wix site when popup opens
-- Related: ADR-018 (ImageViewer)
-```
-
----
-
-## 5. Decision Matrix
-
-Для сложных решений с 3+ альтернативами используй weighted matrix:
-
-```markdown
-## Decision Matrix: State Management
-
-### Criteria (weighted)
-| Criteria | Weight | Description |
-|----------|--------|-------------|
-| Simplicity | 3 | Learning curve, boilerplate |
-| Performance | 2 | Re-render efficiency |
-| DevTools | 1 | Debugging experience |
-| Ecosystem | 1 | Community, plugins |
-| Bundle size | 2 | KB added |
-
-### Scoring (1-5, higher = better)
-
-| Option | Simplicity (×3) | Performance (×2) | DevTools (×1) | Ecosystem (×1) | Bundle (×2) | **Total** |
-|--------|:---:|:---:|:---:|:---:|:---:|:---:|
-| **Zustand** | 5 (15) | 4 (8) | 4 (4) | 3 (3) | 5 (10) | **40** |
-| Redux Toolkit | 3 (9) | 4 (8) | 5 (5) | 5 (5) | 3 (6) | **33** |
-| Context + useReducer | 4 (12) | 2 (4) | 3 (3) | 5 (5) | 5 (10) | **34** |
-| Jotai | 4 (12) | 5 (10) | 3 (3) | 2 (2) | 5 (10) | **37** |
-
-### Decision
-Zustand wins (40 points). Best simplicity + performance + bundle size.
-```
-
----
-
-## 6. Lifecycle
-
-```
-Proposed → Accepted → [Active use]
-                         ↓
-                    Deprecated (if better solution found)
-                         ↓
-                    Superseded by ADR-YYY
-```
-
-| Status | Значение |
-|--------|---------|
-| **Proposed** | Решение предложено, ждёт review |
-| **Accepted** | Решение утверждено, применяется |
-| **Deprecated** | Решение устарело, но код ещё использует |
-| **Superseded** | Заменено другим ADR (указать ссылку) |
-
-### Supersedes/Superseded-by
-
-```markdown
-# ADR-025: Migrate from CSS Modules to Tailwind
-
-## Status
-Accepted (Supersedes ADR-008)
-
----
-
-# ADR-008: Use CSS Modules for component styling
-
-## Status
-Superseded by ADR-025
-```
-
----
-
-## 7. Anti-patterns
-
-| ❌ Anti-pattern | ✅ Решение |
-|----------------|-----------|
-| ADR без Alternatives | Всегда минимум 2 альтернативы |
-| "We chose X because it's popular" | Конкретные Pros/Cons по критериям проекта |
-| 500-строчный ADR | Короткий и конкретный: max 50-80 строк |
-| ADR задним числом (через месяц) | Создавать ADR в момент принятия решения |
-| Нет cross-references | Ссылки на PRD, related ADRs, tickets |
-| Нет Negative consequences | Каждое решение имеет trade-offs |
-| "Alternatives: none" | Если альтернатив нет — пересмотри скоуп вопроса |
-
----
-
-## Deliverables
-
-| Артефакт | Формат | Где |
-|---------|--------|-----|
-| ADR record | Markdown (format above) | `docs/architecture/adr/ADR-XXX-name.md` |
-| ADR index | Table of contents | `docs/architecture/adr/README.md` |
-
-### ADR Index format
-
-```markdown
-# Architecture Decision Records
-
-| # | Title | Status | Date |
-|---|-------|--------|------|
-| ADR-001 | Use MongoDB as primary database | Accepted | 2025-06-15 |
-| ADR-008 | Use CSS Modules for styling | Superseded by ADR-025 | 2025-07-01 |
-| ADR-018 | Use WDS ImageViewer | Accepted | 2025-12-20 |
-| ADR-019 | CSS overflow containment | Accepted | 2025-12-20 |
-| ADR-025 | Migrate to Tailwind | Accepted | 2026-01-15 |
-```
-
----
-
-## См. также
-- `$architecture-doc` — Architecture Document (ADR decisions referenced inline)
-- `$current-state-analysis` — аудит перед новыми ADR
-- `$system-design-checklist` — checklist полноты дизайна

package/.agents/skills/adr-log/agents/claude.json

@@ -1,18 +0,0 @@
-{
-  "name": "adr-log",
-  "display_name": "Журнал ADR",
-  "description": "Зафиксировать ключевые архитектурные решения (ADR) с trade-offs — Pros/Cons/Alternatives/Decision, статусом и датой.",
-  "default_prompt": "Используй $adr-log, когда задача относится к навыку \"Журнал ADR\".",
-  "triggers": [
-    "adr-log",
-    "adr log",
-    "Журнал ADR",
-    "Зафиксировать ключевые архитектурные решения (ADR) с trade-offs — Pros/Cons/Alternatives/Decision, статусом и датой"
-  ],
-  "capabilities": [
-    "adr",
-    "log"
-  ],
-  "tools": [],
-  "implicit_invocation": true
-}

package/.agents/skills/adr-log/agents/copilot.json

@@ -1,18 +0,0 @@
-{
-  "name": "adr-log",
-  "display_name": "Журнал ADR",
-  "description": "Зафиксировать ключевые архитектурные решения (ADR) с trade-offs — Pros/Cons/Alternatives/Decision, статусом и датой.",
-  "default_prompt": "Используй $adr-log, когда задача относится к навыку \"Журнал ADR\".",
-  "triggers": [
-    "adr-log",
-    "adr log",
-    "Журнал ADR",
-    "Зафиксировать ключевые архитектурные решения (ADR) с trade-offs — Pros/Cons/Alternatives/Decision, статусом и датой"
-  ],
-  "capabilities": [
-    "adr",
-    "log"
-  ],
-  "tools": [],
-  "implicit_invocation": true
-}

package/.agents/skills/adr-log/agents/gemini.json

@@ -1,18 +0,0 @@
-{
-  "name": "adr-log",
-  "display_name": "Журнал ADR",
-  "description": "Зафиксировать ключевые архитектурные решения (ADR) с trade-offs — Pros/Cons/Alternatives/Decision, статусом и датой.",
-  "default_prompt": "Используй $adr-log, когда задача относится к навыку \"Журнал ADR\".",
-  "triggers": [
-    "adr-log",
-    "adr log",
-    "Журнал ADR",
-    "Зафиксировать ключевые архитектурные решения (ADR) с trade-offs — Pros/Cons/Alternatives/Decision, статусом и датой"
-  ],
-  "capabilities": [
-    "adr",
-    "log"
-  ],
-  "tools": [],
-  "implicit_invocation": true
-}

package/.agents/skills/adr-log/agents/openai.yaml

@@ -1,8 +0,0 @@
-interface:
-  display_name: "Журнал ADR"
-  short_description: "Зафиксировать ключевые архитектурные решения (ADR) с trade-offs — Pros/Cons/Alternatives/Decisi…"
-  default_prompt: "Используй $adr-log, когда задача относится к навыку \"Журнал ADR\"."
-dependencies:
-  tools: []
-policy:
-  allow_implicit_invocation: true

package/.agents/skills/adr-log/agents/qwen.json

@@ -1,18 +0,0 @@
-{
-  "name": "adr-log",
-  "display_name": "Журнал ADR",
-  "description": "Зафиксировать ключевые архитектурные решения (ADR) с trade-offs — Pros/Cons/Alternatives/Decision, статусом и датой.",
-  "default_prompt": "Используй $adr-log, когда задача относится к навыку \"Журнал ADR\".",
-  "triggers": [
-    "adr-log",
-    "adr log",
-    "Журнал ADR",
-    "Зафиксировать ключевые архитектурные решения (ADR) с trade-offs — Pros/Cons/Alternatives/Decision, статусом и датой"
-  ],
-  "capabilities": [
-    "adr",
-    "log"
-  ],
-  "tools": [],
-  "implicit_invocation": true
-}

package/.agents/skills/adr-log/agents/skill.yaml

@@ -1,22 +0,0 @@
-version: 1
-name: "adr-log"
-display_name: "Журнал ADR"
-description: "Зафиксировать ключевые архитектурные решения (ADR) с trade-offs — Pros/Cons/Alternatives/Decision, статусом и датой."
-default_prompt: "Используй $adr-log, когда задача относится к навыку \"Журнал ADR\"."
-triggers:
-  - "adr-log"
-  - "adr log"
-  - "Журнал ADR"
-  - "Зафиксировать ключевые архитектурные решения (ADR) с trade-offs — Pros/Cons/Alternatives/Decision, статусом и датой"
-capabilities:
-  - "adr"
-  - "log"
-tools: []
-invocation:
-  explicit: true
-  implicit: true
-localization:
-  default_locale: "ru"
-  available_locales:
-    - "ru"
-    - "en"

package/.agents/skills/api-contract-compliance-review/SKILL.md

@@ -1,224 +0,0 @@
----
-name: api-contract-compliance-review
-description: Проверка соответствия реализации API контрактам — схемы, коды ошибок, валидация, авторизация, идемпотентность, пагинация.
----
-
-# Skill: API Contract Compliance Review
-
-Ревью: реализация API соответствует заявленным контрактам.
-
-**Разделы:**
-1. [Workflow](#1-workflow)
-2. [Checklist](#2-checklist)
-3. [Verification Methods](#3-methods)
-4. [Common Mismatches](#4-mismatches)
-5. [Output Template](#5-output)
-
----
-
-## 1. Workflow
-
-```
-1. Загрузи API Contracts (из $api-contracts)
-   └── Список endpoints, schemas, error codes
-
-2. Для каждого endpoint:
-   a. Найди файл реализации (route → controller → service)
-   b. Сравни: method, path, request schema, response schema
-   c. Проверь: error format, status codes, auth, validation
-
-3. Проверь cross-cutting concerns:
-   └── Error format, pagination, auth, rate limiting
-
-4. Сформируй compliance report
-```
-
----
-
-## 2. Checklist
-
-### 2.1 Endpoint Compliance
-
-| # | Check | Severity | Status |
-|---|-------|----------|--------|
-| API-01 | Every documented endpoint exists in code | 🔴 P0 | ☐ |
-| API-02 | HTTP method matches contract (POST, not PUT for create) | 🔴 P0 | ☐ |
-| API-03 | URL path matches contract (naming, params) | 🔴 P0 | ☐ |
-| API-04 | Request body schema validates with Zod (matches contract fields) | 🔴 P0 | ☐ |
-| API-05 | Response body matches contract shape | 🔴 P0 | ☐ |
-| API-06 | No undocumented endpoints exist | 🟠 P1 | ☐ |
-
-### 2.2 Error Format
-
-| # | Check | Severity | Status |
-|---|-------|----------|--------|
-| API-07 | Error responses use unified format `{ error: { code, message } }` | 🔴 P0 | ☐ |
-| API-08 | Error codes match registry (VALIDATION_ERROR, NOT_FOUND, etc.) | 🟠 P1 | ☐ |
-| API-09 | No stack traces in error responses | 🔴 P0 | ☐ |
-| API-10 | Validation errors include `details` with field names | 🟠 P1 | ☐ |
-
-### 2.3 Status Codes
-
-| # | Check | Severity | Status |
-|---|-------|----------|--------|
-| API-11 | 200 for successful GET/PUT | 🟠 P1 | ☐ |
-| API-12 | 201 for successful POST (create) | 🟠 P1 | ☐ |
-| API-13 | 204 for successful DELETE | 🟠 P1 | ☐ |
-| API-14 | 400 for validation errors | 🟠 P1 | ☐ |
-| API-15 | 401 for missing auth, 403 for insufficient permissions | 🔴 P0 | ☐ |
-| API-16 | 404 for not found | 🟠 P1 | ☐ |
-| API-17 | 409 for conflict/duplicate | 🟠 P1 | ☐ |
-| API-18 | 500 only for unexpected errors (not for validation/auth!) | 🟠 P1 | ☐ |
-
-### 2.4 Auth & AuthZ
-
-| # | Check | Severity | Status |
-|---|-------|----------|--------|
-| API-19 | Protected endpoints have auth middleware | 🔴 P0 | ☐ |
-| API-20 | Public endpoints are intentionally public (documented) | 🟠 P1 | ☐ |
-| API-21 | IDOR protection: ownership check on data access | 🔴 P0 | ☐ |
-
-### 2.5 Pagination & Filtering
-
-| # | Check | Severity | Status |
-|---|-------|----------|--------|
-| API-22 | List endpoints have pagination (cursor or offset) | 🔴 P0 | ☐ |
-| API-23 | Pagination params match contract (limit, cursor/page) | 🟠 P1 | ☐ |
-| API-24 | Response includes pagination metadata (totalCount, hasMore) | 🟠 P1 | ☐ |
-| API-25 | Filter params documented and validated | 🟡 P2 | ☐ |
-
-### 2.6 Idempotency
-
-| # | Check | Severity | Status |
-|---|-------|----------|--------|
-| API-26 | Safe methods (GET) are idempotent | 🟠 P1 | ☐ |
-| API-27 | Risky create/charge operations support Idempotency-Key (if contract requires) | 🟡 P2 | ☐ |
-
----
-
-## 3. Verification Methods
-
-### Endpoint comparison table
-
-For each documented endpoint, fill in:
-
-```markdown
-| Contract | Implementation | Match? |
-|----------|---------------|:------:|
-| POST /api/v1/coupons | routes/coupons.js:12 → couponController.create | ✅ |
-| GET /api/v1/coupons | routes/coupons.js:8 → couponController.list | ✅ |
-| PUT /api/v1/settings/:id | routes/settings.js:15 → settingsController.update | ⚠️ PATCH vs PUT |
-| DELETE /api/v1/coupons/:id | — | ❌ NOT IMPLEMENTED |
-```
-
-### Schema comparison
-
-```javascript
-// Contract says:
-// POST /coupons → { code: string, discount: number, expiresAt: string(ISO) }
-
-// Check Zod schema in middleware:
-const createCouponSchema = z.object({
-  code: z.string().min(1).max(50),      // ✅ matches
-  discount: z.number().min(0).max(100),  // ✅ matches
-  expiresAt: z.string().datetime(),      // ✅ matches
-  // ❌ Missing: 'description' field from contract
-});
-```
-
-### Error format validation
-
-```javascript
-// Contract says: { error: { code: string, message: string, details?: object } }
-
-// Check actual error handler:
-grep_search: Query="res.status(4" Includes=["*/controllers/*"]
-grep_search: Query="res.status(5" Includes=["*/controllers/*"]
-// For each: does response match { error: { code, message } } format?
-```
-
-### Grep patterns
-
-```bash
-# Find all route definitions
-grep_search: Query="router\.(get|post|put|patch|delete)" Includes=["*/routes/*"] IsRegex=true
-
-# Find status codes used
-grep_search: Query="res.status(" Includes=["*.js"]
-
-# Find error responses
-grep_search: Query="error.*code" Includes=["*/controllers/*","*/middleware/*"]
-
-# Find auth middleware usage
-grep_search: Query="auth" Includes=["*/routes/*"]
-```
-
----
-
-## 4. Common Mismatches
-
-| Mismatch | Example | Severity | Fix |
-|----------|---------|----------|-----|
-| **Wrong status code** | POST returns 200 instead of 201 | 🟠 P1 | `res.status(201)` |
-| **Wrong method** | PUT for partial update (should be PATCH) | 🟠 P1 | Change to PATCH or justify in ADR |
-| **Error format inconsistent** | Some endpoints return `{ message }`, others `{ error: { code } }` | 🔴 P0 | Unify via error handler middleware |
-| **Missing validation** | Endpoint accepts any body shape | 🔴 P0 | Add Zod middleware |
-| **Missing fields in response** | Contract says `{ data, meta }` but returns only `{ data }` | 🟠 P1 | Add `meta` to response |
-| **Undocumented endpoint** | New endpoint exists without contract update | 🟠 P1 | Update API contracts doc |
-| **Auth on public endpoint** | Widget endpoint requires auth (should be public) | 🔴 P0 | Remove auth, verify contract |
-| **No pagination** | List returns all records | 🔴 P0 | Add pagination params |
-| **Mixed error details** | Some 400 include field errors, some don't | 🟠 P1 | Standardize `details` shape |
-
----
-
-## 5. Output Template
-
-```markdown
-# API Contract Compliance Review
-
-**Scope:** <module/PR>
-**Reviewer:** Reviewer Agent
-**Date:** YYYY-MM-DD
-**Contract reference:** docs/api-contracts.md
-
-## Endpoint Compliance
-
-| # | Contract Endpoint | Implementation | Method | Path | Schema | Auth | Status |
-|---|------------------|---------------|:------:|:----:|:------:|:----:|:------:|
-| 1 | POST /api/v1/coupons | couponController.create | ✅ | ✅ | ✅ | ✅ | ✅ |
-| 2 | GET /api/v1/coupons | couponController.list | ✅ | ✅ | ⚠️ | ✅ | ⚠️ |
-| 3 | PUT /api/v1/settings/:id | settingsController.update | ⚠️ | ✅ | ✅ | ✅ | ⚠️ |
-| 4 | DELETE /api/v1/coupons/:id | — | — | — | — | — | ❌ |
-
-## Findings
-
-| # | Severity | Check | File:Line | Mismatch | Fix |
-|---|----------|-------|-----------|----------|-----|
-| 1 | 🔴 P0 | API-01 | — | DELETE /coupons/:id not implemented | Implement or remove from contract |
-| 2 | 🟠 P1 | API-12 | `controllers/coupon.js:35` | POST returns 200 instead of 201 | Change to `res.status(201)` |
-| 3 | 🟠 P1 | API-02 | `routes/settings.js:15` | PUT used for partial update | Change to PATCH or update contract |
-
-## Error Format Compliance
-| Endpoint | Expected Format | Actual Format | Status |
-|----------|----------------|--------------|:------:|
-| POST /coupons (400) | `{ error: { code, message, details } }` | ✅ | Pass |
-| GET /coupons (500) | `{ error: { code, message } }` | `{ message: err.message }` | ❌ Fail |
-
-## Summary
-- Endpoints: X/Y compliant (Z% coverage)
-- P0 mismatches: N
-- P1 mismatches: M
-
-## Verdict
-- ✅ COMPLIANT — all endpoints match contract
-- ⚠️ DEVIATIONS — minor mismatches to fix
-- ❌ NON-COMPLIANT — critical contract violations
-```
-
----
-
-## См. также
-- `$api-contracts` — API contract definitions (source of truth)
-- `$code-review-checklist` — general review (API section)
-- `$security-review` — auth/validation depth (SEC-06..SEC-17)
-- `$review-reference-snippets` — DO/DON'T snippets (section M)