@engineeros/connector 1.40.1 → 1.42.0

package/README.md

@@ -344,6 +344,20 @@ Unknown runtime failures may use one read-only LLM diagnosis per run through the
 
 Verification results are cached per commit and role. Completed checks are reused. An interrupted check requires inspection before a new revision; it is not automatically billed again. Existing workers must load the new connector code before these protections apply.
 
+## Updates without restarting
+
+`engineeros-connector start` keeps running across connector releases. It runs the connector as a child process; a release is installed into `~/.engineeros/connector/versions/<version>` beside the running one with `npm install --ignore-scripts`, checked against the registry's lockfile integrity, its npm registry signatures and the Node.js range it declares, and smoke-tested (`engineeros-connector version`) there before anything switches. When a release is activated, the connector waits until no assessment, connected prompt, integration request or local command is in flight, then restarts only its own process on the new release. EngineerOS, conversations and Goal runs are not interrupted: Goal workers run in their own processes. A release that stops before it ever reaches EngineerOS is rolled back automatically and not retried; the previous verified release stays installed for **Roll back**.
+
+```sh
+engineeros-connector update                 # version, policy and state
+engineeros-connector update check           # ask npm for the latest release
+engineeros-connector update apply           # prepare (if needed) and activate it, including a major release
+engineeros-connector update rollback        # switch back to the kept verified release
+engineeros-connector update policy approve  # manual | approve | auto-patch | auto-minor
+```
+
+`/update` at the connector's terminal and **Connector updates** under **Project → Steering → Local workspace** do the same; only the connector's owner can use them in EngineerOS. The default `approve` policy checks every six hours and prepares patch and minor releases, but activates one only when you approve it. `auto-patch` and `auto-minor` also activate those; a major release always waits for approval, and `manual` never checks on its own. Updates are shared by every connector on the machine. A connector started from a source checkout rather than the published package is updated with git, not from npm, and a connector run without `start` (for example under a service manager that sets `ENGINEEROS_CONNECTOR_SUPERVISED=1`) reports **Connector restart required** instead of switching itself.
+
 ## Integrations: GitHub, GitLab, Jira, Linear and monday.com
 
 EngineerOS holds no credentials for these services and none of them calls EngineerOS. When EngineerOS needs one (pull request review, Goal pull requests, repository import, backlog triage, filing defects in Linear), it asks the connector, which makes the call with this machine's own sign-in and sends back only the answer.
@@ -384,7 +398,7 @@ engineeros-connector tools sign-out PROVIDER_ID --workspace PATH
 
 After pairing connector 1.8 or newer, open **Project → Steering → Local workspace → Tools and plugins** to search the catalog and control registered providers. The web UI can enable, disable and remove registrations through the authenticated connector session. Enabling and removal require confirmation. Registration remains local because its evaluated manifest contains machine paths and integrity metadata that are never advertised to EngineerOS.
 
-Use `enable all` to clear the global disable. Registration never installs packages or executes a provider. Replacing a pin requires explicit removal and registration. Registry files live beside the user-owned connector configuration as `<workspace-key>.tools.json`, outside the repository. The connected workspace displays their inventory, refreshed through authenticated heartbeats. Stop any abandoned operator update before removing its `.tools.json.lock` file.
+Use `enable all` to clear the global disable. Registration never installs packages or executes a provider. Providers set up from the catalog are installed into `tools/<provider>/<version>` beside the registry file; when a connector release ships a newer reviewed pin, **Update to** (or `tools upgrade PROVIDER_ID`) installs it into its own version directory after console approval, verifies it, and points the registration at it. New agent sessions use it with no restart; sessions already running keep the previous version, which stays installed for **Roll back to** (`tools rollback PROVIDER_ID`) as long as it still passes its integrity check. Replacing any other pin requires explicit removal and registration. Registry files live beside the user-owned connector configuration as `<workspace-key>.tools.json`, outside the repository. The connected workspace displays their inventory, refreshed through authenticated heartbeats. Stop any abandoned operator update before removing its `.tools.json.lock` file.
 
 Manifests are strict internal JSON configuration with these required fields: