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
This commit is contained in:
2026-03-12 17:43:49 -04:00
parent 63fc92244e
commit ecae52712f
4 changed files with 13 additions and 15 deletions

View File

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