Where the system sits
Univer Runner is not one application. It is a coordinated set of local shells, hosted surfaces, and remote authority boundaries.
7 min read
Actors
Four primary users
Alice edits locally, Bob reviews in hosted UI, David edits the remote workbook, and Charlie safely joins an existing remote workbook.
Product shape
Multiple coordinated surfaces
The stack combines local CLIs, a hosted review control plane, a runner runtime, and external remote workbook infrastructure.
Boundary to remember
Remote workbook is external authority
The remote workbook and remote revision are outside the repo's durable truth, even though local commands interact with them.
The system is bigger than one app
The repo produces several product surfaces, each serving a different part of the collaboration story. That is why a single-app mental model keeps breaking down under real use.
From an evaluator's point of view, the right question is not 'which page is the product?' but 'which surface answers which class of user need?'
Who interacts with it
Alice
Local builder
Creates, writes, persists, stages, commits, and pushes work from local shells.
Bob
Hosted reviewer
Opens hosted review, comments on revisions, and approves work without reading raw repo files.
Charlie
Another local builder
Binds to an existing remote workbook, pulls a clean baseline, and continues local-first work safely.
David
Remote workbook editor
Changes the remote workbook through MCP-facing surfaces, creating remote drift that local users may later need to reconcile.
Which surface each actor uses
| Surface | Who uses it | What it is for |
|---|---|---|
| agent-sheet | Alice and Charlie | Local editing shell for workbook-native commands and persistence. |
| sheet-git | Alice and Charlie | Git-shaped workflow shell for repo history, review publishing, and origin replay. |
| review-host | Bob | Hosted HTTP and HTML shell for review detail, comments, approvals, and delivery state. |
| apps/univer-runner | Runtime integrators | Runtime-facing app surface used to execute workbook operations. |
| qa-harness | Maintainers and release owners | Story-driven harness that exercises realistic product flows end to end. |
| Universer and MCP | David and system adapters | External remote workbook authority and protocol surface. |
Three operating modes
Key boundary
Hosted review is a product surface inside this stack. The remote workbook remains an external platform boundary with its own authority.
- 1
Local-first only
Alice can create, edit, persist, stage, commit, and assemble reviewable work entirely on her machine.
Outcome: No hosted review or remote workbook is required.
- 2
Local plus hosted review
Alice publishes a hosted revision, Bob comments and approves, and review state becomes canonical in hosted truth.
Outcome: Review can close before any origin replay happens.
- 3
Local plus hosted review plus origin replay
Approved lineage is replayed to the remote workbook, remote progression is confirmed, and pull projections are updated.
Outcome: This is the full collaboration loop.
Architecture Overview
Return to the high-level truth model and shell versus kernel split.
Subsystems
See which package or shell owns each boundary in practice.
Previous
The architecture in one pass
Univer Runner is an offline-first spreadsheet collaboration stack that joins local editing, Git-shaped workflow, hosted review, and remote workbook sync.
Next
How work moves through the stack
The most important system behavior appears in the handoff between local editing, hosted review, and remote replay.