DEPRECATED: Bridge SDK (moved into Adom Bridge)

@@ -109,9 +109,18 @@ ab's uninstaller enumerates the installed bridges and calls each bridge's `<pref 4. **A long verb is POLLABLE and says so:** return `{started:true, jobId, statusVerb:"<prefix>_progress", progress:{...}}` and keep the same block flowing from the poll verb until `done`/`failed`. **Never block silently past your own declared timeout.** 5. **Terminal frames carry ACTUALS:** `percent:100` + real `elapsedSec` + `measured:{phase, seconds, startKind}` (feeds your history and ab's logs). On failure, name the phase it died in + `failedSteps` so the bar turns red in the right place instead of hanging at 38%. -**ab's side of the deal — what is TRUE TODAY, and what is still owed.** ab forwards `progress` VERBATIM: no parsing, no per-app logic (same generic-renderer rule as the status chip and `stepShot`), so whatever you emit reaches the caller unaltered. **Shipped and verified:** the block survives the round trip through `adom-bridge` to a cloud caller, and the **web-control demo page renders it** (bar + step label, and it consumes a `stepShot` frame verbatim as the step's evidence thumbnail). **NOT yet shipped, and you should not design around it:** ab's OWN window does not yet render a progress bar or a live status line from your `progress` block, and ab does not yet report its own slow operations in this shape. The SSE `/command/stream` progress you may have seen is ab's RECIPE-STEP runner (step N of M, `usuallySec`), not your block being streamed.+**ab's side of the deal - what is TRUE TODAY.** ab forwards `progress` VERBATIM: no parsing, no per-app logic (same generic-renderer rule as the status chip and `stepShot`), so whatever you emit reaches the caller unaltered. **Shipped and verified:** the block survives the round trip through `adom-bridge` to a cloud caller; the **web-control demo page renders it** (bar + step label, and it consumes a `stepShot` frame verbatim as the step's evidence thumbnail); and **as of ab 2.0.67 ab's OWN window renders it too** - a live status line at the bottom of the ab window showing `<bridge> <verb>: <stepLabel>` with percent, time left, and cold/warm. Verified live against kicad 0.9.196. **Still owed:** ab does not yet report its OWN slow operations in this shape. The SSE `/command/stream` progress you may have seen is ab's RECIPE-STEP runner (step N of M, `usuallySec`), not your block being streamed. -So today the contract buys you three real things — the caller gets honest percent/ETA/cold-warm, the demo surface draws it, and a UI can be built against a stable shape — but a bar inside ab's own window is owed, not delivered. This paragraph previously claimed ab already rendered it everywhere; that was aspirational and wrong, and it is corrected here rather than left for an author to discover.+**What that means for you: emit BOTH shapes, because they drive different halves of the bar.** ab reads two, matched on shape alone (never on a bridge name):++1. **The terminal frame** - a top-level `progress` on the slow verb's own response. This is the one `progressContract` already promises, and it always arrives at `percent:100`: by the time the verb answers, the work is done. It is a completion receipt, so on its own it paints a bar that flashes "done" and never moves.+2. **The live poll** - an **`active[]`** array of those same blocks, one per in-flight phase, returned by your fast progress verb (`<prefix>_progress`) while the slow work is still running. **This is the one that makes the bar MOVE**, because a caller polling once a second produces a stream of rising frames. An empty `active[]` means idle and draws nothing.++If you only ship #1, the user watching your 40-second verb sees nothing until it finishes. When several phases are in flight ab draws the **least complete** one, since the honest answer to "how far along is this?" is bounded by the slowest phase.++**`blockedBy` is the one that earns the most trust.** When the work is parked on a HUMAN - a modal dialog, a login, a save prompt - set it, and ab's status line says "waiting on you: `<what>`", turns the fill amber, stops advancing it, and keeps the bar up instead of timing it out. A bar that keeps sliding while nothing can happen without the user is worse than no bar at all.++Why this matters more than a demo page: **ab is the only process that sees every bridge response**, so a cloud AI polling from a container now drives a bar on the USER'S screen. The person at the keyboard finally sees what a remote agent is doing to their machine - something no container-side UI can provide.  The demo verbs already prove the shape works (`<prefix>_demo_progress` streams percent/stepLabel/elapsedSec/estimatedSec and the web-control page draws a live bar from it). The gap was that ONLY the demo verb did it. Instrument the rest: `*_start` (the cold-start case that triggered this), `*_show_*`, install/export/build. 

@@ -109,9 +109,18 @@ ab's uninstaller enumerates the installed bridges and calls each bridge's `<pref 4. **A long verb is POLLABLE and says so:** return `{started:true, jobId, statusVerb:"<prefix>_progress", progress:{...}}` and keep the same block flowing from the poll verb until `done`/`failed`. **Never block silently past your own declared timeout.** 5. **Terminal frames carry ACTUALS:** `percent:100` + real `elapsedSec` + `measured:{phase, seconds, startKind}` (feeds your history and ab's logs). On failure, name the phase it died in + `failedSteps` so the bar turns red in the right place instead of hanging at 38%. -**ab's side of the deal — what is TRUE TODAY, and what is still owed.** ab forwards `progress` VERBATIM: no parsing, no per-app logic (same generic-renderer rule as the status chip and `stepShot`), so whatever you emit reaches the caller unaltered. **Shipped and verified:** the block survives the round trip through `adom-bridge` to a cloud caller, and the **web-control demo page renders it** (bar + step label, and it consumes a `stepShot` frame verbatim as the step's evidence thumbnail). **NOT yet shipped, and you should not design around it:** ab's OWN window does not yet render a progress bar or a live status line from your `progress` block, and ab does not yet report its own slow operations in this shape. The SSE `/command/stream` progress you may have seen is ab's RECIPE-STEP runner (step N of M, `usuallySec`), not your block being streamed.+**ab's side of the deal - what is TRUE TODAY.** ab forwards `progress` VERBATIM: no parsing, no per-app logic (same generic-renderer rule as the status chip and `stepShot`), so whatever you emit reaches the caller unaltered. **Shipped and verified:** the block survives the round trip through `adom-bridge` to a cloud caller; the **web-control demo page renders it** (bar + step label, and it consumes a `stepShot` frame verbatim as the step's evidence thumbnail); and **as of ab 2.0.67 ab's OWN window renders it too** - a live status line at the bottom of the ab window showing `<bridge> <verb>: <stepLabel>` with percent, time left, and cold/warm. Verified live against kicad 0.9.196. **Still owed:** ab does not yet report its OWN slow operations in this shape. The SSE `/command/stream` progress you may have seen is ab's RECIPE-STEP runner (step N of M, `usuallySec`), not your block being streamed. -So today the contract buys you three real things — the caller gets honest percent/ETA/cold-warm, the demo surface draws it, and a UI can be built against a stable shape — but a bar inside ab's own window is owed, not delivered. This paragraph previously claimed ab already rendered it everywhere; that was aspirational and wrong, and it is corrected here rather than left for an author to discover.+**What that means for you: emit BOTH shapes, because they drive different halves of the bar.** ab reads two, matched on shape alone (never on a bridge name):++1. **The terminal frame** - a top-level `progress` on the slow verb's own response. This is the one `progressContract` already promises, and it always arrives at `percent:100`: by the time the verb answers, the work is done. It is a completion receipt, so on its own it paints a bar that flashes "done" and never moves.+2. **The live poll** - an **`active[]`** array of those same blocks, one per in-flight phase, returned by your fast progress verb (`<prefix>_progress`) while the slow work is still running. **This is the one that makes the bar MOVE**, because a caller polling once a second produces a stream of rising frames. An empty `active[]` means idle and draws nothing.++If you only ship #1, the user watching your 40-second verb sees nothing until it finishes. When several phases are in flight ab draws the **least complete** one, since the honest answer to "how far along is this?" is bounded by the slowest phase.++**`blockedBy` is the one that earns the most trust.** When the work is parked on a HUMAN - a modal dialog, a login, a save prompt - set it, and ab's status line says "waiting on you: `<what>`", turns the fill amber, stops advancing it, and keeps the bar up instead of timing it out. A bar that keeps sliding while nothing can happen without the user is worse than no bar at all.++Why this matters more than a demo page: **ab is the only process that sees every bridge response**, so a cloud AI polling from a container now drives a bar on the USER'S screen. The person at the keyboard finally sees what a remote agent is doing to their machine - something no container-side UI can provide.  The demo verbs already prove the shape works (`<prefix>_demo_progress` streams percent/stepLabel/elapsedSec/estimatedSec and the web-control page draws a live bar from it). The gap was that ONLY the demo verb did it. Instrument the rest: `*_start` (the cold-start case that triggered this), `*_show_*`, install/export/build. 

@@ -109,9 +109,18 @@ ab's uninstaller enumerates the installed bridges and calls each bridge's `<pref 4. **A long verb is POLLABLE and says so:** return `{started:true, jobId, statusVerb:"<prefix>_progress", progress:{...}}` and keep the same block flowing from the poll verb until `done`/`failed`. **Never block silently past your own declared timeout.** 5. **Terminal frames carry ACTUALS:** `percent:100` + real `elapsedSec` + `measured:{phase, seconds, startKind}` (feeds your history and ab's logs). On failure, name the phase it died in + `failedSteps` so the bar turns red in the right place instead of hanging at 38%. -**ab's side of the deal — what is TRUE TODAY, and what is still owed.** ab forwards `progress` VERBATIM: no parsing, no per-app logic (same generic-renderer rule as the status chip and `stepShot`), so whatever you emit reaches the caller unaltered. **Shipped and verified:** the block survives the round trip through `adom-bridge` to a cloud caller, and the **web-control demo page renders it** (bar + step label, and it consumes a `stepShot` frame verbatim as the step's evidence thumbnail). **NOT yet shipped, and you should not design around it:** ab's OWN window does not yet render a progress bar or a live status line from your `progress` block, and ab does not yet report its own slow operations in this shape. The SSE `/command/stream` progress you may have seen is ab's RECIPE-STEP runner (step N of M, `usuallySec`), not your block being streamed.+**ab's side of the deal - what is TRUE TODAY.** ab forwards `progress` VERBATIM: no parsing, no per-app logic (same generic-renderer rule as the status chip and `stepShot`), so whatever you emit reaches the caller unaltered. **Shipped and verified:** the block survives the round trip through `adom-bridge` to a cloud caller; the **web-control demo page renders it** (bar + step label, and it consumes a `stepShot` frame verbatim as the step's evidence thumbnail); and **as of ab 2.0.67 ab's OWN window renders it too** - a live status line at the bottom of the ab window showing `<bridge> <verb>: <stepLabel>` with percent, time left, and cold/warm. Verified live against kicad 0.9.196. **Still owed:** ab does not yet report its OWN slow operations in this shape. The SSE `/command/stream` progress you may have seen is ab's RECIPE-STEP runner (step N of M, `usuallySec`), not your block being streamed. -So today the contract buys you three real things — the caller gets honest percent/ETA/cold-warm, the demo surface draws it, and a UI can be built against a stable shape — but a bar inside ab's own window is owed, not delivered. This paragraph previously claimed ab already rendered it everywhere; that was aspirational and wrong, and it is corrected here rather than left for an author to discover.+**What that means for you: emit BOTH shapes, because they drive different halves of the bar.** ab reads two, matched on shape alone (never on a bridge name):++1. **The terminal frame** - a top-level `progress` on the slow verb's own response. This is the one `progressContract` already promises, and it always arrives at `percent:100`: by the time the verb answers, the work is done. It is a completion receipt, so on its own it paints a bar that flashes "done" and never moves.+2. **The live poll** - an **`active[]`** array of those same blocks, one per in-flight phase, returned by your fast progress verb (`<prefix>_progress`) while the slow work is still running. **This is the one that makes the bar MOVE**, because a caller polling once a second produces a stream of rising frames. An empty `active[]` means idle and draws nothing.++If you only ship #1, the user watching your 40-second verb sees nothing until it finishes. When several phases are in flight ab draws the **least complete** one, since the honest answer to "how far along is this?" is bounded by the slowest phase.++**`blockedBy` is the one that earns the most trust.** When the work is parked on a HUMAN - a modal dialog, a login, a save prompt - set it, and ab's status line says "waiting on you: `<what>`", turns the fill amber, stops advancing it, and keeps the bar up instead of timing it out. A bar that keeps sliding while nothing can happen without the user is worse than no bar at all.++Why this matters more than a demo page: **ab is the only process that sees every bridge response**, so a cloud AI polling from a container now drives a bar on the USER'S screen. The person at the keyboard finally sees what a remote agent is doing to their machine - something no container-side UI can provide.  The demo verbs already prove the shape works (`<prefix>_demo_progress` streams percent/stepLabel/elapsedSec/estimatedSec and the web-control page draws a live bar from it). The gap was that ONLY the demo verb did it. Instrument the rest: `*_start` (the cold-start case that triggered this), `*_show_*`, install/export/build.