sys:session & sys:stage

In keeping with documents all the way down, a session’s staged work is exposed as synthesized, read-only documents that any client can subscribe to with the ordinary document API.

sys:session — the summary

One document summarizing all staged work in the session: one entry per staged document, with enough metadata to render a “pending changes” list — what’s staged, what’s blocked, what would commit.

sys:stage:<docId> — the detail

Per staged document, the full picture: the ordered lanes of JSON Patch changes and Yjs updates, base metadata, and conflict state. This is what a review UI renders when the user clicks into one pending document.

Why synthesized documents?

These documents are projections — computed from the changeset, never written directly. Exposing them as documents means:

• A review sidebar is just another document subscription — same hooks, same reactivity as the rest of the app.
• Devtools and agents introspect staged work with the API they already have.
• No second “session inspection API” to design, version, or learn.

It’s the same trick as sys:index and sys:client-docs-status: when the engine has interesting state, the answer is a document.