@mercury-fw/kit 0.39.0 → 0.41.0

package/CHANGELOG.md

@@ -1,5 +1,34 @@
 # @mercury-fw/kit
 
+## 0.41.0
+
+### Patch Changes
+
+- @mercury-fw/plugin-types@0.41.0
+- @mercury-fw/channel-types@0.41.0
+
+## 0.40.0
+
+### Minor Changes
+
+- 0739f77: A plugin acts as the person Mercury is talking to, who logs in to the service through Mercury.
+
+  - Plugin contract version 4: a plugin declares `actsAs: "person" | "mercury"`, and one acting as the person contributes a `login`; its tools get the turn's `person` and `requireLogin` in their context.
+  - A person is offered only the plugins acting as the person: their prompt fragments, skills and tools. A plugin acting as Mercury, or declaring nothing, is offered on the terminal only until people can be allowed to make Mercury act as itself; the startup log names it.
+  - `createCliTool` adds `--user` with the person's id to every command, staged confirmations included, and when the CLI exits with code 3 (not logged in) returns their login instead. `createCliPersonLogin` builds a plugin's `login` on a CLI's two-step remote login. A failed `runCli` carries `exitCode`.
+  - Channel contract version 4: channels get `logins` (`accept` a callback URL, `complete` a login) and `detectLoginRequired`.
+  - The HTTP channel, with `HTTP_SURFACE_PUBLIC_URL` set, streams a `login` event with the link to open and takes the person back at `GET /login/callback`, public and protected by the single-use state.
+  - `mercury.cliCredentials` can declare `userSetup`, run by `mfw credentials setup <plugin> --user-app`: the app people log in through, set up without logging anyone in.
+  - plugin-jira and plugin-bitbucket act as the person, on CLIs 2.3.0: set up their people's app with `--user-app` and register `<HTTP_SURFACE_PUBLIC_URL>/login/callback` on it. Jira's skill now says `currentUser()` is the person.
+  - plugin-atlassian-admin acts as Mercury, on CLI 0.2.0, whose `init` asks for the key without echoing it: until permissions exist it's available on the terminal only.
+  - A third-party plugin needs `apiVersion: 4` to load, and `actsAs: "person"` with a `login` to be offered to people.
+
+### Patch Changes
+
+- Updated dependencies [0739f77]
+  - @mercury-fw/plugin-types@0.40.0
+  - @mercury-fw/channel-types@0.40.0
+
 ## 0.39.0
 
 ### Minor Changes

package/README.md

@@ -17,10 +17,12 @@ A plugin whose CLI keeps its login in a folder under the home, reading it from t
 }
 ```
 
-or anywhere else under the home, with `{ "path": ".my-cli" }` instead of `folder` (relative to the home, inside it). Each command is a binary on the container's PATH followed by its arguments: `setup` sets up the identity the agent runs as and is required, `check` and `logout` (of that identity, or of one person with `--user <id>`) are optional.
+or anywhere else under the home, with `{ "path": ".my-cli" }` instead of `folder` (relative to the home, inside it). Each command is a binary on the container's PATH followed by its arguments: `setup` sets up the identity the agent runs as and is required, `userSetup` (the app people log in through, logging nobody in), `check` and `logout` (of that identity, or of one person with `--user <id>`) are optional.
 
 An app then runs `mfw credentials setup <plugin>`, which runs `setup` in a one-off container on the user's terminal, so the CLI asks for what it needs and writes its login straight onto a volume that keeps what the CLI writes back (a folder outside `~/.config` gets a link from its usual place to the volume). A CLI that authenticates any other way isn't covered by this, and neither is one that deletes its own folder and makes it again.
 
+A plugin also says whose identity its tools act with (`actsAs`). `"person"`: the person the turn is for, who logs in to the service through Mercury; the plugin contributes a `login` (`start` and `complete`, which `createCliPersonLogin` from `@mercury-fw/cli-engine` builds for a CLI with a two-step remote login), and its tools get the person and `requireLogin` in their context (`createCliTool` takes both, adds `--user` to every command and asks for the login when the CLI exits with code 3). `"mercury"`, or nothing declared: Mercury's own identity, whoever asks, which only someone allowed to make Mercury act as itself may use; that permission doesn't exist yet, so such a plugin is offered on the terminal only.
+
 A proper workflow for writing plugins, with an SDK on top of these contracts, is planned ([#27](https://github.com/lucabro81/mercury-fw/issues/27)).
 
 MIT

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mercury-fw/kit",
-  "version": "0.39.0",
+  "version": "0.41.0",
   "type": "module",
   "license": "MIT",
   "repository": {
@@ -27,8 +27,8 @@
     "typecheck": "tsc --noEmit"
   },
   "dependencies": {
-    "@mercury-fw/channel-types": "0.39.0",
-    "@mercury-fw/plugin-types": "0.39.0"
+    "@mercury-fw/channel-types": "0.41.0",
+    "@mercury-fw/plugin-types": "0.41.0"
   },
   "devDependencies": {
     "@mercury-fw/typescript-config": "*",