Browser canvas validation

Canvas inspection requires a Copilot host exposing the browser canvas. It is not a universal browser API. A repository-configured isolated Playwright MCP fallback can cover authorized checks only when the canvas is unavailable for that check. This policy also governs browser evidence gathered by other skills and agent work. Existing automated suites and CI/capture drivers remain unchanged. Default to read-only validation of the requested outcome. A validation request does not authorize source fixes, commits, publishing or real application mutations. Use approved test state and confirm side effects before submissions, deletion, messages or changes to authentication.

Required reads and dependencies

Read context resolution and the complete workflow before driving a page. Install product-design for the shared resolver and scenario policy. The optional agent-browser fallback is needed only for an explicit CLI-only request or a named requirement neither the canvas nor configured MCP fallback can meet, not for ordinary checks. If a required companion or sibling skill is missing, stop and name its path before checks. Do not auto-install dependencies.

Select the first existing root, .agents/context/, then .github/contexts/. Read the applicable BROWSER-VALIDATION.md sections and owner topics for target/readiness, canvas identifiers, safe state and recovery. In the shared template, these are Target and readiness, Canvas host and identifiers, Sessions, safe state and artifacts, and Recovery and cleanup. Read Configured Playwright MCP fallback or Existing CLI adapter only when that fallback is needed.

Read the applicable REPOSITORY.md section for the target (Where UI lives in the shared template), Commands when a command is needed, and Constraints for relevant permissions or lifecycle. Follow applicable owner links. If a consumer uses different headings, select the equivalent sections by owner rather than reading the entire file.

Read PRODUCT-DESIGN.md when expected product behavior is unresolved, when assessing scenario behavior or fidelity, or when checking forms, persistence, destructive actions or externally visible changes. A fully specified, read-only route or menu check can use the request as its expected outcome. Read DESIGN-SYSTEM.md for component-specific assertions, ACCESSIBILITY.md for accessibility checks and RESPONSIVE-DESIGN.md for responsive checks. No manifest or canvas-specific pack file is required. Never mix roots.

Missing required context stops validation. Report the selected root/file and offer setup-skills to author or refresh context under the shared resolution rules. Do not invoke it automatically. Never read drafts as active context. Follow relevant owner links and evidence anchors, preserve proposed-default labels and disclose conflicts. Read the complete applicable owner sections, not unrelated sections or topics. Product context owns scenarios and state policy. Browser context owns target URL, server, routes and recovery.

Use only permitted sources. Do not research remotely or broaden exclusions during validation. Request explicit refresh if required documentation is stale or missing. A document with gaps does not prove runtime capabilities.

Runtime contract

Do not discover canvas capabilities for source-only tasks. For rendered checks, identify the browser canvas and inspect its actual schemas before the first required operation. Reuse a schema already discovered for the same provider in this session. Rediscover only after provider reload/reconnect, a schema mismatch or an explicit request to check for changed capabilities; a timeout alone does not invalidate it. Never carry schemas across providers or sessions.

If the browser canvas or required tools are absent, report the blocker and use only the explicit configured MCP handoff in WORKFLOW.md when applicable. Use the advertised open input and action schemas; no frozen action list overrides the runtime.

Keep the canvas type and caller-chosen instanceId handle distinct. Address the panel with that handle through invoke_canvas_action. If the advertised action needs no separate page identifier, call it directly; do not wait for a page-acquisition tool. Reuse a context-declared session handle when appropriate. Only when an action schema requires a separate page identifier, obtain it from runtime results or an explicit supported host contract. If discovery and returned identifiers cannot satisfy an action schema, report the mismatch and stop rather than inventing a value or an unavailable tool. Missing required page acquisition may use the same explicit MCP handoff; it is not an action failure or permission to infer IDs. A missing action can use that handoff for the affected assertion only; keep supported checks in the canvas.

Open/reuse once, read fresh rendered structure, assert the target rendered, then act using observed elements and advertised actions. Re-read after DOM changes, navigation or reload before using refs. Do not assume a click returns a snapshot or that scoped reads/batching exist. Details and recovery are in WORKFLOW.md.

Output

Report target, context document paths, runtime, tested state/flow, assertions and evidence. Separate confirmed failures from unavailable or untested assertions. An overall pass requires every applicable requested assertion to be verified. No render, missing evidence or unavailable runtime means failed or incomplete validation. Static checks do not prove live browser behavior. Do not automatically run broader design, accessibility, responsive or cross-browser audits.