@abot-ai/runtime 1.6.0 → 1.8.0

package/docs/plugins.md

@@ -16,6 +16,9 @@ the same physical directory, the catalog is discovered only once.
 Open **Plugins** to see installed manifests, capability counts,
 and enabled, partially enabled or disabled selections. Switches save the selected
 plugin's configuration while preserving capability-specific allow/deny rules.
+Whole-plugin switches use `plugins.disabledPluginIds`, an exact list of plugin
+IDs independent of capability names and qualified selectors. The list does not
+interpret wildcards; legacy `allow` and `deny` rules keep their existing meaning.
 Choose **Manage tools** on a plugin to manage its declared tools inside the same card.
 The card keeps its size; the tool list scrolls when needed. Use **Back** or Escape
 to return to the plugin overview. For example, disabling filesystem.read_file
@@ -26,14 +29,164 @@ tools switched off.
 Global, parent-plugin and broad tool deny rules remain explicit blockers.
 A child switch does not silently remove those rules or enable sibling tools.
 
+Install, configuration saves, enable/disable and Remove require every owning Runtime to be idle.
+While a conversation or Job is running, these actions return a clear message
+without saving the requested change. Open but idle conversations do not block
+changes; browsing and reviewing repositories remain available. If another process
+owns an environment, use the owning Web UI so its activity can be verified.
+
 Choose **Apply changes** to activate saved settings. The Web process replaces
 only its own idle environments and preserves session and Job files. If any
 environment is working, or another process owns it, changes remain saved and
 the UI explains why they cannot yet be applied. Saving a switch alone does not
 change tools available to an already running agent.
 
-This screen manages packages already installed on disk; it does not install
-plugins from a marketplace.
+## Configure Plugin Values
+
+Choose **Configure** on an installed plugin, or use the same form during its
+installation review. Fields come from the existing `settings.defaults` and
+`secrets` declarations. Strings, numbers and booleans use ordinary controls;
+objects, arrays and null defaults use JSON. The host checks declared setting
+names and top-level default types. A null default supplies no type information;
+semantic checks such as URL validity remain the plugin's responsibility.
+The form shows whether each setting uses the plugin default or a local value.
+Saving credentials alone leaves inherited defaults unchanged. Editing a setting
+creates a local override, even when its value equals today's default; **Use plugin
+default** removes that override when saved. Existing saved values stay local until
+explicitly reset, so no upgrade automatically rewrites a user's configuration.
+No manifest schema or SDK changes are required. If an upgraded plugin changes a
+setting's default type, an incompatible retained value blocks loading with an
+explicit configuration error. Configure remains available to correct the value;
+the host does not silently replace it with a default.
+
+**Save changes** persists values locally; **Apply changes** loads them into new
+idle Runtime owners. Existing owners retain their loaded values, including when
+activation fails and restores the previous configuration. GET returns settings
+and credential-presence flags, never secret values. Passwords remain in their
+mounted controls until submitted, and are cleared after submission.
+
+Values are shared across environments of the same consumer root and are stored
+in `<consumer-root>/.runtime/plugin-configuration.json`, outside plugin packages,
+with owner-only file permissions. On POSIX, an existing file with any group or
+other-user permission is rejected before its contents are read. Restore its
+permissions with `chmod 600 .runtime/plugin-configuration.json` from the installation
+root; the host does not change permissions automatically. They are local plaintext
+configuration, not an
+encrypted vault. This file must not be committed, published, or shared with a
+plugin repository. The existing `.runtime/` exclusion also keeps it out of Git
+and packages. Settings override declared defaults; undeclared settings are not
+passed to plugins. A locally configured secret is bound to its declared name
+and environment-variable name and is delivered through `context.secrets.get`.
+Without a local override, the existing process environment remains the source.
+Saving plugin values does not write `.env` or change `process.env`. Browser revision
+tokens use a private process key rather than an unkeyed digest of secret-bearing
+content. Reload an open form after restarting its Web UI process.
+
+Keys removed from the current manifest, or whose environment binding changed,
+appear under **Keys no longer used by this plugin** without exposing their values.
+They remain saved until the user selects **Delete saved key** and saves. Ordinary
+settings edits do not delete them. A changed binding under the same key name
+requires explicitly deleting the old saved key before setting or clearing its
+replacement; both choices can be submitted in one save. Configure remains
+available for these keys even when the plugin has no current settings or secrets.
+
+For each secret, keep the current value, replace it, or explicitly clear it.
+Clear suppresses an inherited value for this plugin without deleting a shared
+environment variable. Clearing a required secret prevents the plugin from
+loading on the next Apply until the key is configured again. Remove retains
+local settings and secrets; a later installation review shows the retained
+settings and presence flags. Required secrets are checked before installation
+commits, and failed selection saves roll back the local configuration and package.
+
+## Install Community Plugins
+
+The **Installed** tab manages the existing catalog. **Discover** links to the
+[ABot Marketplace](https://abot-ai.com/marketplace/) and installs public GitHub packages independently of that directory.
+The Marketplace is a directory of community-owned repositories; listing approval
+does not grant a repository permission to run on a user's machine.
+
+Paste a repository URL in **Discover**, optionally choosing a branch, tag or
+commit and a folder inside the repository. **Review plugin** resolves the source
+to an exact commit, validates the manifest and its declared files without
+executing plugin code, and displays its tools and configuration form.
+Fill in required secrets before confirming installation.
+**Install and enable** downloads the same commit, checks the reviewed content
+digest, and installs it at `<consumer-root>/plugins/<manifest.name>`. Existing
+plugin IDs and capability IDs are rejected; this flow never replaces a plugin.
+Package publication and selection saving share the configuration lock with Apply;
+a failed save removes the uncommitted package before Apply can discover it.
+The normal configuration controls and global restrictions still apply.
+The review offers **Install and enable** at both ends. After installation, the
+UI returns to **Installed** with a status message. Choose **Apply changes** to
+load the plugin into the Runtime.
+
+Publishers must commit a complete package: `plugin.json`, its built CommonJS
+`.cjs` entrypoint, referenced skills and all required assets. Bundle dependencies
+that are not supplied by the public plugin SDK. Installation does not execute
+`npm install`, build commands, lifecycle scripts or repository code. Public HTTPS
+repositories on `github.com` are supported; private repositories, updates and
+Studio packages are outside this first installation flow. Repository ZIPs are
+limited to 25 MiB and 2,000 entries, with at most 16 MiB per extracted file and
+64 MiB total. Symlinks, traversal and non-portable filenames are rejected.
+
+### Install In ABot Links
+
+Computer Access setup registers the `abot:` URL scheme on Windows, macOS and
+Linux desktops. Existing installations can use **Update** in Computer Access
+to install Companion release 12 and register links while keeping their pairing.
+A website can render an ordinary link using this contract:
+
+```js
+const link = new URL("abot://install");
+link.searchParams.set("kind", "plugin");
+link.searchParams.set("repo", "https://github.com/owner/plugin");
+link.searchParams.set("ref", "v1.0.0"); // optional; a commit is recommended
+link.searchParams.set("path", "plugins/example"); // optional repository folder
+installAnchor.href = link.toString();
+```
+
+Clicking the link opens **Discover** in the Runtime saved in the local Computer
+Access pairing, with the source ready for review. A link cannot choose another
+Runtime address or bypass local installation confirmation. The browser may ask
+to open ABot. Without Computer Access, users can paste the same repository URL.
+Companion disconnect/uninstall removes its owned protocol registration.
+
+The local API uses `POST /runtime/plugins/inspect` with
+`{ repository, ref?, path? }`, returning `{ ok, review }`.
+Installation uses `POST /runtime/plugins/install` with
+`{ source: review.source, digest: review.digest }`. Both require same-origin
+JSON requests and completed Runtime setup. These APIs operate on the configured
+consumer root and configuration file; they do not depend on the Marketplace.
+
+## Remove Community Plugins
+
+**Remove** is available in the ongoing Plugins screen for packages installed by
+this GitHub flow. After confirmation, it saves a disable, applies configuration
+through the existing idle-owner checks, and only then deletes the installed
+folder. Built-in plugins and manually copied folders without an installation
+receipt do not offer Remove. Removal adds only the target's exact ID to
+`plugins.disabledPluginIds`, so names shared with other tools or qualified
+selectors cannot change another plugin's selection.
+
+If work starts after the disable was saved but before Apply, the files remain.
+Finish the active work, then choose **Remove** again. A failed Apply or any
+concurrent configuration change also prevents deletion. Removal verifies the
+moved directory before deleting it and retires its cached CommonJS modules so
+a later installation loads the new entrypoint and package-local dependencies.
+Selection rules remain in the configuration so removal cannot widen another
+plugin's allow policy. Installing the same plugin again clears its exact disabled
+ID and preserves other disabled IDs and capability-specific deny rules. Existing
+qualified denies are not inferred to be removal-generated; review such legacy
+rules explicitly in Advanced settings if they still disable the tools.
+
+`POST /runtime/plugins/remove` accepts `{ pluginId }`, with the same origin,
+JSON and completed-setup requirements as installation. It returns `removed`,
+`activation`, a status message and the refreshed plugin snapshot. This removes
+the installed plugin folder, including data the plugin kept inside it; files
+stored elsewhere are retained. If Apply succeeds but a later removal check fails,
+the error retains its HTTP status and code and includes `activation` with status
+`ready`. The UI refreshes the active environments; `config_changed` still marks
+the newer saved configuration as pending activation.
 
 ## Package Shape
 
@@ -84,12 +237,71 @@ options, or skill lists in `runtime.config.json`. Installing or changing a
 plugin means changing its package under `plugins/`; runtime config only decides
 whether that installed capability is available.
 
+## Runtime Platform Compatibility
+
+A plugin can declare where its code can run using a separate manifest extension:
+`extensions["ai.abot.compatibility"] = { "version": 1, "runtimePlatforms": ["linux", "darwin"] }`.
+The executable `ai.abot.runtime` extension remains at version 1.
+
+`runtimePlatforms` is a non-empty, duplicate-free list of Node platform names:
+`linux`, `darwin` (macOS), or `win32` (Windows). Unsupported versions, platform
+names and fields are rejected. Declare only platforms on which the complete
+plugin can safely load; individual operations may still require permissions,
+external programs or a connected computer.
+
+The declaration describes the **Runtime host**, not the browser or the computer
+controlled by a tool. A Linux Runtime in WSL or a Linux Docker container remains
+`linux`, including when SYSTEM controls a Windows Companion. It does not grant
+permissions or replace the tool's request-time target checks.
+
+Hosts with this compatibility support apply the following policy before resolving
+plugin settings/secrets or importing executable plugin code:
+
+- A declared matching platform can load, subject to the existing saved selection.
+- A declared non-matching platform cannot load.
+- Without a declaration, existing non-Windows behavior is preserved. Native
+  Windows reports **Compatibility not declared** and does not load the plugin.
+
+Installed, onboarding and model-selection views show compatibility separately
+from saved plugin/tool selection. Changing hosts does not rewrite saved selection
+or erase settings and keys. An incompatible package remains inspectable,
+configurable and removable. It can be installed for later use on a supported
+host; the review and installation result explain that it will not load here.
+Applying configuration cannot bypass the loader gate.
+
+**Older hosts:** ABot 1.7.0 accepts and preserves additional extension namespaces
+but does not enforce this declaration. Its existing behavior remains unchanged.
+This metadata is not an enforcement guarantee on older hosts, nor a claim that
+ABot 1.7.0 or its bundled plugins support native Windows. Existing bundled plugin
+manifests are not certified for Windows by this contract change.
+
+The required `windows-compatibility` CI job builds the Runtime, checks types and
+plugin packages, and runs the focused platform contract and loader suites on
+Windows with Node 24. It complements the Linux validation and macOS Companion
+checks; it does not certify all native Windows tool operations or Store packaging.
+
 ## Manifest Contract
 
 `@abot-ai/runtime/plugin-sdk` is the single public plugin-authoring entrypoint. It
 exports the manifest constants and types, entrypoint contract, and bounded
 authoring helpers consumed by plugin implementations.
 
+The SDK's `readBoundedRegularFile(path, { rootPath, maxBytes, signal })` reads one
+regular file within its authorized root and returns bounded bytes or a typed
+refusal. On native Windows, it uses the same C# handle primitives as `filesystem`,
+compiled by the built-in Windows PowerShell for each read. Root and file identity
+are checked before reading; traversal rejects reparse points beneath the root,
+including junctions. Binary content and documents up to 10 MiB are covered by
+native tests; each caller still sets its own size limit. Linux/macOS retain the
+existing no-follow file-descriptor path.
+
+A Windows policy or compiler restriction returns `safe_open_unsupported`. Plugins
+must report that safe reading is unavailable and avoid automatic retries or a
+less restricted fallback. Cancellation stops the helper and throws `AbortError`;
+a helper deadline (15 seconds) or ordinary I/O failure remains an explicit error.
+This SDK support does not enable Windows compatibility in a plugin manifest.
+Each plugin must still declare and validate its own Windows support.
+
 The manifest follows the Agent Plugins 1.0 package shape and keeps the local
 executable contract under `extensions.ai.abot.runtime`:
 
@@ -143,6 +355,16 @@ input, effect, and approval. Optional capability metadata such as client event
 presentation, payload authoring, development roles, and selection grounding
 belongs here as well—not in runtime orchestration.
 
+An operation may declare `outputChannels` alongside `summary`, for example
+`{"text":"content","data":"metadata"}`. Both fields are required when declared:
+`content` can carry substantive output (possibly bounded or summarized),
+`metadata` contains only identifiers/status/counts/receipts, and `conditional`
+depends on the operation inputs. Omission means unknown, not metadata. This
+passive declaration describes the saved Studio channels, not every field in a
+chat tool result; it changes no execution or binding behavior. Only selected
+Studio `prepare_draft` operations expose it to models; ordinary tool summaries
+and discovery stay concise. Whole Data bindings do not need field pointers.
+
 A plugin declares sensitive operations with `approval: "always"` in its
 manifest, as the bundled EXEC and SYSTEM plugins do. Apply that policy to every
 operation when the whole plugin is sensitive. The generic approval boundary
@@ -201,10 +423,14 @@ receive it. Planner uses this same brief instead of a separate aggregate-tag
 catalog. Its existing group-selection schema and Worker scope enforcement stay
 unchanged; descriptions do not select a group or execute an operation.
 
-Under `execution-agent-v1`, the canonical root receives group descriptions
-generated from member capability ids and summaries, and may mechanically open
-or extend its own RoleCall scope.
-It then selects a concrete capability only from that active scope. Scope
+Under `execution-agent-v1`, the canonical root receives every group and member
+in ASCII order on each decision, and may mechanically open or extend its own
+RoleCall scope. A capability's exact summary appears as `capabilityId: summary`
+at its first group membership; later memberships contain only its id, referring
+to that definition. The first group has no selection priority. Descriptions
+are neither sampled, truncated, nor synthesized. The active catalog supplies
+each capability's id and effect; its selection controls remain in the decision
+schema. It then selects a concrete capability only from that active scope. Scope
 updates, capability binding, payload authoring, adapter execution, and
 settlement use the same ledger and capability engine as delegated Worker
 execution. Unknown, empty, invalid, repeated, or no-op scopes are rejected
@@ -329,6 +555,36 @@ they must not include secrets and they never act as instructions, new user
 intent, or proof that the whole request completed. See
 [tool-execution-result-evidence-contract.md](tool-execution-result-evidence-contract.md).
 
+### Reporting a confirmed mutation
+
+Use `successResult()` for ordinary successful observations. After the owning
+plugin has confirmed a completed mutation, use `mutationSuccessResult()` to
+preserve its receipt and add the Runtime's required `data.mutationEvidence: true`:
+
+```ts
+import { mutationSuccessResult } from "@abot-ai/runtime/plugin-sdk";
+
+// apiReceipt is the result of a completed write already confirmed by this handler.
+return mutationSuccessResult({
+  output: "The article was published.",
+  data: apiReceipt,
+}, context.resultBudget);
+```
+
+The helper does not execute the operation or independently verify its effect.
+Do not use it for a failed, ambiguous, pending, or no-op operation. It retains
+the same JSON and result-size bounds as `successResult()`; a rejected receipt
+returns a failure without asserting mutation evidence. The existing generic
+helper does not infer a mutation from `ok`, `progress`, prose, or the presence of
+arbitrary data. Explicit `actions`, `progress`, and other result fields remain
+available to the owning plugin.
+
+The adapter records operation outcome separately from observed effect.
+For a `mutating` operation, `ok: true` without `mutationEvidence: true` is
+classified as `mutation_evidence_missing`. The new helper supplies that marker
+after the plugin has established the evidence; it does not change the Runtime's
+classification rules or prove completion of the user's whole request.
+
 ### EXEC output storage
 
 EXEC captures stdout and stderr in private files under its injected `stateDir`.
@@ -491,6 +747,54 @@ counts imply full-file coverage.
 
 No concrete tool or skill mapping should be added anywhere under `src/runtime`.
 
+### Native Windows plugin support
+
+The native Windows group contains `capability-brief`, `code-outline`,
+`document-reader`, `exec`, `filesystem`, `json-inspector`, `local-search`, `memory`, `web`,
+`project-orientation`, `system-probe`, and `system`.
+Each declares `win32` in its versioned
+`ai.abot.compatibility` extension, alongside its existing Linux and macOS support.
+Compatibility uses the Runtime process OS, not the browser or a paired computer.
+A Windows-only plugin should declare only `win32`; other hosts will not load it.
+
+On native Windows, SYSTEM provides `system_targets`, `system_command`,
+`system_applications`, and `system_launch`. Commands run in local PowerShell and
+retain existing approvals, cancellation, and protected output handling. Desktop
+observation and input (`computer_*`) are excluded from the request catalog in
+this phase. Linux/macOS Runtime and WSL/Docker Companion routes retain their
+existing capabilities. This phase does not add screenshot OCR.
+
+`system-probe` reports Windows load averages as unsupported instead of presenting
+the OS's placeholder zeros as measured load. Its default disk probe uses the
+Runtime installation's filesystem; an explicit path selects that path's volume.
+
+`code-outline` uses the SDK's bounded file reader on Windows, with the same
+authorized roots, parser and output limits as Linux/macOS. If safe reading is
+unavailable, it reports the restriction explicitly and tells the model not to
+retry or bypass it. See [Code Outline](../plugins/code-outline/README.md).
+
+`document-reader` uses the SDK's bounded Windows reader for configured paths
+and request attachments, with shared text, Office and PDF parsers and limits.
+A blocked reader reports an explicit no-retry restriction.
+See [Document Reader](../plugins/document-reader/README.md).
+
+`json-inspector` uses the SDK's bounded Windows reader with the existing path,
+UTF-8, size and summary limits. A blocked reader reports an explicit no-retry
+restriction. See [JSON Inspector](../plugins/json-inspector/README.md).
+
+`project-orientation` uses the SDK's bounded Windows reader for package
+metadata and retains its existing directory-tree and result limits. Blocked
+manifest reads return an explicit no-retry restriction.
+See [Project Orientation](../plugins/project-orientation/README.md).
+
+`local-search` uses native Windows ripgrep through a PowerShell/C# helper that
+pins the selected path and owns the child process through a Job Object. Existing
+query, output, timeout and cancellation limits still apply. A blocked helper
+fails explicitly without a retry or policy bypass.
+See [Local Search](../plugins/local-search/README.md).
+
+Enabling manifests alone is not a validation step.
+
 ### Shared Computer access
 
 Plugins that need host facilities can import the opt-in

package/docs/projects-and-full-plus.md

@@ -206,12 +206,8 @@ system action. Cancellation or revocation attempts to stop an in-flight command,
 but effects already performed are not rolled back. If a connection is lost during
 execution, inspect the actual host state before trying the action again.
 
-## Validation status
+## Platform validation
 
-Implementation and validation progress are recorded in the task journal. Native
-Mac QA is performed separately with the owner; mocked platform tests are not a
-claim that an actual Mac was tested. No release or installation update is implied
-by changes in a development worktree.
 Native Windows/macOS companion installation, login startup and visible-application
-QA remain separate checks on the real desktop systems; Linux protocol and package
+behavior require checks on the target systems; Linux protocol and package
 tests do not establish those results.

package/docs/runtime-library.md

@@ -13,7 +13,6 @@ For invariant coverage, see
 [runtime-invariant-coverage.md](runtime-invariant-coverage.md).
 For bridge/runtime ownership, see [bridge-compatibility.md](bridge-compatibility.md).
 For current limitations, see [known-limitations.md](known-limitations.md).
-For package and publication gates, see [publishing.md](publishing.md).
 
 ## Basic Composition
 

package/docs/tool-execution-result-evidence-contract.md

@@ -96,6 +96,63 @@ secrets. Secret acquisition and redaction remain responsibilities of the
 owning tool/host boundary; core orchestration must not guess sensitive field
 semantics from arbitrary JSON keys.
 
+### Observed-content secret protection, version 1
+
+Companion and the internal passive collector own host-side protection. The same
+collector protects SPARK whether it runs inside Companion or locally in Runtime.
+SYSTEM owns a separate implementation for its independent native operations.
+The implementations share conformance cases, not a runtime detector dependency.
+
+Required text checks preserve the existing SPARK whole-field detector: credential
+labels, authorization/userinfo, supported provider tokens, private-key indicators
+and compact JOSE tokens, including the supported escaped and encoded forms.
+Successful checking means no known indicator was found; it is not a claim that
+the content contains no secrets. Unknown encodings and arbitrary unlabelled
+secrets remain outside detection. SPARK's existing collection semantics stay intact.
+
+Check full observed fields before excerpts or delivery. A suspected field is
+replaced with `[REDACTED]`; unchecked content must not reach logs, model evidence,
+continuation snapshots or cross-host transport. Desktop frame/media retention
+also follows these checks. Temporary local acquisition belongs inside the checking
+boundary; checking must not use a remote model.
+An incomplete required check, malformed encoding or scanner failure withholds
+the affected content and preserves only a non-sensitive technical receipt.
+
+Command capture may write unchecked bytes to private local files using the existing
+disk-backed capture mechanism. After natural EOF, both full streams must pass
+checking before any read or delivery is admitted. Suspected content is replaced
+with checked text; failed checking withholds output and attempts to remove the raw
+capture. Existing retention cleanup handles leftovers after failure or interruption.
+This permits temporary raw disk storage, not model access before checking; the
+compaction model must also receive only checked text. Deletion is ordinary file
+cleanup, not a claim of forensic erasure.
+
+There is no new logical total-output quota: admitted complete stdout/stderr retain
+the existing context-text handoff, canonical evidence and core compaction path.
+Full-text checking and delivery still materialize text in memory. Capture/storage
+failure does not erase an already dispatched action or justify replaying it for
+output. Published byte counts and digests describe admitted bytes only.
+
+Version 1 desktop checks cover descriptive metadata and accessibility text.
+Suspicion in those fields also withholds the associated image before frame or
+media retention. Control bindings, coordinates and dispatch receipts keep their
+mechanical meaning; sensitive actionable catalog identities are withheld rather
+than replaced by a synthetic actionable identifier. Pixel-only content is not
+inspected: OCR and its deployment requirements are explicitly deferred.
+
+SYSTEM requires `host_secret_protection_v1` before dispatching protected Companion
+operations, and the existing complete-output capability for commands. A missing
+capability is an upgrade-required failure before dispatch, not a fallback to an
+unprotected path. Installed Companion and independently distributed SYSTEM bundles
+must be validated separately; changing Runtime source does not update either.
+
+Conformance covers known indicators, ordinary text, encodings and chunk boundaries,
+late suspicion, scanner/transport failure, pre-admission storage and frame sinks,
+and preservation of exact clean large output and accepted action receipts. Both
+supported implementations must pass the same applicable cases before release.
+This contract does not sandbox an arbitrary third-party plugin's own filesystem
+or network access, nor retroactively remove previously retained observations.
+
 ## Canonical Lifecycle
 
 ```text

package/docs/windows-companion-store.md

@@ -0,0 +1,132 @@
+# Windows Companion Store delivery
+
+## Current status
+
+**ABot AI Companion** is available from
+[Microsoft Store](https://apps.microsoft.com/detail/9PK2FDQQLQS9), product ID
+`9PK2FDQQLQS9`. Runtime 1.7.0 provides the guided connection flow described below.
+
+The Store app and Runtime have separate releases.
+
+## Connection experience
+
+A Runtime running directly on Windows uses local access and collection without
+Companion pairing. The Store connection remains available for a Windows computer
+used with a WSL or Docker Runtime. Spark also requires an installation-wide
+collection acknowledgment in the Web UI; accepting it does not start collection.
+
+The Web UI links to the Store for one installation. The user returns to ABot,
+requests a connection link and explicitly opens Companion. Companion shows the
+Runtime address and asks for confirmation before pairing. Users who already
+installed Companion go directly to connecting. The Web UI confirms the live
+connection after pairing.
+
+Before **Allow connection** is enabled, users must select an initially unchecked
+acknowledgment of the described computer access and data sharing. The dialog
+links to the [software terms](https://abot-ai.com/terms/#software) and
+[privacy policy](https://abot-ai.com/privacy/#software); opening either link does
+not grant consent. Task permissions and optional SPARK controls remain separate.
+Disconnecting does not erase data already sent to the Runtime or other services.
+
+For a paired computer that is offline, **Open Companion** uses the fixed
+`abot-companion://open` activation without creating an invitation. It opens the
+saved connection or explains how to re-pair when local credentials are missing.
+**Set up again** requires confirmation, revokes the old server pairing using
+the existing endpoint, then requests a fresh invitation. An upgrade invitation
+never substitutes for a new pairing grant when local credentials are missing.
+After explicit consent, a fresh connection consumes the new grant even when an
+old local credential remains. The previous owned process is stopped before that
+exchange. A failed exchange preserves the saved credential but does not restart
+the previous process;
+an upgrade continues to use the matching saved host identity.
+
+Every user installs the same package. The personalized, expiring invitation is
+sent through the `abot-companion:` protocol after installation. It carries the
+existing pairing or upgrade grant, not a second authentication scheme. The Web UI
+keeps it only in the current surface, clears it after connection or expiry, and
+does not save it to browser storage. Do not put connection links in logs, support
+reports or screenshots.
+
+The current invitation contract accepts a local HTTP loopback Runtime address.
+Docker must publish its Web UI port on the Windows host's loopback; other setups
+must expose the Runtime through an appropriate local forward. Opening ABot on a
+different computer does not make that remote Runtime address a valid invitation.
+
+## Shared components
+
+| Owner | Responsibility |
+| --- | --- |
+| Shared Web UI connection manager | Connection status, readiness polling, unpairing and onboarding lifecycle. |
+| Windows Store UI module and route | Store link, temporary invitation and explicit launch. The route uses the existing pairing store. |
+| Windows desktop shell | Display connection status and consent, activate links and call the bundled Node entry. |
+| Shared Companion and CLI lifecycle | Pairing credentials, command and desktop capabilities, connection protocol, reconnect behavior and permission checks. |
+| Windows Store lifecycle adapter and MSIX package | Windows package activation, startup integration, notification identity and package updates. |
+
+The desktop shell does not implement another pairing store or copy the Companion
+protocol. Shared fixes belong in the shared Companion implementation; Windows
+presentation and package integration stay in the Windows adapter. The package
+contains the runtime dependencies needed for connection.
+
+The Store integration changes Windows delivery. Native macOS connection, manual
+Mac connection, Linux setup and WSL command routing keep their existing owners
+and behavior. A WSL Runtime can use the Windows desktop Companion without a WSL
+restart.
+
+## Version and update ownership
+
+The **MSIX package version** orders Windows package updates. The **Companion
+release version**, owned by `src/computer-access/companion/release-version.ts`,
+describes the Companion behavior expected by the Runtime. These are different
+values: a packaging or shell-only rebuild can require a newer MSIX version
+without changing the Companion release contract.
+
+If the Runtime requires a Companion release newer than the installed package,
+the invitation is rejected with a request to update through Microsoft Store.
+The Store supplies the replacement package; the Runtime does not overwrite
+Store-owned executable files. Store updates are intended to preserve the user's
+saved pairing.
+
+The Store identity is owned by
+`src/computer-access/companion/windows-store/identity.ts`. Packaging and the
+Companion must use this same identity. Do not create another copy of protocol
+version or package identity policy in the Web UI or desktop shell.
+
+## Build from source
+
+Build Companion from this repository.
+The build uses the pinned Windows Node.js distributions, checking the archive
+hash before extracting only `node.exe` and its license. Supply an explicit
+four-part Store version with a zero last component.
+
+```sh
+npx tsx scripts/build-windows-companion-store.ts \
+  --output-dir <new-layout-directory> \
+  --node-archive <verified-node-windows-zip> \
+  --version <major.minor.patch.0> --architecture x64
+```
+
+Then, in Windows PowerShell, use the .NET Framework compiler and an authentic
+Microsoft Windows SDK `MakeAppx.exe`:
+
+```powershell
+./scripts/build-windows-companion-store.ps1 `
+  -LayoutDirectory <layout-directory> `
+  -MakeAppxPath <local-windows-sdk-makeappx-path> `
+  -OutputPath <new-msix-path>
+```
+
+Keep the SDK tools on a local Windows volume. Package inputs and output can
+remain in the WSL checkout. The output is unsigned and is not installed,
+registered, signed or submitted by these scripts.
+
+## Package contents
+
+The public source includes the Windows shell and packaging scripts. The MSIX
+contains the compiled shell, bundled shared Companion, pinned Node executable,
+licenses, icons and Windows manifest. The Store package and Node executable are
+not part of the Runtime npm package.
+
+Pairing invitations are generated when the user requests a connection. They are
+never baked into the Store package. Local configurations, API keys, saved pairing
+and logs must stay outside the Store package. Store product and publisher identity
+values are public package metadata, not authentication credentials.

package/package.json

@@ -18,12 +18,14 @@
   },
   "description": "Open runtime for local AI agents.",
   "devDependencies": {
+    "@actions/expressions": "^0.3.61",
     "@types/node": "^25.5.2",
     "esbuild": "^0.28.2",
     "prettier": "^3.8.1",
     "tsx": "^4.23.13",
     "typescript": "^6.0.2",
-    "vitest": "^4.1.11"
+    "vitest": "^4.1.11",
+    "yaml": "^2.9.1"
   },
   "engines": {
     "node": "^20.19.0 || >=22.12.0"
@@ -95,11 +97,11 @@
     "docs/bridge-compatibility.md",
     "docs/configuration.md",
     "docs/installation.md",
+    "docs/windows-companion-store.md",
     "docs/known-limitations.md",
     "docs/long-term-memory.md",
     "docs/plugins.md",
     "docs/projects-and-full-plus.md",
-    "docs/publishing.md",
     "docs/running-locally.md",
     "docs/runtime-invariant-coverage.md",
     "docs/runtime-library.md",
@@ -128,7 +130,7 @@
     "plugins/system-probe/",
     "plugins/web/"
   ],
-  "homepage": "https://github.com/Dorshitrit/abot-runtime#readme",
+  "homepage": "https://abot-ai.com/",
   "keywords": [
     "llm",
     "runtime",
@@ -181,5 +183,5 @@
   },
   "type": "module",
   "types": "./dist/src/runtime/index.d.ts",
-  "version": "1.6.0"
+  "version": "1.8.0"
 }

package/plugins/capability-brief/plugin.json

@@ -4,6 +4,10 @@
   "version": "1.0.0",
   "description": "Describe the request-effective ABot tool catalog on demand.",
   "extensions": {
+    "ai.abot.compatibility": {
+      "version": 1,
+      "runtimePlatforms": ["linux", "darwin", "win32"]
+    },
     "ai.abot.runtime": {
       "version": 1,
       "entrypoint": "./src/index.cjs",