app-permissionslisted

# App Permissions — RBAC С НУЛЯ ## Зачем Business/SaaS apps часто начинают как single-user. Потом приходит "ну а если несколько юзеров в команде?". И начинается: - Owner vs members vs viewer - Кто может удалять? Только owner или admins? - Кто может приглашать новых? - Что видит viewer но не редактирует? - Audit log "кто что когда" Если RBAC не заложен с самого начала — refactor 100+ pages чтобы добавить `if (currentUser.canEdit(item)) { ... }`. **Дни work**. Заложить с начала: один pattern, одна функция, везде применяется. ## Когда вызывать - **Business / B2B apps** — обязательно - **SaaS apps** — обязательно (org/team layer) - **Multi-user productivity apps** — если есть concept "share with team" - **Tools / single-user productivity** — НЕ обязательно (skip) ## Pipeline ### Шаг 1 — Read context ``` wiki/_map.md # category, multi-user или нет wiki/architecture/data-model.md # entities to protect ``` ### Шаг 2 — Define roles Standard 4-role hierarchy: ``` Owner — full control, can delete account, manage billing, transfer ownership ↓ Admin — manage members, settings; cannot delete account ↓ Member — create/edit/delete own items, view shared items ↓ Viewer — read-only access ``` Plus optional roles per use case: - **Guest** — limited time, restricted scope (single project) - **Service account** — for API/integrations (no UI access) ### Шаг 3 — Define resources + actions Matrix: who can do what? ``` Resource | Owner | Adm