← Commit history

Publish 1.0.133

John Lauer ·7aadf0cb8d ·1mo ago ·parent a3dac6c
3 files changed +7−6
package.json+1−1
@@ -1,6 +1,6 @@ {   "slug": "kicad-bridge",-  "version": "1.0.132",+  "version": "1.0.133",   "type": "app",   "description": "Skills for your container so your AI knows how to drive the KiCad bridge. The bridge runtime itself is the release zip; Adom Bridge loads that.",   "tags": [
page.json+1−1
@@ -4,7 +4,7 @@   "slug": "kicad-bridge",   "title": "KiCad - the KiCad Bridge",   "brief": "Reference implementation of the KiCad bridge: multi-instance Python server, forward path via kicad-cli, reverse path via in-process plugin. Most complex of the three bundled bridges.",-  "version": "1.0.132",+  "version": "1.0.133",   "tags": [     "kicad",     "pcb",
skills/kicad-bridge-publish/SKILL.md+5−4
@@ -215,8 +215,9 @@ with that page's skills package (adom/wiki#170). The zip stays here.   evidence is the sha256 in the manifest. A rebuild changes zip timestamps and therefore the hash. - A dashboard poll can respawn the old bridge process between `bridge_kill` and your unpack.   Read `kicad_status.bridgeVersion` after `bridge_resume`; if it is still the old one, kill again.-- The dev pin does not stop an explicit `bridge_install` (ab 2.1.66, adom-bridge#159). On a shared-  box tell the other threads, or expect your staged build to vanish.+- From ab 2.1.70 the dev pin also refuses an explicit `bridge_install` (errorCode dev_pinned, force+  included; adom-bridge#159). On an older ab it does not: tell the other threads, or expect your+  staged build to vanish. - After a build, push the non-runtime source too (tests/, demo/, tools/, RELEASE_NOTES.md): the   release tool pushes only what the zip ships. @@ -236,8 +237,8 @@ with that page's skills package (adom/wiki#170). The zip stays here.   with the reason): a `kicad-release-backup-*` copy next to the real cache showed up in bridge_list   as the kicad bridge with the wrong version. Back up to `%LOCALAPPDATA%/Adom Bridge/bridge-backups/`,   which is also ab's documented rule now.-- **Staging chain that works:** `bridge_dev_mode on` (note: does not stop an explicit-  bridge_install, adom-bridge#159), `bridge_kill {confirm:true}` (a dashboard poll can respawn+- **Staging chain that works:** `bridge_dev_mode on` (from ab 2.1.70 this also blocks explicit+  bridge_install; unpin before the canonical install), `bridge_kill {confirm:true}` (a dashboard poll can respawn   the old process; check bridgeVersion after resume and kill again if stale), PowerShell   Copy-Item backup + Expand-Archive -Force, write `.bridge-version`, `bridge_resume`, then test,   then `build_release.py <ver> --publish --reuse-zip`, then unpin and `bridge_install` from the