@evo-hq/pi-evo 0.4.4-alpha.5 → 0.4.4-alpha.6

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@evo-hq/pi-evo",
-  "version": "0.4.4-alpha.5",
+  "version": "0.4.4-alpha.6",
   "description": "Evo plugin for pi-coding-agent: optimize/discover/subagent skills + mid-run inject extension.",
   "publishConfig": {
     "access": "public"

package/skills/discover/SKILL.md

@@ -2,7 +2,7 @@
 name: discover
 description: Initialize evo for the current repository by exploring the codebase, proposing unexplored optimization dimensions, constructing the benchmark inside a baseline worktree, and running the first experiment. Use when the user invokes /evo:discover, mentions setting up evo, wants to instrument a codebase for autonomous optimization, or asks to start a new evo run on a project.
 argument-hint: <optional context about what to optimize>
-evo_version: 0.4.4-alpha.5
+evo_version: 0.4.4-alpha.6
 ---
 
 # Discover
@@ -40,20 +40,20 @@ evo --version
 The output must be exactly:
 
 ```
-evo-hq-cli 0.4.4-alpha.5
+evo-hq-cli 0.4.4-alpha.6
 ```
 
 Three outcomes:
 
 1. **Matches exactly** — continue to step 1.
 2. **Reports a different version** (`evo-hq-cli 0.4.2`, etc.) — the host refetched a newer/older skill bundle than the CLI on PATH. Drift breaks skills silently. Stop and tell the user:
-   > Your installed evo CLI is on a different version than this skill (`0.4.4-alpha.5`). Run:
+   > Your installed evo CLI is on a different version than this skill (`0.4.4-alpha.6`). Run:
    > ```
-   > uv tool install --force evo-hq-cli==0.4.4-alpha.5
+   > uv tool install --force evo-hq-cli==0.4.4-alpha.6
    > ```
    > Then re-invoke this skill.
 3. **`command not found`, or reports a different package** (commonly `evo 1.x` — the unrelated SLAM tool) — the CLI isn't installed. Tell the user:
-   > `evo-hq-cli` isn't on your PATH. Install it: `uv tool install evo-hq-cli==0.4.4-alpha.5` (or `pipx install evo-hq-cli==0.4.4-alpha.5`). Then re-invoke this skill.
+   > `evo-hq-cli` isn't on your PATH. Install it: `uv tool install evo-hq-cli==0.4.4-alpha.6` (or `pipx install evo-hq-cli==0.4.4-alpha.6`). Then re-invoke this skill.
 
 Do not try to auto-install. Host sandbox + network policy may block it; leaving the install as a user action keeps failure modes clear.
 
@@ -123,8 +123,14 @@ For cases 2 and 3, ask once:
 
 > "I can wire up the benchmark in one of two ways:
 >
-> 1. **SDK mode** -- install the evo agent SDK with this project's package manager/runtime (for example `uv add --dev evo-hq-agent`, `python -m pip install evo-hq-agent`, or `npm install @evo-hq/evo-agent`). Richer per-task logs, ~5 lines of user code.
-> 2. **Inline mode** -- paste a ~30-line helper directly into the benchmark. Zero new dependencies. Same data contract."
+> 1. **SDK mode** -- install the evo agent SDK with this project's package manager/runtime (`uv add --dev evo-hq-agent`, `python -m pip install evo-hq-agent`, or `npm install @evo-hq/evo-agent`). ~5 lines of user code, with incremental per-task logging handled for you. **Python and Node only** -- the SDK ships for those two runtimes.
+> 2. **Inline mode** -- implement the trace/result contract directly in the benchmark, in the benchmark's own language. Zero new dependencies, same data.
+>
+> Recommended: SDK mode."
+
+Inline mode is language-native and lives entirely in the user's setup: whatever the benchmark is written in is what the instrumentation is written in, with no evo package added to the project. Do not introduce a Python (or any other) sidecar script to wrap a benchmark written in another language -- that is the friction this avoids. For a Python or Node benchmark, the ready-made paste-in helper (`references/inline_instrumentation.py` / `.js`) is the inline implementation. For any other language, port the ~10-15 line contract from `references/instrumentation-contract.md` into that language. Either way the mode is `inline`.
+
+Order the options SDK first, inline second, and suggest SDK as the recommended default when it's available -- it's the managed path with per-task logging handled for you. Inline stays a first-class choice with the same data contract, though: if the user declines the SDK for any reason -- they don't want a new dependency, can't add evo to their project's tree, internal policy, or plain preference -- honor it without pushback. SDK mode is only *available* when the benchmark runs on Python or Node; when the benchmark's language has no SDK there's nothing to suggest, so go straight to inline.
 
 Pass the answer to `evo init` via `--instrumentation-mode <sdk|inline>` in step 7. **Never install packages without this confirmation.** If you skip the question (case 1), still pass the detected mode to `evo init` so optimize/subagent runs see a consistent value.
 
@@ -303,14 +309,14 @@ Patterns to scan for:
 
 ### 10c. Apply instrumentation
 
-Based on the instrumentation mode passed to `evo init`:
+Both modes satisfy the same file-and-env contract: per-task `task_<id>.json` written to `$EVO_TRACES_DIR`, a result JSON with a numeric `score` written to `$EVO_RESULT_PATH` (stdout if unset). `evo run` reads those files; it never inspects the language. The full spec is `references/instrumentation-contract.md`.
 
 Paths below are relative to this `SKILL.md` file (resolve them against the skill directory).
 
-- **SDK mode**: add `from evo_agent import Run` (Python) or `import { Run } from '@evo-hq/evo-agent'` (Node) to the benchmark script. Wrap the eval loop per `references/sdk_python.py` or `references/sdk_node.js`.
-- **Inline mode**: copy the helper from `references/inline_instrumentation.py` (or `.js`) into the benchmark. Use `log_task` / `logTask` per task and `write_result` / `writeResult` once at the end.
-
-The wire protocol is the same either way: `task_<id>.json` written to `$EVO_TRACES_DIR`, score JSON written to `$EVO_RESULT_PATH`. Stdout is free for user output.
+- **SDK mode** (Python/Node only): add `from evo_agent import Run` (Python) or `import { Run } from '@evo-hq/evo-agent'` (Node) to the benchmark script. Wrap the eval loop per `references/sdk_python.py` or `references/sdk_node.js`.
+- **Inline mode**: implement the contract in the benchmark's own language.
+  - Benchmark is Python or Node: paste `references/inline_instrumentation.py` (or `.js`) and call `log_task` / `logTask` per task, `write_result` / `writeResult` once at the end.
+  - Benchmark is any other language: port the contract from `references/instrumentation-contract.md` directly into that language (~10-15 lines: read the env vars, write each task trace, atomically publish the result). Do not add a Python/JS wrapper around it.
 
 ### 10d. Cheap validation run
 
@@ -325,7 +331,7 @@ evo gate check exp_0000
 
 Use `evo gate check <exp_id>` when only gate wiring changed or when you need to validate inherited gates without running the benchmark. It writes a `gate_check.json` artifact under the same checks directory and also does not mutate experiment state.
 
-The check asserts `result.json` exists, is non-empty, and is a JSON object with a numeric `score`. Also verify:
+This is the authoritative wiring check, and it is language-agnostic -- it runs the real benchmark command and inspects the JSON artifacts, so a native inline implementation in any language is validated the same way a Python one is. The check asserts `result.json` exists, is non-empty, and is a JSON object with a numeric `score`. Also verify:
 
 - All dependencies resolve and the command completes.
 - Traces appear in `$EVO_TRACES_DIR` (if applicable).
@@ -386,37 +392,11 @@ Document:
   - `uses LLMs with temp=0` -- expected to be deterministic in practice; flag if it isn't
   - `sampling-based, variance expected` -- inherent noise; optimize will need multi-run strategies
 - Environment requirements discovered during validation
+- **Resource profile (for run sizing)** -- the binding resource one benchmark run needs (exclusive GPU/accelerator, peak memory, an exclusive port, a shared DB/fixture, or an external API rate limit / $-per-run), whether concurrent benchmark runs are safe on this backend or must serialize, and rough time/cost per run. `/evo:optimize` reads this to size each round (see `plugins/evo/skills/optimize/references/sizing-the-round.md`)
 - What each gate protects
 - Benchmark gaming risks identified during the Goodhart check
 - Future experiment candidates (the non-picked dimensions from step 3)
 
-## 12a. Confirm how the optimize loop should run
-
-Ask the user once how they want `/evo:optimize` to behave. These are run-behavior defaults stored on the workspace; they don't affect discover itself. Ask as a single, light question (use your host's structured multi-choice tool if you have one; otherwise plain text), and make clear both are optional — the defaults apply if the user has no preference:
-
-- **Autonomous loop** — should evo's internal wiring keep the loop running on its own, re-engaging the agent at every turn boundary until the run stalls (`autonomous`)? Default off: evo does not auto-continue the loop.
-- **Orchestrator edits** — push every edit through subagents, steering the orchestrator away from editing directly (`subagents-only`)? Default off: the orchestrator may also edit directly if it chooses.
-
-**Pre-fill from the user's remembered choice.** Before asking, read their cross-project defaults and use each as the suggested answer (so a returning user just confirms):
-
-```bash
-evo defaults get autonomous --json        # → true | false | null
-evo defaults get subagents-only --json
-```
-
-If a value is non-null, present it as the default in the question (e.g. "autonomous was on last time — keep it?"). Always still ask — never apply a remembered value silently.
-
-Persist the answer to both the workspace (this project) and the user-level store (remembered for next project):
-
-```bash
-evo config set default-autonomous on|off
-evo config set default-subagents-only on|off
-evo defaults set autonomous on|off
-evo defaults set subagents-only on|off
-```
-
-If the user has no opinion and no remembered value exists, or you skip the question, leave both off — the defaults: the loop stops naturally after each round, and the orchestrator may edit directly. Do NOT infer these from the user's earlier free-form messages; only set `on` when the user clearly chooses it here. `/evo:optimize` reads these defaults at startup (workspace first, then user-level), and a bare-word `autonomous` / `subagents-only` on the invocation overrides the stored default for that run.
-
 ## 13. Report to the user
 
 End the skill by reporting in chat:

package/skills/discover/references/constructing-benchmark.md

@@ -54,7 +54,7 @@ Output contract (same as existing evo benchmarks):
 - **stdout / stderr:** free for user output (logs, progress, debug)
 - **exit code:** 0 on successful completion (even if score is low); non-zero only on infrastructure failure (import error, missing data, etc.)
 
-Use the SDK or inline instrumentation depending on the user's earlier choice (recorded in `.evo/meta.json` as `instrumentation_mode`).
+Use the SDK or inline instrumentation depending on the user's earlier choice (recorded in `.evo/meta.json` as `instrumentation_mode`). Write the harness in the language that drives the target -- a Rust target gets a Rust harness, a Go target a Go harness. Inline mode is language-native: implement the trace/result contract in that same language (`instrumentation-contract.md`), don't wrap the benchmark in a Python or JS sidecar. SDK mode is Python/Node only.
 
 ## 4. Goodhart check
 

package/skills/discover/references/instrumentation-contract.md

@@ -0,0 +1,89 @@
+# Instrumentation contract
+
+Inline instrumentation is a file-and-env contract, not a library. `evo run` sets two environment variables, runs your benchmark command as a subprocess in whatever language it's written in, and reads back JSON files. Any language that can read an env var and write a JSON file satisfies it — implement it directly in the benchmark's own language.
+
+The `inline_instrumentation.py` and `inline_instrumentation.js` helpers in this directory are ready-made reference implementations of this contract. For a Python or Node benchmark, paste one in. For any other language (Go, Rust, Ruby, Java, C++, shell, ...), implement the contract below in that language — it's ~10-15 lines.
+
+## Environment (set by `evo run`)
+
+| Variable | Meaning | If unset |
+|---|---|---|
+| `EVO_RESULT_PATH` | Absolute path to write the final result JSON | Print the result JSON to stdout instead |
+| `EVO_TRACES_DIR` | Directory to write per-task traces into | Skip traces (score still works; the dashboard just shows less) |
+| `EVO_EXPERIMENT_ID` | The experiment id, for stamping traces | Use `"unknown"` |
+
+## Result JSON (required)
+
+Write one JSON object — to `$EVO_RESULT_PATH`, or stdout if that's unset:
+
+```json
+{
+  "score": 0.6,
+  "tasks": {"t1": 0.8, "t2": 0.4},
+  "started_at": "2026-05-30T09:00:00+00:00",
+  "ended_at": "2026-05-30T09:01:00+00:00"
+}
+```
+
+- `score` (number) is the only required field. `evo run --check` fails if the result is missing, empty, or has no numeric `score`.
+- `tasks` (map of task id -> score) drives per-task selection strategies. Include it when the benchmark has discrete tasks.
+- `started_at` / `ended_at` are optional ISO-8601 timestamps.
+- Add `tasks_meta` only when a task's optimization direction differs from the benchmark's top-level `--metric`: `"tasks_meta": {"latency_ms": {"direction": "min"}}`.
+
+**Exit code:** 0 on successful completion, even when the score is low. Exit non-zero only on infrastructure failure (missing data, import/compile error). A low score is data, not a crash. (Score-threshold *gates* are the exception — see SKILL.md step 8.)
+
+## Per-task trace (recommended)
+
+For each task, write `$EVO_TRACES_DIR/task_<id>.json` as the task finishes, so the dashboard streams progress live:
+
+```json
+{
+  "experiment_id": "exp_0000",
+  "task_id": "t1",
+  "score": 0.8,
+  "ended_at": "2026-05-30T09:00:30+00:00"
+}
+```
+
+- `task_id` and `score` are the substance; `experiment_id` and `ended_at` are for display.
+- Optional fields, include what helps debugging: `status` (a `"passed"`/`"failed"` display label — set it from the benchmark's own pass criterion, whatever that is for this score scale; the engine does not read it or impose a threshold), `summary`, `failure_reason`, `log`, `direction`.
+
+## Atomic result publish (the one non-obvious rule)
+
+Publish the result file with claim-then-rename, not a plain write:
+
+1. Atomically create-exclusive the result path to claim it (`O_EXCL` / open mode `"wx"`). If it already exists, fail loudly — a second writer in the same attempt is a wiring bug, not something to overwrite.
+2. Write the payload to `<result_path>.tmp`.
+3. Rename `.tmp` over the result path.
+
+This makes duplicate writers fail fast and ensures a crash mid-publish leaves an empty claimed file (which `load_result` treats as a failed run) rather than a half-written JSON that parses wrong. The `.py`/`.js` helpers show the exact calls. Per-task traces don't need this — they're write-once-per-id.
+
+## Validate the wiring
+
+The contract is language-agnostic, and so is the check. From the main repo root:
+
+```bash
+evo run <exp_id> --check
+```
+
+This runs the real benchmark command and asserts the result artifact exists, is non-empty, and carries a numeric `score` — regardless of what language produced it. It's the authoritative "is the wiring correct" test; passing it means evo can read your harness. Inspect the artifacts with `evo show <exp_id>`.
+
+## Minimal shell reference
+
+A complete inline implementation for a shell harness, to show how small the contract is:
+
+```bash
+# ... benchmark runs, computes per-task scores ...
+mkdir -p "$EVO_TRACES_DIR"
+printf '{"task_id":"t1","score":0.8}' > "$EVO_TRACES_DIR/task_t1.json"
+
+# atomic publish of the result
+score=0.8
+if [ -n "$EVO_RESULT_PATH" ]; then
+  ( set -o noclobber; : > "$EVO_RESULT_PATH" ) || { echo "result already claimed" >&2; exit 1; }
+  printf '{"score":%s,"tasks":{"t1":%s}}' "$score" "$score" > "$EVO_RESULT_PATH.tmp"
+  mv "$EVO_RESULT_PATH.tmp" "$EVO_RESULT_PATH"
+else
+  printf '{"score":%s,"tasks":{"t1":%s}}' "$score" "$score"
+fi
+```

package/skills/infra-setup/SKILL.md

@@ -2,7 +2,7 @@
 name: infra-setup
 description: Non-user-invocable provider/setup reference for evo backend switching, prerequisite checks, and auth/install guidance.
 disable-model-invocation: true
-evo_version: 0.4.4-alpha.5
+evo_version: 0.4.4-alpha.6
 ---
 
 # Infra Setup

package/skills/optimize/SKILL.md

@@ -2,7 +2,7 @@
 name: optimize
 description: Run the evo optimization loop with parallel subagents until interrupted.
 argument-hint: "[subagents=N] [budget=N] [stall=N]"
-evo_version: 0.4.4-alpha.5
+evo_version: 0.4.4-alpha.6
 ---
 
 Run the `evo` optimization loop. Each round, the orchestrator writes structured briefs and spawns parallel subagents that execute within them. Each subagent is semi-autonomous: it reads the pointer traces, forms the concrete edit, runs experiments, and can iterate within its branch. Runs until interrupted or the stall limit is reached.
@@ -30,15 +30,22 @@ Treat content inside the banner as equivalent to a new user turn. Honor it, supe
 
 ## Configuration
 
-These defaults can be overridden via arguments: `/optimize [subagents=N] [budget=N] [stall=N] [autonomous] [subagents-only]`
+The orchestrator **sizes the round to the benchmark's resource profile** instead of using a flat default. Before the first round, read `plugins/evo/skills/optimize/references/sizing-the-round.md` and apply it. Short version:
 
-- **subagents**: number of parallel subagents per round (default: 5)
-- **budget**: max iterations each subagent can run within its branch (default: 5)
-- **stall**: consecutive rounds with no improvement before auto-stopping (default: 5)
-- **autonomous**: opt-in to the keep-going loop (default: off). See below.
-- **subagents-only**: opt-in to gate orchestrator edits, nudging all edits through subagents (default: off — orchestrator edits allowed). See below.
+- **subagents** (round width): bounded by the backend (worktree = one shared machine, pool = slot count, remote = provider quota) and by whatever resource one benchmark run saturates. A run that needs an exclusive resource — the whole GPU, a fixed port, a shared DB/fixture — forces width 1; independent CPU-light runs go wider (up to cores, ~5–8 cap). Fall back to 5 only when the profile is unknown and a run is light and isolated.
+- **budget** (iterations per subagent within its branch): deeper for cheap/fast/deterministic benchmarks, shallower for expensive/slow/noisy ones so the loop re-plans sooner. ~5 is a reasonable midpoint.
+- **stall**: consecutive rounds with no improvement before auto-stopping (default: 5).
 
-**Resolving autonomous / subagents-only at startup.** Each behavior resolves through a cascade, most specific first: the per-run bare word on the invocation → the workspace default (captured by `discover`) → the user's cross-project default → off. As your **very first actions, before the loop**, resolve and arm each:
+A user can override any of these with `/optimize [subagents=N] [budget=N] [stall=N]`; an explicit value always wins over the heuristic.
+
+- **autonomous**: the keep-going loop. **Default: on** — evo is autoresearch; it runs unattended. Turn off for a run with `evo autonomous off`.
+- **subagents-only**: gate orchestrator edits, pushing all edits through subagents. **Default: on**. Turn off for a run with `evo subagents-only off`.
+
+**Resolving autonomous / subagents-only at startup.** Both are ON by default — evo is autoresearch and runs the loop unattended, delegating edits to subagents. Do not ask the user about either. Resolve each through a cascade, most specific first:
+
+1. **An explicit instruction from the user this run wins — on or off.** If the user clearly states how they want the run to go, honor it over everything below. "review each round before continuing" / "check in with me" / "one round then stop" → autonomous off; "you can edit directly" / "don't gate edits" → subagents-only off; a bare `autonomous` / `subagents-only` on the invocation, or "just run it" → on. Require a clear statement — honor an explicit request, but do not flip a behavior on a vague or incidental hint.
+2. **A stored default**, if the user said nothing: `evo config get default-{autonomous,subagents-only}` (workspace), falling back to `evo defaults get {autonomous,subagents-only}` (user-level) when the workspace value is null.
+3. **Otherwise → on** — the framework default.
 
 ```bash
 evo config get default-autonomous --json        # workspace → true | false | null
@@ -47,12 +54,7 @@ evo config get default-subagents-only --json
 evo defaults get subagents-only --json
 ```
 
-For each behavior: if the bare word is on the invocation → on; else if the workspace value is non-null → use it; else if the user-level value is non-null → use it; else off. When the resolved value is on, run the matching command before the loop:
-
-- `autonomous` resolved on → run `evo autonomous on`.
-- `subagents-only` resolved on → run `evo subagents-only on`.
-
-If a value comes from a stored default (not a bare word on this invocation), say so in your opening message — e.g. "autonomous on (from your saved default)" — so an inherited setting is never invisible. Never infer either from the user's free-form task description; only the invocation argument or a stored default may turn them on.
+As your **very first actions, before the loop**, resolve each and arm it: run `evo autonomous on` / `evo subagents-only on` when it resolves on, or `evo autonomous off` / `evo subagents-only off` when an explicit instruction or stored default turned it off. If a behavior resolves off — whether from the user's instruction this run or a stored default — say so in your opening message (e.g. "autonomous off — running one round at a time, as you asked") so it's never invisible.
 
 **Autonomous mode.** Off lets you stop naturally at a turn boundary — finish a round, report, and stop. On arms the stop-nudge: at every turn boundary you are re-prompted to keep driving the loop until the **stall** limit is hit or the user interrupts. Without it, the loop does NOT force-continue across turn boundaries. To stop an autonomous run, the user runs `evo autonomous off` or `evo exit-optimize-mode`.
 

package/skills/optimize/references/sizing-the-round.md

@@ -0,0 +1,47 @@
+# Sizing the round
+
+How to pick **round width** (`subagents`) and **per-branch depth** (`budget`) for a round. Apply this before the first round and re-check it if the backend or benchmark changes.
+
+The governing idea: **round width is resource-bound.** Spawning N subagents means up to N benchmark runs executing at once. If one run already saturates the binding resource, more runs don't go faster — they contend, thrash, or OOM. So:
+
+```
+width = min(backend_ceiling, resource_width)
+```
+
+## 1. Backend ceiling
+
+Check `evo config backend show`.
+
+- **worktree** (default): every experiment runs on the *same machine*. The ceiling is what that one machine can run concurrently without contention — set by `resource_width` below, not by a fixed number.
+- **pool**: hard ceiling = slot count (`evo workspace status`). Exceeding it makes later `evo new` calls fail with `PoolExhausted`. Never set width above the slots.
+- **remote**: each experiment runs in its own container, so the local machine isn't the limit. Ceiling is provider quota / concurrency cap / cost tolerance.
+
+## 2. Resource width — what one benchmark run saturates
+
+Read `.evo/project.md`'s resource-profile line first (discover records it). If it's missing or thin, infer from the benchmark command, the target's imports, and a quick probe (`nvidia-smi`, core count, the benchmark's own docs). Then size to whatever one run consumes:
+
+| Binding resource of one run | Round width on a shared machine |
+|---|---|
+| Exclusive accelerator — needs the whole GPU/TPU, or a pinned device | **1** with one device; **K** with K devices that can be pinned per worktree |
+| Memory-heavy | `floor(total_RAM / per_run_peak)` with headroom |
+| Exclusive port, singleton service, shared DB, or a shared mutable fixture | **1**, unless the harness parameterizes that resource per worktree |
+| External API rate limit or real $-per-run | cap width to stay under the limit / within budget |
+| CPU-light, in-memory, fully isolated | wider — up to core count, capped ~5–8 to keep the round legible |
+
+When a run needs an exclusive resource, serializing benchmark *execution* (width 1) is correct even though the *edits* are independent — on the worktree backend `evo run` executes the benchmark in-place, so concurrent `evo run` means concurrent benchmark processes on that one resource.
+
+## 3. Depth — `budget` (iterations per subagent within its branch)
+
+Depth trades exploration against spend, and keys off cost per run, not concurrency:
+
+- Cheap, fast, deterministic benchmark → larger budget; let a promising branch iterate several times before the orchestrator re-plans.
+- Expensive, slow, or noisy benchmark → smaller budget; re-plan sooner so spend tracks signal. For noisy benchmarks, deep single-branch iteration over-fits to lucky runs.
+- ~5 is a reasonable midpoint when nothing argues otherwise.
+
+## 4. Default and override
+
+- **Unknown profile, light isolated run** → fall back to width 5, budget 5.
+- **Unsure, but a shared exclusive resource is plausible** (the benchmark touches a GPU, a port, a DB) → serialize (width 1). Under-subscribing wastes a little wall-clock; over-subscribing corrupts results or crashes the round.
+- **The user gave an explicit value** (`/optimize subagents=N budget=N`, or said it in plain language) → honor it, over the heuristic. They know their hardware.
+
+State the width/budget you chose and the one-line reason in your opening message, so the sizing is visible (e.g. "width 1 — benchmark needs the single GPU; budget 6 — runs are cheap and deterministic").

package/skills/report/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: report
 description: Print the dashboard's dot chart (score over experiment order, status colors, best-path stair) inline in the terminal for every run in the workspace. Use when the user invokes /evo:report, asks for a quick score chart without opening the dashboard, or wants the scatter plot in chat output.
-evo_version: 0.4.4-alpha.5
+evo_version: 0.4.4-alpha.6
 ---
 
 # Report

package/skills/subagent/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: subagent
 description: Internal protocol for evo optimization subagents. Loaded by subagents spawned from /optimize via their host's skill loader. Not for orchestrator use.
-evo_version: 0.4.4-alpha.5
+evo_version: 0.4.4-alpha.6
 ---
 
 # Evo Subagent Protocol