chore(deps): adopt interface 0.53 lockstep with runtime 0.135.3 and sandbox 0.27.0

[drewstone]

Change

Move the shell onto the coherent interface-0.53 cohort:

package	before	after
@tangle-network/agent-interface	0.47.x line	0.53.0
@tangle-network/agent-knowledge	7.x	8.0.1
@tangle-network/agent-runtime	0.135.2	0.135.3
@tangle-network/sandbox	0.26.2	0.27.0
@tangle-network/sandbox-ui	0.103.0	0.103.1

agent-runtime 0.135.3 raises its interface peer to >=0.53.0 <0.54.0, which agent-knowledge 8.x requires. This makes the published set co-installable (agent-runtime#694).

Proof

• pnpm install resolves one version of each first-party package: interface 0.53.0, knowledge 8.0.1, runtime 0.135.3, sandbox 0.27.0, sandbox-ui 0.103.1.
• pnpm typecheck (tsc --noEmit): clean, zero errors.
• src/peer-floors/check.test.ts: 14 passed (14).
• The one remaining peer warning (@tangle-network/brand 1.4.0 vs wanted ^1.5.0) predates this change: sandbox-ui 0.103.0 and ui 11.5.0 already declared ^1.5.0.

[drewstone]

@tangletools review now

[tangletools]

✅ Auto-approved drewstone PR — a30eafce

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-16T04:42:49Z}

[tangletools]

✅ Auto-approved drewstone PR — a30eafce

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-16T04:42:54Z}

[drewstone]

@tangletools review now

[tangletools]

✅ Auto-approved drewstone PR — a30eafce

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-16T04:45:11Z}

[tangletools]

🔴 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	308.8s (2 bridge agents)
Total	308.8s

💰 Value — redundant-or-flawed

Right and necessary lockstep move (the old interface cap made the published set un-installable), but executed across 2 files where the repo's own doctrine and prior lockstep PR (#432, 25 files) require the pin to move in every place it appears — it leaves the create-agent-app templates below the new

• What it does: Raises agent-app's published peer floor for @tangle-network/agent-interface from '>=0.47.0 <0.48.0' to '>=0.53.0 <0.54.0' (package.json:576) and moves this repo's own devDependency cohort onto the interface-0.53 line: interface 0.47.0→0.53.0, knowledge 7.2.4→8.0.1 (major), runtime 0.133.0→0.135.3, sandbox 0.21.1→0.27.0 (six minors), sandbox-ui 0.100.1→0.103.1, eval 0.145.3→0.145.15, integrations 0
• Goals it achieves: Co-installability of the published set: agent-runtime 0.135.3 and agent-knowledge 8.0.1 both peer interface '>=0.53.0 <0.54.0' (verified in pnpm-lock.yaml:1883-1896), so a consumer installing agent-app beside current runtime/knowledge had no peer-consistent tree under the old <0.48.0 cap (agent-runtime#694). Once merged, a consumer resolving agent-app + current siblings gets one version of each fi
• Assessment: The goal is legitimate and the core move (interface floor raise + self-audit test update) is in-grain and verified by the lockfile. But the execution contradicts the change's own completeness standard, set by the directly preceding interface-line move: #432 (2dc375e, the 0.42→0.47 move) touched 25 files — both create-agent-app templates, docs/codemap/llms regeneration, and source fallout — and #43
• Better / existing approach: Not a different architecture — the same move, completed the way the repo already does it. Searched: git log for both template files (every prior dep-line move — #432, #433 — updated them), the drift gates in tests/create-agent-app*.test.ts, pnpm-lock.yaml peer blocks, and release commits (878d953 etc. — automation bumps only create-agent-app's own version, never template pins, so there is no auto-
• 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 lockstep move itself is correct and verified (the committed lockfile resolves exactly one version of each first-party package on the interface-0.53 cohort), but the create-agent-app templates were left pinning interface 0.47.0 / runtime 0.133.0 / sandbox 0.21.1, which reds this repo's own drift

• Integration: The core wiring is right and reachable: package.json devDeps, the committed pnpm-lock.yaml (lines 1874-1956: exactly one resolved version of interface 0.53.0, knowledge 8.0.1, runtime 0.135.3, sandbox 0.27.0, sandbox-ui 0.103.1), the published peer floor, and the self-audit test all move together. The lockfile confirms the stated motivation is real: agent-runtime 0.135.3 peers interface '>=0.53.0
• Fit with existing patterns: Perfect fit for the established pattern — this is the same move as #432 (2dc375e, 'move onto the agent-interface 0.47 line') and #433 (e0d53e2, 'keep the create-agent-app templates on agent-runtime 0.133.0'), both of which bumped the template manifests in the same commit. The minor-locked interface floor is the repo's own doctrine (AGENTS.md /peer-floors: 'a caret on a 0.x version is MINOR-LOCKED.
• Real-world viability: Beyond the red gates, the real-world failure mode is the exact one /peer-floors was built to prevent: a freshly scaffolded app ('create-agent-app', the repo's own first-class onboarding surface, whose template AGENTS.md step 0 says 'Run pnpm install && pnpm typecheck && pnpm test. Confirm green BEFORE editing') installs a peer-inconsistent tree that typechecks against mismatched types and can fail
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 1

🎯 Usefulness Audit

🔴 create-agent-app templates left on the old cohort; repo's own drift gates go red [integration] ``

create-agent-app/template/_package.json:24,30 and create-agent-app/template-chat/_package.json:21-23 still pin @tangle-network/agent-interface 0.47.0 (plus runtime 0.133.0, sandbox 0.21.1, eval 0.145.3, integrations 0.53.53), while this PR raises agent-app's published interface floor to '>=0.53.0 <0.54.0'. The repo's own gates catch this: tests/create-agent-app.test.ts:146-160 and tests/create-agent-app-chat.test.ts:150-157 assert minimumVersionGte(templatePin, peerFloor), and gte(0.47.0, 0.53.0

💰 Value Audit

🔴 Templates left below the new floor — the repo's own drift gates go red by construction [against-grain] ``

create-agent-app/template/_package.json:24,30 and template-chat/_package.json:21 still pin @tangle-network/agent-interface '0.47.0' (plus runtime 0.133.0, sandbox 0.21.1, eval 0.145.3) while package.json:576 now floors interface at '>=0.53.0 <0.54.0'. tests/create-agent-app-chat.test.ts:136-158 and tests/create-agent-app.test.ts:117-139 assert minimumVersionGte(templatePin, floor); minVersion('0.47.0') fails gte against 0.53.0 (helper at tests/test-utils/version-ranges.ts:3-10), so both gates fa

🟠 Published knowledge/runtime floor minima are now unsatisfiable against the shell's own interface requirement [against-grain] ``

package.json:577 keeps '@tangle-network/agent-knowledge': '>=7.2.4' and :579 keeps '@tangle-network/agent-runtime': '>=0.132.13', but #432's commit message documents that knowledge 7.2.4 and runtime 0.132.13 peer interface '>=0.47.0 <0.48.0', while agent-app now requires '>=0.53.0 <0.54.0' — a consumer honoring the published minimum gets an unmet-peer tree by arithmetic. The lockfile confirms the new cohort boundary (pnpm-lock.yaml:1883-1896: knowledge 8.0.1 and runtime 0.135.3 both peer interfa

🟡 PR body misstates the before-versions, understating the size of the jump [maintenance] ``

The body's table claims before: runtime 0.135.2, sandbox 0.26.2, sandbox-ui 0.103.0. The actual base (git show 878d953:package.json lines 522-530) is runtime 0.133.0, sandbox 0.21.1, sandbox-ui 0.100.1, knowledge 7.2.4 — i.e. sandbox jumps six minors, knowledge a major, runtime two minors, not three patch bumps. The risk profile a reviewer infers from the table (small) and the real one (interface 6 minors + knowledge major + sandbox 6 minors with zero source fallout handled) differ materially; #

---

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 · 20260816T051157Z}

[tangletools]

❌ Needs Work — a30eafce

Review health 100/100 · Reviewer score 34/100 · Confidence 75/100 · 14 findings (1 high, 7 medium, 6 low)

	opencode GLM 5.2	opencode DeepSeek v4 Pro	opencode DeepSeek v4 Flash	aggregate
Readiness	34	62	76	34
Confidence	75	75	75	75
Correctness	34	62	76	34
Security	34	62	76	34
Testing	34	62	76	34
Architecture	34	62	76	34

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

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

Blocking

🔴 HIGH Interface floor bump to the 0.53 line breaks create-agent-app templates; own drift gate fails on head — package.json

Floor moved from '>=0.47.0 <0.48.0' to '>=0.53.0 <0.54.0' while create-agent-app/template/_package.json (lines 24-31: interface 0.47.0, runtime 0.133.0) and template-chat/_package.json (lines 21-23: interface 0.47.0, runtime 0.133.0, sandbox 0.21.1) still pin the 0.47 line against scaffolded agent-app@AGENT_APP_VERSION (= 0.45.61 after publish). Reproduced: after pnpm build, npx vitest run tests/create-agent-app.test.ts tests/create-agent-app-chat.test.ts fails 'template pins @tangle-network/agent-interface@0.47.0, below agent-app's peer floor >=0.53.0 <0.54

Other

🟠 MEDIUM Breaking peer-floor move ships as a patch release (0.45.61) — package.json

Head sits directly on release commit 0.45.60 with two chore(deps) commits and no version bump; publish.yml's auto mode always computes patch+1 (lines 100-107: ${major}.${minor}.${BigInt(patch)+1n}). So this merges as 0.45.61, and ^0.45.60 consumers auto-take a manifest whose interface peer floor jumped six 0.x minor lines — their installs fail peer resolution until they bump interface 0.47→0.53, knowledge 7→8, runtime 0.133→0.135.x, sandbox 0.21→0.27 together. Fail-closed but a breaking change in a patch channel; the repo's own convention (AGENTS.md: Office-attachment default widening was 'a minor-version change, not an additive one') treats moved shipped contracts as

🟠 MEDIUM Sibling peer floors left stale are jointly unsatisfiable with the new interface floor — package.json

Only the interface floor was raised. agent-knowledge floor stays '>=7.2.4' (line 577) but every knowledge 7.x peers interface '>=0.47.0 <0.48.0' (base pnpm-lock.yaml) — no knowledge 7.x version can resolve against agent-app's new interface floor 0.53.x; only knowledge >=8.0.1 (interface peer '>=0.53.0 <0.54.0') can. Same class for agent-runtime floor '>=0.132.13' (line 579): runtime 0.133.0 peers interface '<0.48.0', runtime 0.135.3 peers '>=0.53.0 <0.54.0' (both read from committed lockfiles). The published floor set therefore advertises install combinations that cannot

🟠 MEDIUM agent-interface peer floor breaks consumers at 0.47.x-0.52.x (0.47 -> 0.53 line) — package.json

Peer range moved from '>=0.47.0 <0.48.0' to '>=0.53.0 <0.54.0'. Every consumer still on the previously sanctioned 0.47.x line (or 0.48-0.52) now sits below the floor: their agent-app-peer-check goes red, and without the check they get the documented failure class — clean install + green typecheck, then a module-load error at the tagged-MCP-config exports (agent-interface 0.38+ changed the MCP builder surface; the /tools subpath validates against the real agentProfileMcpServerSchema at build time). The move is REQUIRED (agent-eval 0.145.15, agent-runtime 0.135.3, and sandbox 0.27.0 all peer-require agent-interface >=0.53.0 <0.54.0; the self-audit test in src/peer-floors/check.test.ts was updated in the same PR), so the change is correct — but it is a forced coordinated migration (interface

🟠 MEDIUM agent-knowledge peer floor not raised across a MAJOR bump — package.json

Line 525 bumps @tangle-network/agent-knowledge 7.2.4 -> 8.0.1 (a MAJOR; also gains engines {node: '>=20.19.0'} per lockfile), but line 577 keeps the peer floor at '>=7.2.4'. A major carries breaking changes by convention, so a consumer resolving 7.x satisfies the declared floor while the /knowledge and /knowledge-loop subpaths are developed and tested only against 8.x. The agent-runtime 0.135.3 entry in the lockfile confirms the ecosystem moved to 8.0.1 as a direct dependency. Fix: raise the floor to '>=8.0.1' or document a concrete reason the 7.x wire contract still hold

🟠 MEDIUM sandbox peer floor not raised while dev dep and peer runtime both require 0.27.x — package.json

Line 529 bumps devDependency @tangle-network/sandbox 0.21.1 -> 0.27.0 (six 0.x minors, breaking by convention), but line 581 leaves the published peer floor at '>=0.21.1'. The lockfile proves the gap: agent-runtime@0.135.3 (which agent-app declares support for via the '>=0.132.13' peer on line 579 and dev-depends on) declares its own peer sandbox '>=0.27.0 <0.28.0' (was '>=0.21.1 <0.22.0' on 0.133.0). A consumer following agent-app's floor guidance installs sandb

🟠 MEDIUM sandbox-ui 0.103.1 requires @tangle-network/brand ^1.5.0 but brand remains 1.4.0 — pnpm-lock.yaml

The bump of @tangle-network/sandbox-ui 0.100.1 -> 0.103.1 widens its peerDependency on @tangle-network/brand from ^1.4.0 to ^1.5.0 (line 1919), and brand is NOT in sandbox-ui's peerDependenciesMeta.optional list, so it is a required peer. package.json and the lock importer still pin brand at 1.4.0 (importer line 57), and the sandbox-ui snapshot resolves '@tangle-network/brand': 1.4.0(react@19.2.8) (line 6325) — a version that does not satisfy ^1.5.0. brand

🟠 MEDIUM sandbox-ui 0.103.1 requires @tangle-network/brand ^1.5.0 but the tree resolves brand 1.4.0 — pnpm-lock.yaml

The lock records sandbox-ui 0.103.1 with required peer '@tangle-network/brand': ^1.5.0 (not in peerDependenciesMeta's optional list, verified at packages entry ~line 1914), while the only brand entry in the tree is '@tangle-network/brand@1.4.0' (line 1905, snapshot 6314) — package.json still pins "@tangle-network/brand": "1.4.0". Reproduced via pnpm peers check: 'unmet peer @tangle-network/brand Installed: 1.4.0 Wanted: ^1.5.0: @tangle-network/sandbox-ui@0.103.1'. At base, sandbox-ui 0.100.1 accepted ^1.4.0, so this PR introduces a new unmet required peer. pnpm is

🟡 LOW agent-eval peer floor left below what the new agent-runtime requires — package.json

Line 522 bumps @tangle-network/agent-eval 0.145.3 -> 0.145.15, but line 574 keeps the peer floor at '>=0.145.2' (unbounded above). The lockfile shows agent-runtime@0.135.3 now declares agent-eval '>=0.145.15 <0.146.0' (was '>=0.145.2 <0.146.0'), so agent-app's floor admits 0.145.2-0.145.14 (rejected by its own peer runtime) and any 0.146.0+ (also rejected). Patch-level gap, hence low, but the same floor-vs-runtime inconsistency as the sandbox case. Fix: raise to '>=0.145.15'.

🟡 LOW agent-knowledge major 7->8 adopted with floor >=7.2.4 unchanged — package.json

The devDep jumped a major line (7.2.4 -> 8.0.1) while the optional-peer floor stayed >=7.2.4. Verified safe today: the 8 symbols consumed by src/knowledge-loop/index.ts (runKnowledgeResearchLoop, textSourceAdapter, AddSourceTextInput, SourceAdapter, KnowledgeResearchLoopContext/Decision/Result, RunKnowledgeResearchLoopOptions) are type-identical between published 7.2.4 and 8.0.1 — the 8.0.1 d.ts diff only touches UncheckableClaimError's constructor (+required note arg) and the added gradeFor/ClaimGrade, neither of which agent-app imports. Same one-directional floor-verification caveat as the sandbox finding; no action required now.

🟡 LOW sandbox floor >=0.21.1 unchanged while dev/test surface moved to 0.27.0 — package.json

Verified the floor is NOT stale today: all 9 sandbox symbols imported by src/ (EgressPolicy, MintScopedTokenOptions, ProvisionEvent, SandboxConnection, SandboxInstance, ScopedTokenScope, SessionMessage, StorageConfig, TurnDriveResult) and every called method (mintScopedToken, driveTurn, streamPrompt, session().sendMessage, findCompletedTurn) exist in published sandbox 0.21.1; the 7 members added in 0.27.0 (.capabilities, .fork, .createReceipt, getForkOperation, getSnapshotOperation, _listInteractions, _respondToInteraction) are never called. But the self-audit test only asserts one direction (the dev install satisfies the published floors), never that the dev install is the MINIMUM the code supports — the moment any subpath calls a post-0.21.1 API, consumers on 0.21.1 fail a passing floor.

🟡 LOW sandbox-ui 0.103.1 requires brand ^1.5.0 but brand pin and floor stay on 1.4.0 — package.json

Verified from installed manifests: sandbox-ui 0.103.1 (pinned by this PR) declares peer '@tangle-network/brand: ^1.5.0' and '@tangle-network/ui: ^11.5.0', but package.json pins brand 1.4.0 (line 528) and publishes floor '>=1.4.0' (line 580). The dev tree itself carries an unmet peer (install completed with at most a warning; typecheck/tests green because brand 1.4's surface still satisfies both), and consumers combining brand 1.4.x with sandbox-ui 0.103.x get the same unmet peer. Risk is design-token drift between what sandbox-ui 0.103 was built against and the pinned bra

🟡 LOW Pre-existing unmet peer: @tangle-network/ui@11.5.0 also wants brand ^1.5.0 — pnpm-lock.yaml

Verified via git show <base>:pnpm-lock.yaml that ui@11.5.0 already declared brand ^1.5.0 at base with brand 1.4.0 resolved — so half of the pnpm peers check output is inherited, not introduced by this PR. Not blocking for this shot, but a brand 1.5.x bump fixing the medium finding would clear both violations at once; leaving it means the tree's only unmet-peer warning now names two packages, making future real regressions easier to miss in the noise.

🟡 LOW sandbox-ui@0.103.1 resolved below its declared @tangle-network/brand peer floor — pnpm-lock.yaml

sandbox-ui@0.103.1 declares a REQUIRED (not in peerDependenciesMeta) peer '@tangle-network/brand': ^1.5.0 (pnpm-lock.yaml:1919), but the snapshot resolves '@tangle-network/brand': 1.4.0 (pnpm-lock.yaml:6325); the importer pins brand at 1.4.0 (package.json:528). The previous sandbox-ui 0.100.1 wanted ^1.4.0, so this PR is what widens the mismatch. pnpm 11 (packageManager: pnpm@11.17.0, no strict-peer-dependencies/.npmrc) installs this with an 'Unmet peer dependency' WARNING on pnpm install --frozen-lockfile in CI (ci.yml:51) — the exact clean-install/clean-typecheck/green-suite class this repo's /peer-floors module exists to catch. Verified impact today is nil: the published brand 1.4.0 and 1.5.0 dist directories diff empty and both export Logo/TangleKnot, which is all sandbox-ui 0.103.1

---

_{tangletools · 2026-08-16T05:31:42Z · trace}

[tangletools]

❌ 1 Blocking Finding — a30eafce

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

Full immutable report for this review: trace

Summary comment for this run: full summary

---

_{tangletools · 2026-08-16T05:31:42Z · immutable trace}

[tangletools]

🟡 Value Audit — sound-with-nits

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

💰 Value — sound-with-nits

A correct, in-grain cohort bump that restores co-installability (runtime 0.135.x and knowledge 8.x both hard-require interface 0.53.x, verified from installed peer manifests), ship it — but only the interface peer floor moved, leaving the published floor set internally contradictory where the repo's

• What it does: Bumps the first-party devDependency cohort (package.json:521-530): agent-interface 0.47.0→0.53.0, agent-knowledge 7.2.4→8.0.1, agent-runtime 0.133.0→0.135.3, sandbox 0.21.1→0.27.0, sandbox-ui 0.100.1→0.103.1, plus agent-eval/integrations/profile-materialize. Raises the published interface peer floor from '>=0.47.0 <0.48.0' to '>=0.53.0 <0.54.0' (package.json:576), updates the peer-floors self-audi
• Goals it achieves: Restore a co-installable published set: the previous '<0.48.0' interface cap excluded every version the current engine line accepts. Verified from the installed tree: agent-runtime 0.135.3 peer-requires interface '>=0.53.0 <0.54.0' and agent-knowledge 8.0.1 peer-requires the same range plus agent-eval '>=0.145.14 <0.146.0', so the old floor made no valid combination installable. The new cap byte-m
• Assessment: Good change, correctly executed. The interface cap exactly matches what runtime 0.135.3 and knowledge 8.0.1 declare (checked node_modules peer manifests, not just the PR body). The self-audit test update is precisely the file this repo maintains for pinning the published range shape, and the minor-locked '>=0.53.0 <0.54.0' form follows the peer-floors doctrine for 0.x peers. The lockfile is regene
• Better / existing approach: No better mechanism — the interface cap is the right and necessary move. Searched for one anyway: the repo's own /peer-floors module is the existing tool for exactly this and the PR uses it correctly. The improvement is completeness, not redesign: raise the sibling floors in the same commit, as the directly analogous PR #432 (commit 2dc375e, 'move onto the agent-interface 0.47 line') did — that co
• 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 dev-dependency cohort aligns correctly onto interface 0.53.0 and typechecks/passes cleanly, but the lockstep is incomplete — four sibling peer floors were left at pre-0.53 versions whose own interface constraints are disjoint from the new interface floor, so the published peer set is not actuall

• Integration: Wires in correctly and is genuinely consumed: the peerDependencies in package.json are the published contract every consumer installs against, not speculative surface. The interface floor moved from >=0.47.0 <0.48.0 to >=0.53.0 <0.54.0 (package.json:576), which is exactly the range agent-runtime 0.135.3 and agent-knowledge 8.0.1 require, and it is satisfied by sandbox-ui 0.103.1 (`>=0.36.0 <0.
• Fit with existing patterns: Follows the repo's existing /peer-floors discipline and its self-audit convention (check.test.ts pins the current interface line and asserts the dev install satisfies the published floors). The gap is that the lockstep is only half-applied. The PR title promises 'adopt interface 0.53 lockstep' and the body's goal is 'makes the published set co-installable', but only the interface peer moved. The
• Real-world viability: The dev tree is co-installable and verified, and interface 0.53.0 satisfies every peer constraint in the current install, so the tested path holds. Under realistic use the edge case is the consumer who satisfies the shell's declared floors exactly (e.g. holds knowledge 7.2.4 or runtime 0.132.13) and upgrades only agent-app: pnpm then finds no intersection between the shell's `interface >=0.53 <0.5
• 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

🟠 Sibling peer floors left in the old 0.47 cohort, making the published floor set self-contradictory [against-grain] ``

Only the interface floor moved (package.json:576). The knowledge floor still reads '>=7.2.4' (package.json:577) and runtime still '>=0.132.13' (package.json:579), but the old lockfile shows knowledge 7.2.4 and runtime 0.133.0 both peer-require interface '>=0.47.0 <0.48.0' (git show HEAD~2:pnpm-lock.yaml, snapshots section). A consumer honoring this shell's published floors at floor-minimum versions therefore cannot build a tree that satisfies the new interface cap — the exact 'clean install, gre

🎯 Usefulness Audit

🟠 Sibling peer floors left behind the interface lockstep, so the published peer set is not co-installable [problem-fit] ``

The change's stated goal is to make the published set co-installable, but it raised only the interface peer (package.json:576 to >=0.53.0 <0.54.0) while leaving agent-knowledge >=7.2.4 (577), agent-runtime >=0.132.13 (579), agent-profile-materialize >=0.14.0 (578) and sandbox-ui >=0.100.1 (582) at floors whose own interface requirements (>=0.47 <0.48, >=0.47 <0.48, >=0.46 <0.48, >=0.36 <0.48 respectively, verified via npm view <pkg>@<floor> peerDependencies) are disjoint from

---

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 · 20260816T053830Z}

[tangletools]

🔴 Value Audit — redundant-or-flawed

Verdict	redundant-or-flawed
Coverage	2 of 2 lenses (value, usefulness)
Concerns	4 (1 strong-concern, 2 medium-concern, 1 weak-concern)
Heuristic	0.0s
Duplication	0.0s
Interrogation	800.2s (2 bridge agents)
Total	800.2s

💰 Value — redundant-or-flawed

A correct, in-grain interface-0.53 lockstep for the dev tree, but the lockstep is left incomplete in the two places the repo's own doctrine (#432/#433 precedent, signoff gate) requires it to land: the create-agent-app templates still pin the 0.47 cohort (verified to fail the repo's own generated-pro

• What it does: Moves the shell's devDependency cohort onto the interface-0.53 line: agent-interface 0.47.0→0.53.0, agent-knowledge 7.2.4→8.0.1 (a major), agent-runtime 0.133.0→0.135.3, sandbox 0.21.1→0.27.0, sandbox-ui 0.100.1→0.103.1, plus eval 0.145.15 / integrations 0.53.54 / materialize 0.15.1 (package.json:522-530). Narrows the published peer for interface from '>=0.47.0 <0.48.0' to '>=0.53.0 <0.54.0' (pack
• Goals it achieves: Make the published set co-installable: the PR body and lockfile show runtime 0.135.3 and knowledge 8.0.1 both peer interface '>=0.53.0 <0.54.0', so the old '>=0.47.0 <0.48.0' peer had an empty intersection with the current sibling cohort — the exact defect #432 fixed in the same direction. Secondary: keep the shell developing against the current engine cohort (sandbox 0.21→0.27, sandbox-ui 0.100→0
• Assessment: Direction and mechanism are right — this is the established #432 pattern, the test change is the correct mechanical move, and I re-ran the proof: src/peer-floors/check.test.ts 14/14 green. But the change under-delivers its own stated goal ('lockstep'): the lockstep stops at package.json while the repo carries the same pins in two more places, and the repo's own merge gate catches one of them. This
• Better / existing approach: No better architecture — bumping pins in lockstep is the right approach; it is just incompletely executed. I looked for an existing mechanism that syncs the template pins automatically (grep'd create-agent-app/index.mjs — it only substitutes AGENT_APP_VERSION at line 141; no script in scripts/ or .github/scripts/ rewrites template versions) and for a guard stronger than the self-audit (check.t
• 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

Necessary lockstep cohort adoption, verified installing/typechecking clean with the real schema-sensitive surfaces passing — but the adopted agent-knowledge 8.0.1 makes the shell's own /knowledge-loop e2e tests intermittently exceed the default 5s timeout (~50% of runs, 0% on base), and the publishe

• Integration: Fully wired: devDependencies pin the cohort (package.json:522-530), pnpm-lock.yaml resolves exactly one version of each first-party package (verified after fresh install: interface 0.53.0, knowledge 8.0.1, runtime 0.135.3, sandbox 0.27.0, sandbox-ui 0.103.1), and the raised interface floor >=0.53.0 <0.54.0 (package.json:576) is the mechanism that pushes fleet consumers onto the coherent set — th
• Fit with existing patterns: Matches the repo's established lockstep-bump convention exactly: exact dev pins + range floors + lockfile update (git log shows the same shape in prior cohort bumps). The interface floor kept minor-locked per the repo's own 0.x-is-breaking doctrine, and the test that pins the current line without claiming the next was updated in the same change — the in-grain way to do this.
• Real-world viability: Mixed. Typecheck clean, gates 94/94, tools/sandbox/profile suites pass. But the /knowledge-loop e2e tests (tests/knowledge-loop.test.ts) — the module that wraps agent-knowledge's runKnowledgeResearchLoop/textSourceAdapter (src/knowledge-loop/index.ts:43-54) — timed out in 2 of 4 runs at the default 5s per-test budget on this cohort, while the same tests pass consistently on base (HEAD~2 worktr
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 1

💰 Value Audit

🔴 create-agent-app templates still pin the 0.47 cohort — the repo's own generated-project gate goes red [against-grain] ``

create-agent-app/template/_package.json:24,30-31 and template-chat/_package.json:21-23 pin agent-interface 0.47.0, agent-runtime 0.133.0, sandbox 0.21.1, eval 0.145.3 — the OLD cohort. The scaffolder substitutes only AGENT_APP_VERSION (create-agent-app/index.mjs:141), so a generated project installs this branch's packed agent-app (peer '>=0.53.0 <0.54.0') beside interface 0.47.0. Verified empirically: 'pnpm install --strict-peer-dependencies' against a shell carrying this exact peer range an

🟠 Published sibling floors still admit the 0.47 cohort — the floor minimums are jointly unsatisfiable with the new interface peer [against-grain] ``

package.json:577-582 leaves agent-knowledge '>=7.2.4', agent-runtime '>=0.132.13', sandbox '>=0.21.1' unchanged. Per the repo's own record (#432 commit message), runtime 0.132.13 and knowledge 7.2.4 peer interface '>=0.47.0 <0.48.0'; the new snapshots in this lockfile show runtime 0.135.3 and knowledge 8.0.1 are the cohort that peers interface 0.53 (and runtime 0.135.3 peers sandbox '>=0.27.0 <0.28.0'). So a consumer satisfying agent-app's floors at their minimums (knowledge 7.2.4 or runtime 0.1

🎯 Usefulness Audit

🟠 agent-knowledge 8.0.1 intermittently pushes /knowledge-loop e2e past the 5s test timeout — the adopted major degrades the one capability that consumes it [robustness] ``

Evidence: npx vitest run tests/knowledge-loop.test.ts on HEAD → 2 failed / 9 passed, then 9/9, 9/9, 2 failed (50% flake, all 'Test timed out in 5000ms'); the same file on a base worktree (HEAD2, knowledge 7.2.4) → 9/9 across runs; with --testTimeout=60000 on HEAD all pass in 4.6s total, so the loop is intermittently slow rather than deadlocked. src/knowledge-loop/index.ts:51-54 is the shell's only runtime import of agent-knowledge, so this is the direct consumer of the 7→8 major. What to do:

🟡 Sibling peer floors left at pre-cohort versions, so the published floor set itself is not co-installable with the new interface floor [problem-fit] ``

Evidence: interface floor raised to >=0.53.0 <0.54.0 (package.json:576) but runtime stays >=0.132.13 (:579), sandbox >=0.21.1 (:581), knowledge >=7.2.4 (:577), materialize >=0.14.0 (:578). The lockfile shows runtime 0.133.0 (floor-satisfying) itself pins interface >=0.47.0 <0.48.0 and sandbox >=0.21.1 <0.22.0, and sandbox 0.21.1 resolves agent-core 0.6.1 → interface 0.47 — so a consumer honoring agent-app's published floors verbatim (interface 0.53 + runtime 0.132.13) passes this s

---

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 · 20260816T054622Z}

[tangletools]

✅ No Blockers — a30eafce

Review health 100/100 · Reviewer score 63/100 · Confidence 75/100 · 9 findings (4 medium, 5 low)

	opencode DeepSeek v4 Pro	opencode DeepSeek v4 Flash	aggregate
Readiness	72	63	63
Confidence	75	75	75
Correctness	72	63	63
Security	72	63	63
Testing	72	63	63
Architecture	72	63	63

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

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

🟠 MEDIUM agent-eval peer floor left below agent-runtime 0.135.3 and agent-knowledge 8.x requirements — package.json

package.json:574 publishes agent-eval ">=0.145.2", but the engines adopted in this PR declare higher floors: agent-runtime@0.135.3 requires agent-eval ">=0.145.15 <0.146.0" (pnpm-lock.yaml:1895) and agent-knowledge@8.0.1 requires ">=0.145.14 <0.146.0" (pnpm-lock.yaml:1882). A consumer with eval 0.145.2-0.145.14 who installs this shell plus agent-runtime/knowledge gets a silent (optional-peer) mismatch and fails at module load or first call, with their own peer-floor audit green. The shell's own tree passes only because dev resolves 0.145.15 (package.json:522). Fix: raise the eval floor to >=0.145.15.

🟠 MEDIUM agent-knowledge peer floor not raised across a MAJOR bump — package.json

devDependencies bumps @tangle-network/agent-knowledge 7.2.4 → 8.0.1 (a semver MAJOR, line 525), but the peerDependency floor stays >=7.2.4 (line 577). agent-app source imports it at runtime (src/knowledge-loop/index.ts:50-54 — runKnowledgeResearchLoop, textSourceAdapter). A major bump is the strongest signal of breaking changes; declaring >=7.2.4 compatibility while the package is now built and tested exclusively against 8.0.1 means a consumer pinned to 7.2.4 gets a clean install, clean typecheck and green deploy yet may fail at module load or on a live call if

🟠 MEDIUM sandbox peer floor left below the adopted agent-runtime line's own requirement — package.json

package.json:579 publishes agent-runtime ">=0.132.13" (resolves to 0.135.3), but agent-runtime@0.135.3 declares peer '@tangle-network/sandbox': '>=0.27.0 <0.28.0' (pnpm-lock.yaml:1897). package.json:581 still publishes sandbox ">=0.21.1". Both are optional peers (peerDependenciesMeta:612,616), so pnpm says nothing on an unmet OPTIONAL peer — the documented failure mode in AGENTS.md /peer-floors. A consumer on sandbox 0.21.x-0.26.x who adopts this shell + agent-runtime passes their own floor audit against these published floors and breaks only on a live wire call. This is the same defect class the PR's own commit message fixed for the interface cap ('no published set installable for this shell') — the fix was applied to the interface edge but not the runtime->sandbox edge. Fix: raise the sa

🟠 MEDIUM sandbox-ui peer floor on @tangle-network/brand raised to ^1.5.0 but brand stays pinned at 1.4.0 — pnpm-lock.yaml

The bump sandbox-ui 0.100.1 -> 0.103.1 raises its peerDependencies '@tangle-network/brand' from ^1.4.0 (base, satisfied) to ^1.5.0 (line 1919), which is NOT optional (absent from peerDependenciesMeta at lines 1932-1954). The importer still resolves brand to 1.4.0 (lines 57-59: specifier 1.4.0, version 1.4.0), and package.json leaves '@tangle-network/brand' at 1.4.0 (devDep) and '>=1.4.0' (peer floor, [line 580](https://github.com/tangle-network/a

🟡 LOW 0.x peer floors left behind their dev-dependency bumps — package.json

sandbox dev 0.21.1 → 0.27.0 (six 0.x minors, each minor-locked/breaking per this repo's own satisfiesRange rule), agent-runtime 0.133.0 → 0.135.3, sandbox-ui 0.100.1 → 0.103.1, agent-profile-materialize 0.14.0 → 0.15.1 — yet their peerDependency floors remain >=0.21.1, >=0.132.13, >=0.100.1, >=0.14.0 respectively. The repo's documentation cites a concrete instance of this class biting (sandbox 0.15.1's {command}→{executable,args} spawn body failing at runtime on a live wire call). The floors are likely conservative minimums and this PR changes no src/ code, so the risk is latent, but the floors should be re-confirmed against the new tested versions for consistency with the agent-interface bump.

🟡 LOW Breaking peer-floor migration ships inside a patch chore with no consumer-migration note — package.json

The agent-interface peer floor jumps from '>=0.47.0 <0.48.0' to '>=0.53.0 <0.54.0' — five minor lines. Per this repo's own /peer-floors docs, a caret on 0.x is MINOR-LOCKED, so every consumer pinned to ^0.47 (and any consumer whose agent-runtime/knowledge/sandbox-ui still target the old interface line) must change pins to install this shell at all. The change itself is correct and justified (agent-knowledge 8.x and agent-runtime 0.135.x both require interface >=0.53.0, verified in the lockfile), and the commit message documents the rationale, but it is a breaking published-contract change riding a 0.45.60 patch chore. Recommend the release note calls out the interface migration for fleet consumers (tax/legal/gtm/insurance).

🟡 LOW sandbox-ui 0.103.1 bump raises its brand peer to ^1.5.0 while brand dev and floor stay at 1.4.0 — package.json

sandbox-ui@0.103.1 declares peer '@tangle-network/brand': '^1.5.0' (pnpm-lock.yaml:1919), up from ^1.4.0 in 0.100.1. This PR bumps sandbox-ui to 0.103.1 (package.json:530) but leaves brand dev at 1.4.0 (package.json:528) and the published brand floor at >=1.4.0 (package.json:580), so the shell's own tree now resolves brand 1.4.0 against sandbox-ui 0.103.1 (lock:6314) — an unmet peer — and the published floor set permits consumers to install the same broken pair. Note ui@11.5.0 already carried this same mismatch pre-PR (old lockfile required brand ^1.5.0 at line 1976) and was tolerated, which is why this is low; but the sandbox-ui edge is newly introduced here. Fix: bump brand dev

🟡 LOW sandbox-ui 0.103.1 brand peer floor ^1.5.0 resolved against brand 1.4.0 — pnpm-lock.yaml

sandbox-ui@0.103.1 declares peerDependencies['@tangle-network/brand'] = '^1.5.0' (line 1919), but its snapshot (line 6325) resolves the peer to @tangle-network/brand@1.4.0 -- the only brand version in the lockfile, pinned exactly in package.json. semver.satisfies('1.4.0','^1.5.0') is false. The previous sandbox-ui 0.100.1 declared '^1.4.0' (satisfied), so this PR actively introduces the out-of-range edge. pnpm 11.17.0 (packageManager pin) accepts it silently: a from-scratch offline re-resolution and a full offline install emitted no unmet-peer warnings, and the lock

🟡 LOW No in-range patch assertion for the 0.53 line — src/peer-floors/check.test.ts

The lifted assertions pin only the floor (0.52.0 out / 0.53.0 in) and ceiling (0.54.0 out), not a patch inside the range such as 0.53.9. If the range were accidentally tightened to an exact '0.53.0' pin, all three existing assertions would still pass while the published floor lost patch flexibility. The load-bearing 0.53.0 assertion does catch both upward and downward drift of the declared range, so impact is limited to a coverage gap that the '>=0.42.1 <0.44.0' compound-range block already demonstrates the pattern for. Fix: add expect(satisfiesRange('0.53.9', range!)).toBe(true).

---

_{tangletools · 2026-08-16T05:59:47Z · trace}

Superseded by re-review — no blocking findings on latest commit.

[tangletools]

✅ Approved — 9 non-blocking findings — a30eafce

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

Full immutable report for this review: trace

Summary comment for this run: full summary

---

_{tangletools · 2026-08-16T05:59:47Z · immutable trace}

[drewstone]

Findings addressed — new head c435f3f

Every finding from the three reviews at a30eafce is fixed or answered below. The core criticism was correct and shared by all three reviewers: the PR raised the interface floor but left the sibling floors on the 0.47 cohort, so the published floor set was not co-installable. Two commits close it.

🔴 HIGH (blocking) — create-agent-app templates still pinned the 0.47 cohort

Fixed in d32749f. Both templates move to the 0.53 cohort: create-agent-app/template/_package.json and template-chat/_package.json now pin interface 0.53.0, runtime 0.135.3, sandbox 0.27.0, eval 0.145.15, integrations 0.53.54.

Proof — the repo's own generated-project gate, the exact command from the finding:

$ npx vitest run tests/create-agent-app.test.ts tests/create-agent-app-chat.test.ts
 Test Files  2 passed (2)
      Tests  12 passed (12)

🟠 MEDIUM — sibling peer floors jointly unsatisfiable with the new interface floor

(Reported three times: blocking-summary MEDIUM, value audit against-grain, usefulness audit problem-fit.)

Fixed in c435f3f. Confirmed the mechanism against the registry before changing anything — each floor-minimum peers interface <0.48.0, so the intersection with >=0.53.0 <0.54.0 was empty:

floor	was	peers interface	now
agent-knowledge	>=7.2.4	>=0.47.0 <0.48.0	>=8.0.1
agent-runtime	>=0.132.13	>=0.47.0 <0.48.0	>=0.135.3
agent-profile-materialize	>=0.14.0	>=0.46.0 <0.48.0	>=0.15.1
sandbox-ui	>=0.100.1	>=0.36.0 <0.48.0	>=0.103.1
sandbox	>=0.21.1	— (runtime 0.135.3 peers >=0.27.0 <0.28.0)	>=0.27.0
agent-eval	>=0.145.2	— (runtime 0.135.3 peers >=0.145.15 <0.146.0)	>=0.145.15

This is the shape #432 used: it moved the sibling floors in the same commit as the interface floor. This PR had not, which is exactly what the reviewers caught.

🟠 MEDIUM ×2 — sandbox-ui 0.103.1 requires brand ^1.5.0, tree resolved 1.4.0

Fixed in c435f3f: brand dev pin 1.4.0 → 1.5.0, floor >=1.4.0 → >=1.5.0. brand 1.5.0 is published.

$ pnpm peers check
No peer dependency issues found

This also clears the 🟡 LOW pre-existing violation — ui@11.5.0 wants brand ^1.5.0 too, so the tree's unmet-peer output is now empty rather than naming two packages, as that finding predicted.

🟠 MEDIUM — agent-knowledge 8.0.1 pushes /knowledge-loop e2e past the 5s timeout

Confirmed, then fixed in c435f3f. I reproduced it first: 2 of 4 runs failed, matching the reported ~50%.

Root cause is a mis-specified budget, not a hung loop. The four cases in that block drive the real agent-knowledge loop against a KB on disk; measured idle cost is 936ms / 729ms / 160ms / 122ms against vitest's 5s default unit budget. They fail on host load, not on the loop — this box was running at load average ~42 during the failing batch.

Fix: declare the budget explicitly ({ timeout: 30_000 } on the e2e describe), matching how the repo's other e2e tests declare theirs (create-agent-app-chat.test.ts uses 180_000). Proof under deliberate load — 12 CPU busy-loops on a 32-core box, the condition that produced the original failures:

 Tests  9 passed (9)
 Tests  9 passed (9)
 Tests  9 passed (9)

🟠 MEDIUM — interface floor breaks consumers on 0.47.x–0.52.x

Intended, and the reason this PR exists. As the finding itself concludes, the move is required: runtime 0.135.3, knowledge 8.0.1 and eval 0.145.15 all peer interface >=0.53.0 <0.54.0, so the old <0.48.0 cap had an empty intersection with the current sibling cohort — no consumer could build a peer-consistent tree at all. This is a forced coordinated migration; it fails closed at peer resolution rather than silently, which is what /peer-floors exists to guarantee.

🟠 MEDIUM — breaking peer-floor move ships in the patch channel (0.45.61)

Answered, not changed. Three reasons, on the record:

1. Precedent. chore(deps): move onto the agent-interface 0.47 line #432 (2dc375e) made the directly analogous move — interface >=0.42.1 <0.44.0 → >=0.47.0 <0.48.0, plus every sibling floor — and shipped as 0.45.51, a patch. The convention this PR follows is the repo's own most recent instance of the same change.
2. Fails closed. The failure mode is a peer-resolution error at install, not a silent runtime break — the class /peer-floors is built to make loud.
3. Scope. publish.yml auto mode always computes patch+1; changing the channel for contract moves is a repo-wide release-policy change, not something to smuggle into a pin bump.

Worth its own issue if we want floor moves to force a minor. Flagging rather than silently ignoring.

Remaining 🟡 LOW findings

All fixed by the floor table above: agent-eval >=0.145.15, knowledge >=8.0.1, sandbox >=0.27.0, brand >=1.5.0.

Verification on c435f3f

$ pnpm run typecheck          # tsc --noEmit, clean
$ pnpm peers check            # No peer dependency issues found
$ npx vitest run src/peer-floors/check.test.ts
      Tests  14 passed (14)
$ pnpm test
 Test Files  321 passed | 6 skipped (327)
      Tests  5459 passed | 10 skipped (5469)

One note for reproducers: the generated chat app's suite needs the better-sqlite3 native binding built (pnpm rebuild better-sqlite3). Without it the failure is Could not locate the bindings file, which is environmental and unrelated to these pins.

[drewstone]

@tangletools review now

[tangletools]

✅ Auto-approved drewstone PR — c435f3fc

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:16:33Z}

[drewstone]

@tangletools review now

[tangletools]

✅ Auto-approved drewstone PR — c435f3fc

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:30:12Z}

[tangletools]

🟢 Value Audit — sound

Verdict	sound
Coverage	2 of 2 lenses (value, usefulness)
Concerns	1 (1 weak-concern)
Heuristic	0.0s
Duplication	0.0s
Interrogation	206.0s (2 bridge agents)
Total	206.0s

💰 Value — sound

Bumps the first-party dependency cohort to the interface-0.53 lockstep line (pins, peer floors, and template manifests) and updates the peer-floors self-audit range — a correct, mechanical, in-grain deps sync.

• What it does: Moves five+ first-party packages onto one co-installable cohort. In package.json it raises devDependency pins (agent-interface 0.47.0→0.53.0, knowledge 7.2.4→8.0.1, runtime 0.133.0→0.135.3, sandbox 0.21.1→0.27.0, sandbox-ui 0.100.1→0.103.1, eval 0.145.3→0.145.15, materialize 0.14.0→0.15.1, brand 1.4.0→1.5.0) and matching peerDependency floors (agent-interface's floor becomes >=0.53.0 <0.54.0). T
• Goals it achieves: Achieves a coherent, jointly-installable published set: the sibling peer floors on the 0.47 cohort each peered agent-interface <0.48.0, so honoring the new interface floor at those floors' minimums produced a peer-inconsistent tree (documented in commit c435f3f's body). Raising every floor to the cohort member that peers the 0.53 line restores lockstep, and the create-agent-app templates track t
• Assessment: Good, in the grain of the repo. The change respects the repo's documented invariants: engines stay peerDependencies with floors (never bundled deps), interface stays a minor-locked 0.x range (matching the caret-on-0.x-is-minor-locked rule the peer-floors module encodes), and templates are pinned to agent-app's own floors — exactly what tests/create-agent-app.test.ts:117 and create-agent-app-chat
• Better / existing approach: None — this is a version-synchronization chore with no architecture to reinvent. I checked for an existing mechanism: the repo already owns the machinery that constrains and validates this exact change (src/peer-floors/check.test.ts self-audit at line 108, the drift-gate tests in tests/create-agent-app.test.ts and tests/create-agent-app-chat.test.ts, and the /peer-floors doc). There is no renovate
• 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 — sound

A coherent, internally-consistent dependency lockstep that moves the shell's interface peer floor, templates, lockfile, and self-audit test onto the interface-0.53 cohort in one stroke.

• Integration: Fully wired and enforced by the repo's own gate: package.json devDeps (interface 0.53.0 / knowledge 8.0.1 / runtime 0.135.3 / sandbox 0.27.0 / sandbox-ui 0.103.1 / brand 1.5.0 / profile-materialize 0.15.1) match the peerDependencies floors (interface >=0.53.0 <0.54.0, runtime >=0.135.3, sandbox >=0.27.0, etc.), the pnpm-lock.yaml resolves exactly one version of each (confirmed by grep of the lockf
• Fit with existing patterns: Follows the established lockstep pattern exactly — a version move is one commit set touching devDeps pins + peerDependencies floors + template pins + the self-audit assertion together, matching AGENTS.md invariant 1 (engine as peer with a published floor, never bundled). No competing or duplicated mechanism; the shell still imports only types + the loop entry from agent-knowledge (src/knowledge-lo
• Real-world viability: Co-installability is proven by the lockfile's single-version resolution rather than asserted. The agent-knowledge 7.x→8.x major is exercised against the real on-disk loop by tests/knowledge-loop.test.ts, and the accompanying 5s→30s timeout bump (tests/knowledge-loop.test.ts:121-125) is a genuine robustness fix — the comment documents that these cases cost ~0.7-1.0s idle and only flake under host l
• 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

🟡 Knowledge-loop test-timeout bump rides inside a deps PR [proportion] ``

tests/knowledge-loop.test.ts adds a 30s timeout to the e2e KB-loop describe. It is out of scope for a dependency sync, but it is small, explained inline (real KB loop costs ~0.7-1.0s/case, vitest 5s default leaves no headroom), and plausibly needed because agent-knowledge moved 7.2.4→8.0.1. Reviewer note only; no alternative mechanism needed and nothing to reuse.

---

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 · 20260816T064304Z}