fix(bench): restore trusted publishing metadata

[drewstone]

What

• add the public Git repository identity npm requires for trusted publishing
• identify bench as the monorepo package directory
• advance the failed 0.2.0 release to 0.2.1

Why

Both agent-bench 0.1.1 and 0.2.0 reached npm publish with GitHub token-mint permission, then failed ENEEDAUTH. The package omitted repository.url. Current npm trusted-publishing documentation requires repository.url to exactly match the GitHub repository, and npm package metadata supports repository.directory for monorepo packages.

The workflow already uses a GitHub-hosted runner, id-token write permission, and npm 11. No token authentication or workflow change is needed.

Checks

• pnpm test: 21/21 TypeScript package tests plus Pier bridge
• pnpm run typecheck:public
• pnpm run verify:package: clean consumer installed agent-bench 0.2.1 with agent-runtime 0.92.1
• packed package contains the exact repository URL and bench directory
• agent-bench-v0.2.1 matches package version
• npm registry confirms 0.2.1 is not published

[tangletools]

✅ Auto-approved drewstone PR — 53436801

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.

_{tangletools · auto-approval · reason: drewstone_author · 2026-07-11T17:11:28Z}

[tangletools]

✅ No Blockers — 53436801

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

deepseek: Correctness 95 · Security 95 · Testing 95 · Architecture 95

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

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

No findings.

---

_{tangletools · 2026-07-11T17:13:47Z · trace}

[tangletools]

✅ Clean — 53436801

Full multi-shot audit completed 1/1 planned shots over 1 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-11T17:13:47Z · immutable trace}

[tangletools]

🟢 Value Audit — sound

Verdict	sound
Concerns	0 (none)
Heuristic	0.0s
Duplication	0.0s
Interrogation	56.0s (2 bridge agents)
Total	56.0s

💰 Value — sound

Adds the npm repository metadata that trusted-publishing provenance requires and bumps the failed 0.2.0 to 0.2.1 — a minimal, correct fix that unblocks the bench publish pipeline.

• What it does: Three edits to bench/package.json: (1) version 0.2.0→0.2.1; (2) adds repository.type=git + repository.url=git+https://github.com/tangle-network/agent-runtime.git; (3) adds repository.directory=bench to identify it as the monorepo subpackage path. No code or workflow changes.
• Goals it achieves: Unblocks @tangle-network/agent-bench npm publishing under OIDC trusted publishing. npm's provenance check matches the package's repository.url against the GitHub repo minting the OIDC token; without it the publish reaches the registry with token-mint permission then fails ENEEDAUTH (the exact failure on 0.1.1 and 0.2.0). The version bump is required because 0.2.0 already hit the registry and npm f
• Assessment: Correct and in-grain. The root package.json:6-9 already uses the identical repository.url pattern, so bench is being brought into line with the repo's own convention rather than introducing a new one. The object form with url+directory is the right npm idiom for a monorepo subpackage (the 'github:owner/repo' shorthand can't express directory). No workflow edit is needed — publish.yml already sets
• Better / existing approach: none — this is the right approach. Checked: (a) npm trusted-publishing docs require repository.url to match the Trusted Publisher's GitHub repo, and repository.directory is the documented monorepo field — both are used here; (b) the root package.json already models this exact field, so bench is extending the existing pattern, not reinventing; (c) no shared metadata helper exists in the repo (only
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 2
• Bridge warning: opencode/kimi-for-coding/k2p7: bridge stream ended without value-audit content

🎯 Usefulness — sound

Adds the repository.url + directory metadata that npm OIDC trusted publishing requires, unblocking the already-wired publish-agent-bench workflow; follows the exact pattern the root package already ships.

• Integration: Directly consumed by .github/workflows/publish.yml:137-171 (publish-agent-bench job), which runs npm publish --provenance with id-token:write. npm trusted publishing requires repository.url to match the GitHub repo; without it, 0.1.1 and 0.2.0 both failed ENEEDAUTH. The tag/version lock at publish.yml:127-135 will validate agent-bench-v0.2.1 against the bumped version. The caller exists today an
• Fit with existing patterns: Follows the established monorepo convention exactly. Root package.json:6-9 already ships the identical repository block (git+https://github.com/tangle-network/agent-runtime.git); bench adds only the standard npm directory: "bench" field for subdirectory packages. Root package publishes successfully (at 0.92.1), proving the pattern works with this workflow.
• Real-world viability: URL matches the actual GitHub repo the workflow checks out from. Version bump 0.2.0→0.2.1 is the correct response to a failed publish (npm forbids republishing the same version). The publish job is idempotent (publish.yml:167 guards with npm view before publishing), so re-runs are safe. No runtime/edge-case surface — this is static metadata consumed by npm's registry.
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 1

No concerns — sound change, no better or existing approach found. ✅

---

What this audit checks

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

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

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

_{value-audit · 20260711T171410Z}