chore(deps): align knowledge with eval 0.144.3

[drewstone]

Why

Agent Knowledge 7.0.9 declares Agent Eval 0.144.1, which installs an older Eval copy beside Runtime 0.129.0 and blocks the exact published package-set check.

Change

• require published @tangle-network/agent-eval@0.144.3
• release Agent Knowledge as 7.0.10
• update the exact install example and lockfile

Direct proof

• 545 tests passed; 12 skipped
• source and contract typechecks passed
• lint passed across 203 files
• build produced 35 files
• packed clean-install/public-import/CLI/skill/repack checks passed
• official GEPA and SkillOpt integrations passed 2/2 with agent-eval-rpc==0.144.3
• npm pack --dry-run: 50 files, 679.5 kB packed
• clean merge tree against current origin/main: 4fdc6e0fa24489519050d5bae8ef7a39effbc17b

[tangletools]

✅ Auto-approved drewstone PR — 140ab0fc

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-08-04T04:46:40Z}

[tangletools]

🟢 Value Audit — sound

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

💰 Value — sound

Two-line routine dep pin bump (agent-eval 0.144.1→0.144.3, knowledge patch release 7.0.9→7.0.10) that follows this repo's established exact-pin alignment pattern; nothing architecturally to object to.

• What it does: Bumps the exact-pinned @tangle-network/agent-eval dependency from 0.144.1 to 0.144.3 (package.json:78) and bumps this package's own version from 7.0.9 to 7.0.10 (package.json:3). No other files change — no source, no lockfile-in-repo (pnpm pulls the new pin), no API surface.
• Goals it achieves: Keep the published agent-knowledge package's exact dependency pin in lockstep with the freshly published agent-eval 0.144.3, so installs no longer drag in an older eval copy beside runtime 0.129.0 and the repo's 'exact published package-set' check goes green. This goal is read straight off the change and the established commit cadence.
• Assessment: Good change. The repo deliberately pins tangle-network sibling deps exactly (0.144.3, 0.43.0, 4.1.2 at package.json:78-80) to enforce a single coherent published cohort — exactly what the AGENTS.md 'Integration Boundaries' section calls for, and what the last 5+ commits in the log do (9fc3c6d 'align with eval 0.144.1', b60ce17 'align with eval 0.143', etc.). A patch-version forward-bump with a mat
• Better / existing approach: none — this is the right approach. Verified via git log: the 5 prior merges (b67218f, 7111e31, b60ce17, 9fc3c6d, ea213f2) all use this same single-file package.json bump for sibling-version alignment, so this is the established grain, not a reinvention. The only design lever would be switching from exact pins to ^ ranges, but the repo intentionally rejects that to keep the published set check me
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 2
• Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error

🎯 Usefulness — sound

Clean dependency bump of @tangle-network/agent-eval 0.144.1→0.144.3 with consistent lockfile, README, and CHANGELOG; the dependency is heavily consumed across the codebase.

• Integration: agent-eval is a foundational dependency imported in 77 sites across src/ (canonicalJson/contentHash utilities, RunRecord validation, campaign storage, paired-arm comparison, holdout significance, etc. — e.g. src/release.ts:9, src/optimization.ts:1, src/kb-improvement/contracts.ts:1, src/memory/improvement/promotion.ts:1). The bumped version is reached by every optimization, RAG, memory, and benchm
• Fit with existing patterns: Follows the established chore(deps) alignment pattern — git log shows three prior identical-shape bumps in the last 10 commits (eval 0.143, eval 0.144.1, interface 0.43). Lockfile, README install example, and CHANGELOG all updated in lockstep, matching the repo's release discipline. No competing pattern.
• Real-world viability: Pure version-string bump with no API surface change; resolves the exact-published-package-set check by removing the dual-eval-version install the PR body describes. The lockfile integrity hash is updated and consistent with the specifier, so pnpm install --frozen-lockfile will hold. No new code paths introduced, so no new concurrency/edge-case exposure.
• 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 · 20260804T044905Z}