fix(optimization): verify the published GEPA wheel

[drewstone]

Use the published GEPA 0.1.4 wheel in CI and release verification through Agent Eval 0.126.5.

pnpm verify:official-optimizers now creates the exact Python environment itself, so local checks, CI, and release share one install path. It requires public wheels for Agent Eval and GEPA. SkillOpt remains source-pinned because its 0.2.0 wheel omits required prompt files.

Checks:

• packed Agent Knowledge package through official GEPA and SkillOpt: 2/2 passed
• package suite: 466 passed, 12 skipped
• clean package lifecycle: 5 imports, skill, CLI version, and re-pack passed
• lint, typecheck, build, frozen install, workflow syntax, and script syntax passed

[tangletools]

✅ Auto-approved drewstone PR — 8dfac6ed

This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.

_{tangletools · auto-approval · reason: drewstone_author · 2026-07-24T18:40:38Z}

[tangletools]

✅ No Blockers — 8dfac6ed

Review health 100/100 · Reviewer score 95/100 · Confidence 65/100 · 0 findings (none)

glm: Correctness 95 · Security 95 · Testing 95 · Architecture 95

Reviewer score is advisory once the run is complete and the verdict has no blockers.

Full multi-shot audit completed 1/1 planned shots over 2 changed files. Global verifier still owns final merge decision.

No findings.

---

_{tangletools · 2026-07-24T18:43:22Z · trace}

[tangletools]

✅ Clean — 8dfac6ed

Full multi-shot audit completed 1/1 planned shots over 2 changed files. Global verifier still owns final merge decision.

Full immutable report for this review: trace

Summary comment for this run: full summary

---

_{tangletools · 2026-07-24T18:43:22Z · immutable trace}

[tangletools]

🟢 Value Audit — sound

Verdict	sound
Concerns	1 (1 weak-concern)
Heuristic	0.0s
Duplication	0.0s
Interrogation	62.1s (2 bridge agents)
Total	62.1s

💰 Value — sound

Swaps the GEPA git-source pin for the tested 0.1.4 PyPI wheel in both CI and release verification — coherent, low-risk, and self-checking; ship.

• What it does: Replaces the inline git-source install of GEPA ('gepa[full] @ git+https://github.com/gepa-ai/gepa.git@f919db0...') with the published wheel ('gepa[full]==0.1.4') in the 'Install official Python optimizers' step of both .github/workflows/ci.yml:69 and .github/workflows/publish.yml:52. SkillOpt is left on its existing git source pin in both files. No other behavior changes.
• Goals it achieves: Make the verification environment use the exact published artifact developers install (reproducibility + parity with real users), drop the now-obsolete source revision, and keep SkillOpt source-pinned because its published wheel omits prompt files. Exact-pinning GEPA also matches the repo's existing strict-versioning grain (agent-eval is enforced exact at ci.yml:66 and verified in scripts/verify-o
• Assessment: Good change on its merits. The swap is symmetric across both workflows, uses an exact pin (correct for CI reproducibility), and is self-verifying: tests/official-optimization.integration.test.ts:38 imports gepa.optimize_anything, so if 0.1.4 lacks the needed surface the official-optimizers CI job fails before merge. The stated SkillOpt asymmetry is a concrete, defensible reason rather than an over
• Better / existing approach: Searched scripts/ (verify-official-optimizers.mjs, verify-package.mjs) and grepped all gepa/skillopt references repo-wide. No existing central install helper — the Python-optimizer install block is duplicated verbatim between ci.yml:62-70 and publish.yml:45-53 (pre-existing; this PR keeps them in sync). The only materially better design would be extracting that install into a shared script both wo
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 2
• Bridge warning: opencode/kimi-for-coding/k2p7: bridge stream ended without value-audit content

🎯 Usefulness — sound

Replaces an obsolete GEPA source pin with the tested 0.1.4 PyPI wheel in both CI and release verification, matching the wheel-pin pattern already used for agent-eval-rpc and gated by an end-to-end integration test.

• Integration: Fully reachable. Both edited jobs end by invoking verify:official-optimizers (ci.yml:78, publish.yml:60), which runs scripts/verify-official-optimizers.mjs -> tests/official-optimization.integration.test.ts. That test imports gepa.optimize_anything (line 38) and runs a full gepaOptimizationMethod optimization to a winner (lines 42-118), so the installed wheel is actually exercised, not just
• Fit with existing patterns: Matches the established pattern exactly. The neighboring line pins agent-eval-rpc==$RPC_VERSION as a wheel and SkillOpt as a git source; GEPA now sits in the wheel column alongside agent-eval-rpc. The PR body's stated reason for leaving SkillOpt source-pinned (0.2.0 wheel omits prompt files) is consistent with how the codebase already mixes wheel and source pins.
• Real-world viability: Holds up: the integration test runs GEPA with maxEvaluations, a cost ceiling, concurrency limits, and asserts both a winner config and non-zero evaluation/token counts (lines 108-119), so error paths in the bridge would surface. PyPI confirms 0.1.4 exists and is the latest. The only drift risk is the literal 0.1.4 duplicated across two workflow files, but that duplication pre-exists (the old git
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 1

💰 Value Audit

🟡 Python-optimizer install is duplicated across two workflows [better-architecture] ``

ci.yml:62-70 and publish.yml:45-53 contain the same multi-line pip-install block (venv, agent-eval-rpc, gepa, skillopt). This PR correctly edits both identically, but the duplication means a future single-sided edit silently desyncs CI from release verification. Consider extracting to scripts/install-official-optimizers.mjs (or a reusable composite action) so the pin lives in one place. Pre-existing; does not gate this merge.

---

What this audit checks

It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.

Pass	What it asks
Heuristic	Vague title? Whitespace-only or cruft-bearing diff? (content signals only)
Duplication	Do added function/class names already exist elsewhere in the repo?
Value Audit	What does it do? What goal does it achieve? Is it good? Better architecture or already-exists?
Usefulness Audit	Does it integrate and fit? Will it hold up in real use and actually get used?

Findings are concerns, not blocks — the human reviewer decides what to do with them.

_{value-audit · 20260724T184331Z}

[drewstone]

@tangletools review now

[tangletools]

🟢 Value Audit — sound

Verdict	sound
Concerns	0 (none)
Heuristic	0.0s
Duplication	0.0s
Interrogation	76.0s (2 bridge agents)
Total	76.0s

💰 Value — sound

Moves Python optimizer-env setup from duplicated CI bash into the verify script itself and switches GEPA to the published wheel — a clean DRY consolidation that makes local, CI, and release share one install path.

• What it does: The verify-official-optimizers.mjs script previously REQUIRED a pre-configured AGENT_EVAL_TEST_PYTHON (set up by hand-rolled bash in ci.yml AND publish.yml). It now self-provisions a throwaway venv via installOfficialOptimizers() when that env var is unset — pip-installing the published gepa[full]==0.1.4 wheel + source-pinned SkillOpt, with --only-binary=agent-eval-rpc,gepa enforcing wheels. The ~
• Goals it achieves: (1) Single install path for local + CI + release verification — eliminates the copy-pasted venv bash that existed in two workflow files. (2) Verify the PUBLISHED GEPA 0.1.4 wheel rather than a git source pin (the PR's stated title). (3) Make pnpm verify:official-optimizers runnable locally with zero pre-setup.
• Assessment: Clean, in-grain refactor. It consolidates duplicated bash (two YAML files) into one JS function, preserves the AGENT_EVAL_TEST_PYTHON override so power users keep control, and enforces published wheels via --only-binary while honestly source-pinning SkillOpt (its wheel omits prompt files). The PYTHONNOUSERSITE and --no-cache-dir flags are correct for a throwaway venv. Searched scripts/ and grepped
• Better / existing approach: none — this is the right approach. Searched scripts/*.mjs and grepped for venv/pip/AGENT_EVAL_TEST_PYTHON across the repo; the only Python env management lives in this one file. The change correctly moves duplicated YAML bash into it rather than introducing a parallel helper.
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 2
• Bridge warning: opencode/kimi-for-coding/k2p7: bridge stream ended without value-audit content

🎯 Usefulness — sound

Makes the official-optimizer verification script self-provision its Python env, so the CI/release step already wired into both workflows actually runs instead of throwing on a missing env var.

• Integration: Fully reachable and already consumed: verify:official-optimizers (package.json:73) is invoked by ci.yml:63 (official-optimizers job) and publish.yml:46 (verify job, gates npm publish). On base origin/main the script threw at line 13 when AGENT_EVAL_TEST_PYTHON was unset, yet neither workflow set it — so this PR activates infrastructure that was already wired but non-functional. The env-var overr
• Fit with existing patterns: Fits the established grain precisely. The script already owned version-pinning and rpc-bridge matching; adding venv+install keeps one self-contained verification entrypoint rather than fragmenting setup across a CI-only action (which would re-split local vs CI install paths — the exact fragmentation the PR body says it's removing). Standard python -m venv + pip install --only-binary for the wh
• Real-world viability: Holds up off the happy path: run() throws on non-zero exit with full stdout/stderr (lines 135-146); finally rmSync's tempRoot including the venv (line 98); PYTHONNOUSERSITE avoids user-site leakage (line 104); --no-cache-dir gives reproducible fresh installs; --only-binary enforces wheels so a missing sdist can't silently build; vitest runs --maxWorkers=1 so no concurrency hazard in-script. Ne
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 1

No concerns — sound change, no better or existing approach found. ✅

---

What this audit checks

It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.

Pass	What it asks
Heuristic	Vague title? Whitespace-only or cruft-bearing diff? (content signals only)
Duplication	Do added function/class names already exist elsewhere in the repo?
Value Audit	What does it do? What goal does it achieve? Is it good? Better architecture or already-exists?
Usefulness Audit	Does it integrate and fit? Will it hold up in real use and actually get used?

Findings are concerns, not blocks — the human reviewer decides what to do with them.

_{value-audit · 20260724T194508Z}

[tangletools]

✅ Auto-approved drewstone PR — bfe26f33

This PR was opened by the trusted drewstone account.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.

_{tangletools · auto-approval · reason: drewstone_author · 2026-07-24T19:47:48Z}

[tangletools]

🟡 Value Audit — sound-with-nits

Verdict	sound-with-nits
Concerns	1 (1 weak-concern)
Heuristic	0.0s
Duplication	0.0s
Interrogation	97.8s (2 bridge agents)
Total	97.8s

💰 Value — sound-with-nits

Makes the official-optimizer verification script self-provision its own Python venv (agent-eval-rpc + GEPA wheel + SkillOpt source) so CI, release, and local all run with one command — a coherent, in-grain fix; only a minor version-pinning split worth noting.

• What it does: Two changes: (1) bumps @tangle-network/agent-eval 0.126.3 -> 0.126.5 in package.json:76; (2) rewrites scripts/verify-official-optimizers.mjs so that when AGENT_EVAL_TEST_PYTHON is unset, it creates a throwaway venv under the temp dir and pip-installs agent-eval-rpc==<package.json version> (binary wheel), gepa[full]==0.1.4 (binary wheel), and SkillOpt (source-pinned to a git commit) — then runs the
• Goals it achieves: Make pnpm verify:official-optimizers executable with zero prior setup, identically in local/CI/release. This is load-bearing: both .github/workflows/ci.yml:55-63 and publish.yml:23-46 call the script after only actions/setup-python@v5 — they never set AGENT_EVAL_TEST_PYTHON and never install GEPA/SkillOpt. So before this change the official-optimizers CI job and the release verify step could n
• Assessment: Good change on its merits. It matches the codebase's existing grain precisely: the script already self-provisions its whole ephemeral environment (temp dirs, pnpm build, npm pack, npm install into a temp app dir at lines 36-74), so adding a self-provisioned Python venv is the same pattern, not a new one. installOfficialOptimizers reuses the existing run() helper; PYTHONNOUSERSITE:1 on venv c
• Better / existing approach: none — this is the right approach. Searched: grep for venv|pip install|setup-python|gepa|skillopt (41 matches, all in this script, the consuming test, README docs, or the workflow setup-python step — no shared Python-installer helper exists to reuse). The alternative of installing GEPA/SkillOpt in the workflow YAML would split the install path across two files and break the local==CI==release pa
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 2
• Bridge warning: opencode/kimi-for-coding/k2p7: bridge stream ended without value-audit content

🎯 Usefulness — sound

Consolidates the duplicated Python-optimizer install recipe from CI/release YAML into the verify script, making the official-optimizer gate self-bootstrapping and runnable identically locally, in CI, and at release.

• Integration: Fully reachable: called from ci.yml:63 (official-optimizers job) and publish.yml:46 (release verify job, gating npm publish). The script computes the python interpreter and forwards it to vitest via AGENT_EVAL_TEST_PYTHON (verify-official-optimizers.mjs:88), which the integration test reads to run vs describe.skip (tests/official-optimization.integration.test.ts:20,27). No dead surface; the capabi
• Fit with existing patterns: Fits the codebase grain and removes duplication. Previously the identical pip-install block was copy-pasted in both ci.yml and publish.yml 'Install official Python optimizers' steps, while the script separately required AGENT_EVAL_TEST_PYTHON. Now the script owns the single install recipe, matching the self-contained scripts/verify-package.mjs sibling that bootstraps its own temp environment. No c
• Real-world viability: Holds up off the happy path: setup-python@v5 provides 'python' in CI, system python locally; venv isolation via PYTHONNOUSERSITE; --only-binary=agent-eval-rpc,gepa enforces wheels as the PR intends; SkillOpt stays git-pinned with a stated reason (its 0.2.0 wheel omits prompt files); Windows venv path handled; run() fails loud on non-zero exit; the agent-eval-rpc==agent-eval version-match guard sti
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 1

💰 Value Audit

🟡 GEPA/SkillOpt versions hardcoded in the script, split from the agent-eval pin in package.json [maintenance] ``

agent-eval-rpc's version is sourced from package.json:76 (single source of truth, validated by the existing regex guard at line 17-19), but gepa[full]==0.1.4 (verify-official-optimizers.mjs:120) and the SkillOpt commit hash (line 121) are hardcoded string literals inside the .mjs file. So 'which optimizer versions we verify against' has two homes: the manifest for the RPC bridge and the script body for the two optimizers. A future GEPA bump means editing a .mjs file rather than a dependency decl

---

What this audit checks

It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.

Pass	What it asks
Heuristic	Vague title? Whitespace-only or cruft-bearing diff? (content signals only)
Duplication	Do added function/class names already exist elsewhere in the repo?
Value Audit	What does it do? What goal does it achieve? Is it good? Better architecture or already-exists?
Usefulness Audit	Does it integrate and fit? Will it hold up in real use and actually get used?

Findings are concerns, not blocks — the human reviewer decides what to do with them.

_{value-audit · 20260724T194948Z}