omnius 1.0.587 → 1.0.589

package/.aiwg/addons/omnius-docs/README.md

@@ -2,4 +2,4 @@
 
 This project-local addon exposes Omnius documentation as small discoverable skills. It is for agents that need to answer questions about Omnius without loading the entire docs tree.
 
-Start with `omnius-docs`, then load a more specific skill when the task is about realtime, sponsors, Telegram, or operations.
+Start with `omnius-docs`, then load a more specific skill when the task is about realtime, sponsors, Telegram, operations, or browser interaction validation.

package/.aiwg/addons/omnius-docs/manifest.json

@@ -27,6 +27,11 @@
       "name": "omnius-ops-docs",
       "description": "Operate Omnius safely: .omnius hygiene, Ollama cleanup, broker, remote access, API keys, elevation prompts, and runtime failure capture.",
       "triggers": ["Omnius operations", "Ollama cleanup", "/broker", "remote access", "API keys", ".omnius"]
+    },
+    {
+      "name": "browser-interaction-validation",
+      "description": "Validate a user-facing browser flow with canonical Playwright interactions, postconditions, diagnostics, and honest blocked/not-applicable evidence.",
+      "triggers": ["browser interaction validation", "UI interaction test", "Playwright validation", "browser flow", "dashboard validation", "form interaction"]
     }
   ]
 }

package/.aiwg/addons/omnius-docs/skills/browser-interaction-validation/SKILL.md

@@ -0,0 +1,81 @@
+---
+compaction_strategy: structured
+---
+
+# browser-interaction-validation
+
+Validate user-facing browser flows with `playwright_browser` as the canonical
+runtime. A page loading, a successful click receipt, a screenshot, or static
+source assertions alone do **not** prove that a requested interaction worked.
+
+## Triggers
+
+- browser interaction validation
+- UI interaction test
+- Playwright validation
+- browser flow
+- dashboard validation
+- form interaction
+
+## Required Contract
+
+For every requested interaction, record one evidence outcome:
+
+- `passed` — the action and its explicit postcondition were observed.
+- `failed` — the action or postcondition failed; preserve the concrete error.
+- `blocked` — a runtime prerequisite is missing; name the prerequisite and the
+  smallest action that would unblock it.
+- `not_applicable` — the interaction cannot be exercised in this environment
+  (for example WebSerial without a real USB device and secure user gesture).
+- `inconclusive` — evidence is insufficient; do not convert it to a pass.
+
+Do not let static checks satisfy a distinct live-interaction claim. Report
+static checks separately as static evidence.
+
+## Workflow
+
+1. Use `playwright_browser` for the entire flow. Do not switch to
+   `browser_action` (Selenium) mid-flow; it is a separate browser session and
+   loses page state. Use Selenium only as an explicit legacy fallback.
+2. Navigate to the live URL, then call `observe_bundle` before interacting.
+   Preserve URL, relevant DOM/a11y selectors, screenshot, page errors, console,
+   and network observations.
+3. Choose a stable locator: prefer `data-testid`, then accessible role/name,
+   then a specific CSS selector. Avoid ordinal or broad selectors that can race
+   reactive re-renders.
+4. For each requested action, state its expected postcondition before acting.
+   Examples: a button label changes, a panel becomes visible, a request returns
+   success, a value persists after refresh, or a visible status changes.
+5. Interact with `click`, `fill`, `type`, `press`, `select`, or `check`.
+   Re-query after a detached-element/re-render failure; do not retry a stale
+   handle blindly. If a stable locator is unavailable, report that as a
+   product-testability finding.
+6. Wait for the specific state, then capture post-action `observe_bundle` and
+   a focused DOM/text/a11y observation that proves the postcondition. Include
+   page errors, console errors, and failed network requests in the result.
+7. Close by listing every requested interaction with its evidence outcome,
+   receipt/artifact references, and any precise remediation. Call
+   `task_complete` when the implementation work is done; verifier feedback is
+   advisory and must not be presented as a completion veto.
+
+## Hardware and Permission Boundaries
+
+Browser tests cannot manufacture physical hardware or permission grants.
+Examples include WebSerial/WebUSB, camera/microphone permissions, native
+dialogs, and payment approval. Mark these `blocked` or `not_applicable` with
+the exact missing condition. Do not claim failure merely because headless
+automation cannot exercise a physical-device path.
+
+## Evidence Handoff Shape
+
+```text
+browser flow: fleet control
+- passed: start simulation → button changed to "Stop Simulation"; post-action
+  DOM and screenshot captured.
+- failed: select fleet → card detached during reactive re-render; stable
+  data-testid is missing, so a resilient locator cannot be formed.
+- not_applicable: connect WebSerial → requires a USB CDC device and secure
+  user gesture; no physical device is attached to this browser session.
+- static evidence: dashboard harness passed (does not prove the three flows).
+```
+