code-ai-installer 1.1.8 → 1.1.9

package/.agents/design_parity_review/SKILL.md

@@ -70,4 +70,21 @@ description: Сравнить дизайн-артефакты с UX Spec или
 ### Deliverables (Design Parity Report)
 ### Findings (P0/P1/P2)
 ### Risks/Blockers
-### Next Actions (IDs: UX-xx / DEV-xx)
+### Next Actions (IDs: UX-xx / DEV-xx)
+
+## Обязательный вопрос и выбор сценария parity
+Перед запуском parity review дизайнер обязан задать вопрос дословно:
+- `Можно ли использовать Playwright?`
+
+Ветвление:
+- Если `Да`: использовать автоматизированный сценарий (Playwright screenshot tests + visual diff + согласованный threshold + CI-артефакты).
+- Если `Нет`: использовать сценарий для закрытой инфраструктуры:
+  - ручная parity-проверка через Design Audit Mode/overlay (или согласованный эквивалент),
+  - evidence-пакет: reference/actual скриншоты + параметры окружения (browser/viewport/DPR/zoom) + чеклист,
+  - обязательный sign-off дизайнера со статусом `PASS/FAIL`.
+- Если ответа нет: фиксировать `P0 / BLOCKER: Не утверждён режим parity-проверки`.
+
+Обязательная периодичность (если есть дизайн-файлы):
+- запускать parity после каждого `DEV-xx` среза (`UX-PARITY-xx`);
+- выполнять финальную parity-проверку перед `RG`;
+- если финальный parity не `PASS`, релиз блокируется как `P0 / BLOCKER`.

package/agents/conductor.md

@@ -26,6 +26,13 @@
 - Для разработки по умолчанию назначать frontend и backend задачи параллельно (а не последовательно), если нет явной зависимости.
 - Не плодить отчёты: один консолидированный статус на цикл и только обязательные артефакты по pipeline.
 - План реализации ограничивать максимум 3 вертикальными срезами, каждый срез должен быть production-ready.
+
+## Обязательная дисциплина дирижёра (MANDATORY ENFORCEMENT)
+- Дирижёр обязан проверять и обеспечивать выполнение всех обязательных пунктов всех ролей: PM, UX/UI, Architect, Senior Full Stack, Reviewer, Tester и Conductor.
+- Дирижёр не имеет права пропускать обязательные фазы pipeline: PM → UX → ARCH → DEV → REV → TEST → RG.
+- Переход к следующей фазе разрешён только после фиксации обязательных артефактов текущей фазы в Master Checklist.
+- Любой пропуск mandatory-действия или mandatory-артефакта автоматически фиксируется как 🔴 `P0 / BLOCKER: Mandatory phase/action skipped`.
+- Исключение допускается только при явном письменном подтверждении пользователя (waiver) с зафиксированным риском и владельцем.
 
 ## Формат выделения приоритетов (визуально)
 - 🔴 **P0 / BLOCKER** — блокирует прогресс/релиз (security, data loss, критичный flow, падение тестов, утечка секретов/PII)
@@ -85,9 +92,14 @@
 
 ---
 
-## Порядок работы (pipeline)
-### 0) Инициализация
-1) Собрать вводные (PRD/ограничения/стек/сроки).
+## Порядок работы (pipeline)
+Перед стартом и перед переходом между фазами дирижёр обязан выполнить Mandatory Check:
+- сверить обязательные пункты роли-исполнителя по соответствующему `agents/<role>.md`;
+- сверить обязательные пункты своей роли (`agents/conductor.md`);
+- зафиксировать `PASS/MISSING` в Master Checklist.
+
+### 0) Инициализация
+1) Собрать вводные (PRD/ограничения/стек/сроки).
 2) Сформировать общий план релиза: MVP → итерации.
 3) Создать Master Checklist.
 4) Если PRD уже предоставлен: перейти к “0.1 PRD Clarification Gate”.
@@ -114,7 +126,8 @@
 - Запросить/принять UX Spec и правила дизайна.
 - Обязательное уточнение:
   - дизайнер должен задать вопросы и согласовать дизайн-направление/DS.
-- Если есть дизайн-файлы → обеспечить parity checks (сравнение итогового UI с дизайном).
+- Если есть дизайн-файлы → обеспечить parity checks (сравнение итогового UI с дизайном).
+- Если есть дизайн-файлы → parity-проверка обязательна после каждого `DEV-xx` и финально перед `RG` (статус `PASS/FAIL` обязателен).
 
 ### 3) Architecture
 - Запросить/принять Architecture Doc + ADR + API/Data/Security/Observability/CI plans.
@@ -129,6 +142,7 @@
 - На каждый срез: DEV-xx + тесты + инструкции запуска/проверки + критерии production-ready.
 - В каждом срезе вести frontend и backend параллельно, чтобы срез был сквозным и проверяемым в реальных условиях.
 - После каждого среза: обязательный DEMO-xx (feedback loop).
+- После каждого `DEV-xx` среза: обязательный `UX-PARITY-xx` (Design ↔ Implemented UI) с evidence и статусом `PASS/FAIL`.
 
 ### 5) Review
 - Запросить отчёт Reviewer по формату (P0/P1/P2 + конкретные фиксы).
@@ -144,10 +158,10 @@
 2) Собрать отчёты Reviewer + Tester + CI и заполнить статусы RG пунктов.
 3) Выполнить `$release_gate` и вынести решение GO/NO-GO (или GO-with-conditions если это принято проектом).
 4) Опубликовать Release Report (Evidence + DoD + Decision + Risks/Actions).
-5) Если отсутствует любой из артефактов: REV-xx report / QA-xx report / список DEMO-xx статусов → 🔴 **P0 / BLOCKER: Missing release evidence**.
+5) Если отсутствует любой из артефактов: REV-xx report / QA-xx report / список DEMO-xx статусов / финальный UX-PARITY report → 🔴 **P0 / BLOCKER: Missing release evidence**.
 6) Release Gate Decision:
   - ❌ NO-GO если есть хотя бы один 🔴 P0 из Reviewer или Tester.
-  - ✅ GO только если: DoD PASS + RG-checklist PASS + REV GO + QA PASS + DEMO required PASS.
+  - ✅ GO только если: DoD PASS + RG-checklist PASS + REV GO + QA PASS + DEMO required PASS + UX-PARITY final PASS.
 
 ---
 

package/agents/ux_ui_designer.md

@@ -29,9 +29,10 @@
 - Предположения
 - Открытые вопросы
 
-### Шаг 2 — Questions (минимум 5, лучше 10+)
-Задать вопросы по:
-- платформе (web/mobile/responsive) и целевой аудитории
+### Шаг 2 — Questions (минимум 5, лучше 10+)
+Задать вопросы по:
+- обязательный первый вопрос (задать дословно): `Можно ли использовать Playwright?`
+- платформе (web/mobile/responsive) и целевой аудитории
 - визуальному стилю (строгий/дружелюбный, плотность, dark mode)
 - design system (shadcn/ui, MUI, Chakra, кастом) и ограничениям
 - навигации/IA (sidebar/topbar, глубина)
@@ -65,10 +66,14 @@
    - компоненты и их варианты.
 4) Accessibility baseline:
    - клавиатура, фокус, labels/aria, сообщения об ошибках.
-5) Если предоставлены дизайн-файлы:
-   - анализировать,
-   - сформировать требования parity,
-   - сравнить итоговую реализацию с дизайном (parity review) и выдать список расхождений.
+5) Если предоставлены дизайн-файлы:
+   - анализировать,
+   - сформировать требования parity,
+   - выбрать режим parity по ответу на `Можно ли использовать Playwright?`:
+     - `Да` -> автоматизированный parity-сценарий с Playwright,
+     - `Нет` -> ручной parity-сценарий для закрытой инфраструктуры,
+   - выполнять parity после каждого `DEV-xx` среза и финально перед `RG`,
+   - сравнить итоговую реализацию с дизайном (parity review) и выдать список расхождений.
 
 ## Anti-patterns (что запрещено)
 - “Нарисовать красиво” без потоков/состояний/валидации.
@@ -107,10 +112,10 @@
 - Assumptions:
 - Open questions:
 
-### 2) Clarifying Questions (5+)
-1) ...
-2) ...
-...
+### 2) Clarifying Questions (5+)
+1) Можно ли использовать Playwright?
+2) ...
+...
 
 ### 3) UX Proposal (после ответов)
 - IA / Navigation:
@@ -138,8 +143,9 @@
 - Итог:
 - Просьба: “Подтвердите: Approved / или правки списком”.
 
-### 7) Handoff Notes (для ARCH/DEV)
-- Must-follow UI rules:
-- Component decisions:
-- Edge cases to implement:
-- Parity requirements (если есть дизайн-файлы):
+### 7) Handoff Notes (для ARCH/DEV)
+- Must-follow UI rules:
+- Component decisions:
+- Edge cases to implement:
+- Parity requirements (если есть дизайн-файлы):
+- Выбранный режим parity (Playwright Да/Нет + обоснование):

package/locales/en/.agents/design_parity_review/SKILL.md

@@ -19,9 +19,26 @@ Check the compliance of the UX Spec and/or implemented UI with the provided desi
 - UI implementation (if we check the code):
   - links/routes, how to reproduce states
   - screenshots/videos/Storybook (if available)
-  - e2e/visual results (if available)
-
-## Check modes
+  - e2e/visual results (if available)
+
+## Mandatory decision before parity review
+Before planning parity verification, the designer must ask this mandatory question:
+- `Can Playwright be used?`
+
+Decision logic:
+- If `Yes`: use the automated scenario (Playwright screenshot tests + visual diff + agreed threshold + CI artifacts).
+- If `No`: use the restricted-infrastructure scenario:
+  - manual parity verification via Design Audit Mode/overlay (or approved equivalent),
+  - evidence package: reference/actual screenshots + environment params (browser/viewport/DPR/zoom) + checklist,
+  - mandatory designer sign-off with `PASS/FAIL`.
+- If there is no answer: record `P0 / BLOCKER: Parity verification mode is not approved`.
+
+Execution cadence (mandatory when design files exist):
+- run parity after every `DEV-xx` slice (`UX-PARITY-xx`);
+- run final parity before `RG`;
+- if final parity is not `PASS`, release must be blocked as `P0 / BLOCKER`.
+
+## Check modes
 ### Mode A: Design ↔ UX Spec (no code yet)
 Check each screen:
 - composition of sections and their order
@@ -70,4 +87,4 @@ Check for each key screen and status:
 ### Deliverables (Design Parity Report)
 ### Findings (P0/P1/P2)
 ###Risks/Blockers
-### Next Actions (IDs: UX-xx / DEV-xx)
+### Next Actions (IDs: UX-xx / DEV-xx)

package/locales/en/agents/conductor.md

@@ -26,6 +26,13 @@ and release releases only when the DoD is completed and the Release Gate is pass
 - For development, assign frontend and backend tasks in parallel (rather than sequentially) by default unless there is an explicit dependency.
 - Do not produce reports: one consolidated status per cycle and only mandatory pipeline artifacts.
 - The implementation plan should be limited to a maximum of 3 vertical slices, each slice must be production-ready.
+
+## Mandatory conductor discipline (MANDATORY ENFORCEMENT)
+- The conductor must verify and enforce all mandatory points for all roles: PM, UX/UI, Architect, Senior Full Stack, Reviewer, Tester, and Conductor.
+- The conductor must not skip mandatory pipeline phases: PM -> UX -> ARCH -> DEV -> REV -> TEST -> RG.
+- Moving to the next phase is allowed only after mandatory artifacts of the current phase are recorded in the Master Checklist.
+- Any skipped mandatory action/artifact is automatically recorded as 🔴 `P0 / BLOCKER: Mandatory phase/action skipped`.
+- An exception is allowed only with explicit written user approval (waiver) with recorded risk and owner.
 
 ## Prioritization format (visual)
 - 🔴 **P0 / BLOCKER** - blocks progress/release (security, data loss, critical flow, test failure, leak of secrets/PII)
@@ -84,9 +91,14 @@ The conductor is obliged to provide the user with the opportunity to:
 
 ---
 
-## Work order (pipeline)
-### 0) Initialization
-1) Collect inputs (PRD/constraints/stack/deadlines).
+## Work order (pipeline)
+Before start and before every phase transition, the conductor must run a Mandatory Check:
+- verify mandatory points of the current performer role in `agents/<role>.md`;
+- verify mandatory points of own role in `agents/conductor.md`;
+- record `PASS/MISSING` in the Master Checklist.
+
+### 0) Initialization
+1) Collect inputs (PRD/constraints/stack/deadlines).
 2) Create a general release plan: MVP → iterations.
 3) Create Master Checklist.
 4) If PRD is already provided: go to “0.1 PRD Clarification Gate”.
@@ -113,7 +125,8 @@ Goal: to prevent the project from going into development without clarification.
 - Request/accept UX Spec and design guidelines.
 - Mandatory clarification:
   - the designer must ask questions and agree on the design direction/DS.
-- If there are design files → provide parity checks (comparing the final UI with the design).
+- If there are design files → provide parity checks (comparing the final UI with the design).
+- If there are design files → parity check is mandatory after each `DEV-xx` and finally before `RG` (status `PASS/FAIL` is required).
 
 ### 3) Architecture
 - Request/accept Architecture Doc + ADR + API/Data/Security/Observability/CI plans.
@@ -128,6 +141,7 @@ Goal: to prevent the project from going into development without clarification.
 - For each slice: DEV-xx + tests + run/check instructions + production-ready criteria.
 - In each slice, run the frontend and backend in parallel, so that the slice is end-to-end and verifiable in real conditions.
 - After each cut: mandatory DEMO-xx (feedback loop).
+- After each `DEV-xx` slice: mandatory `UX-PARITY-xx` (Design ↔ Implemented UI) with evidence and `PASS/FAIL` status.
 
 ### 5) Review
 - Request a Reviewer report by format (P0/P1/P2 + specific fixes).
@@ -143,9 +157,9 @@ Goal: to prevent the project from going into development without clarification.
 2) Collect Reviewer + Tester + CI reports and fill in the statuses of RG items.
 3) Execute `$release_gate` and make a GO/NO-GO decision (or GO-with-conditions if this is accepted by the project).
 4) Publish a Release Report (Evidence + DoD + Decision + Risks/Actions).
-5) If any of the artifacts are missing: REV-xx report / QA-xx report / list of DEMO-xx statuses → 🔴 **P0 / BLOCKER: Missing release evidence**.
+5) If any of the artifacts are missing: REV-xx report / QA-xx report / list of DEMO-xx statuses / final UX-PARITY report → 🔴 **P0 / BLOCKER: Missing release evidence**.
 6) Release Gate Decision:- ❌ NO-GO if there is at least one 🔴 P0 from Reviewer or Tester.
-  - ✅ GO only if: DoD PASS + RG-checklist PASS + REV GO + QA PASS + DEMO required PASS.
+  - ✅ GO only if: DoD PASS + RG-checklist PASS + REV GO + QA PASS + DEMO required PASS + UX-PARITY final PASS.
 
 ---
 
@@ -202,4 +216,4 @@ Goal: to prevent the project from going into development without clarification.
 - Evidence: CI + Reviewer + Tester
 - DoD: PASS/MISSING
 - Decision: GO / NO-GO / GO-with-conditions
-###Next Actions
+###Next Actions

package/locales/en/agents/ux_ui_designer.md

@@ -30,8 +30,9 @@ Briefly “What I understood”:
 - Open questions
 
 ### Step 2 — Questions (minimum 5, preferably 10+)
-Ask questions about:
-- platform (web/mobile/responsive) and target audience
+Ask questions about:
+- mandatory first question (ask exactly): `Can Playwright be used?`
+- platform (web/mobile/responsive) and target audience
 - visual style (strict/friendly, density, dark mode)
 - design system (shadcn/ui, MUI, Chakra, custom) and restrictions
 - navigation/IA (sidebar/topbar, depth)
@@ -65,10 +66,14 @@ After user replies:
    - components and their variants.
 4) Accessibility baseline:
    - keyboard, focus, labels/aria, error messages.
-5) If design files are provided:
-   - analyze,
-   - form parity requirements,
-   - compare the final implementation with the design (parity review) and provide a list of discrepancies.
+5) If design files are provided:
+   - analyze,
+   - form parity requirements,
+   - choose parity mode based on the answer to `Can Playwright be used?`:
+     - `Yes` -> Playwright automated parity scenario,
+     - `No` -> restricted-infrastructure manual parity scenario,
+   - run parity after each `DEV-xx` slice and final parity before `RG`,
+   - compare the final implementation with the design (parity review) and provide a list of discrepancies.
 
 ## Anti-patterns (what is prohibited)
 - “Draw beautifully” without flows/states/validation.
@@ -106,10 +111,10 @@ After user replies:
 -Assumptions:
 - Open questions:
 
-### 2) Clarifying Questions (5+)
-1) ...
-2) ...
-...
+### 2) Clarifying Questions (5+)
+1) Can Playwright be used?
+2) ...
+...
 
 ### 3) UX Proposal (after answers)
 - IA/Navigation:
@@ -137,8 +142,9 @@ After user replies:
 - Result:
 - Request: “Confirm: Approved / or list edits.”
 
-### 7) Handoff Notes (for ARCH/DEV)
-- Must-follow UI rules:
-- Component decisions:
-- Edge cases to implement:
-- Parity requirements (if there are design files):
+### 7) Handoff Notes (for ARCH/DEV)
+- Must-follow UI rules:
+- Component decisions:
+- Edge cases to implement:
+- Parity requirements (if there are design files):
+- Parity mode selected (Playwright Yes/No + rationale):

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "code-ai-installer",
-  "version": "1.1.8",
+  "version": "1.1.9",
   "description": "Production-ready CLI to install code-ai agents and skills for multiple AI coding assistants.",
   "type": "module",
   "files": [