Moltaro 0.0.28-beta

Release date: 2026-08-26

This release introduces governed Work Schedule calendars, assignments, exceptions, and Worker-to-User associations, while giving managed Runtime VMs a safe external staging-volume option for backups and deployment work.

Highlights

• Work Schedule provides one responsive operational console for effective Worker and Site schedules, calendar revision authoring, base assignments, temporary moves, leave, closures, additional working time, and explainable exception precedence.
• Operational Location, Site, and Worker become explicitly provisioned system Entity Definitions. Effective civil time follows the dated Worker-to-Site-to-Operational-Location-to-time-zone chain without a viewer time-zone fallback.
• Administrators can associate one current Worker with one User while retaining immutable association history. Worker names become the authoritative display names for an associated User without overwriting the stored User profile.
• A Runtime VM can use one explicitly selected attached provider volume at /mnt/moltaro-staging for transient backup, install, update, agent, and deployment artifacts. Device identity, mount separation, write access, and agent capability are verified fail closed.
• Backup quota reservations are separated from completed artifact sizes, so a failed reservation is no longer displayed as a one-terabyte backup. Release cleanup retains current and previous Docker images and removes only exact unused older tags after successful acceptance.

Detailed changes

Work Schedule

• The Work Schedule module has independent lifecycle and readiness states. Enabling it does not silently create operational catalogs, calendars, or customer access. Administrators explicitly create or repair Operational Location, Site, and Worker definitions and configure their ordinary Entity Security.
• Working Calendars use immutable published revisions and explicit Draft creation, editing, publication, scheduled-revision cancellation, and bounded deletion. Weekly intervals and breaks are authored in civil time with a minimum interval duration of 30 minutes.
• Append-only Site calendar and Worker Site assignment chains resolve the effective Calendar for a date. Workers may inherit a Site Calendar or use a personal Calendar, and unresolved Site, location, or IANA time-zone context remains explicit rather than falling back to the viewer.
• Schedule Exceptions record whole-day or interval additions and removals plus bounded Worker moves. Correction and cancellation append evidence instead of rewriting history. Resolution is deterministic across Worker, Site, and Workspace scopes, with removal winning equal-scope conflicts.
• The responsive Schedule/Exceptions console offers Worker, Site, and Matrix views, desktop and mobile-specific presentations, deep-linkable date and subject state, evidence drawers, collision explanations, and field-safe navigation. Details, Drawers, Tables, and Cards can expose governed Work Schedule context through shared Entity UI extensions and Object Context Facts.
• Net Operation Project functions receive supported Work Schedule automation command and query services. Host-derived actor and provenance, readiness, authorization, idempotency, optimistic concurrency, immutable history, and audit remain authoritative.

Workers and Users

• Worker definitions use protected FirstName and LastName fields with the default presentation {FirstName} {LastName}. Explicit catalog repair moves a legacy protected Name value into FirstName and retires Name; it stops with dependency diagnostics when a custom surface still requires the old field.
• A current Worker-to-User link is one-to-one and history-preserving. Link, change, and unlink commands are serialized, idempotent, permission-checked, and automatically clean up current links when a User or Worker is removed.
• Associated Users are presented with the effective Worker name across core read models while their stored User names remain unchanged. User forms make those effective names read-only until the association is removed or Work Schedule is disabled.

Managed hosting, backups, and releases

• Platform administrators can choose System disk or one exact attached provider volume for a Runtime VM’s operational staging. Existing VMs remain on the system disk until an administrator explicitly changes the setting.
• External staging uses the fixed /mnt/moltaro-staging mount. Portal requires the new agent capability, and both the agent and Deployctl verify that the provider-selected device is mounted read-write, differs from the root filesystem, and has sufficient capacity. There is no silent fallback after external staging is selected.
• Managed backup dump, assembly, archive, and upload staging uses the VM-level destination. Completed backups remain in Object Storage; PostgreSQL data, Docker data, active application files, and the active agent remain on their existing system-disk paths.
• Backup catalog accounting now distinguishes a temporary quota reservation from an observed artifact size. Historical failed placeholder sizes are cleared, while available backups retain their measured sizes.
• After successful release acceptance, Deployctl keeps the current and newest previous image tag for each managed repository. It removes an older tag only after proving that no running or stopped container references its image; it never performs a broad Docker prune.

Database and upgrade impact

The Portal database is migrated during this publication. Existing Runtime VMs default to system-disk staging, so the migration does not redirect any active operation. Historical failed one-terabyte backup placeholders are corrected; available backup sizes and Object Storage artifacts are unchanged.

This publication prepares an update from 0.0.27-beta but does not apply it to existing Managed Apps. Their Workspace databases and customer-serving runtime remain unchanged and have no application downtime during this release.

Applying the prepared update later creates the Work Schedule schema and its module, calendar, assignment, exception, Entity UI extension, operational context, and Worker-to-User association state. That later application requires an ordinary verified recovery point and update downtime. Rollback after the Workspace migrations must restore the matching pre-update database and runtime when customer data has already been authored against the new contracts.

Deployment and operator actions

• Publish 0.0.28-beta using PrepareUpdate from exact source version 0.0.27-beta, with WebApp, API, and Worker components. Do not apply the update to existing Managed Apps in this release.
• Deploy and verify Portal, public documentation, the runtime artifact, and Runtime VM agent 0.1.41. Existing Managed Apps must remain on 0.0.27-beta.
• Before selecting external staging, attach and prepare the provider volume at /mnt/moltaro-staging, then verify its stable provider identity, EXT4 mount, read-write state, separation from /, and available capacity.
• In Portal, select the exact attached volume for the intended Runtime VM only after agent 0.1.41 reports capability runtime-vm-operational-staging-volume-v1. Wait for the next heartbeat and require the Operational staging card to report Ready.
• Create one explicitly requested OMS backup, verify that staging activity and capacity are reported on the attached volume, confirm that the completed artifact becomes Available in Object Storage, and confirm that transient local files are removed.
• Work Schedule remains inactive in the current production applications until the prepared update is applied. When it is adopted, configure its module, operational catalogs, Entity Security, at least one published Calendar, and the optional Runtime Menu explicitly.

Compatibility and breaking changes

Runtime VM agent 0.1.41 adds the operational-staging capability. The Portal refuses an attached-volume selection when the active agent does not advertise that capability. Once external staging is selected, backup, restore, install, update, agent-update, and release operations fail closed if the exact volume is missing, mismatched, read-only, mounted on /, or lacks capacity.

The prepared Managed App update is valid only from 0.0.27-beta. Work Schedule introduces new Package SDK and persisted contracts. Its effective Worker civil time no longer uses a direct Worker-to-Operational-Location relation; it follows the effective Worker-to-Site and Site-to-Operational-Location chains. Explicit Worker catalog repair retires the protected legacy Name field only after dependency validation. Integrations that later adopt Work Schedule must use the supported automation services and current Entity roles rather than relying on those removed intermediate contracts.

No currently running Managed App contract changes until the prepared update is explicitly applied.