Uh oh!
There was an error while loading. Please reload this page.
chore(release): 8.0.6 — require Eval 0.146.0 - #141
Conversation
Eval 0.146.0 adds the multishot/golden subpath and removes no export. Measured against 0.145.21, the published type surface loses no entry point, no top-level export and no interface member. The peer window stopped at 0.146.0 because Eval is pre-1.0 and npm locks a 0.x range to its minor. That window refused an additive release and blocked every consumer that needs multishot/golden.
drewstone
commented
Aug 16, 2026
@tangletools review now |
tangletools
left a comment
There was a problem hiding this comment.
✅ Auto-approved drewstone PR — f1af5758
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:12:58Z
tangletools
left a comment
There was a problem hiding this comment.
✅ Auto-approved drewstone PR — f1af5758
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:13:01Z
tangletools
left a comment
There was a problem hiding this comment.
✅ Auto-approved drewstone PR — f1af5758
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:13:04Z
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 | 178.4s (2 bridge agents) |
| Total | 178.4s |
💰 Value — sound
A routine, mechanically-derived peer-window bump that moves the agent-eval cohort to 0.146.0 exactly the way this repo's release machinery prescribes; ship.
- What it does: Bumps the package to 8.0.6 and moves the agent-eval peer dependency from
>=0.145.21 <0.146.0to>=0.146.0 <0.147.0(package.json:82), with the exact dev pin moved from 0.145.21 to 0.146.0 (package.json:89), plus the matching CHANGELOG entry and pnpm-lock regen (commit f1af575 touches all three, pergit show f1af575 --stat). The practical delta: consumers installing this version get an eval p - Goals it achieves: Reopen the peer window for an additive eval release. Because eval is pre-1.0, the repo's rule derives the window as
>=V <0.minor+1.0, so the 0.145.21 pin automatically excluded 0.146.0. The change re-admits current eval by advancing the pin one minor. Secondary goal, achieved implicitly: keep the published cohort guarantee intact — exactly one admitted eval minor, one installed copy — while shif - Assessment: Good, and squarely in the grain. (1) The range is not hand-written:
expectedPeerRange()in scripts/lib/peer-range.mjs:33-35 emits>=0.146.0 <0.147.0for a pre-1.0 pin — I executed the module and it prints exactly the string at package.json:82. (2) The guard enforces it: scripts/verify-package.mjs:69-74 reads the dev pin, derives the expected range, and failsverify:packageon any mismatch, s - Better / existing approach: none — this is the right approach. I checked the two alternatives against the repo's own machinery: (a) a caret
^0.146.0is semantically identical for 0.x under npm's rule (peer-range.mjs:5-9 documents this), so the explicit range is just the clearer spelling of the same contract — no improvement available; (b) widening to span both minors (e.g.>=0.145.21 <0.147.0) would avoid forcing a simul - 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 co-install with Eval 0.146.0; every claim checks out against the installed package and the repo's own enforcement script.
- Integration: Fully wired. The window is not hand-picked: expectedPeerRange('0.146.0') returns '>=0.146.0 <0.147.0' (scripts/lib/peer-range.mjs:33-35), byte-identical to package.json:82, and scripts/verify-package.mjs:73,294-297 fails the package check if the declared peer ever diverges from the derivation. The devDep (package.json:89) and pnpm-lock.yaml moved to 0.146.0 in the same commit, and CHANGELOG.md doc
- Fit with existing patterns: Follows the repo's established release-alignment grain exactly. git log shows a chain of identical alignment releases (8.0.5, 662c874; 383ce19 introduced the derivation rule this PR applies; 8ee086c; 2128bb2; fd0eaa7). The pre-1.0 exact-minor window is the deliberate policy documented in scripts/lib/peer-range.mjs:5-9 and enforced by the verify scripts — no competing pattern exists.
- Real-world viability: Independently verified beyond the PR's claims: pnpm install --frozen-lockfile clean; pnpm run typecheck (src + contracts) clean against installed 0.146.0; @tangle-network/agent-eval/multishot/golden importable from the installed 0.146.0 (22 exports); the 0.146.0 exports map retains every subpath this repo imports ('.', ./campaign, ./rl, ./experiment all present). The tsc pass is the decisive check
- 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.
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.The window was derived, not chosen
expectedPeerRange()inscripts/lib/peer-range.mjscomputes the range from the dev dependency. For a pre-1.0 dependency it emits>=<version> <major.minor+1.0>, because npm locks a 0.x caret to its minor. Requiring Eval0.145.21therefore produced>=0.145.21 <0.146.0automatically. Requiring0.146.0produces>=0.146.0 <0.147.0by 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
exportsmap:The 20 signature changes are type-precision improvements on previously untyped values —
env?: anybecomingNodeJS.ProcessEnv,Promise<any>becomingPromise<DatabaseSync | null>.Proof