chore(release): bump agent-runtime to 0.94.5

[drewstone]

Publishes the CRLF-safe Codex prompt evidence fix from #536.

Checks:

• pnpm run build
• pnpm run docs:api
• pnpm run docs:freshness
• git diff --check

[tangletools]

✅ Auto-approved drewstone PR — faed1bfb

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-12T22:47:27Z}

[tangletools]

✅ Auto-approved drewstone PR — faed1bfb

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-12T22:47:55Z}

[tangletools]

🟢 Value Audit — sound

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

💰 Value — sound

Routine 0.94.4→0.94.5 patch release of the CRLF-safe Codex prompt evidence fix (#536), following the repo's established one-fix-per-release cadence.

• What it does: Bumps @tangle-network/agent-runtime from 0.94.4 to 0.94.5 in package.json and regenerates the two version-pinned docs (docs/api/primitive-catalog.md, docs/canonical-api.md) so the freshness gate stays green. No source-code behavior changes — it publishes commit eee0487 (#536, the CRLF-safe Codex prompt evidence fix) to the registry.
• Goals it achieves: Ship the #536 fix to consumers as a published npm version and keep the generated API docs' version pins in sync so pnpm docs:freshness does not fail CI. Better state: downstream consumers can pull the CRLF fix by version bump alone.
• Assessment: Good change, fully in the grain of the repo. git log shows the identical pattern four times running (0.94.2 #529, 0.94.3 #531, 0.94.4 #535, 0.94.5 here) — one functional commit, then a chore(release) bump that also regenerates the docs version pins. Minimal, mechanical, reversible.
• Better / existing approach: none — this is the right approach. Searched for an existing release script/automation: the repo already has scripts/gen-primitive-catalog.mjs + pnpm docs:api + pnpm docs:freshness doing the doc regeneration, and the version-bump-and-release flow is the established convention here. Nothing to reuse or extend; this PR already uses it.
• 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 release chore bumping 0.94.4→0.94.5 to publish the already-merged CRLF Codex fix from #536, following the repo's established tag-triggered publish pattern.

• Integration: The version bump is the trigger for the publish workflow (.github/workflows/publish.yml:6-7 fires on refs/tags/v*); the tag/version lock step at publish.yml:45-55 consumes package.json's version directly. Consumers of @tangle-network/agent-runtime reach 0.94.5 via npm once the matching v0.94.5 tag is pushed. No new surface to wire — this only republishes existing, already-integrated code.
• Fit with existing patterns: Matches the established release cadence exactly: prior bumps 0.94.2/3/4 (#529/#531/#535) used the identical chore(release): bump agent-runtime to X.Y.Z pattern with the same three-file footprint (package.json + the two version-pinned docs). The docs/api/primitive-catalog.md and docs/canonical-api.md version pins are required by the pnpm docs:freshness gate mentioned in the PR body, so updating
• Real-world viability: Version bumps have no runtime behavior of their own; the underlying fix (#536) ships its own tests (tests/mcp/local-harness.test.ts, +85 lines per git show eee0487). The publish gate runs lint/test/build/typecheck/verify:package before npm publish, so a broken state would fail CI rather than ship.
• 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 · 20260712T224858Z}

[tangletools]

⚠️ Review Incomplete — faed1bfb

At least one required reviewer lane failed closed. No approval or request-changes review was published. This is a reviewer run failure, not a PR quality score.

Trigger a fresh review on the current PR head.

_{tangletools · 2026-07-12T22:49:50Z}