app
DEPRECATED: Bridge SDK (moved into Adom Bridge)
Public Made by Adomby adom
Bridge SDK guide: bridge.json schema, kind:python/node/exe, hello-python + hello-rust reference templates, packaging + lifecycle commands.
← Commit history
SDK: the background envelope is scoped to a STEP, never an orchestration (REQUIRED) - with the measured 376s-armed / 485-890s-actual case that leaked focus
3 files changed
+15−3
README.md+5−1@@ -189,12 +189,16 @@ John's ruling on foreground etiquette (a window opens in the BACKGROUND by defau **`focusEvents` is blessed as the canonical name** (kicad's, unchanged) on the `<prefix>_state` verb: an append-only log of every focus change your bridge caused or observed, with a timestamp and a cause. An auditable quietness log is a real assert; "nobody complained" is not. fusion is adding it. -### ⛔ Never size a suppression envelope off an ESTIMATE - re-arm per step+### ⛔ REQUIRED: an envelope is scoped to a STEP, never to an orchestration fusion's lesson, and it is the one most likely to bite the next bridge, so it is a rule and not a footnote. fusion's tour armed ONE background-suppression envelope sized from an estimate of how long the run would take. Real runs blew through it - cold boots, dialog stalls - the guard expired mid-run, and a window escaped to the foreground. That was the exact foreground leak John caught live. An estimate cannot bound a step whose duration you do not control. **Re-arm the envelope per step or per operation**, so the guard's lifetime is always shorter than the thing it is guarding, and an overrun costs you a re-arm rather than a leak. This is the same reasoning as the measured-progress rule above: do not let a number you guessed become a thing the system depends on. +**Measured, not theoretical** (fusion, 2026-08-19): a tour armed for ~376s actually ran **485-890s**, and every step after the envelope expired silently reverted to foreground-stealing - it took John's focus while he was working in other threads. The fix is one line per step. **Nesting is refcounted, so re-arming costs nothing** - there is no efficiency argument for the single big envelope, only the illusion of tidiness.++This is REQUIRED rather than recommended for one reason: **the failure is invisible from inside your bridge.** Nothing errors, no log line fires, and you only learn about it when a human notices their window jumped. A rule whose violation is undetectable by its author has to be stated as a rule.+ Both existing shapes may be emitted together during a migration window (`windowEtiquette` plus the old key) so a pinned runner does not break, but the OLD keys are deprecated on sight and should be dropped once your consumers are on the new one. ## The rest of the SDK library
SKILL.md+5−1@@ -189,12 +189,16 @@ John's ruling on foreground etiquette (a window opens in the BACKGROUND by defau **`focusEvents` is blessed as the canonical name** (kicad's, unchanged) on the `<prefix>_state` verb: an append-only log of every focus change your bridge caused or observed, with a timestamp and a cause. An auditable quietness log is a real assert; "nobody complained" is not. fusion is adding it. -### ⛔ Never size a suppression envelope off an ESTIMATE - re-arm per step+### ⛔ REQUIRED: an envelope is scoped to a STEP, never to an orchestration fusion's lesson, and it is the one most likely to bite the next bridge, so it is a rule and not a footnote. fusion's tour armed ONE background-suppression envelope sized from an estimate of how long the run would take. Real runs blew through it - cold boots, dialog stalls - the guard expired mid-run, and a window escaped to the foreground. That was the exact foreground leak John caught live. An estimate cannot bound a step whose duration you do not control. **Re-arm the envelope per step or per operation**, so the guard's lifetime is always shorter than the thing it is guarding, and an overrun costs you a re-arm rather than a leak. This is the same reasoning as the measured-progress rule above: do not let a number you guessed become a thing the system depends on. +**Measured, not theoretical** (fusion, 2026-08-19): a tour armed for ~376s actually ran **485-890s**, and every step after the envelope expired silently reverted to foreground-stealing - it took John's focus while he was working in other threads. The fix is one line per step. **Nesting is refcounted, so re-arming costs nothing** - there is no efficiency argument for the single big envelope, only the illusion of tidiness.++This is REQUIRED rather than recommended for one reason: **the failure is invisible from inside your bridge.** Nothing errors, no log line fires, and you only learn about it when a human notices their window jumped. A rule whose violation is undetectable by its author has to be stated as a rule.+ Both existing shapes may be emitted together during a migration window (`windowEtiquette` plus the old key) so a pinned runner does not break, but the OLD keys are deprecated on sight and should be dropped once your consumers are on the new one. ## The rest of the SDK library
bridges-SDK.md+5−1@@ -189,12 +189,16 @@ John's ruling on foreground etiquette (a window opens in the BACKGROUND by defau **`focusEvents` is blessed as the canonical name** (kicad's, unchanged) on the `<prefix>_state` verb: an append-only log of every focus change your bridge caused or observed, with a timestamp and a cause. An auditable quietness log is a real assert; "nobody complained" is not. fusion is adding it. -### ⛔ Never size a suppression envelope off an ESTIMATE - re-arm per step+### ⛔ REQUIRED: an envelope is scoped to a STEP, never to an orchestration fusion's lesson, and it is the one most likely to bite the next bridge, so it is a rule and not a footnote. fusion's tour armed ONE background-suppression envelope sized from an estimate of how long the run would take. Real runs blew through it - cold boots, dialog stalls - the guard expired mid-run, and a window escaped to the foreground. That was the exact foreground leak John caught live. An estimate cannot bound a step whose duration you do not control. **Re-arm the envelope per step or per operation**, so the guard's lifetime is always shorter than the thing it is guarding, and an overrun costs you a re-arm rather than a leak. This is the same reasoning as the measured-progress rule above: do not let a number you guessed become a thing the system depends on. +**Measured, not theoretical** (fusion, 2026-08-19): a tour armed for ~376s actually ran **485-890s**, and every step after the envelope expired silently reverted to foreground-stealing - it took John's focus while he was working in other threads. The fix is one line per step. **Nesting is refcounted, so re-arming costs nothing** - there is no efficiency argument for the single big envelope, only the illusion of tidiness.++This is REQUIRED rather than recommended for one reason: **the failure is invisible from inside your bridge.** Nothing errors, no log line fires, and you only learn about it when a human notices their window jumped. A rule whose violation is undetectable by its author has to be stated as a rule.+ Both existing shapes may be emitted together during a migration window (`windowEtiquette` plus the old key) so a pinned runner does not break, but the OLD keys are deprecated on sight and should be dropped once your consumers are on the new one. ## The rest of the SDK library