Files
AWatch-rus/DEVELOPMENT_PLAN_NEXT.md
T

644 lines
34 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# AWatch-rus: план развития на следующие 6-12 месяцев
Дата аудита: 2026-07-01.
Статус: development planning после анализа текущего репозитория. Документ не
добавляет новые продуктовые функции и не меняет runtime-поведение. Цель -
снизить эксплуатационные, release, security и maintainability риски без
нарушения обратной совместимости.
## Границы плана
- Production уже существует; текущий DetMir контур рассчитан примерно на 5 RDP
пользователей.
- Рабочие подсистемы не переписываются. Все изменения должны быть
инкрементальными, проверяемыми и откатываемыми.
- DLP runtime остается `core_only/disabled` по умолчанию; `light` включается
только вручную после resource preflight.
- Loki и always-on Velociraptor не включаются как часть этого плана.
- PowerShell fallback на Windows сохраняется до доказанной parity и burn-in
Rust-пути.
- GitHub остается public mirror validation; release evidence для российского
контура должен формироваться отдельно.
## Фактическое состояние репозитория
- Основной runtime слой стал Rust-first: `adk-rust/` содержит 58 workspace
crates; локальный `cargo metadata --locked` разрешает 349 пакетов.
- Rust dependency hygiene уже включен: `cargo audit --deny warnings`,
`cargo deny`, `cargo machete --with-metadata`, `cargo tree --duplicates` есть
в workflow или локальных gate. Текущий аудит: `cargo audit` и `cargo machete`
чистые, `cargo deny` проходит, но оставляет 36 `bans` warnings.
- CI уже покрывает Rust, docs/registry, smoke, operational maturity,
dependency hygiene, security scan и release binary build. Есть drift:
несколько workflows используют floating `stable`, хотя `rust-toolchain.toml`
закрепляет `1.94.0`.
- DetMir DLP resource guardrails реализованы: runtime disabled/core-only by
default, `detmir-dlp-load-guard`, documented rollback, skipped DLP buckets в
smoke считаются нормой.
- Security Finding Inbox, Hayabusa и Velociraptor оформлены как optional
findings/forensics sources и не являются hot-path зависимостью Workforce.
- Документация registry/governance сильная, но `docs/PROJECT_STATUS_RU.md` и
`docs/RESIDUAL_RISKS_RU.md` фиксируют открытые gaps: Gitea restore drill,
Russian build-runner, первый release evidence build, legal/rightsholder
package, external review evidence.
- Самые крупные maintainability hotspots:
`adk-rust/crates/detmir-portal/src/main.rs` - 14200 строк,
`adk-rust/crates/aw-windows-telemetry/src/main.rs` - 6411 строк,
`proxmox/tsj_guardian_bot.py` - 4610 строк,
`adk-rust/crates/worktime-api/src/main.rs` - 3988 строк,
`ansible/deploy_aw_server.yml` - 3099 строк.
- Найдены точные дубликаты скриптов:
`scripts/aw-contour-diag.sh` =
`scripts/detmir-full-diagnostics/aw-contour-diag.sh`;
`scripts/check_production_inventory_placeholders.sh` =
`scripts/detmir-full-diagnostics/check_production_inventory_placeholders.sh`.
- Найден security hygiene gap: ClickHouse/1C ops wrappers передают
`CLICKHOUSE_PASSWORD` через `--password`, что раскрывает секрет в process
argv на хосте.
## P0 - критично для production
### P0-1. Gate фактической свежести production Rust-бинарников
- Почему нужно: `scripts/check_detmir_rust_release_artifacts.sh` проверяет
наличие локальных release artifacts, но не доказывает, что production
service/timer/Windows task реально запускает тот же binary SHA256.
- Риск: stale бинарник в production может отличаться от проверенного кода,
усложнить rollback и скрыть регрессию в high-load контуре.
- Ожидаемый эффект: воспроизводимая цепочка `service/timer/task -> binary path
-> crate -> local artifact -> prod sha256 -> git sha`.
- Сложность: средняя.
- Объем работ: 3-5 инженерных дней.
- Затрагиваемые файлы:
`scripts/check_detmir_rust_release_artifacts.sh`,
`scripts/package_rust_release_binaries.py`,
`scripts/detmir-full-diagnostics/`,
`adk-rust/crates/detmir-readiness/`,
`windows/validate-deployment.ps1`,
`docs/DETMIR_CURRENT_STATE_RU.md`,
`docs/OPERATIONS_VALIDATION_RUNBOOK_RU.md`.
- Критерии приемки:
команда dry-run выводит все реально задействованные binaries на
`10.10.10.2`, `10.10.10.13` и Windows RDP host;
для каждого binary есть crate, role, unit/timer/task, prod SHA256 и local
release SHA256;
gate падает при missing/stale binary;
проверка не включает heavy DLP, Loki или always-on Velociraptor;
rollback path документирован и проверен на одном canary binary.
### P0-2. Bounded retention для state, evidence, queues и diagnostic output
- Почему нужно: DLP/evidence/backlog/diagnostic контуры уже имеют guardrails,
но retention/cleanup policy для исторических artifacts остается отдельной
future work; disk exhaustion на Proxmox/AW server является прямым outage
риском.
- Риск: накопление JSONL queues, screenshots, Hayabusa drops, diagnostic runs,
ClickHouse landing files или локальных state snapshots может забить диск и
остановить ingestion, portal или ActivityWatch.
- Ожидаемый эффект: предсказуемое потребление диска, безопасный dry-run cleanup,
понятный rollback через backup/hold rules.
- Сложность: средняя.
- Объем работ: 4-7 инженерных дней.
- Затрагиваемые файлы:
`adk-rust/crates/aw-prune-local-state/`,
`scripts/detmir-full-diagnostics/`,
`scripts/detmir_dlp_warehouse_sync.sh`,
`aw-server/logrotate.conf`,
`windows/validate-deployment.ps1`,
`adk-rust/crates/aw-windows-telemetry/`,
`docs/DLP_OPTIONAL_RUNTIME_RU.md`,
`docs/DLP_RESOURCE_PROFILES_RU.md`,
`docs/OPERATIONS_VALIDATION_RUNBOOK_RU.md`.
- Критерии приемки:
есть единая retention matrix по путям, владельцам, age/size limits и dry-run;
cleanup never follows untrusted paths and only touches allowlisted roots;
Windows queues имеют max-age/max-size validation;
skipped DLP buckets при `AW_DLP_ENABLED=false` не считаются ошибкой;
smoke показывает, что cleanup не удаляет active state и не требует downtime.
### P0-3. Убрать секреты ClickHouse/1C из process argv
- Почему нужно: `clickhouse-1c/ops/run_*.sh` передают пароль как
`--password "${CLICKHOUSE_PASSWORD}"`; этот аргумент виден через process list
локальному пользователю или диагностике.
- Риск: утечка ClickHouse credentials с возможностью чтения/изменения
production analytics data.
- Ожидаемый эффект: секреты передаются через env/config file descriptor или
другой non-argv канал; logs и error output остаются redacted.
- Сложность: низкая-средняя.
- Объем работ: 2-4 инженерных дня.
- Затрагиваемые файлы:
`clickhouse-1c/ops/run_ingest_cycle.sh`,
`clickhouse-1c/ops/run_manager_brief.sh`,
`clickhouse-1c/ops/run_recovery_brief.sh`,
`clickhouse-1c/ops/run_company_registry_bindings_refresh.sh`,
`clickhouse-1c/ops/run_company_intelligence_refresh.sh`,
`clickhouse-1c/ops/check_ingest_freshness.sh`,
`clickhouse-1c/ai/*.py`,
`clickhouse-1c/etl/*.py`,
`docs/OPERATIONS_VALIDATION_RUNBOOK_RU.md`.
- Критерии приемки:
`rg -- '--password \"\\$\\{CLICKHOUSE_PASSWORD\\}\"' clickhouse-1c` ничего не
находит в runtime wrappers;
smoke через `ps` доказывает отсутствие password в argv;
существующие env-based deployments остаются совместимыми;
failed auth logs не печатают password;
`bash -n clickhouse-1c/ops/*.sh` и affected Python smoke проходят.
## P1 - желательно выполнить до следующего релиза
### P1-1. Выровнять Rust toolchain во всех CI workflows
- Почему нужно: `rust-toolchain.toml` закрепляет `1.94.0`, но
`.github/workflows/ci.yml`, `security.yml`, `coverage.yml`,
`dependency-hygiene.yml` и `release-assets.yml` используют floating
`dtolnay/rust-toolchain@stable`.
- Риск: CI и release runner могут собирать разные версии компилятора, что
снижает воспроизводимость и усложняет анализ regressions.
- Ожидаемый эффект: единый compiler baseline для local, GitHub mirror и
будущего российского build-runner.
- Сложность: низкая.
- Объем работ: 1-2 инженерных дня.
- Затрагиваемые файлы:
`rust-toolchain.toml`,
`.github/workflows/ci.yml`,
`.github/workflows/security.yml`,
`.github/workflows/coverage.yml`,
`.github/workflows/dependency-hygiene.yml`,
`.github/workflows/release-assets.yml`,
`.github/workflows/rust-binary-build.yml`,
`.github/workflows/rust-workspace.yml`,
`docs/QUALITY_STATUS_RU.md`.
- Критерии приемки:
все blocking Rust jobs используют `rust-toolchain.toml` или тот же explicit
channel;
nightly остается только для advisory `cargo udeps`;
CI check names не меняются;
локально и в CI проходят `cargo fmt`, `cargo test`, `cargo clippy -D warnings`.
### P1-2. Staged triage для duplicate/deprecated Rust dependencies
- Почему нужно: `cargo deny` проходит, но `cargo tree --duplicates` показывает
дубли `bitflags`, `getrandom`, `hashbrown`, `mio`, `zip`, `windows-*`;
`serde_yaml 0.9.34+deprecated` уже зафиксирован как средний риск.
- Риск: supply-chain surface и binary size растут, а устаревшие crates могут
стать будущим vulnerability blocker.
- Ожидаемый эффект: baseline по допустимым дублям, запрет новых необоснованных
дублей, replacement path для deprecated crates.
- Сложность: средняя.
- Объем работ: 4-8 инженерных дней.
- Затрагиваемые файлы:
`adk-rust/Cargo.toml`,
`adk-rust/Cargo.lock`,
`deny.toml`,
`.github/workflows/dependency-hygiene.yml`,
crates using `serde_yaml`, `calamine`, `notify`, `zip`, `windows-sys`,
`docs/THIRD_PARTY_LICENSES_RU.md`,
`docs/QUALITY_STATUS_RU.md`.
- Критерии приемки:
для каждого duplicate family есть decision: keep with reason, update, or
remove;
`cargo audit --deny warnings` и `cargo deny ...` проходят;
новые duplicates без allowlist/обоснования блокируются;
replacement plan для `serde_yaml` не ломает существующие YAML configs;
изменения dependency graph идут отдельными PR, не смешиваются с runtime
features.
### P1-3. Load regression harness для portal/worktime/report hot paths
- Почему нужно: `docs/PROJECT_STATUS_RU.md` прямо фиксирует residual risk:
full report/snapshot prewarm может быть CPU/IO дорогим. Сейчас production
малый, но расширение users/events без бюджета нагрузки рискованно.
- Риск: рост RDP users или history window приводит к slow portal, stale cache,
ClickHouse/AW amplification или datastore lock pressure.
- Ожидаемый эффект: измеримые budgets для p95 latency, memory, query count,
cache hit/stale behavior и degradation semantics.
- Сложность: средняя-высокая.
- Объем работ: 1-2 недели.
- Затрагиваемые файлы:
`scripts/operational-maturity-check.mjs`,
`scripts/awatch-production-hardening-smoke.mjs`,
`adk-rust/crates/detmir-portal/`,
`adk-rust/crates/worktime-api/`,
`adk-rust/crates/worktime-prewarm/`,
`adk-rust/crates/aw-contour-smoke/`,
`docs/OPERATIONS_VALIDATION_RUNBOOK_RU.md`,
`docs/QUALITY_STATUS_RU.md`.
- Критерии приемки:
synthetic dataset проверяет минимум 5/20/50 users without prod data;
harness фиксирует p95 latency, max RSS, query count and stale-cache decisions;
disconnected RDP sessions and event-driven buckets не дают false-fail;
`AW_DLP_ENABLED=false` profile respected;
heavy job остается scheduled/advisory, blocking smoke остается быстрым.
### P1-4. Windows Rust validation parity before reducing PowerShell runtime
- Почему нужно: `docs/POWERSHELL_SCRIPT_STATUS_MATRIX_RU.md` показывает, что
Rust overlay уже основной для части collectors, но `validate-deployment.ps1`,
Hayabusa upload и некоторые recovery paths остаются fallback/runtime.
- Риск: преждевременное удаление PowerShell fallback ухудшит recovery на
Windows Server 2019 и localized RDP sessions.
- Ожидаемый эффект: доказанная parity Rust validation, safe fallback policy и
меньше runtime drift.
- Сложность: средняя.
- Объем работ: 1-2 недели.
- Затрагиваемые файлы:
`adk-rust/crates/aw-windows-telemetry/`,
`windows/validate-deployment.ps1`,
`windows/export-upload-hayabusa-to-aw-server.ps1`,
`windows/ActivityWatch.Windows.Common.psm1`,
`ansible/deploy_aw_windows.yml`,
`docs/POWERSHELL_SCRIPT_STATUS_MATRIX_RU.md`,
`docs/POWERSHELL_TO_RUST_ROADMAP_RU.md`.
- Критерии приемки:
Rust `validate-deployment` покрывает все 7 секций PowerShell validation;
CP866/localized user handling covered by tests;
canary run сравнивает Rust и PowerShell reports на одном RDP host;
PowerShell fallback остается documented rollback;
no removal before burn-in evidence.
### P1-5. Российский build-runner и первый release evidence build
- Почему нужно: `ROADMAP.md`, `docs/PROJECT_STATUS_RU.md` и
`docs/RESIDUAL_RISKS_RU.md` фиксируют, что `awatch-build-01` planned, а
первый release evidence build pending.
- Риск: registry/release package cannot be claimed reproducible in target
Russian contour.
- Ожидаемый эффект: проверяемый release package: source archive, binaries,
SBOM, SHA256SUMS, cargo metadata/tree, logs, manifest.
- Сложность: средняя.
- Объем работ: 3-6 инженерных дней плюс инфраструктурное окно.
- Затрагиваемые файлы:
`scripts/build_release_evidence.sh`,
`scripts/check_release_evidence.sh`,
`scripts/verify_release_assets.sh`,
`docs/registry/RU_BUILD_RUNNER_READINESS_RU.md`,
`docs/registry/BUILD_RUNNER_SETUP_RUNBOOK_RU.md`,
`docs/registry/RELEASE_EVIDENCE_RUNBOOK_RU.md`,
`docs/registry/registry-evidence-manifest.json`.
- Критерии приемки:
build-runner имеет documented OS/toolchain;
release evidence build выполнен не на GitHub runner;
`scripts/check_release_evidence.sh` проходит;
artifacts имеют SHA256 и manifest;
public docs не заявляют registry completion раньше legal approval.
### P1-6. Gitea backup restore drill
- Почему нужно: backup и SHA256 documented, но `restore_tested=false` остается
открытым residual risk.
- Риск: disaster recovery process может оказаться неполным только во время
инцидента.
- Ожидаемый эффект: доказанный restore на отдельном хосте и понятный RTO/RPO
baseline.
- Сложность: средняя.
- Объем работ: 2-4 инженерных дня.
- Затрагиваемые файлы:
`docs/registry/GITEA_BACKUP_AND_RESTORE_RUNBOOK_RU.md`,
`docs/registry/registry-evidence-manifest.json`,
`scripts/registry_readiness_check.sh`,
`docs/PROJECT_STATUS_RU.md`,
`docs/RESIDUAL_RISKS_RU.md`.
- Критерии приемки:
restore выполнен на отдельном сервере;
checksums, logs, repository accessibility и rollback notes сохранены;
manifest обновлен с `restore_tested=true`;
recovery evidence не содержит секреты.
### P1-7. Hayabusa upload path: Rust helper parity and operational proof
- Почему нужно: матрица PowerShell-to-Rust помечает
`windows/export-upload-hayabusa-to-aw-server.ps1` как P1 runtime wrapper.
Hayabusa is optional, but it is a security evidence path.
- Риск: Windows PowerShell encoding, task principal или SSH wrapper drift
ломает forensics upload без явной compile-time проверки.
- Ожидаемый эффект: Rust helper covers upload, sidecar metadata, checksum and
server drop-zone contract; PowerShell remains fallback.
- Сложность: средняя.
- Объем работ: 5-8 инженерных дней.
- Затрагиваемые файлы:
`adk-rust/crates/aw-windows-telemetry/`,
`adk-rust/crates/hayabusa-tools/`,
`windows/export-upload-hayabusa-to-aw-server.ps1`,
`aw-server/hayabusa/aw-hayabusa.sh`,
`ansible/deploy_aw_windows.yml`,
`docs/POWERSHELL_SCRIPT_STATUS_MATRIX_RU.md`,
`docs/POWERSHELL_TO_RUST_ROADMAP_RU.md`.
- Критерии приемки:
helper creates identical server-side intake result on fixture;
BOM/backslash/path traversal tests preserved;
task principal remains interactive Administrator where required;
server `aw-hayabusa-drop.path` processing stays optional and fail-closed;
no automatic remediation is introduced.
## P2 - улучшения архитектуры и сопровождаемости
### P2-1. Инкрементальная декомпозиция крупных runtime modules
- Почему нужно: несколько production-critical files слишком крупные для
надежного review и локального reasoning, особенно `detmir-portal/main.rs` и
`aw-windows-telemetry/main.rs`.
- Риск: высокий change-coupling, труднее делать точечные fixes и находить
regressions.
- Ожидаемый эффект: smaller modules by domain, faster review, focused tests.
- Сложность: средняя-высокая.
- Объем работ: 2-4 недели несколькими малыми PR.
- Затрагиваемые файлы:
`adk-rust/crates/detmir-portal/src/main.rs`,
`adk-rust/crates/detmir-portal/src/*`,
`adk-rust/crates/aw-windows-telemetry/src/main.rs`,
`adk-rust/crates/worktime-api/src/main.rs`,
`proxmox/tsj_guardian_bot.py`,
`clickhouse-1c/ai/company_intelligence_api.py`.
- Критерии приемки:
каждый PR только moves/extracts one bounded domain;
public API, config names, systemd units and task names unchanged;
tests before/after identical;
no new dependencies without written justification;
line count decreases in target `main.rs` files without behavioral rewrite.
### P2-2. Consolidate exact duplicate diagnostic scripts
- Почему нужно: две пары скриптов имеют identical SHA256, что создает риск
будущего drift при исправлениях.
- Риск: one copy fixed, bundled copy stale; diagnostics disagree.
- Ожидаемый эффект: single source of truth while preserving existing paths.
- Сложность: низкая.
- Объем работ: 1-2 инженерных дня.
- Затрагиваемые файлы:
`scripts/aw-contour-diag.sh`,
`scripts/detmir-full-diagnostics/aw-contour-diag.sh`,
`scripts/check_production_inventory_placeholders.sh`,
`scripts/detmir-full-diagnostics/check_production_inventory_placeholders.sh`,
`scripts/detmir-full-diagnostics/detmir-full-diagnostics.sh`,
`docs/OPERATIONS_VALIDATION_RUNBOOK_RU.md`.
- Критерии приемки:
оба старых paths продолжают работать;
есть один canonical implementation или generated copy check;
CI/quality gate ловит future drift;
shellcheck/bash syntax pass.
### P2-3. Split oversized Ansible deployment playbook without behavior change
- Почему нужно: `ansible/deploy_aw_server.yml` имеет 3099 строк; это усложняет
review и безопасные partial changes.
- Риск: accidental deploy behavior changes in unrelated task blocks.
- Ожидаемый эффект: role/include structure with same task order and clearer
ownership.
- Сложность: средняя.
- Объем работ: 1-2 недели.
- Затрагиваемые файлы:
`ansible/deploy_aw_server.yml`,
`ansible/roles/`,
`ansible/group_vars/`,
`docs/OPERATIONS_VALIDATION_RUNBOOK_RU.md`.
- Критерии приемки:
`ansible-playbook --syntax-check` passes;
`--list-tasks` before/after is reviewed for ordering parity;
no default vars changed;
rollback is reverting includes to previous single playbook.
### P2-4. Bound 1C ingest memory and file processing profile
- Почему нужно: `adk-rust/crates/aw-1c-ingest/src/main.rs` currently reads rows
into `Vec` and builds large JSON batches; acceptable for pilot, but risky for
larger exports.
- Риск: memory spikes, long transaction windows, ClickHouse insert amplification
on larger 1C files.
- Ожидаемый эффект: chunked processing where practical, explicit limits and
predictable failure mode for oversized files.
- Сложность: средняя-высокая.
- Объем работ: 1-2 недели.
- Затрагиваемые файлы:
`adk-rust/crates/aw-1c-ingest/src/main.rs`,
`clickhouse-1c/etl/config.yml`,
`clickhouse-1c/etl/config.example.yml`,
`clickhouse-1c/sql/`,
`docs/OPERATIONS_VALIDATION_RUNBOOK_RU.md`,
`docs/QUALITY_STATUS_RU.md`.
- Критерии приемки:
synthetic large CSV/XLSX fixture documents max RSS and runtime;
oversized input fails closed with clear diagnostic;
existing small DetMir files produce identical rows;
ClickHouse insert batch size is configurable and bounded.
### P2-5. Systematic command execution boundary audit
- Почему нужно: `detmir-portal` already validates shell probe commands and
kills process groups on timeout, but other operational binaries also execute
shell/commands (`aw-slo-monitor`, `diag-and-manual-restart`, quality tooling).
- Риск: future config drift can reintroduce command injection, secrets in argv
or incomplete timeout cleanup.
- Ожидаемый эффект: documented command execution policy and shared tests for
allowlisted commands, timeouts, redaction and process-group cleanup.
- Сложность: средняя.
- Объем работ: 4-7 инженерных дней.
- Затрагиваемые файлы:
`adk-rust/crates/detmir-portal/src/main.rs`,
`adk-rust/crates/detmir-portal/src/production/limits.rs`,
`adk-rust/crates/aw-slo-monitor/src/main.rs`,
`adk-rust/crates/diag-and-manual-restart/src/main.rs`,
`adk-rust/crates/quality-gate/src/main.rs`,
`docs/SECURITY_OPERATIONS_RUNBOOK_RU.md`.
- Критерии приемки:
every runtime command source is classified as constant, allowlisted config or
operator-only diagnostic;
tests reject shell control operators where config-driven;
timeout tests verify child/grandchild cleanup;
logs never include secrets from env or args.
### P2-6. Install kit artifact reproducibility and stale payload checks
- Почему нужно: install kit is critical for Windows deployment, includes large
LFS artifacts, and must not silently ship stale payloads.
- Риск: Windows production receives an older collector or mismatched config
while repo checks pass.
- Ожидаемый эффект: deterministic installer evidence and stronger
install-kit-vs-repo validation.
- Сложность: средняя.
- Объем работ: 5-8 инженерных дней.
- Затрагиваемые файлы:
`windows/installkit/innosetup/`,
`adk-rust/crates/check-install-kit-vs-repo/`,
`adk-rust/crates/rebuild-install-kit/`,
`adk-rust/crates/validate-install-kit/`,
`adk-rust/crates/verify-innosetup-installer/`,
`scripts/rebuild_install_kit.sh`,
`docs/INSTALL_KIT_RUNBOOK_RU.md`.
- Критерии приемки:
installer manifest lists exact source commit and payload SHA256;
validation fails on stale collector payload;
generated artifacts are not confused with source files;
Windows task names and config schema remain backward compatible.
### P2-7. Standardize operational metrics contract across Rust daemons
- Почему нужно: individual services expose useful fields, but there is no
consistent minimal metrics/diagnostics contract for every long-running Rust
daemon.
- Риск: incident response depends on service-specific knowledge; regressions in
one daemon are harder to compare with another.
- Ожидаемый эффект: consistent `/health`, structured log fields and optional
metrics snapshots for status, cache, queue, retry, timeout and resource
pressure.
- Сложность: средняя.
- Объем работ: 2-3 недели staged by service.
- Затрагиваемые файлы:
`adk-rust/crates/aw-rus-healthd/`,
`adk-rust/crates/worktime-api/`,
`adk-rust/crates/detmir-portal/`,
`adk-rust/crates/dlp-*`,
`adk-rust/crates/aw-1c-ingest/`,
`docs/OPERATIONS_VALIDATION_RUNBOOK_RU.md`,
`grafana/`.
- Критерии приемки:
minimal contract documented;
each daemon reports version/build, config profile, degraded reason and queue
pressure where applicable;
existing endpoints remain backward compatible;
Grafana/dashboard changes are additive.
## P3 - долгосрочные улучшения
### P3-1. Coverage thresholds after baseline review
- Почему нужно: coverage workflow exists, but roadmap explicitly says threshold
should be added after baseline review.
- Риск: coverage can silently decline while CI remains green.
- Ожидаемый эффект: gradual coverage floor without slowing blocking jobs.
- Сложность: средняя.
- Объем работ: 1-2 недели.
- Затрагиваемые файлы:
`.github/workflows/coverage.yml`,
`adk-rust/`,
`docs/QUALITY_STATUS_RU.md`,
`docs/REVIEW_CHECKLIST_RU.md`.
- Критерии приемки:
initial threshold is based on measured baseline, not arbitrary target;
critical crates get stricter per-crate goals;
generated/fixture code excluded consistently;
threshold moves from advisory to blocking only after stable history.
### P3-2. Russian OS compatibility matrix
- Почему нужно: roadmap keeps Russian OS compatibility as planned validation.
- Риск: deployment assumptions can fail on target OS variants only after a
customer deployment attempt.
- Ожидаемый эффект: explicit supported/unsupported OS matrix and installation
evidence.
- Сложность: средняя-высокая.
- Объем работ: 2-4 недели depending on available test hosts.
- Затрагиваемые файлы:
`docs/registry/`,
`docs/INSTALLATION.md`,
`docs/OPERATIONS_VALIDATION_RUNBOOK_RU.md`,
`ansible/`,
`windows/`,
`windows/installkit/`.
- Критерии приемки:
matrix lists OS version, role, test date, result and limitations;
unsupported combinations are documented explicitly;
no production defaults are changed only for compatibility claims.
### P3-3. Reduce single-maintainer operational risk
- Почему нужно: `docs/RESIDUAL_RISKS_RU.md` identifies one-main-developer risk
and pending reviewed PR evidence.
- Риск: incident response and release continuity depend too much on one person.
- Ожидаемый эффект: documented ownership, review evidence and handoff paths.
- Сложность: организационная, средняя.
- Объем работ: 1-3 месяца part-time.
- Затрагиваемые файлы:
`.github/CODEOWNERS`,
`.github/pull_request_template.md`,
`docs/PR_REVIEW_WORKFLOW_RU.md`,
`docs/PR_REVIEW_EVIDENCE_RU.md`,
`docs/REVIEW_CHECKLIST_RU.md`,
`docs/RESIDUAL_RISKS_RU.md`.
- Критерии приемки:
at least one reviewed PR merged without bypass;
release branch review policy documented;
emergency maintainer handoff checklist exists;
residual risk status updated only with real evidence.
### P3-4. Historical docs and naming hygiene
- Почему нужно: older docs still reference staged statuses, older check names
or public-readiness context; this increases cognitive load for maintainers.
- Риск: operators follow outdated docs or confuse GitHub public mirror checks
with Russian release evidence.
- Ожидаемый эффект: clearer current-state docs and archived historical records.
- Сложность: низкая-средняя.
- Объем работ: 3-6 инженерных дней.
- Затрагиваемые файлы:
`docs/PROJECT_STATUS_RU.md`,
`docs/ROADMAP_CONFORMANCE_AUDIT_RU.md`,
`docs/QUALITY_STATUS_RU.md`,
`docs/registry/`,
`README.md`,
`ROADMAP.md`.
- Критерии приемки:
current-state docs contain current required check names;
historical docs are marked historical and not operational runbooks;
no product claims are strengthened without evidence;
broken/stale links are corrected.
### P3-5. Long-horizon capacity sizing guide
- Почему нужно: current DetMir production is small; future deployments need
sizing guidance for AW SQLite, ClickHouse, Influx/Grafana, DLP light profile
and Windows collector load.
- Риск: deployments scale by guesswork and overload the small-Proxmox pattern.
- Ожидаемый эффект: sizing table by users/events/day, retention, disk, CPU/RAM
and optional security contours.
- Сложность: средняя.
- Объем работ: 2-4 недели after P1 load harness data exists.
- Затрагиваемые файлы:
`docs/DLP_RESOURCE_PROFILES_RU.md`,
`docs/OPERATIONS_VALIDATION_RUNBOOK_RU.md`,
`docs/DETMIR_CURRENT_STATE_RU.md`,
`grafana/`,
`scripts/operational-maturity-check.mjs`.
- Критерии приемки:
guide is based on measured data, not estimates only;
separate profiles exist for 5, 20, 50 and 100 users;
optional DLP/Hayabusa/Velociraptor resource costs are explicit;
default production profile remains conservative.
## Не включено, потому что уже реализовано
- Включение dependency hygiene automation: `cargo machete`, `cargo deny`,
`cargo audit`, `cargo tree --duplicates`, advisory `cargo udeps` уже есть в
workflow.
- Удаление текущих unused Rust dependencies: текущий `cargo machete
--with-metadata` не нашел unused dependencies.
- DetMir DLP light/core-only guardrails: runtime control, resource profiles,
load guard and skipped-bucket semantics already implemented.
- Security Finding Inbox and optional Hayabusa/Velociraptor findings path:
schema, portal/API and fail-closed executor path already documented as
optional and approval-driven.
- Operational maturity smoke workflow: already exists and explicitly avoids
heavy DLP/Loki/always-on Velociraptor.
- Branch protection/CODEOWNERS/PR checklist basics: already documented; the
remaining work is evidence and regular use, not creating the mechanism.
## Проверки, использованные для аудита
```bash
cd /mnt/usb_hdd2/Projects/ActivityWatch-Russian/adk-rust
export CARGO_TARGET_DIR=/home/igor/.cache/detmir-adk-rust-target
cargo metadata --locked --format-version 1
cargo tree --duplicates --locked
cargo audit --deny warnings
cargo deny --manifest-path Cargo.toml check --config ../deny.toml --hide-inclusion-graph --show-stats
cargo machete --with-metadata
cd /mnt/usb_hdd2/Projects/ActivityWatch-Russian
rg -n "dtolnay/rust-toolchain@(stable|[0-9])|rust-toolchain" .github/workflows rust-toolchain.toml
rg -n "CLICKHOUSE_PASSWORD|--password" clickhouse-1c/ops clickhouse-1c/ai clickhouse-1c/etl
sha256sum scripts/aw-contour-diag.sh scripts/detmir-full-diagnostics/aw-contour-diag.sh
sha256sum scripts/check_production_inventory_placeholders.sh scripts/detmir-full-diagnostics/check_production_inventory_placeholders.sh
wc -l adk-rust/crates/detmir-portal/src/main.rs adk-rust/crates/aw-windows-telemetry/src/main.rs proxmox/tsj_guardian_bot.py adk-rust/crates/worktime-api/src/main.rs ansible/deploy_aw_server.yml
```