sf-permissionslisted

<!-- Adapted from Jaganpro/sf-skills@ff1ab74 (MIT). Layers Brite conventions sourced from brite-salesforce/CLAUDE.md §Permissions & Security (lines 164–173) + brite-salesforce/docs/decisions/004-permission-set-strategy.md. --> # sf-permissions: Permission Analysis (Brite edition) Permission-set analysis and access auditing for the **brite-salesforce** org: hierarchy views, "who has access to X?" investigations, user-permission analysis, and permission-metadata review. --- ## Brite Context Brite's permission model: - **Profiles:** only `Minimum Access` is tracked in source; all grants flow through Permission Sets. - **Permset naming:** permsets named for capabilities (`Base_CRM_Access`, `Work_Order_Read`); permset groups named for teams — `{Team}_Group` for ICs, `{Team}_Management_Group` for leads. `{Team}` is a placeholder — e.g., `Sales_Group` / `Sales_Management_Group`, `Marketing_Group` / `Marketing_Management_Group`. - **See also:** `brite-salesforce/docs/artifacts/user-role-matrix.md` §3 (canonical role map) and `brite-salesforce/docs/decisions/004-permission-set-strategy.md` (strategy ADR, @imported by `brite-salesforce/CLAUDE.md`). --- ## Brite Permission Conventions These rules are non-negotiable on brite-salesforce and must surface during permset edits, FLS changes, and access investigations. ### 7-permset FLS sync When adding a `CustomField`, update FLS in **all seven** of these permission sets: 1. `Base_CRM_Access` 2. `Finance_Read` 3. `Deal_Financial_R