@jetrabbits/agentic 0.0.1

package/areas/software/general/workflows/code-review-workflow.md

@@ -0,0 +1,84 @@
+---
+name: code-review-workflow
+type: workflow
+trigger: /code-review-workflow
+description: Conduct a structured, constructive code review of a pull or merge request.
+inputs:
+  - pull_request_or_merge_request
+  - codebase_context
+outputs:
+  - review_comments
+  - approval_or_change_requests
+roles:
+  - team-lead
+  - developer
+  - qa
+execution:
+  initiator: developer
+related-rules:
+  - code-style-guide.md
+  - git-workflow-guide.md
+  - sdlc-methodology-guide.md
+uses-skills:
+  - general-dev-tools
+quality-gates:
+  - CI pipeline passes before manual review begins
+  - all blocking comments resolved before approval
+  - no secrets or credentials in diff
+---
+
+## Steps
+
+### 1. Automated Pre-check — `@developer` (author)
+- **Input:** feature branch with changes
+- **Actions:** confirm CI passes (lint / tests / build); no merge conflicts; branch up to date with target
+- **Output:** CI-green PR
+- **Done when:** automated checks pass — only then request review
+
+### 2. Context Understanding — `@team-lead`
+- **Input:** PR description and linked issue/task
+- **Actions:** read PR description and linked ticket; check scope focus; if diff > 400 lines of logic — request splitting the PR
+- **Output:** decision to proceed or split
+- **Done when:** reviewer understands the intent and scope is acceptable
+
+### 3. Code Review — `@team-lead` + `@qa`
+- **Input:** PR diff + context
+- **Actions — Correctness:**
+  - Does the code do what the ticket describes?
+  - Are edge cases and error paths handled?
+- **Actions — Design & Architecture:**
+  - Does the change follow existing codebase patterns?
+  - No unnecessary complexity or over-engineering?
+  - Abstractions at the right level?
+- **Actions — Code Quality:**
+  - Names are clear and intention-revealing?
+  - No duplicated logic that could be extracted?
+  - No magic numbers or strings?
+- **Actions — Tests:**
+  - New behaviors covered by tests?
+  - Tests assert meaningful behavior, not implementation details?
+  - Edge cases tested?
+- **Actions — Security:**
+  - No secrets or credentials committed
+  - User input validated/sanitized
+  - Permissions and access control respected
+- **Output:** review comments with blocking / non-blocking labels; at least one positive comment
+- **Done when:** all review dimensions checked
+
+### 4. Feedback Resolution — `@developer`
+- **Input:** review comments
+- **Actions:** address all blocking comments; push fixes as new commits (no force-push during review); re-request review
+- **Output:** updated PR
+- **Done when:** no open blocking comments
+
+### 5. Approval & Merge — `@team-lead`
+- **Input:** resolved PR
+- **Actions:** re-check fixes; approve; author squashes or rebases per project convention; merge; delete feature branch
+- **Output:** merged PR; branch deleted
+- **Done when:** change merged and feature branch removed
+
+## Iteration Loop
+If fixes introduce new issues → reviewer re-raises blocking comments; loop repeats until clean.
+
+## Exit
+Approved and merged PR = review complete.

package/areas/software/general/workflows/development-cycle-workflow.md

@@ -0,0 +1,85 @@
+---
+name: development-cycle-workflow
+type: workflow
+trigger: /development-cycle-workflow
+description: Implement any development task from ticket to merged code.
+inputs:
+  - task_or_issue_description
+  - existing_codebase
+outputs:
+  - implemented_changes
+  - passing_tests
+  - merged_pull_request
+roles:
+  - product-owner
+  - pm
+  - team-lead
+  - developer
+  - qa
+execution:
+  initiator: product-owner
+related-rules:
+  - git-workflow-guide.md
+  - sdlc-methodology-guide.md
+  - code-style-guide.md
+  - lint-format-guide.md
+uses-skills:
+  - general-dev-tools
+quality-gates:
+  - acceptance criteria confirmed before implementation starts
+  - all checks pass (lint / test / build)
+  - PR reviewed and approved
+---
+
+## Steps
+
+### 1. Requirements Framing — `@product-owner` + `@pm`
+- **Input:** task or issue description
+- **Actions:** define acceptance criteria; clarify scope and non-goals; if larger than 1 day of work — break into sub-tasks
+- **Output:** confirmed acceptance criteria added to the ticket
+- **Done when:** criteria are testable and agreed upon
+
+### 2. Technical Design — `@team-lead`
+- **Input:** confirmed acceptance criteria
+- **Actions:** identify impacted code areas; flag architectural risks; approve approach or request changes
+- **Output:** brief design note (inline comment or `docs/<task>/notes.md` for significant changes)
+- **Done when:** implementation approach is unambiguous
+
+### 3. Implementation — `@developer`
+- **Input:** confirmed acceptance criteria + design note
+- **Actions:**
+  - pull latest `main`, create branch: `git checkout -b feature/<task-id>-short-desc`
+  - implement in small logical commits; follow code style rules
+  - run `make fmt` after each logical change
+  - do not mix unrelated changes in the same branch
+- **Output:** code changes on feature branch
+- **Done when:** implementation covers all acceptance criteria
+
+### 4. Verification — `@developer` → `@qa`
+- **Input:** code changes on branch
+- **Actions:**
+  - `make test` — all tests pass
+  - `make lint` — zero errors
+  - `make fmt` — no diffs
+  - add or update tests for any new behavior
+  - `@qa` runs exploratory checks against acceptance criteria
+- **Output:** green local checks; test evidence attached to PR
+- **Done when:** no failing checks; acceptance criteria manually verified
+
+### 5. Pull Request — `@developer`
+- **Input:** green checks, test evidence
+- **Actions:** open PR with title `[TASK-ID] Short description`; body includes what changed, why, how to test, screenshots if UI; assign reviewer; CI must pass before review
+- **Output:** open PR with passing CI
+- **Done when:** PR is open and CI is green
+
+### 6. Review & Merge — `@team-lead` (coordinated by `@pm`)
+- **Input:** open PR
+- **Actions:** `@team-lead` reviews code quality, architecture, and tests; `@developer` addresses all blocking comments; squash or rebase per project convention; merge; delete feature branch
+- **Output:** merged PR; feature branch deleted
+- **Done when:** PR is merged and change is verified in staging/preview
+
+## Iteration Loop
+If verification (Step 4) or review (Step 6) reveals gaps → return to Step 3. `@pm` tracks blockers and timeline.
+
+## Exit
+Merged PR + acceptance criteria validated in staging = task complete.

package/areas/software/general/workflows/project-setup-workflow.md

@@ -0,0 +1,94 @@
+---
+name: project-setup-workflow
+type: workflow
+trigger: /project-setup-workflow
+description: Bootstrap a new software project with tooling, CI, and documentation from day one.
+inputs:
+  - project_name
+  - language_or_framework
+  - target_platform
+outputs:
+  - initialized_repository
+  - ci_pipeline_configured
+  - readme_and_docs
+roles:
+  - product-owner
+  - pm
+  - team-lead
+  - developer
+  - qa
+execution:
+  initiator: product-owner
+related-rules:
+  - git-workflow-guide.md
+  - makefile-guide.md
+  - docker-compose-guide.md
+  - lint-format-guide.md
+uses-skills:
+  - general-dev-tools
+quality-gates:
+  - CI pipeline passes on first commit
+  - make install && make dev works on a clean machine
+  - pre-commit hooks installed and passing
+---
+
+## Steps
+
+### 1. Scope & Decisions — `@product-owner` + `@pm`
+- **Input:** project name, purpose, team constraints
+- **Actions:** confirm language/framework/platform; define team conventions (branch model, merge strategy); confirm initial milestone
+- **Output:** brief project charter note (README draft or ADR-0)
+- **Done when:** tech stack and conventions agreed upon
+
+### 2. Repository Setup — `@team-lead` + `@developer`
+- **Input:** project charter note
+- **Actions:**
+  - create repo on GitHub/GitLab with meaningful name and description
+  - set up branch protection on `main` (require CI + review)
+  - add `.gitignore` for the language/framework
+  - add `README.md` with: description, prerequisites, quick start (`make install && make dev`), CI badge
+- **Output:** initialized repository with branch protection
+- **Done when:** repo accessible, branch protection active
+
+### 3. Development Environment — `@developer`
+- **Input:** initialized repository
+- **Actions:**
+  - create `Makefile` with targets: `install`, `dev`, `test`, `lint`, `fmt`, `clean`, `help`
+  - if multi-service: create `docker-compose.yml` with health checks and `.env.example`
+  - configure language toolchain (venv, node_modules, go modules, etc.)
+  - add `.editorconfig` for consistent whitespace
+- **Output:** working local dev environment
+- **Done when:** `make install && make dev` succeeds on a clean machine
+
+### 4. Code Quality Tooling — `@developer`
+- **Input:** working dev environment
+- **Actions:**
+  - add linter config (`.eslintrc`, `pyproject.toml [tool.ruff]`, `.golangci.yml`, etc.)
+  - add formatter config (`prettier`, `black`, etc.)
+  - configure `pre-commit` with at minimum: trailing-whitespace, end-of-file-fixer, check-yaml
+  - run `pre-commit install` and `pre-commit run --all-files` — fix any issues
+- **Output:** linter + formatter + pre-commit hooks configured and passing
+- **Done when:** `make lint` and `make fmt` exit clean on the initial codebase
+
+### 5. CI Pipeline — `@developer` + `@team-lead`
+- **Input:** quality tooling configured
+- **Actions:**
+  - create CI config (`.github/workflows/ci.yml` or `.gitlab-ci.yml`)
+  - pipeline runs: lint → test → build on every PR
+  - set branch protection to require passing CI before merge
+  - add CI status badge to README
+- **Output:** CI pipeline running on the repo
+- **Done when:** CI passes on `main`
+
+### 6. First Commit & Validation — `@developer` + `@qa`
+- **Input:** all tooling configured
+- **Actions:**
+  - `git add -A && git commit -m "chore: initial project setup"`
+  - push and verify CI passes on default branch
+  - `@qa` validates: clean install on a second machine, CI badge green, `make test` passes
+  - create first `CHANGELOG.md` entry: `## [Unreleased]`
+- **Output:** green CI on first commit; validated by QA
+- **Done when:** CI green, QA confirms setup is reproducible
+
+## Exit
+Green CI + QA sign-off = project is ready for first feature development.

package/areas/software/mlops/AGENTS.md

@@ -0,0 +1,57 @@
+# MLOps — guidance index
+
+## What this area covers
+
+Machine learning operations: experiment tracking, model training pipelines, feature engineering, model evaluation, champion/challenger workflows, inference serving, model monitoring, and production safety gates. MLOps treats models as software artifacts with the same reproducibility and observability requirements as any production service.
+
+## Guidance chain
+
+1. Project `.agent/` baseline (`AGENTS.md` + `.agent/*`)
+2. `software/general/rules/*` — always active
+3. `mlops/rules/*` — load all for this spec
+4. `mlops/skills/*/SKILL.md` — load only the skill matching the current task
+5. `mlops/workflows/*` — load the workflow matching the triggered command
+
+## Inherited from general
+
+- SDLC methodology and handoff contracts
+- Git / CI / lint and code style baselines
+
+## MLOps-specific constraints
+
+- Every experiment is reproducible: fixed random seed, pinned dependency versions, logged hyperparameters.
+- No model promotes to production without a documented evaluation report and a champion/challenger comparison.
+- Production models emit prediction latency, throughput, and data drift metrics — no silent inference.
+- Training data containing PII is governed under `data-engineering/rules/pii-handling.md` at all times.
+
+## Spec map
+
+```text
+mlops/
+├── rules/
+│   ├── reproducibility.md      ← seed pinning, dependency locking, artifact versioning
+│   ├── data-integrity.md       ← training data lineage, validation, split discipline
+│   ├── model-governance.md     ← approval gates, versioning, rollback policy
+│   └── production-safety.md    ← shadow mode, canary traffic, kill switch requirements
+├── skills/
+│   ├── experiment-tracking/SKILL.md   ← MLflow, W&B, run comparison, artifact logging
+│   ├── feature-engineering/SKILL.md   ← feature stores, transformation pipelines, leakage prevention
+│   ├── model-evaluation/SKILL.md      ← metric selection, fairness checks, threshold calibration
+│   ├── inference-serving/SKILL.md     ← online/batch serving, latency budgets, model registries
+│   └── model-monitoring/SKILL.md      ← data drift, prediction drift, retraining triggers
+├── workflows/
+│   ├── train-experiment.md        ← /train-experiment
+│   ├── evaluate-model.md          ← /evaluate-model
+│   ├── champion-challenger.md     ← /champion-challenger
+│   ├── deploy-endpoint.md         ← /deploy-endpoint
+│   └── model-incident.md          ← /model-incident
+└── prompts/
+    └── *.md
+```
+
+## Discovery patterns
+
+- `rules/*.md`
+- `skills/*/SKILL.md`
+- `workflows/*.md`
+- `prompts/*.md`

package/areas/software/mlops/PROMPTS.md

@@ -0,0 +1,32 @@
+# PROMPTS: mlops
+
+Use these prompts with `AGENTS.md` from the same directory.
+
+## 1) Initialize agent behavior
+
+```text
+Read `mlops/AGENTS.md` and adopt its rules, skills loading strategy, and workflows as hard constraints.
+List the active rules and the selected workflow before implementation.
+```
+
+## 2) Implement a feature
+
+```text
+Using `mlops/AGENTS.md`, implement: <feature description>.
+Before coding: provide architecture notes, risk list, and test plan.
+After coding: run checks and report exact commands and results.
+```
+
+## 3) Incident / debug mode
+
+```text
+Using `mlops/AGENTS.md`, run incident triage for: <incident summary>.
+Return root cause hypotheses, validation steps, fix plan, and rollback plan.
+```
+
+## 4) Release readiness
+
+```text
+Using `mlops/AGENTS.md`, prepare release checklist for: <release scope>.
+Include quality gates, security gates, performance gates, and deployment validation.
+```

package/areas/software/mlops/prompts/champion-challenger.md

@@ -0,0 +1,87 @@
+---
+workflow: champion-challenger
+---
+
+# Prompt: `/champion-challenger`
+
+Use when: running a controlled champion-vs-challenger model experiment with statistical significance and rollback guardrails.
+
+---
+
+## Example 1 — Credit risk model challenger rollout
+
+**EN:**
+```
+/champion-challenger
+
+Champion model: credit-risk-xgb-v14 (Production in registry)
+Challenger model: credit-risk-xgb-v15 (candidate from MLflow run 5d8a9f2)
+Experiment duration: 14 days or until 2.5M scored applications
+Primary metric: approved-loan default rate after policy thresholding
+Guardrails:
+- online latency p99 < 180ms
+- application scoring error rate < 0.2%
+- fairness disparity by age_group and region <= 0.08
+Traffic split: 50% champion / 50% challenger by hashed applicant_id
+Decision rules:
+- promote only if default rate improves by at least 1.5% relative and p-value < 0.05
+- auto-rollback if latency or fairness guardrail breaches for 30 min
+Output: experiment design, sample-size calculation, daily monitoring plan, and final promotion decision template
+```
+
+**RU:**
+```
+/champion-challenger
+
+Champion model: credit-risk-xgb-v14 (Production в registry)
+Challenger model: credit-risk-xgb-v15 (кандидат из MLflow run 5d8a9f2)
+Длительность эксперимента: 14 дней или до 2.5M скорингованных заявок
+Основная метрика: default rate по одобренным займам после применения policy threshold
+Guardrails:
+- online latency p99 < 180ms
+- error rate скоринга заявок < 0.2%
+- fairness disparity по age_group и region <= 0.08
+Разделение трафика: 50% champion / 50% challenger по hashed applicant_id
+Правила решения:
+- продвигать только если default rate улучшается минимум на 1.5% относительно и p-value < 0.05
+- auto-rollback если latency или fairness guardrail нарушается 30 минут подряд
+Результат: дизайн эксперимента, расчёт sample size, ежедневный план мониторинга и шаблон финального решения о promotion
+```
+
+---
+
+## Example 2 — Search ranking experiment with segment safety
+
+**EN:**
+```
+/champion-challenger
+
+Champion model: search-ranker-bert-v8
+Challenger model: search-ranker-bert-v9-distilled
+Experiment duration: 7 days during normal traffic period (exclude Black Friday campaign week)
+Primary metric: click-through rate on top-5 search results
+Secondary metrics:
+- add-to-cart rate from search sessions
+- zero-result session rate
+- median inference cost per 1k requests
+Segments that must not regress: mobile web, long-tail queries, German locale
+Rollback policy: if challenger harms any protected segment by > 2% relative CTR for 24h, revert all traffic to champion
+Output: experiment assignment strategy, segment analysis requirements, and final report structure for registry and product stakeholders
+```
+
+**RU:**
+```
+/champion-challenger
+
+Champion model: search-ranker-bert-v8
+Challenger model: search-ranker-bert-v9-distilled
+Длительность эксперимента: 7 дней в период обычного трафика (исключая неделю кампании Black Friday)
+Основная метрика: click-through rate по top-5 результатам поиска
+Вторичные метрики:
+- add-to-cart rate из search sessions
+- zero-result session rate
+- median inference cost на 1k запросов
+Сегменты, которые не должны деградировать: mobile web, long-tail queries, немецкая локаль
+Политика отката: если challenger ухудшает любой защищённый сегмент более чем на 2% относительного CTR в течение 24ч, вернуть весь трафик champion'у
+Результат: стратегия назначения эксперимента, требования к segment analysis и структура финального отчёта для registry и продуктовых стейкхолдеров
+```

package/areas/software/mlops/prompts/deploy-endpoint.md

@@ -0,0 +1,91 @@
+---
+workflow: deploy-endpoint
+---
+
+# Prompt: `/deploy-endpoint`
+
+Use when: deploying a model endpoint through shadow, canary, and full rollout with explicit rollback thresholds.
+
+---
+
+## Example 1 — Deploy new fraud model with shadow and canary
+
+**EN:**
+```
+/deploy-endpoint
+
+Model name: fraud-detection-xgb
+Run ID: mlflow://fraud-prod/4f2d71b9
+Deployment strategy: shadow -> canary -> full rollout
+Preconditions:
+- /evaluate-model scorecard recommendation = PROMOTE
+- model registry approval recorded by risk lead
+- current production endpoint fraud-score-v12 healthy for last 7 days
+Traffic plan:
+- shadow for 48h with 100% mirrored requests, no user-visible responses from challenger
+- canary 5% -> 20% -> 50% -> 100% if latency p99 < 120ms and error rate < 0.5%
+Monitoring:
+- compare prediction distribution vs champion
+- alert on PSI > 0.2 for any top-10 feature
+- auto-rollback on SLO breach or schema mismatch in payloads
+Output: deployment plan, rollout checkpoints, rollback commands, and post-deploy monitoring checklist
+```
+
+**RU:**
+```
+/deploy-endpoint
+
+Model name: fraud-detection-xgb
+Run ID: mlflow://fraud-prod/4f2d71b9
+Стратегия деплоя: shadow -> canary -> full rollout
+Предусловия:
+- рекомендация в scorecard от /evaluate-model = PROMOTE
+- approval в model registry зафиксирован risk lead
+- текущий production endpoint fraud-score-v12 здоров последние 7 дней
+План трафика:
+- shadow 48ч со 100% зеркалированием запросов, без user-visible ответов от challenger
+- canary 5% -> 20% -> 50% -> 100% если latency p99 < 120ms и error rate < 0.5%
+Мониторинг:
+- сравнивать распределение предсказаний vs champion
+- алерт при PSI > 0.2 для любого из top-10 признаков
+- auto-rollback при нарушении SLO или schema mismatch в payload'ах
+Результат: план деплоя, rollout checkpoints, rollback commands и чеклист post-deploy мониторинга
+```
+
+---
+
+## Example 2 — Emergency redeploy after endpoint infrastructure drift
+
+**EN:**
+```
+/deploy-endpoint
+
+Model name: recommendations-transformer
+Run ID: mlflow://reco-prod/9a17cb21
+Deployment strategy: canary only (skip shadow because the same artifact was already shadow-tested last week)
+Context:
+- current live endpoint lost autoscaling configuration during cluster migration
+- no model change, but serving container and HPA manifests must be re-applied safely
+Success criteria:
+- 100% traffic restored on the same model artifact
+- canary stages complete without error rate increase above 0.2%
+- dashboards updated with new pod labels and endpoint version tags
+Output: infrastructure validation checklist, canary plan, and evidence that registry state still points to the same Production artifact
+```
+
+**RU:**
+```
+/deploy-endpoint
+
+Model name: recommendations-transformer
+Run ID: mlflow://reco-prod/9a17cb21
+Стратегия деплоя: только canary (без shadow, потому что тот же артефакт уже проходил shadow на прошлой неделе)
+Контекст:
+- текущий live endpoint потерял autoscaling configuration во время миграции кластера
+- модель не меняется, но serving container и HPA manifests нужно безопасно применить заново
+Критерии успеха:
+- 100% трафика восстановлено на том же model artifact
+- canary стадии завершаются без роста error rate выше 0.2%
+- dashboards обновлены с новыми pod labels и endpoint version tags
+Результат: чеклист валидации инфраструктуры, canary plan и доказательство, что registry state по-прежнему указывает на тот же Production artifact
+```

package/areas/software/mlops/prompts/evaluate-model.md

@@ -0,0 +1,87 @@
+---
+workflow: evaluate-model
+---
+
+# Prompt: `/evaluate-model`
+
+Use when: evaluating a trained model against a held-out test set, current champion, and business/fairness constraints before promotion.
+
+---
+
+## Example 1 — Binary classification promotion review
+
+**EN:**
+```
+/evaluate-model
+
+Run ID: mlflow://fraud-exp/8124ac91
+Champion reference: fraud-detection-xgb-v12 (Production)
+Model type: binary classification
+Held-out test set: fraud_eval_2026_02_15.parquet (never used in training)
+Required metrics:
+- AUC-ROC, PR-AUC, precision, recall, F1 at operating threshold 0.72
+- confusion matrix for amounts > $500 and <= $500
+Business translation:
+- estimate prevented fraud dollars/month at current traffic
+- estimate false-positive manual review cost increase
+Fairness check required: disparity across customer_region and account_age_bucket
+Decision options: PROMOTE / DO_NOT_PROMOTE / NEEDS_REVIEW
+Output: signed evaluation_scorecard.json + plots + champion comparison summary
+```
+
+**RU:**
+```
+/evaluate-model
+
+Run ID: mlflow://fraud-exp/8124ac91
+Champion reference: fraud-detection-xgb-v12 (Production)
+Тип модели: binary classification
+Held-out test set: fraud_eval_2026_02_15.parquet (никогда не использовался в обучении)
+Обязательные метрики:
+- AUC-ROC, PR-AUC, precision, recall, F1 на operating threshold 0.72
+- confusion matrix для сумм > $500 и <= $500
+Бизнес-интерпретация:
+- оценить предотвращённые fraud losses в месяц при текущем трафике
+- оценить рост стоимости ручной проверки из-за false positive
+Требуется fairness check: disparity по customer_region и account_age_bucket
+Варианты решения: PROMOTE / DO_NOT_PROMOTE / NEEDS_REVIEW
+Результат: подписанный evaluation_scorecard.json + графики + summary сравнения с champion
+```
+
+---
+
+## Example 2 — Regression model with champion comparison and leakage guard
+
+**EN:**
+```
+/evaluate-model
+
+Run ID: mlflow://pricing-exp/cd09f552
+Champion reference: price-forecast-lgbm-v7
+Model type: regression
+Held-out test set: demand_forecast_eval_week_10 (data version dv_2026_03_01)
+Checks required:
+- verify test set rows were excluded from every training iteration and hyperparameter search
+- compute MAE, RMSE, R2, and MAPE vs champion on the same horizon
+- business impact: estimate inventory carrying cost delta if challenger replaces champion
+- slice analysis: top 20 SKUs, long-tail SKUs, promo periods, holiday periods
+Promotion rule: only recommend PROMOTE if MAE improves and no slice regresses by more than 3%
+Output: scorecard, leakage verification note, and decision rationale for pricing team review
+```
+
+**RU:**
+```
+/evaluate-model
+
+Run ID: mlflow://pricing-exp/cd09f552
+Champion reference: price-forecast-lgbm-v7
+Тип модели: regression
+Held-out test set: demand_forecast_eval_week_10 (версия данных dv_2026_03_01)
+Требуемые проверки:
+- подтвердить, что строки test set были исключены из всех итераций обучения и hyperparameter search
+- вычислить MAE, RMSE, R2 и MAPE vs champion на том же горизонте
+- бизнес-эффект: оценить дельту стоимости хранения запасов, если challenger заменит champion
+- slice analysis: top 20 SKU, long-tail SKU, promo periods, holiday periods
+Правило продвижения: рекомендовать PROMOTE только если MAE улучшается и ни один slice не деградирует более чем на 3%
+Результат: scorecard, заметка о проверке leakage и обоснование решения для review командой pricing
+```