Update ATVM docs for cmcReporter artifacts

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.