Admin Workspace
The Divine admin is a fullscreen workspace under the Divine menu in wp-admin, and it is the one place you do worktree work. It is the worktree viewer: select an app or worktree on the left, then inspect rendered theme output, browse a signed preview, edit files, review changes, resolve conflicts, look at history, and export the theme. Access requires the Divine management capability, which defaults to manage_options on single-site and manage_network on multisite.
How The App Is Mounted
Divine registers a top-level admin page and strips the normal wp-admin asset stack from it, so the workspace renders as a focused application rather than a page inside the usual admin chrome. The admin bar, side menu, screen-meta, footer, and notices are hidden, and the React app mounts fullscreen. The app talks to /wp-json/divine/v1/ using the standard WordPress REST nonce, so every workspace operation is the same administrator-gated REST call an agent would make.
The page is registered in exactly one place depending on the install. On single-site it hooks admin_menu and is gated by manage_options; on multisite it hooks network_admin_menu and is gated by manage_network. This is why the workspace appears in network admin on multisite and in normal admin on single-site, and never in both. Per-user preferences such as theme mode, sidebar layout, canvas viewport, and browser tabs are stored in user meta, so the workspace restores where you left off and never shares your state with another user.
The Sidebar
The left sidebar is how you choose what every other surface is showing. It lists apps and their worktrees. Selecting an app opens the app target, and selecting a worktree switches every surface to that worktree’s files and preview target.
What the sidebar lists differs by install, and this is deliberate. On single-site there is one app, the active theme, so the multi-app list is hidden and you work directly with that app and its worktrees. On multisite the sidebar is shown and lists the real network sites from get_sites(), each surfaced as an app with its active theme, so a network administrator can move between sites without leaving the workspace. The multisite sidebar also exposes a link to WordPress site creation (site-new.php); Divine links to native site creation rather than provisioning sites itself.
Navigating The Workspace
The mental model is two layers. The sidebar chooses the target, an app or one of its worktrees, and the main panel chooses what you are looking at for that target. The main panel has a toolbar with three primary views you switch between as tabs, and a set of related surfaces for review, history, and export that open alongside them.
| Surface | What it shows |
|---|---|
| Canvas | Pages and blocks rendered from the selected target’s theme files. |
| Browser | The selected target opened in a signed in-app browser session on the real site URL. |
| Code | The theme file tree and editor. App targets are read-only for edits; worktree targets are writable. |
| Review | The changed-file diff and conflict surface for the selected worktree, plus its latest dv check result. |
| History | Recent commits for the selected target and per-commit file diffs. |
| Export | The action that packages the selected app or worktree as a standalone theme zip. |
Canvas, Browser, and Code are the three views in the main toolbar tab strip. Review, History, and Export are reached from the worktree’s surrounding navigation and panels, because they are about a worktree’s git state and shipping rather than about live editing. The sections below describe each surface.
Canvas
The canvas shows pages and blocks from the selected target’s theme files. Page snapshots come from pages/, block snapshots come from blocks/, and both are resolved through the bundled Blockstudio runtime. A worktree-only page that does not exist in the WordPress database is still visible here, because the canvas renders from files rather than from wp_posts.
The canvas toolbar switches between a pages source and a blocks source, between desktop, tablet, and mobile viewports, and into a grab mode for inspecting the rendered output. It can mark changed blocks so you can see at a glance which parts of a page a worktree touched, and a live mode watches a lightweight file manifest so edits made on disk show up without reloading the whole workspace. The canvas is the surface to reach for when you are iterating quickly on the look of file-backed pages and blocks.
Browser
The browser surface opens the selected app or worktree in an embedded frame backed by a short-lived, signed preview session. The visible URL is the real clean site URL while Divine applies the selected theme copy in the background, so theme PHP and frontend assets run exactly as they would after deploy. This is the surface for exercising real WordPress behavior: real routing, real WP_Query, and admin-side changes that the file-only canvas cannot show.
The browser is a genuine in-app browser, not a static iframe. Within a tab you can navigate to a URL, go back and forward, reload, and return home, and browser tabs persist per user and per workspace scope so a session restores the tabs you had open and where each had navigated. Because the preview is signed and applies only inside the active session, ordinary same-origin navigation keeps the selected theme attached instead of dropping you back to the live theme.
Code
The code surface exposes the theme file tree and a file editor. The distinction between app and worktree targets matters here. App targets are read-only for general file edits, because the app theme is the live theme and should only change through deploy. Worktree targets can read, write, create, and delete files, with every path confined to the worktree directory.
Some paths are protected from normal editing even inside a worktree. .git, node_modules, and binary files are not editable through this surface, so the editor cannot corrupt git state or stomp build output. Saving a file writes it straight into the worktree directory, which is why the change immediately shows up in the canvas, the review diff, and the next dv check.
Review And Merge
The review panel lists every changed file in the selected worktree with its status, insertions, deletions, and conflict state, read from the worktree’s git state. Selecting a file opens a diff view with split or stacked layout, word or character diffing, optional backgrounds, wrapping, and line numbers. The panel also shows the selected worktree’s current Divine check result, including the visible findings when a check reports them, so the review and the validation live in one place.
Conflicted files can be resolved in the merge view by accepting the current change, the incoming change, both, or an inline edited result. Deploy refuses to run while conflicts remain, so this panel is the gate that keeps unresolved work out of the app theme. This is the reason review is its own surface rather than a mode you can skip: it is where a worktree becomes safe to deploy.
History
The history surface lists recent commits for the selected app or worktree and opens per-commit file diffs. Because each worktree copies the app repository, its history includes the app history it branched from, so you can trace a change back through the app’s commits as well as the worktree’s own. History is read-only; it is for understanding how the theme reached its current state, not for editing it.
Export
The export action packages the selected app or worktree as a standalone theme zip. The export embeds the Divine runtime as divine-runtime/ and adds a small marker in functions.php so the resulting theme runs on a client site with no Divine plugin installed. The package excludes the Harness admin code, git state, node modules, test fixtures, and development caches, and it records provenance and third-party license information alongside the runtime. Export is the surface that turns a built theme into something you can hand to a client; the details of the package and the bundled runtime are covered in Theme Export and Standalone Runtime.