chore: release v0.7.98

[vanceingalls]

What

Stable release v0.7.98, a single fix: failed renders now record whether the parallel drawElement router was active (#3081).

de_parallel_router was on 95.4% of render_complete events and 0.83% of render_error. That was an ordering bug, not renders failing before capture — capture_mode survives failures at 98.6%. The routing state was recorded before syncCapturePlan resolved it, so the only assignment that can produce "reverted" never reached observability.

Why it matters

This is a prerequisite for ramping #2840. The per-install circuit breaker only arms on a revert, which requires the render to finish and self-detect — it cannot catch a crash, hang, or OOM. Those are exactly the failure modes a percentage ramp exists to bound, on exactly the profiles with no trial coverage (≤4 CPUs at 8.18% of eligible renders, Docker at 3.99%). Ramping while 99.2% of failures carried no routing state would have meant being blind to what the ramp is watching for.

Acceptance check after publish

de_parallel_router coverage on render_error should climb from 0.83% toward the ~95% seen on completions as installs adopt. The orchestrator change has no unit seam — updateCaptureObservability is a closure inside the render function — so that telemetry movement is the real verification, not the test suite.

Note on numbering

0.7.97 published normally and does not contain this fix — #3081 merged after that release commit. This picks up only a3d13e267.

🤖 Generated with Claude Code

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
hyperframes	🟢 Ready	View Preview	Aug 7, 2026, 6:38 AM

💡 Tip: Enable Workflows to automatically generate PRs for you.