Local adjustments took the develop column from four panels to six, and the
operation set is meant to keep growing — FR-DEV-3 still lists texture,
clarity, sharpening and noise reduction as v1. But the count is the lesser
problem.
The real one is that local adjustments introduced a *mode* without
introducing a way to see it. Selecting a mask silently re-points thirty
sliders at that layer, and the histogram those sliders are judged against
goes on reporting the whole frame. I built that, and it is the fault that
loses work rather than merely slowing someone down.
Decided: local becomes a mode, in the sense `crop-mode` already is. The app
has the pattern, the user knows it, and it removes the ambiguity by
construction instead of describing it in a caption. It also inherits the
Escape/back stack that already leaves the innermost state first.
Recommended: diverge on **width**, not on platform. A tablet in landscape
wants what a desktop wants and a narrow desktop window wants what a phone
wants, so `cfg(target_os)` would give one physical situation two answers.
`apply_layout_class` already classifies on width and already remembers a
per-class override; this is a second consumer of a decision the app makes
anyway. What must not diverge is the controls — both layouts consume the
same generated capability model, so a new operation still needs no UI edit.
Left open, because it is taste: whether the wide layout eventually gains
tool tabs. Recorded rather than left to be rediscovered is the *legitimate*
route to them — a descriptor declaring an operation's nature, the same shape
as `Affects`, with the frontend free to render it as a tab or ignore it.
Deferred because ten operations do not need eight tabs and the field is easy
to add later and awkward to remove.
Surveys what Lightroom, Capture One, darktable and the phone editors
actually do, including the thing none of them do: make a mask a panel that
rewires a different panel.
