1Ordinary client — internal_role: null

Nothing is added. No staff bar, no Move Forward, no Change Status, no Assign, and no assignee name anywhere — the payload does not carry assigned_to_name at all for this viewer, so the name is absent from the HTTP response, not merely hidden in the DOM (spec decision 7). Identical to the BEFORE capture.

2Developer, assigned to this ticket

One control, not two. The server sends allowed_statuses already narrowed to what this viewer may set — for a developer that is exactly [next_status], so length < 2 ⇒ Change Status is not rendered and Move Forward is the only door. A one-option dropdown would be a menu offering a choice that does not exist, three clicks for what the button does in one. The label names the target stage, from next_status_id + next_status_name.

3Developer, not assigned — disabled + tooltip

The button is present and keyboard-focusable: aria-disabled="true" with the click handler short-circuited, never a bare disabled (which drops it out of the tab order, so the explanation becomes unreachable exactly for the people who need it most). The tooltip is the aria-describedby target, shown on hover and on :focus-visible. Below: the same button focused by keyboard, with the second reason shape — nothing left to advance to.

4CTO / platform admin — full set, backward included, plus Assign

Three controls on one row, in decreasing frequency of use: Move Forward (primary — the one verb used twenty times a day) → Change Status (the correction path, forward and backward) → Assign. The Change Status menu lists allowed_statuses verbatim: the frontend holds no status order, so it cannot decide what “forward” means and does not try. Backlog is absent because the server never puts it there.

5Backlog ticket, viewed by a CTO — the credit gate holds

No status control renders for anyone, including CTO and admin. Not a disabled Move Forward with an explanation — absent. Submit stays the only way out of the backlog, and the pane must not suggest a second door exists. The Assign control survives: assigning changes no status and costs no credit, so a CTO can line the work up before the client pays.

6Server refusals — inline, never blanking the pane

Every error is a role="alert" paragraph inside the staff bar, under the control that produced it. The ticket, its description and its criteria stay on screen; the status pill never showed an unconfirmed stage, because the controls are pessimistic by design — there is no optimistic state to roll back. Each failure still invalidates the board and detail queries, so a pane made stale by someone else converges on the next paint.