chore(deps): update pnpm 10

[drewstone]

Problem

The repository pins pnpm 10.28.0 even though the maintained Node 20-compatible line has advanced. pnpm 11 requires Node 22.13 and would violate this package's Node 20 support.

Change

Pin pnpm 10.34.5, the newest release compatible with the declared Node range.

Proof

• corepack pnpm --version -> 10.34.5
• corepack pnpm install --lockfile-only --offline succeeds in 196 ms with no lockfile changes
• clean merge tree against current main

[tangletools]

✅ Auto-approved drewstone PR — 59a599e0

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-25T01:45:17Z}

[tangletools]

✅ No Blockers — 59a599e0

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

glm: 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-25T01:48:33Z · trace}

[tangletools]

✅ Clean — 59a599e0

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-25T01:48:33Z · immutable trace}

[tangletools]

🟢 Value Audit — sound

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

💰 Value — sound

Bumps the Corepack pnpm pin from 10.28.0 to 10.34.5 (latest Node 20-compatible release); trivial, correct, in-grain — ship.

• What it does: Updates the packageManager field in package.json:112 from pnpm@10.28.0 to pnpm@10.34.5. This is the Corepack pin that determines which pnpm version installs/locks the repo. No other files change.
• Goals it achieves: Stay on the newest patch of the maintained pnpm 10 line without breaking the declared Node >=20.19.0 support (engines at package.json:109). pnpm 11 would require Node 22.13 and break the Node 20 floor, so the goal is a safe refresh within the compatible major. The lockfile is unaffected per the PR's --lockfile-only --offline proof.
• Assessment: Good change on its merits. It's the idiomatic mechanism (the packageManager Corepack field is the only correct way to pin pnpm), it's a one-line diff, it stays within the Node-20-compatible major, and it matches the repo's established chore(deps) refresh cadence visible in recent history (3430440 TypeScript 6, d5e7878 integrations, 1d07c89 optimizer bridge). No risk of scope creep, no fighting
• Better / existing approach: none — this is the right approach. Searched for alternative pnpm pinning: there is no .npmrc, pnpm-workspace.yaml, or .nvmrc in the repo — the packageManager field is the sole and canonical Corepack mechanism. git log -p --follow -- package.json shows this field has always been the place pnpm is pinned, so the change extends the existing pattern rather than inventing one.
• 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

Routine, correct patch bump of the corepack pnpm pin within the Node-20-compatible pnpm 10 line; consumed directly by every CI job.

• Integration: Fully reachable. pnpm/action-setup@v4 with no version input auto-detects from package.json:112 packageManager, so ci.yml (jobs ci + official-optimizers) and publish.yml (jobs verify + publish-npm) all run the pinned 10.34.5. Local devs hit the same value via corepack. This field IS the activation surface; nothing else needs to change.
• Fit with existing patterns: Fits the established pattern exactly — packageManager is the corepack-standard pin and the repo already uses it; no competing version source (.nvmrc/.npmrc/version input) exists. Grep confirmed package.json:112 is the only pnpm-version declaration. Staying on pnpm 10 rather than jumping to 11 is the right grain given engines.node floor of 20.19.0.
• Real-world viability: Holds up: it is a patch bump within a locked minor line (10.28→10.34), lockfileVersion 9.0 unchanged, so dependency resolution and the frozen-lockfile CI installs are unaffected. No new error paths, concurrency, or edge-input surface introduced by a package-manager self-version pin.
• 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 · 20260725T014845Z}