Update ATVM docs for cmcReporter artifacts

atvm/AGENTS.md

@@ -46,6 +46,7 @@ This file defines how to operate and maintain the ATVM workspace in `/home/aw/co
 - Controller host: `atvm-cypres-vm-1`
 - Controller IP: `192.168.3.190`
 - Controller credentials: `root / atvmcdsi2012`
+- Detailed test artifact root on controller: `/root/cdc-e2e-cyp-12.17.4/cypress/cmcReporter`
 - Default plugin: `--use_specified_plugin iscsi`
 - Always include `--ignore_force_shutdown` unless explicitly told not to.
 - Default config family: `gold`
@@ -56,6 +57,7 @@ This file defines how to operate and maintain the ATVM workspace in `/home/aw/co
 - Before any automation run, always check whether automation is already running.
 - Always show exact planned ATVM commands before execution.
 - Never execute setup or automation commands that require approval until the operator explicitly approves them.
+- For host-level test detail and failed-test investigation, use `/root/cdc-e2e-cyp-12.17.4/cypress/cmcReporter`, especially `logs/`, `xml/`, and `mochawesome/`.
 - Treat `docs/automation/examples.md` as reference-only, not default operator intent.
 - Put reusable workflow rules in `guide.md` files.
 - Put dated lessons only in `run-learnings.md` files.

atvm/README.md

@@ -30,5 +30,6 @@ This folder contains the ATVM setup workflow, ATVM Cypress automation workflow,
 - Use `guide.md` files for authoritative workflow behavior.
 - Use `examples.md` for reusable command patterns only.
 - Use `run-learnings.md` only when a run produced a new lasting lesson.
+- For detailed ATVM automation test results, especially per-host failures, use `/root/cdc-e2e-cyp-12.17.4/cypress/cmcReporter` on the automation controller.
 - Use `inventory/` for persistent environment information such as hosts, credentials, and IP assignments.
 - Use `archive/imported-notes/` when you need the original full historical notes in their original layout.

atvm/docs/automation/guide.md

@@ -48,6 +48,19 @@ Run ATVM CMC automation tests on the designated automation VM without unintended
 ## Core Scripts
 - Template prep: `/root/cdc-e2e-cyp-12.17.4/cmc-templates.py`
 - Test execution: `./run-sorry-cypress.py`
+- Detailed host-level test artifacts: `/root/cdc-e2e-cyp-12.17.4/cypress/cmcReporter`
+
+## Detailed Test Artifacts
+- Use `/root/cdc-e2e-cyp-12.17.4/cypress/cmcReporter` on the automation controller for detailed per-host test evidence.
+- Reporter subdirectories of interest:
+  - `logs/`
+    - per-host text and JSON logs for the executed tests
+  - `xml/`
+    - machine result XML files and the final `check-xml-files.ts` bookkeeping output
+  - `mochawesome/`
+    - per-run HTML reports
+- When a machine fails, use the matching `logs/` entry first to capture the detailed failure context for that host.
+- When reconstructing historical status, prefer `cmcReporter` artifacts over less-specific runner output because they preserve per-host results after the live run has ended.
 
 Typical sequence:
 1. Build the exact `cmc-templates.py` and `run-sorry-cypress.py` commands for the request.
@@ -185,6 +198,7 @@ Status-report expectations:
 - Use the live automation VM state when available.
 - If no automation is currently running, fall back to the most recent historical run artifacts and logs.
 - Prefer local automation evidence in this order: active runner processes, live automation-VM files, shell history for the last launch command, then historical reporter artifacts.
+- For detailed machine-level failure information, use `/root/cdc-e2e-cyp-12.17.4/cypress/cmcReporter/logs/` on the automation VM.
 - Derive the heading/title from the run `build_name` when available.
 - Format every machine entry as `machine-name - STATUS`.
 - Put each machine on its own line; never combine multiple machines into one paragraph or comma-separated line.