chore(deps): require agent-eval 0.128.2

[drewstone]

Summary

• release Knowledge 5.0.4
• require Eval 0.128.2 exactly
• require Interface 0.33.0 exactly
• remove Core 0.4.20 and Interface 0.32 from the lock

Proof

• lint and TypeScript passed
• 466 tests passed, 12 intentional skips
• package build and clean install passed
• official GEPA 0.1.4 and SkillOpt integration passed against Eval RPC 0.128.2
• branch merges cleanly into current main

[tangletools]

✅ Auto-approved drewstone PR — 4b5445bd

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-25T23:59:56Z}

[tangletools]

🟢 Value Audit — sound

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

💰 Value — sound

Routine, in-grain dependency bump: pins agent-eval 0.128.2, tightens agent-interface to exact 0.33.0, releases Knowledge 5.0.4.

• What it does: Bumps @tangle-network/agent-eval 0.127.0 → 0.128.2 (already exact-pinned), tightens @tangle-network/agent-interface from ^0.32.0 → 0.33.0 (caret to exact), and bumps the package itself 5.0.3 → 5.0.4. The lockfile (pnpm-lock.yaml) shows eval 0.128.2 transitively brings agent-core 0.4.21 and agent-interface 0.33.0, so the new exact Interface pin matches what Eval itself requires — no skew. README in
• Goals it achieves: (1) Pull in Eval 0.128.2's task-failure imports, reports, and validation fixes cited in the CHANGELOG. (2) Lock Interface to the exact 0.33.0 that the certified Knowledge↔Runtime context contract depends on (src/kb-improvement/* and src/memory/improvement/* import AgentCandidateJsonValue / AgentImprovementActivationResult from it). (3) Drop stale Core 0.4.20 and Interface 0.32 from the lock so the
• Assessment: Clean, coherent, and exactly matches the established chore(deps) pattern in this repo — prior commits bc9df72 (eval 0.127), 1d07c89, 0f5e53a, 8a5e955 all do the same version-bump-plus-changelog dance. The only policy delta is tightening Interface from caret to exact, which is justified given Interface carries shared candidate/context types imported from 20 sites in src (grep for '@tangle-network/a
• Better / existing approach: none — this is the right approach. Searched git log for prior dep-bump commits (bc9df72, 3cc4466, 1d07c89) and confirmed this PR replicates the same one-file-plus-changelog-plus-lockfile pattern; there is no existing helper/script to consolidate, and package.json:79-80 already excludes these first-party packages from pnpm's minimumReleaseAge gate, so the pinning strategy is deliberate. No duplicat
• 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

Routine exact-pin dependency bump (Eval 0.127.0→0.128.2, Interface ^0.32.0→0.33.0) following the repo's established release pattern, reachable through 89 existing import sites and gated by the official-optimizer verify script.

• Integration: Fully reachable. Both bumped packages are wired through 69 and 20 import sites respectively (e.g. src/release.ts:9, src/agent-candidate.ts:4). The exact-pin on agent-eval is mandated by scripts/verify-official-optimizers.mjs:17-19, and the agent-interface tightening to 0.33.0 matches agent-core@0.4.21's transitive requirement visible in the lock.
• Fit with existing patterns: Matches the established grain precisely. Prior releases (5.0.1/5.0.2/5.0.3) followed the identical CHANGELOG + package.json + README + lock bump pattern. No competing or duplicated mechanism.
• Real-world viability: Low-risk in practice. The change only moves version pins; all execution paths are existing ones already covered by the 466-test suite and the official GEPA/SkillOpt verify harness cited in the PR body. No new code paths introduced, so no new edge/concurrency surface.
• 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 · 20260726T000316Z}