anthony.wen/cds-ai
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Require ATVM spec verification before starting the runner

Browse Source 
- update the ATVM automation guide to require a post-template verification gate before launching run-sorry-cypress.py
- require verification that both the generated .ts files and the config specPattern include every requested VM after cmc-templates.py finishes
- document that the runner must not be launched when any requested VM is missing from the generated spec set
- update the ATVM AGENTS rules so this template-to-runner verification step is part of the default automation workflow
This commit is contained in:
anthony.wen
2026-03-26 15:55:13 -04:00
parent 35342c1f23
commit 2eed645a85
2 changed files with 10 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
atvm/AGENTS.md
View File

@@ -60,6 +60,8 @@ This file defines how to operate and maintain the ATVM workspace in `/home/aw/co
- Always show exact planned ATVM commands before execution.
- Never execute setup or automation commands that require approval until the operator explicitly approves them.
- For ATVM run approvals, treat `approve` as run-without-watcher and `approve with watcher` as run-with-watcher.
- After `cmc-templates.py`, always verify that the generated spec files and the config `specPattern` still include every requested VM before starting `run-sorry-cypress.py`.
- If any requested VM is missing after template generation, stop and report the mismatch instead of launching the runner.
- 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.