fix(memory): use Eval experiment pairing subpath

[drewstone]

Summary

• Import pairArms from @tangle-network/agent-eval/experiment, where Eval 0.144.13 publishes it.
• Bump Knowledge to 7.2.2 and align the exact development pin and required peer floor with Eval 0.144.13.
• Record the consumer-visible compatibility fix in the changelog.

Verification

• pnpm run test — 558 passed, 12 skipped.
• pnpm run typecheck
• pnpm run lint
• pnpm run build
• pnpm run verify:package
• pnpm run verify:official-optimizers — both official integration cases passed with agent-eval-rpc 0.144.13.

Eval 0.144.13 no longer exports pairArms from its root entry. This patch uses its stable experiment entrypoint and keeps the fix in the owning package.

[tangletools]

✅ Auto-approved drewstone PR — 4c3c5ff4

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-11T23:05:24Z}

[tangletools]

🟢 Value Audit — sound

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

💰 Value — sound

One-line import move of pairArms to Eval's /experiment subpath, plus a peer/dev bump to 0.144.13 — necessary because Eval 0.144.13 dropped pairArms from its root entry; correct and in-grain.

• What it does: Changes the import of { PairedArmRow, pairArms } in src/memory/experiment/learning-pairs.ts:6 from '@tangle-network/agent-eval' (root) to '@tangle-network/agent-eval/experiment' (subpath). Aligns the agent-eval peer floor from >=0.144.11 to >=0.144.13 and the dev pin from 0.144.11 to 0.144.13, bumps this package 7.2.1 -> 7.2.2, and records the fix in CHANGELOG.md.
• Goals it achieves: Keep the published @tangle-network/agent-knowledge package building and typechecking against Eval 0.144.13. Eval removed pairArms from its root entry between 0.144.11 and 0.144.13 (verified by packing both tarballs from npm: 0.144.11 root index.d.ts has 2 pairArms matches; 0.144.13 root has 0; both keep it under /experiment). Without this change the package fails to resolve pairArms against its ow
• Assessment: Correct, minimal, and squarely in the codebase's grain. The repo already uses agent-eval subpath imports pervasively — 40+ call sites split across '@tangle-network/agent-eval' (root, for canonicalJson/contentHash/mulberry32/comparePairedArms), '@tangle-network/agent-eval/campaign', and '@tangle-network/agent-eval/rl'. Importing pairing primitives from /experiment is the same convention, not a new
• Better / existing approach: none — this is the right approach. Considered alternatives: (a) pin eval back to 0.144.11 to preserve the root import — worse, freezes on a stale eval and fights the upstream direction (root re-export is already gone). (b) Re-export pairArms locally to hide the subpath — pointless indirection, no other import in the repo does this. The /experiment subpath is the stable entrypoint upstream intends
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 2
• Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error

🎯 Usefulness — sound

Correct break-fix: Eval 0.144.13 moved pairArms from its root entry to the /experiment subpath, and this patch retargets the one import on the public memory-comparison path, plus aligns the peer floor.

• Integration: Fully reachable. pairArms is consumed in learning-pairs.ts:46 by pairAgentMemoryLearningRuns, which is called by compareAgentMemoryLearning (learning.ts:26) and runAgentMemoryLearningExperiment (learning.ts:82); both are re-exported through src/memory/experiment.ts:7-9 under the ./memory subpath (package.json:32-36). Verified against published tarballs: 0.144.13 root no longer exports pairArms (on
• Fit with existing patterns: Fits the codebase grain. This is the sole /experiment import (36 other eval imports use /campaign), but /experiment is a legitimate stable published entrypoint for pairing/pre-registration primitives, and the root import is what broke — there is no competing or better pattern. Importing PairedArmRow alongside pairArms from the same subpath is cleaner than splitting the symbol and its type across e
• Real-world viability: Mechanical import-path change plus a peer/dev version bump; no new runtime, concurrency, or edge-input surface introduced. pairArms semantics are unchanged, so behavior holds across all inputs the existing 558-test suite covers. The peer floor tightens from >=0.144.11 to >=0.144.13, matching the dev pin and the cohort-consistency pattern documented across prior changelog entries (7.1.3, 7.2.0, 7.2
• 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 · 20260811T231035Z}