Module changes 

A change to an operator — by another operator, or, for the contact address, by themselves: each change with everything it owes — the write, the audit rows, the message — in one function both front ends call.

The CLI and the web admin each used to spell these four as “apply → audit → revoked-sessions row → notify”, and the copies had drifted twice over: the CLI wrote a session_revoked row counting zero sessions after a role or password change, and an operator_contact_updated row for an address set to what it already was, where the panel wrote neither. What genuinely differs between the surfaces — who the actor is, how the client is resolved, which dispatcher carries the message — is an OperatorTrail; the sequence is here, once.

Log lines stay with each front end: they name the surface and the signed-in operator, which only the front end knows.

Traits

OperatorTrail

Where one surface’s record of an operator change goes.

Functions

change_contact

Sets or clears username’s notification address.

change_role

Sets username’s tier, ending their sessions so the new one applies at once — recorded as for change_status. None when there is no such operator.

change_status

Enables or disables username. Disabling ends every session they held, which is a second thing that happened and so a second row — only when there was a session to end. None when there is no such operator.

reset_totp

Removes user’s second factor and every recovery code on another operator’s say-so, ending their sessions: there is no session of theirs to keep, the change being made from somewhere they are not signed in. They are told, since they did not do it.