"Who can see this project, and what can they do" — the access controls, in one place, shared by the surfaces that set them.

Both the creation form and the members page ask exactly this question, and they used to be able to answer it differently: creation had the whole panel, and after creation there was no way to reach visibility or the work floors at all. Rendering them from one component is what keeps the two surfaces honest — the same wording, the same choices, the same conditional rows.

The floors offered are only the ones Authz actually lets a project override. This is a "who can X" panel, not a permission-scheme editor: the rules that never move (settings, membership, archiving and deletion stay with owners) are stated in plain language rather than hidden, because they are what most people are checking for when they come looking for permissions at all.

Conditional rows

A project whose tasks are simple enough not to need comments shouldn't be asked who may comment: the question is noise, and answering it stores a floor for a capability that isn't there. visible_actions/3 filters against the same flags and extensions the rest of the module toggles, so rows appear and disappear as those change.