@bonesofspring/ai-rules 0.2.14 → 0.2.15

package/presets/cursor/nuxt/rules/technical-retro.mdc

@@ -1,16 +1,16 @@
 ---
-description: Роль агента для проведения технического ретроспективы (retro) команды / спринта. On-demand — предпочтительнее slash-команда /technical-retro.
+description: Agent role for running a technical retrospective (retro) for a team / sprint. On-demand — prefer the /technical-retro slash command.
 alwaysApply: false
 ---
 
 <!-- shared-core: review/technical-retro.md -->
 
-# Техническое ретро — rule alias
+# Technical retro — rule alias
 
-Полный сценарий (включая блок **«Работа агентов»** для slug из team tasks) — в slash-команде:
+Full scenario (including the **“Agent work”** block for a slug from team tasks) lives in the slash command:
 
 **`commands/technical-retro.md`** → `/technical-retro`
 
 When a task has `metrics.json`, use the local aggregation script and state the cohort, sample size, incomplete artifacts, attribution confidence, active attempt duration, and human-gate wait separately. Do not score malformed artifacts or gate wait as agent work.
 
-Используй rule только если command недоступен. Не дублируй содержимое command в ответе — следуй command-файлу и skill `technical-retro`.
+Use this rule only if the command is unavailable. Do not duplicate the command contents in the response — follow the command file and skill `technical-retro`.

package/presets/cursor/nuxt/rules/tests-e2e-structure.mdc

@@ -1,51 +1,50 @@
 ---
-description: Структура e2e тестов и планов (Playwright)
+description: Structure of e2e tests and plans (Playwright)
 globs: tests/e2e/**/*
 alwaysApply: false
 ---
 
-# Структура e2e в проекте
-
-- Папка e2e: `tests/e2e/**`.
-- Планы сценариев:
-  - `*.cases.md` файлы — **канонический источник сценариев**.
-- Тесты:
-  - `*.spec.ts` файлы — реализация сценариев на Playwright.
-- Общие утилиты и абстракции:
-  - `tests/e2e/_shared/**` — константы, fluent‑интерфейсы, хелперы.
-
-# Принципы
-
-- Каждый сценарий из `*.cases.md` должен иметь соответствующий тест (или набор тестов).
-- **Нельзя** ослаблять проверки в тестах, если это противоречит бизнес‑ожиданиям из планов.
-- Предпочтительно использовать:
-  - page‑objects (например, `OrderHistoryPage.ts`);
-  - общие хелперы из `_shared`.
-
-# Именование e2e‑тестов
-
-- Язык:
-  - все названия `test` / `it`, `describe`‑блоков и шагов в `*.cases.md` должны быть сформулированы **на русском языке**, описывая поведение и ожидаемый результат.
-- Формат заголовков e2e‑тестов (`test(...)` / `it(...)`):
-  - перед текстовым описанием сценария указывается **префикс с номером** в формате: `ПРЕФИКС-XXX Описание сценария`.
-  - `ПРЕФИКС` — аббревиатура из **первых букв слов** тестируемой сущности, записанная **латиницей в верхнем регистре**.
-    - пример: `OrderHistory` → `OH`, `BillingReport` → `BR`.
-  - `XXX` — порядковый номер теста **с тремя разрядами и лидирующими нулями**: `001`, `002`, `010`, `123` и т.д.
-  - пример полного названия e2e‑теста:
-    - `test('OH-001 Отображается список заказов', async ({ page }) => { ... })`
-  - внутри одной сущности (`ПРЕФИКС`) номера тестов должны образовывать **непротиворечивую последовательность**, без дубликатов номеров.
-
-# data-testid для e2e
-
-- **Приоритет селекторов:** `data-testid` для стабильных элементов; `getByRole` и `getByLabel` для форм и доступных элементов.
-- **Именование:** схема `{parent}__{element}` (например, `history-page__title`, `history-page__recognition-banner__attach-files-button`).
-- **Где добавлять:** на корневые контейнеры страниц и ключевые интерактивные элементы (кнопки, ссылки, поля), к которым обращаются page objects.
-- **При изменении UI:** обновлять data-testid в компонентах и соответствующие селекторы в page objects; сверять с `*.cases.md`.
-
-# Требование к агенту
-
-При добавлении/изменении e2e‑тестов:
-- Сначала смотреть соответствующий `*.cases.md` и синхронизировать названия сценариев.
-- Размещать спеки рядом с планами в той же директории.
-- Переиспользовать общие page‑objects и хелперы, а не копировать селекторы напрямую в каждый тест.
-
+# E2E structure in the project
+
+- E2E folder: `tests/e2e/**`.
+- Scenario plans:
+  - `*.cases.md` files — **canonical source of scenarios**.
+- Tests:
+  - `*.spec.ts` files — Playwright scenario implementation.
+- Shared utilities and abstractions:
+  - `tests/e2e/_shared/**` — constants, fluent interfaces, helpers.
+
+# Principles
+
+- Every scenario from `*.cases.md` must have a matching test (or set of tests).
+- **Do not** weaken assertions in tests if that contradicts business expectations from the plans.
+- Prefer:
+  - page objects (e.g. `OrderHistoryPage.ts`);
+  - shared helpers from `_shared`.
+
+# E2E test naming
+
+- Language:
+  - all `test` / `it` names, `describe` blocks, and steps in `*.cases.md` must be formulated **in Russian**, describing behavior and the expected result. <!-- i18n-keep: E5 -->
+- E2E title format (`test(...)` / `it(...)`):
+  - before the scenario description, put a **numbered prefix** in the form: `PREFIX-XXX Scenario description`.
+  - `PREFIX` — abbreviation from the **first letters of the words** of the entity under test, written in **Latin uppercase**.
+    - example: `OrderHistory` → `OH`, `BillingReport` → `BR`.
+  - `XXX` — sequential test number **with three digits and leading zeros**: `001`, `002`, `010`, `123`, etc.
+  - full e2e title example:
+    - `test('OH-001 Отображается список заказов', async ({ page }) => { ... })` <!-- i18n-keep: E5 -->
+  - within one entity (`PREFIX`), test numbers must form a **consistent sequence** without duplicate numbers.
+
+# data-testid for e2e
+
+- **Selector priority:** `data-testid` for stable elements; `getByRole` and `getByLabel` for forms and accessible elements.
+- **Naming:** scheme `{parent}__{element}` (e.g. `history-page__title`, `history-page__recognition-banner__attach-files-button`).
+- **Where to add:** on page root containers and key interactive elements (buttons, links, fields) that page objects target.
+- **When UI changes:** update data-testid in components and matching selectors in page objects; align with `*.cases.md`.
+
+# Agent requirement
+
+When adding/changing e2e tests:
+- First look at the matching `*.cases.md` and sync scenario names.
+- Place specs next to plans in the same directory.
+- Reuse shared page objects and helpers; do not copy selectors into every test.

package/presets/cursor/nuxt/rules/tests-unit.mdc

@@ -1,5 +1,5 @@
 ---
-description: Unit и интеграционные тесты (Testing Library и runner проекта)
+description: Unit and integration tests (Testing Library and project runner)
 globs:
   - **/*.spec.{ts,tsx}
   - **/*.test.{ts,tsx}
@@ -7,72 +7,71 @@ alwaysApply: false
 impact: MEDIUM
 ---
 
-# Общие правила тестирования
-
-- **Имена файлов:** для **новых** тестов использовать суффикс **`*.spec.ts` / `*.spec.ts`**. Существующие **`*.test.ts` / `*.test.tsx`** не переименовывать без отдельной задачи (легаси).
-- **Runner и матчеры** — как в проекте (часто Jest или Vitest); для компонентов — **@vue/test-utils**.
-- Основная цель тестов:
-  - проверять **поведение и бизнес‑правила**, а не реализацию или внутренние детали.
-- **Именование unit‑тестов** (строки в `describe` / `it` / `test`):
-  - формулировки **только на русском языке** — понятные бизнес‑фразы (что проверяется и какой ожидается результат);
-  - **каждое предложение** в названии **начинается с заглавной буквы** (в том числе после `.`, `!`, `?` и при нескольких предложениях в одной строке); первая буква всей строки — тоже заглавная.
-  - **Проверка в CI:** ESLint (`jest/valid-title` в `eslint.config.mjs`) требует, чтобы строка начиналась с русской заглавной (А–Я, Ё), и запрещает пробел после точки, за которым сразу идёт строчная буква (типичный случай нарушения «с заглавной после точки»).
-
-```typescript
-// ✅ Хорошо
-it('Возвращает пустой список. Пользователь не авторизован', () => {})
-it('При ошибке сети показывается сообщение об ошибке', () => {})
-
-// ❌ Плохо (не с заглавной после точки; или не русский)
-it('Возвращает пустой список. пользователь не авторизован', () => {})
-it('Returns empty list when user is guest', () => {})
-```
+# General testing rules
+
+- **File names:** for **new** tests use the **`*.spec.ts` / `*.spec.ts`** suffix. Do not rename existing **`*.test.ts` / `*.test.tsx`** without a separate task (legacy).
+- **Runner and matchers** — as in the project (often Jest or Vitest); for components — **@vue/test-utils**.
+- Primary goal of tests:
+  - verify **behavior and business rules**, not implementation or internal details.
+- **Unit test naming** (strings in `describe` / `it` / `test`):
+  - consumer apps **may use Russian locale** for titles — clear business phrases (what is checked and expected outcome);
+  - when ESLint enforces Russian (see below), each sentence in the title **must start with a capital letter** (including after `.`, `!`, `?` and with multiple sentences on one line); the first letter of the whole string is capitalized too.
+  - **CI check (when configured):** ESLint (`jest/valid-title` in `eslint.config.mjs`) may require titles to start with a Russian capital letter and forbid a space after `.` followed immediately by a lowercase letter (typical "capital after period" violation).
+
+Good (Russian locale in consumer app):
+
+- `it('Возвращает пустой список. Пользователь не авторизован', () => {})` <!-- i18n-keep: E5 --> (Returns empty list. User is not authorized)
+- `it('При ошибке сети показывается сообщение об ошибке', () => {})` <!-- i18n-keep: E5 --> (On network error, an error message is shown)
+
+Bad (no capital after period; or wrong locale for configured ESLint):
 
-# Тесты компонентов
+- `it('Возвращает пустой список. пользователь не авторизован', () => {})` <!-- i18n-keep: E5 -->
+- `it('Returns empty list when user is guest', () => {})`
 
-- Использовать `render` из `@vue/test-utils`.
-- Ассерты:
-  - матчеры DOM для Testing Library, как подключены в проекте (`toBeInTheDocument`, `toHaveTextContent` и т.п.).
-- Взаимодействия:
-  - `userEvent` из `@testing-library/user-event`.
+# Component tests
 
-# Изоляция и моки
+- Use `render` from `@vue/test-utils`.
+- Assertions:
+  - DOM matchers for Testing Library as wired in the project (`toBeInTheDocument`, `toHaveTextContent`, etc.).
+- Interactions:
+  - `userEvent` from `@testing-library/user-event`.
 
-- Для работы с API/store:
-  - мокать store (через test‑store) или использовать принятый в проекте способ моков HTTP/API.
-- Не мокать то, что является частью публичного контракта фичи, если это ломает смысл теста.
+# Isolation and mocks
 
-# HTTP‑клиент
+- For API/store work:
+  - mock the store (via test-store) or use the project's accepted HTTP/API mock approach.
+- Do not mock what is part of the feature's public contract if that breaks the test's meaning.
 
-- При изменении **реализации общего HTTP‑клиента** (разбор тел, заголовки, ветки ошибок, 401/refresh, `FormData`, `blob` и т.п.) — **обновить или добавить behavior‑тесты** рядом с модулем клиента в `lib/clients/**` (предпочтительно `*.spec.ts`; легаси `*.test.ts` — не трогать без задачи).
-- Проверять смысловые ветки: успешный JSON, HTTP‑ошибка, сеть, релевантные для проекта сценарии авторизации.
+# HTTP client
 
-# Мапперы и преобразование данных
+- When changing the **shared HTTP client implementation** (body parsing, headers, error branches, 401/refresh, `FormData`, `blob`, etc.) — **update or add behavior tests** next to the client module in `lib/clients/**` (prefer `*.spec.ts`; legacy `*.test.ts` — do not touch without a task).
+- Cover meaningful branches: successful JSON, HTTP error, network, auth scenarios relevant to the project.
 
-- Функции маппинга данных (DTO -> доменная модель и обратно), особенно содержащие вычисляемые поля и ветвления, должны быть покрыты unit‑тестами.
-- В тестах мапперов особое внимание уделять edge‑кейсам и регрессии бизнес‑правил (например, граничные значения, отсутствие полей, неожиданные комбинации значений).
+# Mappers and data transformation
 
-# Требование к агенту
+- Data mapping functions (DTO → domain model and back), especially with computed fields and branches, must have unit tests.
+- In mapper tests, pay special attention to edge cases and business-rule regression (for example, boundary values, missing fields, unexpected value combinations).
 
-При добавлении тестов:
-- Следовать существующей структуре и паттернам тестов в репозитории: файл `*.spec.ts(x)` рядом с модулем или в общем каталоге тестов — как в соседних фичах.
-- Добавлять тесты для критичных веток логики и edge‑кейсов.
- - При работе с данными:
-   - использовать **типы респонса** из API (DTO‑типы), а также **целевые доменные типы** из `@/types`, не дублировать интерфейсы в тестах;
-   - по возможности опираться на данные и обработчики из `mocks/**` (или аналог в репо), а не плодить случайные тестовые данные "с нуля".
- - Размещение:
-   - для **компонентов UI** — **не создавать** поддиректорию `__tests__` внутри папки компонента; тест — соседний `*.spec.ts`.
-   - в **других модулях** (например `api/services`) допустима уже существующая схема с `__tests__` — не ломать ради единообразия с UI.
-   - **новые** файлы — `*.spec.ts` / `*.spec.ts` (см. блок «Имена файлов» выше).
+# Agent requirement
+
+When adding tests:
+- Follow existing test structure and patterns in the repository: `*.spec.ts(x)` next to the module or in a shared test directory — as in neighboring features.
+- Add tests for critical logic branches and edge cases.
+ - When working with data:
+   - use **response types** from the API (DTO types) and **target domain types** from `@/types`; do not duplicate interfaces in tests;
+   - when possible, rely on data and handlers from `mocks/**` (or repo equivalent), not ad-hoc random test data.
+ - Placement:
+   - for **UI components** — **do not create** a `__tests__` subdirectory inside the component folder; the test is a sibling `*.spec.ts`.
+   - in **other modules** (for example `api/services`) an existing `__tests__` layout is acceptable — do not break it for UI uniformity.
+   - **new** files — `*.spec.ts` / `*.spec.ts` (see "File names" above).
 ## Incorrect
 
 ```ts
 it('returns empty list when guest', () => {})
-it('Возвращает пустой список. пользователь не авторизован', () => {})
 ```
 
+- `it('Возвращает пустой список. пользователь не авторизован', () => {})` <!-- i18n-keep: E5 -->
+
 ## Correct
 
-```ts
-it('Возвращает пустой список. Пользователь не авторизован', () => {})
-```
+- `it('Возвращает пустой список. Пользователь не авторизован', () => {})` <!-- i18n-keep: E5 -->

package/presets/cursor/nuxt/rules/types-jsdoc.mdc

@@ -1,42 +1,42 @@
 ---
-description: Стиль JSDoc для доменных и транспортных типов в types
+description: JSDoc style for domain and transport types under types
 globs: types/**/*.ts
 alwaysApply: false
 ---
 
-# Документация типов в `types`
+# Type documentation in `types`
 
-При добавлении или существенном изменении типов в этом слое **следовать уже принятому в репозитории стилю JSDoc** (см. примеры: `User.types.ts`, `Common.types.ts`, `ServerValidation.types.ts`, `TreatmentPlan/*.types.ts`).
+When adding or substantially changing types in this layer **follow the JSDoc style already used in the repository** (see examples: `User.types.ts`, `Common.types.ts`, `ServerValidation.types.ts`, `TreatmentPlan/*.types.ts`).
 
-## Язык и форма
+## Language and form
 
-- Текст комментариев — **на русском**, кратко и по делу: что означает тип или поле в предметной области или в контракте с API.
-- **Не опираться** на теги в духе `@param`, `@returns`, `@see`, `@deprecated` для описания типов — в этом слое они **не используются**; достаточно обычного текста в `/** … */`.
+- Comment text — **in Russian**, short and to the point: what the type or field means in the domain or API contract.
+- **Do not rely** on tags like `@param`, `@returns`, `@see`, `@deprecated` for type descriptions — they are **not used** in this layer; plain `/** … */` text is enough.
 
-## Экспортируемый `type` / `interface`
+## Exported `type` / `interface`
 
-- Сразу **перед объявлением** — блок `/** … */`.
-- Если нужно пояснить источник данных, ограничения или неочевидности — **второй абзац** в том же блоке (в JSDoc для абзаца — пустая строка между строками текста).
-- Для **вложенных** объектов в том же файле каждый такой тип документируется отдельным блоком над своим объявлением.
+- Immediately **before the declaration** — a `/** … */` block.
+- If you need to explain data source, constraints, or non-obvious bits — a **second paragraph** in the same block (blank line between paragraphs in JSDoc).
+- For **nested** objects in the same file, each such type gets its own block above its declaration.
 
-## Поля
+## Fields
 
-- У **каждого** публичного свойства — **однострочный** `/** … */` на строке непосредственно **над** полем.
-- Если поле **не приходит с бэкенда «как есть»**, а вычисляется или дополняется на фронте (маппер, селектор, UI) — начать описание с префикса **`[computed]`** (как в `TUserProfile`, типах плана лечения).
-- Для форматов данных указывать это **в тексте**: например дата `YYYY-MM-DD`, пример отображаемой строки в кавычках.
+- Every **public** property — a **one-line** `/** … */` on the line immediately **above** the field.
+- If a field **does not come from the backend “as is”** but is computed or enriched on the frontend (mapper, selector, UI) — start the description with the **`[computed]`** prefix (as in `TUserProfile`, treatment-plan types).
+- For data formats, state that **in the text**: e.g. date `YYYY-MM-DD`, example display string in quotes.
 
-## Классы и прочие объявления
+## Classes and other declarations
 
-- Для **классов** (например ошибки транспорта) при изменении публичного API — краткий блок над классом и **комментарии к публичным полям** по тем же правилам, что у свойств интерфейса.
+- For **classes** (e.g. transport errors), when changing the public API — a short block above the class and **comments on public fields** by the same rules as interface properties.
 
 ## `enum`
 
-- В `enums.ts` исторически часто **без JSDoc** на каждом члене; для новых enum допустимо короткое описание **над самим enum**, если назначение неочевидно из имени. Подписи для UI — как принято, через объекты `*Names` рядом с enum.
+- In `enums.ts` historically often **without JSDoc** on each member; for new enums a short description **above the enum itself** is OK if purpose is not obvious from the name. UI labels — as usual, via `*Names` objects next to the enum.
 
-## Практика для агента
+## Agent practice
 
-- Добавляя новый тип или поле, **не оставлять** новые публичные поля без пояснения, если смысл не равен имени на 100%.
-- Правя файл, где уже есть такие комментарии, **поддерживать тот же стиль**, а не смешивать с англоязычными или «теговыми» блоками.
-- Не раздувать комментарии: одна-две фразы на тип, одна строка на поле — норма; исключение — действительно сложная доменная оговорка.
+- When adding a new type or field, **do not leave** new public fields unexplained if the meaning is not 100% equal to the name.
+- When editing a file that already has such comments, **keep the same style**, do not mix with English or “tag-style” blocks.
+- Do not inflate comments: one–two phrases per type, one line per field — normal; exception — a truly complex domain caveat.
 
-См. также импорты и barrel: `public-imports.mdc`.
+See also imports and barrel: `public-imports.mdc`.

package/presets/cursor/nuxt/rules/vue-ui.mdc

@@ -6,13 +6,13 @@ alwaysApply: false
 
 # Vue UI (Nuxt)
 
-- Предпочитать **SFC** с `<script setup lang="ts">` (`script-setup-conventions`).
-- Явные `defineProps` / `defineEmits` (typed); без массового `v-bind="object"` (`no-v-bind-spread`).
-- Стили: scoped / CSS modules / design tokens — как у соседей; порядок свойств — `css-property-order-stylelint`.
-- Данные: читать Pinia / composables; **не** вызывать HTTP из SFC — только через `~/api` / store actions.
-- Навигация: `<NuxtLink>`, `navigateTo`, `useRouter` / `useRoute` — не `next/link` / `next/navigation`.
+- Prefer **SFC** with `<script setup lang="ts">` (`script-setup-conventions`).
+- Explicit `defineProps` / `defineEmits` (typed); no bulk `v-bind="object"` (`no-v-bind-spread`).
+- Styles: scoped / CSS modules / design tokens — as neighbors; property order — `css-property-order-stylelint`.
+- Data: read Pinia / composables; **do not** call HTTP from SFC — only via `~/api` / store actions.
+- Navigation: `<NuxtLink>`, `navigateTo`, `useRouter` / `useRoute` — not `next/link` / `next/navigation`.
 - A11y: `vue-a11y-coding`.
-- Границы UI: `architecture-boundaries-ui` — no DTO in templates; map in `api/**`.
+- UI boundaries: `architecture-boundaries-ui` — no DTO in templates; map in `api/**`.
 
 ## Incorrect
 

package/presets/cursor/nuxt/skills/feature-delivery/SKILL.md

@@ -8,7 +8,7 @@ description: Delivers Nuxt 3 frontend features end-to-end across domain types, A
 1. Read task brief, acceptance criteria, and decomposition if present.
 2. Read **`feature-delivery-workflow.mdc`** and **`reference-features.mdc`** — follow layer order and mirror closest reference feature.
 3. Add or update focused tests for changed behavior.
-4. Validation from repository root: **invoke** **`post-change-lint.mdc`** after code edits (requestable, not always-on — but mandatory when code changed). Pipeline: scoped lint OK if next step is `build-verifier`.
+4. Validation from repository root: **invoke** **`post-change-lint.mdc`** after code edits (requestable, not always-on — but **must** when code changed). Pipeline: scoped lint OK if next step is `build-verifier`.
 
 ## Scope discipline
 

package/presets/cursor/nuxt/team/README.md

@@ -1,6 +1,6 @@
 # Agent team artifacts
 
-Каталог артефактов пайплайна «команда агентов» Cursor.
+Artifact directory for the Cursor “agent team” pipeline.
 
 ## Layout
 
@@ -97,7 +97,7 @@ Prefer **`executing`** for pipeline mode. Legacy: `analysis`, `development`, `re
 ## Workflow entry
 
 ```bash
-/task <описание задачи>
+/task <task description>
 /task-continue <slug>
 /technical-retro <slug>
 ```

package/presets/cursor/php-hexagonal/AGENTS.md

@@ -2,17 +2,17 @@
 
 **Repo-root agents:** see [`AGENTS.md`](../../AGENTS.md) at the project root (cross-tool setup, commands, security, living conventions pointers).
 
-| Задача | Куда смотреть |
-|--------|----------------|
-| Новая work-задача | `/task` → `commands/task.md` + `agent-team-orchestrator.mdc` |
-| Фича end-to-end | skill `feature-delivery` + `feature-delivery-workflow.mdc` |
-| Стек и слои | `php-app-core.mdc`, `architecture-boundaries.mdc` |
-| После правок PHP | `post-change-test.mdc` (+ `php-tooling.mdc`) |
+| Task | Where to look |
+|------|----------------|
+| New work request | `/task` → `commands/task.md` + `agent-team-orchestrator.mdc` |
+| End-to-end feature | skill `feature-delivery` + `feature-delivery-workflow.mdc` |
+| Stack and layers | `php-app-core.mdc`, `architecture-boundaries.mdc` |
+| After PHP edits | `post-change-test.mdc` (+ `php-tooling.mdc`) |
 | Integration tests | `integration-test-*` + skill `integration-testing` |
 | Unit tests | `unit-test-*` + skill `unit-testing` |
 | Code review | skill `code-review` + `code-review-mr.mdc` |
 | ADR | skill `write-adr` (on-demand) |
-| Как работает X | agent `codebase-analyzer` (explain-as-is; без `/task`) |
+| How does X work | agent `codebase-analyzer` (explain-as-is; without `/task`) |
 
 ## Install
 
@@ -20,7 +20,7 @@
 npx @bonesofspring/ai-rules init cursor --preset php-hexagonal
 ```
 
-Копирует rules/agents/hooks/skills/commands/team + `REPO_AGENTS.md` → корневой `AGENTS.md`.
+Copies rules/agents/hooks/skills/commands/team + `REPO_AGENTS.md` → root `AGENTS.md`.
 
 ## Inventory
 
@@ -28,12 +28,12 @@ npx @bonesofspring/ai-rules init cursor --preset php-hexagonal
 - **8 skills** — `feature-delivery`, `unit-testing`, `integration-testing`, `ci-investigation`, `debug-investigation`, `code-review`, `technical-retro`, `write-adr`
 - **5 commands** — `/task`, `/task-continue`, `/feature-start`, `/feature-continue`, `/technical-retro`
 
-## Dogfood (5 сценариев)
+## Dogfood (5 scenarios)
 
 Host: `dogfood/php-hexagonal`.
 
-1. `/task` — новый use case (domain → ports → adapters → wire) на sample.
-2. Баг маппинга HTTP — debugger + `TodoController` unit.
+1. `/task` — new use case (domain → ports → adapters → wire) on the sample.
+2. HTTP mapping bug — debugger + `TodoController` unit.
 3. Repository contract — integration-test trio (sample: in-memory persistence).
 4. Unit use case — unit-test planner/generator (PHPUnit + port fake/mock).
 5. Secrets in logs — security-reviewer + `security-php`.

package/presets/cursor/php-hexagonal/MCP.md

@@ -1,15 +1,15 @@
 # MCP (preset `php-hexagonal`, Cursor)
 
-Копируется в `.cursor/mcp.json` при `ai-rules init cursor --preset php-hexagonal`.
+Copied to `.cursor/mcp.json` on `ai-rules init cursor --preset php-hexagonal`.
 
 ## Servers
 
-| Name | Package | Зачем |
-|------|---------|--------|
-| `context7` | `@upstash/context7-mcp` | Актуальная документация PHP / Composer / популярных библиотек |
+| Name | Package | Purpose |
+|------|---------|---------|
+| `context7` | `@upstash/context7-mcp` | Up-to-date PHP / Composer / popular library docs |
 
-Figma и browser e2e MCP (Playwright / Chrome DevTools) **не** входят в php-hexagonal-пресет (backend-only).
+Figma and browser e2e MCP (Playwright / Chrome DevTools) are **not** part of the php-hexagonal preset (backend-only).
 
-Секреты в файл не кладём. Опционально: `CONTEXT7_API_KEY` в окружении.
+Do not put secrets in the file. Optional: `CONTEXT7_API_KEY` in the environment.
 
-После init: Settings → MCP → включить серверы. `init` перезаписывает одноимённый `mcp.json`.
+After init: Settings → MCP → enable servers. `init` overwrites the same-named `mcp.json`.

package/presets/cursor/php-hexagonal/agents/README.md

@@ -1,11 +1,11 @@
 # `.cursor/agents` (preset php-hexagonal)
 
-Ролевые subagents для командного пайплайна Cursor (PHP hexagonal).
+Role subagents for the Cursor agent-team pipeline (PHP hexagonal).
 
 ## Analysis (on-demand)
 
-| Agent | Файл | Production-код |
-|-------|------|----------------|
+| Agent | File | Production code |
+|-------|------|-----------------|
 | Codebase analyzer | `codebase-analyzer.md` | no (explain-as-is only) |
 
 ## Roster (21)
@@ -25,7 +25,7 @@
 
 ## Frontmatter `readonly`
 
-Все agents — **`readonly: false`** (нужна запись в `.cursor/team/**`). Ограничения production — в теле промпта.
+All agents use **`readonly: false`** (need writes under `.cursor/team/**`). Production restrictions live in the prompt body.
 
 ## Model matrix (frontmatter `model`)
 

package/presets/cursor/php-hexagonal/agents/task-router.md

@@ -17,19 +17,19 @@ You are a task router for a **PHP hexagonal backend** agent team. You **do not**
 
 | intent | Signals | Default steps |
 |--------|---------|---------------|
-| `feature` | «добавь», «новая», «реализуй», use case/API/adapter | task-analyst → feature-developer → build-verifier → code-reviewer → qa-tester or **integration-test** trio when adapter AC |
-| `bugfix` | «баг», «fix», «не работает», «падает» | debugger → feature-developer (skipIf debugger.fixed) → build-verifier → code-reviewer |
-| `ci-fix` | «CI», «красный PR», «failing check» | ci-investigator → feature-developer (skipIf resolved) → build-verifier → code-reviewer |
-| `migration` | «миграция», «upgrade», «обнови PHP/Composer-Composer» | task-analyst → migration-specialist → feature-developer → build-verifier → code-reviewer |
-| `perf-audit` | «производительность», «JFR/async-profiler», «медленно» | performance-auditor |
-| `review-only` | «ревью», «review MR», «проверь diff» | code-reviewer |
-| `test-only` | «покрой тестами» (unit+integration, no impl) | task-analyst → qa-tester |
-| `unit-only` | «unit», «юнит», «покрой use case» | unit-test-planner → unit-test-generator, or unit-test-healer |
+| `feature` | «добавь» (add), «новая» (new), «реализуй» (implement), use case/API/adapter | task-analyst → feature-developer → build-verifier → code-reviewer → qa-tester or **integration-test** trio when adapter AC | <!-- i18n-keep: E4 -->
+| `bugfix` | «баг» (bug), «fix», «не работает» (doesn't work), «падает» (crashes) | debugger → feature-developer (skipIf debugger.fixed) → build-verifier → code-reviewer | <!-- i18n-keep: E4 -->
+| `ci-fix` | «CI», «красный PR» (red PR), «failing check» | ci-investigator → feature-developer (skipIf resolved) → build-verifier → code-reviewer | <!-- i18n-keep: E4 -->
+| `migration` | «миграция» (migration), «upgrade», «обнови PHP/Composer» (upgrade PHP/Composer) | task-analyst → migration-specialist → feature-developer → build-verifier → code-reviewer | <!-- i18n-keep: E4 -->
+| `perf-audit` | «производительность» (performance), «JFR/async-profiler», «медленно» (slow) | performance-auditor | <!-- i18n-keep: E4 -->
+| `review-only` | «ревью» (review), «review MR», «проверь diff» (check diff) | code-reviewer | <!-- i18n-keep: E4 -->
+| `test-only` | «покрой тестами» (cover with tests) (unit+integration, no impl) | task-analyst → qa-tester | <!-- i18n-keep: E4 -->
+| `unit-only` | «unit», «юнит» (unit), «покрой use case» (cover use case) | unit-test-planner → unit-test-generator, or unit-test-healer | <!-- i18n-keep: E4 -->
 | `e2e-only` / integration | «integration», «e2e», «HTTP controller tests», «integration DB fixtures» | **integration-test-planner** → **integration-test-generator**, or **integration-test-healer** |
-| `docs-only` | «документация», «README», «changelog» | task-analyst → tech-writer |
-| `refactor` | «рефакторинг», «без изменения поведения» | task-analyst → feature-developer → build-verifier → code-reviewer |
-| `spike` | «исследуй», «spike», proof of concept | task-analyst → solution-architect |
-| `retro` | «ретро», «postmortem» | (orchestrator → `/technical-retro`) |
+| `docs-only` | «документация» (documentation), «README», «changelog» | task-analyst → tech-writer | <!-- i18n-keep: E4 -->
+| `refactor` | «рефакторинг» (refactoring), «без изменения поведения» (no behavior change) | task-analyst → feature-developer → build-verifier → code-reviewer | <!-- i18n-keep: E4 -->
+| `spike` | «исследуй» (investigate), «spike», proof of concept | task-analyst → solution-architect | <!-- i18n-keep: E4 -->
+| `retro` | «ретро» (retro), «postmortem» | (orchestrator → `/technical-retro`) | <!-- i18n-keep: E4 -->
 
 **Never schedule** Playwright (`playwright-test-*`), XCUITest (`xcuitest-test-*`), or `accessibility-reviewer`. Put them in `skipped` with reason «PHP backend uses integration-test trio».