fix(release): publish first-party dependencies as ranges, not exact pins - #887
Conversation
A `catalog:` entry and a `workspace:*` specifier are both replaced by an exact version when the package is packed. The published manifest of agent-bench@0.8.12 therefore named five exact first-party versions, so a consumer that already held a later cohort member installed a second physical copy of each. The catalog now states a range per first-party entry, in the shape the depended-on package's own versioning earns: a caret from 1.0.0, and the narrower `>=X.Y.Z <X.Y+1.0` window below it. bench declares agent-runtime as `workspace:^`. `check:published-ranges` packs every publishable workspace package and fails when a packed first-party specifier names one version instead of a range.
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
✅ Auto-approved drewstone PR — 8990c125
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:29:00Z
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
🟡 Value Audit — sound-with-nits
| Verdict | sound-with-nits |
| Coverage | 2 of 2 lenses (value, usefulness) |
| Concerns | 3 (3 weak-concern) |
| Heuristic | 0.0s |
| Duplication | 0.1s |
| Interrogation | 198.5s (2 bridge agents) |
| Total | 198.6s |
💰 Value — sound-with-nits
Converts every first-party catalog/workspace dependency from an exact pin to a cohort range and adds a pack-time gate that refuses exact first-party pins in packed manifests — a correct root-cause fix for a real duplication defect, built squarely in the grain of the existing packed-package test libr
- What it does: Three things. (1) pnpm-workspace.yaml:27-41 changes every
@tangle-network/*catalog entry from an exact version (e.g.0.145.21) to a range in the shape the depended-on package's own versioning earns —^1.0.0from 1.0.0,>=X.Y.Z <X.Y+1.0below it — and bench/package.json:48 changesagent-runtimefromworkspace:*toworkspace:^, so the packed manifest carries ranges instead of exact ve - Goals it achieves: Prevent published manifests from exact-pinning first-party packages. An exact pin forces any consumer that already holds a later cohort member (agent-eval 0.146.0, agent-runtime 0.138.0 exist today) to install a second physical copy — two class identities, two module registries,
instanceoffalse across the seam. The goal is two-sided: fix the current manifests (version bumps 0.138.0→0.138.1 and - Assessment: Good, and coherent. The diagnosis is correct and evidenced: pnpm substitutes catalog and workspace specifiers with exact versions at pack time, so only the packed manifest carries the defect — hence the check packs and reads the archive rather than the source (check-published-ranges.mjs:11-14). Crucially, the existing heavyweight gates genuinely cannot catch this: verify-packed-cohort.mjs and benc
- Better / existing approach: none — this is the right approach. Searched scripts/ for existing equivalents: check-publish-workflow.mjs validates CI workflow hygiene only; check-version-bump.mjs validates bump hygiene; verify-packed-cohort.mjs and verify-packed-consumer.mjs are fresh-install gates blind to this failure mode (exact pins resolve single-copy in a fresh tree); publint/attw validate exports and types, not dependenc
- Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 2
- Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error
🎯 Usefulness — sound
Fixes a real published-manifest defect (exact first-party pins causing duplicate installs) by stating catalog ranges plus workspace:^, and wires a fail-closed packed-tarball guard into both CI and the publish gate — verified green on the current tree and red on a sabotaged exact pin.
- Integration: Fully reachable now, not merely imminently. The new guard (scripts/check-published-ranges.mjs) is invoked from root verify:package (package.json:140) which runs in CI (ci.yml:65) and gates npm publishing (publish.yml:132; publish-npm needs verify), and from bench's verify:package:static (bench/package.json:40) via verify:bench/verify:bench:published (publish.yml:174,303; ci.yml:137). The new lib s
- Fit with existing patterns: In the grain of the codebase. The range shape rule already existed as expectedPeerRange for peers (scripts/lib/packed-package-test.mjs:51-55); cohortRange composes it rather than duplicating it, and the catalog entries in pnpm-workspace.yaml:30-37 apply the same rule. The split is correct for this workspace: workspace member (agent-runtime in bench) uses workspace:^, external first-party packages
- Real-world viability: Holds up off the happy path. The check reads the packed tarball — the artifact consumers actually resolve against — not the source manifest, which is the correct ground truth since the defect only exists after pack substitution. It is fail-closed: missing install errors through execFileSync, multiple archives error (check-published-ranges.mjs:56-59), missing package.json errors (line 78). The wind
- Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 1
💰 Value Audit
🟡 Two spellings for a pre-1.0 window; caretAdmits refuses the one bench now publishes [maintenance] ``
The change standardizes pre-1.0 ranges as
>=X.Y.Z <X.Y+1.0(pnpm-workspace.yaml:32,35,37) but bench'sworkspace:^on the pre-1.0 agent-runtime packs as^0.138.0— semantically the same minor window under npm rules, yet a second spelling in the fleet. MeanwhilecaretAdmits(packed-package-test.mjs:64) returns false whenever floorMajor < 1, sorangeAdmits('^0.138.0', '0.138.1')is false even though the window admits it. Today no live path passes a 0.x caret torangeAdmits(`assertFirst
🟡 Third copy of the pack-and-read-tarball idiom [duplication] ``
check-published-ranges.mjs:46-70 (pnpm pack to scratch dir, find the single .tgz,
tar -xOzf ... package/package.json) now repeats the same plumbing that verify-official-optimizers.mjs:72-82 and verify-packed-cohort.mjs's buildAndPack each carry in their own harness style (execFileSync vs spawnSyncrun()). ~15 lines each and the surrounding harnesses genuinely differ, so consolidation is a judgment call, not a must — but a fourth consumer would make a sharedpackAndReadManifest(dir)helper
🎯 Usefulness Audit
🟡 Guard hard-fails if pnpm-workspace.yaml ever gains a glob entry [robustness] ``
workspacePackageDirectories throws on any workspace entry containing '*' (scripts/check-published-ranges.mjs:38-39). Today the workspace is only
bench, so this is fine, and the failure is fail-closed (blocks verify:package rather than silently skipping a package). But the first person to add e.g.packages/*to pnpm-workspace.yaml will hit a hard error in the publish gate and must teach this script globs. Deliberate per the error message; noting so a human knows the tradeoff was chosen, not o
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 —
|
| opencode GLM 5.2 | opencode DeepSeek v4 Pro | opencode DeepSeek v4 Flash | aggregate | |
|---|---|---|---|---|
| Readiness | 52 | 74 | 26 | 26 |
| Confidence | 85 | 85 | 85 | 85 |
| Correctness | 52 | 74 | 26 | 26 |
| Security | 52 | 74 | 26 | 26 |
| Testing | 52 | 74 | 26 | 26 |
| Architecture | 52 | 74 | 26 | 26 |
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 10 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 5/5 planned shots over 10 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 5/5 planned shots over 10 changed files. Global verifier still owns final merge decision.
🟠 MEDIUM Runner has no automated test coverage — scripts/check-published-ranges.mjs
The pure helpers (isExactVersionSpec, cohortRange, rangeAdmits, assertFirstPartyRangeSpecs) are unit-tested in scripts/lib/packed-package-test.test.mjs, but the runner itself — the pack invocation, workspace-directory enumeration, tarball extraction, and the exit-code contract (lines 32-106) — has no test. The exact behaviors this PR's premise rests on (catalog:/workspace: resolution inside the packed manifest, the 'exactly one archive' assumption, tar layout 'package/package.json') are exercised only by CI's verify:package execution, which made me hand-verify them at review time. An integration test packing a fixture package and asserting exit code w
🟠 MEDIUM pnpm pack failure crashes the loop and swallows pnpm's stderr — scripts/check-published-ranges.mjs
packedManifest(directory) is called outside the try/catch at lines 81-88, so a failing 'pnpm pack' throws uncaught: the script dies with a stack trace, remaining workspace packages are never checked, and the piped stderr (stdio 'pipe' at line 52, available as error.stderr) is never printed, so CI logs cannot show WHY pack failed. The gate still exits non-zero, so it fails closed, but a pack failure in package 1 of N masks all later results and is hard to diagnose. Fix: move packedManifest inside the try, and on catch a
🟠 MEDIUM isExactVersionSpec misses npm-valid exact pins (v-prefixed, =, npm: aliases) — scripts/lib/packed-package-test.mjs
const exactVersion = /^\d+.\d+.\d+(?:[-+].*)?$/ only matches bare versions. Confirmed by execution: isExactVersionSpec('v1.0.0') === false, isExactVersionSpec('=1.0.0') === false, and assertFirstPartyRangeSpecs accepts a first-party dependency of 'v1.0.0'. npm treats v1.0.0, =1.0.0, and npm:@tangle-network/x@1.0.0 as exact pins, so these publish as exact versions and produce the duplicate-physical-copy defect the PR exists to prevent, while the guard reports clean. pnpm catalog/workspace substitution produces bare versions so current tree is unaffected, but the guard silently passes a class of pins it claims to forbid. Fix: strip optional ^v/=v prefixes and npm: aliases before the exact-version test, or reject them explicitly.
🟠 MEDIUM JS/Python bridge version pairing can diverge in consumer verification — scripts/verify-official-optimizers.mjs
assertInstalledAdmitted(appDir, '@tangle-network/agent-eval', packedAgentEvalVersion) (lines 161-172) replaces the old exact assertInstalledVersion. The consumer app now declares the range (>=0.145.21 <0.146.0) and npm installs the NEWEST in-range version, while the Python bridge stays pinned to the workspace version: installWheelPythonPackages uses agent-eval-rpc==${agentEvalVersion} (line 204) and AGENT_EVAL_EXPECTED_BRIDGE_VERSION=agentEvalVersion=workspaceAgentEvalVersion ([lines 40-42](https://github.co
🟡 LOW Doc overstates catalog: pack substitution as 'exact version' — docs/STABILITY.md
Line 55: 'A
catalog:specifier and aworkspace:*specifier are both replaced by an exact version when the package is packed.' Verified empirically with pnpm 11.22: acatalog:specifier is substituted with the catalog entry value verbatim, so a ranged entry (this repo's>=0.9.4 <0.10.0,^1.0.0) packs as that same range, not an exact pin. Onlyworkspace:*and catalog entries whose value is already exact (e.g. a future@tangle-network/*: 0.9.4in pnpm-workspace.yaml) produce an exact pin. Impact: the doc's stated mechanism is wrong for the common ranged case, which could mislead a reader into thinking ranged catalog entries are flattened to pins on pack (they ar
🟡 LOW Pack-replacement sentence overclaims: catalog: is replaced by the catalog entry, not always an exact version — docs/STABILITY.md
The sentence 'A
catalog:specifier and aworkspace:*specifier are both replaced by an exact version when the package is packed' is false for catalog: entries that hold a range. Empirical proof: I ranpnpm run check:published-rangesat head; it passes and prints packed specs like@tangle-network/agent-interface@^1.0.0and@tangle-network/agent-core@>=0.9.4 <0.10.0— ranges, not exact versions. The repo's own pnpm-workspace.yaml comment states the correct semantics ('Acatalog:specifier is replaced by the entry below when the package is packed'), and the same wrong wording is duplicated in the header of scripts/check-published-ranges.mjs:11-13 (outside this shot's scope). The doc's conclusion is unaffected — the defect path (exact catalog entry, or workspace:* which does become
🟡 LOW Below-1.0 windows still duplicate across the next minor line — pnpm-workspace.yaml
>=0.145.21 <0.146.0(agent-eval),>=0.9.4 <0.10.0(agent-core),>=0.16.0 <0.17.0(agent-profile-materialize),>=0.27.1 <0.28.0(sandbox) guarantee one physical copy only within a single minor line. A consumer already holding agent-eval 0.146.0 (pulled by a newer agent-runtime) who installs runtime@0.138.1 will still get a second 0.145.x copy. This is inherent to the documented below-1.0 policy and is arguably correct ('a minor may remove'), but the comment's framing (lines 18-21: 'so every first-party entry states a RANGE') can read as fully solving the duplicate-copy defect when it in fact only bounds it to the minor window. Doc nit only; the behavior is int
🟡 LOW Caret ranges above 1.0 trust the depended-on package's minor-is-additive promise — pnpm-workspace.yaml
@tangle-network/agent-interface: ^1.0.0,@tangle-network/agent-knowledge: ^8.0.5, and@tangle-network/agent-trace-contract: ^1.0.2admit every later minor up to the next major. The comment (lines 23-26) asserts 'a minor is additive' from 1.0.0, but that is a semver policy statement, not a verified fact about these packages' changelogs. If any 1.x/8.x minor removes or narrows an API agent-runtime@0.138.1 relies on, a consumer resolving the range will silently install the breaking minor — the same class of duplicate/conflict the PR exists to prevent. Impact is limited because the below-1.0 entries (agent-core, agent-eval, agent-profile-materialize, sandbox) keep
🟡 LOW Range catalog + minimumReleaseAgeExclude lets fresh resolutions pick a same-day first-party release — pnpm-workspace.yaml
minimumReleaseAge: 4320 (72h) gates new resolutions, but minimumReleaseAgeExclude lists '@tangle-network/*'. Before this PR the exact pin meant a release entered this repo only when a human moved the pin; now any fresh resolution without a lockfile (new CI checkout with frozen-lockfile disabled, lockfile regen, new contributor) silently picks the newest cohort member, e.g. a 0.9.5 of agent-core published minutes earlier. The committed lockfile pins 0.9.4 so CI and existing checkouts are unaffected, and first-party trust is the stated reason for the exclude, so this is a documented tradeoff — but the coupling between the new floating specifiers and the age-gate exclusion is not mentioned in the new comment block. Fix: add one sentence to the comment naming it, or narrow the exclude if suppl
🟡 LOW bench package pack path not re-verifiable in a fresh worktree — pnpm-workspace.yaml
pnpm packof @tangle-network/agent-bench fails in this worktree with ERR_PNPM_CANNOT_RESOLVE_WORKSPACE_PROTOCOL on@tangle-network/agent-runtime: workspace:^(bench/package.json:48) because nopnpm installhas populated the store — workspace-protocol resolution needs installed links. scripts/check-published-ranges.mjs runs this pack, so the newcheck:published-rangesgate depends on a prior install; CI's verify:package:static for bench runspnpm run buildfirst (which itself requires node_modules), so the gate is satisfiable, and the root package packed cleanly in the same run. Verification limitation in this environment, not a code defect; flagging so the reviewer of the check script confirms CI ordering.
🟡 LOW windowAdmits parser couples to the hand-written single-space YAML form — pnpm-workspace.yaml
scripts/lib/packed-package-test.mjs windowAdmits() accepts only '>=X.Y.Z <X.Y.Z' with exactly one space; a future edit like '>=0.9.4 <0.10.0' or a trailing space silently fails both caretAdmits and windowAdmits, making rangeAdmits return false and surfacing as a confusing 'installed X is outside its declared range' failure in verify-official-optimizers.mjs rather than a parse error. Current committed values match the strict form (verified against all five window entries), so this is brittleness, not a live defect. Fix: trim/collapse whitespace in windowAdmits' regex, or add a test asserting every catalog entry parses as exactly one admitted shape.
🟡 LOW Default invocation hard-crashes on glob entries in pnpm-workspace.yaml — scripts/check-published-ranges.mjs
Line 38 throws on any entry containing '*'. The ubiquitous pnpm pattern
packages/*(orbench/*) would crash the no-arg invocation of this check rather than skip or glob-expand. Currently harmless because this repo's pnpm-workspace.yaml lists only 'bench' (verified), but the failure mode is a full abort with no guidance. Suggest expanding simple globs or degrading gracefully with a clear error naming the unsupported entry.
🟡 LOW Glob workspace entries hard-fail; duplicate '.' entry packs twice — scripts/check-published-ranges.mjs
Any pnpm-workspace.yaml entry containing '' throws, so the natural growth path (adding 'packages/') breaks verify:package until this script is taught directory expansion; and a '.' entry would push resolve(repoRoot, '.') again, packing the root twice and printing duplicate output. Both are fail-closed and not reachable with the current workspace (only 'bench'), so this is maintenance friction to note, not a live bug. Fix: expand simple one-level globs with readdirSync, and dedupe the directories array with a Set.
🟡 LOW No timeout on execFileSync child processes — scripts/check-published-ranges.mjs
execFileSync('pnpm', [...]) and the tar extraction have no timeout option. A hung pack (corepack prompt, filesystem stall) hangs verify:package indefinitely instead of failing the gate. Fix: pass timeout (e.g. 120_000) and let the thrown error accumulate as a failure.
🟡 LOW Report omits optionalDependencies, assertions cover them — scripts/check-published-ranges.mjs
The first-party stdout report spreads only manifest.dependencies and manifest.peerDependencies (lines 89-92), but assertFirstPartyRangeSpecs (callee in scripts/lib/packed-package-test.mjs:116) also enforces optionalDependencies. An optional first-party dep is validated yet never printed in the summary line — the report can contradict what was actually checked. Merge the spread with ...(manifest.optionalDependencies ?? {}) for consistency.
🟡 LOW Requested package args resolve against repoRoot, not the caller's cwd — scripts/check-published-ranges.mjs
process.argv.slice(2).map(entry => resolve(repoRoot, entry)) silently ignores the invoking cwd. The documented in-repo call (
node ../scripts/check-published-ranges.mjs benchfrom bench/, andnode scripts/check-published-ranges.mjsfrom root) resolves correctly, but an ad-hoc relative path passed from a subdirectory points at the wrong directory and either throws 'no package.json at ...' or checks an unintended package. Resolve against process.cwd() or document that args are repo-root-relative.
🟡 LOW pack/source-parse failure aborts with raw stack trace, not an aggregated summary — scripts/check-published-ranges.mjs
packedManifest() (pnpm pack, tar, JSON.parse) and the source JSON.parse at line 79 throw out of the loop instead of joining the
failuresarray, so one bad package ends the script with an uncaught exception rather than a summary of all failing packages. Exit code is still non-zero (CI fails correctly), but error UX is worse and remaining packages are never checked. Wrapping the per-directory pack in the existing try/catch would make the report consistent.
🟡 LOW pnpm pack failure aborts the whole run instead of being collected — scripts/check-published-ranges.mjs
packedManifest() is called outside the per-package try/catch (which only wraps the two assert* calls at lines 82-88). Any pack-time failure — verified live here: ERR_PNPM_CANNOT_RESOLVE_WORKSPACE_PROTOCOL for bench ('Try running pnpm install') — propagates as an unhandled Node stack trace and kills the script before other packages are reported. Still fail-closed (exit 1), so CI stays gated, but one bad package masks every other and the diagnostic is a raw crash. Fix: wrap the packedManifest call in the same try/catch and push its error.message into failures, or preflight-check workspace resolution before looping.
🟡 LOW report omits optionalDependencies while the assertion covers them — scripts/check-published-ranges.mjs
The firstParty summary merges only manifest.dependencies and manifest.peerDependencies, but assertFirstPartyRangeSpecs (packed-package-test.mjs:116) also scans optionalDependencies. A first-party optional dependency that is a range passes the assertion but is silently absent from the human-readable output; an exact pin there would be reported by the assert anyway, so this is cosmetic, not a correctness gap.
🟡 LOW workspacePackageDirectories throws on glob entries — scripts/check-published-ranges.mjs
Any pnpm-workspace.yaml entry containing '*' (the common
packages/*convention) throws and aborts the default run. The current workspace lists onlybench(verified), so it passes today, but the first glob adoption breakspnpm run check:published-rangeswith no per-package fallback. Consider resolving globs with a matcher or documenting the plain-directory-only constraint next to the pnpm-workspace.yaml packages list.
🟡 LOW Exact-pin guard misses npm's v-prefix and = exact forms — scripts/lib/packed-package-test.mjs
exactVersion = /^\d+.\d+.\d+(?:[-+].)?$/ does not match 'v1.2.3' or '=1.2.3', both of which npm resolves as exact pins. Verified by execution: assertFirstPartyRangeSpecs({dependencies:{'@tangle-network/sandbox':'v0.27.1'}}) passes, so a catalog entry holding such a shape would publish an exact pin the guard exists to block. Not reachable today (catalog entries are hand-curated to the two documented range shapes) and the strict packed install backstops it, hence low. Fix: /^(?:v|=)?\d+.\d+.\d+(?:[-+].)?$/ after trim, or reject unknown shapes outright.
🟡 LOW Prerelease versions compared without prerelease ordering — scripts/lib/packed-package-test.mjs
windowAdmits strips the prerelease suffix via /^(\d+).(\d+).(\d+)/ on the version, so a prerelease is ordered as its numeric base. Verified: rangeAdmits('>=0.27.1 <0.28.0', '0.27.1-rc.0') returns true even though 0.27.1-rc.0 sorts below 0.27.1 in semver, and caretAdmits similarly ignores prerelease floors. Impact: the only consumers (assertExactDependency, assertCatalogAdmits, assertInstalledAdmitted) compare against installed/packed stable versions, so prereleases never reach these paths. Fix (optional): reject or explicit-handle prerelease versions in found/floor matches, or document that these helpers assume stable versions only.
🟡 LOW caretAdmits rejects all pre-1.0 carets and prerelease carets, unlike npm — scripts/lib/packed-package-test.mjs
return floorMajor < 1 || major !== floorMajor means rangeAdmits('^0.2.3', '0.2.3') === false (confirmed by execution), even though npm's ^0.2.3 is >=0.2.3 <0.3.0 — semantically identical to the window shape this code prefers for pre-1.0. caretAdmits also only matches /^^(\d+).(\d+).(\d+)$/, so '^1.2.3-rc.1' never admits anything. Impact is a false positive in assertExactDependency (verify-packed-cohort.mjs): a first-party dependency declared '^0.2.3' in dependencies fails with the misleading message 'requires X@^0.2.3, packed 0.2.3' even though the packed version is admitted by npm. Deliberate convention (pre-1.0 must use the window shape) but the divergence from npm semantics and the misleading error are undocumented.
🟡 LOW isExactVersionSpec and expectedPeerRange disagree on build metadata — scripts/lib/packed-package-test.mjs
isExactVersionSpec uses /^\d+.\d+.\d+(?:[-+].)?$/ (line 68), which accepts '1.0.0+build'. cohortRange then calls expectedPeerRange on that spec, but expectedPeerRange (line 52) and currentMinorPeerRange (line 38) use /^(.)...(?:-.+)?$/ which only admits a '-' prerelease, not '+'. Verified: cohortRange('1.0.0+build') throws 'cannot derive peer range from version 1.0.0+build'. Imp
🟡 LOW windowAdmits diverges from npm for prereleases of the window ceiling — scripts/lib/packed-package-test.mjs
The window extracts major.minor.patch from the target version (found = /^(\d+).(\d+).(\d+)/) and compares numerically, so it rejects 0.146.0-rc.1 under '>=0.145.21 <0.146.0' (target 0.146.0 fails target < ceiling). npm semver admits 0.146.0-rc.1 here because a prerelease sorts below its release. Same class of divergence for a prerelease floor (0.145.21-rc.1, correctly rejected by both). Only reachable when a first-party package ships prerelease versions, which the cohort currently does not; would surface as a false positive in assertExactDependency/assertInstalledAdmitted. Document the divergence or handle prerelease components explicitly.
🟡 LOW windowAdmits ignores semver prerelease semantics in both directions — scripts/lib/packed-package-test.mjs
The version regex /^(\d+).(\d+).(\d+)/ drops the prerelease suffix, so windowAdmits('>=0.145.21 <0.146.0', '0.145.21-rc.1') returns true (verified by execution) even though npm semver refuses a prerelease in a release-only comparator window — a fail-open deviation used by assertInstalledAdmitted/assertCatalogAdmits (verify-official-optimizers.mjs:306,330) and assertExactDependency (verify-packed-cohort.mjs:609). Conversely the bound regex rejects prerelease floors: currentMinorPeerRange('0.27.1-rc.1') emits '>=0.27.1-rc.1 <0.28.0' (verified), which windowAdmits can never admit, so a future prerelease catalog entry would spuriously red the cohort verification. Fix: capture and compare prerelease segments, or explicitly document prereleases as out of scope and assert their absence. Note ca
🟡 LOW windowAdmits integer ordering loses precision above 8-digit majors — scripts/lib/packed-package-test.mjs
order() packs (major,minor,patch) into one float with a 1e12 major scale; beyond Number.MAX_SAFE_INTEGER comparisons become garbage: windowAdmits('>=99999999.0.0 <99999999.0.1', '99999999.0.0') returns false (verified) when the version sits exactly at the floor and must admit. No real package uses such majors, and neighboring caretAdmits (lines 62-65) avoids the problem by comparing major by equality first. Fix: compare component tuples lexicographically like caretAdmits does.
🟡 LOW Modified assertPeerMatchesDevelopmentDependency behavior has no direct unit test — scripts/lib/packed-package-test.test.mjs
The only change to existing production behavior — line 133, expected = cohortRange(version) instead of expectedPeerRange(version), which newly accepts a range dev dependency and demands verbatim peer equality — is covered only by the heavyweight CI scripts (verify-packed-cohort, verify-official-optimizers, verify-package-exports), not by the new unit test file. cohortRange's throw paths (non-string, empty string, build-metadata pins like '1.2.3+build.1' which throw 'cannot derive peer range') are also untested. Add a describe block: exact dev spec '0.27.1' expects peer '>=0.27.1 <0.28.0', range dev spec '^1.0.0' expects peer '^1.0.0', mismatch throw
🟡 LOW No regression test for the modified assertPeerMatchesDevelopmentDependency — scripts/lib/packed-package-test.test.mjs
The one production behavior change to a pre-existing function — expected = cohortRange(version) at packed-package-test.mjs:133, replacing expectedPeerRange(version) — has no direct test. The new suite covers only the four newly added helpers. The change is behavior-visible: a devDependency declared as a range (e.g. '>=0.145.21 <0.146.0') now yields that range verbatim as the expected peer, where the old code threw on any non-exact spec. Add cases: exact version -> canonical cohort shape (unchanged path), range devDep -> verbatim peer match, and a range devDep whose peer differs -> throws.
🟡 LOW Exact-pin catalog entry produces a misleading failure message — scripts/verify-official-optimizers.mjs
assertVersion(packedAgentEvalVersion, catalogRange('@tangle-network/agent-eval'), ...) compares the packed devDep against cohortRange(catalogSpec). If a maintainer sets the catalog to an exact pin (e.g. 0.145.21), cohortRange expands it to >=0.145.21 <0.146.0 while pnpm packs the literal 0.145.21, so the error reads 'must be >=0.145.21 <0.146.0, found 0.145.21' — blaming the packed dependency instead of the catalog entry that caused it. Works as a gate but the message should point at pnpm-workspace.yaml.
🟡 LOW New inline helpers lack direct unit coverage — scripts/verify-official-optimizers.mjs
assertInstalledAdmitted, catalogRange, assertCohortRange, and assertCatalogAdmits (lines 304-335) are only exercised by the full verify:official-optimizers run, which requires Python 3.12, pip network installs, and a 10-minute npm install — not part of fast CI. The shared cohortRange/rangeAdmits helpers they compose are unit-tested, but the wiring (e.g. that catalogRange rejects a missing catalog entry, that assertCohortRange compares against peerDependencies) has no fast path test. Consider extracting these into packed-package-test.mjs alongside their peers so catalog-driven assertions get the same fast coverage.
🟡 LOW Prerelease versions and prerelease-bearing ranges are mishandled by prefix-only version parsing — scripts/verify-official-optimizers.mjs
caretAdmits/windowAdmits match versions with /^(\d+).(\d+).(\d+)/ and ignore prerelease suffixes, while their range regexes accept no prerelease on the floor/ceiling. Consequences: an installed
0.145.22-rc1would be admitted by>=0.145.21 <0.146.0where npm semver would reject it (over-admission in a verification gate), and a catalog range containing a prerelease floor fails both parsers and reports the version as outside its own range. Cannot trigger with the current catalog (all stable specs) and npm-resolved stable installs, so latent; worth normalizing to a real semver satisfiedBy if these checks ever guard prerelease cohorts.
🟡 LOW Tautological admission checks on direct consumer dependencies — scripts/verify-official-optimizers.mjs
Lines 161-167 call assertInstalledAdmitted with the same range string the consumer's own package.json (lines 130-132) declares as the direct dependency. npm already guarantees a resolved install sits within its declared range, so rangeAdmits can never fail here. This intentionally replaces the former assertInstalledVersion exact-equality check (installed === packed devDependency version), which used to prove the consumer got the exact version the workspace builds/tested against. That relaxation is the P
🟡 LOW Temp dir leaks when the new pre-try catalog asserts fail — scripts/verify-official-optimizers.mjs
tempRoot=mkdtempSync(...) at line 47 runs before the try/finally at line 56, and the new assertCohortRange/assertCatalogAdmits calls (lines 51-54) sit between them. Any failure there skips the finally rmSync(tempRoot) at line 197. The
🟡 LOW rangeAdmits cannot evaluate a ^0.x catalog spec, yielding a confusing false failure — scripts/verify-official-optimizers.mjs
assertInstalledAdmitted and assertCatalogAdmits (line 330) rely on rangeAdmits, which is caretAdmits || windowAdmits. caretAdmits (lib/packed-package-test.mjs:64) returns false whenever floorMajor < 1, and windowAdmits only matches the
>=X <Yshape. So if a maintainer writes a pre-1.0 catalog entry as^0.27.1instead of the documented window form (the yaml comment is the only guard), every check reportsinstalled 0.27.1 is outside its declared range ^0.27.1even though the version is semver-compatible — a fail-closed but misleading CI/publish blocker. Fix: either reject^0.xspecs at catalogRange() with a message pointing to the window form, o
tangletools · 2026-08-17T00:44:15Z · trace
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
✅ Approved — 35 non-blocking findings — 8990c125
Full multi-shot audit completed 5/5 planned shots over 10 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 5/5 planned shots over 10 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 5/5 planned shots over 10 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:44:15Z · immutable trace
# Conflicts: # pnpm-lock.yaml # pnpm-workspace.yaml
The packed manifest now carries a range for its first-party dependencies, which is a consumer-visible change and cannot ship under a published version.
Eval 0.147.0 declares its first-party dependencies as ranges, which the packed-cohort guard in this change requires of every cohort member.
The packed manifest inherits the catalog specifier verbatim, so an exact entry duplicates the package for a consumer already holding a later patch.
# Conflicts: # docs/api/primitive-catalog.md # docs/canonical-api.md # package.json # src/testing/fixtures/agent-improvement-proposal.json # src/testing/fixtures/agent-profile-improvement-proposal.json
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
✅ Auto-approved drewstone PR — 8dcdb6c7
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:57:52Z
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
🔴 Value Audit — redundant-or-flawed
| Verdict | redundant-or-flawed |
| Coverage | 2 of 2 lenses (value, usefulness) |
| Concerns | 5 (2 strong-concern, 3 weak-concern) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 597.3s (2 bridge agents) |
| Total | 597.3s |
💰 Value — redundant-or-flawed
Switches first-party deps from exact pins to ranges in the catalog/workspace specs and adds a packed-manifest guard, but leaves bench's agent-eval, agent-interface, and sandbox as exact pins — its own guard fails on the repo, so CI is red and the stated defect is only half-fixed.
- What it does: Adds a packed-manifest guard (
assertFirstPartyRangeSpecsin scripts/lib/packed-package-test.mjs:112) that rejects any exact first-party version in dependencies/optionalDependencies/peerDependencies, plus a workspace-wide driver (scripts/check-published-ranges.mjs) that packs each publishable package and runs it. It turns some catalog entries into ranges (agent-core→^0.9.4, knowledge→^8.0.6, prof - Goals it achieves: Eliminate the exact first-party pins that make a consumer install a second physical copy of a cohort package (duplicate class identities, broken instanceof). The mechanism is sound and in-grain: state a compatibility range in the catalog once, let pnpm pack it verbatim, and fail CI on any packed exact pin. The runtime package now packs fully clean (verified: `node scripts/check-published-ranges.mj
- Assessment: The architecture is right and matches the codebase's grain — it extends the existing shared lib (packed-package-test.mjs already held
expectedPeerRange/caretAdmits) and reusesassertFirstPartyRangeSpecsacross verify-packed-cohort and the new check, rather than inventing parallel logic. But the change is INCOMPLETE. bench declares agent-eval, agent-interface, and sandbox as runtime `dependen - Better / existing approach: No materially different architecture — the range-in-catalog + packed-manifest-guard mechanism is correct and is the right long-term design. The fix is to COMPLETE it, not redesign: the three missing ranges already exist verbatim as peer ranges in package.json:172-176 (
@tangle-network/agent-eval:>=0.147.0 <0.148.0,agent-interface:^1.0.0,sandbox:>=0.27.1 <0.28.0), so the catalog jus - Model: opencode/deepseek/deepseek-v4-pro
- Bridge attempts: 3
- Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error; opencode/zai-coding-plan/glm-5.2: opencode: opencode error
🎯 Usefulness — redundant-or-flawed
The mechanism is sound and in-grain, but the change is incomplete: it wires a pack-and-check gate into CI that the repo's own catalog currently violates, so verify:bench goes red and three of the five named first-party deps still publish as exact pins.
- Integration: The new check is reachable — actually over-reachable.
check-published-ranges.mjsis invoked from bench'sverify:package:static(bench/package.json:40), which is reached byverify:package:local-runtime->verify:bench(package.json:136), and CI'sagent-benchjob runspnpm run verify:benchon every push/PR (ci.yml:137). Running it today fails: `node scripts/check-published-ranges.mjs ben - Fit with existing patterns: Fits the codebase grain well. It reuses the shared
scripts/lib/packed-package-test.mjshelpers, generalizesexpectedPeerRange/caretAdmitsintocohortRange/rangeAdmits/windowAdmits, and extends the existingverify-official-optimizers.mjsandverify-packed-cohort.mjsrather than forking them. The pack-and-read-the-tarball technique matches the existingverify-packed-consumer.mjspa - Real-world viability: The enforcement logic is correct and works against realistic input (it packs and reads the archive, never the source, and the unit tests cover caret/window/exact cases). But it does not hold up end-to-end: the same PR that adds the guard fails it. Three catalog entries were left exact — agent-eval (pnpm-workspace.yaml:23), agent-interface (:24), sandbox (:28) — because a later cohort-bump commit r
- Model: opencode/deepseek/deepseek-v4-pro
- Bridge attempts: 3
- Bridge warning: opencode/zai-coding-plan/glm-5.2: opencode: opencode error; opencode/kimi-for-coding/k2p7: opencode: opencode error
🎯 Usefulness Audit
🔴 Gate fails against the repo's own catalog: bench still packs 3 exact first-party pins [integration] ``
The stated goal is to publish all five first-party deps as ranges, but only agent-core/agent-knowledge/agent-profile-materialize/agent-trace-contract were converted. pnpm-workspace.yaml:23,24,28 still name agent-eval
0.147.0, agent-interface1.0.0, sandbox0.27.1exactly; bench consumes all three viacatalog:(bench/package.json:42-44,46), so the packed manifest retains exact pins.node scripts/check-published-ranges.mjs benchexits 1 (verified). Becauseverify:package:static(bench/
🟡 Documented script name does not exist [ergonomics] ``
docs/STABILITY.md:56 tells users to run
pnpm run check:published-ranges, but no such script is registered in either package.json — the check is only reachable via the inlinenode ../scripts/check-published-ranges.mjs benchinside bench's verify chain. Add the root script (or fix the doc) so the documented entrypoint matches reality.
💰 Value Audit
🔴 Change does not achieve its goal: bench still publishes 3 exact first-party pins, and its own wired-in guard fails [proportion] ``
bench/package.json:45-47,49 declares agent-eval, agent-interface, sandbox as runtime dependencies via
catalog:, but pnpm-workspace.yaml:23-24,28 leaves those three entries as exact versions (0.147.0, 1.0.0, 0.27.1). Verified by running the PR's own check:node scripts/check-published-ranges.mjs benchfails withdependencies.@tangle-network/agent-eval = 0.147.0,agent-interface = 1.0.0,sandbox = 0.27.1. The guard is wired into CI (bench/package.json:40 → ci.yml:137verify:benchand p
🟡 Published pre-1.0 caret shape is rejected by the shared rangeAdmits/caretAdmits predicate [maintenance] ``
The doc rule (docs/STABILITY.md) and the PR body say pre-1.0 packages use the
>=X.Y.Z <X.Y+1.0window, yet the catalog shipsagent-core: ^0.9.4,agent-profile-materialize: ^0.16.0(pnpm-workspace.yaml:21,26) and bench shipsagent-runtime: workspace:^→^0.140.0(bench/package.json:48).caretAdmits(packed-package-test.mjs:58-66) returns false for any^0.x.yfloor (if (floorMajor < 1 ...) return false), sorangeAdmits('^0.140.0', '0.140.0')is false. Semantically a 0.x caret equ
🟡 Documented entrypoint pnpm run check:published-ranges does not exist [maintenance] ``
docs/STABILITY.md:56 tells users to run
pnpm run check:published-ranges, but no such script exists in package.json or bench/package.json (verified by grep). The check is only reachable via bench'sverify:package:static(bench/package.json:40); the rootverify:package(package.json:139) does not run it. The runtime is still covered byassertFirstPartyRangeSpecsinside verify-packed-cohort.mjs:303, but the documented standalone gate is a dead reference.
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.
|
| 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 · #887 · model: kimi-for-coding · updated 2026-08-17T03:24:37Z
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
✅ Auto-approved drewstone PR — 8dcdb6c7
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-17T03:27:23Z
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
🔴 Value Audit — redundant-or-flawed
| Verdict | redundant-or-flawed |
| Coverage | 2 of 2 lenses (value, usefulness) |
| Concerns | 4 (2 strong-concern, 1 medium-concern, 1 weak-concern) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 520.7s (2 bridge agents) |
| Total | 520.7s |
💰 Value — sound-with-nits
Publishes first-party deps as consumer-safe ranges via catalog entries plus a pack-and-verify guard that fails on exact pins — the design is right and in-grain, but the branch's final state lost 3 of the 7 catalog ranges to a merge from main, so at HEAD it fails its own gate and preserves the defect
- What it does: Three coordinated moves. (1) pnpm-workspace.yaml catalog states first-party entries as ranges (caret from 1.0.0, '>=X.Y.Z <X.Y+1.0' below) and bench declares agent-runtime as 'workspace:^' instead of 'workspace:*' (bench/package.json:49) — both specifiers are replaced verbatim by pnpm pack, so this is the only lever on the published manifest. (2) New scripts/check-published-ranges.mjs packs each p
- Goals it achieves: Prevent duplicate physical copies of first-party packages in consumer trees: an exact pin in the packed manifest forces any consumer already holding a later cohort member to install a second copy (two class identities, instanceof false across the seam — the mechanism is real; agent-bench@0.8.12 shipped exact pins for agent-eval and agent-runtime, which duplicated same-day). Secondary goals: state
- Assessment: The architecture is coherent and in the codebase's grain. It extends the existing shared assertion lib (packed-package-test.mjs) rather than forking it; the range shapes reuse the repo's established expectedPeerRange rule; the gate lands in the existing verify:package:static chain next to publint/attw; and coverage composes cleanly — verify-packed-cohort covers the root package and external cohort
- Better / existing approach: none — this is the right approach. Searched for an existing equivalent: publint and attw (bench verify:package:static) validate exports/types, not specifier shape; scripts/verify-packed-consumer.mjs installs the packed artifact but asserts resolution, not manifest ranges; scripts/verify-packed-cohort.mjs packed only the external cohort + root, not bench, and this change correctly extends it (verif
- Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 2
- Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error
🎯 Usefulness — redundant-or-flawed
The range mechanism and its packed-tarball check are sound and agent-runtime's own manifest is fixed, but the change ships incomplete: three of bench's five first-party dependencies still pack as exact pins, and the PR's own enforcement check fails (exit 1) on that exact package, turning CI red.
- Integration: The check is genuinely wired in and reachable — bench/package.json:40 appends
node ../scripts/check-published-ranges.mjs benchtoverify:package:static, which runs underverify:bench(ci.yml:137) andverify:bench:published/verify:package(publish.yml:174, :303). But it is a red build, not a guard: I rannode scripts/check-published-ranges.mjs benchand it exits 1, reporting `dependenci - Fit with existing patterns: Architecturally it fits the codebase's grain: it extends the existing
scripts/lib/packed-package-test.mjshelpers (expectedPeerRange,assertPublishableDependencySpecs) and reuses the establishedpack-and-read-the-archive pattern already inverify-packed-cohort.mjs/verify-official-optimizers.mjs. No competing pattern exists. The original commit cde097c correctly converted every first-pa - Real-world viability: The detector is correct — it reliably distinguishes exact pins from ranges and reproduced the exact defect the PR body describes. But it won't hold up as shipped: (1) the catalog still states agent-eval/agent-interface/sandbox as exact (pnpm-workspace.yaml:23,24,28), so bench's packed manifest still ships
"@tangle-network/agent-eval":"0.147.0","agent-interface":"1.0.0","sandbox":"0.27.1"( - Model: opencode/deepseek/deepseek-v4-pro
- Bridge attempts: 3
- Bridge warning: opencode/zai-coding-plan/glm-5.2: opencode: opencode error; opencode/kimi-for-coding/k2p7: opencode: opencode error
🎯 Usefulness Audit
🔴 Fix is half-applied: bench still packs three exact pins, and the new check fails on it [problem-fit] ``
pnpm-workspace.yaml still declares
agent-eval: 0.147.0(:23),agent-interface: 1.0.0(:24),sandbox: 0.27.1(:28) as exact, so the packed bench manifest (verified viapnpm --dir bench pack+ tar) emits"@tangle-network/agent-eval":"0.147.0","agent-interface":"1.0.0","sandbox":"0.27.1"— 3 of the 5 first-party pins the PR title/body names as the defect.node scripts/check-published-ranges.mjs benchexits 1 with exactly those three names, and that check is wired into `verify:benc
🟠 Pre-1.0 caret ranges in the catalog are inadmissible by the PR's own rangeAdmits helper [robustness] ``
The catalog now uses
^0.9.4(agent-core) and^0.16.0(agent-profile-materialize), butcaretAdmits(packed-package-test.mjs:64) returns false for anyfloorMajor < 1, sorangeAdmits('^0.9.4','0.9.4')andrangeAdmits('^0.16.0','0.16.0')both return false. This contradicts the documented rule in docs/STABILITY.md (pre-1.0 → window>=X.Y.Z <X.Y+1.0) and the shape cde097c originally used (>=0.9.4 <0.10.0,>=0.16.0 <0.17.0). Today nothing callsrangeAdmitson those two names, but th
💰 Value Audit
🔴 Merge regression: 3 of 7 first-party catalog entries are still exact pins at HEAD, so the PR fails its own gate and preserves the defect for 3 of 5 bench deps [maintenance] ``
cde097c converted every first-party catalog entry to a range with a 7-line explanatory comment (git show cde097c:pnpm-workspace.yaml). The merge from main at c362bc2 reverted them to exact versions, and b10d6c8 re-applied ranges only for agent-core, agent-knowledge, and agent-profile-materialize. At HEAD, pnpm-workspace.yaml:23 ('@tangle-network/agent-eval': 0.147.0), :24 ('@tangle-network/agent-interface': 1.0.0), and :28 ('@tangle-network/sandbox': 0.27.1) are exact, so bench's PACKED manifest
🟡 docs/STABILITY.md references a npm script that does not exist [maintenance] ``
docs/STABILITY.md:56 says
pnpm run check:published-rangespacks each publishable workspace package, but no package.json defines that script (rg over package.json and bench/package.json finds only the direct invocationnode ../scripts/check-published-ranges.mjs benchat bench/package.json:40, which pins the argument to bench and so does not match the doc's 'each publishable workspace package' claim). Prefer addingcheck:published-ranges": "node scripts/check-published-ranges.mjs"to root pa
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.
Bench inherits every catalog specifier verbatim into its published manifest, so Eval, Interface and Sandbox must carry ranges too.
|
The 🔴 audit is correct and already addressed — it ran on Restored on The check the audit ran and saw exit 1 now exits 0 on the same package: Two upstream releases were required to get here and both are live: agent-eval 0.147.0 declares All four CI checks are green on |
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
🟡 Value Audit — sound-with-nits
| Verdict | sound-with-nits |
| Coverage | 2 of 2 lenses (value, usefulness) |
| Concerns | 4 (1 strong-concern, 1 medium-concern, 2 weak-concern) |
| Heuristic | 0.0s |
| Duplication | 0.1s |
| Interrogation | 457.3s (2 bridge agents) |
| Total | 457.4s |
💰 Value — sound-with-nits
Publishes every first-party dependency as a range (catalog entries + workspace:^) and adds a tarball-level CI gate that refuses exact pins — the right fix for a real duplication defect, built in the repo's existing range-doctrine grain, with one internal inconsistency: the catalog uses 0.x carets wh
- What it does: Three things. (1) pnpm-workspace.yaml:21-28 converts the first-party catalog entries from exact versions to ranges, and bench/package.json:48 switches agent-runtime from workspace:* to workspace:^ — since
pnpm packbakes catalog:/workspace:* specifiers into the published manifest verbatim-as-exact, this changes what consumers resolve against from one permitted version to a range. (2) New scripts - Goals it achieves: Stop published manifests from forcing a second physical copy of a first-party package onto any consumer that already holds a later cohort member (two copies = two class identities, instanceof false across the seam — the concrete failure named in the PR body and docs/STABILITY.md). Make the defect mechanically impossible to republish: the guard reads the packed tarball, not the source manifest, bec
- Assessment: Good change on its merits. The defect diagnosis is correct, the fix at the catalog/workspace-specifier level is the minimal root-cause fix, and guarding at the packed tarball is the right measurement point — the repo's own verify-package-exports.mjs:831 single-copy check can only observe a fresh consumer install, never the consumer-holding-a-later-version case this prevents. It extends an establis
- Better / existing approach: Searched for an existing equivalent before answering: no semver library in the repo (grep for import/require of 'semver' — one prose mention in an examples PROVENANCE.md only); assertPublishableDependencySpecs (packed-package-test.mjs:3-15) already rejected protocol specs in packed manifests but said nothing about exactness; verify-package-exports.mjs and verify-packed-cohort.mjs prove single-copy
- Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 2
- Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error
🎯 Usefulness — sound-with-nits
The direction is correct and the pack-and-verify mechanism genuinely works, but the change is currently self-contradictory: pre-1.0 catalog entries use carets that its own enforcement cannot admit, so two required CI jobs fail until two entries are reverted to window form.
- Integration: Reachable on both packages. Bench: bench/package.json:40 wires
node ../scripts/check-published-ranges.mjs benchintoverify:package:static, reached by theagent-benchCI job (ci.yml viaverify:bench) and publish. Root: the packed runtime is guarded indirectly byassertFirstPartyRangeSpecsin verify-packed-cohort.mjs:303 (packed-cohort job, ci.yml:108) plus the peer-shape checks in verify - Fit with existing patterns: Extends the established pack-and-inspect pattern: it reuses
packed-package-test.mjs, which already heldassertPublishableDependencySpecsandassertPeerMatchesDevelopmentDependency, and thecohortRangerefactor folds in the oldexpectedPeerRangelogic rather than forking it. This is the same grain the repo already uses (pack the archive, read the packed manifest, never trust the source sp - Real-world viability: Fails its own verification as written. The catalog declares pre-1.0 cohort members with carets (
agent-eval: ^0.147.0at pnpm-workspace.yaml:23,sandbox: ^0.27.1at :28), but the peerDependencies keep the window shape (>=0.147.0 <0.148.0,>=0.27.1 <0.28.0at package.json:173,175) and the added docs mandate a window below 1.0.0. Two things break: (1)assertCohortRange(verify-official-opti - Model: opencode/deepseek/deepseek-v4-pro
- Bridge attempts: 3
- Bridge warning: opencode/zai-coding-plan/glm-5.2: opencode: opencode error; opencode/kimi-for-coding/k2p7: opencode: opencode error
💰 Value Audit
🟠 Catalog uses 0.x carets where the change's own rule, docs, and range model require the window shape [against-grain] ``
The PR's stated rule (PR body, and docs/STABILITY.md added in this PR: 'Below 1.0.0 — the narrower window >=X.Y.Z <X.Y+1.0') and the codebase's existing model agree that pre-1.0 ranges are windows: package.json:172-174 declares peers as >=0.147.0 <0.148.0 / >=0.27.1 <0.28.0, and caretAdmits (packed-package-test.mjs:64) deliberately refuses carets with floorMajor < 1. But the final catalog (pnpm-workspace.yaml:23,28, commit 71a4a07) writes ^0.147.0 and ^0.27.1. Semver-equivalent for resolution, b
🟡 Fourth copy of pack-and-read-tarball plumbing [duplication] ``
check-published-ranges.mjs:57-81 (mkdtemp, pnpm pack, tar -xOzf, read package/package.json) is now the fourth self-contained pack-and-inspect implementation beside verify-package-exports.mjs, verify-packed-cohort.mjs buildAndPack (:176), and verify-official-optimizers.mjs. Self-contained verify scripts are this repo's grain, so this does not gate shipping, but a shared packAndReadManifest in scripts/lib/ would absorb the next copy before it appears.
🎯 Usefulness Audit
🔴 Pre-1.0 catalog carets contradict the peer windows and break the change's own enforcement [robustness] ``
The catalog uses
^0.147.0/^0.27.1for agent-eval/sandbox (pnpm-workspace.yaml:23,28) while peerDependencies and the new docs use>=0.147.0 <0.148.0/>=0.27.1 <0.28.0(package.json:173,175). The enforcement added in this very change compares these strictly (assertVersionat verify-official-optimizers.mjs:363) andrangeAdmits/caretAdmitsreturns false for any pre-1.0 caret (packed-package-test.mjs:64), soverify:official-optimizers(ci.yml:162) andverify-packed-cohort.mjs(ci.yml
🟡 Docs reference a check:published-ranges script that does not exist [integration] ``
docs/STABILITY.md instructs running
pnpm run check:published-ranges, but no such script exists in root or bench package.json (the script is only reached asnode ../scripts/check-published-ranges.mjs benchfrom bench/package.json:40). Either add the alias or fix the doc; no behavior change.
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.
The cohort guard compares the peer declaration against the resolved development dependency verbatim, so the two must carry the same shape.
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
🟡 Value Audit — sound-with-nits
| Verdict | sound-with-nits |
| Coverage | 2 of 2 lenses (value, usefulness) |
| Concerns | 4 (1 strong-concern, 3 weak-concern) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 533.2s (2 bridge agents) |
| Total | 533.2s |
💰 Value — sound-with-nits
Converts exact first-party version pins into cohort ranges at the publish boundary (catalog ranges + workspace:^, verified against the packed tarball by a new check) — a correct, in-grain fix for a real duplicate-install defect, with two small wiring/doc nits.
- What it does: Changes every first-party
@tangle-network/*catalog entry in pnpm-workspace.yaml from an exact version to a range (caret form: ^0.147.0, ^1.0.0, ^8.0.7, ^0.27.1, ^0.9.4, ^0.16.0), changes bench's agent-runtime dependency fromworkspace:*toworkspace:^(pnpm packs workspace:* as an exact version, workspace:^ as a caret), restates root peerDependencies in the same caret form, and adds scripts - Goals it achieves: Prevents published manifests from forcing duplicate physical copies of first-party packages onto consumers: an exact pin means any consumer already holding a later cohort member (e.g. agent-eval 0.146.0 vs the pinned 0.145.21) installs a second copy — two class identities,
instanceoffalse across the seam. Becausecatalog:andworkspace:*are silently replaced by exact versions at pack time, - Assessment: Good change, well executed. The defect is real (main's catalog carried exact pins — 0.146.0, 1.0.0, 8.0.6, 0.27.1 — and bench used workspace:*, which is exactly what produced the pinned agent-bench@0.8.12 manifest). The fix uses the idiomatic pnpm mechanisms rather than fighting them: catalog ranges survive pack as ranges, workspace:^ packs as a caret. The check inspects the packed archive, not th
- Better / existing approach: none — this is the right approach. Searched for prior art: publint/attw check exports, not specifier shapes; bench's verify-packed-consumer.mjs and wait-for-published-dependencies.mjs assert resolution, not range form; nothing on main detected the defect (it shipped). A
semver-library implementation would be heavier than the two constrained range shapes the repo already hand-parses elsewhere in - Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 2
- Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error
🎯 Usefulness — sound-with-nits
The core change — publishing first-party deps as ranges instead of exact pins — is correct, empirically verified on packed tarballs, and wired into CI and publish; one helper gap (rangeAdmits rejects the pre-1.0 caret spelling the catalog itself now uses) deterministically reds verify-official-optim
- Integration: Reachable and wired in three places, all exercised in CI/publish: (1) scripts/check-published-ranges.mjs is invoked from bench/package.json:40 (
verify:package:static), which runs via verify:bench (ci.yml:137) and verify:bench:published (publish.yml:303); (2) assertFirstPartyRangeSpecs is applied to every packed cohort package in verify-packed-cohort.mjs:303, run at ci.yml:108 and publish.yml:160 - Fit with existing patterns: Extends the codebase's existing
expectedPeerRangepattern rather than competing with it: cohortRange (packed-package-test.mjs:81-86) delegates to expectedPeerRange for exact specs, and assertPeerMatchesDevelopmentDependency (packed-package-test.mjs:131-142) now goes through cohortRange. It also matches the pre-existing 'shared contract peer' release philosophy (verify-packed-cohort.mjs:624-635, - Real-world viability: The happy path holds up (packed manifests verified, check-published-ranges exits 0, 10/10 unit tests pass). But it fails its own verification gate on the pre-1.0 caret form: caretAdmits returns false whenever floorMajor < 1 (packed-package-test.mjs:64), and rangeAdmits (line 101-103) is just caretAdmits || windowAdmits, so
rangeAdmits('^0.147.0','0.147.0') === false. The catalog now spells pre-1 - Model: opencode/deepseek/deepseek-v4-pro
- Bridge attempts: 3
- Bridge warning: opencode/zai-coding-plan/glm-5.2: opencode: opencode error; opencode/kimi-for-coding/k2p7: opencode: opencode error
💰 Value Audit
🟡 docs/STABILITY.md names a script that does not exist (pnpm run check:published-ranges) [maintenance] ``
docs/STABILITY.md:56 tells maintainers to run
pnpm run check:published-ranges, but no package.json in the workspace defines that script (grep found the invocation only asnode ../scripts/check-published-ranges.mjs benchinside bench's verify:package:static, bench/package.json:40). One-line fix: add "check:published-ranges": "node scripts/check-published-ranges.mjs" to root package.json scripts, which also makes the doc command real.
🟡 New check not wired into root's verify:package; root covered only by the heavy cohort job [better-architecture] ``
bench's verify:package:static invokes the check with the
benchargument only (bench/package.json:40), and root's verify:package (package.json:139) does not invoke it at all, so the root package's packed first-party specs are gated only by verify-packed-cohort.mjs:303 (needs clean sibling repo checkouts) and verify-official-optimizers.mjs peer assertions in CI. Addingnode scripts/check-published-ranges.mjs(default args cover both workspace packages) to root's verify:package would give the r
🎯 Usefulness Audit
🔴 rangeAdmits rejects the pre-1.0 caret spelling the catalog now uses; verify-official-optimizers reds [robustness] ``
caretAdmits hard-returns false for any pre-1.0 floor (scripts/lib/packed-package-test.mjs:64
if (floorMajor < 1 ...) return false), so rangeAdmits (packed-package-test.mjs:101-103) cannot admit^0.147.0or^0.27.1. The change's own catalog and peerDependencies use exactly those carets (pnpm-workspace.yaml:23,28; package.json:173,175). Result:node scripts/verify-official-optimizers.mjsthrows at line 51 (installed @tangle-network/agent-eval@0.147.0 is outside the catalog range ^0.147.0
🟡 assertFirstPartyRangeSpecs now also gates external cohort repos' packed manifests [integration] ``
verify-packed-cohort.mjs:303 applies assertFirstPartyRangeSpecs to agent-interface/eval/knowledge (external repos) in addition to agent-runtime. I fetched the pinned refs: agent-eval@0.147.0 deps are all ranges (^0.9.4, ^1.0.0, ^1.0.2) and agent-knowledge@8.0.7 peers are ranges (>=0.147.0 <0.148.0, ^1.0.0); their exact pins live only in devDependencies, which the check intentionally ignores (packed-package-test.mjs:116). So it passes today, but a future external release reintroducing an exact pi
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.
❌ Needs Work —
|
| opencode GLM 5.2 | opencode DeepSeek v4 Pro | opencode DeepSeek v4 Flash | aggregate | |
|---|---|---|---|---|
| Readiness | 0 | 0 | 0 | 0 |
| Confidence | 95 | 95 | 95 | 95 |
| Correctness | 0 | 0 | 0 | 0 |
| Security | 0 | 0 | 0 | 0 |
| Testing | 0 | 0 | 0 | 0 |
| Architecture | 0 | 0 | 0 | 0 |
Reviewer score is advisory once the run is complete and the verdict has no blockers.
Full multi-shot audit completed 8/8 planned shots over 16 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 8/8 planned shots over 16 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 8/8 planned shots over 16 changed files. Global verifier still owns final merge decision.
Blocking
🟣 CRITICAL Check fails against its own workspace, breaking the agent-bench CI job — scripts/check-published-ranges.mjs
Reproduced:
node scripts/check-published-ranges.mjs benchexits 1 with "@tangle-network/agent-bench publishes exact first-party version pins ... dependencies.@tangle-network/agent-eval = 0.147.0, dependencies.@tangle-network/agent-interface = 1.0.0, dependencies.@tangle-network/sandbox = 0.27.1". bench/package.json declares those three ascatalog:, and pnpm-workspace.yaml still pins them exactly (agent-eval: 0.147.0, agent-interface: 1.0.0, sandbox: 0.27.1);pnpm packcopies the catalog value verbatim into the packed manifest, so assertFirstPartyRangeSpecs (line 84) throws. This script is invoked from bench'sverify:package:static(bench/package.js
🔴 HIGH agent-knowledge@8.0.6 peer-dep range excludes the newly-pinned agent-eval 0.147.0 — pnpm-lock.yaml
The catalog bumps @tangle-network/agent-eval to 0.147.0 (pnpm-workspace.yaml:23), and the local package's peerDep was correctly widened to '>=0.147.0 <0.148.0' (package.json:173). But the published @tangle-network/agent-knowledge@8.0.6 manifest still declares peerDependencies '@tangle-network/agent-eval': '>=0.146.0 <0.147.0' (pnpm-lock.yaml:1147-1148), yet the snapshot resolves agent-knowledge@8.0.6 with agent-eval@0.147.0 as its peer (pnpm-lock.yaml:3200-3202). agent-eval 0.147.0 is outside the '<0.147.0' bound, so this is an unmet peer dependency that pnpm will flag (and would fail under strict-peer-dependencies), and agent-knowledge 8.0.6 has not declared compatibility with agent-eval 0.147.0 — a potential runtime API mismatch. Fix: bump @tangle-network/agent-knowledge to a release who
🔴 HIGH Catalog conversion incomplete: 3 first-party entries still exact, breaking the PR's own published-ranges gate and shipping exact pins in agent-bench — pnpm-workspace.yaml
Lines 23, 24, 28 keep '@tangle-network/agent-eval': 0.147.0, '@tangle-network/agent-interface': 1.0.0, '@tangle-network/sandbox': 0.27.1 as exact pins while lines 21/25/26 were converted to ranges. bench/package.json declares all three as runtime dependencies via
catalog:and bench is publishable (no private flag; packed and published by publish.yml:322), so the packed agent-bench manifest ships exact first-party pins - the exact duplicate-copy/instanceof defect docs/STABILITY.md (this PR) documents. Empirically verified: `node scripts/check-publishe
🔴 HIGH Catalog conversion incomplete: bench still publishes exact first-party pins, failing the PR's own new check — pnpm-workspace.yaml
The PR converts 3 catalog entries to ranges (agent-core ^0.9.4, agent-knowledge ^8.0.6, agent-profile-materialize ^0.16.0) but leaves @tangle-network/agent-eval (0.147.0), @tangle-network/agent-interface (1.0.0), and @tangle-network/sandbox (0.27.1) exact. bench/package.json:45-49 declares these three via
catalog:plus agent-runtimeworkspace:^, so the packed @tangle-network/agent-bench manifest inherits exact pins for eval/interface/sandbox. Empirically verified:node scripts/check-published-ranges.mjs bench(the exact command CI runs via verify:bench -> verify:package:static -> check-published-ranges.mjs bench in .github/workflows/ci.yml agent-bench job and publish.yml verify-agent-bench) exits 1 with 'dependencies.@tangle-network/agent-eval = 0.147.0', 'dependencies.@tangle-networ
🔴 HIGH agent-eval bump breaks agent-knowledge peer range (unmet peer, pnpm peers check exits 1) — pnpm-workspace.yaml
Catalog bumps '@tangle-network/agent-eval' from 0.146.0 to 0.147.0 (line 23) while '@tangle-network/agent-knowledge' stays resolvable only to 8.0.6 (line 25, '^8.0.6' resolves to 8.0.6 in the committed lockfile). agent-knowledge@8.0.6 declares peerDependencies['@tangle-network/agent-eval'] = '>=0.146.0 <0.147.0' (lockfile package entry), which excludes 0.147.0. Verified:
pnpm peers check-> exit 1, 'unmet peer @tangle-network/agent-eval: Installed 0.147.0, Wanted >=0.146.0 <0.147.0 (@tangle-network/agent-knowledge@8.0.6)'. package.json also raises th
🔴 HIGH Gate fails the PR's own tree: packed bench carries exact first-party pins — scripts/check-published-ranges.mjs
Running the wired command
node scripts/check-published-ranges.mjs bench(bench/package.json:40,verify:package:static) exits 1 with:dependencies.@tangle-network/agent-eval = 0.147.0,dependencies.@tangle-network/agent-interface = 1.0.0,dependencies.@tangle-network/sandbox = 0.27.1. Repro: pnpm pack rewrites bench'scatalog:specifiers (bench/package.json:46-50) to the exact catalog values in pnpm-workspace.yaml (agent-eval0.147.0, agent-interface1.0.0, sandbox0.27.1); I confirmed this rewrite behavior in a minimal workspace (catalog: -> exact, workspace:^ -> ^range) and on the real tree. CI agent-bench job runspnpm run verify:bench->verify:package:local-runtime->verify:package:static, so this PR's CI is red; publish.yml verify-agent-bench is red the same w
🔴 HIGH New gate fails required agent-bench CI at head: bench publishes exact first-party pins from exact catalog entries — scripts/check-published-ranges.mjs
Evidence: GitHub check-runs for head 8dcdb6c list agent-bench=failure; job 95259997440 log shows this script output: '@tangle-network/agent-bench publishes exact first-party version pins ... dependencies.@tangle-network/agent-eval = 0.147.0, agent-interface = 1.0.0, sandbox = 0.27.1' followed by exit code 1. Root cause is out-of-shot but shipped by this same PR: bench/package.json declares these as 'catalog:' and pnpm-workspace.yaml still holds them exact (0.147.0, 1.0.0, 0.27.1) after commit b10d6c8 converted only agent-core/knowledge/profile-materialize to ranges. pnpm substitutes the catalog specifier verbatim at pack time, so the packed manifest carries exact pins and the script correctly fails. Impact: verify:bench (ci.yml:137) and the publish workflow (publish.yml:174,303) are red a
🔴 HIGH New first-party range check fails on the PR's own bench package, breaking verify:bench in CI — scripts/lib/packed-package-test.mjs
The check works as designed, but the PR head violates its own rule.
pnpm packof bench resolvescatalog:to exact pins from pnpm-workspace.yaml, which still declares@tangle-network/agent-eval: 0.147.0,@tangle-network/agent-interface: 1.0.0,@tangle-network/sandbox: 0.27.1. Measured packed bench manifest deps:{agent-eval: 0.147.0, agent-interface: 1.0.0, sandbox: 0.27.1, agent-knowledge: ^8.0.6, agent-runtime: ^0.140.0}.node scripts/check-published-ranges.mjs benchexits 1. This runs in CI viaverify:bench->verify:package:local-runtime->verify:package:static, which this PR extended with&& node ../scripts/check-published-ranges.mjs bench(bench/package.json:40). The PR converted agent-runtime toworkspace:^and catalog agent-core/knowledge/profile-materialize
🔴 HIGH Packed devDependency asserts compare an exact version to a derived range string with strict equality — scripts/verify-official-optimizers.mjs
assertVersion is strict string equality (line 363). After
pnpm pack, the tarball devDependencies resolve catalog: to exact versions (verified by packing: agent-eval=0.147.0, agent-interface=1.0.0, sandbox=0.27.1), so packedAgentEvalVersion='0.147.0'. catalogRange('@tangle-network/agent-eval') returns cohortRange('0.147.0')='>=0.147.0 <0.148.0'. '0.147.0' !== '>=0.147.0 <0.148.0', so the script always throws here (same for agent-interface and sandbox at 107-121). CI confirms: official-optimizers job on head fails at this exact line. Fix: compare cohortRange(packedAgentEvalVersion) to catalogRange(...), or assert rangeAdmits(catalogRange(...), packedA
🔴 HIGH Verification script deterministically fails at line 102: packed catalog specs are compared by string equality against derived ranges — scripts/verify-official-optimizers.mjs
pnpm pack writes catalog: entries into the packed manifest verbatim (empirically confirmed; also stated in PR commit b10d6c8's message). The workspace catalog pins '@tangle-network/agent-eval': 0.147.0, 'agent-interface': 1.0.0, 'sandbox': 0.27.1 exactly, so the packed devDependencies are '0.147.0'/'1.0.0'/'0.27.1'. catalogRange() converts those exact entries to '>=0.147.0 <0.148.0'/'^1.0.0'/'>=0.27.1 <0.28.0' via cohortRange, and assertVersion is strict string equality, so line 102 always throws. Proven by CI on head SHA 8dcdb6c: the official-optimizers job failed with 'packed @tangle-network/agent-eval development dependency must be >=0.147.0 <0.1
🔴 HIGH assertInstalledAdmitted passes an exact version as a range, so rangeAdmits always returns false — scripts/verify-official-optimizers.mjs
assertInstalledAdmitted(appDir, '@tangle-network/agent-eval', packedAgentEvalVersion) feeds packedAgentEvalVersion ('0.147.0', an exact spec) into rangeAdmits(range, actual). rangeAdmits only supports caret (^X.Y.Z with major>=1) and window (>=X.Y.Z <X.Y+1.0) shapes; an exact '0.147.0' matches neither caretAdmits nor windowAdmits, so it returns false for every installed version and throws 'outside its declared range'. Same for agent-interface (line 162-166) and sandbox (line 167). This call site is currently
🔴 HIGH assertInstalledAdmitted receives exact version strings that rangeAdmits can never admit — scripts/verify-official-optimizers.mjs
Lines 161-167 call assertInstalledAdmitted(appDir, name, packedAgentEvalVersion|packedAgentInterfaceVersion|packedSandboxVersion) passing exact resolved versions ('0.147.0', '1.0.0', '0.27.1'). rangeAdmits only recognizes caret (^X.Y.Z) and window (>=X.Y.Z <A.B.C) shapes; direct execution confirms rangeAdmits('0.147.0','0.147.0') === false, so this always throws 'installed @tangle-network/agent-eval@0.147.0 is outside its declared range 0.147.0'. Masked today only because the earlier packed-assert (line 102)
🔴 HIGH assertVersion compares exact packed devDependency against expanded cohort range and always throws — scripts/verify-official-optimizers.mjs
packedAgentEvalVersion = requiredPackedDevelopmentDependency(...) returns the packed devDependency string. For the catalog entry '@tangle-network/agent-eval: 0.147.0' (exact), pnpm pack inherits the specifier verbatim (stated in commit b10d6c8), so packedAgentEvalVersion === '0.147.0'. But catalogRange('@tangle-network/agent-eval') === cohortRange('0.147.0') === '>=0.147.0 <0.148.0'. assertVersion does
actual !== expected, so '0.147.0' !== '>=0.147.0 <0.148.0' throws at line 104. Same for agent-interface ('1.0.0' vs '^1.0.0', [line 107](https://github.com/tangle-network/agent-runtime/blob/8dcdb6c75b7ddcbce43a7f8b03db3fc9e7e0021f/scripts/verify-offi
Other
🟠 MEDIUM Doc asserts repo-wide conformance the repo does not hold — docs/STABILITY.md
Lines 44 and 54 claim every published @tangle-network/* specifier is a range and that the range is 'stated once, in the catalog block'. Verified false at head: running the actual check (
node scripts/check-published-ranges.mjs bench) exits 1 withdependencies.@tangle-network/agent-eval = 0.147.0,dependencies.@tangle-network/agent-interface = 1.0.0,dependencies.@tangle-network/sandbox = 0.27.1. These exact pins originate inpnpm-workspace.yamlcatalog:and are inlined when bench is packed, exactly the failure the doc describes — but the doc presents conformance as current fact. Impact: the added section is the contract this PR ships, and it is contradicted by t
🟠 MEDIUM Doc instructs a command that does not exist — docs/STABILITY.md
pnpm run check:published-rangeserrors with[ERR_PNPM_NO_SCRIPT] Missing scriptat head 8dcdb6c; grep across the tree findscheck:published-rangesonly in this doc line. The actual invocations arenode scripts/check-published-ranges.mjs(standalone) andbench/package.json:40verify:package:static(node ../scripts/check-published-ranges.mjs bench). Impact: a reader following the doc runs a command that fails immediately. Fix: name the real entrypoint (e.g.node scripts/check-published-ranges.mjs) or add the root script referenced by the doc.
🟠 MEDIUM Documented enforcement command does not exist — docs/STABILITY.md
The doc says
pnpm run check:published-rangespacks each publishable package and fails on exact first-party pins. Running it at head fails: [ERR_PNPM_NO_SCRIPT] Missing script: check:published-ranges (verified by execution). No such alias exists in root package.json or bench/package.json; the check is reachable only asnode scripts/check-published-ranges.mjs [dirs]or via bench's verify:package:static. The stability contract's enforcement step is unrunnable as written. Fix: add "check:published-ranges": "node scripts/check-published-ranges.mjs" to root package.json scripts (package.json is already in this PR), or document the node invocation.
🟠 MEDIUM Stated invariant fails at head on the repo's other publishable package — docs/STABILITY.md
'Every @tangle-network/* specifier this package publishes is a range, never one exact version' is true only for the root agent-runtime package (verified). The doc's own described enforcement, run over 'each publishable workspace package', fails at head:
node scripts/check-published-ranges.mjs benchexits 1 with exact pins dependencies.@tangle-network/agent-eval = 0.147.0, @tangle-network/agent-interface = 1.0.0, @tangle-network/sandbox = 0.27.1 (bench declares the cohort as regularcatalog:dependencies and the catalog keeps those three entries exact). This PR's CI runs that exact check (ci.yml:137 verify:bench -> bench verify:package:static -> check-published-ranges.mjs bench), so the tree is self-inconsistent: the policy doc ships alongside a red enforcement. Root cause lives in benc
🟠 MEDIUM agent-knowledge@8.0.6 paired with out-of-range agent-eval@0.147.0 peer — pnpm-lock.yaml
Line 1148 records knowledge@8.0.6's peer range '@tangle-network/agent-eval': '>=0.146.0 <0.147.0' (verified against the npm registry), but the snapshot at lines 3200-3202 binds that peer to 0.147.0, which the range excludes. pnpm emits only a peer-dependency warning (settings: autoInstallPeers: true, no strictPeerDependencies), so
pnpm install --frozen-lockfilein CI (.github/workflows/ci.yml lines 39/129/159) succeeds while testing a p
🟠 MEDIUM agent-knowledge@8.0.6 peer resolved to out-of-range agent-eval@0.147.0 — pnpm-lock.yaml
The agent-eval bump 0.146.0 -> 0.147.0 (catalog + root peerDeps '>=0.147.0 <0.148.0' + all importers) makes the lockfile resolve agent-knowledge@8.0.6's peer to agent-eval@0.147.0, but agent-knowledge@8.0.6 declares peerDependencies '@tangle-network/agent-eval': '>=0.146.0 <0.147.0' (lock line 1148; confirmed against https://registry.npmjs.org/@tangle-network/agent-knowledge/8.0.6). 0.147.0 is not < 0.147.0, so the peer contract is violated. Evidence in the installed tree: node_modules/.pnpm contains only agent-eval@0.147.0 and the agent-knowledge dir keyed to agent-eval@0.147.0; no nested 0.146.0 peer copy exists. agent-knowledge@8.0.6 is the latest published version, so n
🟠 MEDIUM Pre-1.0 caret ranges pass assertFirstPartyRangeSpecs but are never admitted by rangeAdmits — scripts/lib/packed-package-test.mjs
caretAdmits returns false for any floorMajor < 1 (line 64) and windowAdmits' regex rejects
^..., sorangeAdmits('^0.9.4', '0.9.4')andrangeAdmits('^0.9.4', '0.9.5')both return false. Real npm semver admits them. This PR itself introduces the first pre-1.0 caret:pnpm-workspace.yamlnow has@tangle-network/agent-core: ^0.9.4, which assertFirstPartyRangeSpecs accepts (not exact) while rangeAdmits can never admit. In verify-packed-cohort.assertExactDependency (line 603) thedeclared === dependency.versionequ
🟠 MEDIUM rangeAdmits rejects pre-1.0 caret ranges that the catalog now contains — scripts/lib/packed-package-test.mjs
rangeAdmits ORs caretAdmits and windowAdmits. caretAdmits (line 64) returns false when floorMajor < 1, and windowAdmits only matches the literal
>=X.Y.Z <X.Y.Zshape, so rangeAdmits('^0.9.4', '0.9.5') === false even though^0.9.4admits0.9.5under semver. This PR adds^0.9.4(agent-core) and^0.16.0(agent-profile-materialize) to pnpm-workspace.yaml's catalog, and cohortRange passes^0.x.ythrough unchanged (line 85), so catalogRange() for those names yields a range that rangeAdmits always rejects. No curren
🟠 MEDIUM assertInstalledAdmitted receives the packed spec as a 'range' but rangeAdmits parses only ^X.Y.Z and >=a <b shapes, so exact specs always fail — scripts/verify-official-optimizers.mjs
Lines 161-167 pass packedAgentEvalVersion/packedAgentInterfaceVersion/packedSandboxVersion as the range argument. With the current exact catalog those are '0.147.0'/'1.0.0'/'0.27.1'; rangeAdmits('0.147.0', '0.147.0') returns false (verified by execution: caretAdmits and windowAdmits regexes both fail to parse a bare exact spec), so even if line 102 were relaxed, these assertions throw 'installed ... is outside its declared range 0.147.0' despite the installed version matching exactly. The same exact specs ar
🟠 MEDIUM PR's own range gate fails bench: workspace catalog still pins three first-party packages exactly — scripts/verify-packed-cohort.mjs
The assertion this shot adds (assertFirstPartyRangeSpecs on packed manifests) is not backed by repo-wide compliance in this PR. Empirically verified:
node scripts/check-published-ranges.mjs benchfails because the packed bench manifest contains exact first-party pins@tangle-network/agent-eval: 0.147.0,@tangle-network/agent-interface: 1.0.0,@tangle-network/sandbox: 0.27.1— resolved from thepnpm-workspace.yamlcatalog, which still declares those three as exact versions (only agent-core, agent-knowledge, agent-profile-materialize, agent-trace-contract were converted to ranges). CI's agent-bench job runsverify:bench-> benchverify:package:local-runtime->verify:package:static->check-published-ranges.mjs bench, so that job is red at this head. Root cause is in pnpm-w
🟡 LOW 'catalog: replaced by an exact version' is imprecise — docs/STABILITY.md
The sentence 'A catalog: specifier ... [is] replaced by an exact version when packed' is only true when the catalog value is an exact pin. For the real published dependencies the catalog holds ranges (agent-core ^0.9.4, agent-knowledge ^8.0.6, agent-profile-materialize ^0.16.0, agent-trace-contract ^1.0.2), so catalog: resolves to a range, not an exact version. Only workspace:* genuinely resolves to an exact version. Consider wording to 'replaced by the catalog's declared value' to avoid teaching a contributor that catalog entries are always exact.
🟡 LOW Catalog sentences describe the pre-fix state, not the state this PR creates — docs/STABILITY.md
Line 54: 'The range is stated once, in the catalog: block of pnpm-workspace.yaml' — false for the three first-party peers: the catalog holds exact pins (agent-interface 1.0.0, agent-eval 0.147.0, sandbox 0.27.1) and their published ranges live in root package.json peerDependencies (^1.0.0, >=0.147.0 <0.148.0, >=0.27.1 <0.28.0). A maintainer widening a cohort range per this doc would edit the catalog and change nothing published. Line 55: 'a catalog: specifier ... [is] replaced by an exact version when the package is packed' — stale post-fix: pnpm writes th
🟡 LOW Documented command does not exist — docs/STABILITY.md
The doc instructs 'pnpm run check:published-ranges', but no package.json (root or bench) defines a script by that name. grep for the literal script name returns only this doc line. The real script scripts/check-published-ranges.mjs is wired only into bench/package.json:40 as 'node ../scripts/check-published-ranges.mjs bench' under verify:package:static. A contributor following the doc gets 'No script named check:published-ranges'. Fix: reference 'node scripts/check-published-ranges.mjs' (or add the missing npm script and keep the name).
🟡 LOW Range location and 'stated once' are inaccurate for peer deps — docs/STABILITY.md
Doc says 'The range is stated once, in the catalog: block of pnpm-workspace.yaml', but the published peer ranges for the three first-party peers live in package.json peerDependencies (agent-interface ^1.0.0, agent-eval >=0.147.0 <0.148.0, sandbox >=0.27.1 <0.28.0), while the catalog entries for those exact packages are exact pins (agent-interface: 1.0.0, agent-eval: 0.147.0, sandbox: 0.27.1) used only via devDependencies. So the range is not in the catalog for peers, and it is not 'stated once' (catalog + peerDependencies).
🟡 LOW Catalog pin style inconsistent across the bumped @tangle-network/* entries — pnpm-lock.yaml
The same change widens agent-core to '^0.9.4', agent-knowledge to '^8.0.6', and agent-profile-materialize to '^0.16.0' while agent-eval stays exact at '0.147.0'. Nothing in the lock is inconsistent (all resolve to the listed versions), and the exact pin on agent-eval is plausibly deliberate, but the divergent specifier styles mean a future minor release will auto-resolve the caret'd entries while silently skipping agent-eval. This is a consistency nit, not a bug; note it only if the release checklist expects uniform catalog specifiers.
🟡 LOW Caret ranges on pre-1.0 packages contradict repo range convention and its own rangeAdmits helper — pnpm-workspace.yaml
agent-core (0.9.4) and agent-profile-materialize (0.16.0), both pre-1.0, are changed from exact pins to caret ranges '^0.9.4' (line 21) and '^0.16.0' (line 26). docs/STABILITY.md states 'Below 1.0.0 — the narrower window >=X.Y.Z <X.Y+1.0', and scripts/lib/packed-package-test.mjs expectedPeerRange() emits that window form for pre-1.0, while caretAdmits() returns false whenever the floor major is <1 ('if (floorMajor < 1 ...) return false'). Consequently the repo's own rangeAdmits('^0.9.4', '0.9.4') returns false, and assertExactDependency/assertCatalogAd
🟡 LOW Pre-1.0 caret specs contradict the PR's own range policy and rangeAdmits helper — pnpm-workspace.yaml
Lines 21 and 26 use '^0.9.4' (agent-core) and '^0.16.0' (agent-profile-materialize), but the STABILITY.md policy added in this PR states pre-1.0 first-party ranges use the window '>=X.Y.Z <X.Y+1.0', and the PR's own caretAdmits (scripts/lib/packed-package-test.mjs:64) deliberately returns false for any ^0.x range because a pre-1.0 caret is not a compatibility statement in their model. Semver-wise ^0.9.4 equals >=0.9.4 <0.10.0, so behavior is correct today, and no current rangeAdmits caller covers agent-core or agent-profile-materialize (verify-packed-cohort.mjs:609 only checks eval/interface/knowledge; verify-official-optimizers.mjs:51-54 checks eval/interface/sandbox/kn
🟡 LOW Pre-1.0 catalog entries use caret where the check prescribes a minor window — pnpm-workspace.yaml
agent-core
^0.9.4and agent-profile-materialize^0.16.0are caret on pre-1.0 packages. Semantically^0.9.4==>=0.9.4 <0.10.0and^0.16.0==>=0.16.0 <0.17.0, so admission is identical and rangeAdmits/windowAdmits both pass. Cosmetic inconsistency only: scripts/lib/packed-package-test.mjs:126 and check-published-ranges.mjs tell authors to use '>=X.Y.Z <X.Y+1.0' below 1.0.0, so the workspace and the error message disagree about the canonical sub-1.0 shape. No functional impact; suggest aligning to the window form for consistency with the documented policy.
🟡 LOW Globbed pnpm-workspace entries hard-throw instead of being skipped — scripts/check-published-ranges.mjs
Any workspace entry containing '' throws ('pnpm-workspace.yaml entry is not a plain directory'). Globs are pnpm's normal idiom (e.g. 'packages/'); today's workspace lists only 'bench' so this is latent, and the throw is fail-closed with a clear message, but the first future package added as 'packages/*' breaks the no-arg default path with a hard error rather than a targeted skip or glob expansion.
🟡 LOW POSIX-only assumptions: execFileSync('pnpm') and 'tar -xOzf' — scripts/check-published-ranges.mjs
On Windows, spawn of 'pnpm' without shell resolves to pnpm.cmd and fails (EINVAL/ENOENT) since Node >=18.20 hardened .cmd handling, and tar extraction assumes bsdtar/GNU tar CLI. CI runs on Linux (agent-bench job verified green-path on ubuntu), so this is a local-developer portability nit only. If Windows contributors matter, switch to 'pnpm.cmd' detection or shell:true with a fixed argv, and prefer a Node tar reader already present in the tree (tar-stream is a root dependency).
🟡 LOW Pack failures abort immediately instead of aggregating with assertion failures — scripts/check-published-ranges.mjs
packedManifest() is called outside the try/catch (line 81), so a pnpm pack or tar failure on one package throws an uncaught error and halts the loop, while assertion failures are collected into
failuresand reported together. One broken package hides all later packages and exits with a raw stack trace rather than a tidy message. Minor consistency issue; wrap the pack step in the same aggregation or fail fast deliberately and document it.
🟡 LOW Pack-time errors bypass the failures[] aggregation and abort the run — scripts/check-published-ranges.mjs
assertPublishableDependencySpecs/assertFirstPartyRangeSpecs errors are caught and aggregated (lines 82-88), but any throw from packedManifest (pnpm pack failure, 'produced N archives, expected exactly one', tar/JSON errors) propagates uncaught: one broken package aborts the loop with a stack trace and skips checks for every remaining package. Still fail-closed (non-zero exit), so correctness is preserved, but the diagnostic shape is inconsistent with the intentional failures[] design. Wrap the packedManifest call in the same try/catch used for the asserts.
🟡 LOW Script pack-and-read path has no test coverage — scripts/check-published-ranges.mjs
packed-package-test.test.mjs covers only the pure lib functions (10 passing cases); nothing exercises packedManifest(), pnpm pack + tar extraction, or the default workspace enumeration. The failing bench integration (exact catalog pins) was precisely the case unit tests could not catch. Add an integration test that packs a fixture workspace with an exact catalog entry and asserts exit code 1. Also note workspacePackageDirectories() (line 31) throws on any glob entry; harmless today (pnpm-workspace.yaml lists only
bench) but a hard failure if the workspace ever grows topackages/*.
🟡 LOW Success summary omits optionalDependencies that the assertions check — scripts/check-published-ranges.mjs
assertFirstPartyRangeSpecs and assertPublishableDependencySpecs both cover 'dependencies', 'optionalDependencies', 'peerDependencies' (packed-package-test.mjs lines 6 and 116), but the printed first-party summary merges only dependencies and peerDependencies (lines 89-92). A package whose only first-party specs are optionalDependencies prints 'no first-party dependencies' on the success line. Gate is unaffected; reporting is inconsistent with what was verified.
🟡 LOW Summary line omits optionalDependencies that the check covers — scripts/check-published-ranges.mjs
The stdout summary (lines 89-94) merges only dependencies and peerDependencies, while assertFirstPartyRangeSpecs and assertPublishableDependencySpecs both also inspect optionalDependencies. A package whose only first-party specifier lives in optionalDependencies would print 'no first-party dependencies' despite those specs being checked. Cosmetic; align the summary with the checked sections.
🟡 LOW Summary line omits optionalDependencies while the gates include them — scripts/check-published-ranges.mjs
assertPublishableDependencySpecs/assertFirstPartyRangeSpecs iterate dependencies, optionalDependencies, and peerDependencies (packed-package-test.mjs:6,116), but the informational stdout line (lines 89-92) only merges dependencies + peerDependencies. An exact first-party pin in optionalDependencies fails the gate yet is invisible in the per-package summary. Include optionalDependencies in the summary for parity.
🟡 LOW Build-metadata acceptance is inconsistent between isExactVersionSpec and expectedPeerRange — scripts/lib/packed-package-test.mjs
isExactVersionSpec accepts '1.2.3+sha.abc' ((?:[-+].)? allows '+') but expectedPeerRange's regex /^ (\d+).\d+.\d+(?:-.+)?$/ rejects it, so cohortRange('1.2.3+sha.abc') throws 'cannot derive peer range from version 1.2.3+sha.abc' (verified by execution). Fail-closed, so no correctness hole, but the same literal is classified exact by one predicate and underivable by the next. Fix: accept (?:[-+].)? consistently in expectedPeerRange and currentMinorPeerRange, or narrow exactVersion to prerelease-only suffixes.
🟡 LOW Exact-pin guard misses npm-valid exact forms 'v1.2.3' and '=1.2.3' — scripts/lib/packed-package-test.mjs
The anchored regex /^\d+.\d+.\d+(?:[-+].*)?$/ does not match 'v1.0.0' or '=1.2.3' (verified by execution: both return false). npm/pnpm accept both as exact specifiers, and catalog entries are copied verbatim into the packed manifest, so a first-party catalog entry written 'v1.2.3' would publish an exact pin and escape assertFirstPartyRangeSpecs. Impact is narrow: the docstring's threat model (catalog:/workspace: auto-resolution) always produces bare X.Y.Z, and workspace version fields cannot be v-prefixed. Fix: allow an optional 'v' prefix and a leading '=' in the regex and strip them before delegating to expectedPeerRange.
🟡 LOW cohortRange trims exact specs but returns range specs untrimmed — scripts/lib/packed-package-test.mjs
For an exact spec cohortRange uses spec.trim() (via expectedPeerRange(spec.trim())), but for a non-exact spec it returns
specraw. cohortRange(' ^1.0.0') returns ' ^1.0.0' with the leading space (isExactVersionSpec trims internally, so it is classified as a range), and the downstream literal comparisons in assertPeerMatchesDevelopmentDependency (line 135) and assertVersion would then misfire. Low impact: catalog/YAML values are clean, but the asymmetry is a landmine for future inputs.
🟡 LOW isExactVersionSpec and cohortRange disagree on build-metadata versions — scripts/lib/packed-package-test.mjs
exactVersion (line 68) accepts
[-+].*build metadata, soisExactVersionSpec('1.2.3+build')is true, but expectedPeerRange's regex (line 52) only accepts(?:-.+)?, socohortRange('1.2.3+build')throwscannot derive peer range from version 1.2.3+build. A packed manifest carrying a build-metadata pin crashes assertPeerMatchesDevelopmentDependency/check-published-ranges with a confusing error instead of a clear range message. Verified by execution. Fix: drop+from exactVersion or extend expectedPeerRange to stri
🟡 LOW windowAdmits cannot match a prerelease floor that expectedPeerRange produces — scripts/lib/packed-package-test.mjs
currentMinorPeerRange('0.27.1-rc.1') returns
>=0.27.1-rc.1 <0.28.0, but windowAdmits' regex /^>=(\d+).(\d+).(\d+)\s+<.../ requires the floor to be three bare integers with no prerelease suffix, so rangeAdmits returns false for the floor version itself. isExactVersionSpec (line 68) and expectedPeerRange (line 52) both accept[-+].*prerelease/build suffixes, so the admission predicate is inconsistent with the range-derivation helpers. Low impact: no first-party cohort package currently uses a prerelease version.
🟡 LOW windowAdmits ignores semver prerelease precedence — scripts/lib/packed-package-test.mjs
Two measured divergences. (a)
rangeAdmits('>=0.27.1 <0.28.0', '0.27.1-rc.1')returns true, but0.27.1-rc.1 < 0.27.1in semver, so a prerelease below the floor is admitted. (b)rangeAdmits('>=1.2.3-rc.1 <1.3.0', '1.2.9')returns false because the window regex requires bare digits, yetcurrentMinorPeerRange('1.2.3-rc.1')legitimately emits>=1.2.3-rc.1 <1.3.0— a prerelease floor makes the derived window admit nothing. This is the same prerelease-blindness as the pre-existing caretAdmits, but windowAdmits and cohortRange are new, so the derived-window path is new. No current cohort uses prereleases, so latent. Fix: parse floor/ceiling with full semver precedence (e.g. node-semver) or document the exclusion.
🟡 LOW windowAdmits/caretAdmits ignore prerelease suffixes on the candidate version — scripts/lib/packed-package-test.mjs
The version regex is a prefix match, so '>=0.145.21 <0.146.0' admits '0.145.22-rc.1' where strict semver would refuse a prerelease not annotated on a comparator (verified by execution: true). This mirrors the pre-existing caretAdmits leniency (line 60, unchanged) and the direction is admission-only (it never widens what ships), and the ceiling case '0.146.0-rc.1' is correctly refused. Note-level: if install verification ever needs strict prerelease semantics, both predicates need a prerelease-aware compare; not a defect for current callers.
🟡 LOW Behavior-changed assertPeerMatchesDevelopmentDependency has no unit test — scripts/lib/packed-package-test.test.mjs
This PR changes assertPeerMatchesDevelopmentDependency to derive its expectation via cohortRange (packed-package-test.mjs:133), accepting range dev-dependency specs for the first time (devDep '^1.0.0' now demands peer '^1.0.0' verbatim instead of throwing). No test in this repo covers that function (grep over all *.test.mjs confirms zero references). Add two cases: exact devDep '0.27.1' still yields '>=0.27.1 <0.28.0', and range devDep '^1.0.0' passes when the peer matches.
🟡 LOW Test coverage misses exact peer pins, optionalDependencies, and the new edge cases — scripts/lib/packed-package-test.test.mjs
The 'names every exact first-party pin' test only exercises dependencies; no test asserts an exact first-party peerDependencies pin is refused (sandbox is a range, asserted via not.toContain). No test covers the optionalDependencies section, and none covers prerelease or build-metadata inputs, which is why the three divergences above shipped. All 10 tests pass on PR head (run:
vitest run scripts/lib/packed-package-test.test.mjs).
🟡 LOW Catalog parsing only reads the default top-level 'catalog:' map — scripts/verify-official-optimizers.mjs
parseYaml(...)?.catalog ?? {} silently yields {} if the workspace migrates to named catalogs ('catalogs:' with per-name maps); catalogRange then throws a clear 'no catalog entry' error, so behavior is fail-closed, but the error would be misleading (entry exists, just under a named catalog). Acceptable as-is; a comment or explicit assertion on the parsed shape would make the failure mode obvious.
🟡 LOW rangeAdmits strips prerelease tags, admitting prerelease versions a real package manager would exclude — scripts/verify-official-optimizers.mjs
caretAdmits/windowAdmits match the candidate with /^\d+.\d+.\d+/, dropping prerelease suffixes: verified rangeAdmits('^1.0.0', '1.1.0-rc.1') === true, whereas semver resolution excludes prereleases unless explicitly requested. If a prerelease cohort member is ever published, this gate could pass while npm/pnpm install would resolve a different version. Mitigated today by minimumReleaseAge: 4320 and stable-only catalog entries; low likelihood but worth a guard or a comment. Note the shared helper lives in scripts/lib/packed-package-test.mjs (outside this shot), so fixing there is preferred over local workarounds.
🟡 LOW Dead exact-equality branch in assertExactDependency — scripts/verify-packed-cohort.mjs
if (declared === dependency.version) returnis unreachable for first-party dependencies: buildAndPack now calls assertFirstPartyRangeSpecs on the packed manifest (line 303) before assertCohortPackageContracts runs, and that check throws on any exact first-party pin in dependencies. So declared can never be an exact version equal to the packed version. Harmless redundancy after this PR; remove the branch (and its now-dated comment wording) or keep only the rangeAdmits admission.
🟡 LOW Pre-1.0 caret ranges pass the publish gate but fail the cohort admission check — scripts/verify-packed-cohort.mjs
rangeAdmits(declared, version) = caretAdmits || windowAdmits. caretAdmits returns false for any floorMajor < 1 and windowAdmits only matches the exact '>=X.Y.Z <A.B.C' shape, so a declared '^0.147.0' is ACCEPTED by assertFirstPartyRangeSpecs (isExactVersionSpec false -> it is a valid range) yet REJECTED here with the misleading error 'requires @tangle-network/foo@^0.147.0, packed 0.147.1'. STABILITY.md tells authors to use the window shape below 1.0.0, but neither gate enforces it, so the two checks disagree about whether '^0.x.y' is legal. Fix: have assertFirstPartyRangeSpecs reject '^0.x.y' with a pointer to the window shape (or make caretAdmits handle pre-1.0), so the two gates cannot disagree.
🟡 LOW rangeAdmits ignores prerelease tags, so window ranges admit prerelease packed versions real semver would reject — scripts/verify-packed-cohort.mjs
rangeAdmits (scripts/lib/packed-package-test.mjs:101) parses the packed version with /^\d+.\d+.\d+/, dropping any -prerelease suffix. Verified: rangeAdmits('>=0.145.21 <0.146.0', '0.145.22-rc.1') would admit because the tuple 0.145.22 passes the window, but node-semver's prerelease-exclusion rule rejects it since no comparator shares the (0,145,22) tuple. The swap from caretAdmits newly exposes this to window ranges, which is exactly the shape used for the pre-1.0 first-party cohort (e.g. >=0.145.21 <0.146.0). Impact is low: assertExactDependency is an advisory admission check and the strict packed install with file: overrides plus the single-physical-copy assertion ([lines 402-438](https://github.com/tangle-network/agent-runtime/blob/8dcdb6c75b7ddcbce43a7f8b03db3fc9e7e0021f/scripts/veri
tangletools · 2026-08-17T04:12:54Z · trace
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
❌ 13 Blocking Findings — 8dcdb6c7
Full multi-shot audit completed 8/8 planned shots over 16 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 8/8 planned shots over 16 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 8/8 planned shots over 16 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-17T04:12:54Z · immutable trace
The repo's own admission helpers refuse a 0.x caret, and expectedPeerRange emits the window form below 1.0, so the catalog must state the same shape.
|
|
All 13 blocking findings are against 1. Incomplete catalog conversion (8 of the 13 findings). A merge from main had reverted Checked against the repo's own helper — every range admits its installed version: The gate the findings ran and saw exit 1 now passes on the same package: 2. agent-knowledge 8.0.6 capped agent-eval below 0.147.0 (the unmet-peer findings). Fixed at the source across two releases: 8.0.7 moves the peer to Worth recording: the packed-cohort gate in this PR is what found the agent-knowledge type regression, by typechecking a real consumer against the real packed archives. It fired the moment the cohort ref moved to 8.0.7. |
❌ Needs Work —
|
| opencode GLM 5.2 | opencode DeepSeek v4 Pro | opencode DeepSeek v4 Flash | aggregate | |
|---|---|---|---|---|
| Readiness | 0 | 0 | 0 | 0 |
| Confidence | 95 | 95 | 95 | 95 |
| Correctness | 0 | 0 | 0 | 0 |
| Security | 0 | 0 | 0 | 0 |
| Testing | 0 | 0 | 0 | 0 |
| Architecture | 0 | 0 | 0 | 0 |
Reviewer score is advisory once the run is complete and the verdict has no blockers.
Full multi-shot audit completed 8/8 planned shots over 16 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 8/8 planned shots over 16 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 8/8 planned shots over 16 changed files. Global verifier still owns final merge decision.
Blocking
🟣 CRITICAL Pre-1.0 caret catalog ranges can never admit an installed version; script always throws — scripts/verify-official-optimizers.mjs
assertCohortRange/@agent-eval@^0.147.0 (line 51) and @sandbox@^0.27.1 (line 53), plus assertInstalledAdmitted (lines 161-172), call rangeAdmits, which is caretAdmits(range,version) || windowAdmits(range,version). caretAdmits returns false when floorMajor<1 (packed-package-test.mjs [line 64](https://github.com/tangle-network/agent-runtime/blob/b99075999ad1f2b252c2a850f9e73
🟣 CRITICAL assertCatalogAdmits rejects pre-1.0 caret ranges, script throws at startup — scripts/verify-official-optimizers.mjs
assertCohortRange('@tangle-network/agent-eval', ...) at line 51 calls assertCatalogAdmits, which evaluates rangeAdmits('^0.147.0', '0.147.0'). caretAdmits returns false when floorMajor < 1 (scripts/lib/packed-package-test.mjs), so rangeAdmits('^0.147.0', '0.147.0') === false, and the same holds for sandbox ('^0.27.1') at line 53. Verified by direct execution: rangeAdmits('^0.147.0','0.147.0') => false, rangeAdmits('^0.27.1','0.27.1') => false. The script therefore throws 'installed @tangle-network/agent-eval@0.147.
🟣 CRITICAL assertInstalledAdmitted is passed an exact version, not a range — scripts/verify-official-optimizers.mjs
Lines 161-167 call assertInstalledAdmitted(appDir, name, packedXVersion) with the exact packed version for agent-eval, agent-interface, and sandbox, but the third parameter is documented as a range. rangeAdmits('0.147.0', '0.147.0') is false (caretAdmits requires a '^' prefix; windowAdmits requires '>='), so each call throws 'installed ... is outside its declared range 0.147.0'. Verified: rangeAdmits('0.147.0','0.147.0') => false, rangeAdmits('1.0.0','1.0.0') => false. Only agent-knowledge (line 168) passes
🟣 CRITICAL assertVersion compares an exact packed version to a range specifier — scripts/verify-official-optimizers.mjs
Lines 102-120 changed the expected value from the workspace version to catalogRange(name). packedAgentEvalVersion is the resolved exact devDependency in the packed tarball (e.g. '0.147.0'), while catalogRange returns the specifier ('^0.147.0'); assertVersion uses strict equality (actual !== expected), so every one of the four assertions throws 'must be ^0.147.0, found 0.147.0'. Verified: '0.147.0' === '^0.147.0' => false (likewise interface, knowledge, sandbox). Fix: admit the packed version with rangeAdmits(catalogRange(name), packedVersion), or compare the packed exact version to the catalog's resolved installed version, not its specifier.
🟣 CRITICAL verify:official-optimizers fails deterministically: rangeAdmits never admits the PR's own pre-1.0 caret ranges — scripts/verify-official-optimizers.mjs
Line 51 assertCohortRange('@tangle-network/agent-eval', agentEvalVersion) and line 53 for '@tangle-network/sandbox' call assertCatalogAdmits -> rangeAdmits(catalogRange(name), installed). The PR's catalog declares '^0.147.0' and '^0.27.1'; cohortRange passes caret specs through verbatim, and rangeAdmits returns caretAdmits||windowAdmits where caretAdmits explicitly rejects floorMajor<1 (scripts/lib/packed-package-test.mjs:64) and windowAdmits only matches '>=a.b.c <d.e.f'. Verified empirically with the worktree's r
🔴 HIGH rangeAdmits refuses every caret range on a pre-1.0 package; breaks the official-optimizers gate — scripts/lib/packed-package-test.mjs
rangeAdmits = caretAdmits || windowAdmits. caretAdmits (line 64) returns false whenever floorMajor < 1, and windowAdmits only matches the literal
>=X.Y.Z <X.Y.Zshape. So rangeAdmits('^0.147.0', '0.147.0') === false, although npm semver defines ^0.147.0 as >=0.147.0 <0.148.0 (verified with thesemverpackage: validRange('^0.147.0') -> '>=0.147.0 <0.148.0-0', satisfies('0.147.0') -> true). This PR converts the workspace catalog to caret ranges (pnpm-workspace.yaml: '@tangle-network/agent-eval': ^0.147.0, '@tangle-network/sandbox': ^0.27.1), and verify-official-optimizers.mjs feeds those into rangeAdmits via assertCohortRange/assertCatalogAdmits ([lines
🔴 HIGH rangeAdmits refuses every version for pre-1.0 caret ranges, breaking verify:official-optimizers at head — scripts/lib/packed-package-test.mjs
rangeAdmits = caretAdmits || windowAdmits. caretAdmits (line 64: 'if (floorMajor < 1 || major !== floorMajor) return false') rejects all ^0.x ranges; windowAdmits only matches '>=a.b.c <d.e.f'. Executed against the head module: rangeAdmits('^0.147.0','0.147.0') === false, rangeAdmits('^0.27.1','0.27.1') === false. This PR itself publishes those shapes (package.json peerDependencies '^0.147.0', '^0.27.1'; pnpm-workspace.yaml catalog), and cohortRange (line 85) passes them through as valid cohort ranges. Impact: 'npm run v
🔴 HIGH peer range no longer matches the lib's derived pre-1.0 window — scripts/verify-official-optimizers.mjs
The unchanged loop at lines 83-89 calls assertPeerMatchesDevelopmentDependency, which derives the expected peer range from the packed exact devDependency via cohortRange -> expectedPeerRange. For a pre-1.0 version this yields a window ('>=0.147.0 <0.148.0'), but this PR changed peerDependencies to '^0.147.0' (and sandbox to '^0.27.1'). Verified: '^0.147.0' !== '>=0.147.0 <0.148.0' (and same for sandbox), so even after the three bugs above are fixed, this assertion throws for agent-eval and sandbox. Root cause is shared with the first finding: caret specifiers for pre-1.0 packages contradict the repo's own expectedPeerRange convention.
Other
🟠 MEDIUM Documented command pnpm run check:published-ranges does not exist — docs/STABILITY.md
The doc's actionable enforcement sentence names
pnpm run check:published-ranges, but no npm script with that name exists in root package.json or bench/package.json (grep across repo: only the script file itself, this doc, and bench'sverify:package:staticwhich invokesnode ../scripts/check-published-ranges.mjs bench— restricted to bench, not 'each publishable workspace package'). A contributor copying the doc command at the repo root gets 'Missing script'. Impact: the doc's stated enforcement path is unrunnable as written and overstates the wired coverage. Fix: add"check:published-ranges": "node scripts/check-published-ranges.mjs"to root package.json scripts, or rewrite the sentence to the direct invocation and note root-package enforcement flows through `pnpm run verify:cohort
🟠 MEDIUM Documented enforcement command does not exist — docs/STABILITY.md
pnpm run check:published-rangesis not a script in the root package.json (scripts are listed in full at HEAD; no such entry). The runnerscripts/check-published-ranges.mjswas added by this PR but is wired only asnode ../scripts/check-published-ranges.mjs benchinside bench/package.jsonverify:package:static, reachable via CI's agent-bench job (ci.yml:137 verify:bench). A maintainer pasting the doc's command gets 'Missing script: check:published-ranges', and the root package's own packed ranges are not checked by any CI job (root verify:package at ci.yml:65 omits it). Fix: add"check:published-ranges": "node scripts/check-published-ranges.mjs"to root scripts (and ideally CI), or rewrite the sentence to name the actual invocation.
🟠 MEDIUM False claim that catalog: specifiers pack to an exact version — docs/STABILITY.md
Line 55 states 'A catalog: specifier and a workspace:* specifier are both replaced by an exact version when the package is packed.' Empirically false for catalog: on pnpm 11.17.0 (the repo's packageManager):
pnpm packof the root package replaced@tangle-network/agent-core: catalog:with^0.9.4(the catalog entry's caret range), not0.9.4. The substitution copies the catalog value verbatim, so it is an exact version only when the catalog entry is itself exact — which this PR's catalog no longer is. Only bareworkspace:*packs to an exact version. Impact: the doc's rationale for why the check must read the packed manifest overstates the mechanism; it undermines re
🟠 MEDIUM Root package published ranges are not enforced by any wired command — scripts/check-published-ranges.mjs
The only invocation is bench/package.json:40
node ../scripts/check-published-ranges.mjs bench, which limits directories to repoRoot/bench (resolve(repoRoot,'bench')). The default no-arg path that checks the ROOT package @tangle-network/agent-runtime (the main published artifact, whose peerDependencies the PR itself had to fix from exact/window to caret) is not referenced by package.json:139 verify:package, ci.yml:65, or publish.yml:132. So the guard protects bench only; the root package's first-party range rule is enforced by this script nowhere in CI/publish. Current state passes (root peerDeps are now ranges), but the check will not catch a future regression. Fix: appendnode scripts/check-published-ranges.mjsto root verify:package, or drop the bench arg and let defaults cover both.
🟠 MEDIUM Consumer-installed version check weakened from exact to range-admission — scripts/verify-official-optimizers.mjs
assertInstalledVersion (exact equality, removed) was replaced by assertInstalledAdmitted (lines 304-309), which only checks the consumer-resolved version falls inside the declared range. The consumer package.json declares the packed range (e.g. '^0.147.0') and npm install --prefer-online resolves the latest matching published version, while every earlier verification step (Python wheel agent-eval-rpc==, GEPA bridge, official-packages.test.ts) ran against the exact workspace-installed version. If the registry holds a newer patch within the range, the script passes yet the verified code is not what the consumer installs and runs
🟡 LOW 'The range is stated once, in the catalog: block' is not literally true — docs/STABILITY.md
Peer ranges are stated literally in package.json peerDependencies (
@tangle-network/agent-eval: ^0.147.0,@tangle-network/agent-interface: ^1.0.0,@tangle-network/sandbox: ^0.27.1) — not via catalog — and bench declares@tangle-network/agent-runtime: workspace:^, a range outside any catalog entry. The dependency-range half of the claim is accurate; 'stated once' overgeneralizes to peers and workspace specifiers. Fix: scope the sentence to dependency specifiers, e.g. 'Every first-party dependency specifier is stated once, in the catalog: block; peer ranges are written per-package.'
🟡 LOW Documented command pnpm run check:published-ranges does not exist — docs/STABILITY.md
Line 56 instructs
pnpm run check:published-ranges, butgit grep check:published-ranges <HEAD>returns only this doc line — no npm script by that name exists in package.json, bench/package.json, or any manifest. The actual wiring isbench/package.json#L40(verify:package:static->node ../scripts/check-published-ranges.mjs bench). A maintainer running the documented command gets 'Missing script: check:published-ranges'. Fix: change the line to reference the real invocation, e.g.node scripts/check-published-ranges.mjs(the script auto-discovers workspace packages when run from the root), or add a root-levelcheck:published-rangesscript and reference that.
🟡 LOW Pack-replacement mechanics for catalog: stated backwards — docs/STABILITY.md
Line 55 claims a
catalog:specifier is 'replaced by an exact version when the package is packed'. Disproven by execution in this repo (pnpm 11.17.0): root package.json declares@tangle-network/agent-core: catalog:, the catalog entry is^0.9.4, and the packed manifest carries^0.9.4— the catalog specifier is substituted verbatim, not resolved to an exact version. The claim was true of the pre-PR defect state (catalog held exact pins like0.146.0) but as a durable rule it contradicts the very mechanism this PR relies on: a catalog range must survive packing as a range. Impact: a reader concludes ranges cannot reach the packed manifest via catalog, which is wrong.
🟡 LOW Prescribed pre-1.0 range shape contradicts the repo's own manifests — docs/STABILITY.md
The doc says pre-1.0 ranges must use the window form
>=X.Y.Z <X.Y+1.0, but the repo ships caret for pre-1.0 first-party packages: pnpm-workspace.yaml catalog has@tangle-network/agent-eval: ^0.147.0,@tangle-network/agent-core: ^0.9.4,@tangle-network/sandbox: ^0.27.1, and the packed peerDependencies show^0.147.0/^0.27.1. Caret on a 0.x version is semantically identical to the window (^0.147.0==>=0.147.0 <0.148.0), so this is a shape-vs-semantics inconsistency, and the enforcement lib itself (scripts/lib/packed-package-test.mjscohortRange/expectedPeerRange) accepts the caret form. Impact: a reader following the doc's literal form would write ranges that differ textually from what the package actually publishes. Fix: either align the doc to 'caret below 1.0.0, which
🟡 LOW First-party caret ranges bypass the release-age supply-chain guard on lockfile refresh — pnpm-workspace.yaml
Converting the @tangle-network/* catalog to ranges (^) combined with the pre-existing minimumReleaseAgeExclude for '@tangle-network/' means
pnpm updateor a lockfile regen resolves a freshly published internal patch immediately, with none of the 72h (4320m) age protection applied to third-party packages. Impact: a compromised or bad internal patch release propagates to this repo on the next lockfile refresh with no delay window. Mitigation already present: the committed lockfile pins exact versions until someone refreshes, and the policy is explicitly documented in docs/STABILITY.md. Fix if desired: drop '@tangle-network/' from minimumReleaseAgeExclude, or add a smaller first-party-specific age. Policy-consistent as shipped; not blocking.
🟡 LOW Pre-1.0 catalog entries use caret form while STABILITY.md documents the window shape — pnpm-workspace.yaml
STABILITY.md (added in the same PR) states the pre-1.0 first-party range rule as the window '>=X.Y.Z <X.Y+1.0', but the catalog (and the matching package.json peers) state '^0.147.0' / '^0.9.4' / '^0.16.0' / '^0.27.1' for pre-1.0 packages. Semantically identical — npm/pnpm lock a 0.x caret to its minor, so '^0.147.0' resolves to exactly '>=0.147.0 <0.148.0' — and the head commit's rationale (verbatim string match between packed devDependency and peer) requires the caret form, so this is a docs-vs-implementation shape mismatch, not a behavior bug. Suggest wording STABILITY.md to say a pre-1.0 caret is acceptable because it collapses to the minor window.
🟡 LOW Range entries plus minimumReleaseAge exclusion allow silent drift on non-frozen installs — pnpm-workspace.yaml
Six catalog entries are now ranges, and lines 5-6 exclude '@tangle-network/*' from minimumReleaseAge (72h). Any non-frozen pnpm install (local dev, non-CI) can resolve a newer patch within a window — e.g. agent-eval 0.147.1 — without a lockfile bump, so the locally tested cohort can drift from what verify-packed-cohort verified. Release CI uses --frozen-lockfile and the publish flow packs from the lockfile, so shipped artifacts stay deterministic; this is the pre-existing documented release discipline, but the change widens the drift surface. Not a blocker; a comment in the catalog or STABILITY.md noting 'first-party catalog entries must be bumped by the release bot, n
🟡 LOW Glob workspace entries hard-fail with a misleading message — scripts/check-published-ranges.mjs
Any pnpm-workspace.yaml entry containing '*' throws
entry is not a plain directory. Latent today (the workspace declares only literalbench), but adding a standardpackages/*entry later breaks the no-arg mode of this gate at discovery time rather than degrading to checking what it can. The fail-closed choice is defensible; the message is inaccurate for glob patterns (they are directory patterns, not non-directories). Fix: either expand one-level globs via readdirSync, or reword the error to say wildcard entries are unsupported.
🟡 LOW No direct test for the script; coverage is end-to-end only — scripts/check-published-ranges.mjs
scripts/lib/packed-package-test.test.mjs tests the shared assertion helpers (10/10 pass) but nothing tests check-published-ranges.mjs itself — argument resolution relative to repoRoot, the private-package skip, the archives.length!==1 guard, and the exitCode=1 aggregation are all exercised only via the full CI agent-bench job (which packs a healthy tree and so only ever covers the pass path; the exact-pin rejection path runs nowhere in CI). This review verified both paths manually with synthetic packages. Fix: a node:test that runs the script against fixture package dirs (one exact pin, one clean) asserting exit codes.
🟡 LOW No timeout on pnpm pack / tar child processes — scripts/check-published-ranges.mjs
Both execFileSync calls (pnpm pack line 49, tar line 62) omit
timeout. In CI a hung pnpm pack (network stall, locked store) will hang the verify job indefinitely with no remediation. Recommend adding a timeout (e.g. 120000ms) so the check fails fast and is attributable.
🟡 LOW Pack/tar failures abort the run instead of aggregating — scripts/check-published-ranges.mjs
const manifest = packedManifest(directory)(line 81) executes BEFORE the try/catch at lines 82-88. Ifpnpm packortarthrows (execFileSync non-zero exit, unexpected archive count), the whole loop crashes with an unhandled stack trace and no packages after the failing one are checked, even though assertion failures (lines 85-87) are aggregated and all reported. Inconsistent e
🟡 LOW Summary output omits optionalDependencies that the assertion still enforces — scripts/check-published-ranges.mjs
assertFirstPartyRangeSpecs (in scripts/lib/packed-package-test.mjs:116) checks dependencies, optionalDependencies, and peerDependencies, but the stdout summary at lines 89-92 builds
firstPartyfrom onlymanifest.dependenciesandmanifest.peerDependencies. A first-party exact pin hiding in optionalDependencies would fail the check but print 'no first-party dependencies' (or omit the offending entry) in the diagnostic, making the failure output inconsistent with what actually failed. Cosmetic; no correctness impact. Fix: includemanifest.optionalDependencies ?? {}in the Object.entries spread.
🟡 LOW Workspace wildcard entries brick the default run — scripts/check-published-ranges.mjs
workspacePackageDirectories throws on any entry containing '*', e.g. a future
packages/*glob (pnpm's standard shorthand). Today pnpm-workspace.yaml holds a single literal entry (bench) so this is latent, but the default no-arg mode becomes a hard crash for any repo using globs. The throw fires at startup before any package is checked. Prefer expanding globs (fast-glob or pnpm's own matcher) and skipping non-package dirs.
🟡 LOW execFileSync calls have no timeout — scripts/check-published-ranges.mjs
Neither the
pnpm packcall (line 49) nor thetarcall (line 62) setstimeout. A pack that hangs (e.g., waiting on a prompt or a wedged store) blocks the verify gate indefinitely; CI mitigates with job-level timeouts (agent-bench sets AGENT_BENCH_PACKAGE_TEST_TIMEOUT_MS, ubuntu runners have a 6h default) but the localpnpm run verify:benchpath has no such bound. Fix: addtimeout: 120_000pluskillSignalto both execFileSync options.
🟡 LOW pnpm pack failure escapes the failures[] aggregation with a raw stack trace — scripts/check-published-ranges.mjs
The try/catch at lines 82-88 wraps only assertPublishableDependencySpecs/assertFirstPartyRangeSpecs. packedManifest(directory) on line 81 runs outside it, so any pnpm/tar infrastructure failure throws an uncaught exception that aborts remaining packages and dumps a node stack trace. Reproduced live: a package dir whose manifest carries
catalog:outside the workspace makes pnpm pack fail (ERR_PNPM_CATALOG_ENTRY_NOT_FOUND) and the script dies with a stack instead of the clean per-package failure summary. Exit code is s
🟡 LOW stdout summary omits optionalDependencies that the assertions check — scripts/check-published-ranges.mjs
The printed first-party list merges only dependencies + peerDependencies (lines 89-92) while assertFirstPartyRangeSpecs and assertPublishableDependencySpecs both also scan optionalDependencies. A package whose only first-party tie is an optionalDependency would print 'no first-party dependencies' while still being enforced — misleading log line for the exact defect class the script exists to surface. Fix: spread
...(manifest.optionalDependencies ?? {})into the Object.entries merge.
🟡 LOW Positional integer packing collides for pathological semver components — scripts/lib/packed-package-test.mjs
order() = major1e12 + minor1e6 + patch collides when minor >= 1,000,000 or patch >= 1,000,000 (semver permits arbitrarily large integers, e.g. '1.9999999.0'). Same pattern as pre-existing caretAdmits ('minor*1_000_000 + patch', collides for patch >= 1e6). Unrealistic for this workspace's versions; note only. Component-wise comparison would remove the ceiling.
🟡 LOW cohortRange throws on exact versions with build metadata that isExactVersionSpec accepts — scripts/lib/packed-package-test.mjs
isExactVersionSpec('1.2.3+build') === true (regex allows
+), but cohortRange then calls expectedPeerRange, whose regex /^(\d+).\d+.\d+(?:-.+)?$/ rejects build metadata, so cohortRange('1.2.3+build') throws 'cannot derive peer range from version 1.2.3+build' (reproduced). assertPeerMatchesDevelopmentDependency therefore crashes with an unrelated message if a devDependency ever carries build metadata, and the two functions disagree about what counts as an exact version. Fix: align the regexes (let expectedPeerRange accept [+-]...), or fall back to deriving from the numeric core.
🟡 LOW exactVersion regex accepts +build metadata that expectedPeerRange rejects — scripts/lib/packed-package-test.mjs
exactVersion = /^\d+.\d+.\d+(?:[-+].*)?$/ accepts a trailing +build (e.g. '1.0.0+build'), so isExactVersionSpec('1.0.0+build') returns true and assertFirstPartyRangeSpecs flags it as an exact pin. But expectedPeerRange/currentMinorPeerRange use /^(\d+).\d+.\d+(?:-.+)?$/ which only accepts a '-' prerelease, so cohortRange('1.0.0+build') -> expectedPeerRange('1.0.0+build') throws 'cannot derive peer range from version 1.0.0+build'. Confirmed by direct execution. The two regexes disagree on build metadata: one classifies it as exact, the other cannot derive a cohort from it. Impact is minimal (build metadata in a dependency specifier is essentially never used and is ignored by semver resolution), but if it ever appears in a devDependency, assertPeerMatchesDevelopmentDependency throws an u
🟡 LOW isExactVersionSpec misses =X.Y.Z exact pins, defeating assertFirstPartyRangeSpecs for that shape — scripts/lib/packed-package-test.mjs
The exactVersion regex only matches a bare
X.Y.Z. npm/pnpm accept=1.0.0as an exact pin (verified: semver validRange('=1.0.0') -> '1.0.0'), but isExactVersionSpec('=1.0.0') === false, so assertFirstPartyRangeSpecs silently lets an exact first-party pin written as=0.147.0through — the precise defect (consumer-installed duplicate copy) this gate exists to catch. Confirm by running assertFirstPartyRangeSpecs with dependencies {'@tangle-network/agent-eval':'=0.147.0'}: no throw. Fix: strip a leading '=' before the exact-version test.
🟡 LOW rangeAdmits over-admits prereleases that semver excludes — scripts/lib/packed-package-test.mjs
Both caretAdmits and windowAdmits match only the numeric prefix (/^(\d+).(\d+).(\d+)/) and ignore pre-release identifiers, so rangeAdmits('^1.0.0','1.0.0-rc.1') === true while semver.satisfies('1.0.0-rc.1','^1.0.0') === false (verified). Same for windowAdmits('>=0.27.1 <0.28.0','0.27.2-alpha'). The admission checks used by verify-official-optimizers and verify-packed-cohort would therefore accept an installed prerelease as 'within range'. Not observed in the current cohort (releases only), but the admission predicate should follow semver: a prerelease is excluded unless a comparator carries a prerelease of the same core. Add a prerelease test and cover it in packed-package-test.test.mjs.
🟡 LOW windowAdmits ignores semver prerelease exclusion rules — scripts/lib/packed-package-test.mjs
The version regex /^(\d+).(\d+).(\d+)/ strips prerelease/build suffixes, so '0.145.21-rc.1' (which semver sorts BELOW the floor 0.145.21 and which the range '>=0.145.21 <0.146.0' excludes) is admitted. Permissive direction in a verification-only assert; npm install with --strict-peer-deps upstream remains the real gate, so impact is a check that can pass where npm would refuse. Optional fix: reject versions whose prerelease does not sit on the floor tuple.
🟡 LOW Tests miss the ^0.x caret shape and the assertPeerMatchesDevelopmentDependency passthrough — scripts/lib/packed-package-test.test.mjs
rangeAdmits tests cover ^1 carets and windows but no '^0.x' case — exactly the blind spot that let the high finding ship. Also, the behavior change at packed-package-test.mjs:133 (a range devDependency now requires the peer specifier to equal it verbatim, instead of deriving a window) has no test. Add: rangeAdmits('^0.147.0','0.147.3') === true, rangeAdmits('^0.147.0','0.148.0') === false, and an assertPeerMatchesDevelopmentDependency case where devDependencies carries '^0.147.0' and peerDependencies must match it.
🟡 LOW Consumer-side check loosened from exact-version equality to range admission, allowing untested in-range drift — scripts/verify-official-optimizers.mjs
Previously assertInstalledVersion pinned the consumer-installed agent-eval/interface/sandbox to the exact versions packed from the workspace; now the consumer's package.json depends on the range specs (e.g. '^0.147.0') and npm resolves the newest in-range publish at run time, with only assertInstalledAdmitted verifying membership. If the registry gains a newer in-range patch than the workspace holds, the packed runtime is verified against a combination never tested in-repo (the in-repo vitest run at line 62 uses the workspace versions). This is a deliberate cohort-range tradeoff (acknowledged in the comment at [lines 357-358](https://github.com/tangle-
🟡 LOW assertCohortRange requires literal string equality between peerDependency and catalog spec — scripts/verify-official-optimizers.mjs
assertVersion(packageJson.peerDependencies?.[packageName], catalogRange(packageName), ...) is exact string comparison. Two spellings of the same cohort (e.g. '^1.0.0' vs '>=1.0.0 <2.0.0') would fail despite admitting identical version sets, contradicting the admission-based semantics used everywhere else in this file. It passes today only because package.json and the catalog were changed in lockstep to identical strings. Low impact (verification script, clear error message), but the check is stricter in form than in meaning; comparing via rangeAdmits on both shapes (or normalizing) would be consistent.
🟡 LOW Exact-equality branch in assertExactDependency is now unreachable for first-party deps — scripts/verify-packed-cohort.mjs
Because assertFirstPartyRangeSpecs(packedPackageJson) runs inside every buildAndPack (line 303) before assertCohortPackageContracts, an exact first-party pin in dependencies/peerDependencies already threw during packing. The
declared === dependency.versionearly return therefore can no longer fire for the two pairs this function checks (agentEval->agentInterface, agentRuntime->agentKnowledge). Harmless, but the branch plus the changed comment ('admission rather than equality') suggest an invariant the script now guarantees elsewhere; consider dropping the branch or the misleading equality path. Nit only.
🟡 LOW Prerelease versions at the range boundary are misjudged by the admission regexes — scripts/verify-packed-cohort.mjs
caretAdmits requires exactly ^\d+.\d+.\d+ (lib:59), so a prerelease-carrying floor like ^1.2.3-alpha.1 is never admitted even when the packed version equals the floor, and windowAdmits (lib:89-98) compares only numeric X.Y.Z, so it wrongly rejects a prerelease of the ceiling: windowAdmits('>=0.145.21 <0.146.0','0.146.0-rc.1') returns false though semver admits it (0.146.0-rc.1 < 0.146.0). Verified in node. Impact: an RC/first-release of a cohort package (e.g. publishing agent-interface@0.146.0-rc.1 against the current window) fails the cohort verification even when the declared ranges are semver-correct. Fix: delegate admission to a real semver satisfies() call. Not triggered by the current stable 0.14x/8.0.x cohort, hence low.
🟡 LOW Tilde (or other non-caret/window) first-party range passes the range gate but fails assertExactDependency with a confusing message — scripts/verify-packed-cohort.mjs
assertFirstPartyRangeSpecs (line 303) rejects only EXACT first-party specs (isExactVersionSpec); it accepts any non-exact range, including tilde (~1.5.0). But rangeAdmits (line 609) only understands caret (^X.Y.Z) and window (>=X.Y.Z <X.Y+1.0) shapes. If a first-party runtime dependency were declared as ~1.5.0, the range gate at 303 would pass silently, then assertExactDependency would throw 'owner requires X@~1.5.0, packed 1.5.0' instead of the helpful guidance the assertFirstPartyRangeSpecs error emits ('Declare a range in
🟡 LOW assertExactDependency under-admits 0.x carets; cross-repo coordination required — scripts/verify-packed-cohort.mjs
Executed proof: rangeAdmits('^0.147.0','0.147.3') === false although real semver admits it (caretAdmits requires floorMajor >= 1). If a cohort dependency pair ever declares a 0.x caret, verify:cohort fails even for a valid resolution — arguably intended policy (the PR mandates >=X.Y.Z <X.Y+1.0 below 1.0.0) but the error message won't say the shape is wrong, only 'requires X, packed Y'. Also note this repo's own catalog uses a 0.x caret for @tangle-network/agent-eval (^0.147.0), which is fine only because agent-eval pairs flow through assertSharedContractPeer's string equality, not assertExactDependency. Separately, verify:cohort runs against sibling checkouts (agent-sdk, agent-eval, agent-knowledge); their catalogs must carry matching range specs or CI/publish gates fail — fail-closed, but
🟡 LOW assertFirstPartyRangeSpecs misses '=X.Y.Z' and npm:-alias pins — scripts/verify-packed-cohort.mjs
Executed proof: assertFirstPartyRangeSpecs({peerDependencies:{'@tangle-network/sandbox':'=0.27.1'}}) passes, while the bare '0.27.1' form is flagged. isExactVersionSpec's regex requires the version at string start, so '=0.27.1' and 'npm:@scope/pkg@1.2.3' escape the exact-pin lint. For cohort members the escape is closed (assertExactDependency's rangeAdmits and assertPeerMatchesDevelopmentDependency's string equality both fail on those forms), but a first-party non-cohort peer could publish a pin past this gate. Fix: strip a leading '=' in isExactVersionSpec and reject 'npm:' aliases in assertPublishableDependencySpecs.
🟡 LOW rangeAdmits ignores prerelease semver rules (over-admits) — scripts/verify-packed-cohort.mjs
Executed proof: rangeAdmits('^8.0.7','8.1.0-beta.1') === true, but real semver excludes 8.1.0-beta.1 from ^8.0.7 (prerelease only admitted on a matching comparator tuple). Because the cohort install forces file: overrides (lines 208-231, 376-382), the real resolver never judges the declared range — this static check is the only range-semantics gate, so a prerelease cohort version could be declared admitted where a real consumer's registry resolution would pick a different version. Impact today is nil (cohort ships stable versions). Fix: reject versions with a prerelease suffix in caretAdmits/windowAdmits unless the range carries a prerelease on the sam
🟡 LOW rangeAdmits whitelists only caret and >=floor <ceiling shapes; other valid ranges fail with a confusing error — scripts/verify-packed-cohort.mjs
The new admission gate (rangeAdmits -> caretAdmits || windowAdmits, lib lines 58-103) accepts only ^X.Y.Z and >=X.Y.Z <A.B.C. A first-party dependency declared as ~1.2.3, >=1.0.0 (bare floor), or 1.2.x is treated as 'not exact' by assertFirstPartyRangeSpecs (lib:112-129, invoked at line 303) and passes the publish gate, then throws here as 'requires X@~1.2.3, packed 1.2.3' even though the range admits the packed version. Verified: rangeAdmits('1.2','1.2.0') and rangeAdmits('>=1.0.0','1.5.0') both return false. The two ga
tangletools · 2026-08-17T04:24:37Z · trace
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
❌ 8 Blocking Findings — b9907599
Full multi-shot audit completed 8/8 planned shots over 16 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 8/8 planned shots over 16 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 8/8 planned shots over 16 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-17T04:24:37Z · immutable trace
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
🟡 Value Audit — sound-with-nits
| Verdict | sound-with-nits |
| Coverage | 2 of 2 lenses (value, usefulness) |
| Concerns | 2 (2 weak-concern) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 169.1s (2 bridge agents) |
| Total | 169.1s |
💰 Value — sound-with-nits
Converts every published @tangle-network/* specifier from an exact pin to a cohort range (stated once in the pnpm catalog) and adds a pack-time guard that reads the real tarball, so consumers holding later cohort members stop getting duplicate package copies — well built in the repo's existing verif
- What it does: pnpm replaces
catalog:andworkspace:*specifiers with exact versions at pack time, so the previously published manifests (e.g. agent-bench 0.8.12) carried exact first-party pins. This change (1) rewrites the first-party catalog entries in pnpm-workspace.yaml:21-28 as ranges in the repo's established doctrine — caret from 1.0.0 (^1.0.0,^8.0.8),>=X.Y.Z <X.Y+1.0windows below 1.0 — and c - Goals it achieves: Prevent duplicate physical installs of first-party packages: an exact pin forces a consumer already holding a later cohort member to install a second copy, which breaks
instanceofacross the seam (two class identities). Secondary goals achieved: the compatibility statement now matches the fleet's own range doctrine (the same shape expectedPeerRange already enforced for peers); the range is state - Assessment: Good change, coherently executed. The root-cause fix is correct and minimal: pnpm's pack-time substitution means only catalog-entry shape and
workspace:^can produce ranges, and the floors semantics follow the depended-on package's versioning rather than a blanket caret. It extends the pre-existing doctrine in scripts/lib/packed-package-test.mjs (expectedPeerRange/caretAdmits existed on main; re - Better / existing approach: none — this is the right approach. Searched for existing equivalents: publint/attw (wired into the same verify:package:static) check exports/publish lint, not dependency policy; no semver utility dependency exists in package.json; on main, scripts/lib/packed-package-test.mjs had no first-party-range check (verified via git show origin/main). The alternative —
workspace:^specifiers everywhere in - Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 2
- Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error
🎯 Usefulness — sound
Converts published first-party specs from exact pins to ranges at the correct single-source layer (the pnpm catalog plus workspace:^), and adds a pack-time exact-pin guard wired into three existing verification pipelines that CI and the release workflow already run.
- Integration: Fully reachable. The new
scripts/check-published-ranges.mjsis invoked from bench'sverify:package:static(bench/package.json:40), which rootverify:bench/verify:bench:publishedcall (package.json:136-137) and CI/release run (ci.yml:137, publish.yml:174, 303).assertFirstPartyRangeSpecsis also applied to every packed cohort package inverify-packed-cohort.mjs:303, run at ci.yml:108 an - Fit with existing patterns: Follows the codebase's established pack-and-assert pattern exactly: the new script shares
scripts/lib/packed-package-test.mjswithverify-packed-cohort.mjsandverify-official-optimizers.mjs, andverify-official-optimizers.mjs:46-53was refactored from 'peer == expectedPeerRange(installed version)' to 'peer == catalog range AND catalog admits installed' — consolidating the catalog in pnpm- - Real-world viability: Holds up on real paths: it packs the real archive and reads the packed manifest (never source), skips pack scripts via
npm_config_ignore_scripts, cleans its temp dir infinally, andassertPublishableDependencySpecs(check-published-ranges.mjs:83) still guards againstworkspace:/catalog:leaking into a packed manifest.verify-packed-cohort.mjs:416-437already proves the end-to-end prope - Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 1
🎯 Usefulness Audit
🟡 rangeAdmits refuses the ^0.x shape this PR itself publishes [robustness] ``
packed-package-test.mjs:64 makes caretAdmits return false whenever the floor major is < 1, and windowAdmits only parses
>=a <bwindows, so rangeAdmits('^0.140.0', '0.140.1') is false. Meanwhile bench's packed manifest now carries agent-runtime as^0.140.0via workspace:^ (bench/package.json dependency, confirmed by the PR's own tarball proof). Nothing breaks today — check-published-ranges only tests for exact pins, and the cohort/optimizer checks feed rangeAdmits only 1.0+ carets (^1.0.0, ^8
💰 Value Audit
🟡 STABILITY.md names a script alias that does not exist [maintenance] ``
docs/STABILITY.md:56 tells maintainers to run
pnpm run check:published-ranges, but no such script alias exists — grep across package.json/bench/package.json finds the check invoked only asnode ../scripts/check-published-ranges.mjs benchinside bench/package.json:40 (verify:package:static), with root-package coverage coming indirectly via verify-packed-cohort.mjs:303. Add acheck:published-rangesentry to the root package.json scripts block (next to check:publish-workflow at package.json:1
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.
A packed catalog specifier is a range below 1.0, so the installed copy is proven by admission; only an exact specifier names one version to match.
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
🟡 Value Audit — sound-with-nits
| Verdict | sound-with-nits |
| Coverage | 2 of 2 lenses (value, usefulness) |
| Concerns | 3 (3 weak-concern) |
| Heuristic | 0.0s |
| Duplication | 0.1s |
| Interrogation | 158.1s (2 bridge agents) |
| Total | 158.2s |
💰 Value — sound-with-nits
Converts first-party catalog entries from exact pins to cohort ranges so packed tarballs stop forcing duplicate package copies on consumers, and adds a pack-and-inspect gate to keep it true — correct root-cause fix in the codebase's grain, with two wiring nits.
- What it does: Three coordinated moves. (1) pnpm-workspace.yaml:18-28 changes every first-party catalog entry from an exact version (agent-eval 0.147.0, knowledge 8.0.8, agent-core, sandbox, profile-materialize) to the cohort range shape the repo's expectedPeerRange doctrine already defines — caret from 1.0.0, '>=X.Y.Z <X.Y+1.0' below it. Because pnpm replaces 'catalog:' with the catalog specifier verbatim at pa
- Goals it achieves: Published tarballs stop naming one exact first-party version. An exact pin forces any consumer already holding a later cohort member to install a second physical copy — two class identities, two module registries, instanceof false across the seam. agent-bench@0.8.12 shipped five such pins (confirmed: origin/main catalog held exact 0.146.0/1.0.0/8.0.6/0.27.1 and bench declared workspace:*). The cha
- Assessment: Good on its merits. It fixes the root cause — the catalog IS the source of the packed specifier, so stating the range there is the native pnpm mechanism, versus alternatives like publish-time substitution or overrides that would fight the tooling. The range shapes deliberately mirror expectedPeerRange (packed-package-test.mjs:51-55), so one rule now governs both peer ranges and dependency ranges i
- Better / existing approach: none — this is the right approach. Searched for an existing mechanism that already enforced this: assertPublishableDependencySpecs (packed-package-test.mjs:3-15) catches protocol leakage but not exact pins, so the new assertion is a genuine extension, not a reinvention; verify-packed-cohort proves single-copy but requires four clean sibling checkouts (ci.yml:95-112), too heavy to be the only guard
- Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 2
- Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error
🎯 Usefulness — sound-with-nits
A verified-on-the-packed-tarball fix that converts exact first-party pins into cohort ranges, plus a CI/publish gate that packs every publishable package and refuses exact pins — wired into the existing verify-script family and consistent with its consumers.
- Integration: Fully reachable on the paths that matter. (1) The new gate
scripts/check-published-ranges.mjsis appended to bench'sverify:package:static(bench/package.json:40), reached by rootverify:bench/verify:bench:published(package.json:136-137), which CI and publish run (.github/workflows/ci.yml:137; publish.yml:174, 303). (2)assertFirstPartyRangeSpecsis also enforced on every packed cohort - Fit with existing patterns: Follows the codebase's established pattern exactly: the repo already gates publishability by packing and reading the tarball manifest via the shared lib (
assertPublishableDependencySpecs, scripts/lib/packed-package-test.mjs:3-15), and the caret-vs-window cohort doctrine already existed asexpectedPeerRange(packed-package-test.mjs:51-55). The new assertion closes the adjacent hole in that same - Real-world viability: Holds up beyond the happy path, with evidence: I installed the workspace and ran the real gate — both publishable packages pack cleanly with ranges; the regression path was tested by mutating a catalog entry to an exact version, producing a precise failure and exit 1;
pnpm exec vitest run scripts/lib/packed-package-test.test.mjspasses 10/10. The script packs with `npm_config_ignore_scripts: tru - Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 1
💰 Value Audit
🟡 New gate wired only into bench; root's verify:package skips it [better-architecture] ``
check-published-ranges.mjs is invoked only from bench's verify:package:static (bench/package.json:40). Root's verify:package (package.json:139) does not run it, yet root publishes four first-party 'catalog:' dependencies (package.json:182-187) that the same defect class hits — root was carrying exact pins for agent-core, agent-knowledge, and agent-profile-materialize before this change too. Root is still protected by the heavier cohort gate (verify-packed-cohort.mjs:303 calls assertFirstPartyRan
🟡 Pack-and-read-manifest snippet duplicated in two scripts [duplication] ``
check-published-ranges.mjs:51-74 (packedManifest: mkdtemp, pnpm pack, tar -xOzf package/package.json, rm) substantially repeats the inline pack/unpack flow in verify-package-exports.mjs:52-67. Both drain into the same shared lib but each re-implements the tarball-extraction mechanics. A packedManifest(packageDirectory) helper in scripts/lib/packed-package-test.mjs would keep the two in step (e.g., the 'exactly one archive' rule is asserted independently in both). ~20 lines; cosmetic, does not ga
🎯 Usefulness Audit
🟡 ? [robustness] ``
bench declares
workspace:^on the pre-1.0 agent-runtime (bench/package.json), which packs as^0.140.0(confirmed by my live run). But the repo's own admission helper refuses that shape:caretAdmitsrequires floorMajor >= 1 (scripts/lib/packed-package-test.mjs:64), and the PR's own doctrine is 'a caret from 1.0.0, a window below it' — every other pre-1.0 catalog entry in pnpm-workspace.yaml is a>=X <X+1window. npm semver treats^0.140.0as>=0.140.0 <0.141.0, so the published range
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.
|
Merging with All four checks pass on Every one of those 13 findings is answered above with running proof — Delta I reviewed since that stale review ( Local proof on the merged head: |
2 participants
The defect
The published manifest of
@tangle-network/agent-bench@0.8.12names five exact first-party versions:{ "@tangle-network/agent-eval": "0.145.21", "@tangle-network/agent-interface": "1.0.0", "@tangle-network/agent-knowledge": "8.0.5", "@tangle-network/sandbox": "0.27.1", "@tangle-network/agent-runtime": "0.137.0" }An exact pin is not a compatibility statement. It names one version and refuses every other, so a consumer that already holds a later cohort member installs a second physical copy of the pinned package.
agent-evalis at 0.146.0 andagent-runtimeat 0.138.0 today, so two of those five duplicate right now.agent-interfaceescapes only by coincidence:1.0.0and the fleet's^1.0.0happen to resolve to the same version, and interface 1.0.1 reopens it.Caret semantics do not fix an exact pin. The 1.0 cuts do not fix it either.
The mechanism
Nobody wrote those pins. A
catalog:specifier and aworkspace:*specifier are both replaced by an exact version when the package is packed, so the source manifest looks clean and only the packed manifest carries the defect.pnpm-workspace.yamlnow states a range per first-party catalog entry, in the shape the depended-on package's own versioning earns — the same ruleexpectedPeerRangeapplies to a peer range: a caret from 1.0.0, the narrower>=X.Y.Z <X.Y+1.0window below it.benchdeclaresagent-runtimeasworkspace:^, notworkspace:*.The floors do not move in this change. Only the shape does.
Proof, on the packed tarball
The guard
scripts/check-published-ranges.mjspacks every publishable workspace package, reads the archive manifest, and fails when a first-party specifier names one version instead of a range. It runs inside the existingverify:package(root) andverify:package:static(bench) scripts — no new CI.Negative test, by reverting one catalog entry to
8.0.5:scripts/verify-packed-cohort.mjsasserts the same rule on every cohort archive it packs.Checks that had to move with it
A range lets the installed version float above the catalog floor, so two checks that compared a peer range against the installed version now compare it against the catalog range and assert the installed version is admitted:
verify-official-optimizers.mjs, andassertPeerMatchesDevelopmentDependencythrough the newcohortRange.assertExactDependencyadmits both range shapes through the newrangeAdmits.Verification
pnpm typecheckexit 0pnpm exec vitest run scripts/lib/packed-package-test.test.mjs— 10 tests passed, 0 failednode scripts/check-published-ranges.mjsexit 0; exit 1 on the reverted entry abovenode scripts/check-version-bump.mjsexit 0 —bench0.8.12 -> 0.8.13 pays for 5 consumer-visible changes, root 0.138.0 -> 0.138.1 pays for 3pnpm install --frozen-lockfileexit 0; the lockfile moves 7 specifier lines and no resolved versionWhat this does NOT fix
Below 1.0 a range still stops at the next minor, so
agent-evalat>=0.145.21 <0.146.0does not admit the published 0.146.0 — that copy survives until the cohort floor moves or agent-eval cuts 1.0.0. Raising that floor is a separate change and belongs to the lane cutting agent-eval 1.0.0.