chore(release): 0.90.1

[drewstone]

Summary

Release 0.90.1 from current main.

Included since 0.90.0:

• fix the code-improvement proposer so Claude runs with supported CLI flags and zero-candidate code paths can propose
• scope permission bypass to explicitly isolated worktrees
• add structuralRollout and rollout-policy improvement surfaces
• add withIntelligence typed-diff integration

Verification

• pnpm typecheck
• pnpm test (1,316 passed, 2 skipped across 134 files)
• pnpm build
• pnpm lint
• pnpm docs:check
• pnpm verify:package
• clean merge-tree against origin/main

This is an additive and bug-fix release. No fleet-wide dependency bump is required.

[tangletools]

✅ Auto-approved drewstone PR — 3614f7e4

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-09T21:25:45Z}

[tangletools]

🟢 Value Audit — sound

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

💰 Value — sound

Pure release version stamp 0.90.0→0.90.1 (package.json + auto-generated docs version strings); the substantive fixes/features already landed in #501–#504, so this is the idiomatic cut-release commit with nothing to reinvent.

• What it does: Bumps the package version from 0.90.0 to 0.90.1 in package.json:3 and refreshes the matching version references in docs/api/primitive-catalog.md and docs/canonical-api.md (git diff HEAD~1 --stat: 3 files, 3 insertions, 3 deletions). No runtime code changes.
• Goals it achieves: Tag a publishable 0.90.1 release that packages the already-merged work since 0.90.0: the code-surface proposer headless-flag fix + zero-candidate guard (dcb36a8), structuralRollout + rollout-policy surface (81a534d), and withIntelligence typed-diff unification (394a13c).
• Assessment: Good on its merits. It is exactly the established release pattern — the immediately prior commit e26c161 is 'chore(release): 0.90.0' — so it follows the repo's grain and matches the documented additive-and-bug-fix, no-fleet-bump claim.
• Better / existing approach: none — this is the right approach; a version stamp commit is the standard way this repo cuts a release (cf. e26c161), and there is no existing automation it bypasses or duplicates.
• Model: opencode/kimi-for-coding/k2p7
• Bridge attempts: 1

🎯 Usefulness — sound

A coherent release-cut: bumps package.json to 0.90.1 and updates the two doc version pins that the docs:freshness CI gate requires to match, fully wired into the tag-driven OIDC publish workflow.

• Integration: Fully reachable. The version field is consumed by .github/workflows/publish.yml:42-51 (tag/version lock check) and publish.yml:81-92 (OIDC npm publish, idempotent). A v0.90.1 tag will trigger publish; consumers depending on @tangle-network/agent-runtime reach it via the registry. No dead surface.
• Fit with existing patterns: Matches the established release pattern exactly — prior release e26c161 (0.90.0) made the same package.json + doc-pin bump. The doc edits are mandated by scripts/check-docs-freshness.mjs:139-156 (CLASS 1 gate), so a package.json-only commit would fail docs:check; updating both is correct, not redundant.
• Real-world viability: Robust on the real path: publish verifies tag==package.json version, and the publish step checks the registry and skips if 0.90.1 already exists (idempotent re-run). Version pins are consistent repo-wide (grep for 0.90.0 returns nothing), so CI gates (docs:check, freshness) hold.
• 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 · 20260709T212715Z}

[tangletools]

✅ No Blockers — 3614f7e4

Review health 100/100 · Reviewer score 95/100 · Confidence 75/100 · 0 findings (none)

	opencode-kimi	glm	deepseek	aggregate
Readiness	95	95	95	95
Confidence	75	75	75	75
Correctness	95	95	95	95
Security	95	95	95	95
Testing	95	95	95	95
Architecture	95	95	95	95

Reviewer score is advisory once the run is complete and the verdict has no blockers.

Full multi-shot audit completed 3/3 planned shots over 3 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 3/3 planned shots over 3 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 3/3 planned shots over 3 changed files. Global verifier still owns final merge decision.

No findings.

---

_{tangletools · 2026-07-09T21:28:10Z · trace}

[tangletools]

✅ Clean — 3614f7e4

Full multi-shot audit completed 3/3 planned shots over 3 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 3/3 planned shots over 3 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 3/3 planned shots over 3 changed files. Global verifier still owns final merge decision.

Full immutable report for this review: trace

Summary comment for this run: full summary

---

_{tangletools · 2026-07-09T21:28:10Z · immutable trace}