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.
@@ -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
+