@abot-ai/runtime 1.5.0 → 1.7.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
 
@@ -143,6 +296,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
@@ -307,10 +470,17 @@ explicitly, provide the required string `output` and boolean
 `producedNewInformation`, and place structured operation facts needed by later
 steps in `data`. JSON-safe here means primitives, plain objects, and dense
 arrays with finite numbers: no functions, symbols, accessors, cycles, class
-instances, or other non-plain prototypes. The complete normalized result must
-fit the Runtime's 256 KiB serialized producer boundary. A plugin must return an
-explicit bounded or paginated result, or an explicit failure; neither the
-plugin nor the Runtime may silently remove structured facts.
+instances, or other non-plain prototypes. Results use a 256 KiB serialized
+envelope boundary. A context-aware host exposes `context.resultBudget`; pass it
+to `deliverPluginTextResult(result, ["stdout", "stderr"], context.resultBudget)`
+to hand exact large text to the existing context manager. The helper keeps
+ordinary results unchanged. When needed, it declares `contextTextFields` on
+the original result; metadata and references still count toward the byte limit.
+Only `output`, `stdout`, and `stderr` are eligible string fields. The Runtime
+retains their full content and applies token admission and compaction before
+model invocation. This does not manage the plugin's output storage or RAM.
+Hosts without this contract and plugins that do not opt in retain their
+existing result limit. Neither plugin nor Runtime may silently remove facts.
 
 `ToolRegistry` adds the selected tool identity and creates the canonical
 `ToolExecutionResult`. The Runtime validates and persists that complete result,
@@ -322,6 +492,39 @@ 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).
 
+### EXEC output storage
+
+EXEC captures stdout and stderr in private files under its injected `stateDir`.
+Pipe backpressure bounds queued capture data; the plugin does not accumulate a
+process's entire output in RAM while it runs. Disk writes use 64 KiB chunks, an
+I/O buffer size independent of the model context budget. A storage failure stops
+the producer and returns its process ID, status, cursor and committed byte
+counts; it never claims that incomplete output was successfully delivered.
+
+Delivery materializes the pending observation into the existing text-result
+contract. This still requires memory proportional to that observation; this
+contract is not streaming ingestion by the Runtime. The core owns token
+admission and compaction. It does not read EXEC file paths or manage its storage.
+
+Offsets advance only after the result fits the host's delivery contract. ASK
+state stores plugin-owned, session-bound disk receipts with range hashes, rather
+than copying the full text. Previously saved inline receipts remain readable.
+`outputRetentionMs` defaults to 604,800,000 (seven days) from capture closure,
+including unaccepted output and receipts saved for approval continuation. Reading,
+restoring or accepting a receipt does not extend retention. Active writers and
+readers prevent deletion until they finish. Interrupted and legacy captures
+without a closure timestamp expire using their last captured-file modification.
+
+The plugin sweeps existing storage when loaded and periodically while files
+remain (at most one hour between sweeps). A stopped runtime resumes cleanup when
+the plugin loads again. Expired output returns an explicit tool failure with the
+process ID; it never replays a command. Retention bounds age, not total disk usage.
+Preparation does not create storage directories, and cleanup belongs to EXEC.
+
+Concurrent terminal observations reserve one delivery before leaving the process
+transition. Rejected presentation releases the reservation without consuming any
+output. The same rule applies to restored terminal receipts.
+
 ## Filesystem Roots
 
 `environment.paths.agentWorkDir` is the configured primary work root. Plugins
@@ -406,13 +609,15 @@ searches use procfs; macOS searches inherit the verified current directory of
 an isolated Node child. File content searches use the held input descriptor on
 both platforms. A search fails closed when its authority cannot be established.
 
-All output and structured data must be bounded at the producer. The shared SDK
-reserves wrapper headroom by rejecting plugin results above 128 KiB before they
-reach the Runtime's 256 KiB canonical settlement boundary. Bounds include
-filesystem iteration, file/archive input, collection size, individual labels,
-and rendered text. A truncated success reports machine-readable truncation
-metadata; an operation that cannot produce a truthful bounded result fails
-explicitly.
+Plugins own resource bounds such as filesystem iteration, file/archive input,
+collection size, and buffered process output. Passing `context.resultBudget`
+lets the shared SDK use the Runtime's final envelope accounting, including
+canonical metadata and target references. Without it, the SDK measures the
+plugin object and the Runtime checks the canonical envelope separately.
+Declared context text is preserved separately from that byte
+accounting and remains subject to the complete model-input budget. An explicit
+truncated success reports machine-readable truncation metadata; an operation
+that cannot produce a truthful result fails explicitly.
 
 The bundled `exec` plugin provides trusted, non-interactive `/bin/bash` execution
 on Linux and macOS. Execute, wait and cancel each declare `approval="always"`:

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/runtime-public-contracts.md

@@ -248,8 +248,13 @@ the reported result, not overall completion.
 
 The complete result is a mandatory canonical evidence object. Before capability
 settlement, the Runtime validates that it contains only plain JSON-safe data and
-fits the 256 KiB serialized producer boundary. Functions, symbols, accessors,
-cycles, non-plain prototypes, non-finite numbers, and oversized results fail
+fits the 256 KiB serialized envelope boundary. Registered results may declare
+`contextTextFields` (`output`, `stdout`, or `stderr`) whose exact text bodies are
+budgeted by the existing model-context admission and compaction path. The text
+is retained in the same canonical fields; metadata remains byte-bounded.
+Results without this declaration retain the complete-result byte limit.
+Functions, symbols, accessors, cycles, non-plain prototypes, non-finite numbers,
+and oversized metadata fail
 explicitly. The Runtime does not silently truncate, partially parse, or discard
 structured fields.
 

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

@@ -77,10 +77,17 @@ The Runtime validates the result before ledger settlement:
 - no functions, symbols, accessors, cycles, or non-plain prototypes;
 - the registered result must match the public `ToolExecutionResult` fields;
 - references remain bounded by the RoleCall reference contract;
-- one serialized canonical adapter result is limited to 256 KiB.
-
-The 256 KiB limit is a hard producer boundary, not a model-context truncation
-rule. An over-limit result becomes an explicit technical capability failure.
+- the serialized canonical envelope is limited to 256 KiB. A registered
+  result may declare `contextTextFields` from `output`, `stdout`, and `stderr`;
+  those exact string bodies use the model-context budget instead. Field names,
+  declarations, references, and all other result data still count toward 256 KiB.
+
+The 256 KiB limit is a producer metadata boundary, not a model-context truncation
+rule. Without a text declaration it applies to the complete result as before.
+Declared text remains in the canonical result and follows the same provenance,
+consumer projection, token measurement, and semantic compaction as other tool
+evidence. The declaration grants no action or completion authority. Oversized
+metadata still becomes an explicit technical capability failure.
 The Runtime never sends a syntactically valid but incomplete object and never
 pretends that omitted structured facts were observed.
 

package/docs/windows-companion-store.md

@@ -0,0 +1,127 @@
+# 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
+
+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

@@ -95,11 +95,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 +128,7 @@
     "plugins/system-probe/",
     "plugins/web/"
   ],
-  "homepage": "https://github.com/Dorshitrit/abot-runtime#readme",
+  "homepage": "https://abot-ai.com/",
   "keywords": [
     "llm",
     "runtime",
@@ -181,5 +181,5 @@
   },
   "type": "module",
   "types": "./dist/src/runtime/index.d.ts",
-  "version": "1.5.0"
+  "version": "1.7.0"
 }