omnius 1.0.586 → 1.0.588
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -2,4 +2,4 @@
|
|
|
2
2
|
|
|
3
3
|
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.
|
|
4
4
|
|
|
5
|
-
Start with `omnius-docs`, then load a more specific skill when the task is about realtime, sponsors, Telegram, or
|
|
5
|
+
Start with `omnius-docs`, then load a more specific skill when the task is about realtime, sponsors, Telegram, operations, or browser interaction validation.
|
|
@@ -27,6 +27,11 @@
|
|
|
27
27
|
"name": "omnius-ops-docs",
|
|
28
28
|
"description": "Operate Omnius safely: .omnius hygiene, Ollama cleanup, broker, remote access, API keys, elevation prompts, and runtime failure capture.",
|
|
29
29
|
"triggers": ["Omnius operations", "Ollama cleanup", "/broker", "remote access", "API keys", ".omnius"]
|
|
30
|
+
},
|
|
31
|
+
{
|
|
32
|
+
"name": "browser-interaction-validation",
|
|
33
|
+
"description": "Validate a user-facing browser flow with canonical Playwright interactions, postconditions, diagnostics, and honest blocked/not-applicable evidence.",
|
|
34
|
+
"triggers": ["browser interaction validation", "UI interaction test", "Playwright validation", "browser flow", "dashboard validation", "form interaction"]
|
|
30
35
|
}
|
|
31
36
|
]
|
|
32
37
|
}
|
|
@@ -0,0 +1,81 @@
|
|
|
1
|
+
---
|
|
2
|
+
compaction_strategy: structured
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# browser-interaction-validation
|
|
6
|
+
|
|
7
|
+
Validate user-facing browser flows with `playwright_browser` as the canonical
|
|
8
|
+
runtime. A page loading, a successful click receipt, a screenshot, or static
|
|
9
|
+
source assertions alone do **not** prove that a requested interaction worked.
|
|
10
|
+
|
|
11
|
+
## Triggers
|
|
12
|
+
|
|
13
|
+
- browser interaction validation
|
|
14
|
+
- UI interaction test
|
|
15
|
+
- Playwright validation
|
|
16
|
+
- browser flow
|
|
17
|
+
- dashboard validation
|
|
18
|
+
- form interaction
|
|
19
|
+
|
|
20
|
+
## Required Contract
|
|
21
|
+
|
|
22
|
+
For every requested interaction, record one evidence outcome:
|
|
23
|
+
|
|
24
|
+
- `passed` — the action and its explicit postcondition were observed.
|
|
25
|
+
- `failed` — the action or postcondition failed; preserve the concrete error.
|
|
26
|
+
- `blocked` — a runtime prerequisite is missing; name the prerequisite and the
|
|
27
|
+
smallest action that would unblock it.
|
|
28
|
+
- `not_applicable` — the interaction cannot be exercised in this environment
|
|
29
|
+
(for example WebSerial without a real USB device and secure user gesture).
|
|
30
|
+
- `inconclusive` — evidence is insufficient; do not convert it to a pass.
|
|
31
|
+
|
|
32
|
+
Do not let static checks satisfy a distinct live-interaction claim. Report
|
|
33
|
+
static checks separately as static evidence.
|
|
34
|
+
|
|
35
|
+
## Workflow
|
|
36
|
+
|
|
37
|
+
1. Use `playwright_browser` for the entire flow. Do not switch to
|
|
38
|
+
`browser_action` (Selenium) mid-flow; it is a separate browser session and
|
|
39
|
+
loses page state. Use Selenium only as an explicit legacy fallback.
|
|
40
|
+
2. Navigate to the live URL, then call `observe_bundle` before interacting.
|
|
41
|
+
Preserve URL, relevant DOM/a11y selectors, screenshot, page errors, console,
|
|
42
|
+
and network observations.
|
|
43
|
+
3. Choose a stable locator: prefer `data-testid`, then accessible role/name,
|
|
44
|
+
then a specific CSS selector. Avoid ordinal or broad selectors that can race
|
|
45
|
+
reactive re-renders.
|
|
46
|
+
4. For each requested action, state its expected postcondition before acting.
|
|
47
|
+
Examples: a button label changes, a panel becomes visible, a request returns
|
|
48
|
+
success, a value persists after refresh, or a visible status changes.
|
|
49
|
+
5. Interact with `click`, `fill`, `type`, `press`, `select`, or `check`.
|
|
50
|
+
Re-query after a detached-element/re-render failure; do not retry a stale
|
|
51
|
+
handle blindly. If a stable locator is unavailable, report that as a
|
|
52
|
+
product-testability finding.
|
|
53
|
+
6. Wait for the specific state, then capture post-action `observe_bundle` and
|
|
54
|
+
a focused DOM/text/a11y observation that proves the postcondition. Include
|
|
55
|
+
page errors, console errors, and failed network requests in the result.
|
|
56
|
+
7. Close by listing every requested interaction with its evidence outcome,
|
|
57
|
+
receipt/artifact references, and any precise remediation. Call
|
|
58
|
+
`task_complete` when the implementation work is done; verifier feedback is
|
|
59
|
+
advisory and must not be presented as a completion veto.
|
|
60
|
+
|
|
61
|
+
## Hardware and Permission Boundaries
|
|
62
|
+
|
|
63
|
+
Browser tests cannot manufacture physical hardware or permission grants.
|
|
64
|
+
Examples include WebSerial/WebUSB, camera/microphone permissions, native
|
|
65
|
+
dialogs, and payment approval. Mark these `blocked` or `not_applicable` with
|
|
66
|
+
the exact missing condition. Do not claim failure merely because headless
|
|
67
|
+
automation cannot exercise a physical-device path.
|
|
68
|
+
|
|
69
|
+
## Evidence Handoff Shape
|
|
70
|
+
|
|
71
|
+
```text
|
|
72
|
+
browser flow: fleet control
|
|
73
|
+
- passed: start simulation → button changed to "Stop Simulation"; post-action
|
|
74
|
+
DOM and screenshot captured.
|
|
75
|
+
- failed: select fleet → card detached during reactive re-render; stable
|
|
76
|
+
data-testid is missing, so a resilient locator cannot be formed.
|
|
77
|
+
- not_applicable: connect WebSerial → requires a USB CDC device and secure
|
|
78
|
+
user gesture; no physical device is attached to this browser session.
|
|
79
|
+
- static evidence: dashboard harness passed (does not prove the three flows).
|
|
80
|
+
```
|
|
81
|
+
|