AWatch-rus/docs/ENTERPRISE_QUALITY_STANDARD_RU.md

AWatch-rus: enterprise quality standard

Дата актуализации: 2026-07-01.

AWatch-rus уже работает в production-контуре заказчика. Основная цель разработки - не добавление функций, а повышение надежности, эксплуатационной зрелости, безопасности, сопровождаемости и воспроизводимости.

Приоритеты изменений, по убыванию:

1. Reliability.
2. Operational maturity.
3. Security.
4. Maintainability.
5. Reproducibility.
6. Performance.
7. Simplicity.

Новые функции не должны иметь приоритет над стабильностью production.

Production-first правила

• Предполагать, что production deployment существует и пользователи зависят от непрерывной работы.
• Предпочитать additive/backward-compatible изменения.
• Не перепроектировать работающие подсистемы без измеримой пользы.
• Не включать heavy DLP, Loki или always-on Velociraptor без отдельного operator-approved решения.
• Не менять ActivityWatch logical host ids, bucket suffixes, Grafana variables или ClickHouse workforce keys без отдельной compatibility-процедуры.
• Fail closed для security-sensitive и deployment-sensitive paths.
• Сохранять rollback path для runtime, automation, config и dependency changes.

Порядок принятия решений

Перед реализацией любого изменения ответ должен быть положительным хотя бы на один вопрос:

1. Улучшает ли это production stability?
2. Снижает ли это operational risk?
3. Улучшает ли это diagnostics или observability?
4. Улучшает ли это maintainability?
5. Уменьшает ли это технический долг с низким regression risk?

Если ответ отрицательный на все пять вопросов, изменение не должно попадать в production-oriented PR.

Dependencies

Перед добавлением зависимости нужно явно обосновать:

• почему стандартной библиотеки недостаточно;
• почему существующий workspace crate не решает задачу;
• operational cost зависимости;
• maintenance cost зависимости;
• license/security impact.

Неиспользуемые зависимости удаляются отдельными низкорисковыми PR после targeted tests. Обновление Cargo.lock без причины не допускается.

Required PR sections

Каждый PR обязан содержать:

• Purpose.
• Operational impact.
• Risk assessment.
• Rollback strategy.
• Validation steps.
• Documentation changes.
• Acceptance criteria.

Для documentation-only/governance-only PR нужно явно указать, что runtime, API и UI impact отсутствуют.

Validation baseline

Канонический набор проверок описан в docs/OPERATIONS_VALIDATION_RUNBOOK_RU.md. Минимальный baseline для существенных Rust/runtime changes:

cd /mnt/usb_hdd2/Projects/ActivityWatch-Russian/adk-rust
export CARGO_TARGET_DIR=/home/igor/.cache/detmir-adk-rust-target

cargo fmt --all --check
cargo test --workspace --all-targets --locked
cargo test --workspace --doc --locked
cargo clippy --workspace --all-targets --locked -- -D warnings
cargo audit --deny warnings

cd /mnt/usb_hdd2/Projects/ActivityWatch-Russian
cargo deny --manifest-path adk-rust/Cargo.toml check \
  --config deny.toml \
  --hide-inclusion-graph \
  --show-stats
python3 scripts/public_secret_pattern_check.py
node scripts/operational-maturity-check.mjs --json

Targeted checks are acceptable for small docs/governance or isolated changes, but skipped checks must have a concrete reason.

Technical debt policy

Fix technical debt only when all conditions are true:

• change is isolated;
• regression risk is low;
• tests or operational smoke cover the touched behavior;
• documentation remains accurate.

Otherwise create a follow-up task or document the residual risk instead of mixing broad cleanup into a functional PR.

Canonical references

• Review checklist: docs/REVIEW_CHECKLIST_RU.md.
• Validation runbook: docs/OPERATIONS_VALIDATION_RUNBOOK_RU.md.
• Operational maturity harness: docs/OPERATIONAL_MATURITY_RU.md.
• PR workflow: docs/PR_REVIEW_WORKFLOW_RU.md.
• GitHub governance entrypoint: .github/GOVERNANCE.md.