# AIM 3.3.0rc8 validation record

This record distinguishes source/local validation from native controller acceptance.

## Candidate scope

3.3.0rc8 is a focused Windows Checkmk ACL hardening release on top of the final rc7 source state. It retains the native-module, disk-facts, patch-wave, Checkmk placement, and public API behavior while normalizing access on AIM-managed persistent Windows Checkmk files.

## Local checks

Passed for this source tree:

- all bundled Python files parsed successfully;
- all YAML/YML files parsed successfully;
- report filters compile and the package-facts normalizer accepts Debian/RPM-shaped fact dictionaries;
- `patch_summary_v1` accepts the additive bounded `reboot_reasons_before` field;
- Windows patch source contains `ansible.windows.win_reboot_info` and no custom reboot-registry PowerShell probe;
- Checkmk config reading contains `win_stat` + `slurp` and no `win_shell` reader;
- Linux patch package snapshots contain `package_facts` and no `dpkg-query`/`rpm -qa` snapshot command;
- Linux Checkmk final reporting contains `package_facts`/`service_facts` instead of direct package/systemctl queries;
- Core/service and terminal preflight reject an ansible.windows version below 3.8.0.
- Windows disk usage uses `community.windows.win_disk_facts`; the PowerShell `Get-PSDrive` collector is absent. A local normalizer fixture verified drive-letter and no-drive-letter attached volumes against the unchanged `filesystem_usage_v1` shape.

- the new `checkmk_windows_acl` role uses `win_acl_inheritance` plus `win_acl` with well-known SIDs and is called only for exact AIM-managed script/config paths;
- no customer-specific principal name such as `bitformer` is present in the ACL role;
- no recursive ACL task targets the whole Checkmk local/plugins/config directories.

The remaining command/PowerShell/raw call sites were individually reviewed and retained only where current supported modules do not preserve AIM's required semantics; see RELEASE_NOTES.md.

A wheel build with `pip wheel --no-deps --no-build-isolation ./scripts` succeeded. After removing generated build residue, a disposable fresh full-source installation succeeded with both installed launchers reporting AIM 3.3.0rc8. A disposable rc7→rc8 replacement update also succeeded while preserving an operator root README, unknown operator documentation, and operator `scripts/aim.yml`.

## Exact-runtime limitation

This build environment cannot install the canonical external Ansible runtime/collections from package repositories, so no native `ansible-playbook --syntax-check`, `win_reboot_info`, WinRM, package-manager, or managed-host execution is claimed here.

The release therefore requires controller qualification with:

- ansible-core 2.19.11;
- ansible.windows >=3.8.0,<4.0.0;
- the remaining collections from requirements.yml;
- an approved Windows target and Linux package-manager targets as applicable.

## Required controller acceptance

Before stable promotion verify at minimum:

1. `ansible-galaxy collection list ansible.windows` reports 3.8.x and AIM readiness succeeds;
2. a Windows host with no pending reboot reports `reboot_required_before=false`;
3. a Windows host with a real pending reboot reports the native reason(s), and false-positive behavior is improved relative to the old registry probe;
4. the current Windows update wave/reboot/no-rescan policy from rc4 remains unchanged;
5. `checkmk_read_windows_config` returns the same bounded/redacted report using stat/slurp;
6. Debian/RedHat patch reports still list actual net package changes using package_facts snapshots;
7. Checkmk Linux install/update reporting still returns installed version and service state correctly;
8. a Windows Checkmk deployment created by the service account leaves each AIM-managed script and `check_mk.user.yml` readable/manageable by local Administrators and SYSTEM and readable/executable by both application-package principals.

Previous rc4 Windows patch success is historical evidence only and is not relabeled as an rc8 test.

## Final Windows Checkmk placement checks

Local release validation confirms the Windows script catalog marks `citrix_sessions_customized.ps1`, `veeam_o365_status.ps1`, and `veeam_backup_status.ps1` for `$CUSTOM_PLUGINS_PATH$`, while `veeam_backup_license_status.ps1` is selected automatically as a local check when VBR is detected. The rendered plugin template targets the exact custom-plugin paths, and migration/cleanup touches only the documented AIM-managed legacy filenames. Documentation-source validation also confirms no release Markdown/JSON remains outside `scripts/docs/`, and update planning leaves the installation-root `README.md` untouched. Native Windows/Checkmk execution still requires controller acceptance.

## Documentation placement

Validated that only root/scripts-root AIM-owned documentation is centralized under `scripts/docs/`; `deploy/README.md` and role READMEs remain component-local. The root `README.md` is not part of the release payload and remains operator-owned during update planning.