Found while following the skill on a Jmix 3.0.1 project.
Problem: silent — Gate 3 says what to do but not how a Jmix/Vaadin UI must be driven.
Task
Verifying that a newly added Quartz job class is selectable in the Quartz add-on's job editor, by walking the running app's UI with a browser automation tool.
Where
"Gate 3 — render walk", step 3: "With your browser/UI-automation tool, navigate to each view you created, click each button/action, fill each field, and confirm no error overlay or server exception." That sentence is the whole instruction for interacting with the page.
What happened
The walk cost roughly ten failed tool calls before anything worked, from three causes the skill does not mention. First, the screenshot taken right after the page loaded was blank: the Vaadin client had not finished rendering, so the walk needs a wait-and-retry before any screenshot, snapshot, or assertion. Second, role-based locators such as getByRole('button', {name: 'OK'}) did not resolve against vaadin-button elements, so every click had to use either a ref from a fresh accessibility snapshot or a DOM query fallback. Third, each action invalidates the refs from the previous snapshot, so a snapshot must be retaken before every interaction instead of reusing an earlier one. A fourth, add-on-specific surprise: in the Quartz jobs view the Remove action stays disabled until the selected job is paused, so a cleanup step looked broken when it was behaving as designed. Caught by the browser walk itself — every earlier gate was green.
Suggested fix
Add a short "driving a Jmix/Vaadin UI" note to Gate 3 step 3: wait for the client to finish rendering before the first snapshot or screenshot; retake the snapshot before every interaction because refs go stale after each action; prefer refs from the current snapshot over role/name locators for vaadin-* components, falling back to a DOM query when a component exposes no usable role; and treat a disabled action as a possible precondition (a required selection or state) rather than a defect.
Related but distinct: #26 is also about Gate 3, and covers which database the walk writes into.
Found while following the skill on a Jmix 3.0.1 project.
Problem: silent — Gate 3 says what to do but not how a Jmix/Vaadin UI must be driven.
Task
Verifying that a newly added Quartz job class is selectable in the Quartz add-on's job editor, by walking the running app's UI with a browser automation tool.
Where
"Gate 3 — render walk", step 3: "With your browser/UI-automation tool, navigate to each view you created, click each button/action, fill each field, and confirm no error overlay or server exception." That sentence is the whole instruction for interacting with the page.
What happened
The walk cost roughly ten failed tool calls before anything worked, from three causes the skill does not mention. First, the screenshot taken right after the page loaded was blank: the Vaadin client had not finished rendering, so the walk needs a wait-and-retry before any screenshot, snapshot, or assertion. Second, role-based locators such as
getByRole('button', {name: 'OK'})did not resolve againstvaadin-buttonelements, so every click had to use either a ref from a fresh accessibility snapshot or a DOM query fallback. Third, each action invalidates the refs from the previous snapshot, so a snapshot must be retaken before every interaction instead of reusing an earlier one. A fourth, add-on-specific surprise: in the Quartz jobs view the Remove action stays disabled until the selected job is paused, so a cleanup step looked broken when it was behaving as designed. Caught by the browser walk itself — every earlier gate was green.Suggested fix
Add a short "driving a Jmix/Vaadin UI" note to Gate 3 step 3: wait for the client to finish rendering before the first snapshot or screenshot; retake the snapshot before every interaction because refs go stale after each action; prefer refs from the current snapshot over role/name locators for
vaadin-*components, falling back to a DOM query when a component exposes no usable role; and treat a disabled action as a possible precondition (a required selection or state) rather than a defect.Related but distinct: #26 is also about Gate 3, and covers which database the walk writes into.