jev-layer 0.1.0 → 0.2.0
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/CHANGELOG.md +45 -34
- package/CONTRIBUTING.md +146 -146
- package/LICENSE +21 -21
- package/README.md +123 -126
- package/README.ru.md +138 -117
- package/README.zh-CN.md +137 -117
- package/RELEASE.md +53 -53
- package/SECURITY.md +56 -56
- package/bin/jev.mjs +213 -213
- package/config/codex.mcp.toml +8 -8
- package/config/generic-mcp.json +13 -13
- package/config/hermes.mcp.yaml +9 -9
- package/config/jev.example.json +22 -22
- package/config/omp.mcp.json +14 -14
- package/config/providers.env.example +13 -13
- package/docs/AGENT-IMPLEMENTATION.md +250 -0
- package/docs/COMPATIBILITY.md +15 -15
- package/docs/HERMES-LOCAL-AGENT-HANDOFF.ru.md +177 -0
- package/docs/PROVIDERS.md +67 -0
- package/docs/SCHEMA-VERSIONING.md +96 -94
- package/docs/architecture.svg +77 -0
- package/docs/jev-layer-banner.svg +38 -0
- package/examples/capabilities.json +39 -39
- package/examples/route-request.json +28 -28
- package/integrations/codex/.codex-plugin/plugin.json +19 -19
- package/integrations/codex/.mcp.json +11 -11
- package/integrations/codex/AGENTS.md +1 -1
- package/integrations/codex/run-mcp.mjs +9 -9
- package/integrations/codex/skills/jev-route/SKILL.md +17 -17
- package/integrations/hermes/__init__.py +150 -51
- package/integrations/hermes/plugin.yaml +10 -5
- package/integrations/hermes/schemas.py +89 -12
- package/integrations/omp/extension.js +105 -105
- package/integrations/template/README.md +10 -10
- package/integrations/template/adapter.mjs +87 -87
- package/package.json +60 -59
- package/scripts/benchmark.mjs +35 -35
- package/scripts/browser-benchmark.mjs +92 -92
- package/scripts/browser-e2e.mjs +117 -117
- package/scripts/capability-e2e.mjs +31 -31
- package/scripts/clean-install-smoke.mjs +162 -162
- package/scripts/codex-mcp-smoke.mjs +119 -119
- package/scripts/context-filter-e2e.mjs +45 -45
- package/scripts/fail-open-smoke.mjs +120 -120
- package/scripts/feature-flags-smoke.mjs +46 -46
- package/scripts/mcp-receipt-smoke.mjs +113 -98
- package/scripts/model-route-report.mjs +15 -0
- package/scripts/openrouter-choice.mjs +59 -59
- package/scripts/replay-eval.mjs +124 -124
- package/scripts/smoke.mjs +34 -34
- package/scripts/supervision-e2e.mjs +138 -109
- package/src/browser.mjs +571 -569
- package/src/cli.mjs +33 -33
- package/src/config.mjs +85 -75
- package/src/context-filter.mjs +56 -56
- package/src/contract.mjs +72 -72
- package/src/discovery.mjs +65 -65
- package/src/hermes-adapter.mjs +123 -0
- package/src/mcp-server.mjs +267 -210
- package/src/model-route-metrics.mjs +89 -0
- package/src/model-routing.mjs +87 -0
- package/src/providers/demo.mjs +52 -52
- package/src/providers/index.mjs +12 -0
- package/src/providers/typesafe.mjs +126 -126
- package/src/receipts.mjs +227 -226
- package/src/registry.mjs +109 -109
- package/src/relevance-filter.mjs +99 -99
- package/src/route.mjs +219 -221
- package/src/shadow-compaction.mjs +170 -0
- package/src/supervision.mjs +268 -244
- package/test/browser.test.mjs +199 -199
- package/test/capability.test.mjs +54 -54
- package/test/context-filter.test.mjs +65 -65
- package/test/hermes-adapter.test.mjs +62 -0
- package/test/model-route-metrics.test.mjs +61 -0
- package/test/model-routing.test.mjs +59 -0
- package/test/openrouter-provider.test.mjs +55 -55
- package/test/provider-transports.test.mjs +205 -0
- package/test/providers.test.mjs +126 -0
- package/test/receipts.test.mjs +71 -71
- package/test/route.test.mjs +74 -74
- package/test/shadow-compaction.test.mjs +67 -0
- package/test/supervision.test.mjs +117 -99
package/CHANGELOG.md
CHANGED
|
@@ -1,34 +1,45 @@
|
|
|
1
|
-
# Changelog
|
|
2
|
-
|
|
3
|
-
All notable changes to jev-layer are recorded here. Entries describe public behavior and compatibility impact; provider-specific experiments are listed only when they affect a public contract.
|
|
4
|
-
|
|
5
|
-
##
|
|
6
|
-
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
10
|
-
|
|
11
|
-
-
|
|
12
|
-
-
|
|
13
|
-
|
|
14
|
-
|
|
15
|
-
|
|
16
|
-
|
|
17
|
-
|
|
18
|
-
|
|
19
|
-
|
|
20
|
-
|
|
21
|
-
|
|
22
|
-
|
|
23
|
-
-
|
|
24
|
-
-
|
|
25
|
-
-
|
|
26
|
-
-
|
|
27
|
-
|
|
28
|
-
|
|
29
|
-
|
|
30
|
-
-
|
|
31
|
-
|
|
32
|
-
|
|
33
|
-
|
|
34
|
-
|
|
1
|
+
# Changelog
|
|
2
|
+
|
|
3
|
+
All notable changes to jev-layer are recorded here. Entries describe public behavior and compatibility impact; provider-specific experiments are listed only when they affect a public contract.
|
|
4
|
+
|
|
5
|
+
## Unreleased
|
|
6
|
+
|
|
7
|
+
### Fixed
|
|
8
|
+
|
|
9
|
+
- Route `typesafe` through the official System One provider; share provider resolution with supervision and preserve fail-open decisions for unsupported providers.
|
|
10
|
+
- Apply configured provider environment names in CLI/MCP, including supervision and browser decisions; let Hermes/OMP honor project provider selection.
|
|
11
|
+
- Send OpenRouter's optional app title and record the configured model in provider metadata; allow the Hermes process to outlive the provider HTTP timeout.
|
|
12
|
+
- Cover demo, OpenRouter, and TypeSafe routing with offline provider and CLI/MCP/adapter regression checks; document setup and configuration precedence.
|
|
13
|
+
|
|
14
|
+
## [0.1.0]
|
|
15
|
+
|
|
16
|
+
First public-release candidate. This version is prepared but has not been pushed, released on GitHub, or published to npm.
|
|
17
|
+
|
|
18
|
+
### Added
|
|
19
|
+
|
|
20
|
+
- Portable CLI and stdio MCP routing layer for Hermes, OMP, Codex, and generic MCP-compatible agents.
|
|
21
|
+
- Closed-set capability routing through `jev_route` with deterministic host-side policy checks.
|
|
22
|
+
- `jev_record_execution` and append-only JSONL routing/execution receipts joined by `correlation_id`.
|
|
23
|
+
- Offline replay/evaluation without host execution calls.
|
|
24
|
+
- Opt-in supervision judgments with deterministic host policy.
|
|
25
|
+
- Opt-in, report-only `jev_model_route` with correlated execution outcomes and a local evidence report.
|
|
26
|
+
- Hermes plugin integration with profile-scoped OpenRouter secret resolution, replay receipts, model-route correlation, and a local-agent handoff guide.
|
|
27
|
+
- Opt-in deterministic context filtering (`shadow` and `conservative`).
|
|
28
|
+
- Explicit capability discovery for skills, MCP, CLI, DSH, tools, subagents, and models.
|
|
29
|
+
- Experimental, opt-in browser fast-path over host-supplied observations.
|
|
30
|
+
- MIT license, security policy, schema/version policy, contribution guide, adapter template, CI, and multilingual README documentation.
|
|
31
|
+
|
|
32
|
+
### Compatibility
|
|
33
|
+
|
|
34
|
+
- Node.js `>=20`.
|
|
35
|
+
- Public request, decision, MCP tool, receipt, replay, and adapter contracts remain schema version 1.
|
|
36
|
+
- Release-preparation baseline: OMP `18.2.6`, Hermes `0.21.3` (`b675e6de`), and Codex CLI `0.155.1` observed in the preparation environment. See [docs/COMPATIBILITY.md](docs/COMPATIBILITY.md).
|
|
37
|
+
- Browser reliability is validated against the current real-browser fixtures; browser performance optimization remains experimental.
|
|
38
|
+
|
|
39
|
+
### Release constraints
|
|
40
|
+
|
|
41
|
+
- Host harnesses retain ownership of permissions, approvals, native execution, retries, recovery, and final results.
|
|
42
|
+
- Provider-backed tests require explicit secret-managed environments and are not required for ordinary PR CI.
|
|
43
|
+
- No npm publication, GitHub release, or remote push is part of this preparation.
|
|
44
|
+
|
|
45
|
+
Proposed repository: https://github.com/typakon4/jev-layer. GitHub release and comparison links become active after repository creation.
|
package/CONTRIBUTING.md
CHANGED
|
@@ -1,146 +1,146 @@
|
|
|
1
|
-
# Contributing to jev-layer
|
|
2
|
-
|
|
3
|
-
[English](README.md) | [Русский](README.ru.md) | [简体中文](README.zh-CN.md)
|
|
4
|
-
|
|
5
|
-
jev-layer is a portable System-1 decision layer. Contributions must preserve the rule that the host owns execution, permissions, approvals, retries, recovery, and final results. Jev returns bounded decisions; it does not become a security boundary or a second executor.
|
|
6
|
-
|
|
7
|
-
## Before opening a pull request
|
|
8
|
-
|
|
9
|
-
1. Read `SECURITY.md` and `docs/SCHEMA-VERSIONING.md`.
|
|
10
|
-
2. Keep the change narrow. Do not add runtime features while changing an adapter or documentation.
|
|
11
|
-
3. Add deterministic tests and an offline fixture. Provider-backed tests are optional and must not require secrets in ordinary CI.
|
|
12
|
-
4. Do not commit API keys, tokens, private keys, `.env` files, machine-specific paths, home directories, or local installation state.
|
|
13
|
-
5. Preserve existing schema v1 fields and fail-open behavior unless a versioned migration is part of the change.
|
|
14
|
-
|
|
15
|
-
## Adapter contract (version 1)
|
|
16
|
-
|
|
17
|
-
A harness adapter is a thin integration. It may use the CLI or stdio MCP, but it must preserve the following sequence:
|
|
18
|
-
|
|
19
|
-
| Stage | Required behavior |
|
|
20
|
-
| --- | --- |
|
|
21
|
-
| Capability discovery/input | Build a closed `capabilities[]` set from the host's known capabilities. Include stable `id`, `kind`, `name`, `description`, `permissions`, `risk`, and availability metadata where known. Do not ask Jev to discover or execute hidden host tools. |
|
|
22
|
-
| `jev_route` call | Send `schema_version: 1`, `harness`, `intent`, bounded `context`, `actor_permissions`, `capabilities`, and `policy` to `jev_route`. Preserve the returned `correlation_id` and selected capability id. |
|
|
23
|
-
| Host execution | Resolve the selected id through the harness's native registry. The adapter must not shell out to arbitrary ids, grant permissions, or replace native tool execution. |
|
|
24
|
-
| `jev_record_execution` receipt | After the host decides what happened, call `jev_record_execution` with the same `correlation_id`, `status` (`completed`, `failed`, or `not_started`), `capability_id`, bounded result/error, and optional exit/timing metadata. |
|
|
25
|
-
| Fail-open | If Jev is disabled, unavailable, times out, returns an error, or returns no usable selection, continue through the harness's normal native path. Never guess a capability or treat a Jev failure as permission to execute. |
|
|
26
|
-
| Approval semantics | The host remains the approval authority. Consequential actions require the host's normal approval before execution. A denial records `not_started`; Jev cannot approve, elevate, retry, or override the host. |
|
|
27
|
-
|
|
28
|
-
`jev_browser_step` follows the same ownership rule: the host supplies a structured observation, the host approves consequential browser actions, and the host executes or hands control back. It is experimental and opt-in.
|
|
29
|
-
|
|
30
|
-
### Minimal adapter pseudocode
|
|
31
|
-
|
|
32
|
-
```text
|
|
33
|
-
request = {
|
|
34
|
-
schema_version: 1,
|
|
35
|
-
harness: "my-harness",
|
|
36
|
-
intent: host_goal,
|
|
37
|
-
context: bounded_host_context,
|
|
38
|
-
actor_permissions: host_permissions,
|
|
39
|
-
capabilities: host_capabilities,
|
|
40
|
-
policy: host_policy
|
|
41
|
-
}
|
|
42
|
-
|
|
43
|
-
decision = call_jev_route(request)
|
|
44
|
-
|
|
45
|
-
if decision.status != "selected" or decision.selected is null:
|
|
46
|
-
return native_host_path(request)
|
|
47
|
-
|
|
48
|
-
if consequential(decision.selected) and not host_approval(decision.selected):
|
|
49
|
-
call_jev_record_execution({
|
|
50
|
-
correlation_id: decision.correlation_id,
|
|
51
|
-
capability_id: decision.selected,
|
|
52
|
-
status: "not_started",
|
|
53
|
-
error: "host approval denied"
|
|
54
|
-
})
|
|
55
|
-
return native_host_path(request)
|
|
56
|
-
|
|
57
|
-
try:
|
|
58
|
-
host_result = execute_native(decision.selected)
|
|
59
|
-
status = "completed"
|
|
60
|
-
except error:
|
|
61
|
-
host_result = null
|
|
62
|
-
status = "failed"
|
|
63
|
-
|
|
64
|
-
receipt = call_jev_record_execution({
|
|
65
|
-
correlation_id: decision.correlation_id,
|
|
66
|
-
capability_id: decision.selected,
|
|
67
|
-
status,
|
|
68
|
-
result: bounded(host_result),
|
|
69
|
-
error: bounded(error),
|
|
70
|
-
duration_ms: measured_duration
|
|
71
|
-
})
|
|
72
|
-
return { decision, host_result, receipt }
|
|
73
|
-
```
|
|
74
|
-
|
|
75
|
-
Copy `integrations/template/adapter.mjs` for a small JavaScript starting point with the same injected boundaries.
|
|
76
|
-
|
|
77
|
-
## Adding a new harness
|
|
78
|
-
|
|
79
|
-
The shortest supported PR path is:
|
|
80
|
-
|
|
81
|
-
1. Add `integrations/<harness>/` with a thin adapter that calls the existing CLI or MCP contract.
|
|
82
|
-
2. Add a secret-free config/example snippet under `config/` or the integration directory.
|
|
83
|
-
3. Add an offline smoke fixture proving route, fail-open, approval denial, host execution, and execution receipt behavior.
|
|
84
|
-
4. Register compatibility in `README.md`, the translated READMEs, `docs/SCHEMA-VERSIONING.md`, and `RELEASE.md` when the harness is supported.
|
|
85
|
-
5. Run the required CI commands and submit the PR.
|
|
86
|
-
|
|
87
|
-
Do not add a harness-specific routing implementation. Keep configuration user-owned; never overwrite global harness settings.
|
|
88
|
-
|
|
89
|
-
## Adding a provider
|
|
90
|
-
|
|
91
|
-
Providers implement the existing provider surface in `src/providers/`: a `name` and an async `decide({ state, candidates })` method. Supervision-capable providers may also implement `evaluate({ state, questions })`. Return the normalized provider response expected by `src/route.mjs`; do not execute capabilities in the provider.
|
|
92
|
-
|
|
93
|
-
- Add the provider to explicit configuration/selection only when it is usable offline or clearly fails open.
|
|
94
|
-
- Add deterministic unit tests using injected responses or the `demo` provider.
|
|
95
|
-
- Keep API keys and endpoints in environment variables or user-owned configuration.
|
|
96
|
-
- Provider-backed tests belong in secret-managed CI, not ordinary pull-request CI.
|
|
97
|
-
|
|
98
|
-
## Adding a discovery source
|
|
99
|
-
|
|
100
|
-
Use `discoverCapabilities()` and the normalized capability shape in `src/discovery.mjs`. A new source must:
|
|
101
|
-
|
|
102
|
-
- produce stable, namespaced ids;
|
|
103
|
-
- preserve `kind`, `name`, `description`, `source`, `verified`, and availability metadata;
|
|
104
|
-
- deduplicate by id deterministically;
|
|
105
|
-
- read only explicit input or an explicitly supplied manifest path;
|
|
106
|
-
- never scan undocumented global locations or execute discovered entries.
|
|
107
|
-
|
|
108
|
-
Add a fixture covering empty input, malformed entries, duplicate ids, unavailable entries, and the new source's normalized output.
|
|
109
|
-
|
|
110
|
-
## Adding a browser executor
|
|
111
|
-
|
|
112
|
-
Browser executors are host-owned and optional. Implement `observe()` plus `execute(action)`, and implement `select(action)` when the host has a native select mechanism. The observation must be bounded and structured; the executor must validate target ids, preserve host approval, return the next observation, and report failures without retrying implicitly. Do not add screenshots, text entry, browser workers, or permission logic to jev-layer as part of an executor contribution.
|
|
113
|
-
|
|
114
|
-
## Adding an eval or replay fixture
|
|
115
|
-
|
|
116
|
-
Add a small JSONL or JSON fixture under `examples/` or a test fixture directory. Include a stable `schema_version`, `harness`, bounded capabilities, and deterministic expected selection/fallback behavior. For receipts, use one `correlation_id` for the routing case and execution receipt. Exercise it with:
|
|
117
|
-
|
|
118
|
-
```sh
|
|
119
|
-
npm run replay:evaluate -- --provider demo --limit 20
|
|
120
|
-
npm test
|
|
121
|
-
```
|
|
122
|
-
|
|
123
|
-
A fixture must not call a real provider, host command, network service, or browser. If a real-provider scenario is useful, document it separately and gate it on an explicitly supplied secret.
|
|
124
|
-
|
|
125
|
-
## Required checks
|
|
126
|
-
|
|
127
|
-
From a clean checkout:
|
|
128
|
-
|
|
129
|
-
```sh
|
|
130
|
-
npm install
|
|
131
|
-
npm test
|
|
132
|
-
npm run smoke
|
|
133
|
-
npm run fail-open-smoke
|
|
134
|
-
npm run clean-install-smoke
|
|
135
|
-
npm pack --dry-run
|
|
136
|
-
```
|
|
137
|
-
|
|
138
|
-
Changes touching browser, supervision, context filtering, discovery, or MCP should also run the matching existing E2E/smoke script. CI does not require provider credentials.
|
|
139
|
-
|
|
140
|
-
## Backward compatibility
|
|
141
|
-
|
|
142
|
-
- Keep schema v1 request, decision, receipt, and replay fields readable.
|
|
143
|
-
- Prefer additive optional fields. Do not rename or remove existing fields in a patch release.
|
|
144
|
-
- Preserve `correlation_id` across route and execution records.
|
|
145
|
-
- Preserve fail-open behavior and host approval ownership.
|
|
146
|
-
- If a breaking contract is unavoidable, document a new schema/adapter version and migration before changing the implementation.
|
|
1
|
+
# Contributing to jev-layer
|
|
2
|
+
|
|
3
|
+
[English](README.md) | [Русский](README.ru.md) | [简体中文](README.zh-CN.md)
|
|
4
|
+
|
|
5
|
+
jev-layer is a portable System-1 decision layer. Contributions must preserve the rule that the host owns execution, permissions, approvals, retries, recovery, and final results. Jev returns bounded decisions; it does not become a security boundary or a second executor.
|
|
6
|
+
|
|
7
|
+
## Before opening a pull request
|
|
8
|
+
|
|
9
|
+
1. Read `SECURITY.md` and `docs/SCHEMA-VERSIONING.md`.
|
|
10
|
+
2. Keep the change narrow. Do not add runtime features while changing an adapter or documentation.
|
|
11
|
+
3. Add deterministic tests and an offline fixture. Provider-backed tests are optional and must not require secrets in ordinary CI.
|
|
12
|
+
4. Do not commit API keys, tokens, private keys, `.env` files, machine-specific paths, home directories, or local installation state.
|
|
13
|
+
5. Preserve existing schema v1 fields and fail-open behavior unless a versioned migration is part of the change.
|
|
14
|
+
|
|
15
|
+
## Adapter contract (version 1)
|
|
16
|
+
|
|
17
|
+
A harness adapter is a thin integration. It may use the CLI or stdio MCP, but it must preserve the following sequence:
|
|
18
|
+
|
|
19
|
+
| Stage | Required behavior |
|
|
20
|
+
| --- | --- |
|
|
21
|
+
| Capability discovery/input | Build a closed `capabilities[]` set from the host's known capabilities. Include stable `id`, `kind`, `name`, `description`, `permissions`, `risk`, and availability metadata where known. Do not ask Jev to discover or execute hidden host tools. |
|
|
22
|
+
| `jev_route` call | Send `schema_version: 1`, `harness`, `intent`, bounded `context`, `actor_permissions`, `capabilities`, and `policy` to `jev_route`. Preserve the returned `correlation_id` and selected capability id. |
|
|
23
|
+
| Host execution | Resolve the selected id through the harness's native registry. The adapter must not shell out to arbitrary ids, grant permissions, or replace native tool execution. |
|
|
24
|
+
| `jev_record_execution` receipt | After the host decides what happened, call `jev_record_execution` with the same `correlation_id`, `status` (`completed`, `failed`, or `not_started`), `capability_id`, bounded result/error, and optional exit/timing metadata. |
|
|
25
|
+
| Fail-open | If Jev is disabled, unavailable, times out, returns an error, or returns no usable selection, continue through the harness's normal native path. Never guess a capability or treat a Jev failure as permission to execute. |
|
|
26
|
+
| Approval semantics | The host remains the approval authority. Consequential actions require the host's normal approval before execution. A denial records `not_started`; Jev cannot approve, elevate, retry, or override the host. |
|
|
27
|
+
|
|
28
|
+
`jev_browser_step` follows the same ownership rule: the host supplies a structured observation, the host approves consequential browser actions, and the host executes or hands control back. It is experimental and opt-in.
|
|
29
|
+
|
|
30
|
+
### Minimal adapter pseudocode
|
|
31
|
+
|
|
32
|
+
```text
|
|
33
|
+
request = {
|
|
34
|
+
schema_version: 1,
|
|
35
|
+
harness: "my-harness",
|
|
36
|
+
intent: host_goal,
|
|
37
|
+
context: bounded_host_context,
|
|
38
|
+
actor_permissions: host_permissions,
|
|
39
|
+
capabilities: host_capabilities,
|
|
40
|
+
policy: host_policy
|
|
41
|
+
}
|
|
42
|
+
|
|
43
|
+
decision = call_jev_route(request)
|
|
44
|
+
|
|
45
|
+
if decision.status != "selected" or decision.selected is null:
|
|
46
|
+
return native_host_path(request)
|
|
47
|
+
|
|
48
|
+
if consequential(decision.selected) and not host_approval(decision.selected):
|
|
49
|
+
call_jev_record_execution({
|
|
50
|
+
correlation_id: decision.correlation_id,
|
|
51
|
+
capability_id: decision.selected,
|
|
52
|
+
status: "not_started",
|
|
53
|
+
error: "host approval denied"
|
|
54
|
+
})
|
|
55
|
+
return native_host_path(request)
|
|
56
|
+
|
|
57
|
+
try:
|
|
58
|
+
host_result = execute_native(decision.selected)
|
|
59
|
+
status = "completed"
|
|
60
|
+
except error:
|
|
61
|
+
host_result = null
|
|
62
|
+
status = "failed"
|
|
63
|
+
|
|
64
|
+
receipt = call_jev_record_execution({
|
|
65
|
+
correlation_id: decision.correlation_id,
|
|
66
|
+
capability_id: decision.selected,
|
|
67
|
+
status,
|
|
68
|
+
result: bounded(host_result),
|
|
69
|
+
error: bounded(error),
|
|
70
|
+
duration_ms: measured_duration
|
|
71
|
+
})
|
|
72
|
+
return { decision, host_result, receipt }
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
Copy `integrations/template/adapter.mjs` for a small JavaScript starting point with the same injected boundaries.
|
|
76
|
+
|
|
77
|
+
## Adding a new harness
|
|
78
|
+
|
|
79
|
+
The shortest supported PR path is:
|
|
80
|
+
|
|
81
|
+
1. Add `integrations/<harness>/` with a thin adapter that calls the existing CLI or MCP contract.
|
|
82
|
+
2. Add a secret-free config/example snippet under `config/` or the integration directory.
|
|
83
|
+
3. Add an offline smoke fixture proving route, fail-open, approval denial, host execution, and execution receipt behavior.
|
|
84
|
+
4. Register compatibility in `README.md`, the translated READMEs, `docs/SCHEMA-VERSIONING.md`, and `RELEASE.md` when the harness is supported.
|
|
85
|
+
5. Run the required CI commands and submit the PR.
|
|
86
|
+
|
|
87
|
+
Do not add a harness-specific routing implementation. Keep configuration user-owned; never overwrite global harness settings.
|
|
88
|
+
|
|
89
|
+
## Adding a provider
|
|
90
|
+
|
|
91
|
+
Providers implement the existing provider surface in `src/providers/`: a `name` and an async `decide({ state, candidates })` method. Supervision-capable providers may also implement `evaluate({ state, questions })`. Return the normalized provider response expected by `src/route.mjs`; do not execute capabilities in the provider.
|
|
92
|
+
|
|
93
|
+
- Add the provider to explicit configuration/selection only when it is usable offline or clearly fails open.
|
|
94
|
+
- Add deterministic unit tests using injected responses or the `demo` provider.
|
|
95
|
+
- Keep API keys and endpoints in environment variables or user-owned configuration.
|
|
96
|
+
- Provider-backed tests belong in secret-managed CI, not ordinary pull-request CI.
|
|
97
|
+
|
|
98
|
+
## Adding a discovery source
|
|
99
|
+
|
|
100
|
+
Use `discoverCapabilities()` and the normalized capability shape in `src/discovery.mjs`. A new source must:
|
|
101
|
+
|
|
102
|
+
- produce stable, namespaced ids;
|
|
103
|
+
- preserve `kind`, `name`, `description`, `source`, `verified`, and availability metadata;
|
|
104
|
+
- deduplicate by id deterministically;
|
|
105
|
+
- read only explicit input or an explicitly supplied manifest path;
|
|
106
|
+
- never scan undocumented global locations or execute discovered entries.
|
|
107
|
+
|
|
108
|
+
Add a fixture covering empty input, malformed entries, duplicate ids, unavailable entries, and the new source's normalized output.
|
|
109
|
+
|
|
110
|
+
## Adding a browser executor
|
|
111
|
+
|
|
112
|
+
Browser executors are host-owned and optional. Implement `observe()` plus `execute(action)`, and implement `select(action)` when the host has a native select mechanism. The observation must be bounded and structured; the executor must validate target ids, preserve host approval, return the next observation, and report failures without retrying implicitly. Do not add screenshots, text entry, browser workers, or permission logic to jev-layer as part of an executor contribution.
|
|
113
|
+
|
|
114
|
+
## Adding an eval or replay fixture
|
|
115
|
+
|
|
116
|
+
Add a small JSONL or JSON fixture under `examples/` or a test fixture directory. Include a stable `schema_version`, `harness`, bounded capabilities, and deterministic expected selection/fallback behavior. For receipts, use one `correlation_id` for the routing case and execution receipt. Exercise it with:
|
|
117
|
+
|
|
118
|
+
```sh
|
|
119
|
+
npm run replay:evaluate -- --provider demo --limit 20
|
|
120
|
+
npm test
|
|
121
|
+
```
|
|
122
|
+
|
|
123
|
+
A fixture must not call a real provider, host command, network service, or browser. If a real-provider scenario is useful, document it separately and gate it on an explicitly supplied secret.
|
|
124
|
+
|
|
125
|
+
## Required checks
|
|
126
|
+
|
|
127
|
+
From a clean checkout:
|
|
128
|
+
|
|
129
|
+
```sh
|
|
130
|
+
npm install
|
|
131
|
+
npm test
|
|
132
|
+
npm run smoke
|
|
133
|
+
npm run fail-open-smoke
|
|
134
|
+
npm run clean-install-smoke
|
|
135
|
+
npm pack --dry-run
|
|
136
|
+
```
|
|
137
|
+
|
|
138
|
+
Changes touching browser, supervision, context filtering, discovery, or MCP should also run the matching existing E2E/smoke script. CI does not require provider credentials.
|
|
139
|
+
|
|
140
|
+
## Backward compatibility
|
|
141
|
+
|
|
142
|
+
- Keep schema v1 request, decision, receipt, and replay fields readable.
|
|
143
|
+
- Prefer additive optional fields. Do not rename or remove existing fields in a patch release.
|
|
144
|
+
- Preserve `correlation_id` across route and execution records.
|
|
145
|
+
- Preserve fail-open behavior and host approval ownership.
|
|
146
|
+
- If a breaking contract is unavoidable, document a new schema/adapter version and migration before changing the implementation.
|
package/LICENSE
CHANGED
|
@@ -1,21 +1,21 @@
|
|
|
1
|
-
MIT License
|
|
2
|
-
|
|
3
|
-
Copyright (c) 2026 jev-layer contributors
|
|
4
|
-
|
|
5
|
-
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
-
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
-
in the Software without restriction, including without limitation the rights
|
|
8
|
-
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
-
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
-
furnished to do so, subject to the following conditions:
|
|
11
|
-
|
|
12
|
-
The above copyright notice and this permission notice shall be included in all
|
|
13
|
-
copies or substantial portions of the Software.
|
|
14
|
-
|
|
15
|
-
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
-
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
-
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
-
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
-
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
-
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
-
SOFTWARE.
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 jev-layer contributors
|
|
4
|
+
|
|
5
|
+
Permission is hereby granted, free of charge, to any person obtaining a copy
|
|
6
|
+
of this software and associated documentation files (the "Software"), to deal
|
|
7
|
+
in the Software without restriction, including without limitation the rights
|
|
8
|
+
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
|
9
|
+
copies of the Software, and to permit persons to whom the Software is
|
|
10
|
+
furnished to do so, subject to the following conditions:
|
|
11
|
+
|
|
12
|
+
The above copyright notice and this permission notice shall be included in all
|
|
13
|
+
copies or substantial portions of the Software.
|
|
14
|
+
|
|
15
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
16
|
+
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
17
|
+
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
|
18
|
+
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
19
|
+
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
|
20
|
+
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
|
21
|
+
SOFTWARE.
|