* dashboard: pan canvas via middle-drag and horizontal scroll over browser/chat
- Middle-mouse drag inside a browser webview is forwarded as canvas pan
(previously eaten silently by the guest compositor).
- Horizontal-dominant wheel inside a browser webview pans the canvas
when no ancestor in the guest page can absorb horizontal scroll;
otherwise the page handles it.
- Horizontal-dominant wheel over a chat panel pans the canvas (chat has
no horizontal scroller). Vertical scroll is unchanged.
Plain vertical scroll and ctrl/meta+wheel zoom over a browser stay with
chromium's defaults.
* browser: drop in-guest zoom locks so pinch and cmd+wheel zoom the page
setVisualZoomLevelLimits(1, 1) blocked pinch-to-zoom inside the webview, and
setZoomFactor(1) on every dom-ready reset any user page zoom. Both were added
back when canvas zoom was supposed to take over for ctrl+wheel; with that
reverted, chromium's native zoom handlers should run unimpeded.
* [aidan] fix: prev. commit fix. restore ctrl+wheel canvas zoom over webview cards
* [aidan] ui/ux: app navigation
* [aidan] ui/ux: gate webview preload forwarding on app interactive mode
When a view card is "interactive" (user clicked into the app), the preload stops forwarding ctrl+wheel, middle-mouse-drag, and horizontal-scroll-pan gestures so the embedded app gets every event. A mousedown notifier reports in-guest clicks to the host so it can flip the card into interactive mode without intercepting the click itself.
* aidan] bug: fixed 2 auth claude login issue
* [aidan] bug: claude login w email+pw
* [aidan] ui: edited message for cases where anthropic redirects to enter email code even after login'
* [aidan] ui/ux: fix connecting status accuracy
Add agentBridge.ts and import it FIRST in index.tsx so the bridge is
installed on the window before any app code runs.
The visitor / door / doorbell analogy:
- The visitor is the agent. It shows up wanting to operate the app:
read the rules, see the controls, take an action, check what happened.
- The door is window.OPENSWARM_APP. A single, always-present surface the
visitor can knock on: describe() to learn the app, getState() to read a
snapshot, invoke(name, args) to act.
- The doorbell is register({ rules, controls, getState, invoke }). The app
presses it on mount to say "I'm home, here's how to talk to me." Until it
does, describe()/getState() answer { __ready: false } so the visitor
knows the app is still booting and waits, instead of concluding nobody
lives here.
Why a hook and not just an .md:
A markdown instruction ("please expose your controls on window.X") is a
request the app can forget, half-implement, or drift from, and nothing
fails when it does. The bridge ships WITH the template and is imported
before app code, so the door exists from first paint whether or not the
author thought about agents. The app's only job is to press the doorbell
once; it never wires the plumbing, so it cannot get the plumbing wrong.
The contract is executable, not aspirational, which is the difference
between every generated app being agent-operable by default and hoping
each one remembered to be.
An npm install killed mid-warm leaves node_modules/ populated but no
.bin/, so _ensure_warm_cache (which only checked the dir exists) trusted
the half-tree forever and every app symlinked to it died with
`vite: command not found`. Gate the cache on .bin/vite existing, and
harden the app's frontend/run.sh skip-install guard the same way.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
ciregenz