chore(release): 8.0.9 — require Eval 0.148.0 - #156
Conversation
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
✅ Auto-approved drewstone PR — 7efad008
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-18T20:54:01Z
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
🟢 Value Audit — sound
| Verdict | sound |
| Coverage | 2 of 2 lenses (value, usefulness) |
| Concerns | 1 (1 weak-concern) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 70.0s (2 bridge agents) |
| Total | 70.0s |
💰 Value — sound
A minimal, established-pattern release bump that admits the Eval 0.148.0 / Interface 1.1.0 contract cohort into the peer ranges and ships 8.0.9; it is exactly in the grain of this repo's documented release mechanism.
- What it does: Bumps the package version 8.0.8 -> 8.0.9 and moves the contract cohort in package.json:85-88 — the agent-eval peer range goes from
>=0.147.0 <0.148.0to>=0.148.0 <0.149.0(dev pin 0.147.0 -> 0.148.0) and the agent-interface peer floor from^1.0.0to^1.1.0(dev pin 1.0.0 -> 1.1.0). The commit also updates pnpm-lock.yaml (Eval 0.148.0, Interface 1.1.0, agent-core now resolving Interface 1. - Goals it achieves: Unblocks strict installs once agent-runtime adopts Eval 0.148.0: because Eval is pre-1.0, npm locks a 0.x range to its minor, so the old window physically cannot admit 0.148.0 and any cohort install with it fails ERESOLVE. The Interface floor moves because Eval 0.148.0 depends on Interface
^1.1.0and the repo's verify-package assertion requires one installed copy of each cohort member (scripts/v - Assessment: Good on its merits. This is the repo's established, deliberately documented mechanism — identical bumps at 8.0.3/8.0.4/8.0.5 (CHANGELOG.md:20-38), 8.0.6 (commit 9a1079d), and 8.0.7 (commit 8baaf2b, whose package.json diff is byte-for-byte the same shape). The peer-range philosophy is an explicit documented decision, not an accident: pre-1.0 Eval gets a one-minor window because 0.x minors carry no
- Better / existing approach: none — this is the right approach. I looked for alternatives: widening the Eval window (e.g.
>=0.148.0 <0.150.0) would reduce release churn (three cohort bumps in four days) but contradicts the documented rationale that a 0.x minor may remove exports, so the tight window is the safety property, and the churn cost is one automated line per Eval minor. I also checked for any existing in-repo mecha - Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 2
- Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error
🎯 Usefulness — sound
A minimal, machine-checked peer-range release that admits Eval 0.148.0, exactly following the repo's established release cadence and unblocking the imminent Runtime adopter.
- Integration: Fully wired and imminently consumed. Runtime PR tangle-network/agent-runtime#897 (OPEN, 'test(integration): prove Runtime pursuit evidence through Eval') is the adopter; runtime's published manifest depends on '@tangle-network/agent-knowledge': '^8.0.8' and peers eval '>=0.147.0 <0.148.0' (verified via npm view), so once #897 moves runtime to Eval 0.148.0, knowledge 8.0.9 is the only published ver
- Fit with existing patterns: This is the codebase's established pattern, not a new one: git history shows the identical prior releases 'chore(deps): accept the Eval 0.147.0 generation (#146)' and 'chore(release): 8.0.6 — require Eval 0.146.0 (#141)'. The derived peer ranges are not hand-written — scripts/lib/peer-range.mjs:33-35 (expectedPeerRange: 0.x earns an exact-minor window, >=1.x earns a caret) is the codified rule, an
- Real-world viability: Holds beyond the happy path. pnpm-lock.yaml resolves one copy of interface 1.1.0 across agent-eval 0.148.0 and agent-core 0.9.4 (lockfile diff verified), so strict installers get no ERESOLVE and no duplicate contract package. Consumers still on Eval 0.147.0 keep resolving knowledge 8.0.8 via their existing '^8.0.x' ranges, so the tighter peer floor does not break lagging consumers. The repo's rele
- Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 1
💰 Value Audit
🟡 Published versions 8.0.7 and 8.0.8 have no CHANGELOG.md entries [maintenance] ``
CHANGELOG.md jumps from 8.0.9 (line 3) straight to 8.0.6 (line 14), yet
npm view @tangle-network/agent-knowledge versionsconfirms 8.0.7 and 8.0.8 were published (8.0.7 came from commit 8baaf2b, which shipped without a changelog entry). CHANGELOG.md is in the publishedfileslist (package.json:56), so consumers of those two versions have no release notes. Not caused by this PR — 8.0.9 carries a proper entry — but the gap could be backfilled in a follow-up.
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.
✅ No Blockers —
|
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
✅ Approved — 1 non-blocking finding — 7efad008
Full multi-shot audit completed 3/3 planned shots over 3 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-18T21:00:34Z · immutable trace
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
🟢 Value Audit — sound
| Verdict | sound |
| Coverage | 2 of 2 lenses (value, usefulness) |
| Concerns | 0 (none) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 123.9s (2 bridge agents) |
| Total | 123.9s |
💰 Value — sound
A routine cohort release that repins agent-eval to 0.148.0 and agent-interface to 1.1.0, widens the derived peer windows accordingly, and ships 8.0.9 — exactly the established release pattern this repo has executed 20+ times.
- What it does: Bumps the version 8.0.8 -> 8.0.9, moves the agent-eval dev pin 0.147.0 -> 0.148.0 (peer range becomes the one-minor window >=0.148.0 <0.149.0), moves the agent-interface dev pin 1.0.0 -> 1.1.0 (peer range becomes ^1.1.0), updates pnpm-lock.yaml, and ships the CHANGELOG Unreleased section (the receipts feature from #153) as the 8.0.9 section (CHANGELOG.md:3-12, package.json:3,86-87,93-94).
- Goals it achieves: Admit Eval 0.148.0 into this package's install cohort. Because agent-eval is pre-1.0, npm locks a 0.x peer range to its minor, so the prior window (>=0.147.0 <0.148.0) refused an additive Eval release and any strict consumer install with Eval 0.148.0 hit ERESOLVE. The Interface floor moves because Eval 0.148.0 itself depends on Interface ^1.1.0 and the cohort holds one installed copy (CHANGELOG.md
- Assessment: Good on its merits and squarely in the grain. This is the same shape as chore(release) 8baaf2b (8.0.6 -> 8.0.7 for Eval 0.147.0) and ~20 prior 'align Knowledge with Eval X' commits in git log -- CHANGELOG.md. The repo's own tooling encodes this convention: scripts/verify-package.mjs:294-306 asserts each cohort package is a required peer at exactly the derived range (caret ranges checked by admissi
- Better / existing approach: none — this is the right approach. Alternatives considered and rejected on repo evidence: (1) a wider Eval peer window would admit untested future minors; the one-generation window is a deliberate, documented policy (CHANGELOG.md:18, 8.0.6 entry) enforced by verify-package.mjs. (2) Making agent-eval a regular dependency would break the AGENTS.md layering contract and reverses commit 62dd504 ('make
- Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 2
- Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error
🎯 Usefulness — sound
A minimal, correct peer-window release that unblocks strict cohort installs with Eval 0.148.0, following the repo's established release pattern exactly.
- Integration: The deliverable is the peer range itself, and its caller is the install graph: agent-runtime adopts Eval 0.148.0, and any strict install of runtime + this package ERESOLVES against the old '>=0.147.0 <0.148.0' window. The peers are load-bearing — 100+ imports of @tangle-network/agent-eval and @tangle-network/agent-interface across src/ (e.g. src/release.ts:9, src/kb-improvement/contracts.ts:1, src
- Fit with existing patterns: Matches the established release cadence exactly: 9a1079d did the same for Eval 0.146.0, 662c874 for the Interface caret range, and the pre-PR head held '>=0.147.0 <0.148.0' / '^1.0.0'. The lockfile confirms the single-copy claim — agent-eval@0.148.0 and agent-core@0.9.4 both resolve agent-interface 1.1.0, so raising the Interface floor to ^1.1.0 keeps one installed copy rather than fighting it. Th
- Real-world viability: A range declaration has no runtime behavior of its own; the real risks are a mis-stated window or an Eval 0.148.0 that broke a consumed export. Both are guarded mechanically: verify:package proves the clean install resolves and imports, and the PR reports typecheck and 707 passing tests at this head against 0.148.0. No lockfile/manifest drift — pnpm-lock.yaml, devDependencies, and peerDependencies
- 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.
2 participants
Why
Runtime adopts Eval 0.148.0 (tangle-network/agent-runtime#897). This package peers on Eval `>=0.147.0 <0.148.0`, so a strict install of the cohort with Eval 0.148.0 fails ERESOLVE. No published version admits 0.148.0.
Change
Proof (local, this head)