chore(release): agent-runtime 0.79.3

[drewstone]

Summary

• bump @tangle-network/agent-runtime to 0.79.3
• refresh the generated primitive catalog version pin
• keep canonical API docs in sync

Verification

• pnpm typecheck
• pnpm test (119 files, 1155 passed, 2 skipped)
• pnpm lint
• pnpm run docs:check
• pnpm run verify:package
• pnpm build

[tangletools]

🟢 Value Audit — sound

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

💰 Value — sound

Routine patch release 0.79.2→0.79.3: version bump plus the two doc files whose freshness gate fails CI if the pin drifts.

• What it does: Bumps @tangle-network/agent-runtime from 0.79.2 to 0.79.3 in package.json:1, regenerates docs/api/primitive-catalog.md (the GENERATED primitive inventory, which embeds the source version in its header), and updates the 'Version 0.79.x' pin in docs/canonical-api.md:4. No source-code behavior changes — purely the release plumbing.
• Goals it achieves: Cut a patch release that picks up the commits landed since 0.79.2 (notably feat(runtime): run bridge workers in isolated worktrees 9c100e0, the proposer-profile optimization 9c0fc48, and supervisor hardening 4b8568f) so consumers can depend on a published 0.79.3. The doc updates are not cosmetic: docs/canonical-api.md:3 documents that pnpm docs:freshness FAILS CI if the version pin or generated
• Assessment: Good change, built in the grain of the repo. The commit message chore(release): agent-runtime 0.79.3 matches the established release-commit convention (see 77eefff chore(release): 0.79.0, 089c800 0.78.0, 9a4481f 0.77.0, 6c8fdaf 0.73.0). The three-file shape (package.json + generated catalog + hand-curated version pin) is exactly what the docs:freshness gate demands and matches prior rele
• Better / existing approach: none — this is the right approach. Verified the doc updates are load-bearing by reading docs/canonical-api.md:3 (the freshness-gate contract) and confirmed the release-commit pattern against git log --grep='release'. A version bump cannot be done more simply than bumping the version and regenerating the two artifacts that cite 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

Standard SemVer patch release cut (0.79.2→0.79.3) that regenerates the two version-pinned docs via the repo's own gen+freshness tooling — follows the established chore(release) cadence exactly.

• Integration: This is the package itself; @tangle-network/agent-runtime is the published npm artifact consumed across the Tangle agent fleet. The version bump is the release artifact (tags v0.78.0–v0.79.2 exist; v0.79.3 is the next in cadence). It cuts a release that includes the just-merged feat in PR #406 (bridge workers in isolated worktrees). Maximally reachable by definition.
• Fit with existing patterns: Matches the established pattern exactly: 5+ prior commits use the same chore(release): <version> convention (77eefff 0.79.0, 089c800 0.78.0, 9a4481f 0.77.0, 5dcfe45 0.71.0, 6c8fdaf 0.73.0). Doc regeneration flows through scripts/gen-primitive-catalog.mjs and is gated by scripts/check-docs-freshness.mjs (package.json:91-93) — the repo's own machinery, not a competing pattern.
• Real-world viability: A version-string change plus two mechanical 0.79.2→0.79.3 replacements in generated/pinned docs. The freshness gate (pnpm docs:check = regen + git diff --exit-code + freshness check) would fail CI if the catalog drifted from source, so the doc edits cannot silently fall out of sync. No concurrency/error-path surface — it is a release metadata commit.
• 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 · 20260628T194200Z}