Every Screen in OneEnv: A Guided Tour
Two distinct "sites" live in one app: a public marketing site you're on right now, and the workspace application behind login. Here's what's inside the part you'll actually work in every day.
The operational hub: Service Detail
The single richest screen in the app. Per service, it surfaces every inherited env key (grouped by template vs. standalone, with inline override editing), every inherited DB table and column, owned and inherited API routes, inherited validation rules, and a live export preview — all in one place. Editing an existing shared value here doesn't touch it directly; it stages a change against whichever Branch is active in the topbar, the same as editing it from the workspace-level catalog. A "Publish" button still exists, but it's narrower — it only promotes your own pending local override into effect.
The API Studio
Nested inside Service Detail: an IDE-style, three-pane editor for the service's own API routes. The request tree is the real governed catalog — creating and renaming are instant, but editing a url/method or deleting a route stages onto your active branch like everywhere else, and request fields, DB mapping, response mapping, and validation assignment all read the real governed catalogs. Everything you type — params, headers, bodies, tests, examples, a mock response — autosaves as your own per-user draft, deliberately outside governance: nobody reviews a dev's scratchpad. (Honesty note: "Send" simulates the call against a canned response — there's no real network runner yet, and the widgets for environments/variables/history are still mock.)
Everywhere else, at a glance
The Notifications page is worth calling out specifically — it's the shared inbox for every governed change, and it groups two ways at once: everything one merge fanned out collapses under its branch, and repeat changes to the same entity across different merges collapse into one digest card, so a key that changed three times this week is one conversation, not three. Each card carries its computed risk level and a required-action hint. A branch review card is different from the rest: it isn't scoped to a single service and has no per-service approve/reject rows — it's the single Owner/Admin decision on a whole branch, rendered with the branch's full diff inline. A Member only ever sees the slice touching services they actually have access to. Design is consistent throughout: emerald means in-sync or approved, amber means pending or needs your attention — that color language never changes, screen to screen.