code-ai-installer 4.0.1-b → 4.0.1

package/domains/development/.agents/skills/qa-test-data-management/SKILL.md

@@ -1,250 +1,250 @@
----
-name: qa-test-data-management
-description: Управление test data — fixtures генерируются из real schemas (TS типы, DB schema, OpenAPI), PII hygiene (faker/factory_boy для синтетики), prod-like masking при копировании prod данных, environment isolation (testcontainers, transactional rollback, tempdir), fixture lifecycle. Защита от Mode 1 (mock obsession) — fixture не дрейфует от реальности.
-type: discretionary
-domain: development
-owners:
-  - tester
-gates:
-  - TEST
-tech:
-  - docker
-  - faker
-  - factory_boy
-topic:
-  - qa
-triggers:
-  - test data management
-  - test fixtures
-  - PII в тестах
-  - faker
-  - factory_boy
-  - testcontainers
-  - prod data masking
-  - fixture drift
-  - environment isolation
-related:
-  - qa-test-plan
-  - qa-regression-baseline
-  - qa-mutation-testing
-  - tests-quality-review
-budget_lines: 250
-schema_version: 1
----
-
-
-# Skill: QA Test Data Management
-
-Управление тестовыми данными так, чтобы fixtures **не дрейфовали от реальности**, **не содержали PII**, и **не загрязняли** среду между прогонами. Защита от Mode 1 Test Integrity Defense (mock obsession) — потому что mock obsession часто начинается с "придуманного руками" fixture которое расходится с реальной схемой.
-
-**Разделы:**
-1. [Когда применять](#1-когда)
-2. [Fixture derivation from real schemas](#2-derivation)
-3. [PII hygiene](#3-pii)
-4. [Prod-like data masking](#4-masking)
-5. [Environment isolation](#5-isolation)
-6. [Fixture lifecycle](#6-lifecycle)
-7. [Anti-patterns](#7-anti)
-8. [Output template](#8-output)
-9. [DoD](#9-dod)
-
----
-
-## <a id="1-когда"></a>1. Когда применять
-
-**Триггеры:**
-- Первый интеграционный тест на новый модуль / новую DB таблицу / новый API endpoint
-- Security alert: PII обнаружено в test fixtures (auto-scan, см. `$qa-test-integrity-audit`)
-- DB schema migration — fixtures всех затронутых тестов нужно re-generate
-- Stabilization sprint включает audit test data quality
-
-**Outputs:**
-- Fixture generation скрипт / decorator / factory class
-- Mask config для prod-data clone (если применимо)
-- Cleanup hooks для testcontainers / tempdir
-- PII audit report
-
----
-
-## <a id="2-derivation"></a>2. Fixture derivation from real schemas
-
-**Правило:** fixture генерируется из source-of-truth схемы, не "придуман руками".
-
-**JS/TS — из TypeScript типов через faker:**
-```ts
-import { faker } from "@faker-js/faker";
-import type { User } from "@/types/user";
-
-export function makeUser(overrides?: Partial<User>): User {
-  return {
-    id: faker.string.uuid(),
-    email: faker.internet.email(),
-    name: faker.person.fullName(),
-    role: "user",
-    createdAt: faker.date.recent(),
-    ...overrides,
-  };
-}
-```
-
-**Python — из dataclass через factory_boy:**
-```python
-import factory
-from app.models import User
-
-class UserFactory(factory.Factory):
-    class Meta:
-        model = User
-    id = factory.Faker("uuid4")
-    email = factory.Faker("email")
-    name = factory.Faker("name")
-    role = "user"
-```
-
-**Из OpenAPI / JSON Schema:** используй `openapi-typescript-codegen` (TS) или `datamodel-code-generator` (Python) для type derivation, затем factory как выше.
-
-**Зачем:** schema меняется — type meняется — factory падает на компиляции — тесты переписаны под новую схему. Без этого fixture тихо устаревает, тесты зелёные, prod падает.
-
----
-
-## <a id="3-pii"></a>3. PII hygiene
-
-**Что НЕ должно попадать в test fixtures (никогда):**
-- Real emails / phones / addresses (даже свои)
-- Real payment data (CC numbers, IBAN, SWIFT)
-- Real names of real people
-- Real API keys / tokens / passwords
-- Real customer IDs from prod
-
-**Что использовать вместо:**
-- **faker** (JS/TS): `faker.internet.email()`, `faker.phone.number()`, `faker.location.streetAddress()`
-- **factory_boy + faker** (Python): `factory.Faker("email")`, `factory.Faker("phone_number")`
-
-**Detection:** ESLint rule `no-restricted-syntax` + custom regex на email/phone patterns в test files. Pre-commit hook block если найдено что-то похожее на real PII (см. `$qa-test-integrity-audit` §1).
-
-**Если случайно закоммитили PII:**
-1. Rotate compromised credentials немедленно
-2. Filter git history (`git filter-repo`) — НЕ rebase, чтобы оригинальные commits были недоступны
-3. Notify owners если real customer data была
-4. Document incident в security-baseline-dev runbook
-
----
-
-## <a id="4-masking"></a>4. Prod-like data masking
-
-Иногда нужно тестировать на realistic distribution (volume, edge cases) — копируем prod data в staging/test, но **маскируем PII**.
-
-**Masking rules:**
-- **Emails:** replace local part с hash, keep domain category (`user-a3f9@example.com`)
-- **Names:** replace с faker.person.fullName() seeded by hash of original (consistent within run)
-- **Phones:** randomize last 4 digits keeping country code
-- **Dates:** shift by random Δ ±30 days (preserve weekday patterns)
-- **IDs:** preserve referential integrity through deterministic mapping (`user_123 → user_anon_xyz` consistently)
-- **Payment:** zeroize CC, randomize amounts within ±20% range
-
-**Tools:** `pgmasq` (Postgres), `Faker.unique` + custom transformers, в-house masking script. Run AS PART OF prod→staging sync, не в test runtime.
-
-**Audit:** после mask sample 100 rows, manual check on no leakage. Document mask config in repo so reviewer audits.
-
----
-
-## <a id="5-isolation"></a>5. Environment isolation
-
-Каждый прогон тестов должен начинаться с **clean state** и **не оставлять** артефактов следующему.
-
-**DB isolation patterns:**
-- **Testcontainers** (Docker-based fresh DB per test suite): `@testcontainers/postgresql` (JS), `testcontainers` (Python). Spin up real Postgres/MongoDB в Docker container, teardown after.
-- **Transactional rollback** (быстрее testcontainers): wrap test в transaction, rollback at end. Works for SQL DBs, не работает для MongoDB.
-- **In-memory adapters** (быстрее всех, но менее real): SQLite for Postgres-like, mongo-memory-server.
-
-**File system isolation:**
-- `tmp` директории per test (`os.tmpdir()` + uuid)
-- Cleanup в `afterEach` / pytest fixture teardown
-- НЕ использовать shared `tests/fixtures/output/` директорию
-
-**Network isolation:**
-- MSW (JS) / responses (Python) для mock external HTTP at boundary
-- Никогда не hit реальный API в тесте — flaky + slow + cost
-
-**State между тестами:**
-- Module-level state НЕ shared (avoid singletons в production code или wipe в `beforeEach`)
-- DB indexes/sequences reset between suites
-
----
-
-## <a id="6-lifecycle"></a>6. Fixture lifecycle
-
-**Create:**
-- Generation через factory (не hardcode)
-- Minimum data needed for test (no "kitchen sink" fixtures)
-- Specific test → specific fixture builder
-
-**Use:**
-- Один тест → один fixture instance (не shared)
-- Если нужны связанные entities — factory composition (`UserFactory.subFactory(OrderFactory)`)
-- Overrides только для test-specific вариаций
-
-**Cleanup:**
-- Testcontainers — auto-teardown on suite exit
-- DB transactional rollback — auto on test exit
-- File system — `afterEach` cleanup hook
-- Tempdir — registered for OS cleanup
-
-**Storage convention:**
-- Factory definitions: `tests/factories/` (JS) или `tests/conftest.py` + factory module (Python)
-- Test data files: НЕ commit large fixture JSON files в git; generate on demand
-- Snapshot files OK в git (Playwright traces, vitest snapshots) — но без PII
-
----
-
-## <a id="7-anti"></a>7. Anti-patterns
-
-- 🔴 **Hardcoded real PII** — `expect(user.email).toBe("denis@light-tech.io")` — security leak + flaky когда DEN меняет email.
-- 🔴 **Shared mutable fixture** — `beforeAll(() => fixture = makeUser())` + tests mutate fixture — order dependence, flaky.
-- 🔴 **Fixture drift** — handcrafted `{id: 1, name: "test"}` который не использует TS type / schema. Schema меняется, fixture не падает, prod падает.
-- 🟠 **No cleanup** — testcontainers вы стартанули, забыли teardown — CI runner забит зомби-контейнерами через час.
-- 🟠 **Kitchen sink fixture** — `makeUserWithEverything()` возвращает user + orders + payments + sessions — каждый тест получает больше чем нужно, обновление ломает все тесты.
-- 🟡 **Faker без seed** — рандомность хорошо, но без seed невозможно воспроизвести failing test. Pin seed for reproducible builds (`faker.seed(42)` per test).
-
----
-
-## <a id="8-output"></a>8. Output template
-
-Tester включает в TEST report (если применимо):
-
-```
-### Test Data Management
-- Factories used: N (list)
-- PII audit: pass / N findings
-- Masking config: configured / N/A
-- Environment isolation:
-  - testcontainers: N suites
-  - transactional rollback: N suites
-  - tempdir cleanup: configured
-- Fixture seeding: seeded (reproducible) / random
-- Action items: [fixture refactors / PII findings to fix]
-```
-
----
-
-## <a id="9-dod"></a>9. DoD
-
-- [ ] Все fixtures генерируются через factory (no hardcoded entities)
-- [ ] PII audit pre-commit hook настроен (см. `$qa-test-integrity-audit`)
-- [ ] Environment isolation: testcontainers или transactional rollback per integration suite
-- [ ] Mask config документирован для любого prod→staging sync
-- [ ] Cleanup hooks в каждом test suite (no zombie state)
-- [ ] Faker seed pin'нут для reproducibility
-- [ ] Output template включён в TEST report
-
----
-
-## См. также
-
-- `$qa-test-plan` — план тестирования учитывает test data requirements per flow
-- `$qa-regression-baseline` — baseline tracks fixture changes between releases
-- `$qa-mutation-testing` — mutation сильно зависит от quality fixtures
-- `$qa-test-integrity-audit` — PII detection rules + fixture drift detection
-- `$qa-flaky-test-protocol` — env isolation issues → flaky cause
-- `$tests-quality-review` — Reviewer-side audit включая test data quality
-- `$security-baseline-dev` — PII handling rules consistent с production code
+---
+name: qa-test-data-management
+description: Управление test data — fixtures генерируются из real schemas (TS типы, DB schema, OpenAPI), PII hygiene (faker/factory_boy для синтетики), prod-like masking при копировании prod данных, environment isolation (testcontainers, transactional rollback, tempdir), fixture lifecycle. Защита от Mode 1 (mock obsession) — fixture не дрейфует от реальности.
+type: discretionary
+domain: development
+owners:
+  - tester
+gates:
+  - TEST
+tech:
+  - docker
+  - faker
+  - factory_boy
+topic:
+  - qa
+triggers:
+  - test data management
+  - test fixtures
+  - PII в тестах
+  - faker
+  - factory_boy
+  - testcontainers
+  - prod data masking
+  - fixture drift
+  - environment isolation
+related:
+  - qa-test-plan
+  - qa-regression-baseline
+  - qa-mutation-testing
+  - tests-quality-review
+budget_lines: 250
+schema_version: 1
+---
+
+
+# Skill: QA Test Data Management
+
+Управление тестовыми данными так, чтобы fixtures **не дрейфовали от реальности**, **не содержали PII**, и **не загрязняли** среду между прогонами. Защита от Mode 1 Test Integrity Defense (mock obsession) — потому что mock obsession часто начинается с "придуманного руками" fixture которое расходится с реальной схемой.
+
+**Разделы:**
+1. [Когда применять](#1-когда)
+2. [Fixture derivation from real schemas](#2-derivation)
+3. [PII hygiene](#3-pii)
+4. [Prod-like data masking](#4-masking)
+5. [Environment isolation](#5-isolation)
+6. [Fixture lifecycle](#6-lifecycle)
+7. [Anti-patterns](#7-anti)
+8. [Output template](#8-output)
+9. [DoD](#9-dod)
+
+---
+
+## <a id="1-когда"></a>1. Когда применять
+
+**Триггеры:**
+- Первый интеграционный тест на новый модуль / новую DB таблицу / новый API endpoint
+- Security alert: PII обнаружено в test fixtures (auto-scan, см. `$qa-test-integrity-audit`)
+- DB schema migration — fixtures всех затронутых тестов нужно re-generate
+- Stabilization sprint включает audit test data quality
+
+**Outputs:**
+- Fixture generation скрипт / decorator / factory class
+- Mask config для prod-data clone (если применимо)
+- Cleanup hooks для testcontainers / tempdir
+- PII audit report
+
+---
+
+## <a id="2-derivation"></a>2. Fixture derivation from real schemas
+
+**Правило:** fixture генерируется из source-of-truth схемы, не "придуман руками".
+
+**JS/TS — из TypeScript типов через faker:**
+```ts
+import { faker } from "@faker-js/faker";
+import type { User } from "@/types/user";
+
+export function makeUser(overrides?: Partial<User>): User {
+  return {
+    id: faker.string.uuid(),
+    email: faker.internet.email(),
+    name: faker.person.fullName(),
+    role: "user",
+    createdAt: faker.date.recent(),
+    ...overrides,
+  };
+}
+```
+
+**Python — из dataclass через factory_boy:**
+```python
+import factory
+from app.models import User
+
+class UserFactory(factory.Factory):
+    class Meta:
+        model = User
+    id = factory.Faker("uuid4")
+    email = factory.Faker("email")
+    name = factory.Faker("name")
+    role = "user"
+```
+
+**Из OpenAPI / JSON Schema:** используй `openapi-typescript-codegen` (TS) или `datamodel-code-generator` (Python) для type derivation, затем factory как выше.
+
+**Зачем:** schema меняется — type meняется — factory падает на компиляции — тесты переписаны под новую схему. Без этого fixture тихо устаревает, тесты зелёные, prod падает.
+
+---
+
+## <a id="3-pii"></a>3. PII hygiene
+
+**Что НЕ должно попадать в test fixtures (никогда):**
+- Real emails / phones / addresses (даже свои)
+- Real payment data (CC numbers, IBAN, SWIFT)
+- Real names of real people
+- Real API keys / tokens / passwords
+- Real customer IDs from prod
+
+**Что использовать вместо:**
+- **faker** (JS/TS): `faker.internet.email()`, `faker.phone.number()`, `faker.location.streetAddress()`
+- **factory_boy + faker** (Python): `factory.Faker("email")`, `factory.Faker("phone_number")`
+
+**Detection:** ESLint rule `no-restricted-syntax` + custom regex на email/phone patterns в test files. Pre-commit hook block если найдено что-то похожее на real PII (см. `$qa-test-integrity-audit` §1).
+
+**Если случайно закоммитили PII:**
+1. Rotate compromised credentials немедленно
+2. Filter git history (`git filter-repo`) — НЕ rebase, чтобы оригинальные commits были недоступны
+3. Notify owners если real customer data была
+4. Document incident в security-baseline-dev runbook
+
+---
+
+## <a id="4-masking"></a>4. Prod-like data masking
+
+Иногда нужно тестировать на realistic distribution (volume, edge cases) — копируем prod data в staging/test, но **маскируем PII**.
+
+**Masking rules:**
+- **Emails:** replace local part с hash, keep domain category (`user-a3f9@example.com`)
+- **Names:** replace с faker.person.fullName() seeded by hash of original (consistent within run)
+- **Phones:** randomize last 4 digits keeping country code
+- **Dates:** shift by random Δ ±30 days (preserve weekday patterns)
+- **IDs:** preserve referential integrity through deterministic mapping (`user_123 → user_anon_xyz` consistently)
+- **Payment:** zeroize CC, randomize amounts within ±20% range
+
+**Tools:** `pgmasq` (Postgres), `Faker.unique` + custom transformers, в-house masking script. Run AS PART OF prod→staging sync, не в test runtime.
+
+**Audit:** после mask sample 100 rows, manual check on no leakage. Document mask config in repo so reviewer audits.
+
+---
+
+## <a id="5-isolation"></a>5. Environment isolation
+
+Каждый прогон тестов должен начинаться с **clean state** и **не оставлять** артефактов следующему.
+
+**DB isolation patterns:**
+- **Testcontainers** (Docker-based fresh DB per test suite): `@testcontainers/postgresql` (JS), `testcontainers` (Python). Spin up real Postgres/MongoDB в Docker container, teardown after.
+- **Transactional rollback** (быстрее testcontainers): wrap test в transaction, rollback at end. Works for SQL DBs, не работает для MongoDB.
+- **In-memory adapters** (быстрее всех, но менее real): SQLite for Postgres-like, mongo-memory-server.
+
+**File system isolation:**
+- `tmp` директории per test (`os.tmpdir()` + uuid)
+- Cleanup в `afterEach` / pytest fixture teardown
+- НЕ использовать shared `tests/fixtures/output/` директорию
+
+**Network isolation:**
+- MSW (JS) / responses (Python) для mock external HTTP at boundary
+- Никогда не hit реальный API в тесте — flaky + slow + cost
+
+**State между тестами:**
+- Module-level state НЕ shared (avoid singletons в production code или wipe в `beforeEach`)
+- DB indexes/sequences reset between suites
+
+---
+
+## <a id="6-lifecycle"></a>6. Fixture lifecycle
+
+**Create:**
+- Generation через factory (не hardcode)
+- Minimum data needed for test (no "kitchen sink" fixtures)
+- Specific test → specific fixture builder
+
+**Use:**
+- Один тест → один fixture instance (не shared)
+- Если нужны связанные entities — factory composition (`UserFactory.subFactory(OrderFactory)`)
+- Overrides только для test-specific вариаций
+
+**Cleanup:**
+- Testcontainers — auto-teardown on suite exit
+- DB transactional rollback — auto on test exit
+- File system — `afterEach` cleanup hook
+- Tempdir — registered for OS cleanup
+
+**Storage convention:**
+- Factory definitions: `tests/factories/` (JS) или `tests/conftest.py` + factory module (Python)
+- Test data files: НЕ commit large fixture JSON files в git; generate on demand
+- Snapshot files OK в git (Playwright traces, vitest snapshots) — но без PII
+
+---
+
+## <a id="7-anti"></a>7. Anti-patterns
+
+- 🔴 **Hardcoded real PII** — `expect(user.email).toBe("user@example.com")` — security leak + flaky когда пользователь меняет email.
+- 🔴 **Shared mutable fixture** — `beforeAll(() => fixture = makeUser())` + tests mutate fixture — order dependence, flaky.
+- 🔴 **Fixture drift** — handcrafted `{id: 1, name: "test"}` который не использует TS type / schema. Schema меняется, fixture не падает, prod падает.
+- 🟠 **No cleanup** — testcontainers вы стартанули, забыли teardown — CI runner забит зомби-контейнерами через час.
+- 🟠 **Kitchen sink fixture** — `makeUserWithEverything()` возвращает user + orders + payments + sessions — каждый тест получает больше чем нужно, обновление ломает все тесты.
+- 🟡 **Faker без seed** — рандомность хорошо, но без seed невозможно воспроизвести failing test. Pin seed for reproducible builds (`faker.seed(42)` per test).
+
+---
+
+## <a id="8-output"></a>8. Output template
+
+Tester включает в TEST report (если применимо):
+
+```
+### Test Data Management
+- Factories used: N (list)
+- PII audit: pass / N findings
+- Masking config: configured / N/A
+- Environment isolation:
+  - testcontainers: N suites
+  - transactional rollback: N suites
+  - tempdir cleanup: configured
+- Fixture seeding: seeded (reproducible) / random
+- Action items: [fixture refactors / PII findings to fix]
+```
+
+---
+
+## <a id="9-dod"></a>9. DoD
+
+- [ ] Все fixtures генерируются через factory (no hardcoded entities)
+- [ ] PII audit pre-commit hook настроен (см. `$qa-test-integrity-audit`)
+- [ ] Environment isolation: testcontainers или transactional rollback per integration suite
+- [ ] Mask config документирован для любого prod→staging sync
+- [ ] Cleanup hooks в каждом test suite (no zombie state)
+- [ ] Faker seed pin'нут для reproducibility
+- [ ] Output template включён в TEST report
+
+---
+
+## См. также
+
+- `$qa-test-plan` — план тестирования учитывает test data requirements per flow
+- `$qa-regression-baseline` — baseline tracks fixture changes between releases
+- `$qa-mutation-testing` — mutation сильно зависит от quality fixtures
+- `$qa-test-integrity-audit` — PII detection rules + fixture drift detection
+- `$qa-flaky-test-protocol` — env isolation issues → flaky cause
+- `$tests-quality-review` — Reviewer-side audit включая test data quality
+- `$security-baseline-dev` — PII handling rules consistent с production code

package/domains/development/.agents/workflows/bugfix.md

@@ -1,90 +1,24 @@
 ---
-description: Запуск сокращённого 4-гейтового пайплайна для исправления багов. Используй вместо /start-task для bugfix-задач.
+description: Запуск сокращённого багфикс-пайплайна (3 гейта: DEV → REV → TEST).
 ---
 
-# /bugfix — Запуск Bugfix Pipeline (4 гейта)
+# /bugfix — багфикс-пайплайн (3 гейта)
 
-> 🟢 **Режим:** Bugfix — для исправления багов в существующем функционале.
-> Полный пайплайн: `/start-task`. Hotfix (мелочи): `/hotfix`.
+> 🟢 Для багов в существующем функционале. Полный режим — `/start-task`, мелочь — `/hotfix`.
+> Абсолютные правила — в `pipeline-rules`.
 
-## Когда использовать
+## Когда
+- Баг в логике, ошибки API, сломанная валидация, проблемы с данными.
+- Затрагивает > 2 файлов или нетривиальный blast radius.
+- НЕ меняет UI-layout, не добавляет API, не меняет схему данных (иначе → `/start-task`).
 
-- Баг в логике, API ошибки, сломанная валидация, проблемы с данными
-- Затрагивает > 2 файлов или нетривиальный blast radius
-- НЕ меняет UI layout, НЕ добавляет новый API, НЕ меняет схему данных (иначе → `/start-task`)
+## Поток
+Conductor подтверждает режим (bugfix) и инициализирует доску. Затем по гейтам через поток MCP (`classify_gate → load_role → submit_artifact → sign_off → advance_gate`):
+1. **DEV** — TDD-фикс: RED (тест, воспроизводящий баг) → GREEN → REFACTOR; JSDoc. Подпись `mcp`.
+2. **REV** — ревью: тест реально воспроизводит баг? побочные эффекты? regression-риск? Подпись `mcp`.
+3. **TEST** — верификация: баг исправлен, регрессий нет; авто-пас на зелёном `run_tests`. Подпись `mcp`.
 
-## Шаг 0: Загрузить правила
+Пользователь в рутину не вовлекается — только на `fork` через `request_decision`.
 
-Выполни `/pipeline-rules` — прочитай правила ПЕРЕД началом работы.
-
-## Шаг 1: CONDUCTOR — Классификация
-
-1. Выполни `view_file` на `agents/conductor.md`
-2. Подтверди что задача = bugfix (по Decision Tree)
-3. Создай Mini Checklist:
-```
-[ ] BF-DEV-01   Fix + TDD + Handoff Envelope
-[ ] BF-REV-01   Code review + regression check + Handoff Envelope
-[ ] BF-TEST-01  Verification + regression smoke + GO/NO-GO
-```
-4. `notify_user` → ждать **Approved**
-
-## Шаг 2: DEV — TDD-фикс
-
-1. Выполни `view_file` на `agents/senior_full_stack.md`
-2. Пройди протокол (пропуская §1 UX review и §6 DEMO):
-   - §0: Context + read skills
-   - §2: Analyze bug + root cause
-   - §3: RED — написать падающий тест, воспроизводящий баг
-   - §4: GREEN — минимальный код для прохождения теста
-   - §5: REFACTOR — улучшить без изменения поведения
-   - §7: JSDoc на изменённых функциях
-3. Перезапустить затронутые сервисы (если применимо)
-4. Сформировать Handoff Envelope → REV
-5. `notify_user` → ждать **Approved**
-
-## Шаг 3: REV — Code Review
-
-1. Выполни `view_file` на `agents/reviewer.md`
-2. Фокус ревью:
-   - Тест действительно воспроизводит баг (RED-фаза)?
-   - Фикс не создаёт побочных эффектов?
-   - Regression risk оценён?
-   - JSDoc на месте?
-3. Сформировать Handoff Envelope → TEST
-4. `notify_user` → ждать **Approved**
-
-## Шаг 4: TEST — Верификация
-
-1. Выполни `view_file` на `agents/tester.md`
-2. Проверить:
-   - Баг исправлен (по шагам воспроизведения)
-   - Регрессии нет (smoke по затронутым модулям)
-   - Тесты проходят (CI green)
-3. Вынести вердикт: **GO ✅ / NO-GO ❌**
-4. `notify_user` → ждать **Approved**
-
----
-
-## При FAIL на REV или TEST
-
-1. Агент выдаёт FAIL Report + Handoff → DEV
-2. DEV исправляет → Handoff → REV → TEST (повтор цикла)
-3. Approved на каждом гейте обязателен
-
----
-
-## Шаблон промпта
-
-```
-@AGENTS.md /bugfix
-
-Баг: [описание бага, 1-2 предложения].
-Воспроизведение: [шаги, если известны].
-Файлы: [затронутые файлы, если известны].
-
-Правила:
-1. Bugfix Pipeline: CONDUCTOR → DEV → REV → TEST
-2. TDD обязательно (RED → GREEN → REFACTOR)
-3. Approved на каждом гейте
-```
+## Fix Cycle
+FAIL на REV/TEST или красный `run_tests` → откат к DEV. 2 отката на полосе → аудит Архитектора в свежей сессии (`pipeline-rules`).