@omercnet/paseo-shared-browser 1.2.2 → 2.0.0-next.244.1

package/OVERVIEW.md

@@ -1,4 +1,4 @@
-Shared Browser runs one real Chromium browser per workspace on the daemon host and shows that same live page to every connected Paseo client, so viewers and agents act on one page with one set of cookies and logins. Many viewers can watch, and one human at a time holds control. Open it from the Command Center, the **Shared Browser** composer pill, or, on Paseo 0.11 and newer, the sidebar footer.
+Shared Browser runs one real Chromium browser per workspace on the daemon host and shows that same live page to every connected Paseo client, so viewers and agents act on one page with one set of cookies and logins. Many viewers can watch, and one human at a time holds control. Open it from the Command Center, the **Shared Browser** composer pill, or the sidebar footer.
 
 ## How it works
 
@@ -13,7 +13,7 @@ New agents whose provider accepts external MCP servers receive a local MCP serve
 
 ## Setup
 
-- Paseo 0.9, 0.10 or 0.11, and Node.js 24 or newer on the daemon host.
+- Paseo ^0.11.0, and Node.js 24 or newer on the daemon host.
 - Chromium is downloaded when the plugin is installed and stored in the Paseo data directory. On Linux ARM64 nothing is downloaded, and you install a non-Snap Chromium at `/usr/bin/chromium` first. `PASEO_SHARED_BROWSER_CHROMIUM_EXECUTABLE` points the plugin at a different Chromium.
 
 ## Limits

package/README.md

@@ -1,14 +1,14 @@
 # Shared Browser
 
-A Paseo plugin that runs one real Chromium browser per workspace on the daemon host and shares that
-exact live session with every connected Paseo client. Version 1.0 replaces the previous browser
+A Paseo plugin that runs one real Chromium browser per workspace on the daemon host and shares its
+pages with connected Paseo clients and workspace agents. Version 1.0 replaces the previous browser
 runtime in place with a plugin-owned, pinned `agent-browser` runtime; existing installations keep
 the `shared-browser` plugin ID and upgrade without installing a second plugin.
 
-This is not URL synchronization and not a second browser with copied cookies. Every viewer and
-eligible workspace agent acts on the same running page, DOM, navigation state, and login state.
-Many viewers can watch; human control remains server-authoritative and takes priority over agent
-input.
+Each browser tab is a real page in the same Chromium profile, so tabs share site logins and cookies.
+Each client and agent selects a tab independently. Viewers of the same tab share its live page,
+navigation and control state. Human control remains server-authoritative and takes priority over
+agent input on that tab.
 
 ## Demo
 
@@ -33,12 +33,23 @@ organization names.
 - The plugin server runs beside the Paseo daemon and starts one `agent-browser` session and Chromium
   process per open browser workspace. Browser execution, profiles, IPC, and network access are on the
   daemon host, not on the viewing phone, browser, or desktop app.
-- The plugin owns `agent-browser` version `0.37.1`, its IPC directory, and the Chromium executable.
+- A workspace can have up to eight tabs. Each tab has its own page, capture stream, viewport and
+  controller. Selecting a tab affects only the selecting viewer or agent. Closing a tab removes it
+  for every participant viewing it; the last tab stays open until the browser is closed.
+- Viewers can select a browser action while observing. A dialog offers control, names the current
+  controller when a takeover is needed, and continues the selected action after control is granted.
+  Closing a tab or browser still requires its own confirmation. Actions that need a fresh frame wait
+  for one before sending input.
+- The plugin owns `agent-browser` version `0.38.2`, its IPC directory, and the Chromium executable.
   It strips inherited `AGENT_BROWSER_*` variables and sets `AGENT_BROWSER_SOCKET_DIR`,
   `AGENT_BROWSER_IDLE_TIMEOUT_MS=0`, `AGENT_BROWSER_STREAM_PORT=0`, and
   `AGENT_BROWSER_NO_AUTO_DIALOG=1` itself.
-- Frames stream from Chromium through CDP `Page.startScreencast`, with a bounded screenshot fallback.
-  Remote input supports tap, double-tap, right-click, drag, swipe scrolling, text, and special keys.
+- By default every client receives JPEG frames from CDP `Page.startScreencast` or bounded
+  screenshots, and no capture extension is loaded into Chromium. When the daemon is started with
+  `PASEO_SHARED_BROWSER_VIDEO=1`, desktop/web clients with usable WebCodecs receive encoded
+  workspace-tab video instead; other clients keep JPEG.
+  Remote input supports mouse hover, wheel scrolling, continuous dragging, native touch pan/pinch,
+  tap, double-tap, right-click, text, and special keys.
 - Device presets for Desktop Chrome, iPhone 15 Pro, Pixel 7, and iPad Pro 11 change Chromium's
   viewport, device pixel ratio, touch behavior, platform, and user agent. A phone can view and
   control the shared browser, but the rendered browser remains Chromium. An iPhone preset is mobile
@@ -53,6 +64,12 @@ bridge can reclaim the existing workspace runtime. If no bridge reconnects, the
 all orphaned runtimes after a 120-second grace period. A missed heartbeat fences the old bridge after
 30 seconds; the bridge sends heartbeats every 10 seconds.
 
+The browser actions menu has **Close shared browser**. After confirmation,
+it stops that workspace's Chromium process and ends every viewer and agent connection to it, even
+when their panels are active. Background reconnects cannot reopen a deliberately closed browser.
+A person can select the prominent **Open shared browser** button in the closed panel to start a new runtime with the
+retained profile. Closing the browser does not remove saved cookies or site data.
+
 Each workspace gets a private profile under
 `$PASEO_HOME/plugin-data/shared-browser/profiles/<workspace-id-sha256>`. Cookies and site login state
 therefore survive viewer disconnects, plugin reloads, and Chromium process restarts while that
@@ -93,7 +110,7 @@ Before upgrading the plugin on Windows, close active Shared Browser sessions and
 daemon; Windows does not allow the installer to replace runtime executables that are still running.
 
 Open a workspace, search the Command Center for **Open Shared Browser**, or tap the **Shared
-Browser** composer pill while a workspace session is open. On Paseo 0.11 or newer, a **Shared
+Browser** composer pill while a workspace session is open. A **Shared
 Browser (n)** row in the sidebar footer appears while browser sessions are open; it lists them and
 jumps to the chosen workspace's browser panel.
 
@@ -102,21 +119,22 @@ jumps to the chosen workspace's browser panel.
 The plugin automatically injects its stdio MCP adapter only when a new, non-internal agent is
 created with a provider that accepts external MCP servers. Agents that already exist, resumed
 sessions, imported sessions, and Paseo's internal agents are not modified. Paseo's built-in OMP
-provider accepts session MCP servers from Paseo 0.11, so new OMP agents receive the adapter there.
-On Paseo 0.9 and 0.10 the built-in OMP adapter rejects external MCP servers, so OMP agents are left
-unchanged. Pi agents continue to receive the adapter, but they require Pi's optional MCP support to
+provider accepts session MCP servers, so new OMP agents receive the adapter.
+Pi agents also receive the adapter, but require Pi's optional MCP support to
 launch it.
 
-The injected MCP server exposes exactly these tools: `shared_browser_status`,
-`shared_browser_capture`, `shared_browser_acquire_control`, `shared_browser_release_control`,
-`shared_browser_navigate`, `shared_browser_input`, and `shared_browser_viewport`. It does not
+The injected MCP server exposes `shared_browser_status`, `shared_browser_capture`,
+`shared_browser_acquire_control`, `shared_browser_release_control`,
+`shared_browser_navigate`, `shared_browser_input`, `shared_browser_viewport`,
+`shared_browser_tabs`, `shared_browser_tab_open`, `shared_browser_tab_select`, and
+`shared_browser_tab_close`. It does not
 expose arbitrary CDP commands, JavaScript or page evaluation, browser profile access, or filesystem
 access.
 
 Each adapter launch receives an opaque credential bound to its workspace. It cannot use that
 credential to operate another workspace's browser. Agent input follows human-priority control: an
-agent cannot force a takeover while a human viewer holds control. The human must release control or
-the lease must expire before agent input can proceed.
+agent cannot force a takeover while a human viewer holds control of the same tab. The human must
+release control or the lease must expire before agent input can proceed on that tab.
 
 The provider launches the stdio adapter on the Paseo daemon host, beside the daemon-owned browser
 runtime. Web, desktop, and mobile clients never own or host the adapter or Chromium, and a client
@@ -137,11 +155,163 @@ User-supplied `AGENT_BROWSER_*` variables are deliberately ignored.
 
 ## Controls
 
-- Toolbar: back, forward, reload, address bar, and device emulation.
+- Toolbar: back, forward, reload, address bar, a combined monitor menu, mobile emulation toggle
+  and a vertical-dots browser actions menu. The controller can close the shared browser from that
+  menu after confirmation. Icon controls expose their action name
+  as a hover tooltip on desktop/web and retain native accessibility labels.
+- Custom viewports support 320 to 3840 pixels wide and 480 to 3840 pixels high. Invalid sizes
+  show their error inside the device dialog; a successful Apply closes it.
+- Desktop presets also include 1280 × 800 (16:10) and 1280 × 1280 (1:1).
+- Pixel 7 (high resolution) keeps the same 412 × 839 phone layout and input coordinates,
+  with a sharper 824 × 1678 capture.
+- Desktop presets include 1920 × 1080 and 2560 × 1440 (16:9), 1920 × 1200 and
+  2560 × 1600 (16:10), and 1920 × 1920 and 2560 × 2560 (1:1).
+- Desktop choices use height names such as 720p, 1080p, 1200p and 1440p, with
+  dimensions shown alongside. Square choices name their width explicitly.
+  The 1440-wide choices are 1440 × 810, 1440 × 900 and 1440 × 1440.
+- The Resolution and quality menu groups desktop choices by 16:9, 16:10 and 1:1,
+  then mobile. Each group sorts by width. Filled stars mark favorites; the monitor
+  menu provides favorites in that same grouped order and access to the full
+  resolution and quality list.
+- **Fill viewport** resizes the shared browser to the visible panel and follows panel size
+  changes while this viewer controls it. It preserves mobile behavior. Auto capture density
+  adjusts detail for the screen as the panel grows or shrinks; manual density is retained.
+  Following pauses when the panel is hidden, control is released, or its dimensions exceed
+  the supported resolution at the current density. Choosing a preset or custom resolution
+  stops following; a failed resize also stops it and displays an error.
+- Monitor and browser actions open compact anchored menus rather than dialogs. Menus stay
+  within the pane, scroll long lists, and dismiss with an outside press, Escape or native Back.
+- The monitor menu offers **Fit to panel** (default) and **Actual size (100%)**. Actual size
+  uses browser layout pixels, not the larger JPEG dimensions of sharper phone captures.
+  This choice affects only the current viewer, without resizing the shared browser.
+  Desktop local scrollbars reveal overflow while wheel events on a controlled frame go to
+  the remote page. Phone viewers can pan while observing; controlling sends swipes to the
+  page instead. Fitting images stay centered without empty scroll ranges; a scrollbar on
+  one axis does not force one on the other. Returning to Fit resets local offsets without
+  reloading the page or image.
+- With `PASEO_SHARED_BROWSER_VIDEO=1` set in the daemon environment, desktop and web clients
+  with WebCodecs play genuine encoded tab video (H264 when supported, otherwise VP8). The
+  bundled capture helper, which holds `tabCapture` and `debugger` permissions, is then
+  loaded into every workspace Chromium profile and captures the exact workspace tab, not a
+  screenshot loop or title-selected window. Without the variable the helper is never
+  materialized or loaded, and clients show a one-time disabled reply then use JPEG.
+  Android and other native apps use JPEG: the plugin SDK this package targets publishes no
+  encoded-video surface, so native video is deferred until the host ships one.
+- The monitor menu's resolution and quality list separates JPEG quality (40%, 65%, 85%,
+  or 100%), video bitrate (2, 5, 12, or 24 Mbps), and video frame rate (15, 30, or 60 FPS).
+  Defaults are JPEG65 (Medium) and, when video is enabled, 12 Mbps at 30 FPS. Old saved quality choices keep their
+  corresponding video bitrate when upgraded. These are encoder targets, not measured
+  bandwidth or guaranteed frame rates. Large JPEGs may reduce quality to stay within
+  the 800 KB frame bound. Preferences persist on the connected Paseo host.
+  Capture density defaults to Auto for each viewer panel. While controlling, it selects
+  1x or 2x from the displayed page size and screen pixel density, accounting for Fit's
+  letterboxing and Actual size. Manual 1x/2x choices override Auto until Auto is selected
+  again, the workspace changes, or the panel is reopened. Density raises real source
+  pixel detail without changing page size, input mode, or user agent. The 2x option
+  requires both page dimensions to be 1920 or less; larger pages use 1x. Fill viewport
+  adjusts automatic density and layout size together. Hidden panels, observers, active
+  gestures, and pending operations never trigger automatic density writes. A failed
+  adjustment pauses automation until Auto is selected again. Higher density can increase
+  processing and bandwidth substantially. Quality changes do not navigate or reload the page.
+- Video packets travel through the existing authenticated Paseo RPC connection, including its
+  relay. No extra video port or unauthenticated media server is opened. This is encoded video
+  delivered in bounded request/reply batches, not WebRTC or a custom push subscription.
+- Animated native capture supports a source ceiling of 60 frames per second. Ordinary
+  frames follow each encoder's requested rate; a recovery keyframe can use the next
+  eligible frame without waiting for that interval. Quiet tabs produce genuine frames
+  around once per second; repeated packets never acquire a newer source capture timestamp.
+  At most three bitrate/frame-rate cohorts share one source. Changing quality never evicts
+  another active cohort. If all three are occupied, another profile uses JPEG fallback
+  and retries video after 2.5 seconds while visible. Hiding or unmounting cancels
+  that viewing-only retry; the soft error clears after a fresh video frame paints.
+  Idle encoders release their buffers and codecs after two seconds without an active read;
+  when no video consumer remains, the native track and helper also close. A returning video
+  viewer can reacquire the source safely. Higher rates/bitrates and multiple encoders cost
+  more host CPU and bandwidth; pixel density and the host's native codecs also affect cost.
+- Hidden documents, page-cache suspension, inactive native AppState and panel unmount stop
+  this viewer's video reads and release decoding resources. Resuming requests a fresh
+  keyframe. One already-issued bounded RPC may finish, but cannot restore old input authority.
+  Video remains video when the page is quiet; no idle still-image overlay or static-page
+  polling is used. Keyframes restore decoding after a gap but do not make video lossless.
+- Initial human control requires decoded and painted geometry. Once admitted,
+  the controller's ordered input channel continues while video catches up.
+  A click may reach a page ahead of the displayed image, as in remote desktop.
+  Agent commands retain strict fresh-frame targeting. Document, viewport,
+  runtime, bridge and controller changes invalidate the human admission. Dropped packets recover at a keyframe rather
+  than decoding a broken delta chain. Video reads wait outside the input queues.
+- If no fresh video is painted for 2.5 seconds, the viewer revokes video input authority and
+  requests JPEG fallback and a fresh keyframe. The retained video remains visible
+  until a current image has decoded, so a delayed fallback cannot flash an older view. Decoder/capture failures also retain
+  fallback. The Video, CDP and fallback labels describe the displayed transport.
+- JPEG captures refresh after input. A stalled screencast falls back to a fresh screenshot.
+  Healthy painted video suppresses redundant JPEG polling and focus captures. Media
+  reads use source generations without repeatedly querying page metadata inside
+  the control queue; ordinary status checks still reconcile navigation state.
+  Shared JPEG screencasting starts on image demand and stops after three seconds
+  without demand. Phone/image viewers and agent captures restart it lazily;
+  video reads alone do not keep it running. An image fallback after retirement
+  may wait for stream startup or use the existing screenshot fallback.
+  Repeated reads of the exact cached JPEG send metadata only; image source age still expires
+  within one second. The last decoded image remains visible while its replacement loads.
+- Reconnecting or switching browser tabs restores the selected device viewport, capture density,
+  touch and user agent before accepting new frames.
+- Actual video and JPEG dimensions must match the selected capture resolution before a frame is accepted.
+  The fallback captures the complete visible viewport, preserves scroll position, and accounts
+  for device pixel ratio and capture scale so inputs still use the original layout coordinates.
+- The last decoded frame stays visible while its replacement loads, with native image fading
+  disabled. Initial human admission and agent commands use the painted frame;
+  admitted human input retains its qualified geometry while pixels catch up.
+  Obsolete image callbacks cannot replace the displayed frame.
 - Status row: session state, viewer count, controller, and lease expiry.
+- Returning after viewer expiry reattaches viewing once automatically while preserving the
+  page. Expired control is cleared; take control again to send input. Expected expiry is not
+  shown as an action failure; a failed reattachment still offers manual retry.
+- Clicking a link or submitting a form may navigate before its input reply arrives. A completed
+  input returns the new viewing state without a false failure or repeating the action.
+  Replaced controls, targets and uncertain sends remain rejected.
+- A document change during metadata reads discards both partial observations and
+  permits one fresh read on the same attachment within the original timeout.
+  Repeated changes, failed reads and replacement attachments remain errors;
+  browser input is never replayed to obtain metadata.
+- Agent stale-frame errors identify initial admission or a context change during admitted
+  input. Known receipt age is bounded to 60 seconds and uses its original clock; missing
+  receipts report missing-or-revoked without inventing an age. These diagnostics contain
+  no page content or authority identifiers and do not authorize replay. Initial frame
+  admission still expires after five seconds.
 - Human control: **Take control**, **Release**, and **Take over** for explicit handoff. Agent MCP
   calls have no forced-takeover operation.
-- Mobile: swipe scrolls by default; pointer and keyboard options open as bottom sheets.
+- With control, mouse movement forwards real hover effects and standard browser cursor changes.
+  Wheel scrolling stays inside the browser canvas; held drags update before release. Leaving the
+  canvas clears remote hover, while dragging beyond its edges still releases the held button.
+- Hidden Linux browsers are headless by default. Opting in to a private virtual display
+  (see Optional Linux desktop hover) supplies native desktop pointer/hover capabilities,
+  including after switching back from phone mode.
+- Native touch forwards active fingers continuously, including pan and pinch on desktop and mobile
+  presets. Physical mouse buttons and double clicks retain their natural actions; touch never
+  changes into a synthetic mouse gesture.
+  Losing control, changing page or resizing cancels held input; old contacts must lift before a
+  fresh touch can target the replacement page. No uncertain input is replayed after a failure.
+- Desktop viewports show native scrollbars. Dragging a scrollbar thumb scrolls the page
+  continuously before release. Wheel scrolling and touch panning remain available;
+  mobile emulation retains its normal mobile scrollbar behavior.
+- Click the controlled canvas to type directly on desktop and web. Shortcuts, repeat,
+  modifier clicks and committed composition text are forwarded; other Paseo inputs stay local.
+- The address-bar Browser menu contains a Send keys submenu and reconnect actions. On desktop,
+  keys open beside the menu; on compact screens, Back returns to the parent menu. Extra keys
+  are no longer shown below the canvas or in a separate dialog.
+- On native phones and compact web layouts, Compose text in that menu opens an explicit local
+  draft for keyboard or IME text, inserted once into the focused page field when you choose
+  Done. Native phones have no live software-keyboard relay; compact web also keeps canvas
+  typing. Extra keys remain available in the Send keys submenu.
+- Local plain-text paste is forwarded; remote copy/cut are not synchronized to the local clipboard.
+- The address-bar mobile toggle changes shared emulation while preserving the current display
+  dimensions and capture density. Choose a resolution explicitly to change the display.
+  Your device default applies the first time you take control, never while observing, and
+  also preserves the current display. Narrow desktop layouts do not count as phones.
+- The mobile address field keeps a full text line with compact padding. Read-only addresses
+  stay legible while observing; taking control is still required to edit or navigate.
+- Mode changes preserve the current page and unsaved fields. Sites that select layouts only
+  at page load may need an explicit Reload. There are no click, swipe or scroll mode controls.
 
 ## Security boundary
 
@@ -160,29 +330,148 @@ User-supplied `AGENT_BROWSER_*` variables are deliberately ignored.
   callbacks expose no authenticated caller identity, so these human-viewer tokens are a workflow
   safeguard, not an authorization boundary. The stdio MCP adapter separately uses an
   opaque, workspace-bound credential.
-- Downloads, uploads, clipboard synchronization, media permissions, extensions, native passkeys,
-  and platform authenticators are not exposed by this plugin.
+- The bundled trusted video helper has tabCapture/debugger access to capture the exact workspace
+  tab. It exposes no content scripts, site messages, network host permissions or web-accessible
+  resources. User-supplied extensions and page media permissions remain unavailable.
+- Downloads, uploads, clipboard synchronization, native passkeys and platform authenticators
+  are not exposed by this plugin.
 - Browser navigation uses the daemon OS user's network access, including local development servers.
   It is therefore a trusted-agent capability; this plugin deliberately does not apply a blanket
   loopback or RFC1918 navigation ban.
 
 ## Develop
 
+Follow the repository's `AGENTS.md`. Runtime verification must use an isolated
+Paseo home, never the default daemon, active plugin installation, or signed-in
+profile. Run dependency installation from the monorepo root, then the following
+checks from `paseo-shared-browser`:
+
 ```bash
-bun install
+bun install --frozen-lockfile
 bun run typecheck
-bun run lint
-bun run format:check
+bun run check
 bun run test:unit
+```
+
+The `test:tabs` native check requires explicit
+`PASEO_SHARED_BROWSER_AGENT_BROWSER_BINARY` and
+`PASEO_SHARED_BROWSER_CHROMIUM_EXECUTABLE` paths. It creates and cleans up its own
+temporary Paseo home and browser profile.
+
+`node scripts/test-image-capture-mounted.mjs --tooling-root /path/to/test-workspace`
+opt-in checks the real React/React Query image scheduling and viewing recovery hooks
+in JSDOM. The tooling workspace must already provide compatible React, react-dom,
+jsdom, React Query and esbuild. The plugin intentionally does not add these DOM test
+dependencies or install missing packages. Omitting `--tooling-root` uses this
+checkout if its dependencies include them. The command owns and removes temporary
+hook bundles; it never launches or accesses a browser/runtime or profile.
+For reproducible mounted checks, create a disposable tooling workspace with
+React and react-dom 19.1.0 (matching this repository's React version), jsdom
+30.1.1, React Query 5.102.3 and esbuild 0.28.2. jsdom requires Node 24.15 or
+newer on the supported Node 24 line. These are test-only dependencies, not
+plugin runtime dependencies. For example:
+
+```bash
+npm install --prefix /tmp/shared-browser-dom-tools --ignore-scripts --no-save \
+  react@19.1.0 react-dom@19.1.0 jsdom@30.1.1 \
+  @tanstack/react-query@5.102.3 esbuild@0.28.2
+node scripts/test-image-capture-mounted.mjs --tooling-root /tmp/shared-browser-dom-tools
+node scripts/test-panel-video-mounted.mjs --tooling-root /tmp/shared-browser-dom-tools --fixture settlement
+```
+
+The panel fixture also accepts `handoff`, `rapid`, `continuous` and `admission`.
+Run each variant for changes to media handoff or input policy. The `settlement`
+fixture checks late replies across viewer and controller replacement. Delete
+the tooling directory when done.
+
+Use the same command with `--fixture density` for six mounted controller/density
+menu regressions, including observer bounds, same-workspace token replacement,
+unmount and no retry after an uncertain write.
+
+Prepare runtime assets with an explicit temporary `PASEO_HOME` before either
+browser gate. Keep that directory outside the default Paseo home. For example,
+on POSIX systems:
+
+```bash
+export PASEO_HOME="$(mktemp -d -t shared-browser-verification-XXXXXX)"
 bun run prepare:runtime
+bun run test:smoke
+bun run test:video
 ```
 
+Remove the temporary directory after verification. On Windows, use a new
+explicit temporary directory in `$env:PASEO_HOME` instead. Tests manage their
+own browser teardown; do not run daemon lifecycle commands against the default
+host to recover a test failure.
+
 `bun run test:smoke` launches the configured real Chromium runtime and exercises two viewers,
 control handoff, reconnect, stale-frame rejection, viewport changes, device emulation, profile
 persistence, and archive teardown.
 
+`bun run test:video` is an optional real video gate. It opts its own runtime into encoded video
+and reads prepared Chromium/CLI assets,
+then creates its own temporary Paseo home, browser profile, Unix socket and local fixture pages.
+It checks the production video decoder and canvas at 1280x800, sharp Pixel and 2560x2560,
+including all four corner markers. It never uses the live browser. This gate requires usable
+WebCodecs/tab capture and the local runtime assets; it is separate from unit tests.
+Linux CI requires Xvfb and runs this video gate without skipping unsupported
+capture. macOS and Windows run the image/browser smoke; their native video
+hardware and remote-network performance require separate qualification. CI also
+runs the actual Paseo compiler on both plugin entries.
+
 Release Please maintains the version, changelog, component tag, and GitHub release from
 Conventional Commits in the monorepo.
 
-Both the Paseo daemon and app must satisfy `^0.9.0 || ^0.10.0 || ^0.11.0`. The client surface uses React Native primitives
-and works in desktop, web, iOS, and Android Paseo clients.
+Both the Paseo daemon and app must satisfy `^0.11.0`. Encoded video is opt-in on the daemon and
+requires WebCodecs in a web client; JPEG is always available. The client surface uses React
+Native primitives and works in desktop, web, iOS, and Android Paseo clients.
+
+Every independent press (mouse down or first touch contact) carries the decoded frame
+receipt that was visible when it was made. Receipts last five seconds and are spent by
+acknowledged input, so a stalled or superseded presentation cannot admit a later click;
+held drags, releases and keys continue on their channel. A wheel capture can finish decoding
+after input revoked its frame token. The server
+returns a known non-admission receipt before creating a new channel; the canvas waits
+for another decoded frame before admitting that still-unsent gesture. Recovery allows
+up to three admission attempts within one four-second decoded-frame wait budget.
+Published input, unknown outcomes, expired leases, and replaced contexts are never retried.
+
+
+## Maintainer references
+
+[Streaming design](STREAMING_DESIGN.md) documents media ownership, resource
+bounds, input admission and recovery. [Remote-control research](REMOTE_BROWSER_RESEARCH.md)
+records primary-source comparisons and the trade-offs behind continuous human
+input. These describe the implementation's guarantees, not a promise of a
+particular frame rate or remote-network latency.
+
+
+## Optional Linux desktop hover
+
+Hidden browsers are headless by default. To expose desktop pointer and hover
+behavior on Linux, opt in by setting `PASEO_SHARED_BROWSER_XVFB=1` (exactly `1`;
+any other value stays headless) in the environment of the Shared Browser
+supervisor process. The supervisor is a detached process that inherits the
+daemon environment when it is spawned, so changing the variable affects it only
+after that supervisor process restarts. Within a running supervisor the variable
+is read each time a workspace browser runtime is created; existing runtimes keep
+their mode. A trusted embedding can pass `virtualDisplay: true | false` to
+`createRuntimeOwner`; an explicit `false` overrides the variable.
+
+When opted in and `/usr/bin/Xvfb` exists, each hidden Linux browser uses its own
+private, authenticated display. No visible window opens and no TCP or pathname
+listener is created. The display is stopped with its browser. Headed mode and
+non-Linux platforms are unchanged. The plugin never installs Xvfb or changes host
+display settings.
+
+If the display cannot start, the browser falls back to headless and the viewer
+shows a short notice (for example "Private display unavailable: Xvfb was not
+found."). The notice never contains paths or credentials. If an opted-in display
+dies while running, requests fail and the viewer shows an error; use **Reconnect
+viewer** to replace the browser. Reconnect discards the old runtime and starts a
+new one, so the page reloads from its initial URL, and old viewer, control and
+input attachments are rejected. Nothing is replayed automatically.
+
+Known limitation: if the supervisor is killed with SIGKILL it cannot stop its
+child, so an orphaned Xvfb process and its private authority directory under the
+temporary directory can remain until removed manually.