Clean up ATVM automation examples and standardize status guidance

- keep atvm-automation-examples.md limited to reusable example commands

- move example-file role guidance into AGENTS.md and atvm-automation-guide.md

- document that all ATVM automation run types use the same status display format

- record the status-format rule as a run learning in atvm-automation-runs.md

atvm/AGENTS.md

@@ -29,6 +29,7 @@ Reference/inventory material:
 - `*-examples.md` files:
   - Reusable command examples and commonly used option combinations.
   - Keep generic; avoid dated one-off run outcomes.
+  - Keep command-focused; move workflow rules, defaults, blacklist policy, and reporting requirements into the corresponding `*-guide.md` or `*-runs.md` files.
 
 ## Setup Track: Required Behavior
 Use `atvm-setup-script-guide.md` as the procedure source and keep behavior aligned with `atvm-setup-script.sh`.
@@ -113,6 +114,7 @@ When the operator asks for run status, report in this order:
 8. Estimated completion time.
 
 Status details:
+- Use the same status display format for every ATVM automation status response regardless of template type (`e2e`, `systemOS`, `reboot`, `migrateops`, and others).
 - Use the live run log on the automation VM when available.
 - Use the run `build_name` as the heading/title when available.
 - Format every machine entry as `machine-name - STATUS`.

atvm/atvm-automation-examples.md

@@ -1,20 +1,5 @@
 ## Examples
 
-- `--build_name` values must not include spaces; use `-` between words.
-- Add the maintained blacklist to `--exclude_partial_match` for runs that use broad selection or randomization.
-- Maintained blacklist:
-  - `atvm6-centos6.0`
-  - `atvm41-redhat6.0`
-  - `atvm73-oracle6.0`
-  - `atvm113-debian9.0.0`
-  - `atvm115-debian9.1.0`
-  - `atvm116-debian9.2.0`
-  - `atvm156-debian9.3.0`
-  - `atvm157-debian13.0.0`
-
-### Config default
-- Unless explicitly told otherwise, use `cypress.atvm-config-gold.ts` in commands instead of `cypress.atvm-config.ts`.
-
 ### E2E: Pure iscsi+fc with specific VMs
 ```bash
 python3 cmc-templates.py --template cmc-e2e --ignore_force_shutdown --config_file_path ./cypress.atvm-config-gold.ts --test_partition --integration_type pure --use_specified_plugin both --specify_vms atvm3-ubuntu18.04 atvm109-w2k12R2; \

atvm/atvm-automation-guide.md

@@ -70,6 +70,7 @@ python3 ./run-sorry-cypress.py --config_file <config-file> --build_name <hyphena
 - Commonly used command examples: `atvm-automation-examples.md`
 - Keep this guide focused on run-control rules and workflow constraints.
 - Use examples as reference material only, not as default intent for new operator requests.
+- Keep `atvm-automation-examples.md` limited to reusable example commands; keep workflow rules, defaults, blacklist policy, and reporting rules in this guide or `atvm-automation-runs.md`.
 
 ## Example Option Patterns (Guide-Only)
 - Distro-scoped VM selection:
@@ -157,6 +158,7 @@ When the operator asks for the status of an ATVM automation run, report in this
 8. Estimated completion time.
 
 Status-report expectations:
+- Use the same display layout for every ATVM automation status response regardless of test type (`e2e`, `systemOS`, `reboot`, `migrateops`, and others).
 - Use the live automation VM state when available.
 - Derive the heading/title from the run `build_name` when available.
 - Format every machine entry as `machine-name - STATUS`.

atvm/atvm-automation-runs.md

@@ -108,3 +108,12 @@ This file stores run-specific examples only when a run produced a new learning r
   - Treat `atvm-automation-examples.md` as reference-only.
   - Use only the options the operator explicitly requested, plus maintained mandatory blacklist handling.
   - Do not assume extra example exclusions such as distro filters are desired unless the operator asks for them.
+
+## Run Learning: 2026-03-12 (Use one status format for all automation run types)
+- Observed requirement:
+  - The operator wants the same ATVM run status display every time, regardless of whether the run is `e2e`, `systemOS`, `reboot`, or another template.
+  - Changing the display style between run types makes the status harder to scan and compare.
+- Action for future runs:
+  - Use one consistent ATVM status layout for all automation status responses.
+  - Keep the order the same: build name, completed machines, notes, skipped machines, remaining machines, summary, timing, estimated completion time.
+  - Keep machine entries one per line as `machine-name - STATUS` regardless of test type.