chore(release): 0.133.5

[drewstone]

Ships #820 — cascaded aborts preserve their reason, so a child that dies from a parent-scope abort no longer reports the generic execution aborted.

Measured motivation: on one 281-run fleet, 65 of 146 children settled down (45%) and execution aborted was the largest single bucket, none of them diagnosable from the journal because the reason was discarded in transit.

Prepared with pnpm run release:prepare 0.133.5; no hand edits.

🤖 Generated with Claude Code

[tangletools]

✅ Auto-approved drewstone PR — 52d042b9

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-08-13T11:01:55Z}

[tangletools]

🟢 Value Audit — sound

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

💰 Value — sound

Pure mechanical release bump 0.133.4→0.133.5 via the repo's own prepare script; ships the already-merged abort-reason fix (#820).

• What it does: Bumps package.json version 0.133.4→0.133.5 and regenerates the three CI-gated artifacts that embed the runtime version: the two testing fixtures (digests + runtimeVersion/runId/recordDigest fields) and the docs version banner (docs/canonical-api.md, docs/api/primitive-catalog.md). No source-code or behavior change in this PR — the cascaded-abort-reason fix it ships is commit 2201968, already on ma
• Goals it achieves: Cut a release that includes #820 (cascaded aborts forward their reason so worker down-records say the real cause instead of the generic 'execution aborted'). The bookkeeping keeps package.json, the checked-in fixtures, and the docs version banner in lockstep so CI freshness gates stay green and the publish tag matches the code.
• Assessment: Good change, fully in the grain of the codebase. scripts/prepare-release.mjs is purpose-built for exactly this: it rewrites the version textually (preserving formatting), updates the hand-written version banner, and runs generate:testing-fixture + docs:api. Three CI gates verify the version-bearing artifacts (prepare-release.mjs:5-11), so a hand-edit bump fails and the release does not publish. Th
• Better / existing approach: none — this is the right approach. The repo already has the dedicated release-mechanism (scripts/prepare-release.mjs) and the PR is its exact output; nothing to reuse or extend. Searched: git log on package.json, prepare-release.mjs source, and the diff of all touched files.
• Model: opencode/zai-coding-plan/glm-5.2
• Bridge attempts: 2
• Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error

🎯 Usefulness — sound

A clean mechanical 0.133.5 release: version bump + regenerated version-bound artifacts via the repo's own release:prepare script, with all five version surfaces consistent and CI gates enforcing them; the functional fix it ships (#820) already landed separately with tests.

• Integration: Fully wired. Every version-bearing artifact is regenerated in lockstep — zero stale 0.133.4 references remain (rg confirms). The three artifact classes the prepare script owns (fixtures via tests/testing-fixture.test.ts + check:testing-fixture, primitive-catalog.md via docs:api, canonical-api.md banner) are all CI-gated inside verify:package, so inconsistency would block publish. The publish workf
• Fit with existing patterns: Matches the established release pattern exactly — identical shape to #819 (0.133.4). The prepare script (scripts/prepare-release.mjs) is the documented, dedicated tool for this; no competing or hand-edit path. Conventional Commit scope and the release:prepare flow are the repo's grain.
• Real-world viability: Holds up: the change is deterministic digest/version regeneration with no runtime behavior of its own, so there is no happy-path-only risk in the bump. The underlying functional change (#820, commit 2201968) carries 5 new tests covering string reasons, either-side firing, already-aborted-before-linking, Error unwrapping, and the placeholder case — suite reported 2587/2593.
• 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 · 20260813T110618Z}