chore(release): 0.135.4 — accept the agent-interface 0.54 generation and move the sibling floors with it

[drewstone]

Problem

agent-interface publishes minors faster than the fleet can adopt them, and each one takes the npm latest tag on arrival.

time (UTC)	event
04:28:43Z	agent-runtime#873 merged, widening this peer to >=0.53.0 <0.54.0.
04:30:11Z	agent-interface@0.54.0 published — 88 seconds later — taking latest.
04:30:16Z	agent-core@0.9.1 published, dep interface 0.54.0.
06:09:50Z	agent-eval@0.145.16 published, dep interface 0.54.0.
06:19:28Z	agent-knowledge@8.0.2 published, peer interface >=0.54.0 <0.55.0.
06:44:30Z	agent-interface@0.55.0 published — 2h 14m after 0.54.0 — taking latest in turn.

Because 0.135.3 and agent-knowledge 8.0.2 landed on adjacent single-generation windows, their ranges are disjoint. The break is therefore not an @latest problem on the interface — it holds when the interface is never named:

$ npm install --dry-run @tangle-network/agent-runtime@latest @tangle-network/agent-knowledge@latest
npm error   peer @tangle-network/agent-interface@">=0.54.0 <0.55.0" from @tangle-network/agent-knowledge@8.0.2
npm error   @tangle-network/agent-interface@"0.54.0" from @tangle-network/agent-eval@0.145.16
npm error Could not resolve dependency:
npm error @tangle-network/agent-runtime@"0.135.3" from the root project
npm error Conflicting peer dependency: @tangle-network/agent-interface@0.53.0
npm error   peer @tangle-network/agent-interface@">=0.53.0 <0.54.0" from @tangle-network/agent-runtime@0.135.3

Change — release 0.135.4

field	before	after
version	0.135.3	0.135.4
bench version	0.8.11	0.8.12
peer agent-interface	>=0.53.0 <0.54.0	>=0.53.0 <0.56.0
peer agent-eval	>=0.145.15 <0.146.0	>=0.145.16 <0.146.0
catalog agent-interface	0.53.0	0.55.0
catalog agent-eval	0.145.15	0.145.16
catalog agent-knowledge	8.0.1	8.0.2
catalog agent-core	0.9.0	0.9.1
catalog agent-profile-materialize	0.15.1	0.15.2

The peer holds three generations, not the newest one alone. A consumer carrying a package capped below 0.54 resolves against interface 0.53; one carrying agent-knowledge 8.0.2 resolves against 0.54; one carrying agent-core 0.9.2 resolves against 0.55. A single-generation window makes every adoption wave atomic, and at a 2h14m publish cadence a 5-repository wave cannot be atomic. That is the condition that produced this break, so the window is what changes.

The agent-eval floor moves in the SAME commit. agent-knowledge 8.0.2 requires agent-eval >=0.145.16, and 0.145.16 is the release that depends on interface 0.54.0. A floor that moves generation alone leaves the same disjoint pair one level down.

agent-core stays at 0.9.1 rather than 0.9.2, because agent-eval 0.145.16 pins 0.9.1 and a consumer install should hold one copy.

Evidence that both generations are additive

Published tarballs, exported-symbol lists diffed per changed .d.ts.

0.53.0 → 0.54.0 — identical file lists, four dist/*.d.ts changed:

• Added isCredentialBearingProfileConfigName (profile-schema), isRuntimeProcessControlEnvironmentName (profile-security).
• Widened RequestedInteractions from {permission?, question?, plan?} to Readonly<Record<string, boolean | undefined>>, and RequestedInteractionsSchema from a strict ZodObject to a ZodRecord. Every old value stays assignable.
• Removed nothing.

RequestedInteractions entered the package in 0.53.0, one day earlier, and is read by zero files in agent-runtime, agent-knowledge, agent-app, agent-eval, sandbox-ui.

0.54.0 → 0.55.0 — one file added:

• Added file dist/environment-interactive.{d.ts,js}.
• Added optional startInteractive? and interactive? on AgentEnvironment; optional interactiveAgent? capability block on AgentEnvironmentCapabilities; AgentInteractiveSession* schemas and helpers re-exported from index.
• Removed nothing. The remaining diff lines are enum key order in generated declarations.

Proof, on this head, against interface 0.55.0

• pnpm install: resolves interface 0.55.0, agent-eval 0.145.16, agent-knowledge 8.0.2, agent-core 0.9.1, agent-profile-materialize 0.15.2.
• pnpm typecheck (tsc --noEmit plus the examples project): exit 0.
• pnpm test: Test Files 216 passed | 2 skipped (218), Tests 2714 passed | 6 skipped (2720).
• node scripts/check-version-bump.mjs: Consumer-visible package surfaces carry their version bumps — bench/package.json: 3 consumer-visible change(s), paid for by 0.8.11 -> 0.8.12, package.json: 5 consumer-visible change(s), paid for by 0.135.3 -> 0.135.4.
• pnpm run check:testing-fixture: agent improvement proposal fixtures are current.
• pnpm run docs:check: docs freshness: OK — no drift detected in the curated docs.

Rest of the wave

• chore(release): 8.0.3 — widen the Interface peer to <0.56.0 and verify against 0.55.0 agent-knowledge#135 — 8.0.3, peer >=0.54.0 <0.56.0. This is what unblocks a plain agent-interface@latest install.
• chore(deps): declare the agent-interface peer as a caret range sandbox-ui#254 — peer >=0.36.0 <0.56.0.
• tangle-network/agent-dev-container#5742 — agent-profile-materialize peer >=0.47.0 <0.56.0. It was the one unmet peer pnpm peers check reported here.
• chore(deps): adopt interface 0.53 lockstep with runtime 0.135.3 and sandbox 0.27.0 agent-app#444 — merged 06:45:13Z, moving the shell off the 0.47 line onto 0.53. Its follow-up onto this window waits on 0.135.4 publishing.

Root causes filed

• release(agent-interface): a new minor takes the npm 'latest' tag on arrival and breaks every consumer until the adoption wave finishes agent-sdk#190 — publish under a next tag, promote to latest only after N first-party consumers accept the version. Removes the race instead of buying time.
• peer-floors: add a sibling-coherence check — a floor that moves generation without its siblings publishes an unresolvable manifest agent-app#445 — a manifest gate that fails when one peer floor moves generation without its siblings.

Refs agent-runtime#694.

[tangletools]

✅ Auto-approved drewstone PR — 38ef766f

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-16T06:35:08Z}

[drewstone]

@tangletools review now

[tangletools]

✅ Auto-approved drewstone PR — 38ef766f

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-16T06:45:27Z}

[drewstone]

Head moved to e1f6bab4: this now carries the 0.135.4 release commit (root 0.135.3 -> 0.135.4, bench 0.8.11 -> 0.8.12), the CHANGELOG entry, and the docs/canonical-api.md peer-pin update the freshness gate requires.

Local gates on the pushed head:

• node scripts/check-version-bump.mjs: Consumer-visible package surfaces carry their version bumps — bench/package.json: 3 consumer-visible change(s), paid for by 0.8.11 -> 0.8.12, package.json: 5 consumer-visible change(s), paid for by 0.135.3 -> 0.135.4.
• pnpm run check:testing-fixture: agent improvement proposal fixtures are current.
• pnpm run docs:check: docs freshness: OK — no drift detected in the curated docs.
• pnpm typecheck: exit 0.
• pnpm test: Test Files 216 passed | 2 skipped (218), Tests 2714 passed | 6 skipped (2720).

@tangletools review now

[tangletools]

✅ Auto-approved drewstone PR — ebb1b976

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-16T07:00:01Z}

[drewstone]

@tangletools review now

[tangletools]

✅ Auto-approved drewstone PR — ebb1b976

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-16T07:00:13Z}

[drewstone]

Head is now ebb1b976. The target moved while this PR was open, which is the finding itself.

agent-interface 0.55.0 published 2026-08-16T06:44:30Z — 2 hours 14 minutes after 0.54.0 — and took latest in turn. A <0.55.0 ceiling would have shipped already behind the tag it exists to track. Measured cadence: 0.53 → 0.54 = 20h26m, 0.54 → 0.55 = 2h14m.

So the peer is >=0.53.0 <0.56.0 — three generations, each verified here, not the newest one alone.

0.55.0 is additive over 0.54.0: it adds dist/environment-interactive.{d.ts,js}, the optional startInteractive? and interactive? methods on AgentEnvironment, and the optional interactiveAgent? capability block. Diffing the exported-symbol list of every changed .d.ts yields zero removals; the remaining diff lines are enum key order in generated declarations.

Re-verified on this head against interface 0.55.0:

• pnpm typecheck: exit 0.
• pnpm test: Test Files 216 passed | 2 skipped (218), Tests 2714 passed | 6 skipped (2720).
• node scripts/check-version-bump.mjs: package.json: 5 consumer-visible change(s), paid for by 0.135.3 -> 0.135.4, bench/package.json: 3 consumer-visible change(s), paid for by 0.8.11 -> 0.8.12.
• pnpm run docs:check: docs freshness: OK — no drift detected in the curated docs.

Sibling PRs move to the same <0.56.0 ceiling: sandbox-ui#254, agent-dev-container#5742, agent-knowledge#135 (8.0.3, which is what unblocks a plain interface@latest install).

Root cause and the release-order rule: tangle-network/agent-sdk#190. Manifest gate for the sibling-floor half: tangle-network/agent-app#445.

[tangletools]

⚠️ Value Audit did not run — no verdict

This is not an approval and not a clean bill of health. Neither interrogation lens returned a judgment, so this PR has no value-audit evidence for or against it.

Status	audit-incomplete (could not run)
Why	value: cli-bridge admission rejected (queue saturated); usefulness: cli-bridge admission rejected (queue saturated)
Lenses answered	0 of 2
What to do	re-run once the CLI bridge has capacity: pr-reviewerctl trigger <repo>#<pr> --force

💰 Value — error

value agent never ran: the CLI bridge refused admission (no model was started).

• Model: opencode/deepseek/deepseek-v4-pro
• Bridge attempts: 4
• Bridge error: opencode/kimi-for-coding/k2p7: Bridge returned 503: bridge at capacity (queue_timeout, lane=reserved): active=20/20 queued=5/48 — no model was started

🎯 Usefulness — error

usefulness agent never ran: the CLI bridge refused admission (no model was started).

• Model: opencode/deepseek/deepseek-v4-pro
• Bridge attempts: 4
• Bridge error: opencode/zai-coding-plan/glm-5.2: Bridge returned 503: bridge at capacity (queue_timeout, lane=reserved): active=20/20 queued=6/48 — no model was started

No concerns are listed because nothing examined the change — absence of findings here is absence of evidence, not a pass.

---

What this audit checks

It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.

Pass	What it asks
Heuristic	Vague title? Whitespace-only or cruft-bearing diff? (content signals only)
Duplication	Do added function/class names already exist elsewhere in the repo?
Value Audit	What does it do? What goal does it achieve? Is it good? Better architecture or already-exists?
Usefulness Audit	Does it integrate and fit? Will it hold up in real use and actually get used?

Findings are concerns, not blocks — the human reviewer decides what to do with them.

_{value-audit · 20260816T071531Z}

Value audit could not run (value: cli-bridge admission rejected (queue saturated); usefulness: cli-bridge admission rejected (queue saturated)). This approval was provisional on that audit running, so it is dismissed. Re-run the reviewer once the CLI bridge has capacity.

[drewstone]

Positive control — the wave resolves, proven before merge

The final proof normally waits on merge → publish. It does not have to: npm's resolver reads only manifests, so packing these branches and installing the tarballs beside the live registry is the same resolution the published packages will produce.

agent-runtime's catalog: specifiers were resolved from pnpm-workspace.yaml exactly as pnpm publish does (agent-core 0.9.1, agent-knowledge 8.0.2, agent-profile-materialize 0.15.2, agent-trace-contract ^1.0.2) and devDependencies dropped, since a consumer never installs them.

Negative control — the published state, right now

$ npm install --dry-run @tangle-network/agent-runtime@latest \
    @tangle-network/agent-knowledge@latest \
    @tangle-network/agent-eval@latest \
    @tangle-network/agent-interface@latest
npm error code ERESOLVE
npm error ERESOLVE unable to resolve dependency tree
npm error     peer @tangle-network/agent-eval@">=0.145.16 <0.146.0" from @tangle-network/agent-knowledge@8.0.2
npm error Could not resolve dependency:
npm error peer @tangle-network/agent-interface@">=0.54.0 <0.55.0" from @tangle-network/agent-knowledge@8.0.2
  EXIT=1

Positive control — the same command against these branches

$ npm install --dry-run ./agent-runtime-0.135.4-resolved.tgz \
    ./tangle-network-agent-knowledge-8.0.3.tgz \
    @tangle-network/agent-eval@latest \
    @tangle-network/agent-interface@latest
add @tangle-network/agent-runtime 0.135.4
add @tangle-network/agent-knowledge 8.0.3
add @tangle-network/agent-interface 0.55.0
add @tangle-network/agent-eval 0.145.17
add @tangle-network/agent-core 0.9.2
add @tangle-network/agent-profile-materialize 0.15.2
add @tangle-network/agent-knowledge 8.0.2
add @tangle-network/agent-core 0.9.1
add @tangle-network/agent-interface 0.54.0

added 48 packages in 6s
  EXIT=0

Zero ERESOLVE. Interface 0.55.0 hoists to the root and satisfies both new peer windows. The nested 0.54.0 and agent-core 0.9.1 are exact dependencies of transitively pulled older releases — npm nests those rather than failing, so they never block an install.

Same command shape, same live registry, same day. Only the two manifests differ.

One more generation landed during this run

@tangle-network/agent-eval@0.145.17 published while the proof was being built, depending on agent-interface 0.55.0 and agent-core 0.9.2. That is the fourth first-party package to adopt 0.55 inside three hours, and the <0.56.0 window in these branches admits it with no further change — which is the point of widening the window instead of tracking the newest generation alone.

Root cause and the release-order rule: tangle-network/agent-sdk#190. Manifest gate for the sibling-floor half: tangle-network/agent-app#445.

[drewstone]

Re-verified against the manifest that actually merged

agent-knowledge 8.0.3 landed on its main via tangle-network/agent-knowledge#136 at 07:13:44Z, and my parallel tangle-network/agent-knowledge#135 was closed as superseded. The merged version declares a narrower window than #135 proposed:

	tangle-network/agent-knowledge#135 (closed)	#136 (merged)
peer agent-interface	>=0.54.0 <0.56.0	>=0.55.0 <0.56.0
peer agent-eval	>=0.145.16 <0.146.0	>=0.145.17 <0.146.0

So the proof above was re-run against the real merged manifest, packed straight from origin/main, rather than my closed branch:

$ npm install --dry-run ./agent-runtime-0.135.4-resolved.tgz ./knowledge-8.0.3-main.tgz \
    @tangle-network/agent-eval@latest @tangle-network/agent-interface@latest
add @tangle-network/agent-runtime 0.135.4
add @tangle-network/agent-knowledge 8.0.3
add @tangle-network/agent-interface 0.55.0
add @tangle-network/agent-eval 0.145.17
added 48 packages in 1s
  EXIT=0

Zero ERESOLVE. This PR's >=0.53.0 <0.56.0 intersects the merged >=0.55.0 <0.56.0 at 0.55.x, so the pair resolves.

What the narrower window costs, stated plainly

agent-knowledge 8.0.3 raised its FLOOR to >=0.55.0, so it is now disjoint from agent-app 0.45.61, which published at 06:45Z declaring >=0.53.0 <0.54.0:

agent-knowledge 8.0.3 : >=0.55.0 <0.56.0
agent-app      0.45.61: >=0.53.0 <0.54.0     ← no overlap

That is the same failure this PR exists to fix, one repository over, created inside the same hour. It is not an argument against #136 — it is the argument in tangle-network/agent-sdk#190 and tangle-network/agent-app#445, restated by the fleet a third time in one morning. This PR keeps the floor at 0.53 for exactly that reason: a wide window costs nothing and a narrow one costs a wave.

agent-app is the remaining laggard and needs >=0.53.0 <0.56.0. That follow-up is gated on 0.135.4 publishing, since agent-app pins agent-runtime as a devDependency.

[tangletools]

🟡 Value Audit — sound-with-nits

Verdict	sound-with-nits
Coverage	2 of 2 lenses (value, usefulness)
Concerns	4 (4 weak-concern)
Heuristic	0.0s
Duplication	0.0s
Interrogation	454.4s (2 bridge agents)
Total	454.4s

💰 Value — sound-with-nits

Patch release 0.135.4 that widens the agent-interface peer window to three generations (>=0.53.0 <0.56.0) and moves sibling floors (eval >=0.145.16, catalog knowledge/core/materialize) to un-break npm resolution of agent-runtime@latest alongside agent-knowledge@latest — a coherent, well-evidenced fi

• What it does: Four commits on top of 0.135.3: (1) 38ef766 widens the interface peer from >=0.53.0 <0.54.0 to <0.55.0 and moves the catalog (interface 0.54.0, eval 0.145.16, knowledge 8.0.2, core 0.9.1, profile-materialize 0.15.2); (2) e3edf2e cuts release 0.135.4 — version bumps in package.json:3 and bench/package.json, CHANGELOG entry, regenerated version-embedding fixtures via the repo's own generator (packag
• Goals it achieves: Restore installability: 0.135.3's single-generation window (>=0.53.0 <0.54.0) and agent-knowledge 8.0.2's peer (>=0.54.0 <0.55.0) are disjoint, so 'npm install agent-runtime@latest agent-knowledge@latest' fails regardless of the interface's own latest tag (reproduced in the PR body). The eval floor moves in the same release because knowledge 8.0.2 requires eval >=0.145.16 — fixing only the interfa
• Assessment: Good change, executed in the grain of the codebase. The file set exactly matches prior releases (9e6d7c9/#873, 1502fe5/#871: package.json, bench, catalog, lockfile, fixtures, CHANGELOG). The version bump satisfies the repo's own gate requiring peer-surface changes to raise the version (scripts/check-version-bump.mjs, header comment). Fixtures were regenerated with the documented script and are cov
• Better / existing approach: Searched the repo for an existing mechanism: scripts/ has check-version-bump.mjs, prepare-release.mjs, verify-packed-cohort.mjs — release/verification machinery this change correctly rides, none of which solves cross-package peer disjointness. Alternatives considered and rejected on evidence: an unbounded peer (>=0.53.0 with no ceiling) would silently accept a breaking 0.56; staying single-generat
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 5
• Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error

🎯 Usefulness — sound

Release 0.135.4 fixes a real, reproduced npm ERESOLVE failure between agent-runtime and the agent-interface 0.54/0.55 generation, using the repo's established release pattern; verified empirically that the new ranges resolve cleanly.

• Integration: Fully wired. Peer ranges (package.json:172-176), catalog (pnpm-workspace.yaml:21-28), lockfile, CHANGELOG, and the version-embedding fixtures (consumed via src/testing/index.ts:12-13, regeneration enforced by check:testing-fixture inside verify:package, package.json:139) all move together, matching the identical shape of the prior release (commit 9e6d7c9, 0.135.3). The 'caller' is every npm consum
• Fit with existing patterns: Follows the established release cadence exactly: single-generation peer windows widened at release time with the catalog floor moved in lockstep (git log shows 0.135.3 performed the identical move one generation earlier). The extension from a one-generation to a two-generation window (<0.56.0, catalog 0.55.0) is a deliberate, commit-stated response to the interface package outpacing the fleet — no
• Real-world viability: Verified on the real resolver, not just the happy path: the previously-broken combination now installs, including when the consumer pins agent-interface@0.55.0 at the root. Two weak caveats found: (1) npm satisfies agent-knowledge@8.0.2's narrower peer (>=0.54.0 <0.55.0, confirmed via npm view) by nesting a second agent-interface@0.54.0 copy under it while the rest of the tree gets 0.55.0 — duplic
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 1

🎯 Usefulness Audit

🟡 Hard dep agent-knowledge@8.0.2 still peers interface <0.55.0, forcing a nested duplicate copy [robustness] ``

npm view confirms agent-knowledge@8.0.2 peers agent-interface >=0.54.0 <0.55.0 while this release's own peer accepts <0.56.0; npm install empirically resolves this by nesting interface@0.54.0 under agent-knowledge alongside 0.55.0 elsewhere (npm ls shows both). Currently benign (no identity checks in src; types+schemas), but until agent-knowledge widens its peer, every npm consumer co-installing at 0.55.0 carries two interface copies. No action needed in this PR; revisit if agent-interface ever

🟡 Peer range floor 0.53.0 is accepted but never tested [robustness] ``

pnpm-workspace.yaml:24 pins agent-interface 0.55.0, so CI verifies only the ceiling of the >=0.53.0 <0.56.0 range. A consumer pinned to 0.53.x is promised compatibility that no test run exercises. Prior releases had the inverse gap (tested floor only), so this matches existing practice; if a low-floor break is ever suspected, a matrix check against the floor would close it.

💰 Value Audit

🟡 Lower end of the widened peer window (0.53.0) is not exercised by CI [maintenance] ``

The development catalog pins interface 0.55.0 (pnpm-workspace.yaml:24), so typecheck/tests verify only the ceiling; interface 0.53.0 appears in the lockfile solely as sandbox 0.27.0's nested dependency (pnpm-lock.yaml:3215), not as a first-class verification arm. The additivity claim for the floor end rests on the commit-message symbol diff, not on an executed check. Acceptable for a patch release, but if the multi-generation window becomes the standing policy, add a verify arm that installs the

🟡 PR body table misstates the catalog agent-core change [maintenance] ``

The table says catalog agent-core went 0.9.0 -> 0 (removed) and omits agent-profile-materialize 0.15.1 -> 0.15.2; the actual cumulative diff keeps agent-core at 0.9.1 (git diff 9e6d7c9..HEAD -- pnpm-workspace.yaml). The durable artifacts are accurate — CHANGELOG 0.135.4 entry records 'agent-knowledge to 8.0.2, agent-core to 0.9.1, and agent-profile-materialize to 0.15.2' — so this is a description error only; no code action needed, flagged so future dependency forensics trust the CHANGELOG over

---

What this audit checks

It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.

Pass	What it asks
Heuristic	Vague title? Whitespace-only or cruft-bearing diff? (content signals only)
Duplication	Do added function/class names already exist elsewhere in the repo?
Value Audit	What does it do? What goal does it achieve? Is it good? Better architecture or already-exists?
Usefulness Audit	Does it integrate and fit? Will it hold up in real use and actually get used?

Findings are concerns, not blocks — the human reviewer decides what to do with them.

_{value-audit · 20260816T074330Z}

[tangletools]

❌ Needs Work — ebb1b976

Review health 100/100 · Reviewer score 29/100 · Confidence 85/100 · 15 findings (2 high, 5 medium, 8 low)

	opencode GLM 5.2	opencode DeepSeek v4 Pro	opencode DeepSeek v4 Flash	aggregate
Readiness	76	29	56	29
Confidence	85	85	85	85
Correctness	76	29	56	29
Security	76	29	56	29
Testing	76	29	56	29
Architecture	76	29	56	29

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 9 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 5/5 planned shots over 9 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 5/5 planned shots over 9 changed files. Global verifier still owns final merge decision.

Blocking

🔴 HIGH agent-knowledge 8.0.2 resolved against an out-of-range agent-interface peer — pnpm-lock.yaml

The package entry declares peerDependencies '@tangle-network/agent-interface': '>=0.54.0 <0.55.0' (line 1163), but the resolved snapshot at line 3233 binds it to agent-interface 0.55.0 (dependency line 3236). 0.55.0 does not satisfy '<0.55.0'. This is an unmet-peer violation that pnpm will report on every install (and fail under strict-peer-dependencies). The CHANGELOG itself says 'one that carries agent-knowledge 8.0.2 resolves against 0.54'

🔴 HIGH agent-profile-materialize 0.15.2 resolved against an out-of-range agent-interface peer — pnpm-lock.yaml

The package entry declares peerDependencies '@tangle-network/agent-interface': '>=0.47.0 <0.54.0' (line 1168), unchanged from 0.15.1, but the snapshot at line 3240 binds it to agent-interface 0.55.0. 0.55.0 is two minor generations past the '<0.54.0' cap, so the peer is unmet. This is the strongest signal that the 0.55.0 catalog bump is premature: profile-materialize was not updated to accept even 0.54.0, let alone 0.55.0. Combined with finding #1, the dependency set is mutually incompatible — knowledge needs >=0.54.0 while profile-materialize needs <0.54.0

Other

🟠 MEDIUM Lockfile wires two siblings against interface generations their published peer ranges exclude — pnpm-lock.yaml

Snapshot '@tangle-network/agent-knowledge@8.0.2(...)(@tangle-network/agent-interface@0.55.0)' (line 3233, importer lines 61/137) violates knowledge 8.0.2's published peer 'agent-interface >=0.54.0 <0.55.0', and '@tangle-network/agent-profile-materialize@0.15.2(@tangle-network/agent-interface@0.55.0)' (line 3240, importer line 64)

🟠 MEDIUM Two active agent-interface copies (0.54.0 and 0.55.0) coexist across the module boundary — pnpm-lock.yaml

agent-core 0.9.1 (line 3196) and agent-eval 0.145.16 (line 3206) hard-depend on agent-interface 0.54.0, while the workspace importers depend on 0.55.0 (lines 61/64/137) and knowledge/profile-materialize resolve to 0.55.0. Two copies of the zod-typed interface package ship in one install, so values/schemas produced by agent-core/agent-eval (interface 0.54.0) are passed to consumers on interface 0.55.0. This duplicates zod schema identity across

🟠 MEDIUM agent-knowledge@8.0.2 peer resolved against agent-interface 0.55.0, outside its declared range — pnpm-lock.yaml

The catalog pins @tangle-network/agent-interface to 0.55.0 (line 1154), but agent-knowledge@8.0.2 declares its peer as '>=0.54.0 <0.55.0' (line 1163). The lockfile still resolves knowledge's peer to 0.55.0 (snapshot key and dependency line 3236). pnpm peers check confirms: 'unmet peer @tangle-network/agent-interface Installed: 0.55.0 Wanted >=0.54.0 <0.55.0'. This contradicts the PR changelog, which says a consumer carrying agent-knowledge

🟠 MEDIUM agent-profile-materialize@0.15.2 peer resolved against agent-interface 0.55.0, outside its declared range — pnpm-lock.yaml

agent-profile-materialize@0.15.2 declares peer '@tangle-network/agent-interface: >=0.47.0 <0.54.0' (line 1168) but the lockfile resolves it against 0.55.0 (snapshot line 3242). pnpm peers check flags it as an unmet peer. The published package has no release that accepts interface 0.55.0 (0.15.2 is the latest 0.15.x and still caps at <0.54.0). Same root cause as the agent-knowledge finding: catalog pins interface 0.55.0 ahead of the sibling packages' declared compatibility. Same remediation.

🟠 MEDIUM agent-interface 0.55.0 catalog bump leaves peer ranges unsatisfied for agent-knowledge and agent-profile-materialize — pnpm-workspace.yaml

Catalog now pins '@tangle-network/agent-interface': 0.55.0 (line 24) and bumps siblings to 8.0.2 (line 25) and 0.15.2 (line 26). Evidence: (1) agent-knowledge@8.0.2 publishes peerDependencies '@tangle-network/agent-interface': '>=0.54.0 <0.55.0' — 0.55.0 is outside the range; lockfile resolves it as 'agent-knowledge@8.0.2(...)(@tangle-network/agent-interface@0.55.0)' (pnpm-lock.yaml:61) and installed node_modules links it to 0.55.0.

🟡 LOW agent-core 0.9.2 referenced but catalog pins 0.9.1 — CHANGELOG.md

Line 15 says a consumer carrying agent-core 0.9.2 resolves against interface 0.55, but line 19 and pnpm-workspace.yaml pin the dev catalog at agent-core 0.9.1. The consumer-side version (0.9.2) is not what this repo verifies against (0.9.1), so the example is one version removed from the tested set. Not incorrect per se — a downstream consumer could carry 0.9.2 — but the two numbers side by side read as inconsistent. Fix: cite 0.9.1 to match the catalog, or add one clause explaining 0.9.2 is a newer consumer-side release the window also covers.

🟡 LOW agent-core version stated as both 0.9.2 and 0.9.1 in the same release entry — CHANGELOG.md

Line 15 (bullet 3): 'one that carries agent-core 0.9.2 resolves against 0.55.' Line 19 (bullet 4): 'The development catalog moves agent-knowledge to 8.0.2, agent-core to 0.9.1, and agent-profile-materialize to 0.15.2 for the same reason.' The same package is named at two different versions (0.9.2 vs 0.9.1) in one entry with no note distinguishing a consumer-installed copy from the dev-catalog pin. Fix: make the two references agree, or clarify that the dev catalog pins 0.9.1 while a released consumer copy may be 0.9.2. Docs-only, no runtime impact.

🟡 LOW test-pass claim not independently provable from this diff — CHANGELOG.md

Line 13 asserts 'Typecheck and the test suite pass against 0.55.0'. The claim is plausible (CI ran on this PR) but the evidence lives in CI, not the diff, and a changelog cannot carry it. Consistent with the repo's existing changelog convention (0.135.3 line 26 makes the same claim against 0.53.0), so acceptable; only flagged so the claim gate is explicit — verify CI green on the head commit before merge.

🟡 LOW Orphaned agent-interface@0.53.0 snapshot left in lockfile — pnpm-lock.yaml

Both the package entry (line 1148) and snapshot (line 3215) for agent-interface 0.53.0 remain, but no importer or dependency references them (grep for 'agent-interface: 0.53.0' and 'agent-interface@0.53.0' returns only these self-definitions). The lockfile was not pruned after the bump; a fresh 'pnpm install' would drop it. Purely a hygiene nit, but it suggests the lockfile was hand-edited or not regenerated cleanly.

🟡 LOW Three agent-interface copies coexist in the dependency graph — pnpm-lock.yaml

The tree now contains agent-interface 0.53.0 (pulled by sandbox@0.27.0, line 3215), 0.54.0 (regular dep of agent-core@0.9.1 and agent-eval@0.145.16, lines 3196/3206), and 0.55.0 (root catalog, line 3227). Since agent-interface ships runtime zod schemas (agentProfileSchema, sha256DigestSchema) plus @noble/hashes and spdx-expression-parse, duplicate copies risk schema/type identity mismatch when objects validated by one copy cross into code com

🟡 LOW Three copies of agent-interface (0.53.0/0.54.0/0.55.0) coexist in the dev tree — pnpm-lock.yaml

pnpm why @tangle-network/agent-interface on the installed tree confirms 0.53.0 (via @tangle-network/sandbox@0.27.0, which pins agent-core@0.9.0/interface 0.53.0 as direct deps — lines 3187/3215/3248), 0.54.0 (inside agent-core@0.9.1 and agent-eval@0.145.16), and 0.55.0 (root, knowledge, profile-materialize). Any value crossing the runtime↔agent-eval boundary passes between two interface generations; zod schemas and structural types keep it working now, but instance-identity checks or symbol-keyed registries would split silently. The sandbox 0.27.0 pin was deliberately not bumped this wave (consistent with the changelog's three-generation strategy) — track it for the next

🟡 LOW Three copies of agent-interface and two of agent-core coexist in the dependency tree — pnpm-workspace.yaml

Installed tree contains agent-interface 0.53.0 (via @tangle-network/sandbox@0.27.0), 0.54.0 (hard dep of agent-eval@0.145.16 and agent-core@0.9.1), and 0.55.0 (catalog); agent-core 0.9.0 (via sandbox) and 0.9.1 (catalog). Verified the repo imports only zod schemas and pure functions from agent-interface (applyAgentProfileDiff, digest fns, *Schema), so no instanceof/symbol-branding hazard across copies exists today. Informational: any future runtime-value identity checks across these boundaries would silently fail. No action required in this shot.

🟡 LOW agent-interface 0.55.0 violates declared peer ranges of agent-knowledge 8.0.2 and agent-profile-materialize 0.15.2 — pnpm-workspace.yaml

Catalog pins '@tangle-network/agent-interface': 0.55.0 while lockfile shows agent-knowledge@8.0.2 declares peer '>=0.54.0 <0.55.0' (pnpm-lock.yaml:1157-1163, snapshot resolved at 0.55.0 on :3233) and agent-profile-materialize@0.15.2 declares '>=0.47.0 <0.54.0' (resolved at 0.55.0 on :3240). The two declared ranges are mutually disjoint, so no pin satisfies both. pnpm resolves anyway (no strict-peer-dependencies; no .npmrc), producing install warnings and a latent risk if either package later ships a patch relying on <0.55 semantics. CHANGELOG documents this as deliberate (0.54/0.55 additive, typecheck+tests pass — I verified tsc and fixture check clean). Fix: upstream, republish knowledge/materialize with widened peers; nothing to change in this repo now.

---

_{tangletools · 2026-08-16T08:15:21Z · trace}

[tangletools]

❌ 2 Blocking Findings — ebb1b976

Full multi-shot audit completed 5/5 planned shots over 9 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 5/5 planned shots over 9 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 5/5 planned shots over 9 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-16T08:15:21Z · immutable trace}

[drewstone]

Redirected to ^1.0.0

This PR declares another single-generation window. That pattern is being retired, so this branch will be repointed rather than merged as written.

@tangle-network/agent-interface 1.0.0 is cut in tangle-network/agent-sdk#195. Its published surface equals 0.56.0 exactly; only the number changes, plus a stated promise in the CHANGELOG and README:

• minor = additive
• patch = fix
• removal or narrowing = major

The evidence is on tangle-network/agent-sdk#190: ten transitions 0.45.0 → 0.55.0 audited from unpacked tarballs, exports 748 → 823, zero removals, one narrowing in ten generations, and 0 major / 53 minor / 14 patch across every changeset in that repository's history. The team already applies 1.x semantics; the number contradicted them.

A window like <0.56.0 buys days. Under ^1.0.0 an additive minor needs no consumer release at all, so this is intended as the last adoption wave.

This branch will be updated to declare ^1.0.0 once 1.0.0 publishes, then re-reviewed and merged.

[drewstone]

Superseded by #881, which adopts @tangle-network/agent-interface@^1.0.0 instead of widening to the next single-generation window.

This PR moved the peer to >=0.54.0 <0.55.0. That shape is the defect, not the fix: it needs a release of this package for every interface minor, and while it is in flight the fleet splits into two disjoint halves — which is exactly what happened this morning and is written up in tangle-network/agent-sdk#190.

It was also CONFLICTING, and its sibling floors (agent-eval, sandbox, agent-knowledge, agent-profile-materialize) have all moved since it was opened, so repointing the branch would have meant rewriting every line of it.

#881 supersedes it end to end:

declaration	this PR	#881
peer agent-interface	>=0.54.0 <0.55.0	^1.0.0
catalog agent-interface	0.54.0	1.0.0
catalog agent-core	—	0.9.4
catalog agent-eval	—	0.145.21
catalog agent-knowledge	—	8.0.5
catalog agent-profile-materialize	—	0.16.0
catalog sandbox	—	0.27.1

A clean install under #881 resolves exactly one agent-interface@1.0.0 and one agent-core@0.9.4; 2733 tests pass.