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

atvm: default automation runs to watcher-backed execute mode

Browse Source 
Update ATVM run workflow rules to remove the default pre-run approval gate for automation requests while keeping safety checks around live running-state and spec verification. Set watcher-backed execution as the default unless explicitly overridden and require post-execution reporting of the exact template and runner commands used. Record the workflow shift in automation run learnings with a dated entry for future consistency.
This commit is contained in:
anthony.wen
2026-05-06 18:40:22 -04:00
parent 2e0acb69c1
commit 82f285a7b1
3 changed files with 65 additions and 48 deletions
Download Patch File Download Diff File Expand all files Collapse all files

19
atvm/docs/automation/run-learnings.md
View File

@@ -9,6 +9,25 @@ This file stores run-specific examples only when a run produced a new learning r
## Current State
- No run-learning entries recorded yet from `guide.md` source material.
## Run Learning: 2026-05-06 (ATVM runs now execute by default with watcher and report executed commands after start)
- Observed requirement:
- The operator does not want a pre-run approval/review gate for standard ATVM automation run requests.
- The operator wants watcher-backed execution to be the default unless explicitly overridden.
- The operator wants the exact executed template and runner commands reported after execution starts.
- Action for future runs:
- Execute ATVM run requests by default without waiting for explicit `approve`.
- Default to watcher-backed launch using the combined `start-atvm-run.sh` wrapper unless the operator explicitly asks to run without watcher.
- After command execution, report the exact executed `cmc-templates.py` and `run-sorry-cypress.py` command strings in the response.
## Run Learning: 2026-05-02 (Do not reuse the previous controller status check for a new ATVM request)
- Observed failure mode:
- A later ATVM run request was blocked because the assistant reused the immediately previous controller status result instead of performing a fresh live running-state check at request time.
- The earlier check had been correct when it was taken, but the prior run had already failed and exited by the time the new request arrived.
- Action for future runs:
- Treat each new ATVM request to start, replace, or block on a run as requiring a fresh live controller check on `192.168.3.190`.
- Do not decide whether to block or allow a new run from a previously reported controller state, even within the same conversation.
- Re-check live runner and watcher state before telling the operator that automation is still running.
## Run Learning: 2026-04-29 (Combined watcher wrapper must execute template generation before runner startup)
- Observed failure mode:
- A watcher-backed `start-atvm-run.sh` launch for `cmc-migrateops-compute-migration` started `run-sorry-cypress.py` without ever running the approved `cmc-templates.py` command.