Moltaro 0.0.69-beta

Release date: 2026-09-27

Teams can find and inspect running workflows, suspend and resume them, and use their state to govern Board moves. Tasks now support business data, instructions, Queue dispatch and timed postponement. Integrators can save several Entity records atomically, while File Protection shares stored content within each Source and restores complete directory trees.

Highlights

• Workflow Instances provides an authorized process list, preview, history and a visual execution trace of the revision that actually ran.
• Board workflows have one Board-wide identity, configurable presentation and transition rules; administrators can suspend processes without losing their current step or original deadline.
• Queue work supports taking, dispatching, interrupting, postponing, reassigning and returning tasks, with capacity checks and recorded reasons.
• Entity saves gain an atomic multi-record API, clearer replay and error responses, mandatory lifecycle evidence and more informative change history.
• File Protection adds deduplication across files and history within a Source, directory recovery and updated Windows/Linux Agent and Recovery tools.

Detailed changes

Workflow Instances and execution history

The Process Instances page lists processes the caller may view or administer. Filters include Definition, status, start dates, waiting work and work requiring the caller’s action. Authorization, filtering and counts apply before pagination. The page supports desktop tables and mobile cards, with a preview drawer and a details page containing active steps and ordered history.

The Execution view shows the pinned revision, visited and current steps, waits, faults and traversal counts. It supports zoom, search, navigation and fullscreen inspection. Publishing a newer revision does not change this historical view. Missing graph content or incomplete traces are reported instead of inventing a path. Runtime administrators without Subject View receive a technical projection that omits Subject identity, node titles, instructions and choices.

Authorized runtime administrators can Suspend a Running or Faulted instance and Resume it later, with a reason and concurrency check. Suspension preserves visits, the pinned revision and the original Delay deadline. An overdue delay becomes runnable after Resume; a process suspended while Faulted still needs Retry after Resume. Suspended processes reject new responses and reserve their Definition/Subject pair against another start. Cancel remains available.

The supported executable nodes remain Start, Delay, User Input, DevLog and End. This release does not add parallel graphs, arbitrary User Input forms or the planned related-resource orchestration nodes.

Board workflows, transition rules and context changes

A Board-subject Workflow Definition now belongs to the whole Board. Authors configure its context key, order, visibility and optional signal-bar display. Existing process identities and pinned revisions are preserved during upgrade. Cards, drawers and details share process links and current facts.

Board transition rules can use persisted Workflow facts. A refused move explains the failed rules and shows the related processes the user may access. Background refreshes preserve readable content and edits during transient failures, and remove content when access is denied.

Transitions expose Allow System User, enabled by default. For an active transition, this contributes the System user’s required View, MoveItem and UseTransition permissions through normal Board Security. It does not authorize human users or skip transition rules. Configuration owns these contributions; turning the option off removes its contributions. Transition and endpoint status keys are required when the option is enabled.

Board and Workflow changes now publish explicit context-change events to affected Subjects and external Targets. They do not pretend that an Entity’s business fields changed or start a Workflow implicitly from a context-only event. SDK consumers can distinguish these events and their causes.

Tasks: data, Queue work and interruptions

Tasks can carry a description, due date, priority/subpriority, a business Context, Input Data and Working Data. Authorized users edit each through the ordinary Tasks commands, with property history and conflict handling. Instructions and their bound files are readable through Task access. Completion rules evaluate the saved Working Data. Permanent removal of a Context is refused while a Task still references it; archiving remains possible.

Authorized assignment removal is supported, including tasks without participants. Queue work adds Queue residence and ordering, Any/First/Last selection, Take, Take-and-Start and dispatcher assignment. Available-work lists respect selection and access rules. Capacity exceptions require the appropriate dispatcher authority and explanation; a dispatcher cannot override their own capacity. A Queue holding unfinished work cannot become Inactive; Draining provides the path to empty it.

Queue Executors can pause, resume, stop, block or postpone work under the configured rules. Postponement uses a fixed delay and lifetime attempt allowance, preserves assignment and Queue position, and returns to Idle through the Worker when due. Duplicate or stale timer deliveries do not return the task twice. Supervisors can resolve blocks; a performer can resolve only their own report.

Dispatchers and Task administrators can change or clear the Executor of unfinished Queue work. Once an Executor is assigned, a reason is required. Running work stops, a pause or postponement ends and the task becomes Idle; a block stays in place. Executors can return work only when the Queue permits it, always with a reason. Returns retain Queue residence, entry time and manual rank. The default return policy is NotAllowed.

Queue dashboards and assignment dialogs show authorized Worker load. Ordinary Workers see their own load. Lists and history show postponed return times and automatic returns. Peer-to-peer handoff and the later Queue-transfer increment are not included.

Entity saves, lifecycle evidence and integrations

POST /api/workspace/entity-composite-mutations saves 1–16 Create/Update steps across standalone Entity records in one transaction. A step can reference a record created by an earlier step. Validation, authorization, history, resource events, required audit and the operation receipt commit together. An unreadable new record rolls the whole save back. An updated record that becomes unreadable returns only its caller-known identity as a receipt.

The request limit is 1 MiB. File/InverseReference input, calculated or read-only fields and Markdown draft headers are unsupported. The 15-second cooperative execution budget is not a response-time guarantee. The C# equivalent, IEntityCompositeMutationService, is available to Command and HTTP endpoint functions as the current active user, including a Service user. It refuses trusted system invocations and an already open caller transaction. Code outside that call is outside its atomicity guarantee.

Single-record Create, PATCH, Archive, Restore and Delete now share a consistent request-error envelope. Exact retries retain the seven-day replay window. Update/Archive/Restore retries can return a safe receipt after the caller loses read access; an unreadable Create replay reports that the earlier create committed without disclosing its identity. The former per-actor limit of 1,000 live receipts in an operation scope is removed.

GET /api/workspace/error-catalog lets any active workspace user inspect the installed build’s error meanings and safe reactions for single-record and composite Entity mutations. Integrations should treat unknown outcomes conservatively and repeat only the identical request with the same key inside the replay window. An expired or unknown-age operation must not be automatically repeated as a new create.

Archive, Restore, permanent Delete, bulk lifecycle operations and record merge require a trimmed reason of 1–1000 characters. Lifecycle evidence is stored in the same transaction, including when ordinary field history is disabled. Native record history and embedded history components show reasons when permitted. Administrative audit search supports record identity filters and hides record, comment and file content that the reader lacks permission to see.

C# Create, Update, Import and BulkUpdate record the initiating function run, trigger or schedule in change history. Before-save functions that change the record appear as contributors. These C# writes no longer start Entity triggers on the written records; merge and responsibility replacement retain their existing trigger behavior. Database writes attempted by a C# validation function inside an Entity save are rolled back while retained diagnostics remain available.

Field authorization now resolves supplied keys exactly as the writer does, including accepted whitespace/case variations and Table cells. Updating a hidden record consistently answers as missing. Native Entity forms send only changed cells of existing Table rows, allowing saves alongside read-only columns. Changing only a String field’s maximum length preserves stored values; reducing it below any existing value is refused.

Entity list pages and access refresh

Each Entity List Page can select an exposed Statement as its fixed filter. Hosted queries intersect that filter with user filters, saved views and search before counting or pagination. The page’s export uses the last loaded filter. Restricted pages disable Manual Order. Clone and YAML portability preserve the setting; clearing or resetting it removes the restriction. Missing or hidden Statements fail closed. This page filter does not replace Entity Security.

Security recompiles saved Statements against current runtime dependencies when a stored plan is stale or unreadable. A Statement that no longer compiles grants nothing, while valid Statements continue to work. Board/target activation changes no longer require re-saving Security merely to refresh a plan.

Browser session changes now invalidate stale authentication/profile results and reconnect realtime for the current actor. Authorized attention-signal badges refresh after changes and reconnects and clear when the session ends. File Protection signal settings explain that calendar exclusions pause threshold timers, so counted hours can span a longer elapsed period.

File Protection and recovery

New File and Directory captures use one repository per Source, allowing identical content to share storage across file names and recovery points. Existing per-file history remains readable without repacking or changing stored object-version identities. Historical Glob points remain readable; new Glob capture is refused.

Updated Recovery supports a file, selected files, a subdirectory or a whole Source, including directory structure and empty directories. Temporary recovery remains mediated by the platform; Permanent recovery reads protected catalogs directly from storage with separately supplied owner credentials. Progress reports distinguish download, restore and verification. Restores publish without overwriting existing output, and Windows output inherits the destination’s access rules.

For new SourceTree points, Temporary recovery authority covers the Source repository. Selecting a file is a restore choice, not a file-level security boundary within that Source. Administrators must grant that access accordingly.

A repository or metadata failure belonging to one Source no longer prevents an Agent from receiving work for its other Sources. Identity mismatches fail the affected run; retryable repository preparation waits without monopolizing the Agent queue.

Platform upgrades with customer C# compilation errors

A confirmed compilation error in a Net Operation Project no longer stops a runtime upgrade. Preparation and activation report the affected revision and build so the application author can inspect and repair it in Development. The failed build preserves the previous artifact; incompatible functions remain unavailable until the author successfully rebuilds them. Infrastructure and database failures still stop the upgrade.

Release preparation and disk space

Preparation now removes eligible obsolete installation caches before building and staging packages. It preserves current and previous releases and packages still needed by unfinished operations. Verified archives and extracted packages already on the target machine no longer consume the disk budget a second time. The database recovery budget and protected free-space reserve remain in place.

Database and upgrade impact

The Workspace database changes for Tasks, Workflow/Boards, File Protection, resource-event identity and Entity List Page filters. Existing Queue creation requirements and stored command results are carried forward. Old File Protection history remains readable, and existing Sources receive no guessed historical File/Directory type. There is no Portal database migration in this comparison range.

Managed Apps require a full ReplaceRuntime replacement of WebApp, Api and Worker. Plan interruption while each app stops, applies database changes, refreshes stored rules, rebuilds extensions and starts the target runtime. No production downtime measurement is available.

Retain a verified pre-upgrade database backup, compatible runtime, configuration, Managed Secrets and the external-file recovery material. A database backup alone does not contain external file bodies. Board-wide Workflow affiliation cannot be reversed to the earlier target-bound model; new Tasks and File Protection data also impose downgrade restrictions. Reverting images alone is not a safe rollback. Use the supported restoration procedure and the compatible backup/runtime pair.

The upgrade establishes deployment evidence for the resource-event stream outside logical database dumps. API and Worker refuse readiness if it is absent, inconsistent or marked as an incomplete restore. Preserve the customer configuration and use supported stopped restore/recovery operations; copying a database or deleting the evidence file is not a repair procedure.

Unresolved release risk: source review found inconsistent schema metadata for Tasks in the latest migration. Resolve and validate that discrepancy before production promotion. This note does not certify the candidate’s database parity or a successful upgrade.

Deployment and operator actions

1. Use ReplaceRuntime, version 0.0.69-beta, components WebApp, Api, Worker. FromVersion is unset. Supply the full target runtime package; a delta/Portal-managed update does not perform the required Net Operation Project rebuild.
2. Inventory installed NetPackages, active and working Net Operation Project revisions, queued/leased C# jobs, schedules, Entity trigger bindings and resource-event deliveries. Resolve unpublished drafts deliberately: a full upgrade checks and rebuilds the working revision with the target toolchain. Successful builds activate that revision. Confirmed source compilation errors are reported for author repair and do not prevent platform publication.
3. Rebuild customer NetPackages against the new SDK, raise their PackageVersion and apply the compatible bundles in a coordinated window. Re-author installation packages embedding old bundles. For affected C# workloads, finish old jobs or explicitly plan their interruption/cancellation and retry handling; assess schedules that would create incompatible jobs during the transition. Do not infer automatic replay of uncertain business effects.
4. Complete target-package preflight and preserve recovery evidence. Correct ambiguous Board Workflow aliases, orphan placements or unsupported target templates on the installed version when preflight reports them. Review transition and endpoint status keys before the stopped reconciliation and review the default-on Allow System User permission contributions.
5. Let the supported upgrade apply migrations, refresh stored Statements/Security, establish resource-event stream evidence and rebuild the Net Operation Project before runtime startup. Confirmed customer C# compilation errors remain warnings; repair affected functions after the platform upgrade. A blocking infrastructure or schema failure after schema transition keeps API and Worker stopped; correct its cause and retry the supported operation or restore the backup. Never edit migration/checkpoint/evidence rows to force readiness.
6. Coordinate File Protection API, Worker, Restore Gateway/signing services, Agent 4.0.0 (protocol 4.0) and Recovery 2.0.0. Customer File Protection agents have a separate update boundary from Runtime VM agents. Confirm old writer authority has expired or drained through the supported fences before new captures; confirm File/Directory declarations and review historical Glob Sources. Verify actual API/Gateway memory headroom for large manifests.
7. After replacement, verify every in-scope app’s package/image version, API, WebApp, Worker and queue health, completed database/rule refresh, event-stream trust, compatible extension status and resource-event delivery. Repair any incompatible published Workspace UI through its normal build/activation flow. Record all app-specific warnings and unresolved acceptance below.

Concrete post-deploy scenarios

Use approved disposable business records and canary Sources. Record actor, operation identities, before/after state, expected/actual results and evidence.

1. Atomic Entity save: as an ordinary authorized user, create two linked records in one composite. Repeat the identical request/key and confirm one pair exists and the result reports replay. With a new key, make the final step invalid and confirm neither record is saved. Verify the installed error catalog describes the answer. Check a representative rebuilt C# Command and its history source, including any downstream automation affected by the trigger change.
2. Board Workflow: open an existing process from Process Instances and confirm its pinned graph and history. Start an approved Start → User Input → Delay → End process. Suspend it with a reason, confirm a new response is refused, then Resume and respond once. Suspend again during Delay, wait past its original deadline, then Resume and verify that it advances once. Attempt a Board move guarded by its Workflow state before and after completion; verify the refusal explanation, allowed move and passive refresh. Check a reader without Subject View and a System-user transition with the configured permission/rule constraints.
3. Queue task: dispatch approved work to an Executor with capacity, save Working Data, start and postpone it. Confirm Worker return to Idle occurs once. Change an assigned Executor with a reason and verify history. Return the task through a Queue permitting returns and verify Queue position and the recorded reason. Check the same task and controls at desktop and 375px.
4. File recovery: restore an existing per-file point with the updated Recovery into a new destination and compare its saved digest, plus an independent original digest when available. Capture an approved Directory canary, change and rename files, then restore a file, subdirectory and complete Source. Verify bytes, paths, empty directories, access scope and no-overwrite behavior. Production Permanent recovery requires the owner’s separate credentials; actual retention-expiry proof remains pending until its real horizon.

Compatibility and breaking changes

• C# artifacts: Package gateway contract is 13 and Net Operation Project gateway contract is 10, checked by exact equality. Core SDK/templates and the module SDK family previously on 2.0.0 use 3.0.0; Workflow SDK/Engine use 4.0.0 and Tasks SDK uses 3.0.0. Workspace contract generator is 6.10.0. Older compiled artifacts fail closed until rebuilt. Refresh previously downloaded project SDK libraries. The Workspace UI host contract remains 1.
• Receipts and automation: C# Entity record/responsibility receipts now use typed identities. Update result matching code; SafeFailure.Metadata is removed. Merge/bulk replay receipts that previously used a generic resource identity now carry an Entity identity. Supply required lifecycle/merge reasons and review reliance on C# writes starting Entity triggers. Pre-change completed merges cannot be replayed under the new reason-bearing fingerprint.
• Entity HTTP errors: malformed single-record mutation input uses ApiResponse and public member names. Changed requests under a committed key return 409 moltaro.security.idempotency.keyReuse; unreadable stored results use moltaro.security.idempotency.replayInvalid. Stale record versions use 409 moltaro.security.concurrency.staleRowVersion. Hidden Update targets return 404 moltaro.instances.notFound. An unreadable Create replay returns 403 moltaro.instances.replay.resultNotViewable and must not be retried with a new key. Supplied responsibility subjects require EffectiveFrom.
• Field writes: every supplied value still requires its field write permission, even when unchanged. Send only intended editable fields. Unknown or Part definitions passed to ordinary C# Entity automation now return moltaro.definitions.notFound instead of entering the standalone record path. First responsibility assignment can use Guid.Empty only while the record has no responsibility state; subsequent assignments use ResourceRowVersion.
• Workflow/Boards: Board Subjects no longer accept BoardTargetDefinitionId, and the Board-target subject-options route is removed. Use Board-only Subjects. Stored revisions remain executable; saving/publishing node keys now requires a Latin letter followed by ASCII letters, digits, underscores or hyphens, up to 64 characters. Consumers must handle Suspended and context-change events.
• Tasks: clients must support assignment removal, Queue Executor semantics, postponement and the reason required for changing an assigned Executor. The strict Queue installation document contract is 9; regenerate older Queue resources before importing them.
• File Protection: new captures require Agent protocol 4.0 and use SourceTree layout 2. Recovery 2.0.0 reads old and new catalogs; new Temporary descriptors use schema 2 while Permanent outer configuration remains schema 1. Old writers receive no new write authority. New capture does not support Glob.
• Restore/startup: the runtime requires matching external stream evidence. Use the target package’s deployment/backup tools for initialization and restore. A privileged physical clone carrying both database and evidence is outside the logical-restore detection guarantee.