chore(release): bump agent-runtime to 0.94.1

[drewstone]

Summary

• release the reproducible Codex worktree execution merged in feat(codex): add reproducible worktree execution #522
• advance package and generated documentation version pins to 0.94.1

Verification

• pnpm run build
• pnpm run docs:check
• pnpm run typecheck
• pnpm run verify:package
• clean merge-tree against current origin/main
• confirmed 0.94.0 is live on npm at gitHead 358aa76128fc9bc7d1b0e687f5ee15f0f0503653 before opening this patch release

[tangletools]

✅ Auto-approved drewstone PR — c6d4d956

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-12T03:20:23Z}

[tangletools]

🟢 Value Audit — sound

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

💰 Value — sound

Clean 3-line patch release (0.94.0 → 0.94.1) that bumps package.json plus its two version-pinned generated docs in lockstep, following the repo's established release chore convention.

• What it does: Bumps the @tangle-network/agent-runtime version from 0.94.0 to 0.94.1 in package.json:4 and updates the two version references in the generated companion docs (docs/api/primitive-catalog.md:10, docs/canonical-api.md:5). No code, type, dependency, or lockfile changes.
• Goals it achieves: Publish a patch release for the reproducible Codex worktree execution merged in #522 (commit 3e29bbe), keeping the published npm package, the generated primitive-catalog version stamp, and the canonical-api 'Version X' header in sync so the docs:freshness CI gate stays green.
• Assessment: Textbook patch release. The diff is exactly the three version pins the freshness gate requires — nothing more, nothing less. It follows the identical shape as the five preceding chore(release) commits (358aa76, 1b1c3fd, ad5093e, cfe92fc, 4229f80) and is even tighter than 0.94.0 (no lockfile churn). Both doc files declare themselves GENERATED/hand-curated spine with version pins, so updating them i
• Better / existing approach: none — this is the right approach. Searches run: git show 358aa76 confirms the prior release used the same 3-file pattern; git log --oneline | rg chore\(release\) confirms 6+ identical release commits in recent history; the doc headers at docs/api/primitive-catalog.md:10 and docs/canonical-api.md:5 both state the version pin is enforced by pnpm docs:freshness, so regenerating-and-committing
• 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

Clean patch-version bump (0.94.0→0.94.1) releasing the merged #522 worktree feature via the repo's standard release pattern, with correctly regenerated docs and no stale version references.

• Integration: Directly reachable: publish.yml reads package.json#version (lines 88-93, 165-170) and OIDC-publishes @tangle-network/agent-runtime to npm gated on tag/version match; consumers depend on this package across the Tangle substrate fleet. This bump is the trigger that ships #522 to the registry.
• Fit with existing patterns: Follows the established release pattern precisely — identical file set (package.json + docs/api/primitive-catalog.md + docs/canonical-api.md) and commit-message convention as the four prior release commits (0.93.1, 0.93.2, 0.94.0). No competing release mechanism exists.
• Real-world viability: A mechanical version pin + doc regeneration; the substantive code shipped and was tested in #522 (175-line worktree-cli-executor test, 283-line local-harness test delta). No new logic here, so happy/error/edge behavior is owned by that earlier merge. Version consistency verified: grep confirms no lingering 0.94.0 references.
• 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 · 20260712T032259Z}