DEPRECATED: Bridge SDK (moved into Adom Bridge)

@@ -216,6 +216,51 @@ This is REQUIRED rather than recommended for one reason: **the failure is invisi  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. +## ⭐ REQUIRED: PRUNE WHAT YOU WRITE - a bridge owns its own scratch directory (kicad-bridge#40, 2026-08-20)++If your bridge writes a file per operation - screenshots, exports, logs, temp+renders - **you must prune it.** ab will not, and should not: ab's janitor covers+ab's OWN directories, and a bridge's scratch space is the bridge's. ab deleting+files out of it would be ab reaching into storage it does not own.++This is a REQUIRED rule rather than advice because the failure is invisible until+it is large. Measured on one real box: a bridge writing captures per call had+accumulated **226 files / 37.5 MB**, growing, with nothing pruning it - and it+went unnoticed for months because nothing errors. Nobody sees a directory that+merely gets bigger.++**The retention shape that works** (from kicad-bridge 0.9.203, which is a good+default to copy rather than reinvent):++- an **age cap** (48h is a sane default for evidence captures),+- a **hard file ceiling** (300) as a backstop for a burst,+- **oldest-first** eviction over the ceiling - this one is load-bearing, because+  it guarantees an in-flight capture is never the file you delete,+- **rate-limited** (once per 10 minutes) so a burst of captures never pays for+  the sweep,+- and when you RENAME a directory, **drain the old one and remove it**, or every+  existing install keeps its orphans forever.++**Write under your own bridge cache**, next to the other bridges, not a+hand-rolled path:++```+%LOCALAPPDATA%\Adom Bridge\bridges-cache\<your-bridge>\screenshots\+```++Two traps worth naming, both hit in the wild:++- **Do not invent a top-level directory** like `C:\tmp\<something>`. It is+  outside every janitor, invisible to the user's mental model of where apps keep+  things, and it survives your uninstall.+- **Check the NAME is current.** A directory created under a retired product name+  keeps that name propagating long after the rename - and a user auditing their+  disk finds a folder for an app that no longer exists.++Unit-test the retention rule against a synthetic tree (aged-out removed, fresh+kept, legacy drained) rather than asserting it - the whole point is that nobody+will notice when it silently stops working.+ ## The rest of the SDK library  The SDK is a **skill library**, not one file, so you load only the phase you are in:

@@ -216,6 +216,51 @@ This is REQUIRED rather than recommended for one reason: **the failure is invisi  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. +## ⭐ REQUIRED: PRUNE WHAT YOU WRITE - a bridge owns its own scratch directory (kicad-bridge#40, 2026-08-20)++If your bridge writes a file per operation - screenshots, exports, logs, temp+renders - **you must prune it.** ab will not, and should not: ab's janitor covers+ab's OWN directories, and a bridge's scratch space is the bridge's. ab deleting+files out of it would be ab reaching into storage it does not own.++This is a REQUIRED rule rather than advice because the failure is invisible until+it is large. Measured on one real box: a bridge writing captures per call had+accumulated **226 files / 37.5 MB**, growing, with nothing pruning it - and it+went unnoticed for months because nothing errors. Nobody sees a directory that+merely gets bigger.++**The retention shape that works** (from kicad-bridge 0.9.203, which is a good+default to copy rather than reinvent):++- an **age cap** (48h is a sane default for evidence captures),+- a **hard file ceiling** (300) as a backstop for a burst,+- **oldest-first** eviction over the ceiling - this one is load-bearing, because+  it guarantees an in-flight capture is never the file you delete,+- **rate-limited** (once per 10 minutes) so a burst of captures never pays for+  the sweep,+- and when you RENAME a directory, **drain the old one and remove it**, or every+  existing install keeps its orphans forever.++**Write under your own bridge cache**, next to the other bridges, not a+hand-rolled path:++```+%LOCALAPPDATA%\Adom Bridge\bridges-cache\<your-bridge>\screenshots\+```++Two traps worth naming, both hit in the wild:++- **Do not invent a top-level directory** like `C:\tmp\<something>`. It is+  outside every janitor, invisible to the user's mental model of where apps keep+  things, and it survives your uninstall.+- **Check the NAME is current.** A directory created under a retired product name+  keeps that name propagating long after the rename - and a user auditing their+  disk finds a folder for an app that no longer exists.++Unit-test the retention rule against a synthetic tree (aged-out removed, fresh+kept, legacy drained) rather than asserting it - the whole point is that nobody+will notice when it silently stops working.+ ## The rest of the SDK library  The SDK is a **skill library**, not one file, so you load only the phase you are in:

@@ -216,6 +216,51 @@ This is REQUIRED rather than recommended for one reason: **the failure is invisi  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. +## ⭐ REQUIRED: PRUNE WHAT YOU WRITE - a bridge owns its own scratch directory (kicad-bridge#40, 2026-08-20)++If your bridge writes a file per operation - screenshots, exports, logs, temp+renders - **you must prune it.** ab will not, and should not: ab's janitor covers+ab's OWN directories, and a bridge's scratch space is the bridge's. ab deleting+files out of it would be ab reaching into storage it does not own.++This is a REQUIRED rule rather than advice because the failure is invisible until+it is large. Measured on one real box: a bridge writing captures per call had+accumulated **226 files / 37.5 MB**, growing, with nothing pruning it - and it+went unnoticed for months because nothing errors. Nobody sees a directory that+merely gets bigger.++**The retention shape that works** (from kicad-bridge 0.9.203, which is a good+default to copy rather than reinvent):++- an **age cap** (48h is a sane default for evidence captures),+- a **hard file ceiling** (300) as a backstop for a burst,+- **oldest-first** eviction over the ceiling - this one is load-bearing, because+  it guarantees an in-flight capture is never the file you delete,+- **rate-limited** (once per 10 minutes) so a burst of captures never pays for+  the sweep,+- and when you RENAME a directory, **drain the old one and remove it**, or every+  existing install keeps its orphans forever.++**Write under your own bridge cache**, next to the other bridges, not a+hand-rolled path:++```+%LOCALAPPDATA%\Adom Bridge\bridges-cache\<your-bridge>\screenshots\+```++Two traps worth naming, both hit in the wild:++- **Do not invent a top-level directory** like `C:\tmp\<something>`. It is+  outside every janitor, invisible to the user's mental model of where apps keep+  things, and it survives your uninstall.+- **Check the NAME is current.** A directory created under a retired product name+  keeps that name propagating long after the rename - and a user auditing their+  disk finds a folder for an app that no longer exists.++Unit-test the retention rule against a synthetic tree (aged-out removed, fresh+kept, legacy drained) rather than asserting it - the whole point is that nobody+will notice when it silently stops working.+ ## The rest of the SDK library  The SDK is a **skill library**, not one file, so you load only the phase you are in: