A change waits for the people who have to see it first.
An approval flow drawn on a canvas — who approves, how many of them, in what order, under what conditions — and enforced where it counts: a submitted change is held from the team until it is approved, and the item is frozen for everyone, the author included. Locks for the hours someone needs a component to themselves. A merge that only argues about the fields both sides touched.
The nodes
Scoped, frozen, enforced.
A flow on a project, a folder or a request; the nearest one wins.
The submission
Carries the exact proposed content and the revision it is based on. The approver sees a field-level diff. The item is frozen for everyone while it is open — the originator too — and the lock is visible in the tree and the editor.
No way around it
A manual save, a manual publish and a conflict resolution cannot bypass approval. An approved change publishes through the approval path alone. Resubmission restarts the full review. The originator can withdraw; an administrator can void.
When the store moved on
An approved change is merged against its base. An unclean merge goes back to the originator as stale, never published half-right. A guest division's changes to a shared workspace wait for the home administrators.
The rest of working together without stepping on each other.
Each one signed and sealed like everything else in the store.
Edit locks
Take a component for one member's edits, from one hour to a week, with a reason. Everyone else is read-only, the administrator included — though the administrator can lift it. A folder lock covers everything under it. Tell the administrator, the project, or picked people, and tell them again on release. A Locks page lists all of them.
Three-way merge
Against the common base, field by field. Query parameters, headers and path variables merged by key; checks, examples and saved messages by stable id. A one-sided change wins on its own; the same change from both sides resolves itself; only fields both sides changed become conflicts, resolved one by one, or keep local, or take remote. Serialization-only differences are not conflicts.
History
Every kept revision with who published it, from where and when; two to a hundred per item, twenty by default. Side-by-side or inline diff against your copy. Open an old revision without restoring it, or restore it — and the replaced one lands in history too. The previous publisher is told when a revision is merged or replaced.