omnius 1.0.589 → 1.0.591
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.
- package/.aiwg/addons/omnius-docs/README.md +2 -0
- package/.aiwg/addons/omnius-docs/manifest.json +35 -0
- package/.aiwg/addons/omnius-docs/skills/agent-failure-recovery/SKILL.md +23 -0
- package/.aiwg/addons/omnius-docs/skills/evidence-directed-delivery/SKILL.md +63 -0
- package/.aiwg/addons/omnius-docs/skills/hardware-evidence-audit/SKILL.md +25 -0
- package/.aiwg/addons/omnius-docs/skills/runtime-provenance-audit/SKILL.md +20 -0
- package/.aiwg/addons/omnius-docs/skills/secrets-and-config-audit/SKILL.md +22 -0
- package/.aiwg/addons/omnius-docs/skills/test-surface-audit/SKILL.md +22 -0
- package/.aiwg/addons/omnius-docs/skills/workspace-reality-audit/SKILL.md +24 -0
- package/dist/index.js +4408 -3211
- package/npm-shrinkwrap.json +16 -16
- package/package.json +1 -1
|
@@ -3,3 +3,5 @@
|
|
|
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
5
|
Start with `omnius-docs`, then load a more specific skill when the task is about realtime, sponsors, Telegram, operations, or browser interaction validation.
|
|
6
|
+
|
|
7
|
+
For cross-cutting delivery work, the add-on also exposes `evidence-directed-delivery`, `workspace-reality-audit`, `test-surface-audit`, `runtime-provenance-audit`, `hardware-evidence-audit`, `secrets-and-config-audit`, and `agent-failure-recovery`. These skills are feedback-oriented: they help an agent discover evidence gaps and recover from actual failures without treating planning telemetry as a completion veto.
|
|
@@ -32,6 +32,41 @@
|
|
|
32
32
|
"name": "browser-interaction-validation",
|
|
33
33
|
"description": "Validate a user-facing browser flow with canonical Playwright interactions, postconditions, diagnostics, and honest blocked/not-applicable evidence.",
|
|
34
34
|
"triggers": ["browser interaction validation", "UI interaction test", "Playwright validation", "browser flow", "dashboard validation", "form interaction"]
|
|
35
|
+
},
|
|
36
|
+
{
|
|
37
|
+
"name": "evidence-directed-delivery",
|
|
38
|
+
"description": "Use generic claim/evidence, anti-reward-hacking, bounded recovery, and feedback-only completion rules for non-trivial work.",
|
|
39
|
+
"triggers": ["evidence based completion", "delivery audit", "completion evidence", "verify claims", "remaining gaps"]
|
|
40
|
+
},
|
|
41
|
+
{
|
|
42
|
+
"name": "workspace-reality-audit",
|
|
43
|
+
"description": "Audit repository truth, generated artifacts, documentation drift, and delivery ownership before claiming progress.",
|
|
44
|
+
"triggers": ["workspace audit", "repository reality", "stale artifact", "untracked source", "documentation drift"]
|
|
45
|
+
},
|
|
46
|
+
{
|
|
47
|
+
"name": "test-surface-audit",
|
|
48
|
+
"description": "Map canonical tests to claims and expose placeholder, mock-only, copied-logic, and un-wired verification gaps.",
|
|
49
|
+
"triggers": ["test audit", "test coverage", "test surface", "canonical test", "mock only"]
|
|
50
|
+
},
|
|
51
|
+
{
|
|
52
|
+
"name": "runtime-provenance-audit",
|
|
53
|
+
"description": "Prove active process, artifact, port, configuration, and restart/update ownership for runtime claims.",
|
|
54
|
+
"triggers": ["runtime provenance", "deployed version", "process audit", "service ownership", "running artifact"]
|
|
55
|
+
},
|
|
56
|
+
{
|
|
57
|
+
"name": "hardware-evidence-audit",
|
|
58
|
+
"description": "Classify static, simulation, integration, and physical-device evidence without overstating hardware proof.",
|
|
59
|
+
"triggers": ["hardware validation", "device evidence", "simulation versus hardware", "firmware test", "physical device"]
|
|
60
|
+
},
|
|
61
|
+
{
|
|
62
|
+
"name": "secrets-and-config-audit",
|
|
63
|
+
"description": "Audit credential and configuration provenance without exposing secret values.",
|
|
64
|
+
"triggers": ["secret audit", "credential provenance", "endpoint credential", "configuration security"]
|
|
65
|
+
},
|
|
66
|
+
{
|
|
67
|
+
"name": "agent-failure-recovery",
|
|
68
|
+
"description": "Convert failed calls into bounded, evidence-backed recovery actions and stop blind retries.",
|
|
69
|
+
"triggers": ["recover tool failure", "stale hash", "unknown tool", "retry loop", "agent recovery"]
|
|
35
70
|
}
|
|
36
71
|
]
|
|
37
72
|
}
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
---
|
|
2
|
+
compaction_strategy: structured
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# agent-failure-recovery
|
|
6
|
+
|
|
7
|
+
Use after a failed tool, rejected mutation, unknown capability, stale hash,
|
|
8
|
+
timeout, or contradictory evidence.
|
|
9
|
+
|
|
10
|
+
## Procedure
|
|
11
|
+
|
|
12
|
+
1. Preserve the raw failure and classify it: retryable, blocked, permanent, or
|
|
13
|
+
unknown.
|
|
14
|
+
2. Name the authoritative state needed to change strategy. For a stale edit,
|
|
15
|
+
re-read the target; for an unavailable tool, inspect the capability contract;
|
|
16
|
+
for a failed verifier, inspect its exact diagnostic.
|
|
17
|
+
3. Create one recovery action with evidence requirements and an exit condition.
|
|
18
|
+
4. Retry only after a distinct observation or correction. Do not repeat an
|
|
19
|
+
identical failure.
|
|
20
|
+
5. Resolve the failure only with evidence that addresses the same tool family,
|
|
21
|
+
claim, and current state. Keep it as feedback; do not use it as a terminal
|
|
22
|
+
completion gate.
|
|
23
|
+
|
|
@@ -0,0 +1,63 @@
|
|
|
1
|
+
---
|
|
2
|
+
compaction_strategy: structured
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# evidence-directed-delivery
|
|
6
|
+
|
|
7
|
+
Use this skill for any non-trivial implementation, diagnosis, review, release,
|
|
8
|
+
or completion claim. It keeps the agent oriented to observed system state
|
|
9
|
+
without making verification a veto on `task_complete`.
|
|
10
|
+
|
|
11
|
+
## Required operating contract
|
|
12
|
+
|
|
13
|
+
1. Start with a bounded, read-only discovery pass. Inspect only surfaces
|
|
14
|
+
relevant to the request: workspace, build/test, runtime, delivery boundary,
|
|
15
|
+
configuration/security, and existing failures.
|
|
16
|
+
2. State which observations are direct evidence and which are only proxies.
|
|
17
|
+
Source edits, command exit codes, screenshots, simulations, and task
|
|
18
|
+
completion are not proof by themselves.
|
|
19
|
+
3. For every material claim, identify the most likely counterexample and check
|
|
20
|
+
it when the capability is available and in scope.
|
|
21
|
+
4. Classify each result as `verified`, `unverified`, `contradicted`, or
|
|
22
|
+
`blocked`. Preserve failed and inconclusive evidence until newer evidence
|
|
23
|
+
addresses the same claim and state.
|
|
24
|
+
5. `task_complete` remains callable. Before calling it, provide the main loop
|
|
25
|
+
structured feedback: verified claims, unverified claims, contradictions,
|
|
26
|
+
active recovery items, and surfaces not checked.
|
|
27
|
+
|
|
28
|
+
## Anti-reward-hacking rules
|
|
29
|
+
|
|
30
|
+
- Do not use “fixed”, “complete”, “verified”, “deployed”, “healthy”, or
|
|
31
|
+
“end-to-end” unless the corresponding claim has fresh, scope-matched
|
|
32
|
+
evidence.
|
|
33
|
+
- Do not count tool volume, todo volume, created files, plans, or persuasive
|
|
34
|
+
prose as implementation evidence.
|
|
35
|
+
- Do not convert simulation or mock evidence into real-device evidence.
|
|
36
|
+
- Do not hide a failed tool call because a later unrelated check passed.
|
|
37
|
+
- Do not retry the same failure unchanged. Classify it, inspect authoritative
|
|
38
|
+
state, choose a distinct recovery action, and retry once only when justified.
|
|
39
|
+
|
|
40
|
+
## Capability contract
|
|
41
|
+
|
|
42
|
+
Use only tools in the current schema or `[RUNTIME CAPABILITY CONTRACT v1]`.
|
|
43
|
+
When a tool is unavailable, read its structured recovery output, use an
|
|
44
|
+
advertised equivalent if present, and do not repeat the unavailable call.
|
|
45
|
+
|
|
46
|
+
## Handoff shape
|
|
47
|
+
|
|
48
|
+
```text
|
|
49
|
+
claim: active artifact contains the change
|
|
50
|
+
- status: verified
|
|
51
|
+
- evidence: current executable hash matched built artifact
|
|
52
|
+
- counter-check: process path and working directory inspected
|
|
53
|
+
|
|
54
|
+
claim: device path works
|
|
55
|
+
- status: unverified
|
|
56
|
+
- evidence: simulation harness passed
|
|
57
|
+
- boundary: no physical device/transport observation was available
|
|
58
|
+
|
|
59
|
+
recovery: stale edit target
|
|
60
|
+
- status: resolved
|
|
61
|
+
- evidence: re-read current target, rebuilt the edit, then ran a fresh verifier
|
|
62
|
+
```
|
|
63
|
+
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
---
|
|
2
|
+
compaction_strategy: structured
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# hardware-evidence-audit
|
|
6
|
+
|
|
7
|
+
Use for physical-device, transport, firmware, sensor, accelerator, or browser
|
|
8
|
+
permission claims.
|
|
9
|
+
|
|
10
|
+
## Evidence ladder
|
|
11
|
+
|
|
12
|
+
Classify every relevant result exactly once:
|
|
13
|
+
|
|
14
|
+
- static source inspection
|
|
15
|
+
- mock or simulation
|
|
16
|
+
- emulator or software-in-the-loop
|
|
17
|
+
- integration against a live service
|
|
18
|
+
- connected physical device
|
|
19
|
+
- production/field observation
|
|
20
|
+
|
|
21
|
+
Never promote an item to a higher level without a fresh observation at that
|
|
22
|
+
level. Before live local inference or hardware work, follow the project’s
|
|
23
|
+
hardware preflight rules. If the required device, endpoint, permission, or
|
|
24
|
+
accelerator cannot be proven, report `blocked` or `not_applicable`.
|
|
25
|
+
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
---
|
|
2
|
+
compaction_strategy: structured
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# runtime-provenance-audit
|
|
6
|
+
|
|
7
|
+
Use for any claim about a running service, deployed code, background worker,
|
|
8
|
+
port, endpoint, or update.
|
|
9
|
+
|
|
10
|
+
## Procedure
|
|
11
|
+
|
|
12
|
+
1. Inspect active process identity, executable/module path, version or hash,
|
|
13
|
+
working directory, start time, and active listener/port.
|
|
14
|
+
2. Compare the active artifact with the intended built artifact. Source state
|
|
15
|
+
alone cannot satisfy this claim.
|
|
16
|
+
3. Identify service ownership, restart/update procedure, configuration origin,
|
|
17
|
+
and whether a process is project-supervised or ad hoc.
|
|
18
|
+
4. Report unavailable access as `blocked` or `unverified`, never as a failed
|
|
19
|
+
implementation claim.
|
|
20
|
+
|
|
@@ -0,0 +1,22 @@
|
|
|
1
|
+
---
|
|
2
|
+
compaction_strategy: structured
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# secrets-and-config-audit
|
|
6
|
+
|
|
7
|
+
Use before remote inference, deployment, endpoint changes, or when inspecting
|
|
8
|
+
configuration provenance.
|
|
9
|
+
|
|
10
|
+
## Procedure
|
|
11
|
+
|
|
12
|
+
1. Discover whether required credential sources exist without displaying their
|
|
13
|
+
values. Prefer a named environment/credential reference over raw settings.
|
|
14
|
+
2. Inspect tracked and ignored configuration separately; ignored state can
|
|
15
|
+
still be an operational or security finding.
|
|
16
|
+
3. Never print tokens, authorization headers, secret values, or full URLs that
|
|
17
|
+
embed credentials.
|
|
18
|
+
4. For remote inference, record endpoint, exact model identifier, credential
|
|
19
|
+
source indicator, timestamp, and non-secret receipt only.
|
|
20
|
+
5. Treat 401/403, unavailable models, or changed free/pricing status as a
|
|
21
|
+
configuration outcome requiring action—not an invitation to retry blindly.
|
|
22
|
+
|
|
@@ -0,0 +1,22 @@
|
|
|
1
|
+
---
|
|
2
|
+
compaction_strategy: structured
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# test-surface-audit
|
|
6
|
+
|
|
7
|
+
Use when a task changes behavior, claims a fix, or asks for release readiness.
|
|
8
|
+
|
|
9
|
+
## Procedure
|
|
10
|
+
|
|
11
|
+
1. Identify the canonical build and test commands from project manifests and
|
|
12
|
+
documentation. Flag placeholders and commands that intentionally fail.
|
|
13
|
+
2. Map each requested claim to source, unit, integration, browser, and
|
|
14
|
+
hardware evidence levels. State which level is actually exercised.
|
|
15
|
+
3. Check whether tests invoke production code or duplicate the implementation
|
|
16
|
+
under test. Copied protocol/decoder logic is a drift risk, not independent
|
|
17
|
+
proof.
|
|
18
|
+
4. Run only relevant safe checks, capture fresh results, and distinguish
|
|
19
|
+
passing execution from coverage of the requested behavior.
|
|
20
|
+
5. On failure, retain the exact diagnostic and create a distinct recovery
|
|
21
|
+
action; do not blanket-retry.
|
|
22
|
+
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
---
|
|
2
|
+
compaction_strategy: structured
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
# workspace-reality-audit
|
|
6
|
+
|
|
7
|
+
Use for discovery of repository and delivery gaps before implementation or a
|
|
8
|
+
completion claim.
|
|
9
|
+
|
|
10
|
+
## Procedure
|
|
11
|
+
|
|
12
|
+
1. Discover available read-only tools from the current capability contract.
|
|
13
|
+
2. Inspect tracked, modified, untracked, ignored, and generated paths.
|
|
14
|
+
3. Compare documentation claims with actual source and repository layout.
|
|
15
|
+
4. Compare changed source with generated artifacts by timestamp/hash where
|
|
16
|
+
applicable; do not infer a build occurred from an old artifact existing.
|
|
17
|
+
5. Report only observed gaps. An empty exploratory scan is an advisory, not a
|
|
18
|
+
missing-evidence failure unless the task explicitly named required artifacts.
|
|
19
|
+
|
|
20
|
+
## Output
|
|
21
|
+
|
|
22
|
+
For each finding emit: `status`, `evidence`, `impact`, `counter-check`, and
|
|
23
|
+
`smallest next action`. Keep workspace findings separate from runtime claims.
|
|
24
|
+
|