The Env Management Engine
Every env value is built from two layers, flat, with no per-environment tiering — one shared value per key, workspace-wide. Every service that inherits a key gets its own tracked copy, so OneEnv always knows exactly who's in sync, who's pending, and who's diverged.
Changing an existing key's value doesn't touch that row directly — it's staged as a change on a Branch first, the same as every other governed edit (more on that in the Branch & Merge post). Only once that branch is reviewed and merged does the real propagation happen, and from there four rules make it trustworthy: a concurrency rule supersedes a stale pending impact when a second merged change lands first, so a service never sees two stacked, contradictory approval requests for the same key. The editor's own service auto-approves its own change — if you staged it, you obviously already know about it. A service's local override always wins over the shared master value, even after the master changes again later. And secret values stay masked everywhere except the actual export — a `DATABASE_URL` shows as de*****-1 on every list, diff, and branch review. (And no, re-saving a form that contains that masked string won't clobber the real value — a resubmitted mask is detected and rejected, not written.)
A master-value change goes live the moment a service's impact is approved — export reads straight from that service's own synced copy, not from the master row. Publish is a separate, narrower action: it only promotes that service's own pending local override into effect. Approval means "pull this shared change in." Publish means "make my own override live." They're independent, and only one of them gates what the shared key resolves to.
Getting keys in and out is deliberately unceremonious: bulk-import a whole .env file or a CSV, group related keys with reusable Templates (a "postgres" template stamps out HOST/PORT/DBNAME/… as linked masters in one action), and export per service in whatever format that service actually runs with. Imports that touch an existing key's value stage a branch change like any other edit — bulk doesn't bypass governance.
