@sanity/workflow-cli 0.24.0 → 0.25.0

package/CHANGELOG.md

@@ -1,5 +1,46 @@
 # @sanity/workflow-cli
 
+## 0.25.0
+
+### Minor Changes
+
+- 177d600: Deployed workflow environment tags are now discoverable.
+
+  The engine gains two cross-partition GROQ builders: `deployedTagsGroq()` lists
+  every tag holding a deployed definition in a resource, and
+  `definitionTagsGroq()` narrows that to one definition name via `$definition`.
+  Both deliberately span tag partitions — every other read is tag-scoped, and
+  `workflow.query` refuses GROQ that isn't — so they answer "which environments
+  exist here" for a caller holding a resource but no tag. They report what is
+  _observed_: a tag with nothing deployed does not appear.
+
+  The stdio MCP server adds a `list_workflow_tags` tool taking a
+  `workflow_resource` and no tag. It is registered by the host rather than exported
+  as a tool def, because a def is only ever handed an engine and an engine is
+  pinned to one tag. `LIST_WORKFLOW_TAGS_TOOL_NAME` and
+  `LIST_WORKFLOW_TAGS_DESCRIPTION` are exported so an embedding host registers the
+  same capability under the same name without re-authoring the model-facing
+  wording. The `tag` parameter's description now points an agent at that tool where
+  a server offers it and at the user otherwise, and requires confirmation either
+  way — having the list does not license picking from it.
+
+  Both registration paths share one outcome path, `withToolTelemetry`, so the
+  result envelope, error rendering, and the `Editorial Workflows MCP Tool Called`
+  event cannot diverge between a def-backed tool and a host-registered one. Tag
+  discovery reports its adoption event like every other tool, and because it names
+  a resource it can also initialize the stdio server's deferred telemetry shell —
+  which matters when discovery is an agent's first call.
+
+  The CLI's definition-tags probe runs the engine's builder instead of its own
+  copy of the query, so its `params` key is `definition` rather than `name`, and
+  the tag partitions it names in an ambiguity error arrive sorted from the lake.
+
+### Patch Changes
+
+- Updated dependencies [177d600]
+- Updated dependencies [fc12989]
+  - @sanity/workflow-engine@0.25.0
+
 ## 0.24.0
 
 ### Minor Changes

package/dist/commands/editorial-workflows/definition/show.js

@@ -61,7 +61,7 @@ async function assertSingleTagPartition({ targets, name, }) {
         const tags = await target.client.fetch(groq, params, { tag: 'definition.show' });
         if (tags.length > 1) {
             fail(`Definition "${name}" exists in several tag partitions in ` +
-                `${resourceLabel(target.resource)} — pass --tag to choose one.`, tags.toSorted().join('\n'));
+                `${resourceLabel(target.resource)} — pass --tag to choose one.`, tags.join('\n'));
         }
     }));
 }

package/dist/lib/definitions.d.ts

@@ -10,10 +10,9 @@ export declare function buildDefinitionShowQuery(flags: DefinitionShowQueryArgs)
     params: Record<string, unknown>;
 };
 /**
- * The tag partitions holding any version of a definition name within one
- * dataset. An untagged lookup that would span several partitions must error
- * (the highest version ACROSS partitions is meaningless — it could show a
- * prod operator the dev definition), the same way a cross-dataset hit does.
+ * The engine's {@link definitionTagsGroq} in this package's `{groq, params}`
+ * calling shape. Refusing an untagged lookup that spans partitions mirrors the
+ * cross-dataset rule: ambiguity errors, never picks.
  */
 export declare function buildDefinitionTagsQuery(name: string): {
     groq: string;

package/dist/lib/definitions.js

@@ -1,4 +1,4 @@
-import { WORKFLOW_DEFINITION_TYPE, assertReadableModel, errorMessage, tagScopeFilter, validateDefinition, } from '@sanity/workflow-engine';
+import { WORKFLOW_DEFINITION_TYPE, assertReadableModel, definitionTagsGroq, errorMessage, tagScopeFilter, validateDefinition, } from '@sanity/workflow-engine';
 import { fail } from "./fail.js";
 export function buildDefinitionShowQuery(flags) {
     const params = { name: flags.name };
@@ -16,8 +16,8 @@ export function buildDefinitionShowQuery(flags) {
 }
 export function buildDefinitionTagsQuery(name) {
     return {
-        groq: `array::unique(*[_type == "${WORKFLOW_DEFINITION_TYPE}" && name == $name].tag)`,
-        params: { name },
+        groq: definitionTagsGroq(),
+        params: { definition: name },
     };
 }
 export async function fetchDeployedDefinition({ client, name, tag, version, }) {

package/oclif.manifest.json

@@ -978,5 +978,5 @@
       ]
     }
   },
-  "version": "0.24.0"
+  "version": "0.25.0"
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sanity/workflow-cli",
-  "version": "0.24.0",
+  "version": "0.25.0",
   "description": "Command-line tool for deploying, inspecting, and administering Sanity workflow definitions and instances.",
   "keywords": [
     "cli",
@@ -62,12 +62,12 @@
     "@types/node": "^24.12.4",
     "oclif": "^4.23.16",
     "vitest": "^4.1.8",
-    "@sanity/workflow-engine": "0.24.0",
-    "@sanity/workflow-examples": "0.10.3",
-    "@sanity/workflow-engine-test": "0.24.0"
+    "@sanity/workflow-engine": "0.25.0",
+    "@sanity/workflow-engine-test": "0.25.0",
+    "@sanity/workflow-examples": "0.10.4"
   },
   "peerDependencies": {
-    "@sanity/workflow-engine": "0.24.0"
+    "@sanity/workflow-engine": "0.25.0"
   },
   "oclif": {
     "bin": "sanity-workflows",