namespace DodoSSH.Domain.Authorization;

/// <summary>
/// PermissionFlags a subject (user or team) may hold over a vault or an individual resource.
/// </summary>
/// <remarks>
/// <para>
/// Evaluation is a plain union across the subject's direct grants and the grants held by
/// teams they belong to. There are deliberately no Deny rules: union-only evaluation is
/// monotonic and straightforward to test, and Deny can be added later additively if a
/// real need appears. Express restriction by granting narrowly instead.
/// </para>
/// <para>
/// <see cref="Connect"/> is a user-interface hint, <b>not</b> a security boundary. SSH
/// terminates on the client, so opening a session requires the credential's plaintext on
/// that machine; "may connect but may not view the key" is therefore unenforceable in
/// this architecture. Treat it as an anti-shoulder-surfing convenience and never document
/// it as access control. See docs/adr/0001-e2ee-trust-model.md.
/// </para>
/// </remarks>
[Flags]
public enum PermissionFlags
{
    /// <summary>No access.</summary>
    None = 0,

    /// <summary>May fetch and decrypt the resource. Implies the ability to use it.</summary>
    Read = 1 << 0,

    /// <summary>May create, modify and soft-delete resources in the vault.</summary>
    Write = 1 << 1,

    /// <summary>Intent hint that the subject uses this host for sessions. Not a boundary.</summary>
    Connect = 1 << 2,

    /// <summary>May grant access to other subjects, which requires re-wrapping the vault key.</summary>
    Share = 1 << 3,

    /// <summary>May administer the vault itself: rename, rekey, manage ACLs.</summary>
    Admin = 1 << 4,
}
