@mercury-fw/cli 0.50.4 → 0.52.0

package/CHANGELOG.md

@@ -1,5 +1,27 @@
 # @mercury-fw/cli
 
+## 0.52.0
+
+### Minor Changes
+
+- 7939ff2: - `@mercury-fw/core` exports `OPERATOR_PRINCIPAL`, the terminal's principal, for a caller that drives `handleTurn` itself as the operator.
+  - `@mercury-fw/cli/e2e` exports `turnFromDump` and `createExpect`, so a tool running Mercury turns of its own reads and checks them the way `mfw e2e` does.
+
+### Patch Changes
+
+- Updated dependencies [678c1cc]
+- Updated dependencies [7939ff2]
+  - @mercury-fw/core@0.52.0
+  - @mercury-fw/utils@0.52.0
+
+## 0.51.0
+
+### Patch Changes
+
+- Updated dependencies [b2f8cfb]
+  - @mercury-fw/core@0.51.0
+  - @mercury-fw/utils@0.51.0
+
 ## 0.50.4
 
 ### Patch Changes

package/dist/src/e2e/define.d.ts

@@ -5,10 +5,14 @@
  * checks on the calls it made and the answer it gave. A case talks to the
  * app's REPL, or to its HTTP surface as one of the test's users (each a token
  * the app's auth provider knows), possibly in lanes that run at the same time.
- * `mfw e2e` runs them (`runner.ts`).
+ * `mfw e2e` runs them (`runner.ts`). A tool driving Mercury turns of its own
+ * (the skill trainer) reads them with `turnFromDump` and checks them with
+ * `createExpect`, the same two the runner uses.
  */
 import type { Call, TurnData } from "./dump.ts";
 export type { Call } from "./dump.ts";
+export { turnFromDump } from "./dump.ts";
+export { createExpect, type Check } from "./expect.ts";
 /** One turn as a check sees it: its calls, its answer, how long it took, and
  * on HTTP the response's status (200, or 401 for a token the app refused).
  * On HTTP a call's `input` is the detail line the surface shows (the command,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mercury-fw/cli",
-  "version": "0.50.4",
+  "version": "0.52.0",
   "type": "module",
   "license": "MIT",
   "repository": {
@@ -41,17 +41,17 @@
   "comment:shape": "The Mercury CLI (`mfw`). `mfw create <dir>` writes a new Mercury app from the template. The framework packages move in lockstep with it, so a new app gets them at the CLI's own version; plugins and channels at the registry's latest. The plugin and channel packages are devDependencies only for the catalog test. `main(argv)` is exported for create-mercury-agent.",
   "dependencies": {
     "@clack/prompts": "^1.8.1",
-    "@mercury-fw/core": "0.50.4",
-    "@mercury-fw/utils": "0.50.4",
+    "@mercury-fw/core": "0.52.0",
+    "@mercury-fw/utils": "0.52.0",
     "commander": "^15.0.0"
   },
   "devDependencies": {
     "@mercury-fw/auth-oidc": "0.2.0",
     "@mercury-fw/auth-static": "0.2.1",
-    "@mercury-fw/channel-google-chat": "0.7.0",
-    "@mercury-fw/channel-http": "0.9.0",
+    "@mercury-fw/channel-google-chat": "0.8.0",
+    "@mercury-fw/channel-http": "0.10.1",
     "@mercury-fw/directory-static": "0.1.1",
-    "@mercury-fw/formatter": "0.50.4",
+    "@mercury-fw/formatter": "0.52.0",
     "@mercury-fw/plugin-atlassian-admin": "0.3.2",
     "@mercury-fw/plugin-bitbucket": "0.4.1",
     "@mercury-fw/plugin-jira": "0.6.5",

package/src/e2e/define.ts

@@ -5,11 +5,15 @@
  * checks on the calls it made and the answer it gave. A case talks to the
  * app's REPL, or to its HTTP surface as one of the test's users (each a token
  * the app's auth provider knows), possibly in lanes that run at the same time.
- * `mfw e2e` runs them (`runner.ts`).
+ * `mfw e2e` runs them (`runner.ts`). A tool driving Mercury turns of its own
+ * (the skill trainer) reads them with `turnFromDump` and checks them with
+ * `createExpect`, the same two the runner uses.
  */
 import type { Call, TurnData } from "./dump.ts";
 
 export type { Call } from "./dump.ts";
+export { turnFromDump } from "./dump.ts";
+export { createExpect, type Check } from "./expect.ts";
 
 /** One turn as a check sees it: its calls, its answer, how long it took, and
  * on HTTP the response's status (200, or 401 for a token the app refused).