← Commit history

SDK correction: ab does NOT yet render a progress bar in its own window - the previous text claimed it did

John Lauer ·4adc170098 ·2mo ago ·parent c0e3cda
3 files changed +9−3
README.md+3−1
@@ -109,7 +109,9 @@ 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:** ab forwards `progress` VERBATIM - no parsing, no per-app logic (same generic-renderer rule as the status chip and `stepShot`) - and renders a real bar + ETA + step label for every slow verb, not just the demo tour. ab also reports its OWN slow operations in this shape, so the contract is symmetric rather than something only bridges owe.+**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.++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.  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. 
SKILL.md+3−1
@@ -109,7 +109,9 @@ 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:** ab forwards `progress` VERBATIM - no parsing, no per-app logic (same generic-renderer rule as the status chip and `stepShot`) - and renders a real bar + ETA + step label for every slow verb, not just the demo tour. ab also reports its OWN slow operations in this shape, so the contract is symmetric rather than something only bridges owe.+**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.++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.  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. 
bridges-SDK.md+3−1
@@ -109,7 +109,9 @@ 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:** ab forwards `progress` VERBATIM - no parsing, no per-app logic (same generic-renderer rule as the status chip and `stepShot`) - and renders a real bar + ETA + step label for every slow verb, not just the demo tour. ab also reports its OWN slow operations in this shape, so the contract is symmetric rather than something only bridges owe.+**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.++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.  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.