The Status Bar

The status bar (<footer className="em-statusbar">) is the strip across the very bottom of Edit Mode. Every value on it is derived from state that some other control owns, and it answers one question at a glance: is it safe to walk away from this scene right now?

When the answer is no, each indicator is also a button: click any of them to open the Problems panel and see exactly what is wrong.

The status bar footer showing the Saved/Valid draft/Scene valid status dots and the current project name

The three status dots#

Three coloured dots (green em-status-ok, amber em-status-warn, red em-status-error), left to right:

Dot	States	What it reflects
Save state	`Saved` / `Dirty changes` / `Invalid draft`	The same `saveStateLabel` the topbar's save-state pill shows — whether the draft on the server matches what is in front of you, and whether any open Deck/Model/File/Script tab still holds edits its backing file doesn't have.
Draft validation	`Validation pending` / `Valid draft` / `Invalid draft`	The server's validation result for the whole draft (manifest + scene + script text), returned in `response.draft.validation` whenever the project loads or saves. `Validation pending` means no server response has come back yet — this dot does not recompute itself locally.
Scene validation	`Scene pending` / `Scene valid` / `Scene invalid`	A live, client-side re-check: `editSceneSnapshotSchema.safeParse(sceneDraft)`, recomputed on every edit to the in-memory scene draft. This is what tells you immediately that an edit broke the schema, without waiting on a round trip.

The draft validation and scene validation dots can disagree, and that is meaningful: the scene dot reacts the instant you make an edit; the draft dot only refreshes on the next load or save, so it can still show yesterday's Valid draft for a few seconds after you have just made the scene locally invalid. If you need to know right now whether your last edit is schema-valid, read the scene dot, not the draft dot.

Save Draft itself does a third, stricter check before it writes anything — see Save Draft — so a Saved state on this bar always implies the document passed that check at the time it was saved, even if the underlying dots have since drifted.

Project and GitHub status#

Project: {name}, or No project before one loads.
For a GitHub-linked mod only, two more indicators — one for each direction of travel.

`↳ {repo}` — the checkpoint dot (pushes OUT)#

A titled span showing either the last WIP checkpoint status message (Checkpointed to {repo}@wip. or a failure with retry note) or, before the first checkpoint of the session, ↳ {repo}. This is the same background auto-checkpoint mechanism described in Publish to GitHub — it pushes your working tree to the repository's wip branch, separate from an explicit Publish.

`⇅ Synced` — the sync dot (pulls IN)#

Every time a GitHub-linked project opens, the repository's file tree is re-synced down into this device's local working copy: anything missing is downloaded, anything that changed upstream is updated, and anything you changed locally is left alone. This dot reports that pull.

⇅ Synced (green) — every file is either identical to the repository's copy or has already been reconciled with it.
⇅ N conflicts (amber) — N files changed both here and on GitHub. Nothing has been overwritten in either direction; the sync deliberately declines to guess.

Unlike the other indicators, this one is a button whether or not there is a problem, because it is also the only way to reach the reset described below. Clicking it opens the GitHub sync dialog.

Resolving a conflict

Each conflicted file gets a row. Expanding it lays the two versions side by side with the facts that separate them — byte size, when your copy was last edited, when the repository's copy was last committed, and each side's content hash — plus a preview of both where the bytes can be shown honestly (text files render as text, images as thumbnails, anything else reports its size and hash). Then choose per file:

Keep local — your copy stands.
Use GitHub — the repository's copy replaces yours. Your version is gone.

Whichever you choose is recorded. The same file is not raised again until one side changes again, so resolving a conflict actually clears it rather than deferring it to the next time you open the project. Keep all local / Use all from GitHub set every row at once; Apply writes only the rows you decided.

Sync now re-runs the pull without waiting for a reload — useful after pushing from elsewhere.

Reset local copy from GitHub

The escape hatch, in its own section at the bottom of the dialog and gated behind typing the repository name. It deletes this device's entire local working copy and re-downloads every file from the branch. Anything you edited locally and never published is lost.

What it does not touch: your manifest and your scene. Those live on the server as the project's draft, not in the local file tree, so Mod Details and the viewport survive a reset untouched — the two files that represent them in the project folder are rewritten from the draft as the last step.

The Problems panel#

A status dot tells you that something is wrong. The Problems panel tells you what.

Whenever there is anything to report, every indicator on this bar — and the topbar's save-state pill, which grows a red/amber count badge — becomes a button that toggles a panel anchored above the bar. All of them open the same panel, so you never have to work out which indicator owns a given failure. With nothing to report they stay inert text and are not focusable, and the panel closes itself the moment the last problem clears.

Each row carries a severity icon, the message, the source it came from, the path into the offending document where one is known (objects[3].scale), and the remedy. Errors sort above warnings; within a severity the order is stable, so the list does not reshuffle under your pointer as unrelated state changes.

Source	What it reports
Scene	Every issue from the live `editSceneSnapshotSchema` re-check, one row per Zod issue, each with its path. Listed first: an invalid scene is the failure that actually loses work, because Save Draft refuses to write a scene that will not parse back.
Draft	The server's compatibility issues for the whole draft, carrying their own severity and code.
GitHub	No repository linked (warning), GitHub not connected (error), and the last WIP checkpoint failed (error, with the underlying message). Sync conflicts are not here — they are not failures, and they have their own dialog.
Publishing	The Mod Details fields a listing needs before you can publish — the same list the Publish dialog shows.
Last operation	The most recent failed action, the same text the status message shows.

Rows you can fix from here#

Most rows tell you what to do. A few can do it for you, and carry a button.

Manifest references an asset that is not in the draft — Drop from manifest removes that one dangling entry from diceytable.mod.json. This is a blocking error, and it used to be a dead end: the remedy was to edit the manifest, and diceytable.mod.json is generated on save and is not in the project explorer, so there was no way to do it. Removing a declaration for a file that is demonstrably not there is safe — nothing can load bytes that do not exist, and re-importing the file re-declares it the normal way. If you meant to keep the asset, put the file back instead of clicking the button.

Save Draft also reconciles the manifest against the project tree, so in most cases saving clears this row on its own. The button is for when you want it gone now, or when saving is what the error is blocking.

The GitHub rows are the reason this panel exists. A checkpoint that cannot reach GitHub — an expired authorization, a permission change, a network failure — used to fail into a status string that the next message overwrote, leaving a mod that looked saved and was not. That is how a working tree drifts off the branch it publishes from. Now it is a standing error you can read at any time, and it names the repository it could not reach.

The status message#

The rightmost, and widest, element. It shows the most recent error (styled red) if one is set, or otherwise the most recent informational status message, or Ready. when neither is set. Nearly every action elsewhere in Edit Mode — saving, restoring a version, uploading an asset, compressing a texture — writes its outcome here, so this is the first place to look after clicking something that appears to do nothing.

What the status bar writes#

Nothing about your scene. Every element is a projection of state owned elsewhere — the topbar's save/undo actions, the Versions panel, the asset explorer's uploads, and the background WIP checkpoint. The only thing clicking a dot changes is whether the Problems panel is open.