@sanity/workflow-studio-plugin 0.22.0 → 0.23.0

package/CHANGELOG.md

@@ -1,5 +1,40 @@
 # @sanity/workflow-studio-plugin
 
+## 0.23.0
+
+### Minor Changes
+
+- 2a2c5d0: The Workflows tool renders full width with a compact title, and its chrome — the title row and the tab strip — stays mounted on every route: detail views render under it with their own title line below the tabs, and selecting a tab from a detail view returns to the home panel on that tab. The back-arrow button is gone; the tab strip is the tool's navigation. The selected tab is a path segment (`…/workflows/definitions`), not a search param, and on detail routes the strip highlights the tab the page's kind belongs to (instances under Overview, definitions under Definitions).
+
+  The tool's task list uses one spacing step between all bands, so a closed workflow band sits the same distance from the next document group as from its own group header.
+
+  The For me tabs share one empty state: the tool now shows the same "Nothing to do!" card as the document view, and on both surfaces the empty card fills the panel's remaining space with its lockup centered.
+
+  The tool's Overview and For me tabs order their document groups alphabetically by each document's resolved preview title, title-less documents trailing on a stable key. Preview titles resolved as data (this ordering, the document filter's options) now follow the doc-ref faces' rules — the target's probed actual type, draft-aware, under the active perspective — so a draft-only document or a generic stored ref type titles the same everywhere.
+
+  The tool gains a Definitions tab between Overview and For me: the deployed catalog, one clickable row per definition with its description, live in-flight instance count, and the document types it runs on (the discovery-effective mappings, schema-titled). Each row opens a deep-linkable definition detail view — when it was deployed and under which tag, how runs begin, the document types, the description, and the full stage diagram.
+
+  The tool's capped instance stream stays warm from the first home-panel visit for the rest of the tool session, so returning to a list from a detail view repaints counts and task rows immediately instead of flashing loading placeholders. A detail view entered directly (deep link, document-view jump-out) doesn't start the stream until a list is first shown.
+
+  The event log moves from the document view into the tool. Each document-view instance section's overflow menu is gone entirely — its "Event log (debug)" dialog is removed, and the jump into the tool becomes a text link under the expanded instance body (collapsed sections offer nothing, so stacked instances don't accumulate header buttons), rendered only when the workspace's resolved tool list includes the Workflows tool — a host studio that filters the tool out gets no dead link. The tool's instance detail renders the log inline under the stage card instead — the full history feed, newest first, with no kind tabs, actor filter, or resolution badge. Each entry is an attributed line: the acting user's avatar and name leading the sentence (engine-driven entries carry a glyph and read standalone — a cascade-fired action attributes to the workflow, not the token that executed it), with a compact relative timestamp ("15d ago") carrying the absolute time on hover. Resolved stage/activity/action titles render bare (no quotes); machine names (effect names, op types) render as monospaced chips; lines never wrap — the sentence ellipsizes so the timestamp stays whole. Pending effects sit at the top of the same feed as ordinary rows — a waiting glyph, the effect and where its run will come from, its queued age — with their resolutions in a per-row overflow menu: "Run registered handlers" (only when the effect has a Studio handler) plus the manual done/failed overrides.
+
+  The tool's instance detail title names its subject: "<workflow title> in <document chip>" — the slim one-line document preview linking to the document, cap-cancelled so the title line's position doesn't shift. Instances referencing no Studio document keep the bare title.
+
+  The tool's instance detail view now renders the same per-instance snapshot as the Workflows document view — part-of band, workflow-scope field pills (with their inline editors), and the spine-topped stage card — constrained to the document pane's width, so the two surfaces read as one. The stage diagram, the Studio-documents preview section, and the "All tasks" list leave the instance detail view — the diagram renders on the definition detail instead, so the plugin's `@sanity/workflow-diagram` peer dependency is unchanged.
+
+  Document previews now come in two modes. The activity dialog's "Studio document" details row renders the slim one-line chip (schema icon + title, opens the document) instead of the full preview card; form contexts (activity field values) keep the full card. The workflow stage/"+N" preview decoration is removed everywhere — the plugin no longer registers preview middleware, so its cards and reference-field previews of workflow-mapped types render Studio's native preview unchanged. Workflow stage remains visible in the form strip, the document footer badge, and the Workflows tool.
+
+### Patch Changes
+
+- 2a2c5d0: The Workflows tool's definition surfaces (Definitions tab, definition detail, start picker) paint the previously read catalog immediately on a revisit while the fresh read runs behind it, instead of showing a loading spinner on every visit.
+- Updated dependencies [94d311e]
+- Updated dependencies [795b4bb]
+  - @sanity/workflow-engine@0.23.0
+  - @sanity/workflow-components@0.23.0
+  - @sanity/workflow-diagram@0.23.0
+  - @sanity/workflow-react@0.23.0
+  - @sanity/workflow-studio@0.23.0
+
 ## 0.22.0
 
 ### Patch Changes

package/README.md

@@ -10,9 +10,11 @@ between them — deploy it to your dataset, and this plugin gives editors the
 UI: a **workflow strip** above the editor form of mapped documents (the
 current stage, your task count, and a **Start workflow** button), and a
 **Workflows tab** next to the editor with the stage's activities and to-dos,
-where they fire actions and read the history, and a **Workflows tool** in the
-Studio navbar — the open tasks across the newest workflow instances (capped),
-the user's own cut of them, and a deep-linkable per-workflow detail view.
+where they fire actions, and a **Workflows tool** in the Studio navbar — the
+open tasks across the newest workflow instances (capped), the user's own cut
+of them, the deployed definitions catalog, and deep-linkable per-instance and
+per-definition detail views (the instance detail carries the full history
+feed).
 
 Four ideas cover everything in this guide:
 
@@ -160,22 +162,6 @@ replaces the discovered defaults for its exact `(docType, definition)` pair or
 adds that pair when discovery did not produce it. Duplicate rows for the same
 pair are rejected as configuration errors.
 
-### Workflow status in previews
-
-Editorial Workflows status does not require `components.preview`, a projected
-`_id`, or changes to `preview.select` / `preview.prepare`. Studio already
-supplies document identity to preview middleware, and the plugin uses it while delegating
-the document's title, subtitle, media, and custom preview component unchanged.
-
-The status pill appears on Studio surfaces that invoke preview middleware,
-including reference and array-item previews. A custom preview component must
-render the `status` prop it receives if it replaces Studio's default layout.
-
-Studio's Structure document-list rows bypass plugin preview middleware, so
-those rows do not render workflow stage status. Their native previews remain
-unchanged; workflow status is available in
-the document form, footer badge, and Workflows tab.
-
 ### Auto-start a workflow on new documents
 
 `autoStart` on a mapping override starts a workflow the moment an editor opens a **fresh** document