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

Clarify ATVM plugin validation rules

Browse Source
This commit is contained in:
anthony.wen
2026-03-30 16:22:59 -04:00
parent 6000fa0e78
commit 0b379612a8
3 changed files with 13 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -383,3 +383,12 @@ This file stores run-specific examples only when a run produced a new learning r
- Never execute `git push` for this workspace unless the operator explicitly overrides the workspace rule.
- After creating a local commit, provide the manual push command reference only, defaulting to `git push origin main` unless the operator explicitly asks for a different remote or branch.
- Do not interpret a generic `approve` after a commit as push approval.
## Run Learning: 2026-03-30 (Do not infer plugin execution from generated spec text alone)
- Observed failure mode:
- A generated reboot spec for Pure still contained both iSCSI and FC code blocks, and that was incorrectly treated as proof that both plugin paths would run.
- In this template, the generated file includes both branches, but runtime execution is gated by `Cypress.env("pure_plugin_type")`.
- Action for future runs:
- Do not treat the presence of plugin-specific strings or code blocks in the generated `.ts` file as proof that those plugin steps will execute.
- For plugin-specific questions, determine expected behavior from the template/runtime gate and only call it a mismatch if the runtime logic would execute the wrong plugin path.
- Continue verifying that the requested VM set is present in the generated files and `specPattern`, but keep plugin-path validation separate from simple text-presence checks.