Permission Model

Fork combines multiple access layers. Passing one does not remove the others.

1. Discord identity or a web session identifies the caller.
2. Live guild authorization protects administrative web routes.
3. Native Discord member permissions apply to sensitive commands.
4. Fork’s role matrix checks the underlying command policy key.
5. Bot permissions, target hierarchy and workflow approval constrain the actual operation.

Role-matrix evaluation

The role evaluator checks these in order:

1. Native Discord Administrator bypasses the Fork matrix.
2. Before valid setup, sensitive commands fail closed; non-sensitive commands remain allowed by this layer.
3. After setup, a currently loaded configured Fork administrator role bypasses the remaining matrix rules.
4. A missing/empty allow rule refuses sensitive commands but allows non-sensitive commands at this layer.
5. For a populated rule, a matching denied role refuses access before allowed roles are considered.
6. Otherwise at least one allowed role must match.

A custom Fork administrator role does not bypass the separate native member-permission guard. The SQLite compatibility reader does not authorize custom-admin grants from a stale cache; persisted backend behavior and current configuration matter.

Grouping does not change authority

The public slash surface uses mod, tools, chat and social groups. Their handlers retain original leaf policy keys. Registration metadata is not a complete business-rule description; FAQ writes and TTS administrator operations have additional handler checks.

Workflow-specific checks

Server Manager requires live administrator/owner authority and approval of an exact plan revision. Moderation applies target hierarchy where appropriate. AI-tool enablement never grants missing authority.

Do not troubleshoot by granting broad Administrator rights. Identify the failing layer using the command’s exact article and Missing Permissions.