Multi-user and cloud collaboration

[mberrys]

Scope

Comes after revision identity, markup and proof approval exist. Do not attempt Google-Docs-style concurrent editing of arbitrary PDF object streams.

Model (optimistic revisions)

DocumentRevision: id, parent, file_hash, mutation_log, author, timestamp. Users edit a checked-out revision; saving creates a new immutable revision; conflicts are detected from object IDs / mutation sets.

Stages

1. Shared files, revision history, comments.
2. Assignment, proof approval, roles, audit history.
3. Simultaneous presence and non-conflicting object edits.
4. Sophisticated merge/conflict handling.

Roles are explicit: owner, production operator, reviewer, customer approver, read-only. Keep binary PDF storage separate from structured collaboration metadata, so Loop never requires a cloud database to interpret a production PDF.

Roadmap boundary

This widens the platform beyond the current local-first contract: the current roadmap lists multi-user collaboration/sync as out of scope through 0.8.0. This issue is deliberately parked as future work and requires its own roadmap/ADR decision before any implementation.

Deliverables (when promoted)

• Revision/mutation-log contract with conflict-detection fixtures on the same object edited twice.
• Storage split proven: collaboration metadata loss never makes a production PDF unreadable.
• Role enforcement tested per stage; approvals bound to revision identity.

Prerequisites / related

Revision/provenance model; Review, markup, and XFDF annotation interoperability; Customer proof and approval packages; a decided hosting model (none required before stage 1).

Batch context (2026-09-15 architecture review). These items are epics sharing five foundations, not isolated UI features: a production PDF object/mutation engine (parse page content/resources into an editable object model, mutate transactionally, regenerate a valid PDF, preserve untouched objects, run render/preflight/separation regression after every mutation), a separation/color engine, a sheet/layout engine, a production semantic/job model, and a revision/provenance model. Every edit is expected to produce a change record (changed_object_ids, operation, before, after, warnings, reversible). Recommended sequencing: Ink Manager + mutation foundation + printer furniture + basic hairline normalization first; then imposition and direct-object editing foundations; then ISO 19593 packaging; then PDF/VT and XJDF; customer portals and cloud collaboration much later.

Parked: no milestone, labeled future planned. Promote by assigning a milestone and removing the label when a release train picks this up.