> Historical reference retained from the preceding release. Current deployment/contracts and evidence are in DEPLOYMENT.md, REPORTS.md, JOURNAL.md and VERIFICATION.md. Do not treat old limitations or tests as current qualification.

> Historical core review. Current2.1 behavior is documented in README, API and READ-ONLY-EXPERIENCE; older capability limits below are not current release claims.

# Review of the supplied AIM 3.1.0 contract

Reviewed archive: AIM-Ansible-3.1.0.zip
SHA-256: `6005cab58875cfd6eabfd18e9b388c219a02d5b0472ba50a94c78abafb637ae9` (matched the supplied checksum).
This is source-based analysis, not live-controller verification. The core archive
and extracted baseline are not changed by WebGUI development.

## Sources reviewed

Paths below are relative to aim-core-3.1.0 in the uploaded ZIP:

| Source | Load-bearing contract/findings |
|---|---|
| ADDON_AGENTS.md | Authoritative same-UID, independent client boundary; no private imports, argument interception or key export |
| scripts/docs/ADDON_API.md | Public operations, RunRequest, credentials-fd framing, event/result schema, limits |
| scripts/docs/ADDON_SUPPORT.md and addon-support-v1.json | Implemented scope versus unsupported Custom, raw output and mutable APIs |
| scripts/docs/RELEASE_HANDOFF.md | Core 3.1/API 1.0 stability; controller results do NOT establish noninteractive execution or non-root SSH qualification |
| scripts/docs/RC19_HANDOFF.md | Historical design intent only; newer support contract takes precedence |
| scripts/docs/LOCAL_VALIDATION.md and CONTROLLER_ACCEPTANCE.md | Core acceptance procedure and evidence boundaries |
| deploy/README.md and scripts/aim.yml | Independently installed aim/aimctl; operator-owned addon execution opt-in and runtime settings |
| scripts/src/aim/services/v1/models.py | Strict RunRequest; unknown fields rejected; explicit hosts; no credential or arbitrary path/actor fields |
| scripts/src/aim/services/v1/service.py | prepare/readiness/execute, key 0600 calling-UID policy, authoritative revisions, native inventory precedence, safe events |
| scripts/src/aim/ctl.py | One request JSONL line; separate inherited pipe/socket secret channel; final response required |
| scripts/src/aim/runtime/ansible.py and process.py | Native CLI discovery/execution, core-owned environment and cancellation |
| scripts/src/aim/locking.py | Stable customer .aim.lock, shared terminal/service advisory locking |
| scripts/src/aim/inventory and playbooks modules | Checked only to understand documented output; never imported by the add-on |

## Decisions derived from these sources

1. Replace RC18Adapter, external_presentation interception and the private Ansible
credential strategy entirely with a bounded aimctl client. Core's private signatures
are not the supported extension interface.
2. `service_user` remains the remote account/key basename. `runtime.private_key_owner`
controls new-key ownership, not automatic local UID switching. An explicitly
pre-started add-on executor runs as the actual authorized key-owning UID. This is
add-on infrastructure, not a claimed native core broker.
3. prepare returns a core-owned revision and credential requirements. Save/queue/
dispatch revalidate through prepare, not local inventory scans/hashes. No stat-only
shortcut for protected sources. Key mode customer needs key access during prepare.
4. Core 1.0 supports customer/catalog reads but no inventory mutations, Custom forced
authentication or password-only verification. Native password defaults retain
inventory precedence. The old Custom UI is removed rather than silently reinterpreted.
5. list_hosts exposes name/address/platforms, not recursive inventory group paths.
Bulk selection is retained for available platform groups only. This is a temporary
feature-parity loss, not a reason to import inventory internals.
6. Global catalog is a union of customer-scoped available catalogs; unavailable
customer-specific playbooks are not offered. Catalog inputs remain core-typed.
7. Events contain structured fixed statuses/counters, not raw task names/messages.
The old raw live console becomes Execution progress. RunResult controls success;
zero exit without final counters is not treated as successful.
8. Optional core fields are ignored safely. The tested product is 3.1.0, service/
wire/event1.0. Future core products need qualification even if API 1.x is stable.
9. Core's public `readiness` performs local runtime/collection checks. It is not a
remote connection test or guarantee that native task execution will succeed.
10. There is no public per-browser-user actor authorization. WebGUI maintains its
own account/grant/approval checks, but the executor UID is a trusted controller actor
with the core permissions of that OS identity, not an isolated tenant.

## Explicit changes from old WebGUI

- Removed imports of aim.config, managers, inventory readers and old command hooks.
- Removed TextVaultSecret/VaultSecret API adaptation, custom Ansible strategies,
canonical-key-export sudo bridge, job-private canonical-key copies and elevated
CAP_SETUID/CAP_SETGID worker design.
- Ansible/version/collection interpretation now belongs to core. `/usr/bin` is no
longer an add-on execution.ansible_bin setting.
- Added a reviewed one-run path; saving is optional. Name collisions return 409.
- New HTTP v2 and schema 4, independently of core API 1.0. Old APIs are not silently
accepted with changed semantics.

## Useful requests for a future core release (NOT implemented here)

Additive HostSummary group paths would restore subgroup selection. Safe per-host
result identifiers and explicitly bounded diagnostic categories could improve
progress without raw logs. A separately designed forced Custom authentication mode
would need to define native precedence, key/agent/control-socket fallback and
approval semantics. None should be recreated in the add-on using private APIs.

## Qualification status

The tests use the real uploaded-core machine interface. Native Ansible is absent
in this development container: controlled fake native commands verify protocol,
result and worker integration only. Real SSH/WinRM, encrypted-key behavior, actual
systemd sandbox deployment and reverse-proxy streaming require controller acceptance.
See VERIFICATION.md for exact tests and limitations; no old rc9 qualification is
claimed as qualification of this new core boundary.