For Divvent’s own team. It is generated from the operations document in our repository, which is the one to edit. If you use Divvent, the help centre is for you.
2. A change request in managed mode
Default for every account (changeMode: managed). The customer never sees the ChangeSet; they see what they asked for, where it got to, and what came of it.
| # | Who | Where | What |
|---|---|---|---|
| 1 | Customer | Portal → Changes | Describes the change in their own words, in the box at the top |
| 2 | — | — | The Haiku pre-gate classifies it. Off-topic gets the fixed refusal and never reaches the proposer |
| 3 | — | — | The proposer returns a ChangeSet, or a question, or "no change needed" |
| 4 | Operator | Console → Requests | The queue, hardest impact first then oldest — a destructive change behind eleven additive ones is one somebody approves at the end of the afternoon |
| 5 | Operator | Console → Requests → Read what it would do | The change's page: a plain summary, then a short list of what changes — who can see what and what data leaves are always on it, "unchanged" or "none" included — then Approve. The full preview is under Details: permissions delta first, then what happens to the data, then what else it touches |
| 6 | Operator | Console → Requests | Adjust or Decline. A decline needs a reason the customer will read |
| 7 | Operator | — | Approve → a revision is written, immutable, with the ChangeSet that produced it |
| 8 | — | — | Build by hash, deploy to production — or into a trial, if the customer asked to try it first |
| 9 | Customer | Portal → Changes | Sees the change move from In progress to Done, with the version it made (Live · 0.5.0); the audit entry is Settings → Activity |
Reading the preview is the job. The section order is the argument: a permission that just widened sits above a column rename because a permission change nobody noticed is the failure mode across this whole category of tool. A widened cell is marked, and the approve button says "I have read what this changes" rather than "Approve" when one is present.
"Approval interrupted" on a card means somebody pressed approve and the revision was never written — the Worker died between the two, most likely. No revision exists and nothing will ship. After five minutes anybody allowed to approve it may approve it again, or it can be declined; a customer's own interrupted approval appears here too, so somebody notices, but it stays theirs to approve.
Offline is a protection change. Declaring offline:, or adding a page or a role to it, lets the company's data be kept on devices, and it is an operator's to approve whatever the account has graduated to. What to read before approving it, and what Check has already refused, is docs/OFFLINE.md Part 2.
A deferred removal is not a removal. The contract half of an expand/contract runs next revision, so the column is still there and the rollback is still safe. The preview marks it next revision; do not read it as data already gone.
Approve is never on a card. The queue lists each change with Read what it would do; Approve is on the change's own page, under its summary and its list of what changes, and never drawn without both (DESIGN.md §17, decision 55). One whose decision is the customer's — waiting on the customer — offers nothing to press here. The screens are described one by one in docs/SCREENS.md.
2.1 Deploying an approved change that needs approval, through the queue
A plan with a destructive or not-rollback-safe step refuses to deploy without an approval (<impact> changes need approval). At a terminal that is --approve, recorded as DIVVENT_OPERATOR. **The runner never passes --approve.** It passes the revision's recorded approval instead:
divvent deploy … --approved-plan <hash> --approved-by <who><hash> is approvalHash over the approval-requiring steps of the plan the approver was shown, recorded on the change request when it was approved (platform_change_request.approved_plan). divvent deploy compares it with the same value computed over the artifact's own .divvent/plan.json — what the deployer will apply — and approves only if they are equal, recording <who> in _divvent_meta. A plan that gained a step needing approval after it was approved is refused before anything is built: **"this plan is not the one <who> approved"**, naming the steps. Approve the change again against what it now does. An approval from before approved_plan existed names no plan and is treated as none. The deployer still bookmarks before such a plan migrates.
---