**Note: Lolly Work**

This guide covers the optional organisation service. Configuration, console and API paths refer to your Work instance. The packaged console keeps its release-matched copy of this guide.

# Lolly and Work 1.1.0

The shared release is published as [Work v1.1.0](https://github.com/lolly-tools/lolly-work/releases/tag/v1.1.0)
and [Lolly web-v1.1.0](https://github.com/lolly-tools/lolly/releases/tag/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](https://github.com/lolly-tools/lolly-work/blob/v1.1.0/docs/install.md),
[deployment options](https://github.com/lolly-tools/lolly-work/blob/v1.1.0/docs/deployment.md)
and [documentation index](https://github.com/lolly-tools/lolly-work/blob/v1.1.0/docs/README.md).

## Matching components

| Component | Version or source |
|---|---|
| Lolly desktop product version | 1.1.0, from the Tauri configuration; native release held |
| Work application | 1.1.0 |
| Published Work tag source | b17800561df9a1e39cc4befce986a20fa1c7f661 |
| Work Helm chart | 0.3.0; appVersion 1.1.0 |
| Lolly source | 0359d8106bccbd1da56b5552605199f0bf705472 |
| Qualified Work runtime source | 464ac88d4498b00985dfbcdb47dd96655425f426 |
| Engine | 1.259.0 |
| Tool-author core | 1.2.0 |

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](https://github.com/lolly-tools/lolly-work/actions/runs/38284012710),
including native server and real Chromium worker qualification on Linux amd64.
Helm and deployment checks passed. [Release workflow attempt 2](https://github.com/lolly-tools/lolly-work/actions/runs/38289495755/attempts/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:

```text
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:

```text
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](https://lolli.li/lolly-work-1.1.0-ynh3.tar.gz) 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:

```text
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](https://github.com/lolly-tools/lolly-work/blob/7f2be8cb52df5b53b539009ec62e2f151ed72d18/deploy/yunohost/README.md). 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](https://github.com/lolly-tools/lolly-work/actions/runs/38284099878)
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:

```bash
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.

---

Content ([MPL 2.0](https://www.mozilla.org/en-US/MPL/2.0/)) · [Lolly Work source](https://github.com/lolly-tools/lolly-work/tree/7f2be8cb52df5b53b539009ec62e2f151ed72d18) · [lolly.tools](https://lolly.tools)