clean docs

Author: KSemenenko

AGENTS.md

@@ -134,6 +134,7 @@ Browser test execution rules:
 - Do not run `PrompterOne.Web.UITests` in parallel with another `dotnet build` or `dotnet test` command.
 - In GitHub Actions, run the browser suite in its own dedicated macOS job and keep supporting suites in a separate job so CI can parallelize work without Linux x64 browser-runner contention stretching release validation.
 - GitHub Actions pipelines must expose explicit staged jobs with readable names such as restore, build, supporting tests, browser tests, release publish, and deploy; vague single-job `validate` graphs are not acceptable when the user needs to see pipeline phases clearly in the Actions UI.
+- When monitoring long-running GitHub Actions jobs from the terminal, poll with coarse waits of roughly `3-5` minutes between checks; frequent short-interval polling is noise and does not help on multi-minute browser suites.
 - Browser acceptance tests must stay on the production-shaped runtime path; do not add or keep `?wasm-debug=1` or similar debug-query scenarios in automated acceptance coverage unless the user explicitly asks for that path.
 - Do not add Python or ad-hoc runner scripts to bootstrap browser verification. The repo test commands must self-host the app and execute the flows end to end on their own.
 - Browser UI scenarios are the primary acceptance gate for this repo. Component and core tests are supporting layers, not the release bar.