v0.3 E2E checklist

This checklist verifies the user-visible v0.3.0 workflows after the automated release gate passes. Record the result and evidence for every scenario before tagging the release.

1. Test boundaries

• Use a disposable FleetAMP database or a copied v0.2 database.
• Keep the existing service on localhost:8080 unchanged when using a separate test instance.
• Use test users, groups, agents and repositories.
• Never use a production repository token or the only copy of a database.
• Keep Git provider writes disabled until the dry-run workflow succeeds.

2. Prerequisites

Requirement	Verification
Clean release branch	git status --short --branch
Automated release gate passed	bash scripts/verify-v0.3.0.sh
FleetAMP is healthy	curl --fail http://127.0.0.1:8080/health
FleetAMP is ready	curl --fail http://127.0.0.1:8080/ready
Administrator account exists	Sign in and open Administration
Test ownership groups exist	Create two groups in Groups & Labels
Test Collectors are connected	Use at least three Collectors, initially unassigned
Test Git repository exists	Use an empty or dedicated non-production repository

3. Record the test run

Field	Value
Date
Tester
Commit
FleetAMP version
Database source	Fresh / copied v0.2
Git provider mode	Dry-run / GitHub PR
Result	Pass / Fail

4. Core regression

4.1 Authentication and authorization

1. Sign in as an administrator.
2. Change the administrator password from the account page.
3. Create or use a Group Owner assigned to only the test group.
4. Sign in as that Group Owner and confirm unrelated groups and Admin pages are not accessible.

Expected result: password changes preserve access, sessions follow the security rules, and group-scoped authorization prevents access outside assigned groups.

4.2 Configuration governance

1. Open the test group.
2. Create and validate a new configuration version.
3. Submit it for approval with a different eligible reviewer.
4. Approve it and deploy it to the snapshotted targets.
5. Confirm deployment history, desired configuration and effective configuration.
6. Introduce a controlled test difference and verify drift visibility.

Expected result: the immutable version, approval, target snapshot, deployment, effective state, drift and audit entries refer to the same governed change.

4.3 Collector membership governance

Use three connected Collectors and two ownership groups.

1. Create the first group and explicitly select one unassigned Collector.
2. Add a dynamic wildcard rule that matches a second Collector.
3. Confirm the membership preview shows both expected targets.
4. Attempt to enable an overlapping rule in the second group.
5. Confirm the overlapping ownership rule is rejected.
6. Remove the dynamically matched Collector and confirm an explicit exclusion prevents immediate re-entry.
7. Assign the third unassigned Collector from the membership workspace.
8. Move one Collector to the second group and select an approved destination configuration.
9. Remove another Collector and choose the pre-group restoration policy.
10. Submit, approve, and execute the exact immutable proposals.
11. Introduce a controlled failure on a later batch target and inspect compensating rollback evidence.

Expected result: only eligible Collectors can be selected; permissions cover both boundaries for a move; destination configuration belongs to the destination group; target snapshots remain immutable; and every target records completed, failed, restored, rollback_failed, or not_started.

Capture screenshots of the available-Collector selection, dynamic-rule preview, impact preview, approval evidence, execution results, and audit trail. See Manage Collector membership for the complete operator workflow.

5. Migration workflow

1. Open Migration and paste or upload valid Collector YAML.
2. Parse and normalize the configuration.
3. Review standardization findings and pattern matches.
4. Run the Validate stage.
5. Review the final preview before saving.
6. Save the result as an immutable group configuration version.
7. Confirm it appears in Migration History.
8. Optionally submit the exact saved version for approval.

Expected result: invalid input cannot be saved; preview content matches the saved immutable version; history and optional approval preserve its identity.

6. Guides, Blueprints and secrets

1. Follow one path through Guides and confirm only compatible choices are progressively displayed.
2. Select a Blueprint, destination profile and accessible group.
3. Generate and validate the Collector configuration.
4. If the configuration needs a credential, create a group secret and use a ${secret:key} reference.
5. Confirm the raw secret does not appear in previews, versions, approval diffs or audit details.

Expected result: educational guidance remains read-only; generated configuration enters the normal immutable validation and approval workflow; secret values remain write-only.

7. Component lifecycle and GitOps

7.1 Repository connection

1. Open Administration → Integrations.
2. Enter a name and select GitHub, GitLab or Azure DevOps.
3. Confirm only fields relevant to the selected provider are displayed.
4. Limit the connection to the test group and a safe allowed root.
5. Save the connection using a secret:// credential reference.
6. Run connection validation.

Expected result: immutable validation evidence records repository and branch access without exposing the credential. Failed, missing or expired validation prevents execution queueing.

7.2 Proposal, target resolution and approval

1. Open Deployments and create an install, upgrade, restart or removal proposal.
2. Select the component type, test group and compatible deployment method.
3. Resolve targets and review every compatibility finding.
4. Submit the immutable proposal for approval.
5. Sign in as the assigned reviewer and approve the exact proposal evidence.

Expected result: resolved targets are group-scoped; blocking compatibility findings prevent preparation; the requester cannot approve their own proposal.

7.3 Immutable preview and execution

1. Select the enabled and currently validated Git connection.
2. Generate the GitOps preview.
3. Verify the repository path remains below the configured allowed root.
4. Review the files and diff, then submit the exact preview for approval.
5. Approve and queue it in the execution outbox.
6. Open GitOps execution monitor and follow its append-only timeline.

Expected result: preview, approval and execution share the same preview and plan hashes. Dry-run mode records success without modifying a repository.

7.4 Optional GitHub pull-request delivery

Enable real writes only for a dedicated test repository and least-privilege token. GitLab and Azure DevOps remain dry-run delivery providers in v0.3.0.

1. Enable the GitOps worker and GitHub writes.
2. Queue an approved GitHub pull-request execution.
3. Confirm FleetAMP creates or reuses the deterministic FleetAMP branch and one pull request containing exactly the approved files.
4. Merge or close the pull request.
5. Confirm status synchronization appends the corresponding change event.

Expected result: retries and worker recovery reuse the execution ID and branch; they do not create duplicate pull requests.

8. Statistics and audit

1. Confirm Integration statistics classify connections as valid, failed, expired or untested.
2. Confirm the GitOps monitor classifies in-progress, open, completed, failed/closed and retried executions.
3. Filter Audit Log by GitOps & Integrations.
4. Trace one test change from connection validation through preview, approval, queueing and completion.

Expected result: totals match visible immutable records and the audit entries identify actor, action, resource and outcome without credentials.

9. Failure and recovery checks

Scenario	Expected behavior
Invalid Collector YAML	Validation fails and no version is saved
Collector already assigned	A stale explicit assignment proposal is rejected
Overlapping dynamic ownership rule	Group creation or update is rejected
Destination configuration belongs to another group	Move or assignment is rejected
Later membership batch target fails	Earlier completed targets are restored or explicit rollback failure evidence is recorded
Disabled or unauthorized connection	Preview preparation fails
Missing, failed or expired connection validation	Execution cannot be queued
Repository path traversal attempt	Path resolution rejects it
Worker lease expires	Another worker may reclaim the same execution
Provider execution fails	Failure evidence is appended
Administrator retries with a reason	Same execution and deterministic branch are reused
Retry limit reached	Further retry is rejected

10. Release decision

The release candidate is ready only when:

• the full automated verifier passes;
• the copied v0.2 database starts, migrates and restarts successfully;
• all applicable E2E scenarios pass;
• no credentials appear in logs, audit data, previews or saved versions;
• release-blocking defects are closed or explicitly documented;
• known limitations in the release notes match the tested behavior.

Attach the completed checklist, relevant screenshots and sanitized logs to the release PR. Do not attach tokens, passwords, private keys or raw secret values.