Adom Wiki

@kcknox, this one is about making every Adom surface drivable by the AI, starting with the wiki, and it will hit your Altium Bridge video the same way it is hitting my Fusion Bridge video.

What happened

For the Fusion buck demo video, the AI had to show four component pages: open the page, load the 3D model, then on the LED page jump to States, load the states widget and flip it from Off to On. There is no way for the AI to ask the page to do any of that, so it drove it like a person would:

• turned on Adom Bridge mouse control, then clicked screen pixels for "Load all viewers", "Load 3D model", "Load adom-states" and the On button;
• guessed coordinates from screenshots. One "Load 3D model" click landed 23 px above the button and the TPS54202 model never loaded; it took three re-takes to find out why;
• "Load all viewers" is a toggle, so on a page that already had viewers loaded, the same click unloaded them;
• had no way to ask the page "is the model loaded yet?", so every step waited a fixed number of seconds and hoped.

It works, but it is slow, brittle and it looks clunky on camera. Every time the AI has to fall back to mouse driving, that is a surface the AI cannot actually control.

Why it matters now

Your Altium Bridge video is the same shape as this Fusion one: the AI pulls parts from the wiki, shows their pages and 3D models, then builds the board. You will hit exactly this. It is also the general rule we want: every Adom surface should be drivable by the AI directly, not through the mouse.

Two ways to do it

1. A small JavaScript API on every wiki page (lighter, and probably the place to start). Expose something like window.adomWiki and let the AI drive it with an eval, through whatever is showing the page: a Hydrogen webview, a pup window or the native browser. All three can already run JavaScript in a page. For example:

await adomWiki.viewers.loadAll()                 // the same as the button, but not a toggle
await adomWiki.viewer('3d').ready()              // resolves when the model has rendered
adomWiki.viewer('3d').orbit({ yaw: 30, seconds: 2 })
adomWiki.viewer('3d').setCamera('iso')
adomWiki.scrollTo('states', { smooth: true })
await adomWiki.widget('states').load()
adomWiki.widget('states').set('on')              // the LED lights up
adomWiki.state()                                 // which viewers/widgets are loaded, current camera, scroll

Each call returns a promise that resolves when the thing is actually on screen, so the AI never sleeps and guesses. This keeps #1292 intact: viewers still never load on their own, the AI loads them on purpose.

2. A live channel back to the AI (heavier, more powerful). A URL parameter that names an SSE endpoint, for example ?drive=<endpoint>. The page connects back to it, and a server-side process in the user's container can then send commands and receive state and events, the same pattern the app-creator skill's live channel uses for our own apps. The AI talks to that process instead of injecting JavaScript, and gets pushed events ("viewer ready", "user clicked On") instead of polling.

Option 1 is enough for demo videos and most AI flows. Option 2 is worth it if we want the AI and a person to share a wiki page live.

Ask

1. Pick a direction (I would start with option 1).
2. Make the component page viewers and widgets controllable through it first: 3D viewer load, ready, orbit and camera; the states widget; scroll to a section; the inline datasheet.
3. Document it in the wiki skill so every agent finds it, and have the 3D viewer and widget code expose the same hooks so new widgets are drivable by default.
4. Then we retire the mouse-driven fallback for wiki pages in both demo videos.