chore(release): bump agent-runtime to 0.94.4

[drewstone]

Publishes the exact composed-prompt digest added in #534.

Checks:

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

[tangletools]

✅ Auto-approved drewstone PR — dca5d2ea

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:14:37Z}

[tangletools]

🟢 Value Audit — sound

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

💰 Value — sound

Standard patch-version bump to publish the composed-prompt digest from #534 — matches the repo's established release-commit pattern.

• What it does: Bumps version in package.json from 0.94.3 to 0.94.4 (package.json:3). No other files touched.
• Goals it achieves: Publishes the composed-prompt digest feature landed in #534 (commit 5f039c3) to npm under a new semver patch.
• Assessment: This is the repo's standard release pattern — git log shows identical chore(release): bump agent-runtime to 0.94.x commits at 0.94.1, 0.94.2, 0.94.3 (commits c7a2b96, f8d3182, 7817e94), each following a feat/fix with a version-bump release commit. The change is in grain and proportionate.
• Better / existing approach: none — this is the right approach. Searched git log for the release pattern; the bump-commit-after-feature cadence is established convention here.
• 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

Version bump 0.94.3→0.94.4 publishing the requestedPromptSha256 evidence field from #534, which is correctly wired into the existing Codex execution evidence pipeline and fills a real integrity gap (requested vs. rendered prompt).

• Integration: requestedPromptSha256 is computed in collectCodexExecutionEvidence (src/mcp/local-harness.ts:756), exposed on CodexExecutionEvidence (src/mcp/local-harness.ts:331), propagated through runWorktreeHarness into WorktreeHarnessResult (src/mcp/worktree-harness.ts:77,236), and consumed by the runtime supervisor executor (src/runtime/supervise/runtime.ts:1308; src/runtime/supervise/worktree-cli-executor.
• Fit with existing patterns: Matches the established evidence-digest pattern exactly: same interface, same collection site, same propagation path as effectivePromptSha256/nonPromptArgsSha256/controlledConfigSha256/executableSha256. It complements rather than competes — effectivePromptSha256 proves what Codex rendered, requestedPromptSha256 proves what was passed in, and tests assert they genuinely differ (tests/mcp/local-harn
• Real-world viability: SHA-256 of a local string with no concurrency surface. Optional on WorktreeHarnessResult (worktree-harness.ts:77) so stale/older harness results won't break consumers. Empty-prompt input yields a defined constant rather than crashing. Evidence collection is unconditional whenever the harness produces evidence (local-harness.ts:756).
• 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 · 20260712T221752Z}