dsh-evokit 0.0.0-stage → 0.1.5
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/LICENSE +21 -0
- package/README.md +67 -2
- package/cordis.patch.yml +21 -0
- package/improver.patch.yml +26 -0
- package/mcp.json +10 -0
- package/package.json +33 -4
- package/plugin.json +11 -0
- package/skills/evolve/SKILL.md +101 -0
- package/skills/meta/SKILL.md +194 -0
- package/skills/onboard/SKILL.md +56 -0
package/LICENSE
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
MIT License
|
|
2
|
+
|
|
3
|
+
Copyright (c) 2026 Jiahao
|
|
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.
|
package/README.md
CHANGED
|
@@ -1,3 +1,68 @@
|
|
|
1
|
-
#
|
|
1
|
+
# evokit for DeepSeek Harness
|
|
2
2
|
|
|
3
|
-
|
|
3
|
+
The native DSH bundle adds evokit's stdio MCP tools and the `onboard`, `evolve`
|
|
4
|
+
and `meta` skills. Install Python and the wheel first. Compatibility is pinned to
|
|
5
|
+
DSH `0.2.2-rc.1`, Node 24 and DSH's pnpm prerequisite. Local runtime acceptance
|
|
6
|
+
uses Windows. Other platforms remain unverified.
|
|
7
|
+
|
|
8
|
+
## Install in an isolated profile
|
|
9
|
+
|
|
10
|
+
Download and verify `dsh_evokit-0.1.5-py3-none-any.whl`,
|
|
11
|
+
`dsh-evokit-0.1.5.tgz` and `SHA256SUMS` from the planned
|
|
12
|
+
[release page](https://github.com/edsml-jz2321/dsh-evokit/releases).
|
|
13
|
+
From PowerShell, with an existing scenario at `./my-system`:
|
|
14
|
+
|
|
15
|
+
```powershell
|
|
16
|
+
uv tool install ./dsh_evokit-0.1.5-py3-none-any.whl
|
|
17
|
+
$env:EVOKIT_MCP_COMMAND = (Get-Command evokit).Source
|
|
18
|
+
$env:EVOKIT_WORKSPACE = (Resolve-Path ./my-system).Path
|
|
19
|
+
$env:DSH_HOME = Join-Path (Get-Location) 'private-dsh/home'
|
|
20
|
+
$env:DSH_AGENTS_HOME = Join-Path (Get-Location) 'private-dsh/agents'
|
|
21
|
+
$env:HOME = $env:DSH_HOME
|
|
22
|
+
$env:USERPROFILE = $env:DSH_HOME
|
|
23
|
+
$env:DSH_TELEMETRY_DISABLED = '1'
|
|
24
|
+
$env:DSH_TELEMETRY_MODE = 'DISABLED'
|
|
25
|
+
dsh plugin --profile evokit add ./dsh-evokit-0.1.5.tgz
|
|
26
|
+
$env:EVOKIT_SKILL_ROOT = Join-Path $env:DSH_HOME 'profiles/evokit/node_modules/dsh-evokit/skills'
|
|
27
|
+
dsh plugin --profile evokit list
|
|
28
|
+
dsh --profile evokit --dump-config
|
|
29
|
+
```
|
|
30
|
+
|
|
31
|
+
Keep these variables for each launch. On other shells, set the same absolute
|
|
32
|
+
paths using the shell's environment syntax. The bundle does not install Python.
|
|
33
|
+
Package listing checks installation; `--dump-config` checks configuration without
|
|
34
|
+
starting an agent or making model requests.
|
|
35
|
+
|
|
36
|
+
## Configure your improver
|
|
37
|
+
|
|
38
|
+
Use your own provider key in DSH's local credential settings or a process-local
|
|
39
|
+
environment variable. Set the provider URL and model in your private DSH profile;
|
|
40
|
+
do not commit credentials. No particular gateway is required. For optional
|
|
41
|
+
file-key accounting, adapt [the relay example](../relay/README.md), set
|
|
42
|
+
`EVOKIT_IMPROVER_BASE_URL` to its loopback `/v1` endpoint and
|
|
43
|
+
`EVOKIT_RELAY_CLIENT_TOKEN` to its local client token, then apply
|
|
44
|
+
`improver.patch.yml` with `--patch`. Its model policy is an example, not a
|
|
45
|
+
universal provider default. Confirm model support and pricing before execution.
|
|
46
|
+
|
|
47
|
+
Run the `onboard` skill with the scenario's config path. The `evolve` skill
|
|
48
|
+
diagnoses and proposes; `meta` owns adoption, sealed confirmation and revert.
|
|
49
|
+
The default MCP profile excludes operator decisions. Configure a separate
|
|
50
|
+
`evokit mcp --profile operator` server for those decisions and protect its files
|
|
51
|
+
from the improver's direct access.
|
|
52
|
+
|
|
53
|
+
## Inspect tools without a model
|
|
54
|
+
|
|
55
|
+
The source includes `list-tools.mjs` and `list-tools.patch.yml`. Copy the overlay
|
|
56
|
+
to a private directory, replace `EVOKIT_TOOL_INSPECTOR_URI` with the module's file
|
|
57
|
+
URI, and pass it with `--patch`. It disables model adapters and credential services
|
|
58
|
+
and exits after comparing registered MCP tools against `evokit tools`.
|
|
59
|
+
|
|
60
|
+
## Add the market after publication
|
|
61
|
+
|
|
62
|
+
DSH ships no built-in plugin index. Enable **Custom plugin indexes**, open
|
|
63
|
+
**Discover → Add index source**, and enter:
|
|
64
|
+
`https://edsml-jz2321.github.io/dsh-evokit/index.json`.
|
|
65
|
+
This URL becomes available only after the publisher deploys market/.
|
|
66
|
+
The Git source pins the exported bundle subdirectory and a specific commit.
|
|
67
|
+
|
|
68
|
+
MIT; see [LICENSE](LICENSE).
|
package/cordis.patch.yml
ADDED
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
- insert:
|
|
2
|
+
- id: evokit-mcp
|
|
3
|
+
name: '@deepseek-ai/dsh-mcp-client'
|
|
4
|
+
config:
|
|
5
|
+
serverName: evokit
|
|
6
|
+
transport: stdio
|
|
7
|
+
command: !!js process.env.EVOKIT_MCP_COMMAND
|
|
8
|
+
args: [mcp]
|
|
9
|
+
cwd: !!js process.env.EVOKIT_WORKSPACE
|
|
10
|
+
startupTimeoutMs: 30000
|
|
11
|
+
toolCallTimeoutMs: 300000
|
|
12
|
+
failOnStartupError: true
|
|
13
|
+
reconnect:
|
|
14
|
+
enabled: false
|
|
15
|
+
- id: evokit-skills
|
|
16
|
+
name: '@deepseek-ai/dsh-skill-filesystem'
|
|
17
|
+
config:
|
|
18
|
+
providerName: evokit
|
|
19
|
+
includeDefaultRoots: false
|
|
20
|
+
customSkillDirs: !!js "[process.env.EVOKIT_SKILL_ROOT]"
|
|
21
|
+
watch: false
|
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
# Apply alongside cordis.patch.yml. Point this provider at the accounting relay.
|
|
2
|
+
# The deepseek-improver route injects thinking enabled and reasoning_effort high.
|
|
3
|
+
- id: llm-pi-ai
|
|
4
|
+
disabled: false
|
|
5
|
+
config:
|
|
6
|
+
providers:
|
|
7
|
+
evokit-improver:
|
|
8
|
+
api: openai-completions
|
|
9
|
+
baseURL: !!js process.env.EVOKIT_IMPROVER_BASE_URL
|
|
10
|
+
apiKeyEnv: EVOKIT_RELAY_CLIENT_TOKEN
|
|
11
|
+
retryPolicy: {mode: normal, maxRetries: 0}
|
|
12
|
+
reasoning: high
|
|
13
|
+
compat:
|
|
14
|
+
supportsDeveloperRole: false
|
|
15
|
+
maxTokensField: max_tokens
|
|
16
|
+
thinkingFormat: deepseek
|
|
17
|
+
models:
|
|
18
|
+
- id: deepseek-improver
|
|
19
|
+
contextWindow: 128000
|
|
20
|
+
maxTokens: 32768
|
|
21
|
+
input: [text]
|
|
22
|
+
reasoningEfforts: {high: high}
|
|
23
|
+
- id: agent-default-model
|
|
24
|
+
config:
|
|
25
|
+
provider: evokit-improver
|
|
26
|
+
model: deepseek-improver
|
package/mcp.json
ADDED
package/package.json
CHANGED
|
@@ -1,6 +1,35 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "dsh-evokit",
|
|
3
|
-
"version": "0.
|
|
4
|
-
"
|
|
5
|
-
"
|
|
6
|
-
|
|
3
|
+
"version": "0.1.5",
|
|
4
|
+
"type": "module",
|
|
5
|
+
"files": [
|
|
6
|
+
"cordis.patch.yml",
|
|
7
|
+
"improver.patch.yml",
|
|
8
|
+
"plugin.json",
|
|
9
|
+
"mcp.json",
|
|
10
|
+
"skills"
|
|
11
|
+
],
|
|
12
|
+
"engines": {
|
|
13
|
+
"dsh": "0.2.2-rc.1"
|
|
14
|
+
},
|
|
15
|
+
"dsh": {
|
|
16
|
+
"bundle": {
|
|
17
|
+
"patch": "./cordis.patch.yml"
|
|
18
|
+
}
|
|
19
|
+
},
|
|
20
|
+
"license": "MIT",
|
|
21
|
+
"author": "Jiahao",
|
|
22
|
+
"description": "Measured self-improvement: paired experiments, noise-aware gates and sealed confirmation.",
|
|
23
|
+
"repository": {
|
|
24
|
+
"type": "git",
|
|
25
|
+
"url": "git+https://github.com/edsml-jz2321/dsh-evokit.git",
|
|
26
|
+
"directory": "integrations/dsh"
|
|
27
|
+
},
|
|
28
|
+
"homepage": "https://github.com/edsml-jz2321/dsh-evokit#readme",
|
|
29
|
+
"keywords": [
|
|
30
|
+
"dsh-plugin",
|
|
31
|
+
"self-evolution",
|
|
32
|
+
"evaluation",
|
|
33
|
+
"mcp"
|
|
34
|
+
]
|
|
35
|
+
}
|
package/plugin.json
ADDED
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
{
|
|
2
|
+
"$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
|
|
3
|
+
"name": "dsh-evokit",
|
|
4
|
+
"version": "0.1.5",
|
|
5
|
+
"description": "Domain-neutral self-evolution experiments, paired gates and lineage",
|
|
6
|
+
"keywords": [
|
|
7
|
+
"evolution",
|
|
8
|
+
"evaluation",
|
|
9
|
+
"experiments"
|
|
10
|
+
]
|
|
11
|
+
}
|
|
@@ -0,0 +1,101 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: evolve
|
|
3
|
+
description: Improve editable system artifacts through evokit proposals, paired experiments, noise-aware gates and append-only lineage. Use with an onboarded evokit scenario.
|
|
4
|
+
metadata:
|
|
5
|
+
version: 0.1.4
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# Evolve a system
|
|
9
|
+
|
|
10
|
+
META decides; the improver analyzes and proposes. Use the `meta` skill for the
|
|
11
|
+
epoch contract, generation plans, adoption, confirmation reverts, budget, stopping
|
|
12
|
+
and the final measurement. Delegated improvers never make those decisions.
|
|
13
|
+
|
|
14
|
+
Use the scenario's `config` path with every tool. `scenario_describe` explains
|
|
15
|
+
editable scope, task counts, budgets and the domain primer. `version_current`
|
|
16
|
+
and `ledger_history` establish the current base and earlier attempts. The host
|
|
17
|
+
supplies the improver; these instructions do not require a particular agent.
|
|
18
|
+
Inspect the available tools (`evokit tools --config PATH`). For an HB workspace,
|
|
19
|
+
use `records_query` to compare tasks, groups, outcomes, proposal versions and
|
|
20
|
+
adoption generations, including `flipped_between: [parent, child]`. Use
|
|
21
|
+
`failures_similar` to find related earlier mechanisms before proposing. These
|
|
22
|
+
capabilities are absent for files storage; the generation loop below works on both.
|
|
23
|
+
Neither tool can query private confirmation or final records.
|
|
24
|
+
|
|
25
|
+
## Generation loop
|
|
26
|
+
|
|
27
|
+
1. Read the full failure index with `failure_cards` on a diagnosis run. Do not
|
|
28
|
+
reason from a few attractive examples. Cluster failures by mechanism, then
|
|
29
|
+
read original traces through their archived pointers. Keep task identities
|
|
30
|
+
and observed answers out of every editable artifact, including derived files.
|
|
31
|
+
2. Read the measured selection noise threshold before proposing. State the
|
|
32
|
+
predicted net score-sum effect and threshold in the same units, and whether
|
|
33
|
+
the effect is detectable on this selection set. If noise is unmeasured, request
|
|
34
|
+
incumbent repeats first. If the effect does not exceed the threshold,
|
|
35
|
+
propose a stronger mechanism or state that more tasks or repeats are needed.
|
|
36
|
+
Write distinct, falsifiable hypotheses. Cite prior attempts only from
|
|
37
|
+
`proposal_list` / `ledger_history` records with their ids, or use null when
|
|
38
|
+
no related record exists. Each proposal names target files, a generic mechanism,
|
|
39
|
+
a falsification criterion and what differs from its cited prior. Verify that
|
|
40
|
+
the failing tasks actually load the artifact, including its language and stage.
|
|
41
|
+
Name the specific public failing tasks expected to flip and the trace changes
|
|
42
|
+
that would demonstrate the mechanism in the proposal record. Edit in a candidate checkout,
|
|
43
|
+
inspect the full diff for task, fixture, repository and expected-output literals,
|
|
44
|
+
and remove them before claiming genericity. Keep task evidence in records.
|
|
45
|
+
then use `version_create` and `proposal_create`. Each proposal pins this
|
|
46
|
+
playbook's content version. Improve the playbook as a separate level-1 artifact
|
|
47
|
+
using the same evidence discipline, preserving system/scorer anchors.
|
|
48
|
+
3. Smoke each candidate with `run_launch(smoke=true)` (two tasks when available).
|
|
49
|
+
Fix execution errors before buying a full experiment. A completed result is
|
|
50
|
+
never rerun on resume: pass the original run id and exact arm parameters.
|
|
51
|
+
4. Repeat the incumbent on selection with `repeats >= 2`; use `noise_estimate`.
|
|
52
|
+
Measure noise before setting thresholds. Small apparent gains can be noise.
|
|
53
|
+
Run a same-window incumbent control because providers drift over time.
|
|
54
|
+
5. Launch candidate arms in parallel using distinct run ids; use task workers
|
|
55
|
+
appropriate to the host and budget. A host can pin one arm per machine when
|
|
56
|
+
orchestration supports it. Keep a launched arm on its original machine and
|
|
57
|
+
inputs. Reuse stage replay only when the scenario declares complete cache keys;
|
|
58
|
+
a changed dependency must invalidate its stage. Cached upstream cost is zero.
|
|
59
|
+
6. Wait for completion via `run_status`; inspect `run_results` and original traces.
|
|
60
|
+
Use `compare_paired` on identical selection tasks and repeats. Choose `majority`
|
|
61
|
+
for binary votes (ties fail), or `mean` for scores, explicitly. Review fixes,
|
|
62
|
+
breaks, group tables, costs and latency, including failures of the hypothesis.
|
|
63
|
+
Check the predicted task flips against original traces for the stated mechanism.
|
|
64
|
+
7. `gate_check` enforces anchors, public instance guards, holdout isolation, budgets and
|
|
65
|
+
a measured threshold. Attest `generic=true` only after reviewing the mechanism.
|
|
66
|
+
`adopt-no-harm` also requires a concrete rationale. Report a passing verdict to META for
|
|
67
|
+
`ledger_adopt` in the operator profile. Recommend promising runner-ups for META
|
|
68
|
+
to queue with `ledger_adopt(queue=true)` and retest them against the next base
|
|
69
|
+
through a new proposal. Earlier scores do not establish performance on a changed base.
|
|
70
|
+
|
|
71
|
+
## Constraints and lessons
|
|
72
|
+
|
|
73
|
+
- Diagnosis supports analysis; selection decides adoption. Confirmation (the
|
|
74
|
+
backward-compatible `holdout` role) is operator-only and decides keep-or-revert
|
|
75
|
+
of the already chosen adoption under the anchored rule. It never chooses
|
|
76
|
+
proposals. Improvers see only the not-confirmed bit, never private task ids,
|
|
77
|
+
scores, outputs or traces. META owns its wear budget (default 4 decisions).
|
|
78
|
+
- Final is a separate optional split opened once, with human approval, by META
|
|
79
|
+
at the end. It decides nothing. Without final tasks, use a fresh-task epoch.
|
|
80
|
+
Split assignments, scorer and contract stay anchored within the epoch.
|
|
81
|
+
- Prefer a generic mechanism over an instance patch even when scores tie. Leak
|
|
82
|
+
checks cover derived examples, memories, lookup tables and other artifacts.
|
|
83
|
+
Literal scans are a backstop, not a proof against encoded or semantic leaks.
|
|
84
|
+
- Separate bug fixes from behavior changes. A defect in implementation can merge
|
|
85
|
+
after review and focused tests; a change to system behavior needs paired
|
|
86
|
+
evidence. If it changes scoring or frozen support, begin a new epoch.
|
|
87
|
+
- Keep records minimal and sufficient: proposals, arms, outcomes, verdicts and
|
|
88
|
+
rationale. Do not add reservations or elaborate approval machinery.
|
|
89
|
+
- Replay, caching and cheap counterfactuals multiply iteration capacity. Verify
|
|
90
|
+
cache identity and cost attribution; do not count stale results as an improvement.
|
|
91
|
+
- Use `meta_metrics` to examine acceptance rate, prediction error and gain per
|
|
92
|
+
cost. META reads the operator-only confirmation rate; the improver receives
|
|
93
|
+
only each proposal's `not_confirmed` bit. Avoid optimizing proposal count alone.
|
|
94
|
+
|
|
95
|
+
## Stop rules
|
|
96
|
+
|
|
97
|
+
Set an experiment budget and a stagnation window before a generation. Stop when
|
|
98
|
+
the remaining budget cannot fund a smoke plus a matched comparison, when the
|
|
99
|
+
latency/cost ceiling is reached, or when successive generations yield no generic
|
|
100
|
+
gain above measured noise. Record why, leave runner-ups queued, and preserve
|
|
101
|
+
failed proposals. Do not lower the gate merely to force another adoption.
|
|
@@ -0,0 +1,194 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: meta
|
|
3
|
+
description: Coordinate an evokit self-evolution campaign as META. META owns the epoch contract, generation plans, adoption, confirmation reverts, the final measurement, budget and stopping. Use it with the evolve skill (analysis and proposals) and the onboard skill (new systems).
|
|
4
|
+
metadata:
|
|
5
|
+
version: 0.1.2
|
|
6
|
+
---
|
|
7
|
+
|
|
8
|
+
# META: coordinate self-evolution
|
|
9
|
+
|
|
10
|
+
You are META, the coordinator of a self-evolution campaign over one onboarded evokit scenario. Two other roles exist:
|
|
11
|
+
- **analysts and improvers** read failures and write proposals (the `evolve` skill);
|
|
12
|
+
- **executors** run smokes and arms and report.
|
|
13
|
+
|
|
14
|
+
Your host may let you delegate those roles to sub-agents. If it does not, perform them yourself, but keep every decision step
|
|
15
|
+
below separate from the analysis that produced it.
|
|
16
|
+
|
|
17
|
+
**Delegated agents never adopt, revert, change the epoch contract, open the final measurement or start a generation.** Only
|
|
18
|
+
META does, and META records why.
|
|
19
|
+
|
|
20
|
+
Use the scenario's `config` path with every tool. Read `scenario_describe`, `version_current`, `ledger_history`,
|
|
21
|
+
`proposal_list` and `meta_metrics` before acting. Never infer the current state from memory or a summary.
|
|
22
|
+
|
|
23
|
+
## 1. Declare the epoch contract before the first paid call
|
|
24
|
+
|
|
25
|
+
Record these with `contract_record` and read them with `contract_read`. The tool anchors split assignments and the scorer.
|
|
26
|
+
Record before the first arm, including a keyless smoke; afterwards changes require a new epoch:
|
|
27
|
+
|
|
28
|
+
| Item | What to fix |
|
|
29
|
+
|---|---|
|
|
30
|
+
| Objective | The primary per-task score, plus guard metrics that must not drop (cost, latency, secondary quality). Name the latency/cost ceiling, e.g. ≤ 1.2× the parent. |
|
|
31
|
+
| Splits | **diagnosis** (analysis), **selection** (decides adoption), **confirmation** (operator-only; decides only keep-or-revert of an adoption), **final** (opened once at the end; decides nothing). Without a separate final split, the final measurement needs a new epoch with fresh tasks. |
|
|
32
|
+
| Anchors | The scorer version, the split assignments, the confirmation rule and the final split. Changing any of them starts a new epoch. |
|
|
33
|
+
| Noise plan | The incumbent repeats on selection (≥ 2), and how the threshold is derived. |
|
|
34
|
+
| Confirmation rule | E.g. "revert if the child's paired net vs its parent on confirmation is < 0, or below −(confirmation noise threshold)". Choose the rule before seeing any confirmation result. |
|
|
35
|
+
| Budget and stop rules | The money cap, the per-generation cap, and the stagnation window (e.g. 2 generations without a confirmed gain). |
|
|
36
|
+
|
|
37
|
+
## 2. Run one generation
|
|
38
|
+
|
|
39
|
+
1. **Fix the base.** The base is the ledger's current pointer and its retained selection run. Every comparison in this
|
|
40
|
+
generation pairs against that base, or against a same-window incumbent control when the provider or host may have
|
|
41
|
+
drifted.
|
|
42
|
+
2. **Analysis.** Have analysts read the **complete** diagnosis failure index (`failure_cards`), cluster failures by mechanism,
|
|
43
|
+
and read the original traces of representative failures **and** of correct controls with the same surface features. A
|
|
44
|
+
mechanism with no counter-example check is a hypothesis, not a finding.
|
|
45
|
+
3. **Build a portfolio** of 4 or more proposals across **different mechanisms**: workflow, selection/choice, argument or format
|
|
46
|
+
contract, planning, knowledge, tools, parameters. Re-propose last generation's queued runner-ups on the new base. Avoid
|
|
47
|
+
directions that recently failed repeatedly unless the base changed materially; say what changed.
|
|
48
|
+
4. **Review every proposal before spending** (META's own check, not the proposer's). Reject before smoke if any answer is no:
|
|
49
|
+
- **Generic?** It would help unseen tasks of the same kind. It is not phrased around this task set's fixtures, tool names,
|
|
50
|
+
sample values, expected replies or answer strings.
|
|
51
|
+
- Example: a skill line containing the fixture's literal acknowledgement ("Recorded.") is task-set-specific, even when the
|
|
52
|
+
literal scan passes.
|
|
53
|
+
- **Only the editable artifacts are touched,** and the change uses only parameters and keys the system really supports.
|
|
54
|
+
Invented configuration flags are an execution error, not an experiment.
|
|
55
|
+
- **The prediction is stated:** net effect, mechanism, falsification criterion, and the prior attempt with what differs.
|
|
56
|
+
- **The proposal is the smallest change that tests the mechanism.** Two mechanisms in one proposal cannot be attributed.
|
|
57
|
+
5. **Smoke each candidate** on two tasks from the exact launch configuration. Fix execution errors before buying a full arm. A
|
|
58
|
+
failed smoke never becomes an evaluated arm.
|
|
59
|
+
6. **Run arms in parallel,** one arm per isolated environment where resources allow, with the same selection tasks and repeats as
|
|
60
|
+
the base or control. Never re-run a completed result. Resume an interrupted arm on its original id, environment and inputs.
|
|
61
|
+
7. **Pair and read** each arm with `compare_paired`:
|
|
62
|
+
- fixes, breaks, net vs the measured threshold;
|
|
63
|
+
- group tables;
|
|
64
|
+
- cost and latency ratios;
|
|
65
|
+
- **read the actual fixed and broken traces.** A gain whose fixes do not show the proposed mechanism is noise or a side effect.
|
|
66
|
+
Record which.
|
|
67
|
+
|
|
68
|
+
## 3. Decide
|
|
69
|
+
|
|
70
|
+
Apply these in order and record one verdict per proposal with a one-paragraph rationale:
|
|
71
|
+
|
|
72
|
+
1. **Reject:**
|
|
73
|
+
- a guard metric breached (latency or cost ceiling, a secondary metric beyond its noise);
|
|
74
|
+
- an execution error rate above the scenario's norm;
|
|
75
|
+
- any genericity failure found after the fact.
|
|
76
|
+
2. **Promote:** the best eligible candidate whose paired net exceeds the measured threshold and whose fixes show the mechanism.
|
|
77
|
+
3. **Adopt no-harm:** net ≥ 0 within noise, plus an evidence-backed generic benefit. Use it for:
|
|
78
|
+
- replacing an instance-specific or hand-made change with a generic mechanism at equal score;
|
|
79
|
+
- simplifying an artifact;
|
|
80
|
+
- reducing cost or latency.
|
|
81
|
+
|
|
82
|
+
At most one per generation unless the changes are provably independent.
|
|
83
|
+
4. **Queue runner-ups** with a positive or no-harm effect. Predict additivity from their recorded fixes:
|
|
84
|
+
- disjoint fixes on different artifacts → test the combination next;
|
|
85
|
+
- mostly the same fixes → keep only the better;
|
|
86
|
+
- the same artifact or role → mutually exclusive; keep the idea, not both.
|
|
87
|
+
5. **One adoption per generation** by default. The next generation's numbers on the new base decide everything queued.
|
|
88
|
+
6. **Bug fixes are not experiments.** A defect fix merges after review and focused tests, never gated or rejected by one noisy
|
|
89
|
+
arm. A change that mixes a fix with behavior gets split: merge the fix, measure the behavior.
|
|
90
|
+
|
|
91
|
+
**Never adopt:**
|
|
92
|
+
- task-id, answer, fixture or gold-matching changes;
|
|
93
|
+
- hand edits to rows an automated generator produced (change the generator instead);
|
|
94
|
+
- a change you cannot explain from its traces.
|
|
95
|
+
|
|
96
|
+
## 4. Confirmation: keep or revert an adoption
|
|
97
|
+
|
|
98
|
+
After each adoption, measure the adopted version **and its parent** on the confirmation split, paired, with the operator-only
|
|
99
|
+
`confirm_adoption` tool (the operator profile). Read only the aggregate: fixes, breaks, net, cost and latency. **Never open confirmation task ids, inputs, outputs or
|
|
100
|
+
traces, and never pass anything but the verdict to analysts.**
|
|
101
|
+
|
|
102
|
+
- **Confirmed.** The rule passes. Keep the adoption. Record the confirmation.
|
|
103
|
+
- **Not confirmed.** The rule fails. **Revert** the current pointer to the parent:
|
|
104
|
+
- Use `ledger_revert` to record the child, the parent and a reason containing the aggregate result and the rule.
|
|
105
|
+
- Mark the proposal "selection gain, not confirmed".
|
|
106
|
+
- Tell analysts only that it did not confirm, and look for the generic flaw: an overfit wording, a fixture-specific example,
|
|
107
|
+
a mechanism that only fires on selection tasks.
|
|
108
|
+
- The mechanism may return later as a new, more generic proposal.
|
|
109
|
+
- **Confirmation results never choose between proposals.** They only keep or revert the one adoption that selection already
|
|
110
|
+
chose.
|
|
111
|
+
- **Confirmation wears out.** Every use leaks a little information. The confirmed scores become optimistic estimates.
|
|
112
|
+
- Plan at most 3–5 confirmation decisions per epoch (`confirmation_wear_budget`, default 4).
|
|
113
|
+
- Report confirmed numbers as "confirmation", never as the final result.
|
|
114
|
+
- When the wear budget is spent, start a new epoch with a fresh confirmation split.
|
|
115
|
+
|
|
116
|
+
Public BFCL example: held-out accuracy improved from 41 to 47 of 50 after confirmation.
|
|
117
|
+
A failed confirmation must revert the adoption; selection gains alone do not establish generalization.
|
|
118
|
+
|
|
119
|
+
## 5. The final measurement
|
|
120
|
+
|
|
121
|
+
- Use `final_measure` to open the final split, or a fresh-task epoch, **once**, at the end of a campaign or a release.
|
|
122
|
+
- Measure the current version and the campaign's starting version, paired.
|
|
123
|
+
- It decides nothing: no adoption, no revert, no tuning afterwards.
|
|
124
|
+
- Report it with its noise, its task source, and any differences between the final tasks and the evolution tasks, listed
|
|
125
|
+
separately.
|
|
126
|
+
- Ask the human before opening it. It is the number people will quote.
|
|
127
|
+
|
|
128
|
+
## 6. Noise, drift and controls
|
|
129
|
+
|
|
130
|
+
- **Measure before you threshold.** Repeat the incumbent at least twice on selection; derive the threshold from the flip rate
|
|
131
|
+
and the repeat spread. Small nets near the threshold need a repeat or more tasks, not a lower bar.
|
|
132
|
+
- Changes that regenerate stochastic outputs carry resampling noise that replays do not. Pair them with a same-window control
|
|
133
|
+
when providers, hosts or load may have changed.
|
|
134
|
+
- **Never lower a gate to force an adoption.** Change thresholds only at an epoch boundary, from fresh noise data.
|
|
135
|
+
|
|
136
|
+
## 7. Leaks and generalization
|
|
137
|
+
|
|
138
|
+
- Leaks hide in derived artifacts: examples, memories, lookup tables, retrieved snippets, cached outputs.
|
|
139
|
+
- Sweep every derived artifact against public selection inputs and labels before each adoption. Keep confirmation and final
|
|
140
|
+
inputs and labels sealed; an operator audit must not return private membership or matches to analysts.
|
|
141
|
+
- A leak found later invalidates every score it touched. Rebuild, re-baseline and say so.
|
|
142
|
+
- Prefer the generic mechanism even when an instance patch scores the same. Unseen tasks are the point.
|
|
143
|
+
|
|
144
|
+
## 8. Operations
|
|
145
|
+
|
|
146
|
+
- **Smoke from the exact launch configuration** before every paid arm. One missing import once voided three full arms.
|
|
147
|
+
- **Resume, never restart.** A completed result is never recomputed. One process per task: check for duplicates after any
|
|
148
|
+
interruption.
|
|
149
|
+
- **Unknown accounting stops paid work** until it is reconciled. Never replay a paid slot silently.
|
|
150
|
+
- Watch long runs with a monitor that fires on completion, death, stalls and duplicate workers.
|
|
151
|
+
- Credentials are read from files, never printed, logged or committed, and copies are deleted after use.
|
|
152
|
+
- **Keep records minimal but sufficient:**
|
|
153
|
+
- the epoch contract;
|
|
154
|
+
- proposals;
|
|
155
|
+
- arms;
|
|
156
|
+
- paired outcomes;
|
|
157
|
+
- verdicts with rationale;
|
|
158
|
+
- adoptions and reverts;
|
|
159
|
+
- confirmation aggregates;
|
|
160
|
+
- the final measurement.
|
|
161
|
+
|
|
162
|
+
Add nothing that no decision reads.
|
|
163
|
+
|
|
164
|
+
## 9. Improve the improver (level 1), at epoch boundaries
|
|
165
|
+
|
|
166
|
+
Track `meta_metrics`:
|
|
167
|
+
- acceptance rate;
|
|
168
|
+
- mean |predicted − measured| net;
|
|
169
|
+
- **confirmation rate of adoptions**;
|
|
170
|
+
- gain per unit cost;
|
|
171
|
+
- which mechanism families keep failing.
|
|
172
|
+
|
|
173
|
+
At an epoch boundary, edit the `evolve` skill or this skill only from that evidence, as a versioned change with its own
|
|
174
|
+
rationale. Never edit them mid-epoch to rescue a result.
|
|
175
|
+
|
|
176
|
+
## 10. Stop and report
|
|
177
|
+
|
|
178
|
+
Stop when:
|
|
179
|
+
- the budget cannot fund a smoke plus a matched arm;
|
|
180
|
+
- the stagnation window passes without a confirmed gain;
|
|
181
|
+
- a guard ceiling is reached;
|
|
182
|
+
- unknown accounting or an integrity problem appears.
|
|
183
|
+
|
|
184
|
+
Report to the human in plain words:
|
|
185
|
+
- what was adopted, confirmed and reverted;
|
|
186
|
+
- each number with its noise;
|
|
187
|
+
- the cost;
|
|
188
|
+
- what is queued;
|
|
189
|
+
- what you recommend next.
|
|
190
|
+
|
|
191
|
+
Ask the human before:
|
|
192
|
+
- changing scope, anchors or budget;
|
|
193
|
+
- opening the final measurement;
|
|
194
|
+
- anything irreversible.
|
|
@@ -0,0 +1,56 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: onboard
|
|
3
|
+
description: Onboard an existing repository as an evokit scenario by finding editable artifacts, stable tasks and a run-and-score entrypoint, then scaffolding and checking the integration.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Onboard a system
|
|
7
|
+
|
|
8
|
+
Help the operator connect an existing system to evokit. Keep its language,
|
|
9
|
+
runtime, scorer and deployment conventions. The three required pieces are
|
|
10
|
+
editable file globs, stable JSON tasks and a runner that returns a measured
|
|
11
|
+
outcome, reason and cost. No model-provider or database interface is required.
|
|
12
|
+
|
|
13
|
+
Inspect the repository's instructions and existing test/evaluation commands.
|
|
14
|
+
Identify the run command and the independent scoring boundary. Ask the operator
|
|
15
|
+
only for missing decisions: editable scope, task source, success criterion and
|
|
16
|
+
execution budget. Propose concrete globs that exclude scorers, labels, task data,
|
|
17
|
+
credentials and frozen environment configuration. Do not invent a success score.
|
|
18
|
+
|
|
19
|
+
Run `evokit init --help`, then scaffold in a small scenario directory. For example:
|
|
20
|
+
|
|
21
|
+
```console
|
|
22
|
+
evokit init ./evolution --editable "prompts/*.md" --tasks ./public-tasks.json --command-argv node run-and-score.mjs
|
|
23
|
+
```
|
|
24
|
+
|
|
25
|
+
Use `--adapter python` before `--command-argv` for a Python SDK skeleton. A blank
|
|
26
|
+
interactive command creates an unfinished runner that refuses execution until
|
|
27
|
+
implemented. Init never overwrites existing files. Put executable/frozen support
|
|
28
|
+
inside the scenario root, or pin external dependencies explicitly. Verify that
|
|
29
|
+
the runner reads EVOKIT_TASK_FILE, uses EVOKIT_VERSION_DIR and writes one Result
|
|
30
|
+
JSON to EVOKIT_RESULT_FILE. Trace files must remain inside its isolated checkout.
|
|
31
|
+
|
|
32
|
+
Run `evokit doctor --config ./evolution/scenario.yaml` first. This freezes/checks
|
|
33
|
+
normal epoch anchors but does not execute the runner. Review counts, edit scope,
|
|
34
|
+
public-literal leak scans and confirmation/final isolation. Do not treat skipped checks as
|
|
35
|
+
passes. Keep labels and confirmation/final sources outside the agent's filesystem access
|
|
36
|
+
when confidentiality is required; evokit is not an OS sandbox.
|
|
37
|
+
|
|
38
|
+
With the operator's existing execution authorization and budget, use `doctor
|
|
39
|
+
--run --labels ./calibration.json` for two public diagnosis tasks twice plus any
|
|
40
|
+
additional explicitly labeled public tasks once. Labels map public ids to human
|
|
41
|
+
verified expected scores. Never supply or query confirmation/final labels. Inspect scorer
|
|
42
|
+
agreement, outcome stability, reported cost units and task time. Missing cost
|
|
43
|
+
units remain unknown. Stop on execution/accounting errors; do not retry paid work
|
|
44
|
+
or weaken the scorer to make readiness pass.
|
|
45
|
+
|
|
46
|
+
Run a two-task smoke through the normal tools: obtain `version_current`, then
|
|
47
|
+
`run_launch` with that version, `split=diagnosis`, `smoke=true`, `workers=1`,
|
|
48
|
+
`wait=true`; read `run_results`. Use an args file for PowerShell. Keep the run id
|
|
49
|
+
after uncertain transport and resume the same run instead of launching a duplicate.
|
|
50
|
+
Do not start provider-backed work without existing authorization.
|
|
51
|
+
|
|
52
|
+
Hand off the config path, editable scope, task/split counts, scorer identity,
|
|
53
|
+
calibration result, observed costs and unresolved checks. Suggest repeated
|
|
54
|
+
incumbent selection controls and `noise_estimate` before using `evolve`.
|
|
55
|
+
Holdout remains operator-only post-adoption measurement. Onboarding does not
|
|
56
|
+
authorize evolution, promotion, deployment or additional spending.
|