chore(release): 0.138.1 — require Eval 0.146.0 and Knowledge 8.0.6

[drewstone]

Unblocks every consumer that needs @tangle-network/agent-eval/multishot/golden. That subpath is new in Eval 0.146.0, and this package's peer window stopped one version short of it, which is what blocks tangle-network/gtm-agent#902 and tangle-network/tax-agent#488.

The window is derived, not chosen

assertPeerMatchesDevelopmentDependency holds the peer range to the shape the dependency's own versioning earns. A pre-1.0 dependency stops at its next minor, because npm locks a 0.x caret to its minor. Requiring Eval 0.145.21 therefore produced >=0.145.21 <0.146.0 on its own; requiring 0.146.0 produces >=0.146.0 <0.147.0 by the same rule.

Eval 0.146.0 removes nothing

Measured by diffing the published type surfaces of 0.145.21 and 0.146.0 through the TypeScript checker, across every entry point in the exports map:

measure	0.145.21 → 0.146.0
entry points removed	0
top-level exports removed	0
interface members removed	0
top-level exports added	51

The 20 signature changes are type-precision improvements on values that were any — env?: any becoming NodeJS.ProcessEnv, Promise<any> becoming Promise<DatabaseSync | null>.

Knowledge had to move first

@tangle-network/agent-knowledge is a dependency of this package, and its own Eval peer capped <0.146.0. verify:package installs the packed tarball beside it, so this gate could not pass until Knowledge 8.0.6 published.

The fixtures carry the version

src/testing/fixtures/*.json pin runtimeVersion, and tests/testing-fixture.test.ts compares them against the live manifest, so the version bump regenerates them through pnpm generate:testing-fixture. pnpm check:testing-fixture reports current.

Proof

pnpm typecheck   clean (tsc --noEmit + examples)
pnpm test        218 files passed | 2 skipped, 2740 tests passed | 6 skipped
pnpm verify:package
  @tangle-network/agent-core:      one 0.9.4 installation.
  @tangle-network/agent-eval:      one 0.146.0 installation.
  @tangle-network/agent-interface: one 1.0.0 installation.
  @tangle-network/agent-knowledge: one 8.0.6 installation.
  @tangle-network/sandbox:         one 0.27.1 installation.
  Edge module-load safety: 8 first-party packages, 323 shipped files, no blocked static imports.
  Edge tool loop: packed Worker bundled and executed without Node compatibility.

[drewstone]

@tangletools review now

[tangletools]

✅ Auto-approved drewstone PR — c0735244

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.

This approval is provisional. It rests on the audit running. If the audit cannot run — for example the CLI bridge rejects it — this approval is dismissed rather than left standing, so an unrun check never reads as a passing one.

_{tangletools · auto-approval · reason: drewstone_author · 2026-08-16T22:33:23Z}

[tangletools]

✅ Auto-approved drewstone PR — c0735244

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.

This approval is provisional. It rests on the audit running. If the audit cannot run — for example the CLI bridge rejects it — this approval is dismissed rather than left standing, so an unrun check never reads as a passing one.

_{tangletools · auto-approval · reason: drewstone_author · 2026-08-16T22:33:26Z}

[tangletools]

✅ Auto-approved drewstone PR — c0735244

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.

This approval is provisional. It rests on the audit running. If the audit cannot run — for example the CLI bridge rejects it — this approval is dismissed rather than left standing, so an unrun check never reads as a passing one.

_{tangletools · auto-approval · reason: drewstone_author · 2026-08-16T22:44:50Z}

[tangletools]

🟢 Value Audit — sound

Verdict	sound
Coverage	2 of 2 lenses (value, usefulness)
Concerns	0 (none)
Heuristic	0.0s
Duplication	0.0s
Interrogation	114.9s (2 bridge agents)
Total	114.9s

💰 Value — sound

A minimal, machinery-driven release bump that moves the Eval peer window to 0.146.0 to unblock consumers of the new multishot/golden subpath; exactly the right change, done the way this repo already does it.

• What it does: Bumps @tangle-network/agent-runtime from 0.138.0 to 0.138.1 and moves the @tangle-network/agent-eval peer window from '>=0.145.21 <0.146.0' to '>=0.146.0 <0.147.0' (package.json:173), bumps the workspace catalog to Eval 0.146.0 and Knowledge 8.0.6 (pnpm-workspace.yaml) plus the lockfile, adds a CHANGELOG entry, and regenerates the two testing fixtures whose digests/runIds/runtimeVersion embed the
• Goals it achieves: Unblocks downstream consumers that import '@tangle-network/agent-eval/multishot/golden' (new in Eval 0.146.0): the previous peer window capped below 0.146.0, so npm would refuse co-installation for repos like gtm-agent and tax-agent. Keeps this package's published peer contract aligned with the Eval version it actually develops against, per the repo's own enforcement tooling.
• Assessment: Good on its merits. The change is the established release pattern in this repo (prior commits 9e6d7c9 'widen the agent-interface peer', bfa66ec 'declare the agent-interface peer as a caret range' are the same shape). The peer window is not hand-picked: assertPeerMatchesDevelopmentDependency (scripts/lib/packed-package-test.mjs:68) is invoked by verify-package-exports.mjs:72, verify-packed-cohort.m
• Better / existing approach: none — this is the right approach. A wider window spanning both 0.145.x and 0.146.x would be rejected by the repo's own assertPeerMatchesDevelopmentDependency gates, and the change reuses the existing release machinery (prepare-release, check-version-bump, verify:package, fixture check/generate scripts) rather than inventing anything. Searched: git log for prior chore(release) commits, scripts/lib
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 2
• Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error

🎯 Usefulness — sound

A mechanically-derived peer-window bump that unblocks real consumers needing agent-eval's new multishot/golden subpath, with fixture regeneration forced by an existing live-manifest test — every claim in the PR body checked out against the repo and registry.

• Integration: Fully wired. The peer range is not hand-picked: assertPeerMatchesDevelopmentDependency (scripts/lib/packed-package-test.mjs:68) derives it from the dev dependency via expectedPeerRange (scripts/lib/packed-package-test.mjs:51), which maps a pre-1.0 pin to '>=X.Y.Z <X.Y+1.0'. The catalog moved agent-eval to 0.146.0 (pnpm-workspace.yaml:23), forcing the new window; the lockfile resolves eval 0.146.0
• Fit with existing patterns: Matches the repo's established release discipline precisely — prior release bfa66ec ('0.138.0... declare the agent-interface peer') is the same genre, and the fixture regeneration is mandated by tests/testing-fixture.test.ts:31,62, which asserts each fixture's runtimeVersion equals the live package.json version. The check:testing-fixture gate is embedded in verify:package (package.json:139). No ne
• Real-world viability: The window excludes eval 0.147.0 when it arrives, so every future eval minor forces another runtime release — but that is the deliberate pre-1.0 policy encoded and documented in expectedPeerRange (scripts/lib/packed-package-test.mjs:43-55), not a defect introduced here. Error paths are covered: the derivation throws on malformed versions and the packed-tarball verification (verify:package) install
• 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 · 20260817T004120Z}

[drewstone]

@tangletools review now

[tangletools]

❌ Needs Work — c0735244

Review health 100/100 · Reviewer score 70/100 · Confidence 85/100 · 4 findings (1 high, 1 medium, 2 low)

	opencode GLM 5.2	opencode DeepSeek v4 Pro	opencode DeepSeek v4 Flash	aggregate
Readiness	92	70	82	70
Confidence	85	85	85	85
Correctness	92	70	82	70
Security	92	70	82	70
Testing	92	70	82	70
Architecture	92	70	82	70

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

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

Blocking

🔴 HIGH Peer range bumped but CI/publish cohort checkout pins not updated — verify-packed-cohort will fail — package.json

package.json:173 raises the @tangle-network/agent-eval peer floor to '>=0.146.0 <0.147.0', and pnpm-workspace.yaml (same PR) bumps the catalog to agent-eval@0.146.0 and agent-knowledge@8.0.6. But .github/workflows/ci.yml:91,98 and .github/workflows/publish.yml:146,154 still checkout the cohort at agent-eval@0.145.21 (f99af3aa) and agent-knowledge@8.0.5 (662c8742). scripts/verify-packed-cohort.mjs runs assertCohortPackageContracts -> assertExactDependency(agentRuntime, agentKnowledge) (line 590), which throws at lines 601-611 because the runtime's dependencies

Other

🟠 MEDIUM Catalog bump not propagated to generated and curated docs; docs:check CI gate will fail — pnpm-workspace.yaml

The agent-eval pin moves 0.145.21 -> 0.146.0 and agent-knowledge 8.0.5 -> 8.0.6 (pnpm-workspace.yaml:23,25), and package.json peer moves to >=0.146.0 <0.147.0, but neither docs file was updated in this PR. docs/canonical-api.md:9 still states agent-eval must satisfy >=0.145.21 <0.146.0, and docs/api/primitive-catalog.md:10 is generated from @tangle-network/agent-runtime@0.138.0 and @tangle-network/agent-eval@0.145.21. Evidence chain: CI runs pnpm run docs:check (.github/workflows/ci.yml:71) = docs:api && git diff --exit-code -- docs/api && docs:freshness. scripts/gen-primitive-catalog.mjs:368-369 emits the header live from the installed package, which after this bump resolves to 0.146.0 (and, per the commit message, gains 51 exports), so git diff --exit-code -- docs/api is no

🟡 LOW Peer floor move in a patch release forces concurrent consumer upgrade — package.json

The window drops 0.145.x entirely (was >=0.145.21 <0.146.0, now >=0.146.0 <0.147.0) while the package version moves only 0.138.0→0.138.1. Consumers on runtime 0.138.x with agent-eval 0.145.21 pinned will hit npm ERESOLVE on upgrading to 0.138.1 until they also bump agent-eval to 0.146.0. This is the declared intent of the release ('require Eval 0.146.0'), matches the repo's documented pre-1.0 peer-window convention, and the lockfile shows the new floor resolves cleanly — but downstream upgrade docs/release notes should state the co-required agent-eval bump. No code change needed in this PR.

🟡 LOW Peer floor narrowing is a breaking constraint for consumers pinned to Eval <0.146.0 — package.json

peerDependencies.@tangle-network/agent-eval moves from ">=0.145.21 <0.146.0" to ">=0.146.0 <0.147.0", which drops support for consumers still on Eval 0.145.x. This is intentional and machine-derived (expectedPeerRange in scripts/lib/packed-package-test.mjs, and the release policy documented in CHANGELOG.md), and the code was type-checked against 0.146.0, so the floor equals the tested version. No action required; flagged for completeness since the change is shipped as a patch (0.138.1), not a minor. Consumers must upgrade Eval simultaneously.

---

_{tangletools · 2026-08-17T00:51:38Z · trace}

[tangletools]

❌ 1 Blocking Finding — c0735244

Full multi-shot audit completed 5/5 planned shots over 6 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 5/5 planned shots over 6 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 5/5 planned shots over 6 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-17T00:51:38Z · immutable trace}

[drewstone]

Blocking finding addressed, plus the two it implied.

The HIGH named ci.yml only for the cohort checkout pins; publish.yml:146,154 carried the same stale refs and would have packed a version the release does not require, so both files now point at agent-eval@0.146.0 (76969e55) and agent-knowledge@8.0.6 (9a1079dd).

The MEDIUM is closed too: docs/api/primitive-catalog.md is regenerated (now agent-runtime@0.138.1 / agent-eval@0.146.0), docs/canonical-api.md states the 0.146.0 window and the released version.

bench/package.json moves to 0.8.13 because its catalog dependencies change with this release and 0.8.12 is already published.

Local proof on this head: node scripts/check-version-bump.mjs exit 0 (bench 0.8.12→0.8.13, root 0.138.0→0.138.1 both accounted), pnpm docs:check exit 0. CI on the prior push already had packed-cohort, official-optimizers and agent-bench green.

@tangletools review now

[tangletools]

❌ Needs Work — c0735244

Review health 100/100 · Reviewer score 54/100 · Confidence 85/100 · 6 findings (1 high, 1 medium, 4 low)

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

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

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

Blocking

🔴 HIGH Cohort source pins in ci.yml/publish.yml not bumped with the catalog, breaking packed-cohort verification — pnpm-workspace.yaml

The catalog now requires agent-eval 0.146.0 and agent-knowledge 8.0.6, but .github/workflows/ci.yml:91,98 and .github/workflows/publish.yml:146,154 still check out agent-eval at ref f99af3aa (@0.145.21) and agent-knowledge at 662c874 (@8.0.5) for the packed-cohort job. The packed runtime archive declares dependencies['@tangle-network/agent-knowledge']='8.0.6' (catalog: is substituted on pack; assertPublishableDependencySpecs would throw otherwise) and peer agent-eval '>=0.146.0 <0.147.0'. verify-packed-cohort.mjs assertExactDependency (line 601) compares declared 8.0.6 vs packed 8.0.5 and throws 'requires @tangle-network/agent-knowledge@8.0.6, packed 8.0.5' (the spec is

Other

🟠 MEDIUM Docs freshness gate will fail: canonical-api.md and primitive-catalog.md still pin eval 0.145.21 — pnpm-workspace.yaml

scripts/check-docs-freshness.mjs (CLASS 1, lines 190-235) requires docs/canonical-api.md substrate pins to match the package.json peer floor. docs/canonical-api.md:9 still says agent-eval must satisfy '>=0.145.21 <0.146.0' while the peer floor is now 0.146.0 -> SUBSTRATE mismatch report -> 'pnpm run docs:check' (ci.yml:71) fails. Additionally docs/api/primitive-catalog.md is generated from the LIVE installed agent-eval (scripts/gen-primitive-catalog.mjs resolves node_modules, which the catalog now installs at 0.146.0), so its committed header 'GENERATED from ... agent-eval@0.145.21' is stale and the regenerable-identical check (check-docs-freshness.mjs:589-629) fai

🟡 LOW Changelog omits the forced consumer move that the 0.137.0 entry documented for the same kind of change — CHANGELOG.md

The 0.137.0 entry (line 64) explicitly stated 'A consumer holding sandbox 0.27.0 must move to 0.27.1' when a peer window shifted; the 0.138.1 entry shifts the Eval peer window from '>=0.145.21 <0.146.0' to '>=0.146.0 <0.147.0' without stating that a consumer on Eval 0.145.21 cannot take 0.138.1 without upgrading Eval. Impact is low because the entry proves 0.146.0 removes nothing, but the migration note convention set by the prior entry is dropped. Fix: add one sentence naming the forced move, e.g. 'A consumer holding Eval 0.145.21 must move to 0.146.0, which removes nothing.'

🟡 LOW External type-surface claims not reproducible from this repo — CHANGELOG.md

The sentence 'Diffing the two published type surfaces ... removes no entry point, no top-level export and no interface member, and adds 51 exports. The 20 signature changes are type-precision improvements' cites a TypeScript-checker diff of published Eval packages. No script or artifact in this repo records that audit, so a future reader cannot reproduce it and the claim cannot be re-verified from the repo. Impact is documentation trust only; the peer-range claims (the load-bearing part) are fully reproducible via expectedPeerRange. Fix: reference the audit artifact/script or drop the precise counts.

🟡 LOW Patch release narrows the agent-eval peer window, forcing ERESOLVE for consumers on 0.145.x — package.json

The peer range drops >=0.145.21 <0.146.0, so a consumer holding agent-eval 0.145.x who upgrades to agent-runtime 0.138.1 (auto within ^0.138.0) hits a peer conflict and must also bump agent-eval to 0.146.0. Evidence: diff of line 173 plus npm peer resolution semantics. This is intentional house policy: the range is machine-derived (scripts/lib/packed-package-test.mjs:51, enforced by assertPeerMatchesDevelopmentDependency) and the CHANGELOG documents the compatibility analysis. Informational only; no change required.

🟡 LOW Peer-window bump shipped as a patch release is semver-visible to consumers — package.json

peerDependencies @tangle-network/agent-eval narrowed from >=0.145.21 <0.146.0 to >=0.146.0 <0.147.0 inside a patch release (0.138.0 -> 0.138.1). Consumers resolving agent-eval@0.145.x will see a peer-resolution failure when upgrading agent-runtime to 0.138.1. This is intentional per the repo's derived-window policy for pre-1.0 deps (stop at next minor) and the commit verifies the published surface is unchanged, so it is an informational note, not a blocking defect. If the maintainers want zero peer churn in patch releases, this belongs in a minor bump — but that is policy, and the change is internally consistent as-is.

---

_{tangletools · 2026-08-17T00:57:00Z · trace}

[tangletools]

❌ 1 Blocking Finding — c0735244

Full multi-shot audit completed 5/5 planned shots over 6 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 5/5 planned shots over 6 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 5/5 planned shots over 6 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-17T00:57:00Z · immutable trace}

[tangletools]

✅ Auto-approved drewstone PR — 82073e05

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.

This approval is provisional. It rests on the audit running. If the audit cannot run — for example the CLI bridge rejects it — this approval is dismissed rather than left standing, so an unrun check never reads as a passing one.

_{tangletools · auto-approval · reason: drewstone_author · 2026-08-17T01:02:47Z}

[tangletools]

🟢 Value Audit — sound

Verdict	sound
Coverage	2 of 2 lenses (value, usefulness)
Concerns	0 (none)
Heuristic	0.0s
Duplication	0.0s
Interrogation	242.6s (2 bridge agents)
Total	242.6s

💰 Value — sound

A minimal, mechanically-forced patch release that moves the required agent-eval peer window to 0.146.0 so consumers can reach the new multishot/golden subpath — exactly the repo's established release discipline.

• What it does: Bumps @tangle-network/agent-runtime 0.138.0→0.138.1 and moves the required @tangle-network/agent-eval peer from >=0.145.21 <0.146.0 to >=0.146.0 <0.147.0 (package.json:173), which unblocks consumers of the agent-eval/multishot/golden subpath new in Eval 0.146.0. The workspace catalog now pins agent-eval 0.146.0 and agent-knowledge 8.0.6 (pnpm-workspace.yaml:23,25); the two testing fixtures that em
• Goals it achieves: Unblocks every consumer needing Eval 0.146.0's new multishot/golden subpath (cited: gtm-agent#902, tax-agent#488) by widening the accepted peer floor to include it. Secondarily keeps the whole first-party cohort on one resolved Eval copy — the documented bench pattern (bench/CHANGELOG.md:7 'the first-party cohort this benchmark resolves through the workspace catalog moves with the runtime'). The p
• Assessment: Good on its merits, and exactly in the grain of the codebase. The repo's own gates make every part of this PR mandatory rather than discretionary: (1) scripts/check-version-bump.mjs — covered by tests/version-bump-check.test.ts:121-139 'rejects a peer range move that keeps the same version' — forces the 0.138.1 bump because the peer range moved; (2) assertPeerMatchesDevelopmentDependency forces th
• Better / existing approach: none — this is the right approach. I searched for an alternative before answering: (a) a caret peer (^0.146.0) is deliberately unavailable — expectedPeerRange (scripts/lib/packed-package-test.mjs:51-55) grants caret only from 1.0.0, with the rationale documented at lines 43-50 (a pre-1.0 minor may remove, so a caret would risk two installed copies); agent-interface got its caret only when it hit 1
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 3
• Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error

🎯 Usefulness — sound

A mechanically-derived peer-window release that unblocks two verified downstream consumers; every claim in the PR body checks out against the registry and the live repos.

• Integration: Fully wired and imminently consumed. The peer change at package.json:173 (>=0.146.0 <0.147.0) is not hand-picked: scripts/lib/packed-package-test.mjs:51-55 derives a pre-1.0 dependency's window as its next minor, and assertPeerMatchesDevelopmentDependency (packed-package-test.mjs:68) is enforced by verify-package-exports.mjs:72, verify-packed-cohort.mjs:595, and verify-official-optimizers.mjs:93 —
• Fit with existing patterns: Follows the repo's established release chore exactly: catalog pin + derived peer window + version-bump gate + fixture regeneration is the same pattern as every prior release (check-version-bump.mjs validated '2 consumer-visible changes paid for by 0.138.0 -> 0.138.1' and the bench 0.8.12 -> 0.8.13 bump). No competing mechanism exists — this is the only channel through which the peer window moves.
• Real-world viability: Holds under realistic use. The narrow <0.147.0 cap means the next eval minor forces another release, but that is the repo's deliberate pre-1.0 discipline (documented at packed-package-test.mjs:43-50), not brittleness introduced here. The PR body's compat table (0 removed exports, 51 added, 20 any-tightening signature changes) is consistent with 0.146.0 being additive; the fixtures are digest-verif
• 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 · 20260817T011221Z}