Fusion - the Fusion 360 Bridge

@@ -1,51 +0,0 @@-----name: fusion-bridge-dev-description: How to develop, version, and PUBLISH the Adom Desktop Fusion 360 bridge — where the source canonically lives, and the rule to ALWAYS publish to the wiki AND push the GitHub backup on every change. Read before editing/shipping the fusion bridge. Trigger words — fusion bridge dev, publish fusion bridge, fusion bridge repo, where does the fusion bridge live, ship fusion bridge, bump fusion bridge, adom-desktop-fusion-bridge.------# Fusion bridge — dev + publish workflow--## Canonical source = the wiki page (the ONE source of truth)-**`https://wiki.adom.inc/adom/adom-desktop-fusion-bridge`** (owner `adom`, public). A wiki-page IS a git repo; this is THE main repo for the bridge. AD installs the bridge from here-(its manifest + zip). Every version ships here.--- Local working clone: `~/project/adom-desktop-fusion-bridge`.-- Files on the page: `bridge.json`, `BRIDGE_VERSION`, `README.md`, `SKILL.md`, `aps.py`,-  `server.py`, handlers/addin, the `adom-bridge-fusion-manifest.json` + version zips-  (`adom-bridge-fusion-v<ver>.zip`), `adom-bridge-fusion-source.tar.gz`, and-  `adom-bridge-fusion.bundle` (portable full git history).--## GitHub backup — ALWAYS push it too-`github.com/adom-inc/adom-desktop-fusion-bridge` (renamed from the old `adom-bridge-fusion`-to match the wiki slug). It is a **backup mirror**. **On EVERY change you publish to the-wiki, also `git push` to this GitHub repo.** Never let them drift again (they were 6 commits-out of sync once — that's the confusion we're preventing). Wiki = canonical, GitHub = backup,-keep them in lockstep.--## The publish ritual (every version)-1. Edit in `~/project/adom-desktop-fusion-bridge`. Bump `BRIDGE_VERSION` + `bridge.json`-   `version` together.-2. `git commit` locally.-3. **Push to GitHub backup:** `git push origin main`.-4. Publish to the wiki via the raw `/files` API (the wiki CLIs are dead) — token-   `${ADOM_WIKI_TOKEN:-$(cat /var/run/adom/api-key)}`:-   `curl -X POST -H "Authorization: Bearer $TOK" -F "file=@<f>" \-    https://wiki.adom.inc/api/v1/pages/adom-desktop-fusion-bridge/files`-   Upload: the new `adom-bridge-fusion-v<ver>.zip`, the `adom-bridge-fusion-manifest.json`-   (`{manifest_version,name,version,url,sha256,size,released_at}`, url = absolute `/files/`-   path), `bridge.json`, `BRIDGE_VERSION`, a fresh `adom-bridge-fusion-source.tar.gz`-   (`git archive`) and `adom-bridge-fusion.bundle` (`git bundle create … --all`).-5. **ANON-VERIFY**: re-download the zip + sha256-match, fetch the manifest, confirm version.-6. Install on a Fusion box: `adom-desktop --target <laptop> bridge_install-   '{"manifestUrl":".../adom-bridge-fusion-manifest.json"}'`, then reap the old instance-   (`bridge_kill` on AD ≥1.8.187, else taskkill the PID on its runtimePort) so the new code-   loads, and verify via `bridge_log_read` / a `fusion_*` verb.--## The stale seed — do NOT publish from it-`adom-desktop` (private GitHub) → `plugins/fusion360/` was the bridge's ORIGINAL home and is-now a **frozen first-run fallback only** (AD bundles it offline). It is STALE and NOT-canonical. `release-bridge.sh` refuses to publish it. There is a `STALE.md` in that folder-pointing here. Never treat `plugins/fusion360` as the source; never publish from it.--Related: [[project_adom_desktop_fusion_bridge]], skills `fusion-aps-search`, `fusion-aps-signin`.