Version Packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@tangle-network/agent-interface@0.25.0

Minor Changes

• a26171f: Bind the exact benchmark grader implementation to every candidate execution plan.

@tangle-network/agent-core@0.4.10

Patch Changes

• Updated dependencies [a26171f]
  • @tangle-network/agent-interface@0.25.0

@tangle-network/agent-provider-cli-bridge@0.2.12

Patch Changes

• Updated dependencies [a26171f]
  • @tangle-network/agent-interface@0.25.0

@tangle-network/agent-provider-computesdk@0.2.12

Patch Changes

• Updated dependencies [a26171f]
  • @tangle-network/agent-interface@0.25.0

@tangle-network/agent-provider-daytona@0.2.12

Patch Changes

• Updated dependencies [a26171f]
  • @tangle-network/agent-interface@0.25.0

@tangle-network/agent-provider-e2b@0.2.12

Patch Changes

• Updated dependencies [a26171f]
  • @tangle-network/agent-interface@0.25.0

@tangle-network/agent-provider-tangle@0.2.12

Patch Changes

• Updated dependencies [a26171f]
  • @tangle-network/agent-interface@0.25.0

@tangle-network/agent-provider-testkit@0.2.12

Patch Changes

• Updated dependencies [a26171f]
  • @tangle-network/agent-interface@0.25.0

[tangletools]

✅ Auto-approved GitHub Actions PR — 06c68803

This PR was opened by trusted GitHub Actions automation.
The full PR reviewer audit still runs separately and will publish findings if it detects issues.

_{tangletools · auto-approval · reason: github_actions_author · 2026-07-11T07:15:36Z}

[tangletools]

🟢 Value Audit — sound

Verdict	sound
Concerns	1 (1 weak-concern)
Heuristic	0.0s
Duplication	0.0s
Interrogation	180.6s (2 bridge agents)
Total	180.6s

💰 Value — sound

A mechanical Changesets release commit that bumps versions and CHANGELOGs to publish the already-merged grader-binding feature (a26171f); correct and in the grain of the repo.

• What it does: Commit 06c6880 contains zero functional code: it deletes the consumed changeset .changeset/frozen-graders-plan.md, bumps @tangle-network/agent-interface 0.24.0→0.25.0 (minor, for the feature) and the seven dependents 0.2.11→0.2.12 / agent-core 0.4.9→0.4.10 (patch, dependency update), and appends matching CHANGELOG entries. Verified via git show 06c6880 --stat (17 files, only package.json + C
• Goals it achieves: Cut an npm release so the merged feature 'bind benchmark graders to execution plans' (a26171f, PR #43) becomes installable. Semver is coherent: the package with the behavior change gets a minor bump; packages that only re-declare the dependency get patch bumps.
• Assessment: Good on its merits. It is the standard, established Changesets workflow — git log shows identical 'Version Packages' commits at #42, #40, #34, #29. Version increment choices match the nature of each change, dependent bumps are consistent, and the consumed changeset is correctly removed. Nothing fights the codebase.
• Better / existing approach: none — this is the right approach. Searched: .changeset/*.md (glob), git log --oneline -15, git show 06c6880 --stat. The repo already uses Changesets for exactly this; no alternate release mechanism exists to reuse, and there is no functional code here to redesign. The substantive change lives in a26171f (already merged), not in this PR.
• Model: opencode/kimi-for-coding/k2p7
• Bridge attempts: 1

🎯 Usefulness — sound

Binds the exact benchmark grader implementation to the execution plan — closing the last provenance gap in the candidate-receipt integrity chain — reusing the grader shape already proven in the benchmark-result schema.

• Integration: The grader field is now part of agentCandidateExecutionPlanMaterialSchema (agent-candidate-execution-plan-schema.ts:340-346) and its TS interface AgentCandidateExecutionPlanMaterialV1 (agent-candidate.ts:523-528). It is reachable via the existing receipt cross-validator at agent-candidate-receipt-schema.ts:154, which already reads receipt.executionPlan.material to enforce that the plan pins
• Fit with existing patterns: Follows the codebase's established pinning grain exactly. Every artifact the candidate touches is frozen in the plan before execution — bundle, base commit, instruction bytes, container image, resolved model, network allowlist. Before this change the grader was the one artifact referenced at outcome time but NOT committed in the plan, meaning an evaluator could swap grader implementations after se
• Real-world viability: The artifact reuses agentCandidateArtifactRefSchema (sha256 + byteLength + s3/ipfs locator with credential and path-safety refines), so the locator and integrity mechanics are already battle-tested across bundle, workspace, and container refs. .strict() on the object prevents extra fields. One minor asymmetry: the outcome schema enforces grader.artifact.byteLength > 0 (outcome-schema.ts:34
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 1

🎯 Usefulness Audit

🟡 Plan grader lacks the zero-byte guard the outcome grader has [robustness] ``

agent-candidate-outcome-schema.ts:348-354 rejects a zero-byte grader artifact ('pinned grader artifact must contain executable grader bytes'), but the execution-plan grader block at agent-candidate-execution-plan-schema.ts:340-346 has no equivalent superRefine. A plan could therefore be built and signed pinning a grader that can never produce a valid benchmark result, failing only later at outcome validation. Add a matching byteLength === 0 check in the plan's superRefine for symmetry and earl

---

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 · 20260711T072023Z}

[tangletools]

✅ No Blockers — 06c68803

Review health 100/100 · Reviewer score 95/100 · Confidence 95/100 · 0 findings (none)

	opencode-kimi	glm	deepseek	aggregate
Readiness	95	95	95	95
Confidence	95	95	95	95
Correctness	95	95	95	95
Security	95	95	95	95
Testing	95	95	95	95
Architecture	95	95	95	95

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.

No findings.

---

_{tangletools · 2026-07-11T07:25:06Z · trace}

[tangletools]

✅ Clean — 06c68803

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-07-11T07:25:06Z · immutable trace}