Moltaro 0.0.16-beta

Release date: 2026-08-11

This release unblocks scheduled Package SDK attachment imports into managed object storage, adds complete and durable duplicate-detection workflows, fixes Data Explorer preview ownership and overflow behavior, and makes Runtime VM agent publication an enforced part of the production release transaction.

Highlights

• Scheduled and queued Package SDK code can upload managed attachments through the Worker capability without impersonation, ACL broadening, direct S3 credentials, or a storage bypass.
• Exact duplicate checks on record details use complete authorization-shaped candidate queries, while table users can start, close, recover, cancel, or retry a durable actor-owned full scan executed by the Worker.
• Data Explorer preview navigation keeps the correct host ownership and related grids remain usable when their content exceeds the drawer viewport.
• Deployctl now treats the Runtime VM agent as a mandatory signed release artifact, activates it atomically, restarts the service, verifies the selected binary, and retains rollback behavior on activation failure.

Detailed changes

Managed attachment uploads

• The file-body signer permits both API and Worker app-scoped capabilities to execute the exact managed multipart lifecycle: create, authorize parts, list parts, complete, and abort.
• Worker-only delete and provider-inventory operations remain Worker-only. API capabilities still cannot use those cleanup operations, and neither runtime capability can select a bucket, cross an application binding, receive an S3 credential, or bypass the new-upload rollout switch and signer rate limits.
• The change aligns the signer with the supported IAttachmentService UploadStreamAsync and UpsertStreamAsync contract, whose runtime bridge may execute inside API or scheduled Worker hosts.
• Regression coverage proves the complete Worker upload lifecycle, disabled rollout rejection, API cleanup denial, app/bucket isolation, exact-part geometry, idempotency, and the scheduled attachment publication/replay path.

Record matching and duplicate detection

• Anchored record-detail checks execute complete exact matching over the full actor-visible archive scope with bounded SQL candidate selection, stable cancellation, and localized API/UI errors.
• Data Explorer table checks retain their bounded immediate review and can now enqueue a complete Worker-owned scan. Scan state, progress, results, retries, cancellation, leases, idempotency, actor authorization facts, and retention are durable in the Workspace database.
• Full-scan results are published only as a complete attempt; execution or result-budget failures do not expose partial duplicate groups.
• Public documentation, OpenAPI, agent navigation, backend tests, WebApp tests, E2E coverage, and named 10k/100k load evidence describe the shipped anchored and full-scan behavior.

Data Explorer behavior

• Preview ownership and open-target navigation now stay with the correct Entity host when Data Explorer renders special blocks and projections.
• Related grids no longer force the preview drawer beyond its usable viewport; focused WebApp and E2E coverage protects desktop and hosted-layout behavior.

Release engineering

• Runtime VM agent build, signed publication, atomic current/previous activation, selected-binary verification, and rollback evidence are mandatory release stages instead of an out-of-band operator action.
• Activation explicitly restarts an already-running systemd service after the release symlink changes, so the live process cannot continue serving the previous binary.
• Task branches must use isolated same-name upstreams and explicit first-push refspecs, preventing later IDE or human sync operations from targeting a protected branch accidentally.

Database and upgrade impact

The Workspace database changes additively to persist durable record-matching full scans and their results. Existing records and matching profiles are not rewritten. There is no PortalDb change. Each Managed App has ordinary full-replacement downtime while the transactional schema change and startup readiness complete. Keep the Deployctl recovery point; a failed release must use coordinated recovery rather than manual table removal or an older runtime against a partially advanced database.

Deployment and operator actions

• Publish 0.0.16-beta as a full Managed App runtime replacement for every production Managed App. Do not prepare or apply a delta update package.
• Deploy Portal, StorageSigner, regenerated public documentation, the base runtime package, and the mandatory Runtime VM agent artifact through the interactive production Deployctl workflow.
• Replace API, WebApp, Worker, RabbitMQ configuration, and runtime package for east sos 1, OMS, and Questionnaire while preserving each Workspace database, managed file-body binding, object-storage bucket, and available backups.
• No capability rotation, S3 policy edit, application ACL change, or VentControl package change is required. Existing distinct app-scoped API and Worker capabilities remain valid after the signer release switches atomically.
• After deployment, run Portal/signer/runtime health checks, verify all three application routes, and execute the OMS scheduled retry that previously failed with filesystem.upload.providerUnavailable. Acceptance requires an Available Order-owned attachment, matching download bytes, resolved migration issue, idempotent replay, and unchanged source-user attribution.

Compatibility and breaking changes

• No supported Runtime API, Portal API, Package SDK type, file-body storage key, capability token format, or persisted business-data contract is removed.
• Worker capabilities intentionally gain only the five exact managed-upload lifecycle operations required by the already documented scheduled Package SDK contract. Provider inventory and delete boundaries are unchanged.
• The new full-scan persistence schema is additive. Older runtimes do not use it, but production rollback must remain coordinated with the release recovery point rather than treating a mixed runtime/database state as supported.
• No client configuration change is required. Full-scan users receive new durable behavior through the existing Data Explorer and record-matching surfaces.