AWatch-rus/DEVELOPMENT_PLAN_NEXT.md

TASK_065: Production 1.0 development plan

Audit date: 2026-07-01.

Scope: AWatch-rus repository readiness for Production 1.0. This plan is based only on repository evidence: tracked files, documentation, CI workflows, Cargo metadata, dependency checks, scripts, deployment assets and operational maturity contracts.

This is not a feature roadmap. Every task below exists because the current repository still has a confirmed blocker or material risk for a durable Production 1.0 release.

Guardrails

• Do not redesign working subsystems.
• Do not add new product functionality as part of Production 1.0 readiness.
• Preserve backward compatibility for deployed DetMir production.
• Keep DLP runtime conservative: core_only/disabled by default; light only after explicit operator resource preflight.
• Do not enable Loki or always-on Velociraptor as part of Production 1.0.
• Keep PowerShell fallback until Rust parity, canary evidence and rollback criteria are proven.
• GitHub remains public mirror validation. Release evidence must be produced in the controlled release contour documented under docs/registry/.

Evidence Base

Reviewed repository areas:

• Rust workspace: adk-rust/, 58 crates from adk-rust/crates/*/Cargo.toml.
• Cargo state: cargo metadata --locked --format-version 1 returned 58 workspace members and 349 packages.
• Dependency hygiene: cargo audit --deny warnings passed; cargo machete --with-metadata found no unused dependencies; cargo deny passed with non-blocking policy warnings; cargo tree --duplicates --locked found duplicate roots including bitflags, getrandom, hashbrown, mio, zip.
• CI: .github/workflows/ci.yml, security.yml, coverage.yml, dependency-hygiene.yml, operational-maturity.yml, rust-workspace.yml, rust-binary-build.yml, release-assets.yml.
• Operational maturity: configs/operational-maturity-contract.json, scripts/operational-maturity-check.mjs, docs/OPERATIONS_VALIDATION_RUNBOOK_RU.md.
• Registry and release evidence docs: docs/registry/*, docs/PROJECT_STATUS_RU.md, docs/RESIDUAL_RISKS_RU.md, docs/QUALITY_STATUS_RU.md, ROADMAP.md.
• Runtime/deployment: ansible/, aw-server/, windows/, proxmox/, clickhouse-1c/, grafana/, pfsense/, root operational wrappers.

Confirmed current strengths:

• Rust-first runtime and wrappers exist.
• Public mirror CI exists.
• Dependency hygiene automation exists.
• Operational maturity offline harness exists.
• DLP resource guardrails and conservative runtime profile exist.
• Security Finding Inbox / Hayabusa / Velociraptor are optional and separated from Workforce hot path.
• Production runbooks and DetMir guardrails are documented.

Confirmed Production 1.0 blockers and material risks are organized below.

P0 - Critical before Production 1.0

P0-1. Production binary parity gate

Purpose: prove that every binary actually running in production matches the reviewed release artifact.

Reason: scripts/check_detmir_rust_release_artifacts.sh verifies local release artifacts, but Production 1.0 also needs a verified mapping from deployed unit, timer or Windows task to exact production SHA256 and source crate.

Operational impact: prevents stale binary drift and makes rollback decisions deterministic.

Risk: high. A stale production binary can invalidate test results and hide regressions.

Estimated effort: 3-5 days.

Affected modules:

• scripts/check_detmir_rust_release_artifacts.sh
• scripts/package_rust_release_binaries.py
• scripts/detmir-full-diagnostics/
• adk-rust/crates/detmir-readiness/
• adk-rust/crates/aw-windows-telemetry/
• windows/validate-deployment.ps1
• docs/OPERATIONS_VALIDATION_RUNBOOK_RU.md

Acceptance criteria:

• Report maps service/timer/task -> binary path -> crate -> runtime role.
• Report includes local release SHA256, production SHA256 and git SHA.
• Missing or mismatched binaries fail the gate.
• DLP/Loki/Velociraptor heavy runtime is not enabled by the check.

Validation steps:

• Run the parity gate against current release artifacts.
• Run diagnostics for 10.10.10.2, 10.10.10.13 and Windows RDP host.
• Confirm stale binary simulation fails.

Expected benefit: release and production state become auditable.

P0-2. Controlled release evidence build

Purpose: produce Production 1.0 release evidence outside GitHub public mirror.

Reason: docs/PROJECT_STATUS_RU.md, docs/QUALITY_STATUS_RU.md and docs/registry/registry-evidence-manifest.json state that GitHub Actions are public validation only and that the Russian build-runner/release evidence path is still pending.

Operational impact: separates mirror CI from release authority.

Risk: high. Without controlled release evidence, Production 1.0 cannot be treated as reproducibly built.

Estimated effort: 3-6 days plus infrastructure window.

Affected modules:

• 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/RELEASE_EVIDENCE_MANIFEST_RU.md
• scripts/build_release_evidence.sh
• scripts/check_release_evidence.sh
• scripts/verify_release_assets.sh

Acceptance criteria:

• Controlled runner has documented OS, toolchain and access model.
• Release evidence includes source archive, binary archive, SBOM if available, SHA256SUMS, Cargo metadata/tree, smoke logs and release manifest.
• scripts/check_release_evidence.sh passes on produced artifacts.
• GitHub CI is not described as release evidence.

Validation steps:

• Run release evidence script on controlled runner.
• Verify manifest and checksums.
• Record runner environment and commit SHA.

Expected benefit: Production 1.0 release becomes reproducible and auditable.

P0-3. Disaster recovery restore proof

Purpose: prove that repository backup can be restored before Production 1.0.

Reason: docs/registry/registry-evidence-manifest.json records restore_tested=false, and docs/RESIDUAL_RISKS_RU.md lists Gitea restore test as open.

Operational impact: validates recovery from source repository loss.

Risk: high. Untested backup is not a recovery capability.

Estimated effort: 2-4 days.

Affected modules:

• 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

Acceptance criteria:

• Restore is performed on a separate host.
• SHA256 verification, logs, restored repository access and rollback notes are captured.
• Manifest is updated only after evidence exists.
• No secrets are copied into repository documentation.

Validation steps:

• Execute restore runbook.
• Run registry readiness check after manifest update.
• Confirm restored repository clone and log evidence.

Expected benefit: repository DR becomes proven, not only documented.

P0-4. Bounded retention for operational state and evidence

Purpose: prevent disk exhaustion from state, queues, diagnostics, evidence and forensics artifacts.

Reason: DLP optional runtime docs explicitly state that historical DLP buckets and artifacts may remain until a separate retention/cleanup procedure. Scripts and diagnostics also create durable output.

Operational impact: reduces outage risk on Proxmox/AW server/Windows state paths.

Risk: high. Disk exhaustion can stop ingestion, portal, ClickHouse or ActivityWatch services.

Estimated effort: 4-7 days.

Affected modules:

• 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

Acceptance criteria:

• Retention matrix lists roots, owners, max age, max size and dry-run behavior.
• Cleanup only touches allowlisted roots and refuses traversal/symlink escape.
• Active state is preserved.
• Disabled DLP buckets remain SKIPPED, not failure.

Validation steps:

• Run dry-run cleanup on fixture tree.
• Run apply mode on controlled temporary tree.
• Run operational smoke after cleanup.

Expected benefit: long-running production operation has bounded disk behavior.

P0-5. Remove ClickHouse password exposure from process arguments

Status: addressed by TASK_068. Runtime ClickHouse/1C wrappers keep CLICKHOUSE_PASSWORD in the environment/config path and no longer pass it in process arguments.

Purpose: keep production credentials out of ps/process argv.

Reason: rg confirmed clickhouse-1c/ops/run_*.sh wrappers pass --password "${CLICKHOUSE_PASSWORD}".

Operational impact: improves secret handling for the 1C/ClickHouse contour.

Risk: high. Local process listing can reveal ClickHouse credentials.

Estimated effort: 2-4 days.

Affected modules:

• 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

Acceptance criteria:

• Runtime wrappers no longer pass password through argv.
• Existing environment-based deployment remains backward compatible.
• Logs redact authentication failures.
• ps smoke proves password absence.

Validation steps:

• bash -n clickhouse-1c/ops/*.sh
• Run affected wrapper against a test or dry-run configuration.
• Verify ps output during execution.
• Run secret-pattern scan.

Expected benefit: production secret exposure surface is reduced.

P0-6. Portal/worktime hot-path load gate

Purpose: prevent Production 1.0 from regressing under report/prewarm load.

Reason: docs/PROJECT_STATUS_RU.md records that full report/snapshot prewarm can still be CPU/IO expensive.

Operational impact: protects owner/operator portal, worktime reports and AW query path.

Risk: high. More users or more history can produce slow portal, stale data or AW datastore pressure.

Estimated effort: 1-2 weeks.

Affected modules:

• 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

Acceptance criteria:

• Synthetic 5/20/50 user fixtures exist without production data.
• Gate records p95 latency, max RSS, query count and stale-cache behavior.
• Disconnected RDP sessions do not false-fail.
• AW_DLP_ENABLED=false semantics remain valid.
• Heavy load job is scheduled/advisory; blocking smoke remains fast.

Validation steps:

• Run offline load harness.
• Confirm configured p95/RSS ceilings.
• Run existing operational maturity smoke.

Expected benefit: Production 1.0 has measurable performance safety.

P1 - Strongly recommended for the first Production 1.0 release train

P1-1. Align Rust toolchain across CI

Purpose: remove compiler drift from blocking workflows.

Reason: rust-toolchain.toml pins 1.94.0, but several workflows install floating stable.

Operational impact: improves reproducibility between local, CI and release contours.

Risk: medium. Toolchain drift can create inconsistent warnings or binaries.

Estimated effort: 1-2 days.

Affected modules:

• 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
• docs/QUALITY_STATUS_RU.md

Acceptance criteria:

• Blocking Rust workflows use the pinned toolchain.
• Nightly remains limited to advisory cargo udeps.
• Required check names do not change.

Validation steps:

• YAML syntax validation.
• Affected workflow dry review.
• Run relevant Rust checks if workflow commands change.

Expected benefit: CI becomes more deterministic.

P1-2. Dependency warning baseline and future block policy

Purpose: make dependency hygiene fail closed for new risk while preserving current compatibility.

Reason: cargo deny passes but reports 36 non-blocking bans warnings; cargo tree --duplicates --locked reports duplicate roots; serde_yaml is documented as deprecated in third-party license docs.

Operational impact: reduces future supply-chain drift.

Risk: medium. Uncontrolled duplicate/deprecated dependency growth increases maintenance and security load.

Estimated effort: 4-8 days.

Affected modules:

• adk-rust/Cargo.toml
• adk-rust/Cargo.lock
• deny.toml
• .github/workflows/dependency-hygiene.yml
• docs/THIRD_PARTY_LICENSES_RU.md
• docs/QUALITY_STATUS_RU.md

Acceptance criteria:

• Each existing warning is classified: keep, update, remove or defer.
• New duplicate/deprecated dependencies require documented exception.
• cargo audit, cargo deny, cargo machete, cargo metadata pass.

Validation steps:

• Run dependency hygiene pipeline.
• Verify policy failure on synthetic unapproved duplicate where practical.

Expected benefit: dependency hygiene remains controlled after 1.0.

P1-3. Windows Rust validation parity

Purpose: prove Rust validation is equivalent to current PowerShell validation before reducing fallback reliance.

Reason: docs/POWERSHELL_SCRIPT_STATUS_MATRIX_RU.md lists remaining fallback and runtime PowerShell paths, including validation and Hayabusa upload.

Operational impact: keeps Windows/RDP production recoverable while reducing runtime drift.

Risk: medium. Premature fallback removal can break localized Windows Server 2019 recovery paths.

Estimated effort: 1-2 weeks.

Affected modules:

• adk-rust/crates/aw-windows-telemetry/
• windows/validate-deployment.ps1
• windows/ActivityWatch.Windows.Common.psm1
• windows/export-upload-hayabusa-to-aw-server.ps1
• ansible/deploy_aw_windows.yml
• docs/POWERSHELL_SCRIPT_STATUS_MATRIX_RU.md
• docs/POWERSHELL_TO_RUST_ROADMAP_RU.md

Acceptance criteria:

• Rust validation covers all current production validation sections.
• Localized Windows user/session handling is tested.
• Canary comparison between Rust and PowerShell reports is recorded.
• PowerShell remains documented rollback.

Validation steps:

• Run Rust validation against fixture and live canary.
• Run PowerShell validation against same host.
• Compare normalized reports.

Expected benefit: Windows runtime maturity improves without breaking rollback.

P1-4. Install kit reproducibility and stale payload gate

Purpose: ensure Windows installer payloads match repository and release artifacts.

Reason: repository contains install-kit tooling and large installer artifacts; stale payloads can deploy old collectors while CI is green.

Operational impact: safer Windows upgrades and rollback.

Risk: medium. Mismatched install kit can create production drift.

Estimated effort: 5-8 days.

Affected modules:

• 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

Acceptance criteria:

• Installer manifest contains source commit and payload SHA256 values.
• Validation fails on stale collector payload.
• Existing Windows task names and config schema remain compatible.

Validation steps:

• Rebuild install kit on controlled runner.
• Run install-kit validators.
• Compare payload manifest with repository state.

Expected benefit: Windows deployments become reproducible.

P1-5. Current-state documentation cleanup

Purpose: prevent operators and reviewers from following stale status text.

Reason: current docs include historical statuses, older required check names and explicit pending sections that must be reconciled with active branch protection and current workflows.

Operational impact: reduces release and support mistakes.

Risk: medium. Wrong runbook/status interpretation can cause incorrect release decisions.

Estimated effort: 3-6 days.

Affected modules:

• docs/PROJECT_STATUS_RU.md
• docs/QUALITY_STATUS_RU.md
• docs/ROADMAP_CONFORMANCE_AUDIT_RU.md
• docs/BRANCH_PROTECTION_POLICY_RU.md
• docs/BRANCH_PROTECTION_EVIDENCE_RU.md
• README.md
• ROADMAP.md

Acceptance criteria:

• Current docs list actual required check names.
• Historical docs are clearly marked historical.
• Registry/release claims remain conservative.
• No stale instructions contradict Production 1.0 guardrails.

Validation steps:

• Run registry readiness check.
• Run docs smoke/link validation.
• Run secret scan.

Expected benefit: release process is less error-prone.

P1-6. Reviewed PR and release governance evidence

Purpose: prove review discipline before Production 1.0.

Reason: docs/RESIDUAL_RISKS_RU.md records first reviewed PR evidence as pending even though CODEOWNERS, PR template and ruleset are present.

Operational impact: improves change control for production releases.

Risk: medium. Lack of review evidence weakens release governance.

Estimated effort: 1-3 days after reviewer availability.

Affected modules:

• .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

Acceptance criteria:

• At least one PR is reviewed and merged without bypass.
• Evidence records checks, reviewer, approval and merge path.
• Release branch review policy is documented.

Validation steps:

• Verify PR history and ruleset evidence.
• Run registry readiness check after evidence update.

Expected benefit: Production 1.0 has visible governance evidence.

P2 - Engineering improvements for post-1.0 hardening

P2-1. Incremental decomposition of large modules

Purpose: reduce review risk in the largest files without behavior changes.

Reason: confirmed hotspots include detmir-portal/src/main.rs at 14200 lines, aw-windows-telemetry/src/main.rs at 6411 lines, proxmox/tsj_guardian_bot.py at 4610 lines, worktime-api/src/main.rs at 3988 lines and ansible/deploy_aw_server.yml at 3099 lines.

Operational impact: easier reviews and lower regression risk.

Risk: medium. Large files increase accidental coupling.

Estimated effort: 2-4 weeks in small PRs.

Affected modules:

• adk-rust/crates/detmir-portal/
• adk-rust/crates/aw-windows-telemetry/
• adk-rust/crates/worktime-api/
• proxmox/tsj_guardian_bot.py
• ansible/deploy_aw_server.yml

Acceptance criteria:

• Only extract bounded domains.
• Public API, config, unit and task names remain unchanged.
• Tests before and after remain equivalent.

Validation steps:

• Targeted tests per extracted module.
• Full Rust pipeline for Rust changes.
• Ansible syntax/list-tasks parity for playbook changes.

Expected benefit: maintainability improves without architecture rewrite.

P2-2. Consolidate exact duplicate diagnostic scripts

Purpose: prevent script drift.

Reason: SHA256 confirms exact duplicates: scripts/aw-contour-diag.sh equals scripts/detmir-full-diagnostics/aw-contour-diag.sh; and scripts/check_production_inventory_placeholders.sh equals scripts/detmir-full-diagnostics/check_production_inventory_placeholders.sh.

Operational impact: diagnostics remain consistent.

Risk: low-medium. Future fixes may land in one copy only.

Estimated effort: 1-2 days.

Affected modules:

• 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

Acceptance criteria:

• Existing paths continue to work.
• One implementation is canonical or drift check is enforced.
• Shell syntax and shellcheck pass.

Validation steps:

• bash -n on affected scripts.
• Run diagnostic wrapper in dry-run/smoke mode.

Expected benefit: lower maintenance overhead.

P2-3. Bound 1C ingest memory profile

Purpose: make 1C ingest safer for larger files.

Reason: adk-rust/crates/aw-1c-ingest/src/main.rs reads rows into Vec and builds large JSON batches; acceptable now, but risky as export volume grows.

Operational impact: improves ClickHouse ingestion predictability.

Risk: medium. Large files can create memory spikes and long insert windows.

Estimated effort: 1-2 weeks.

Affected modules:

• adk-rust/crates/aw-1c-ingest/src/main.rs
• clickhouse-1c/etl/config.yml
• clickhouse-1c/etl/config.example.yml
• clickhouse-1c/sql/

Acceptance criteria:

• Oversized input fails closed with clear diagnostic.
• Batch size is bounded and configurable.
• Existing small DetMir files produce identical output.

Validation steps:

• Add synthetic large CSV/XLSX fixture.
• Run targeted Rust tests.
• Measure max RSS on fixture.

Expected benefit: safer scaling of 1C analytics.

P2-4. Command execution boundary audit

Purpose: standardize shell/command execution safety.

Reason: detmir-portal already validates shell probe commands and tests process-tree timeout cleanup, while other operational tools also execute commands.

Operational impact: prevents future command injection or timeout regressions.

Risk: medium. Config-driven command execution must remain fail-closed.

Estimated effort: 4-7 days.

Affected modules:

• 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

Acceptance criteria:

• Runtime command sources are classified.
• Config-driven commands reject shell control operators where applicable.
• Timeout tests cover child/grandchild cleanup.
• Logs do not expose secrets.

Validation steps:

• Targeted Rust tests.
• Clippy for affected crates.
• Secret scan.

Expected benefit: stronger fail-closed security posture.

P3 - Long-term improvements after Production 1.0

P3-1. Russian OS compatibility matrix

Purpose: document supported and unsupported target OS combinations.

Reason: ROADMAP.md lists Russian OS compatibility validation as planned.

Operational impact: reduces deployment surprises for new customers.

Risk: low-medium for current DetMir, higher for wider distribution.

Estimated effort: 2-4 weeks depending on test hosts.

Affected modules:

• docs/registry/
• docs/INSTALLATION.md
• docs/OPERATIONS_VALIDATION_RUNBOOK_RU.md
• ansible/
• windows/
• windows/installkit/

Acceptance criteria:

• Matrix lists OS, role, test date, result and limitations.
• Unsupported combinations are explicit.
• No production defaults are changed just for claims.

Validation steps:

• Run install/deploy smoke per OS.
• Record evidence paths.

Expected benefit: clearer deployment support boundary.

P3-2. Coverage threshold after baseline review

Purpose: prevent coverage decline after baseline stabilizes.

Reason: docs/QUALITY_STATUS_RU.md and ROADMAP.md state coverage threshold is not enforced yet.

Operational impact: improves long-term regression resistance.

Risk: low for current production if kept advisory first.

Estimated effort: 1-2 weeks.

Affected modules:

• .github/workflows/coverage.yml
• docs/QUALITY_STATUS_RU.md
• docs/REVIEW_CHECKLIST_RU.md
• selected adk-rust/ crates

Acceptance criteria:

• Initial threshold is based on measured baseline.
• Threshold starts advisory and becomes blocking only after stable history.
• Generated/fixture code exclusions are documented.

Validation steps:

• Run coverage workflow locally or in CI.
• Compare summary to baseline.

Expected benefit: gradual improvement in test discipline.

P3-3. Capacity sizing guide from measured data

Purpose: provide measured sizing guidance beyond the current 5-user DetMir deployment.

Reason: current production is small; future deployments need measured guidance for AW SQLite, ClickHouse, Grafana, DLP light profile and Windows collector load.

Operational impact: safer planning for larger deployments.

Risk: low for current production, medium for growth.

Estimated effort: 2-4 weeks after P0 load gate data exists.

Affected modules:

• docs/SIZING_GUIDE_RU.md
• docs/DLP_RESOURCE_PROFILES_RU.md
• docs/OPERATIONS_VALIDATION_RUNBOOK_RU.md
• grafana/
• scripts/operational-maturity-check.mjs

Acceptance criteria:

• Profiles exist for 5, 20, 50 and 100 users.
• Optional DLP/Hayabusa/Velociraptor resource costs are explicit.
• Guidance is based on measured harness output.

Validation steps:

• Run synthetic capacity scenarios.
• Update sizing doc with observed p95/RSS/storage data.

Expected benefit: production planning becomes evidence-based.

Not Proposed Because Already Implemented

• Rust-first runtime direction.
• Public mirror CI, security scan and dependency review.
• cargo audit, cargo deny, cargo machete, cargo tree --duplicates and advisory cargo udeps workflow coverage.
• DLP core_only/disabled production guardrails and load guard.
• Optional Security Finding Inbox / Hayabusa / Velociraptor separation from Workforce hot path.
• Operational maturity offline harness.
• Branch protection, CODEOWNERS, PR template and review checklist mechanisms.
• Unused dependency cleanup: current cargo machete --with-metadata reports no unused dependencies.