Lolly and Work 1.1.0

The shared release is published as Work v1.1.0 and Lolly web-v1.1.0. Work's tag remains b17800561df9a1e39cc4befce986a20fa1c7f661; the Lolly web tag remains 0359d8106bccbd1da56b5552605199f0bf705472. Installation and production acceptance are tracked separately. Lolly desktop and mobile release holds remain.

Start with the tagged installation guide, deployment options and documentation index.

Matching components

Engine and core versions describe their own contracts. They are not reset to the product version. Lolly's private workspace package version is also separate from the desktop product version. engine-pin.json carries the exact Lolly origin, packed content hashes and schema hashes; content-resolver-pin.json carries the same committed resolver origin. Both are generated by the maintained producers.

The Work server consumes that unmodified engine and core. The Chromium worker is a separate image qualified with the same signed Lolly shell and catalog. The release workflow published both server and worker tags as 1.1.0; the chart uses that application version for both default image tags and the migration Job. Production installations should select the qualified immutable digests. The worker remains optional and disabled by default.

Changes carried by this release

The matched Lolly source includes the Design hierarchy and presentation work, responsive editor fixes, provider-reference catalog admission, export-error propagation, complete delivery validators, transition token bindings and the reviewed Strip Data 1.3 metadata cleanup. It also includes the reviewed source navigation, emoji popover and numeric field styling. Work retains its signed per-caller catalog, content coding verification, publication readiness, governed providers, collaboration and concrete public delivery update helpers. The shared version records a matched application release; it does not enable a new deployment, extra writable collaboration owners or an anonymous private-file service.

Published images and qualification

The tagged Work source passed all five ordinary CI jobs, including native server and real Chromium worker qualification on Linux amd64. Helm and deployment checks passed. Release workflow attempt 2 published and signed both multiarch images from the exact tag. Its workflow source was 78e22f33dc8c3ba678133cbbfdeda6cbd771c3d6, separate from the tagged application source. Original failed attempts and the inherited successful source-artifact receipt remain preserved.

Use the verified immutable manifest digests:

ghcr.io/lolly-tools/lolly-work-server@sha256:db96f0d0f84b81ec609a3816031bd7f78bbb2af87d36f49a6fef8a76c8a656ae
ghcr.io/lolly-tools/lolly-work-render-worker@sha256:8dbe45a9586f426c72cb87eb121da393e18c1074ff3ea5d886a39dceefdfbd5f

Anonymous manifest, configuration and layer-metadata access and both keyless signatures were independently verified. The certificate issuer is https://token.actions.githubusercontent.com; its identity is https://github.com/lolly-tools/lolly-work/.github/workflows/release.yml@refs/heads/main. The release's source/image metadata records the platform digests. Linux amd64 and arm64 images are published; native arm64 runtime qualification remains open.

Both GHCR packages are public and grant this repository's Actions access Write. The temporary organization permission to create public packages was restored to its original disabled setting after the package visibility changes were verified.

Prepare and qualify

Use clean isolated source checkouts and preserve the existing deployment's data, configuration, keys, pin and rollback artifacts. From the final committed Lolly source, refresh Work with the maintained producers:

node scripts/vendor-content-resolver.ts --write
pnpm run repin-engine --apply
pnpm run verify:engine-pin
pnpm run typecheck

The committed vendor/lolly checkout must be the exact release source. Re-pinning packs its actual engine/core/schema bytes, updates the lockfile and runs its coherence and local test gates. Do not edit the resulting hashes or patch vendor source. A local test skip is not qualification for the skipped component.

Before a version tag or image publication, require ordinary CI on the exact final Work commit and the exact Lolly source. Require the native server image checks and the actual Chromium worker checks with the matched signed shell, including real SVG/PNG rendering, cancellation and egress controls. Preserve the original workflow, source, archive, image and pin receipts. The tagged server and worker must come from that same Work commit. Neither an older qualified tuple nor a successful metadata-only rehearsal admits these images.

Generic installers remain supported for their own targets. Existing production instances follow their current authority handoff and guarded cohort publication route. Preserve immutable pin, pack, shell and configuration identities, complete owner and storage guards, and actual runtime acceptance before switching them. Never mount an active asset volume into a staging Pod.

YunoHost packaging

1.1.0~ynh3 is the current beta test candidate for the engine 1.259 cohort. It pairs Work runtime source 464ac88d4498b00985dfbcdb47dd96655425f426 with the genuine signed neutral Lolly build of source 0359d8106bccbd1da56b5552605199f0bf705472. The web archive is published at https://lolli.li/lolly-web-1.1.0-ynh3.tar.gz, with full SHA-256 8bc8121a68e6fee6dda3902ed48d5e2669353bcfd101ca3822990235a2099376. It was built with models base https://lolli.li; model bodies are excluded. Its complete archive bytes, included-file hashes, signed P256 catalog and decoded gzip copies passed local checks, and its published HTTPS bytes were verified. These checks establish the artifact, rather than a YunoHost installation.

The published Work archive is 11,889,092 bytes with SHA-256 e7b70e269b261bfed4bc5f7c6dce69eec84885ce2b0bf9335143a1cc3ff2efbb. It was cut from clean packaging source 9ba7104377f6aa3102053fb26e407fa67463d336 using the maintained producer. That source adds release documentation and excluded deployment metadata to the qualified runtime source; its installed server, engine, console, lockfile and other runtime files remain literal. The original producer command was:

node scripts/yunohost-release.ts --ynh-rev 3 --shell-url https://lolli.li/lolly-web-1.1.0-ynh3.tar.gz --shell-sha256 8bc8121a68e6fee6dda3902ed48d5e2669353bcfd101ca3822990235a2099376 --out ABS_NEW_ARTIFACT_DIRECTORY

The producer uses the held Git tree with a fixed UTC timestamp of one second after epoch, canonical file permissions and deterministic gzip. Each packaging revision uses a distinct archive name, and an existing output is refused. The adjacent .source.json records the actual commit, tree, archive size, full checksum and shell pin; it does not assert runtime compatibility. Review and commit the generated manifest, then recut into a separate directory and require full archive byte equality. Deployment metadata is excluded from the archive, so that manifest commit preserves the checksum. Release documentation is included and must be recorded as an explicit source change. Reproducing those archive bytes requires the original packaging source. A new cut, including this documentation update, requires a new revision and filename; never replace the published ynh3 archives or hand-edit their pins.

After both immutable archives are published and the package directory is mirrored, run .github/workflows/yunohost-runtime.yml with the reviewed full 40-character mirror commit and exact version 1.1.0~ynh3; the command is documented in the package README. It uses a fresh Ubuntu runner and the official Incus checker on amd64 Debian Bookworm, requiring successful root and multiple-instance installation, upgrade, backup/restore and URL-change results. The package also tests upgrading from mirror commit db60f651fbeb561e4b330a1dd44bd4aaf463e635 (0.2.0~ynh1).

The actual runtime run used mirror commit 583cdc4af5322e683991a548428859b79084db2d on amd64 Debian Bookworm with YunoHost 12.1.41.2. Six current-package checks passed: root installation and reinstall, multiple instances, backup/restore, same-version upgrade, URL change and package lint.

The complete seven-check run failed while preparing the historical 0.2.0~ynh1 baseline: its unsupported full_domain field prevented installation, so the application upgrade never began. The historical shell URL also advertises checksum metadata that differs from its old manifest; those old bytes were not requalified. Upgrade from 0.2 and arm64 installation remain unqualified. There is no stable YunoHost tag or catalog promotion; earlier ynh1 and ynh2 pins remain historical.

For a fresh beta installation, use the exact reviewed package:

sudo yunohost app install https://github.com/lolly-tools/lolly-work_ynh/tree/583cdc4af5322e683991a548428859b79084db2d

Keep a verified backup and complete an independent restore before upgrading an existing instance. The six passing checks do not qualify the historical upgrade path or every deployment platform.

Migration and recovery

This preparation adds no SQL migration. The maintained migration history contains56 files through 0066_catalog_delivery_sequence.sql. Before upgrading, verify the actual database migration history with pnpm run migrate:status, take a fresh verified backup and complete an independent restore. Apply the maintained migration runner or the reviewed chart migration Job only against the selected instance. Preserve the generation and sequence tables and do not reset their rows to make an old catalog appear current.

Retain the previously accepted server and worker digests, shell and pack roots, public key pin, configuration generation, owning Deployment specification and recovery receipts. If a new cohort fails acceptance, use its reviewed inverse application patch. A successful inverse patch still requires runtime observation. Do not delete active or rollback volumes or automatically undo database changes. Database restoration is a separately reviewed recovery operation. The replica and room-routing limits, permissions and instance credentials remain unchanged.

Production and remaining acceptance

As of 2026-10-13, private lolly.ing serves the qualified Work464/Lolly0359 cohort. Owner, content, authenticated catalog and normal-TLS checks passed, as did worker SVG/PNG and scoped document-agent read/claim-inspection/revocation checks. Current signed-in browser observations reached Tools, presentation advance/exit and reload/reconnect with Saved to work. Full browser acceptance remains pending; an independent local recovery-copy warning is still under diagnosis. These document-agent checks do not establish restricted public MCP result-link delivery.

Public lolly.tools now serves Lolly0359 as a verified web-only release. Pre-promotion qualification verified all 45,777 static-file hashes, all 177 model hashes and the complete staged HTTP matrix; the qualifier and its policy were retired before promotion. Read-only serving observation on 2026-10-13 verified the serving owner, complete physical static/model roots and normal TLS through index and small-model body probes. Those limited requests do not repeat the complete HTTP matrix or establish browser acceptance. Full owner and storage guards passed, and previous public roots and models remain retained for rollback. Fresh recovery remains mandatory; original failures are retained and never replayed.

Main 6a77ca47a7beeb6f6a122193b7f5411a9d6abac2 adds the reviewed accepted-baseline handoff for recurring public delivery updates. Its four source workflows and all thirteen required jobs passed. It reuses actual publication evidence for the next prepare while retaining source, owner, storage and rollback guards. This follow-up does not change the published v1.1.0 tag or artifacts; the generic adapter's first native target acceptance remains open.

Main 41ce3844f0790ab939883d234ce11ecaa2a65d35 adds the reviewed generic HTTP collection-budget and report correction. Its 35 runtime checks, six optimized checks and Node wrapper passed locally. At this status update, its four source CI workflows remain pending; local checks do not establish their result. Published release tags and artifacts remain unchanged.

Plan300 remains in progress. M8 restricted result-link activation still needs genuine two-principal OAuth, a large PDF, real 300-second expiry, drain/restart, accounting and normal-TLS acceptance. M9 has historical EA backend and partial 640 WebP/parent verification proofs; its latest browser run refused before complete original placement/export acceptance, and 0359 has no M9 runtime acceptance yet. The public web rollout does not close those remaining milestones. Post-promotion end-to-end delivery, model and retention checks and final plan closeout remain required. Same-origin delivery remains selected; no third-party CDN or separate asset host was activated.

Plan295's P3f fidelity, broader phase3 and physical/native release holds remain open. Multiarch image publication, web acceptance and YunoHost beta checks do not close those holds or qualify the historical 0.2 upgrade and arm64 installation.