rbacPermissionMatrix advertises only 2 PROJECT entity types (MODEL_CARD/APP_CONFIG/etc. missing) — drift from real action inventory

Symptom: In the WebUI RBAC management page, "세부 권한 추가" (Add detail permission) for a PROJECT scope shows only 2 options in the 권한 타입 (Permission Type / entityType) dropdown: MODEL_DEPLOYMENT (배포) and ROLE_ASSIGNMENT (역할 할당). The 세부 권한 LIST for the same role already shows ~11 PROJECT entity types (MODEL_CARD, VFOLDER, SESSION, IMAGE, ARTIFACT, APP_CONFIG, NOTIFICATION_CHANNEL, NOTIFICATION_RULE, ARTIFACT_REGISTRY, ...), so those combinations are clearly grantable yet cannot be added through the modal.

Not a frontend bug: The dropdown faithfully renders the manager GraphQL rbacPermissionMatrix (only entities whose actions array is non-empty). Confirmed by running the matrix builder directly — scope=project returns exactly model_deployment + role:assignment.

Root cause: The matrix is built SOLELY from the hand-maintained RBAC_ACTION_REGISTRY (src/ai/backend/manager/actions/action/__init__.py:80), a tuple of BaseRBACAction stub classes covering only 6 entity types (model_deployment, project, user, session, vfolder, role:assignment). This is a separate, parallel inventory from the system's real action set aggregated in services/processors.py:502 supported_actions() (~55 packages), which already carries entity_type + operation_type for MODEL_CARD, NOTIFICATION_CHANNEL, IMAGE, ARTIFACT, ARTIFACT_REGISTRY, APP_CONFIG_\*, and dozens more. The only thing the real actions lack is a scope: ActionSpec (actions/types.py:41) has no scope field and BaseAction has no permission_scope(). That single missing dimension is the entire reason the parallel BaseRBACAction hierarchy exists — and being manually synced, it drifted to 6 entities while data migrations (e.g. f1a2b3c4d5e6_add_model_card_permissions_to_rbac.py, a5e87ed3b6d4_migrate_app_config_data_to_rbac.py, 013a6676866c_migrate_notification_data_to_rbac.py) seeded the broader entity set into the permissions table (which is what the LIST tab reads via adminPermissions). Three registries must agree but only manual glue connects them.

Fix option A (narrow, closes the symptom): add PROJECT-scoped BaseRBACAction stub declarations for the missing entity types and register them in RBAC_ACTION_REGISTRY. Keeps the drift-prone design.

Fix option B (preferred): attach permission_scope to the real actions — an optional permission_scope() on BaseAction or a scope field on ActionSpec — and derive the matrix from supported_actions(), then retire the BaseRBACAction stub registry. Every existing and future service action then appears automatically. ActionOperationType.to_permission_operation() already maps CRUD -> RBAC OperationType, so only scope is missing. Confirm the target architecture with the RBAC epic owner before choosing A vs B; may relate to the Virtual Scope RBAC generalization (BA-6567) and the BaseAction removal refactor (BA-6285).

Also affected: rbacEntityOperationCombinations and rbacScopeEntityCombinations are built from the same RBAC_ACTION_REGISTRY / VALID_SCOPE_ENTITY_COMBINATIONS and inherit the same gap. No WebUI change needed.

Secondary inconsistency: VALID_SCOPE_ENTITY_COMBINATIONS (common/data/permission/scope_entity_combinations.py) lists SESSION and VFOLDER under PROJECT, but the action registry scopes them under USER. Reconcile the two source-of-truth maps.

Full analysis (hejo workspace): .cmux-tasks/rbac-permission-matrix/FINDINGS.md

Key files: services/permission_contoller/service.py:412 (builder, _GRANT_OPERATIONS:161); api/adapters/rbac/adapter.py:603; api/gql/rbac/resolver/permission.py:154; actions/action/__init__.py:80 (registry); actions/action/rbac_\*.py (stubs); services/processors.py:502 (real inventory); actions/types.py:41 (ActionSpec).

JIRA Issue: BA-6722

Start with services/permission_contoller/service.py:412 and actions/action/__init__.py:80 to trace how the matrix and related combinations are built. Compare the stub registry with services/processors.py:502 and ActionSpec in actions/types.py:41, then confirm the intended architecture with the RBAC epic owner. Done means the matrix and related combinations cover the supported entity types and reconcile scope mappings without a WebUI change.

Written by the indexing model from the issue text.