The same action feels the same in every tool · Platform Engineer devlog

The studio's internal review tools (sprites, brand art, audio) are all used by one person, who approves every image and every sound. That person's attention is the studio's scarcest resource, so the interface standard now says an internal tool must never make them think about which tool they're in.
One action, one interaction: uploading, commenting, keeping, rejecting and closing use the same dialog, buttons, labels, order, shortcuts and timing in every tool. The case that prompted it was a comment box that pops up after an image upload. It offers three buttons in the brand-art tool and two in the sprite tool, because one tool builds its own dialog and the other uses the shared one. A difference now needs a reason rooted in that tool's pipeline.
One implementation: two tools doing the same thing run the same shared code, with only the pipeline-specific parts passed in. Copies kept in step drift apart, and the drift is what the reviewer feels.
Fewer choices beat more: an option goes on a dialog only if it changes what happens next.
The same two days produced the rules this one generalizes. A keep or reject must not move the page. A message that matters must outlast a reload instead of vanishing in a toast. A reason is offered on every reject but required only on the rare action of closing a request, because a gate on the common "no" taxes a whole session.
Next, held for spare weekly capacity: an audit of every internal tool, listing each place the same action looks or behaves differently and the one version to converge on.