@mercury-fw/kit 0.47.1 → 0.49.0

package/CHANGELOG.md

@@ -1,5 +1,30 @@
 # @mercury-fw/kit
 
+## 0.49.0
+
+### Patch Changes
+
+- Updated dependencies [b7438a6]
+  - @mercury-fw/channel-types@0.49.0
+  - @mercury-fw/plugin-types@0.49.0
+
+## 0.48.0
+
+### Minor Changes
+
+- 62bb3a3: - `persona.name` is the assistant's name, Mercury when left out. A name that's blank, longer than 40 characters or on more than one line stops the app at startup.
+  - Every text the model reads refers to the name as `{{assistant}}`, and the core puts the persona's name there: the persona's identity and tone, the system prompt, plugin fragments, skills and tool descriptions. The model no longer takes "Mercury" for its own name when the app calls its assistant something else.
+  - Where the one acting is the system around the model, the texts say "the system" or "this instance" instead of Mercury: the wiki tools, the cli-engine's errors, the jira skill and its issue lists.
+  - Plugins get `assistantName` in their `build()` context, and channels in their runtime context, for texts they build while running. The login messages, the linking reply and the HTTP login page name the assistant that way.
+  - The tools a person runs as the assistant itself are `<tool>AsSelf`, previously `<tool>AsMercury`. The `mercury.act-as-self` roles are unchanged.
+  - `mfw create` writes the assistant's name as `persona.name`, with `persona/identity.md` and `persona/tone.md` referring to it. An existing app keeps working as it is: to rename its assistant everywhere, add `name` to its persona and write `{{assistant}}` in its persona files.
+
+### Patch Changes
+
+- Updated dependencies [62bb3a3]
+  - @mercury-fw/plugin-types@0.48.0
+  - @mercury-fw/channel-types@0.48.0
+
 ## 0.47.1
 
 ### Patch Changes

package/README.md

@@ -21,7 +21,9 @@ or anywhere else under the home, with `{ "path": ".my-cli" }` instead of `folder
 
 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: a person holding `mercury.act-as-self` (every plugin) or `mercury.act-as-self.<plugin>` (that one), and the terminal. Those people also get each tool of a plugin acting as the person a second time, as `<tool>AsMercury`, run with Mercury's identity. Roles come from the directory the app declares (`DirectoryPlugin` in the channel contract: given who a channel says is talking, it returns the person and their roles, or `null` for someone it doesn't know).
+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: a person holding `mercury.act-as-self` (every plugin) or `mercury.act-as-self.<plugin>` (that one), and the terminal. Those people also get each tool of a plugin acting as the person a second time, as `<tool>AsSelf`, run with Mercury's identity. Roles come from the directory the app declares (`DirectoryPlugin` in the channel contract: given who a channel says is talking, it returns the person and their roles, or `null` for someone it doesn't know).
+
+The assistant has the name the app gives it (`persona.name`), so a plugin never writes one into what the model reads. Its fragment, its skills and its tools' descriptions say `{{assistant}}`, which the core replaces with that name. A text the plugin builds while running gets the name as `assistantName` in its `build()` context (a channel gets it in its runtime context too). Where the one acting is the system around the model (a list it appends, an account it picks), the text says "the system" and no name at all.
 
 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)).
 

package/package.json

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