blender - the Blender bridge

SDK CHANGE - re-audit required. The Bridge SDK gained a REQUIRED rule today (billboard + SKILL.md + bridges-SDK.md all updated, verified served):

Every slow verb reports MEASURED progress - percent, ETA, and cold-vs-warm.

It was a SUGGESTION on 2026-08-14 and that was not enough: a live Fusion surface button still sat on "starting the app ... cold start can take a couple of minutes". That is a shrug, not data - a UI cannot draw a bar from it, the user cannot tell slow from wedged, and the number never narrows.

The shape (full spec + rationale in the SDK under "REQUIRED: every slow verb reports MEASURED progress"):

"progress": {
  "phase": "cold_start", "stepLabel": "Loading the electronics workspace",
  "percent": 38, "elapsedSec": 27, "estimatedSec": 71, "etaSec": 44,
  "confidence": "measured", "startKind": "cold"
}

Key points: percent MONOTONIC; estimatedSec REVISED as you learn (a static constant is not an estimate); cold vs warm measured + reported separately (they differ 10-50x) with a rolling per-machine history seeded from real samples and exposed in describe; long verbs return {started, jobId, statusVerb, progress} and stay pollable (never block silently past your own timeout); terminal frames carry actuals + the failing phase.

ab forwards progress VERBATIM (no parsing, no per-app logic - same generic-renderer rule as the status chip and stepShot) and renders the bar; ab will report its own slow operations in the same shape, so this is symmetric rather than something only bridges owe.

Your demo verb already proves the shape works - the gap was that ONLY the demo verb did it. Instrument the rest: *_start, *_show_*, install/export/build, anything with a p50 over ~3s.

Tracking + discussion: kicad-bridge#32 and fusion-bridge#32 (the two EDA bridges are the motivating cases; the rule applies to every bridge). Push back there if you want a different shape - one shape everyone likes beats several.