Moltaro 0.0.68-beta

Release date: 2026-09-17

Teams can now run governed workflows from Entity and Board records, follow their numbered progress and collaboration history, and extend native record screens and forms with workspace-authored components. Release packages also move to the serviced .NET and ASP.NET Core 10.0.12 baseline.

Highlights

• Published workflows can execute Start, Delay, User Input, DevLog and End nodes through durable API, Worker and C# SDK paths, with explicit or event-driven activation, replay protection and administrative recovery.
• Entity records can show live Workflow facts and actions in cards, tables, drawers and details. Each process has a stable number, an authorized details page and optional immutable activity in the Subject’s Collaboration feed.
• Workspace UI authors can place registered Vue components in native Details, Drawer, Card and Table surfaces, or bind editable components into the native Entity form without creating a second draft or save path.
• Runtime and package construction now require the September servicing baseline: .NET/ASP.NET Core 10.0.12 and SDK 10.0.401.

Detailed changes

Workflow execution and administration

Workflow now runs published sequential graphs containing Start, Delay, User Input, DevLog and End nodes. Explicit starts and implicit Entity or Board events use the configured activation mode, condition and current persisted security. An accepted start pins the active revision, and execution continues until it reaches a durable wait, a business outcome or a technical fault. Repeated visits have distinct identities; a response applies only to the exact waiting visit and version shown to the user.

Commands, waits, history, effects and results are durable. Operation identities make an exact retry idempotent and reject a changed request under the same identity. Worker leases are fenced, crashed work is recovered within a bounded retry budget, and RabbitMQ notifications wake database-backed work without making the message the source of truth. Disabling Workflow pauses advancement without consuming retry attempts; re-enabling it wakes pending work. Archiving or deleting a Subject faults unfinished work while retaining history, and an authorized administrator can Retry after restore or Cancel an unfinished process.

Workflow Definition Security can assign existing workspace roles or responsibility groups as runtime administrators. Global administrators and administrators assigned to that Definition can Cancel or Retry; configuration management alone does not grant that authority. Runtime administration does not grant Subject data access or User Input permission. A user without Subject View receives only the existing technical projection.

The authenticated runtime API supports Subject discovery, explicit Start, instance and paged-history reads, exact User Input response, Cancel, Retry and safe command status. Matching application services are available to supported C# Action, Command, HttpEndpoint, Job and TriggerHandler contexts. Direct Entity Framework access remains a trusted storage-level option and does not execute, authorize or publish a workflow command.

This release remains sequential: fork/join, parallel graph syntax, arbitrary User Input forms, personal Inbox delivery and a global Workflow Instances browser are not included.

Workflow facts, numbers and Collaboration

Constructor can bind a Workflow Definition as an Object Context Fact on an Entity record. Cards, drawers and details can Start an admitted process or answer its current User Input; table cells remain read-only. A per-occurrence option controls whether active node names are shown. Visible facts refresh after runtime, configuration, Entity or security changes without adding a Workflow polling loop.

Every existing and new Workflow Instance has an immutable, workspace-unique number. Definitions default to the WF- prefix and may choose a different prefix for future instances. Numbers link to a read-only process page showing the Definition, pinned revision, status, outcome, timestamps, authorized Subject link, active visits and sequence-ordered history. Number search and links also work in Workflow activity.

A Definition-level Collaboration policy, disabled by default, can publish subsequent start, transition, choice, completion, cancellation, retry and fault activity to the Entity or Board Subject’s existing Collaboration channel. Published entries capture safe display text atomically with the runtime transition, contain no business field values or technical stack traces, and are not rewritten when the policy changes. Enabling the policy does not create a missing comments channel and does not backfill earlier Workflow history.

Workspace UI components in native Entity screens

UI Studio and workspace-ui.json can register components with Section, CardItem, TableCell and/or FormItem placements. Constructor can place a read-only component as a Details/Drawer section, Card item or synthetic Table column. The native host retains navigation, layout, virtualization, permissions, loading/error/unavailable presentation, scoped styling, overlay ownership and an abort signal for obsolete work. A component receives only the current record identity and already loaded, permission-shaped fields; additional reads use ordinary APIs under the current user.

Editable FormItem components declare up to 16 typed Read or ReadWrite bindings. Constructor maps those bindings to fields on the Entity’s primary table. The native form remains the single owner of the draft, rules, dependent references, validation, conflict handling and Create/PATCH submission. Components request changes through setValue and participate in the same validity gate through setValidity; field-level server authorization and business invariants still apply to every request. Restricted values are not exposed, locked values cannot be changed, and unavailable custom input blocks saving only when it is the sole editor for required data.

Read-only table components are not sortable, filterable, included in the mobile card list or exported by the server. Package-owned Entity surfaces cannot reference workspace components. A form component does not replace native Reference Eligibility or Lookup configuration for dependent-reference scenarios. When a component-bound field has no sibling native field item, the browser context exposes only its static required flag in this release; dynamic visibility, editability and required rules are still enforced by server evaluation and save. If a component registration later removes a binding name, Constructor retains the stored mapping and reports it as unknown until an author removes or remaps it.

Serviced .NET runtime baseline

The runtime, ASP.NET Core and Microsoft package families advance to 10.0.12, and the repository SDK baseline advances to 10.0.401. Release packaging pulls and verifies the exact SDK and ASP.NET Core base images used for the combined app, standalone API, Worker, restore gateway and Identity image instead of accepting a stale floating-tag cache.

Platform releases continue when custom UI needs repair

A failed Workspace UI build now leaves an app-specific warning and build history for its author, while the platform release continues. Published source and draft edits are preserved. An incompatible custom page or embedded component remains unavailable until its author fixes, builds and activates the UI; core platform services remain available.

When a custom UI artifact needs the new database schema, its automatic build runs after the runtime migration. Preparation no longer attempts to store that artifact in a column that has not yet been installed. Publication retries reuse the exact source and saved result. Platform health verification distinguishes custom UI repair from a failed database, package or service.

Database and upgrade impact

This release changes the Workspace database for durable Workflow commands and administrators, activation boundaries, Workflow Collaboration/history metadata, instance numbers and Workspace UI component descriptors and form bindings. Existing Workflow instances are assigned deterministic numbers during upgrade; existing revision content, identities and history remain in place. Collaboration defaults to disabled and no earlier activity is backfilled. There is no Portal database migration in this comparison range.

Managed Apps receive a full ReplaceRuntime replacement of WebApp, Api and Worker. Plan a service interruption while each application is stopped, its Workspace database is migrated and its replacement services start. These notes do not establish measured production downtime.

Retain a verified pre-upgrade Workspace database backup and the matching runtime and external-file recovery material. A database backup alone does not retain external file bodies. Reverse migrations remove the newly stored Workflow command, administrator, collaboration, number and Workspace UI component data; reverting container images alone is therefore not a safe rollback. Restore the compatible pre-upgrade backup and runtime when rollback must preserve the prior state.

Deployment and operator actions

1. Use ReplaceRuntime for 0.0.68-beta, covering WebApp, Api and Worker. FromVersion is unset; this is not an update package.
2. Preserve the normal database and external-file recovery evidence. Let the supported upgrade path apply all Workspace migrations before starting the new runtime; do not apply schema changes manually.
3. On Windows Files/IIS hosts, install the .NET and ASP.NET Core 10.0.12 or later stable 10.0 patch Hosting Bundle before activation. Project-build hosts must have the supplied SDK or SDK 10.0.401 or later in 10.0. Package image probes do not validate the destination Windows host or separately supplied SDK.
4. The upgrade rebuilds the published Workspace UI against the new host contract. Builds requiring the target artifact schema run automatically after migration. A failed UI build does not stop the platform release. Record the app-specific warning and have the author repair it in UI Project, then Check → Build → Activate and reload clients. Do not rely on incompatible pages or embedded components until that repair succeeds.
5. Rebuild C# extensions that consume Workflow packages against Workflow Engine 3.4.0 and Workflow SDK 3.5.0. Review any direct EF creation of Workflow instances: trusted writers must now supply a unique complete instance number.
6. After replacement, verify the exact WebApp/API/Worker package and image versions, Workspace migration completion, RabbitMQ/Worker recovery, public routes and current published Workspace UI artifact. Record UI repair warnings separately from platform acceptance. Confirm all Managed Apps run on the serviced .NET runtime before closing acceptance.

Concrete post-deploy acceptance scenario

Use an approved test Entity record, a Workflow Definition with Collaboration enabled, a runtime-administrator test role and an active revision containing Start → User Input → Delay → DevLog → End. Bind the Definition as an Object Context Fact on the Entity’s Card and Table surfaces with active-node details enabled.

1. As an admitted user, start the process from the record card. Confirm a new #WF-… number and User Input action appear without a page reload, while the Table cell shows the same number and state without an action.
2. Submit one declared choice. Confirm the exact waiting visit is consumed once, the Delay resumes through the Worker, the process reaches its configured outcome, and retrying the same operation does not add another transition or DevLog entry.
3. Open the number link. Verify the Definition, pinned revision, Subject link, outcome, timestamps and ordered history. Confirm the Entity Collaboration feed contains the new Workflow activities and number link, then verify a user without Subject View cannot open the business projection.
4. As the assigned runtime administrator without Subject View, verify the technical projection omits Subject and business node content; then restore the approved test identities and permissions.
5. Open an Entity with one registered read-only Workspace UI component in a Card or Details section and one registered FormItem. Confirm the read-only component reaches ready; edit a mapped ReadWrite field through the form component, save, reopen and verify the same value. Temporarily checking the unavailable state must not expose restricted fields or bypass a required input.
6. Record the actual Workspace migration result, runtime versions, component artifact compatibility and all observations in the production acceptance record.

These observations are pending production checks, not evidence that deployment has already succeeded.

Compatibility and breaking changes

• Workflow Engine advances from 3.3.0 to 3.4.0 and Workflow SDK from 3.3.0 to 3.5.0. The runtime, Definition Security, Collaboration, numbering and EF navigation surfaces are additive, and Workflow YAML remains version 2. Rebuild extensions and check runtime-command results rather than treating a queued receipt as process completion.
• WorkflowInstance.Number is required and unique. Runtime commands allocate it; direct EF writers must allocate a complete unique value themselves. Number-prefix edits affect only future instances.
• The authenticated /api/workspace/workflow/runtime routes and bounded Entity fact query are new. Runtime administration does not imply Subject View, configuration management or User Input admission; clients must handle technical-only projections and reauthorization after permission changes.
• Workspace UI HostContractVersion remains 1, but its declaration and fingerprint change. Existing artifacts must be checked, rebuilt and activated. The component registration, contexts and form-binding members are additive; a renamed component key makes stored placements unavailable until corrected.
• Windows framework-dependent Files/IIS deployments require the 10.0.12+ Hosting Bundle, and build hosts require SDK 10.0.401+ in the 10.0 line. The shipped Docker images carry the required runtime baseline.

No other known compatibility or breaking changes were found in the reviewed range.