chore(release): bump agent-runtime to 0.94.2

[drewstone]

Publishes the merged reproducible Codex host-isolation fix.

• bumps package and canonical/generated API version pins to 0.94.2
• full local suite: 149/149 test files, 1,508 tests passed and 2 skipped
• lint, typecheck, build, package-export verification, and docs freshness passed
• release will be tagged only after this PR is green and merged

[tangletools]

✅ Auto-approved drewstone PR — 2d584c93

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-12T18:03:48Z}

[tangletools]

🟢 Value Audit — sound

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

💰 Value — sound

Routine patch release bump from 0.94.1 to 0.94.2, publishing the merged Codex host-isolation fix; mechanically updates package.json plus the two version-pinned docs that the freshness gate requires to match.

• What it does: Bumps the package version in package.json from 0.94.1 to 0.94.2 and regenerates the two docs that cite the version pin — docs/api/primitive-catalog.md (the GENERATED inventory header) and docs/canonical-api.md (the Version 0.94.x line). No source/code changes; the actual fix shipped in the prior commit a38460e (fix(codex): isolate reproducible worktree execution #528).
• Goals it achieves: Publish the merged reproducible Codex host-isolation fix as a consumable npm release. Keeps the version-pinned docs in sync with package.json so the docs:freshness CI gate (documented in docs/canonical-api.md header as failing CI if a version pin drifts) stays green.
• Assessment: Sound. This is the established release pattern in this repo: git log shows 5+ identical 'chore(release): bump agent-runtime to X.Y.Z' commits (c7a2b96, 358aa76, 1b1c3fd, ad5093e...), each touching exactly the same three files (package.json + the two version-referencing docs). The 0.94.1 release diff is byte-for-byte the same shape. Updating the generated docs is mandatory here, not optional — the
• Better / existing approach: none — this is the right approach. Verified the prior release commits (c7a2b96, 358aa76) follow the identical 3-file pattern, so this is not reinventing anything; it is the established release chore. The version pin in docs is required by the freshness gate, so it cannot be dropped or automated away differently.
• 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

A mechanical, correctly-scoped release cut (0.94.1→0.94.2) that publishes the already-merged #528 host-isolation fix via the package.json-driven OIDC publish flow; matches the established 0.94.x release pattern exactly.

• Integration: The version bump in package.json:3 is the trigger the release pipeline consumes: .github/workflows/publish.yml:83-93 runs npm publish --provenance reading the version straight from package.json, and idempotently skips if the version already exists on the registry. The two docs pins (docs/canonical-api.md:5, docs/api/primitive-catalog.md:10) are regenerated companions that keep the canonical API do
• Fit with existing patterns: Fits the established release pattern precisely. The immediately preceding release c7a2b96 (0.94.1, #527) touched the identical 3-file set (package.json + docs/canonical-api.md + docs/api/primitive-catalog.md) with the identical 'chore(release): bump agent-runtime to X' commit style. The 0.93.x→0.94.x release cadence (#518, #520, #523, #527, now this) shows a single, repeated, working release disci
• Real-world viability: The release mechanism is already proven across at least five consecutive patch releases on this same workflow; the only surface this PR changes is a version string, so the real-world risk is whatever the code in a38460e carries (out of scope for this audit per its own review pass), not the bump itself. The publish step is fail-safe (skips if version already on registry), and the docs are generated
• 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 · 20260712T180621Z}