access

Guide: For coding agents

access

Who may manage THIS project in the admin dashboard (project-scoped), mapped to management levels by ROLE MEMBERSHIP. Each level is a CEL predicate over the closed context @user exposes — @user.id and @user.roles, nothing else. In practice a level tests ROLE MEMBERSHIP: @user.id is admitted, but Alvo’s CEL grammar has no uuid literal and a level sees no row, so there is no uuid-typed operand to compare it against and ‘@user.id == …’ is refused as a type error rather than by this block. It stays admitted deliberately, so a level written against a future typed claim compiles unchanged. Attribute-based rules (an email domain, a team) are NOT expressible in this or any other block; typed claims are tracked by #37, and widening @user is additive, so a role-based level keeps compiling once they land. Every declared level is COMPILED AT APPLY, in the same pass as every rule and against the same declared roles: a level referring to a role that auth.roles does not declare is refused there, with the same ‘did you mean’ suggestion a rule’s typo gets. The three levels are independent predicates resolved HIGHEST MATCH WINS (admin > developer > viewer), evaluated in memory and never rendered to SQL; a caller matching none is refused every management operation that carries the gate, and the deployment’s bootstrap administrator is an admin whatever this block says — so a descriptor with no access block admits nobody else.

• Type: object
• Required: no

Keys

access.admin

CEL over @user.roles / @user.id: who may fully administer this project (schema, rules, data, settings).

• Type: string
• Required: no

access.developer

CEL over @user.roles / @user.id: who may edit this project’s schema, rules, and automation, but not its settings.

• Type: string
• Required: no

access.viewer

CEL over @user.roles / @user.id: who may view this project’s data and configuration read-only.

• Type: string
• Required: no