@abot-ai/runtime 1.4.0 → 1.6.0

package/docs/long-term-memory.md

@@ -20,7 +20,12 @@ structured candidate-only call:
   "memoryCandidates": [
     {
       "content": "A durable fact or preference established by the user.",
-      "tags": ["normalized-later-by-core"]
+      "tags": ["normalized-later-by-core"],
+      "target": null,
+      "score": 95,
+      "reason": "A lasting preference explicitly established in this request.",
+      "reinforced": true,
+      "explicitRequestQuote": null
     }
   ]
 }
@@ -40,6 +45,11 @@ unchanged.
 Candidate data remains internal and is processed after the final assistant
 response is persisted. Persistence runs through a Runtime-owned background
 queue; response completion never waits for embedding or memory-store work.
+When the current user directly asks the assistant to remember a fact, the same
+authoring result can include an exact excerpt of that request. The Runtime
+binds the excerpt to the current user message and writes the fact through the
+existing protected memory management path, without candidate maturation or a
+second model call. A queued write is not confirmation of storage.
 
 Before the next terminal response is authored, the Runtime retrieves a small
 relevant set from the cross-session pool. Retrieval uses provider embeddings
@@ -52,6 +62,62 @@ contracts differ. Automatic retrieval remains a terminal-response feature.
 Planner, Worker, Reviewer, payload, and tool contexts do not receive the memory
 projection.
 
+## Shared Automatic Admission
+
+Conversation proposals and ABot Spark observations use one core maturation owner
+and the same candidate pool, even when ABot Spark collection or processing is off.
+Candidates are excluded from recall until promoted. The default promotion
+score is 90 and can be set from 0 to 100, with at least two independent
+evidence opportunities. A first proposal always
+remains a candidate, even with a score of 100. Repeated input, replayed batches,
+unchanged screen revisits and scheduled reassessment alone cannot supply fresh evidence.
+The score expresses model judgment, not a statistical probability.
+
+The model proposes durable usefulness, semantic identity, score and a short
+reason. The core binds request/batch identity, versions and evidence timestamps;
+it controls admission, expiry, deduplication and storage. Prior knowledge is
+bounded passive reference, not fresh evidence. Task diaries, temporary activity,
+QA data and unsupported inferences about the user are excluded by the shared
+authoring policy. This adds no separate judging model call.
+
+Automatic content changes to an existing memory also pass through a replacement
+candidate and the same admission gate. A replacement is bound to the original
+record version; a manual edit or deletion wins. Manual records remain protected
+from automatic changes. Existing stored records are preserved, rather than
+retroactively deleted or demoted.
+
+The shared policy is persisted with memory state. Older Co-worker settings are
+imported once, respecting the new minimum; later stale callers cannot overwrite
+the canonical policy. Candidates are bounded by 500 entries, 2 MiB and 30 days
+without reinforcement by default. Store version 5 preserves older records and
+creates a private `.pre-v5.backup` before migration. ABot 1.4.0 cannot read the
+upgraded store; preserve that backup if a downgrade may be needed. Old candidates
+receive no invented independent evidence.
+
+Candidate and receipt expiry belongs to the core memory service, even without a
+running ABot Spark. It uses one deadline timer, no periodic polling or model calls,
+and no timer when nothing awaits expiry. Standalone service owners can stop and
+restart retention through `memory.retention`; Runtime hosts own that lifecycle.
+Conversation evidence uses the same reference clock as memory admission.
+
+## Explicit Memory Plugin
+
+The `memory_add`, `memory_get`, `memory_search` and `memory_delete` tools belong
+to the independent memory plugin. They use its own deterministic store without
+an embedding model or the core long-term memory service. Their storage format,
+legacy migration and tool-permission behavior remain unchanged.
+
+Plugin records are separate from core Stored memories and its candidate pool.
+Manual creation and editing through the existing core memory management UI
+remain immediate and protected; they atomically discard matching candidates
+and pending replacements of an edited memory. Automatic conversation proposals
+still use shared maturation. Only a direct user request bound to the current
+message may use the protected core write; the plugin remains independent.
+
+Live QA should use a separately configured environment with its own runtime
+directory. Shared admission reduces accidental automatic storage, but does not
+replace isolation for tests that deliberately exercise explicit memory writes.
+
 ## Model-Requested Recall
 
 When memory is enabled, the Supervisor and Execution Agent root decisions may
@@ -123,7 +189,7 @@ performs a real embedding probe and validates the complete candidate config
 before writing it. The previous config is backed up, and a restart is required
 after enablement or disablement.
 
-The Config workspace in the packaged Web UI uses the same onboarding service.
+**Memory → Setup** in the packaged Web UI uses the same onboarding service.
 It can list configured providers, discover models when the provider supports
 discovery, probe and enable a selected model, or disable the feature. A provider
 without discovery support accepts a model id entered by the user.
@@ -220,3 +286,145 @@ candidates.
 The bundled `memory` plugin remains a separate, explicit user-invoked
 capability. Passive long-term memory does not depend on that plugin and remains
 operational if the plugin is disabled or removed.
+
+## Learning from computer activity
+
+The **ABot Spark** screen controls optional collection, learning and proactive
+suggestions. The separate **Memory** screen manages embedding setup and saved records;
+Spark's Knowledge tab shows candidates. Collection and proactive mode are off by
+default. Collected
+text is processed by the provider of the selected model; learning also requires
+working long-term memory. Collection needs a connected Companion.
+
+In **Spark → Settings → Activity permissions**, choose which activities to
+authorize and their configured models, then **Save settings**. Saving validates
+the selected models without starting work. Use each activity's **Start/Stop**
+control to run or stop it. Stopping preserves its authorization, schedules,
+resource limits and pending work. Revoking permission stops the activity and
+prevents it from starting until authorized again. Home's Start action starts all
+authorized activities together.
+
+The controls are independent. **Stop collection** stops new observations while
+already collected activity remains eligible for processing. **Stop learning**
+interrupts learning and keeps pending activity within its retention limit; it does
+not stop collection. Proactive mode has its own control and can use existing
+knowledge without new collection. **Delete pending** is a separate confirmed action
+that removes queued activity and cancels its review. Deleting pending activity
+does not delete saved memories. Starting collection does not resume explicitly
+paused processing. Older settings that were off and have no processing
+preference load with processing paused.
+
+Choose a learning model explicitly. Proactive reviews can use that model or a
+separate profile. Configure collection, learning and proactive activity hours
+independently, with an explicit time zone. Learning can start on a time interval
+or after an eligible observation count; an admitted pass drains in bounded batches.
+Storage pressure can admit eligible work earlier, subject to the same hours,
+pause and resource limits. Pending evidence expires after 24 hours. Interactive
+requests take priority and can interrupt background work for later resumption.
+
+Learning and proactive activity share persisted daily model-call and embedding
+limits. Each actual model stage consumes a call; these limits are not monetary
+or token budgets. Local or unclassified providers run one operation at a time;
+known cloud operations can use the configured concurrency. No observation review
+runs for an empty queue, although enabled proactive checks and due knowledge
+reassessments can run independently.
+
+The Companion listens for desktop accessibility events in the signed-in graphical
+session. It collects settled visible text and editable-control changes across
+applications, including documents, editors and browsers. Repeated content is
+deduplicated; revisits retain a compact activity reference. Observations retain
+their application/window identity and declared coverage, then enter bounded batches.
+An editable control changing does not establish authorship, and a visible page
+does not prove that the user read or agreed with it.
+
+The selected profile's execution policy determines the review method. Execution
+Agent profiles use a direct review. Supervisor profiles use bounded stages for
+discovery, matching, decisions, authoring and assessment, with at most 18 stages
+per learning review and four per proactive review. Each fresh stage calls the
+model; replaying valid completed stages does not. Completed stages are saved
+before the next call and can resume after pauses, resource deferrals or
+restart while the evidence, knowledge and model bindings remain valid. Changed
+or expired inputs invalidate saved progress. Neither method can invoke tools or
+perform the suggested action.
+
+Learning proposals use the shared automatic memory-admission policy described
+above. Proactive reviews may deliver a suggestion to a conversation, decline to
+send one, or schedule reconsideration. They respect independent activity hours,
+daily message limits, current knowledge versions and duplicate-delivery controls.
+Reading a delivered suggestion clears its unread Home presentation.
+
+The Applications tab has separate collection and processing exclusions. A
+processing exclusion retains pending observations under the existing expiry
+limits; it does not retract content already sent to a provider or delete saved
+memories. Previously collected activity remains explicitly deletable.
+
+Before an observation leaves the Companion, supported credential labels and
+recognizable secret formats trigger redaction of the entire affected text field
+as `[REDACTED]`. This covers captured content, source metadata, URLs and diagnostic
+reasons across applications. Surrounding ordinary text in that field is also
+removed, which can reduce learning detail; other fields remain available.
+Recognition uses a bounded rule set: unlabelled secrets and unknown formats or
+encodings can still pass through. This protection applies to newly collected
+observations after the updated Companion is running; existing stored observations
+are unchanged.
+
+Native reads are at least five seconds apart. A sustained sequence of non-edit
+changes is muted after four reads within 30 seconds, before another accessibility
+extraction. A foreground-window switch, an editable-control change or 30 seconds
+without changes releases the mute. Quiet screens do not trigger periodic reads.
+This limits noisy movie/game interfaces without identifying specific applications.
+
+Stopping collection closes the native reader and its timers. The Companion's
+connection remains available for Computer access; it watches connection-file
+changes and checks private state every 15 seconds instead of every second.
+Status writes replace a single bounded file and retain private-file permission
+checks. This is maintenance, not screen collection or model execution.
+
+The pending queue is capped at 256 observations and 2 MiB of serialized evidence;
+the raw journal holds at most 50 batches within 4 MiB. These are data bounds,
+not total process-RAM limits. Existing memory-store retention remains unchanged.
+
+The current Companion excludes ABot's own Web UI by its canonical window title
+before transport, including tabs left open with the previous canonical title.
+This requires an updated Companion and an operating system that exposes the
+window title; a hidden or rewritten title cannot be identified by this rule.
+Previously saved memories and observation history are unchanged.
+
+Windows uses UI Automation and window events. macOS uses Accessibility and a
+Swift helper; the host needs its Swift toolchain and must grant Accessibility
+permission. Linux uses a graphical session with Python AT-SPI, D-Bus and GLib
+bindings and accessible session-lock status. Missing dependencies or permissions
+are reported without installing software or escalating privileges. Wayland and
+application accessibility coverage varies: protected controls, inaccessible
+canvas content and unexposed document text remain missing, rather than being
+presented as observed. The activity collector does not capture video, audio,
+keystrokes, clipboard history or perform OCR.
+
+For WSL, run the Companion on Windows. For Docker, run it on the native desktop
+host. The Companion connects to the Runtime endpoint published or forwarded on
+host loopback; the container or WSL process does not read the desktop itself.
+The paired device grants one learning subscription at a time, so a second
+environment cannot silently start duplicate collection. Connection leases stop
+native collection when its authorized owner disconnects.
+
+ABot Spark shows collection state, recent batches and bounded observation
+detail. Memory shows saved records and their configuration. Home shows a compact
+learning section while collection is enabled or unprocessed activity remains,
+including disconnected, failed and paused-processing states.
+These screens receive invalidation events
+and fetch canonical state; they do not poll for screen data or create collectors.
+Raw batch evidence is local, private runtime state with a bounded history and
+24-hour expiry cleanup while the service runs and at startup. A stopped process
+cannot execute cleanup until it starts again. The general model-I/O trace omits
+learning payloads and model output; diagnostics retain identifiers, counts and
+failure codes. The batch details view makes partial collection visible.
+
+Connected Companions report a release number independently of the wire protocol.
+ABot Spark offers setup again when that release is older than the Runtime's bundle
+or was not reported by an older installation. The installer still verifies the
+exact bundle and replacement process; a newer Companion is not downgraded by this
+notice. Update through Computer access to replace the installed native bundle.
+
+Native platform support must be verified on the target desktop and applications.
+Fixture tests of the transport and collector scripts alone are not proof of
+desktop coverage or the quality of learned memories.

package/docs/plugins.md

@@ -13,7 +13,7 @@ the same physical directory, the catalog is discovered only once.
 
 ## Manage Plugins In The Web UI
 
-Open **Configuration → Plugins** to see installed manifests, capability counts,
+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.
 Choose **Manage tools** on a plugin to manage its declared tools inside the same card.
@@ -307,10 +307,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 +329,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 +446,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"`:
@@ -448,3 +490,13 @@ counts imply full-file coverage.
    restrictive allow-list.
 
 No concrete tool or skill mapping should be added anywhere under `src/runtime`.
+
+### Shared Computer access
+
+Plugins that need host facilities can import the opt-in
+`@abot-ai/runtime/plugin-sdk/computer-access` facade. It exposes native target and
+computer backend contracts and the existing bound Companion client. The Runtime
+owns installation, pairing and connection lifecycle; plugins must not install
+another companion or import another plugin's implementation. Tool permissions,
+request disposal, target binding and exact-action approval remain the plugin's
+existing execution contract. Disabling SYSTEM does not disable ABot Spark.

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

@@ -113,7 +113,7 @@ action may start; it does not lower that process's OS permissions.
 
 ## Connecting a Docker Runtime to its computer
 
-A Docker Runtime can use applications and commands on its Windows or macOS host
+A Docker Runtime can use applications and commands on its Windows, macOS or Linux host
 through the optional native host companion. The companion runs as the signed-in
 desktop user and connects outbound to the Runtime's published loopback Web UI
 address. It does not require a Docker socket, a privileged container, a Windows
@@ -126,12 +126,14 @@ Linux target; discovery identifies Docker separately from WSL.
    loopback port mapping (for example, `-p 127.0.0.1:5184:5184
    -e ABOT_WEB_TRUST_LOOPBACK_PUBLISH=1`). Open the Web UI using its configured
    hostname and port.
-2. In the initial **Computer** step or **Config → Connected computer**, download
-   the setup script for the computer running Docker. Open the Windows script, or
-   extract the Mac ZIP and open its executable command file, on that computer.
-3. The script installs a private, checksum-verified Node runtime and the exact
-   companion build supplied by this ABot installation. It pairs automatically
-   using a single-use grant valid for 15 minutes, without a copied code or command.
+2. In the initial **Computer** step or **Home → Computer access**, choose
+   the computer running Docker. On a Mac, choose **Connect a Mac**, install the
+   same ABot version's CLI locally, run the displayed command in Terminal and
+   enter its separate one-time code. That code is valid for five minutes.
+3. On Windows or Linux, download and run the setup script. Windows setup installs
+   a private, checksum-verified Node runtime; Linux uses an existing Node runtime.
+   The script installs the exact companion build supplied by ABot and pairs
+   automatically using a single-use grant valid for 15 minutes.
 4. The companion saves a private credential and starts now and at future user
    logins. The Web UI polls actual connection readiness. Downloading the script
    alone is not a successful connection; wait for **Ready**.
@@ -154,15 +156,11 @@ Web UI origin. They do not disable TLS validation for unsupported HTTPS setups.
 
 One computer connection is shared by all Runtime environments belonging to the
 same ABot installation. The native user can pair with one installation at a time;
-disconnect before connecting another. Existing native macOS operation and Windows
-operation through functioning WSL interop do not require this companion. The
-setup screen checks those direct paths first. If WSL Windows execution is
-unavailable, it offers a Windows interop repair script instead. The script
-preserves unrelated `wsl.conf` settings, including `appendWindowsPath`, then
-automatically restarts only the selected distribution without a typed confirmation.
-Finish active work before opening the file: the restart interrupts all services
-in that distribution. If the configuration update fails, no restart occurs.
-The script and GUI verify actual Windows execution after the restart.
+disconnect before connecting another. Native commands and functioning WSL interop
+remain available without the companion. Computer access setup installs the shared
+companion for desktop tools and ABot Spark on every supported host, including WSL;
+it does not change interop settings or restart WSL. ABot Spark links to this same
+setup screen. Enabling or disabling collection does not pair or unpair a computer.
 
 Host requests use the existing system plugin and the same exact-action approval
 flow: Ask and Full request approval; FULL+ does not add a separate ABot prompt.
@@ -180,12 +178,12 @@ path. OS authorization still applies, and a launch receipt alone is not proof
 that a visible application window appeared.
 
 When confirmed Docker or WSL readiness requires setup, Chat shows a small,
-dismissible suggestion linking to **Config → Connected computer**. It does not
+dismissible suggestion linking to **Home → Computer access**. It does not
 appear for working native access, unknown status, or an already paired computer.
 It reuses the existing readiness state and refreshes on returning to Chat, without
 adding a polling loop. Dismissal lasts until the page is reloaded.
 
-Use **Disconnect computer** in the Web UI to revoke the Runtime's pairing and
+Use **Unpair computer** in the Web UI to revoke the Runtime's pairing and
 pending invitations. The connected companion removes its credential after
 revocation. Downloaded setup files contain an expiring invitation, so keep them
 private and delete them after use. Browser storage retains neither the invitation
@@ -193,10 +191,11 @@ nor the persistent credential.
 
 Advanced installations using the ABot CLI can still use `abot host status`,
 `abot host disconnect` and `abot host uninstall`. The downloaded installer does
-not add a global `abot` command. Its private Node binary and immutable companion
-bundle live under `%LOCALAPPDATA%\ABot\HostCompanion` on Windows or
-`~/Library/Application Support/ABot/HostCompanion` on Mac; the same CLI operations
-can be invoked there as `<node> <companion-bundle> host uninstall`. This removes
+not add a global `abot` command. On Windows, its private Node binary and immutable
+companion bundle live under `%LOCALAPPDATA%\ABot\HostCompanion`. On Mac, the Node
+executable is `~/.abot/host-companion/runtime/node` and the bundle lives under
+`~/Library/Application Support/ABot/HostCompanion`. The same CLI operations can
+be invoked as `<node> <companion-bundle> host uninstall`. This removes
 the local credential and login registration; use the Web UI to clear Runtime-side
 pairing as well. Reconnecting never silently replaces another installation's
 saved native connection.

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/package.json

@@ -42,6 +42,10 @@
       "import": "./dist/src/plugin-sdk/index.js",
       "types": "./dist/src/plugin-sdk/index.d.ts"
     },
+    "./plugin-sdk/computer-access": {
+      "import": "./dist/src/plugin-sdk/computer-access.js",
+      "types": "./dist/src/plugin-sdk/computer-access.d.ts"
+    },
     "./runtime": {
       "import": "./dist/src/runtime/index.js",
       "types": "./dist/src/runtime/index.d.ts"
@@ -81,7 +85,7 @@
     "dist/src/plugin-contract/",
     "dist/src/plugin-sdk/",
     "dist/src/web-ui/",
-    "dist/plugins/system/",
+    "dist/src/computer-access/",
     "runtime.config.schema.json",
     "src/runtime/README.md",
     "src/runtime/scheduler/README.md",
@@ -177,5 +181,5 @@
   },
   "type": "module",
   "types": "./dist/src/runtime/index.d.ts",
-  "version": "1.4.0"
+  "version": "1.6.0"
 }