@mercury-fw/kit 0.53.1 → 0.54.0

package/CHANGELOG.md

@@ -1,5 +1,21 @@
 # @mercury-fw/kit
 
+## 0.54.0
+
+### Patch Changes
+
+- Updated dependencies [e00ff73]
+- Updated dependencies [5015642]
+  - @mercury-fw/channel-types@0.54.0
+  - @mercury-fw/plugin-types@0.54.0
+
+## 0.53.2
+
+### Patch Changes
+
+- @mercury-fw/plugin-types@0.53.2
+- @mercury-fw/channel-types@0.53.2
+
 ## 0.53.1
 
 ### Patch Changes

package/README.md

@@ -25,6 +25,10 @@ A plugin also says whose identity its tools act with (`actsAs`). `"person"`: the
 
 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.
 
+What a plugin shows the person in its own words (a status line while its tool runs, a choice's label, a heading it adds) is written once, in English, in the plugin's `messages`, every key under its name (`web-search.choice.once`); the core refuses a plugin with a key outside it, and `core` and `app` can't be plugin names (their keys are the core's and the app's). While a turn runs the plugin gets `t`, the texts of the person the turn is for, and asks for each text by its key: in `SessionToolContext.t`, as the second argument of a status describer, the third of a post-processor, and in a post-turn guard (`statusLabel(t)`, `run(text, steps, t)`). The app translates the keys in its language files. The core's own keys (`core.…`) are always there, `core.status.command` for a CLI command's default status line among them. This is version 5 of the plugin contract: a plugin written for 4 isn't loaded, and the log says why.
+
+A channel's texts work the same way (channel contract version 6): its English in `messages`, under its name; `ctx.i18n.forRequest(principal, hint)` gives the texts for a request, in the person's language, else the `hint` (an `Accept-Language` value the channel passes on, also as `InboundTurn.languageHint`), else the app's default. `ctx.confirm` and `ctx.resolveConfirmation` hand back what to tell the person (`{ text, resume? }`), so a channel never words a confirmation itself, and `finalize(text, { pendingNote })` says when the text begins with the core's stand-in for an answer the model didn't write, which a channel showing its own confirmation UI drops.
+
 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.53.1",
+  "version": "0.54.0",
   "type": "module",
   "license": "MIT",
   "repository": {
@@ -27,8 +27,8 @@
     "typecheck": "tsc --noEmit"
   },
   "dependencies": {
-    "@mercury-fw/channel-types": "0.53.1",
-    "@mercury-fw/plugin-types": "0.53.1"
+    "@mercury-fw/channel-types": "0.54.0",
+    "@mercury-fw/plugin-types": "0.54.0"
   },
   "devDependencies": {
     "@mercury-fw/typescript-config": "*",