Suppress harmless watcher reset-failed noise in ATVM updates

- update the ATVM AGENTS guidance so expected  output is not called out in routine run updates
- update the ATVM automation guide to mention reset-failed output only when it actually blocks watcher startup or matters for debugging
- add a 2026-03-26 run learning recording that this reset-failed output is normal low-signal noise during successful watcher startup

atvm/AGENTS.md

@@ -65,6 +65,7 @@ This file defines how to operate and maintain the ATVM workspace in `/home/aw/co
 - For host-level test detail and failed-test investigation, use `/root/cdc-e2e-cyp-12.17.4/cypress/cmcReporter`, especially `logs/`, `xml/`, and `mochawesome/`.
 - If the operator asks for ATVM run status without mentioning Mattermost, respond locally only and do not post externally.
 - If the operator asks to send ATVM run status to Mattermost, use `MATTERMOST_ATVM_WEBHOOK` and `MATTERMOST_ATVM_CHANNEL` from `/home/aw/code/cds/.env.credentials.local` by default and send the final status only after the run has fully completed, whether the run passed or failed.
+- Do not call out expected, harmless `systemctl reset-failed ... unit not loaded` output in routine run updates; mention it only if it blocks startup or matters for debugging.
 - 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/docs/automation/guide.md

@@ -50,6 +50,8 @@ Run ATVM CMC automation tests on the designated automation VM without unintended
   - if the child build id label does not match the actual host/spec being executed, report the grouped run using the inferred host-based group instead of the raw child build id label
   - it must not wait and replace those with one single parent-only post
 - After execution, report immediate success/failure only.
+- Do not include expected, harmless `systemctl reset-failed ... unit not loaded` output in routine run-start confirmations.
+- Mention `reset-failed` output only when it prevents watcher startup or becomes relevant to debugging.
 - Do not actively monitor completion unless explicitly requested.
 - If monitoring is requested, allow long runtime windows (15-30+ minutes) and continue until completion unless operator instructs otherwise.
 - Report command errors immediately.

atvm/docs/automation/run-learnings.md

@@ -183,3 +183,12 @@ This file stores run-specific examples only when a run produced a new learning r
   - After `cmc-templates.py`, verify both the generated `.ts` files and the controller config `specPattern` before launching `run-sorry-cypress.py`.
   - Prefer direct controller-side inspection of the config block and file presence rather than fragile shell-escaped regex checks.
   - If the requested VM list is not visibly present in both places, stop and report the mismatch instead of starting the runner.
+
+## Run Learning: 2026-03-26 (Do not repeat harmless reset-failed watcher noise)
+- Observed requirement:
+  - `systemctl reset-failed atvm-run-watcher@...` often reports that the unit was not loaded.
+  - In normal watcher startup this has been harmless and does not change the run outcome.
+  - Repeating that note in routine run confirmations adds noise without helping the operator.
+- Action for future runs:
+  - Do not mention expected, harmless `reset-failed` output in routine run updates.
+  - Only mention it if it actually prevents watcher startup or becomes relevant to debugging.