# Resolve Admin Rights From Configuration, Not Role Names

Replaces hard-coded admin role strings with configured names and permissions.

Follow these project instructions.
# Resolve Admin Rights From Configuration, Not Role Names

Replaces hard-coded admin role strings with configured names and permissions.

Version: `1.0.0`

Do not compare a role name to a literal. The words an application uses for its administrators are a deployment decision - one tenant's Owner is another's Administrator, and a customer may want a name in their own language - so put them in configuration and read them from there.

Better still, check a permission rather than a role. Roles are containers that change shape; a permission is the thing the operation actually needs, and granting it to a new role later requires no code change.

The literal comparison fails quietly in the other direction as well. A machine caller whose credential happens to carry a matching role string passes a check that was written with a human administrator in mind. Administrative management surfaces should require a human administrator, not merely a matching string.

When a check must stay at the edge for a fast rejection, keep the real one in the service as well. An edge check is an optimisation; the service check is the rule.

#### Constraints
- Do not let an API credential reach an administrative management surface on a role string alone.
- Never compare a role name to a hard-coded literal to decide access.
- Never leave an edge check as the only check.

#### Verification
- A machine credential is refused on administrative management, proven by a test
- Administrative role names come from configuration, or the check uses a permission
- Every edge check has a matching service check behind it
