docs: refresh roadmap

ROADMAP.md

@@ -1,6 +1,6 @@
 # Elsa Roadmap
 
-Last refreshed: 2026-08-26
+Last refreshed: 2026-09-02
 
 This roadmap is a product direction document, not a fixed release calendar. Elsa is developed through a mix of core maintainer work, customer-funded work, and community contributions, so sequencing can change when real-world demand changes. The intent is stable: make Elsa the most productive, dependable, and extensible workflow platform for the .NET ecosystem.
 
@@ -24,7 +24,7 @@ Legend: `[x]` shipped foundation, `[~]` partially shipped or needs productizatio
 - [x] Non-blocking activity execution
 - [x] Fork, join, and explicit flowchart merge modes
 - [x] State machine core activity
-- [~] State machine Studio authoring, docs, and examples
+- [~] State machine Studio semantic authoring is merged to `release/3.8.0`; final release, docs/examples, and authenticated browser validation remain
 - [~] Extensible activity output conversion: Core contracts, descriptor discovery, binding validation, and Studio selection/settings UX are on `main`; release packaging and built-in extension converters remain productization work
 - [~] Graceful shutdown and interrupted recovery
 - [ ] Full workflow execution recovery UX
@@ -110,6 +110,7 @@ These are already present in the codebase and should be treated as foundations f
 - Core `main` includes [`Elsa.Dashboard.Api`](src/modules/Elsa.Dashboard.Api), a read-only operational-dashboard backend with overview, trends, attention, recent-activity, and workflow-hotspot endpoints plus independent diagnostics capability states ([#7529](https://github.com/elsa-workflows/elsa-core/pull/7529), [#7532](https://github.com/elsa-workflows/elsa-core/pull/7532)). Studio `main` now supplies the operational health, trends, activity, attention, and diagnostics surface through [elsa-studio#923](https://github.com/elsa-workflows/elsa-studio/pull/923); release packaging, robust deep links, and unavailable-state handling remain productization work.
 - Core `main` now includes `Elsa.AI.Abstractions`, `Elsa.AI.Host`, `Elsa.AI.Copilot`, and `Elsa.AI.Persistence.EFCore` through [PR #7523](https://github.com/elsa-workflows/elsa-core/pull/7523), and Studio `main` now includes `Elsa.Studio.AI` through [elsa-studio#900](https://github.com/elsa-workflows/elsa-studio/pull/900). That gives Weaver both server and Studio workspace foundations, while proposal actions, broader authoring contracts, and polished product UX remain roadmap work.
 - State machine core activity support in [`Elsa.Workflows.Core/Activities/StateMachine`](src/modules/Elsa.Workflows.Core/Activities/StateMachine).
+- Studio's state-machine designer now has semantic lifecycle slots, a context-aware activity picker, malformed-definition preservation, and nested-designer support through [elsa-studio#958](https://github.com/elsa-workflows/elsa-studio/pull/958) and [elsa-studio#959](https://github.com/elsa-workflows/elsa-studio/pull/959). Those changes are merged to `release/3.8.0`, so release packaging, documentation/examples, and authenticated browser validation still keep the product surface partial.
 - Core `main` now has extensible output-converter contracts, registration, definition/runtime validation, privacy-safe conversion faults, and an authorized descriptor API through [PR #7902](https://github.com/elsa-workflows/elsa-core/pull/7902). Studio `main` consumes that API with unavailable-state handling, converter selection, and schema-driven settings editing in [elsa-studio#922](https://github.com/elsa-workflows/elsa-studio/pull/922). Converters are opt-in at a variable or workflow-output binding, so the activity output and its diagnostics remain native. This is a partially shipped foundation: release packaging and a maintained extension converter catalog are still follow-up work ([#7770](https://github.com/elsa-workflows/elsa-core/issues/7770), [elsa-extensions#164](https://github.com/elsa-workflows/elsa-extensions/issues/164)).
 - ElsaScript DSL and blob storage integration in [`Elsa.Dsl.ElsaScript`](src/modules/Elsa.Dsl.ElsaScript) and [`Elsa.WorkflowProviders.BlobStorage.ElsaScript`](src/modules/Elsa.WorkflowProviders.BlobStorage.ElsaScript).
 - Core `main` now contains `Elsa.Bpmn` and `Elsa.Bpmn.Interchange`: a BPMN process container, persisted execution state, activity bindings, message/signal/timer triggers, and analyze/import/export endpoints ([#7938](https://github.com/elsa-workflows/elsa-core/pull/7938), [#7945](https://github.com/elsa-workflows/elsa-core/pull/7945), [#7946](https://github.com/elsa-workflows/elsa-core/pull/7946), [#7954](https://github.com/elsa-workflows/elsa-core/pull/7954), [#7956](https://github.com/elsa-workflows/elsa-core/pull/7956)). The two packages joined Core `3.8.0-rc2` through [#7970](https://github.com/elsa-workflows/elsa-core/pull/7970); publish-time validation, compensation/transaction conformance coverage, and Studio rendering/authoring remain productization work ([#7958](https://github.com/elsa-workflows/elsa-core/pull/7958), [#7960](https://github.com/elsa-workflows/elsa-core/pull/7960), [#7909](https://github.com/elsa-workflows/elsa-core/issues/7909)).
@@ -122,6 +123,7 @@ These are already present in the codebase and should be treated as foundations f
 - Core `3.8.0-rc1` contains a protocol-neutral external-authentication broker with configuration- or database-backed OIDC connections, PKCE, secret handling, identity linking/JIT users, session management, persistence, and tests ([#7889](https://github.com/elsa-workflows/elsa-core/pull/7889)). Its Studio companions add Settings-based SSO connection management and a generic login-method UI ([elsa-studio#920](https://github.com/elsa-workflows/elsa-studio/pull/920)), configurable login themes ([elsa-studio#921](https://github.com/elsa-workflows/elsa-studio/pull/921)), and the all-host feature-stack integration ([elsa-studio#925](https://github.com/elsa-workflows/elsa-studio/pull/925) through [elsa-studio#931](https://github.com/elsa-workflows/elsa-studio/pull/931)). This remains a partially shipped foundation until the final cross-repository release, operational verification, and documentation are complete.
 - Studio `3.8.0-rc2` now has permission-aware user and role list, create, edit, and delete flows; role assignments; permission-token editing; tenant-scope display; and Server/WASM API-client integration ([elsa-studio#936](https://github.com/elsa-workflows/elsa-studio/pull/936)). This is a partially shipped identity-administration foundation, not workflow-authoring governance: final-release validation and operational documentation remain, and tenant/role-based activity visibility is still roadmap work.
 - Core `main` now has a structured `{resource}:{verb}` authorization model with hierarchical wildcard matching, a module-contributed permission catalog, endpoint-coverage enforcement, permission introspection, revocation bounds, and tenant-isolation hardening ([#7980](https://github.com/elsa-workflows/elsa-core/pull/7980)). This breaking change landed after `3.8.0-rc2`; migration support, broader live-host verification, and client-side governance remain productization work.
+- Core `main` now scopes managed Secrets to the active tenant and makes secret names unique per tenant ([#7991](https://github.com/elsa-workflows/elsa-core/pull/7991)). Existing multi-tenant secret rows remain in the default tenant until deliberately assigned, and the VNext document store fails closed outside that tenant rather than exposing another tenant's secret. This is an important security foundation, with migration planning and tenant-aware VNext storage still productization work.
 - Elsa Extensions is an active modular integration repository with 70+ module projects in [elsa-workflows/elsa-extensions](https://github.com/elsa-workflows/elsa-extensions), targeting `net8.0`, `net9.0`, and `net10.0`.
 - Extensions already provide broad integration foundations: Connections, Secrets, Agents, OpenAPI, SQL/CSV/data tooling, messaging, schedulers, cloud storage, logging, webhooks, persistence providers, LDAP, and external system activities.
 - Extensions `3.7.0` adds package manifest metadata, infrastructure attributes, shell features for MassTransit/Quartz/Webhooks, Dapper and MongoDB activity execution-chain lookups, Dapper bookmark queue filtering, Kafka multitenancy/schema-trigger work, Quartz lifecycle/job cleanup fixes, and other operational hardening.
@@ -138,7 +140,7 @@ High-value items:
 - Complete the graceful-shutdown operational slice: back-pressure-aware bookmark queueing, health checks, pause persistence across reactivation, and contract tests. The remaining task list is visible in [`specs/002-graceful-shutdown/tasks.md`](specs/002-graceful-shutdown/tasks.md).
 - Close the workflow recovery story around interrupted, crashed, and stuck-running instances. This directly addresses [#4833](https://github.com/elsa-workflows/elsa-core/issues/4833) and should include Studio-facing recovery states, operator actions, and clear audit records.
 - Harden distributed execution semantics: child workflow completion, bookmark races, duplicate dispatch, timer/delay behavior, and clustered refresh/reload. Community signal shows this repeatedly in [discussion #5857](https://github.com/elsa-workflows/elsa-core/discussions/5857), [#7397](https://github.com/elsa-workflows/elsa-core/issues/7397), [#7405](https://github.com/elsa-workflows/elsa-core/issues/7405), and related FlowJoin/bookmark issues.
-- Treat scheduler and messaging correctness as release-blocking infrastructure. The new `3.7.1` patch line improved Azure Service Bus startup behavior and stable instance naming in Core ([#7732](https://github.com/elsa-workflows/elsa-core/issues/7732), [#7736](https://github.com/elsa-workflows/elsa-core/issues/7736), [#7742](https://github.com/elsa-workflows/elsa-core/pull/7742)) and tightened Quartz durable trigger scheduling in Extensions ([elsa-extensions#162](https://github.com/elsa-workflows/elsa-extensions/pull/162)). That progress is useful, but active issues around Quartz clustering and recovery ([elsa-extensions#109](https://github.com/elsa-workflows/elsa-extensions/issues/109), [elsa-extensions#101](https://github.com/elsa-workflows/elsa-extensions/issues/101)), Hangfire duplicate jobs ([elsa-extensions#121](https://github.com/elsa-workflows/elsa-extensions/issues/121)), MassTransit stimulus routing ([elsa-extensions#72](https://github.com/elsa-workflows/elsa-extensions/issues/72)), Kafka extensibility ([elsa-extensions#134](https://github.com/elsa-workflows/elsa-extensions/issues/134)), and Azure Service Bus backlog/startup pressure ([#7735](https://github.com/elsa-workflows/elsa-core/issues/7735), [#7737](https://github.com/elsa-workflows/elsa-core/issues/7737)) all point to the same production theme: clustered workload behavior must be boring, observable, and customizable.
+- Treat scheduler and messaging correctness as release-blocking infrastructure. The new `3.7.1` patch line improved Azure Service Bus startup behavior and stable instance naming in Core ([#7732](https://github.com/elsa-workflows/elsa-core/issues/7732), [#7736](https://github.com/elsa-workflows/elsa-core/issues/7736), [#7742](https://github.com/elsa-workflows/elsa-core/pull/7742)) and tightened Quartz durable trigger scheduling in Extensions ([elsa-extensions#162](https://github.com/elsa-workflows/elsa-extensions/pull/162)). Current unreleased Extensions work on Proto.Actor startup ordering, remote configuration, subscriber storage, and per-member cache invalidation ([elsa-extensions#168](https://github.com/elsa-workflows/elsa-extensions/pull/168), [elsa-extensions#171](https://github.com/elsa-workflows/elsa-extensions/pull/171), [elsa-extensions#172](https://github.com/elsa-workflows/elsa-extensions/pull/172), [elsa-extensions#174](https://github.com/elsa-workflows/elsa-extensions/pull/174)), plus Quartz provider configuration ([elsa-extensions#176](https://github.com/elsa-workflows/elsa-extensions/pull/176)), reinforces the same need. Active issues around Quartz clustering and recovery ([elsa-extensions#109](https://github.com/elsa-workflows/elsa-extensions/issues/109), [elsa-extensions#101](https://github.com/elsa-workflows/elsa-extensions/issues/101)), Hangfire duplicate jobs ([elsa-extensions#121](https://github.com/elsa-workflows/elsa-extensions/issues/121)), MassTransit stimulus routing ([elsa-extensions#72](https://github.com/elsa-workflows/elsa-extensions/issues/72)), Kafka extensibility ([elsa-extensions#134](https://github.com/elsa-workflows/elsa-extensions/issues/134)), and Azure Service Bus backlog/startup pressure ([#7735](https://github.com/elsa-workflows/elsa-core/issues/7735), [#7737](https://github.com/elsa-workflows/elsa-core/issues/7737)) all point to the same production theme: clustered workload behavior must be boring, observable, and customizable.
 - Turn the draft native background execution architecture into an implementation plan. [#7356](https://github.com/elsa-workflows/elsa-core/issues/7356) and [#7313](https://github.com/elsa-workflows/elsa-core/issues/7313) point toward an engine-owned, workflow-aware runtime that can evolve toward an actor-model abstraction without coupling Elsa to Orleans, Proto.Actor, or any single backend.
 - Treat persistence and migration reliability as a product feature: provider-specific migration validation, large-tenant performance tests, safer defaults, and upgrade notes that cover SQL Server, PostgreSQL, MySQL, SQLite, Oracle, and MongoDB scenarios.
 - Promote the Elsa Deployment Platform PRD into scoped implementation work. [#7469](https://github.com/elsa-workflows/elsa-core/issues/7469) defines the right product boundary: declarative environment manifests, immutable deployment artifacts, dry-run validation, deployment history, and GitOps-compatible reconciliation should manage control-plane state without reconciling runtime execution state.
@@ -161,7 +163,7 @@ High-value items:
 - Ship workflow organization as a coherent feature: labels/categories, folder-like views, search/filter by metadata, and Studio support. This consolidates [#5872](https://github.com/elsa-workflows/elsa-core/issues/5872), [#6307](https://github.com/elsa-workflows/elsa-core/issues/6307), the existing `Elsa.Labels` module, and workflow definition `CustomProperties`.
 - Make designer reliability a visible workstream. Recent Studio issues show expression/input rendering regressions after 3.6 ([elsa-studio#791](https://github.com/elsa-workflows/elsa-studio/issues/791), [elsa-studio#781](https://github.com/elsa-workflows/elsa-studio/issues/781), [elsa-studio#795](https://github.com/elsa-workflows/elsa-studio/issues/795)), persistent browser/JS failures ([elsa-studio#903](https://github.com/elsa-workflows/elsa-studio/issues/903)), and fragile Playwright automation ([elsa-studio#919](https://github.com/elsa-workflows/elsa-studio/issues/919)). These should drive a regression harness for designer rendering, property editors, expression descriptors, drag/drop, stable test identifiers, deterministic canvas state, and WASM/Server parity.
 - Make workflow progress visible to application users: a current-state/step API, timeline model, and embeddable progress component. This responds to [discussion #6012](https://github.com/elsa-workflows/elsa-core/discussions/6012) and should reuse execution logs, activity records, call-stack tracking, and real-time workflow updates.
-- Finish the state machine product surface. The core activity exists, but [#5085](https://github.com/elsa-workflows/elsa-core/issues/5085) should be closed only when JSON serialization, Studio authoring, docs, and examples make state machines approachable.
+- Finish the state machine product surface. Core support is in place and the `release/3.8.0` Studio branch now adds semantic lifecycle editing and safe malformed-definition handling ([elsa-studio#958](https://github.com/elsa-workflows/elsa-studio/pull/958), [elsa-studio#959](https://github.com/elsa-workflows/elsa-studio/pull/959)); [#5085](https://github.com/elsa-workflows/elsa-core/issues/5085) should close only after final release, docs/examples, and authenticated browser validation make the workflow approachable.
 - Build first-class workflow testing and debugging: test runners for full workflows, breakpoint-like inspection, replay from execution logs where feasible, better failed-activity retry flows, child/descendant workflow instance navigation, and Studio affordances for fault investigation. The Studio `3.7.0` activity call-stack viewer is a useful foundation, but requests for child workflow visibility ([elsa-studio#152](https://github.com/elsa-workflows/elsa-studio/issues/152)) and breakpoint debugging ([elsa-studio discussion #662](https://github.com/elsa-workflows/elsa-studio/discussions/662)) still need a coherent debugging experience.
 - Productize the paired User Tasks implementation into a released human-workflow feature. Core now supplies durable, identity-neutral workflow tasks, invitations/guest sessions, authorization, persistence, audit, and delivery reliability; Studio supplies the queue, task/manager workbench, guest completion page, and polling fallback ([#7955](https://github.com/elsa-workflows/elsa-core/pull/7955), [elsa-studio#941](https://github.com/elsa-workflows/elsa-studio/pull/941)). Prioritize release packaging, a Core invalidation hub, cross-provider conformance coverage, samples, and operational validation.
 - Improve Studio authoring fundamentals: input validation ([elsa-studio#15](https://github.com/elsa-workflows/elsa-studio/issues/15)), activity version indicators ([elsa-studio#284](https://github.com/elsa-workflows/elsa-studio/issues/284)), async `/dispatch` instead of blocking `/execute` where appropriate ([elsa-studio#811](https://github.com/elsa-workflows/elsa-studio/issues/811)), designer image export ([elsa-studio#585](https://github.com/elsa-workflows/elsa-studio/issues/585)), and expression evaluation controls ([elsa-studio#643](https://github.com/elsa-workflows/elsa-studio/issues/643)).
@@ -231,6 +233,7 @@ High-value items:
 - Productize the external-authentication and SSO foundation for Blazor Server, WASM, separate server/studio, all-in-one hosts, and reverse-proxy sub-path deployments. The `3.8.0-rc2` releases include an Elsa-owned extensible broker and OIDC adapter in Core ([#7889](https://github.com/elsa-workflows/elsa-core/pull/7889)), Settings-based SSO administration and generic login composition in Studio ([elsa-studio#920](https://github.com/elsa-workflows/elsa-studio/pull/920)), and configurable login themes ([elsa-studio#921](https://github.com/elsa-workflows/elsa-studio/pull/921)). Finish solution-level verification, operational recipes, migration/release guidance, and broad provider hardening without conflating upstream identity claims with Elsa authorization.
 - Provide a production security guide: API keys, JWT/OIDC, default admin bootstrap, scripting trust levels, C# expression risks, Docker demo boundaries, secret masking, tenant isolation, and permission design.
 - Productize the new Core authorization model: use the documented migration from legacy permission strings, extend coverage gates and live-host smoke tests to every endpoint-bearing module, and bring the catalog and introspection experience into Studio ([#7980](https://github.com/elsa-workflows/elsa-core/pull/7980)).
+- Complete the Secrets tenancy migration and provider story: make the default-tenant treatment of existing rows explicit in upgrade guidance, provide safe assignment/validation workflows for multi-tenant operators, and design tenant-aware VNext document keys before enabling non-default tenant access ([#7991](https://github.com/elsa-workflows/elsa-core/pull/7991)).
 - Extend the Studio user/role administration foundation into workflow governance: tenant/role-based activity visibility, granular permission-aware menus/routes, feature-gated modules, and clear behavior for hidden activities in existing workflow definitions. The administration flows are in `3.8.0-rc2` ([elsa-studio#936](https://github.com/elsa-workflows/elsa-studio/pull/936)), but [elsa-studio#584](https://github.com/elsa-workflows/elsa-studio/issues/584) and [elsa-studio#908](https://github.com/elsa-workflows/elsa-studio/issues/908) show that the authoring-side and permission-honoring product work still remains.
 - Complete localization and white-label readiness: translation contribution docs, coverage status, missing key checks, branding hooks, and supportable customization patterns. Studio issues and discussions show setup/coverage friction in [elsa-studio#771](https://github.com/elsa-workflows/elsa-studio/issues/771), [elsa-studio discussion #695](https://github.com/elsa-workflows/elsa-studio/discussions/695), and [elsa-studio discussion #678](https://github.com/elsa-workflows/elsa-studio/discussions/678).
 - Improve multi-tenant ergonomics: tenant-agnostic workflows, high tenant counts, tenant validation modes, cache isolation, and clear migration guidance after the 3.6 tenant ID convention changes.