fix(release): align Knowledge with Eval 0.145.2

[drewstone]

Problem

Knowledge 7.2.4 must track the current shared Eval and Interface release cohort.

Change

• Raise the Eval peer floor to >=0.145.2 <0.146.0.
• Raise the Interface peer floor to >=0.47.0 <0.48.0.
• Pin Eval 0.145.2 and Interface 0.47.0 in development and the lockfile.
• Release as 7.2.4 with matching CHANGELOG and README install instructions.

Verification

• pnpm install --frozen-lockfile --ignore-scripts passes with one Eval 0.145.2, Core 0.6.1, and Interface 0.47.0.
• Typecheck (source and contracts), 558 tests (12 skipped), lint, build, package verification, and official optimizer integration pass locally.
• Eval 0.145.2 is live on npm and PyPI from publish workflow 31607031698.

[tangletools]

✅ Auto-approved drewstone PR — f2ba23a8

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-12T08:27:33Z}

[tangletools]

⚠️ Review Interrupted — f2ba23a8

The review runner stopped before publishing a final verdict: webhook_restarted.

State	Detail
Interrupted	webhook restarted

No review verdict was produced for this run. Trigger a fresh review on the current PR head if the PR is still open.

_{tangletools · #123 · model: kimi-for-coding · updated 2026-08-12T11:21:08Z}

[tangletools]

✅ Auto-approved drewstone PR — f2ba23a8

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-12T11:47:30Z}

[tangletools]

🟢 Value Audit — sound

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

💰 Value — sound

Raises the Eval peer floor from 0.145.0 to 0.145.1 so deduped Eval copies still satisfy the root pairArms import that older published Knowledge dists depend on — minimal, correct, in-grain.

• What it does: Bumps three fields in package.json: the package version (7.2.3 → 7.2.4), the @tangle-network/agent-eval peer range floor (>=0.145.0 → >=0.145.1), and the exact dev pin (0.145.0 → 0.145.1). README install line and CHANGELOG entry are updated to match. No source code changes.
• Goals it achieves: Ensures that when a consumer resolves a single shared Eval copy under Knowledge's peer range, that copy (0.145.1+) carries the root pairArms export. This matters for already-published older Knowledge dists (7.0.x–7.2.1) which import pairArms from the eval root barrel (git show 077017c:src/memory/experiment/learning-pairs.ts shows import { pairArms } from '@tangle-network/agent-eval'). With
• Assessment: Good change on its merits. The current source already moved pairArms to the /experiment subpath at learning-pairs.ts:6 (PR #121 / Knowledge 7.2.2), so the current dist does not need the root export — the floor bump is purely a compatibility guard for already-published dists, which is the only lever a new release has (you cannot republish old dists). The change is the smallest possible: one flo
• Better / existing approach: none — this is the right approach. Searched for alternatives: (1) re-exporting pairArms from Knowledge's own root would not help old dists that already reference the eval root directly; (2) republishing old dists is impossible on npm; (3) dropping the peer floor would reintroduce the dedupe-to-0.145.0 hazard. The fragile coupling between Knowledge and Eval's export surface (root vs /experiment
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 2
• Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error

🎯 Usefulness — sound

Correct, low-risk peer-floor alignment to Eval 0.145.1 (the patch that restored a root export older published Knowledge dists need), following a well-established repo pattern.

• Assessment: Sound coordination release that does its job. One subtlety worth noting (not a flaw): the current Knowledge source does not strictly require 0.145.1 for its own imports — it moved pairArms to the /experiment subpath in 7.2.2, so its own pairArms usage works on 0.145.0 too. The floor bump's direct benefit is defensive: it forces consumers who mix this Knowledge with older published dists (7.0.8/7.0
• Integration: The change is pure dependency-metadata (package.json:82,89 + pnpm-lock). It is consumed by every npm/pnpm install of @tangle-network/agent-knowledge@7.2.4 — the peer range IS the integration surface, and the lock confirms a single resolved Eval 0.145.1 copy. The current source's only pairArms import resolves via the /experiment subpath (src/memory/experiment/learning-pairs.ts:6), unaffected by the
• Fit with existing patterns: This is the established, repeated pattern in this repo: git log shows 7+ identical 'align Knowledge with Eval X.Y.Z' commits (0.143, 0.144.1, 0.144.3, 0.144.8, 0.144.11, 0.145.0, now 0.145.1). The CHANGELOG documents the full coordination thread — 7.2.0 made Eval a required peer, 7.2.2 moved pairArms to the subpath, 7.2.3/7.2.4 track the 0.145.x patches. The bump follows the grain exactly.
• Real-world viability: Metadata-only; no runtime behavior changed. The range >=0.145.1 <0.146.0 is correctly bounded within the minor. The only theoretical risk is excluding a consumer pinned at 0.145.0, but 0.145.0→0.145.1 is a same-minor patch and 0.145.0 carried the root-export regression, so there is no reason to stay. Holds up trivially.
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 1

💰 Value Audit

🟡 Root-vs-subpath export churn signals fragile Eval barrel coupling [maintenance] ``

pairArms has bounced: Knowledge 7.2.2 (PR #121) moved its import to /experiment to dodge Eval 0.144.13 dropping the root export; now 7.2.4 raises the peer floor because Eval 0.145.1 restored the root export for old dists' sake. Each Eval release that touches the root barrel forces a Knowledge alignment release. This is inherent to the peer-dependency layering in AGENTS.md and not actionable from Knowledge's side for already-published dists, but a stable barrel commitment on the Eval side wou

---

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 · 20260812T122334Z}

[tangletools]

✅ No Blockers — f2ba23a8

Review health 100/100 · Reviewer score 89/100 · Confidence 80/100 · 2 findings (2 low)

	opencode GLM 5.2	opencode DeepSeek v4 Pro	opencode DeepSeek v4 Flash	aggregate
Readiness	95	95	89	89
Confidence	80	80	80	80
Correctness	95	95	89	89
Security	95	95	89	89
Testing	95	95	89	89
Architecture	95	95	89	89

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

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

🟡 LOW README pins 7.2.4 before it is published — README.md

The install snippet references @tangle-network/agent-knowledge@7.2.4, which returns E404 on the npm registry at review time (verified via npm view). This is the normal release ordering: package.json version is 7.2.4 and publishing follows merge, so users following README before publish get a 404. Informational only; no action needed if the release pipeline publishes immediately after merge.

🟡 LOW Peer floor raise is a de-facto breaking change shipped as a patch — package.json

peerDependencies @tangle-network/agent-eval narrowed from '>=0.145.0 <0.146.0' to '>=0.145.1 <0.146.0' while the package version bumps only 7.2.3→7.2.4. Under strict pnpm peer resolution, consumers pinned to eval 0.145.0 (which satisfied 7.2.3 and on which this repo's own dist works, since it imports pairArms from the 'experiment' subpath) will now hit a peer conflict when upgrading to 7.2.4. This is intentional cohort safety for older published dists that import pairArms from the eval root, and it is documented in CHANGELOG.md; it is also consistent with prior alignment releases (7.2.1→7.2.2→7.2.3). Noting only for semver strictness; no change required.

---

_{tangletools · 2026-08-12T12:25:25Z · trace}

[tangletools]

✅ Approved — 2 non-blocking findings — f2ba23a8

Full multi-shot audit completed 4/4 planned shots over 4 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 4/4 planned shots over 4 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 4/4 planned shots over 4 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-08-12T12:25:25Z · immutable trace}

[drewstone]

@tangletools review now

[tangletools]

✅ No Blockers — 31df8ce8

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 4 changed files. Global verifier still owns final merge decision.

No findings.

---

_{tangletools · 2026-08-12T14:49:15Z · trace}

[tangletools]

✅ Clean — 31df8ce8

Full multi-shot audit completed 1/1 planned shots over 4 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-08-12T14:49:15Z · immutable trace}

[tangletools]

🟢 Value Audit — sound

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

💰 Value — sound

Mechanical peer-dependency cohort bump (Knowledge 7.2.3→7.2.4, Eval floor 0.145.1→0.145.2, Interface cohort 0.46.x→0.47.x) — internally consistent across all four files and matches a twice-weekly pattern in git log; ship.

• What it does: Raises the agent-eval peer floor from >=0.145.1 to >=0.145.2 and the agent-interface peer cohort from >=0.46.1 <0.47.0 to >=0.47.0 <0.48.0; pins the matching dev dependencies; updates pnpm-lock.yaml (also transitively pulling agent-core 0.5.4→0.6.1); bumps this package 7.2.3→7.2.4; updates CHANGELOG.md and the README install line. No source or contract files change.
• Goals it achieves: Keep the published Knowledge package tracking the current shared Eval/Interface contract cohort so consumers who install latest get mutually-compatible versions. The lockfile also gets agent-core 0.6.1, the version Eval 0.145.2 depends on.
• Assessment: Good change, in the grain of the repo. Git log shows this exact commit shape repeated roughly every 1–3 days for weeks (f2ba23a 0.145.1, c1279c5 0.145.0, 07b5c6c 0.144.11, 84f6079 0.144.8, 3b56d3b/4c29d55 interface cohort moves). All four modified files are internally consistent: package.json peer + dev specifiers, lockfile specifier + resolved version, CHANGELOG entry, and README install instruct
• Better / existing approach: none — this is the right approach. There is no design choice to make; this commit IS the repo's established mechanism for tracking the shared peer cohort (visible across ~6 identical prior commits in git log). I grepped for any automation or script that generates these bumps (release.mjs, changeset, release-please config) and found none — they're authored by hand per the git log, which is acceptab
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 2
• Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error

🎯 Usefulness — sound

Routine peer/dev/lock triple-bump tracking the freshly-published Eval 0.145.2 and Interface 0.47.0; the package depends on both heavily, the bump is internally consistent, and it follows the established alignment cadence.

• Integration: The bumped peers are deeply reachable: src/optimization.ts:1, src/retrieval-eval.ts:1, src/release.ts:9, src/propose-from-finding.ts:26, src/benchmarks/suite.ts:3, src/memory/improvement/run.ts:2, src/kb-improvement/contracts.ts:1 and ~50 more sites import canonicalJson/contentHash/CampaignStorage/RunRecord/AgentCandidateJsonValue/etc. from @tangle-network/agent-eval and @tangle-network/agent-inte
• Fit with existing patterns: This is the codebase's established release-alignment pattern. The prior two commits on this branch are identical in shape: f2ba23a 'align Knowledge with Eval 0.145.1' and c1279c5 'align Knowledge with Eval 0.145.0 (#122)'. Same 4-file surface (package.json, pnpm-lock.yaml, README.md, CHANGELOG.md), same peer-floor-raises-with-dev-pin-and-lockfile coherence. No competing or duplicate mechanism exis
• Real-world viability: Pure metadata: no behavioral code changes, so concurrency/error/edge-case surface is unchanged. The lockfile is internally consistent (specifier + resolved version both move in lockstep for all three tangle-network packages, including the transitive agent-core bump that flows through agent-eval's own deps). The only failure mode is install-resolution, which the frozen-lockfile pinning eliminates.
• 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 · 20260812T144924Z}