@xopcai/xopc 0.0.416 → 0.0.418

package/dist/src/work-discovery/service.js

@@ -1,9 +1,9 @@
 import { createLogger } from "../utils/logger/index.js";
 import { init_logger } from "../utils/logger.js";
 import { afterSqliteCommit, getSqliteDatabase, init_transaction, runSqliteWriteTransaction } from "../storage/sqlite/transaction.js";
-import { createContextEvidence, init_context_evidence_repository } from "../storage/sqlite/context-evidence-repository.js";
+import { createContextEvidence } from "../storage/sqlite/context-evidence-repository.js";
 import { ensureSessionRecord, patchSessionMetadata } from "../storage/sqlite/session-repository.js";
-import { init_sqlite } from "../storage/sqlite/index.js";
+import "../storage/sqlite/index.js";
 import { ActivityService } from "../activity/service.js";
 import { getAgentDefaultModelRef, init_schema } from "../config/schema.js";
 import { init_session_key, resolveConversationId } from "../routing/session-key.js";
@@ -38,8 +38,6 @@ init_providers();
 init_transaction();
 init_session_key();
 init_resolve_route();
-init_sqlite();
-init_context_evidence_repository();
 init_logger();
 const log = createLogger("WorkDiscovery");
 const MAX_UNDERSTANDING_ITEMS = 150;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@xopcai/xopc",
-  "version": "0.0.416",
+  "version": "0.0.418",
   "description": "Local-first personal AI with Ada, task delegation, files, projects and automations. Use cloud or local models.",
   "type": "module",
   "main": "dist/src/index.js",
@@ -62,7 +62,7 @@
   },
   "homepage": "https://xopc.ai",
   "engines": {
-    "node": ">=22.22.3"
+    "node": ">=26.12.1"
   },
   "dependencies": {
     "@composio/core": "0.21.0",
@@ -144,13 +144,13 @@
     "@types/jsdom": "^28.0.3",
     "@types/luxon": "^3.7.5",
     "@types/markdown-it": "^14.1.2",
-    "@types/node": "^25.9.1",
+    "@types/node": "^26.6.5",
     "@types/qrcode-terminal": "^0.12.2",
     "@types/ws": "^8.18.1",
     "@vitejs/plugin-react-swc": "^4.3.1",
     "cross-env": "^10.1.0",
     "dependency-cruiser": "^17.4.3",
-    "electron": "^42.4.1",
+    "electron": "^45.0.0",
     "electron-builder": "^26.15.3",
     "electron-updater": "6.8.9",
     "electron-vite": "^6.0.0-beta.1",
@@ -171,10 +171,10 @@
     "vue": "^3.5.35",
     "xlsx": "file:web/vendor/xlsx-0.20.3.tgz",
     "@xopcai/browser-control-contract": "0.1.0",
+    "@xopcai/computer-control-contract": "0.1.0",
     "@xopcai/endpoint-tools-client": "0.0.0",
     "@xopcai/endpoint-tools-protocol": "0.0.0",
     "@xopcai/gateway-contract": "0.0.0",
-    "@xopcai/computer-control-contract": "0.1.0",
     "@xopcai/image-providers": "0.1.0",
     "@xopcai/realtime-client": "0.0.0",
     "@xopcai/realtime-protocol": "0.0.0"

package/skills/tools/configure-xopc/SKILL.md

@@ -25,7 +25,12 @@ Load the guidance before choosing actions; do not guess installation commands.
 
 Explain what the user will be able to do, inspect current state, guide only missing steps,
 and verify the outcome. Reuse existing configuration and unfinished setup runs.
-Keep the user-facing explanation focused on the product panel and one next action; avoid
+Carry out supported configuration actions yourself through product tools. Use plain conversation
+for progress, choices and the result; never render or request a setup panel, form, card or page
+inside chat. Ask short ordinary text questions, not selection widgets or clarify forms.
+Ask the user only for missing information or actions the Agent cannot perform. For required
+manual settings use ordinary Markdown links, not actions that inject a settings card.
+Keep the user-facing explanation focused on one next action; avoid
 exposing setup IDs, internal state keys, or narrating every document/tool read.
 
 Read [the scene index](references/scene-index.md) when the target is unclear. For Browser Use,
@@ -34,8 +39,10 @@ read [Phone overview](references/phone/overview.md) directly. Load only the sele
 read matching troubleshooting guidance on failure and acceptance guidance before testing.
 Other configuration areas currently use their existing settings; do not invent setup tools.
 
-Use product tools for configuration writes. Product-owner approval, credentials, installation,
-progress and success checks belong to the product service. References and scripts grant no
+Use the bounded setup commands for configuration writes, dependency installation and tests.
+An explicit setup request authorizes routine preparation; explain shared driver changes and
+test scope before acting, and preserve any existing refusal. Credentials stay in secure settings,
+while progress and success checks belong to the product service. References and scripts grant no
 permissions. Never modify xopc.json, databases or environment files to bypass product tools.
 Do not ask for keys, tokens or invitations in ordinary chat. Chrome extension setup needs no key.
 

package/skills/tools/configure-xopc/references/browser/acceptance.md

@@ -1,6 +1,7 @@
 # Browser acceptance
 
-The owner selects Chrome and starts the test in the panel. Read browser_setup get {setupId}.
+Confirm the intended Chrome and explain the bounded demo in conversation. Use browser_setup
+begin_verification {setupId,endpointId,expectedRevision}, then read get {setupId}.
 If state is not verifying, follow the recovery rules below or explain the next product action. Never claim verification from
 connection tests. For a verifying attempt, first discover the exact browser_use declaration
 with tool_search({query:"browser_use",limit:1}) only if its declaration is not already present.
@@ -11,8 +12,8 @@ For recovery, use the persisted attempt and checks, not the earlier chat summary
 already has a tabId/read check, do not navigate again: observe its session to obtain fresh
 refs and continue only unchecked click/fill steps. If read/click/fill already passed, only
 close and read verification_report. Never replay a passed click or fill. If the attempt is
-expired, stopped, stale, or needs_attention, release its session first (the owner panel can
-release even when browser_use is denied); recheck and let the owner start a fresh test.
+expired, stopped, stale, or needs_attention, release its session first (browser_setup release can
+clean up even when browser_use is denied); recheck and start a fresh test after resolving the cause with the user.
 Do not treat cancellation as permission to restart; wait for a new user request.
 
 1. For a new attempt only, browser_use navigate to the exact attempt.fixtureUrl. The host pins the selected endpoint

package/skills/tools/configure-xopc/references/browser/chrome-extension.md

@@ -1,19 +1,23 @@
 # Local Chrome extension
 
-Explain: after setup, xopc can read and interact with pages assigned to the conversation.
-Call browser_setup start, then present the setup panel. It handles local-owner approval,
-shared-driver changes, file preparation, and opening Chrome's extension page and folder. Present the returned settingsPath exactly
-when a settings link is needed; do not replace it with a generic settings open call, which
-loses this setup's identity. Prefer the existing configuration panel in the conversation.
-advance {setupId} can prepare only after product-owner approval; get reads saved progress.
+Explain that configured Browser Use can read and operate pages assigned to this conversation.
+Call start, then prepare {setupId,expectedRevision}. The product tool enables the extension
+route and prepares managed files and the native host. It does not require a configuration UI
+or a separate approval button. Re-read after revision conflicts; do not overwrite manual edits.
+If changing an enabled non-extension driver, explain the shared change and obtain the user's
+choice before prepare with switchDriver:true. Do not switch on the user's behalf silently.
 
-Files prepared does not mean Chrome has loaded the extension. Guide the user through:
-1. Open chrome://extensions and enable Developer mode.
-2. Choose Load unpacked and select the prepared directory itself.
-3. Open the xopc extension side panel so it connects to the local Gateway.
+Use open {setupId,expectedRevision,target:"both"} to open Chrome's extension page and the
+prepared folder. Only these manual browser steps belong to the user:
+1. Enable Developer mode in chrome://extensions, choose Load unpacked and the exact returned
+   extensionDir. Give that directory as plain text; do not invent a folder-opening button in settings.
+2. Open the xopc extension side panel and accept any native/browser permission they want.
 
-Use recheck after user actions. A connected endpoint must be selected by the owner in the
-setup panel before starting the test. Do not choose the first connected computer implicitly.
-The test creates its own browser session; an attached user tab must be released first.
-Read acceptance.md before operating. If a user is on another computer, direct them to Device
-access's pairing flow; local installation controls must not bypass local-owner restrictions.
+Recheck after the user returns. If already installed and connected, skip manual installation.
+Describe available Chrome names and ask only when the intended endpoint is ambiguous. Explain
+the independent read/click/fill demo, then begin_verification with the chosen endpointId and
+current expectedRevision. Read acceptance.md and perform the test yourself using browser_use.
+The user never needs to find or click a test button inside this chat.
+
+For another computer, use existing Device access pairing and guide the user there. Never
+install Gateway-host files as if they belonged to a different computer, or bypass refusal.

package/skills/tools/configure-xopc/references/browser/overview.md

@@ -1,22 +1,19 @@
 # Browser setup
 
-Read tool_manual({tool:"xopc_use",topic:"browser_setup"}); if tool_search is available, discover
-the exact xopc_use tool before its first invocation. Then call
-xopc_use({mode:"browser_setup",command:"inspect"}). Configuration is shared across the Gateway;
-actual browser actions still obey the current Agent's tool and action policy.
+Read tool_manual({tool:"xopc_use",topic:"browser_setup"}), discover xopc_use if needed, then
+call browser_setup inspect. Explain the intended outcome and carry out missing preparation
+with tools; all guidance and progress in chat are ordinary text, never an embedded setup UI.
 
-After inspect selects the extension route, read chrome-extension.md before start or explaining
-installation steps. For the user's current Chrome this is the supported branch. Other modes remain in Settings → Browser;
-remote Chrome pairing is in Device access. Do not install Gateway-host files as though they were
-on another computer. Use existing connections when appropriate; never switch a working driver
-without explaining the shared impact.
+For the user's signed-in local Chrome, read chrome-extension.md. Reuse a healthy extension
+and pairing. Other browser modes remain available in existing Browser settings; explain any
+shared driver change and get the user's choice before switching a working configuration.
+The setup runs on the Gateway computer, which may differ from the computer displaying chat.
 
-start {} creates/reuses a setup tied to this conversation and Agent. Its settingsPath opens the
-owner setup panel, also shown in chat. Owner approval permits preparing files and enabling the
-extension configuration. If tools are unavailable, provide the returned settings entry and the
-remaining action rather than shell/file fallbacks. No arbitrary config paths are accepted.
+start creates or reuses the conversation's setup. After preparation, recheck actual connection,
+identify the intended Chrome, then use begin_verification and the normal browser_use tool.
+Report prepared files, connected extension, actual interaction and release separately.
+If human intervention is needed, give the exact step and relevant settingsPath as an ordinary
+link to the existing settings page. Resume this conversation after the user returns.
 
-For repair requests, inspect installation health even when an earlier run completed. Load
-troubleshooting.md on missing files, denied toolPermission or interrupted verification. Reuse
-the saved run while unfinished; a completed run can be followed by a new repair plan in the
-same conversation. Never reuse successful evidence for a new verification attempt.
+On interruption inspect the saved run and real state; never reuse old successful evidence for
+a new attempt. Browser policy and native permission refusals remain authoritative.

package/skills/tools/configure-xopc/references/browser/permissions.md

@@ -5,14 +5,12 @@ has a Cancel control: cancelling revokes control across tabs until the user expl
 Resume browser control in the xopc extension. This stop survives worker restarts. Neither a
 model request nor opening a new test tab is consent to resume. Do not repeatedly retry.
 
-After a stop, read setup get and close only its demo session (or use the owner's Release demo
-control button). Report release separately. Ask the user to review the extension's stopped
-notice and resume only if they want to. Then recheck; the owner starts a new independent test
-in the original chat. Old checks must not mark the new test passed. Read acceptance.md and
+After a stop, read setup get and close only its demo session (or use browser_setup release). Report release separately. Ask the user to review the extension's stopped
+notice and resume only if they want to. Then recheck; start a new independent test in the original conversation after the user has restored permission. Old checks must not mark the new test passed. Read acceptance.md and
 verify real reading, clicking, typing and release again.
 
 If the native host cannot start, no pairing or browser control is proven. Inspect installation
-health; the owner can use Repair preparation to restore xopc's managed executable and manifest,
+health; use prepare to repair xopc's managed executable and manifest in this conversation,
 then Retry local connection in the extension. Preserve an existing pairing if it is healthy.
 If an OS or managed-browser security policy blocks execution, explain the observed failure and
 let the user review that specific permission through normal settings. Never disable Gatekeeper,

package/skills/tools/configure-xopc/references/browser/troubleshooting.md

@@ -3,11 +3,11 @@
 - Existing installation repair: inspect installation health and toolPermission, even if an older
   setup completed. If files need repair, start a new reviewed setup in this conversation;
   keep the existing endpoint and pairing identity. Never reinstall or re-pair a healthy connection.
-- Files missing or INSTALLATION_REQUIRED: use the panel's preparation action after owner approval.
+- Files missing or INSTALLATION_REQUIRED: use prepare with the latest expectedRevision in this authorized conversation.
 - Files prepared but no endpoint: guide Chrome loading and opening its side panel, then recheck.
 - Old extension: reload xopc in chrome://extensions, open the side panel and recheck.
 - LOCAL_OWNER_REQUIRED: open setup on the Gateway computer; use Device access for remote pairing.
-- Multiple endpoints: let the owner select the correct Chrome in the panel.
+- Multiple endpoints: ask which Chrome the user intends, then pass its exact endpointId to begin_verification.
 - CONFIG_CHANGED: preserve the latest manual configuration and start a reviewed replacement plan.
 - TAB_ALREADY_ATTACHED: ask the user to release the current tab before the independent demo.
 - Verification stopped, timeout, action failure or target changed: close the verification session

package/skills/tools/configure-xopc/references/phone/acceptance.md

@@ -1,6 +1,8 @@
 # Phone basic acceptance
 
-Read phone_setup get {setupId}. Only a verifying, non-stale attempt is approved. Otherwise
+After explaining the test and resolving the intended phone with the user, call phone_setup
+begin_verification {setupId,deviceId,expectedRevision}, then get {setupId}. Only a verifying,
+non-stale attempt is approved. Otherwise
 explain the remaining owner action. Read tool_manual phone_use; discover that exact tool only
 if not already declared. Use only the attempt's selected device, goal, completion and budget.
 
@@ -17,8 +19,8 @@ if not already declared. Use only the attempt's selected device, goal, completio
 For interruption, inspect status and saved setup before any action; do not open over an active
 session or replay an uncertain action. A resumed test still uses the same pinned owner/device.
 If already verified, only close and report. If paused, stopped, stale, expired, failed or a Gateway restart
-lost the runtime session, use the owner's Release test phone action, confirm lease expiry if
-needed, then let the owner begin a new test. Never adopt another phone or prior session report.
+lost the runtime session, use phone_setup release {setupId}, confirm lease expiry if
+needed, then begin a new test after the cause is resolved and the user still wants to continue. Never adopt another phone or prior session report.
 
 This test verifies screenshot observation, model-driven Settings navigation, native UI matching
 and control release. It does not verify payment, login, arbitrary apps, typing or live video.

package/skills/tools/configure-xopc/references/phone/dependencies.md

@@ -1,8 +1,8 @@
 # Phone dependencies
 
-Inspect readiness dependencies before asking the user to install anything. The product's
-Phone dependencies card downloads pinned official assets with checksum/version validation,
-shows progress, supports repair and can use a verified existing installation. Installation
+Inspect readiness dependencies before asking the user to install anything. Use phone_setup install_dependency
+{setupId,kind:"adb"|"scrcpy",expectedRevision,repair?:true} for missing or damaged dependencies.
+The product downloads pinned official assets with checksum/version validation and verifies them. Installation
 happens on the Gateway host, not necessarily the computer displaying this chat.
 
 Local USB/emulator connections require compatible Android Platform Tools (ADB). A cloud
@@ -10,7 +10,7 @@ Aliyun direct ADB connection does not need a local ADB executable. scrcpy server
 video, continuous touch and Unicode clipboard input for either route. Without it, snapshots
 and manual input remain available; do not mark missing video as a failed basic connection.
 
-Let the owner click Install/Repair in the dependency card. Existing ADB can be selected with
+Install or repair automatically through that tool, then inspect fresh status. Existing ADB can be selected with
 an absolute host path and verified version. If managed installation is disabled, explain
 that policy and use existing/runtime controls; do not shell-install around it. Downloads may
 use a configured proxy or verified offline bundle in Runtime Tools. Do not replace system

package/skills/tools/configure-xopc/references/phone/local.md

@@ -1,7 +1,8 @@
 # Local Android and emulators
 
-Reuse an existing enabled registration when it is the intended test phone. Otherwise open
-Phone Use → Add phone → Local phone and refresh discovery. Guide one missing step at a time:
+Reuse an existing enabled registration when it is the intended test phone. Otherwise inspect source local and use
+register_local {setupId,serial:<discovered serial>,expectedRevision,name?:<name>} to register
+the intended online device, restricted to Android Settings for this test. Guide one missing step at a time:
 use a data-capable USB cable, unlock Android, enable Developer options and USB debugging,
 then review the RSA authorization prompt for this Gateway computer on the phone.
 
@@ -11,9 +12,8 @@ ADB missing, a charge-only cable, USB mode, a stopped emulator or a remote Gatew
 Do not advise clearing phone data or revoking all debugging trust as a routine fix.
 On Windows the phone vendor may require its own official USB driver; do not guess downloads.
 
-After discovery reports device, the owner adds the exact device and reviews app access.
+After discovery reports device, register the exact intended serial through the product tool.
 Selected-only access needs the intended apps explicitly selected; do not widen to all apps.
 The setup test needs Android Settings. Do not register a different serial after disconnect.
 For an emulator, start the user's chosen AVD through its normal manager. No new emulator,
-system image download or app install is silently required. Recheck and then let the owner
-select the registered phone and approve basic acceptance in the original chat.
+system image download or app install is silently required. Recheck, explain the selected phone and safe test, then begin verification in this conversation.

package/skills/tools/configure-xopc/references/phone/models.md

@@ -1,18 +1,21 @@
 # Phone model configuration
 
-Phone action model is models.phoneUse, separate from models.chat. Do not replace the chat
-model. Inspect the current Agent's effective model: an Agent override can differ from the
-global Phone settings. Let the owner edit that specific override when it exists.
+Phone actions use models.phoneUse, separately from models.chat. Inspect this Agent's effective
+model and its source first. Keep a healthy existing configuration; never replace the chat model.
 
-Phone settings list supported real models. XOPC Cloud phone routing can use existing Cloud
-login when available; do not promise a Cloud login grants balance or service availability.
-Otherwise guide the owner to Intelligence → Models for an independently configured compatible
-provider. A model needs image input, the supported chat protocol and an explicit Phone action
-profile; generic vision support or a model name is insufficient. Never select internal mock.
+Use phone_setup models to list compatible real models and configured providers. For a missing
+Phone model use set_model {setupId,modelRef:<listed compatible ref>,expectedRevision}. This
+bounded tool changes only this Agent's Phone model, preserving chat and all other routes.
+Do not use generic agent update or models.chat for Phone setup. Respect a specific user choice;
+explain ambiguity between configured compatible models rather than choosing an unrelated provider.
+If a healthy different Phone model already exists, replaceExisting:true is only for an explicit
+user-requested replacement; reuse it otherwise.
+XOPC Cloud phone can reuse an existing Cloud login. A model needs image input, the supported API
+and explicit Phone profile. Never use internal mock.
 
-API keys and OAuth login go through product settings, never chat. Save the Phone model in
-Settings → Phone Use, or the current Agent's Phone override if intentionally configured.
-Use the product's Test model connection action: it sends a synthetic image and reports protocol
-and grounding separately, with possible model charges. It does not inspect or operate a phone.
-A saved reference and credential status are not proof of a working provider. Real device
-acceptance is still required and sends screenshots to the selected Phone model.
+Only new credentials or OAuth require the user's secure product settings. Give a precise link
+to Models and explain what to enter there, never request keys in chat. After the user returns,
+re-inspect and continue yourself. A saved model or logged-in account does not prove service
+availability or free quota. Real acceptance sends Settings screenshots to the selected model
+and can incur model costs. On quota exhaustion, close, report release and wait for resolution;
+do not silently change providers or enable billing.

package/skills/tools/configure-xopc/references/phone/overview.md

@@ -1,30 +1,25 @@
 # Phone setup
 
-Read tool_manual({tool:"xopc_use",topic:"phone_setup"}). Discover xopc_use if not already
-loaded. Call mode phone_setup inspect, then start to create/reuse a setup in this conversation.
-Inspect before asking questions; reuse healthy registrations and matching model configuration.
-Read models.md only for missing/unsupported models, dependencies.md for missing dependencies,
-then only the owner's chosen local.md or aliyun.md branch. Missing scrcpy only limits video
-and Unicode input; it does not block the Settings screenshot/navigation acceptance. State this
-when reporting dependencies instead of asking the owner to install an optional prerequisite. Load troubleshooting.md on refusal
-or failure, acceptance.md only when the owner starts a test.
+Read tool_manual({tool:"xopc_use",topic:"phone_setup"}), discover xopc_use if needed, then
+inspect and start. Carry out missing configuration through tools; use ordinary conversation
+for guidance, choices, progress and results. Never ask for an embedded chat configuration UI.
+Reuse healthy registrations, model configuration and the user's prior device/source choices.
 
-Explain outcomes: xopc can observe and operate the explicitly selected Android phone through
-a dedicated action model. Chat model, Phone model, software dependencies, connection, actual
-UI verification and release are distinct. A registered/enabled phone is not proof of a live
-connection; describe it as registered until a connection check or actual PhoneRuntime operation
-confirms it is online. Setup configuration is shared on the Gateway host;
-a USB cable to the browser computer cannot connect a different remote Gateway.
+Use source {setupId,source:"local"|"aliyun",expectedRevision} after identifying the desired
+route. Ask only if it is unclear. Use configure {setupId,enabled:true,expectedRevision} when
+Phone Use is disabled. This does not enable a denied Agent tool or widen device app access.
+Read models.md for a missing model, dependencies.md for missing software, then local.md or
+aliyun.md for the selected route. scrcpy is optional for basic screenshot/navigation testing.
 
-Use the chat setup panel. The owner chooses local or Aliyun and the exact registered phone;
-do not silently choose the first/default device or buy a phone. Configuration writes, downloads,
-private-key upload, app access and paid tests remain in existing product controls. Model tools
-can inspect/start/get/recheck/cancel/report; begin_verification returns the owner action.
-After saving configuration, direct the user to “授权并开始安全验收” / “Approve and start safe test”
-in this chat. That button sends the continuation itself; do not require an additional “好了”
-message after the owner starts the test.
-Do not write config, credentials, durable_state, Android keys or cloud account settings yourself.
+The Phone action model is separate from chat. A registered/enabled device is not yet a proven
+live connection. Connections and dependency installation run on the Gateway computer.
+When configuration is ready, explain the exact phone, Settings-only goal, screenshot sharing
+and possible model cost. Reuse existing user authorization; ask if the device or scope is
+ambiguous. Use begin_verification {setupId,deviceId,expectedRevision} and carry out acceptance.md
+with phone_use, then close and read verification_report. No chat test button is needed.
 
-A conversation may show other phone tasks: never replace or close those sessions. Setup uses
-its own narrowly scoped test owner; cancellation and release operate only that test. If the
-Agent's phone_use policy is denied, do not change identity or permission to bypass it.
+Only human-only work should be handed back: connect/unlock a physical phone, accept its RSA
+prompt, supply credentials through the secure existing settings page, perform OAuth/login,
+or review and purchase a cloud phone. Give a precise next action and ordinary link when
+needed, then recheck and resume the same conversation. Never ask for keys in chat, purchase
+an instance, edit config files directly, or replace another phone task's session.

package/skills/tools/configure-xopc/references/phone/troubleshooting.md

@@ -9,6 +9,9 @@ configuration and healthy registrations. Explain the one next owner action, not
   failure. Explain the returned retry delay, preserve configuration, close this test and confirm
   release. The owner can wait for reset or select an already configured compatible Phone model
   in product settings. Never silently switch providers, enable billing or buy credits.
+- Temporary model HTTP 503: close and inspect actual dispatch first. If no uncertain input
+  remains, at most one new test may be retried in this turn. After the second failed attempt,
+  stop and report the external service problem. Never loop begin_verification to hide failures.
 - ADB absent/corrupted/download failure: dependencies.md and actual progress diagnostics.
 - USB unauthorized/offline/no device: local.md; the phone owner decides on the RSA prompt.
 - Cloud authentication/timeout: aliyun.md; check key binding and endpoint reachability from