DEPRECATED: Bridge SDK (moved into Adom Bridge)

@@ -109,7 +109,11 @@ 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.** 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.+**ab's side of the deal - what is TRUE TODAY, and WHERE your block gets drawn.** 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, percent/ETA, cold-vs-warm, a dimmed fill when your `confidence` is not `measured`, an amber stalled bar on `blockedBy`, and your `stepShot` frame verbatim as the step's evidence thumbnail.++**The renderer is the WEB, and that is the point.** Your progress is drawn where a person is actually looking: the web-control demo page (`http://127.0.0.1:24681`) is the REFERENCE IMPLEMENTATION, and it exists so wiki.adom.inc can render your bar the same way for real users. **ab's own window deliberately draws NO progress bar** - it is a background agent's console the user barely opens, so a bar there would be effort spent where nobody looks. (ab 2.0.66/67 shipped one by mistake; 2.0.68 removed it. ab still emits the block internally, so a future surface can pick it up with no ab release.) Design for the web surface, not for ab's window.++**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.  **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): 

@@ -109,7 +109,11 @@ 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.** 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.+**ab's side of the deal - what is TRUE TODAY, and WHERE your block gets drawn.** 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, percent/ETA, cold-vs-warm, a dimmed fill when your `confidence` is not `measured`, an amber stalled bar on `blockedBy`, and your `stepShot` frame verbatim as the step's evidence thumbnail.++**The renderer is the WEB, and that is the point.** Your progress is drawn where a person is actually looking: the web-control demo page (`http://127.0.0.1:24681`) is the REFERENCE IMPLEMENTATION, and it exists so wiki.adom.inc can render your bar the same way for real users. **ab's own window deliberately draws NO progress bar** - it is a background agent's console the user barely opens, so a bar there would be effort spent where nobody looks. (ab 2.0.66/67 shipped one by mistake; 2.0.68 removed it. ab still emits the block internally, so a future surface can pick it up with no ab release.) Design for the web surface, not for ab's window.++**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.  **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): 

@@ -109,7 +109,11 @@ 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.** 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.+**ab's side of the deal - what is TRUE TODAY, and WHERE your block gets drawn.** 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, percent/ETA, cold-vs-warm, a dimmed fill when your `confidence` is not `measured`, an amber stalled bar on `blockedBy`, and your `stepShot` frame verbatim as the step's evidence thumbnail.++**The renderer is the WEB, and that is the point.** Your progress is drawn where a person is actually looking: the web-control demo page (`http://127.0.0.1:24681`) is the REFERENCE IMPLEMENTATION, and it exists so wiki.adom.inc can render your bar the same way for real users. **ab's own window deliberately draws NO progress bar** - it is a background agent's console the user barely opens, so a bar there would be effort spent where nobody looks. (ab 2.0.66/67 shipped one by mistake; 2.0.68 removed it. ab still emits the block internally, so a future surface can pick it up with no ab release.) Design for the web surface, not for ab's window.++**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.  **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):