kcode-k1-access-profiles 0.4.0

Synchronous K1 saved access profile facade and resolution
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87

# K1 access profiles

This library is the synchronous facade for private saved authorization profiles. It composes canonical mutation bytes, KTO/Peering submission and callbacks, rebuildable SQLite projection state, owner-filtered reads, and profile resolution. The logical subsystem remains `k1-profile-subsystem`.

## Public API

The crate reexports the established profile identities and values, including `AuthorizationProfile`, `Authorizations`, `ProfileId`, `ProfileName`, `ProfileColor`, `ProfileRevision`, `ProfileSelection`, `ResolvedProfile`, `SavedProfile`, subject and principal types, and K1 identifiers.

```rust
impl K1AccessProfiles {
    pub fn open(
        root: &Path,
        ordering: Arc<K1TxnOrdering>,
        peering: Arc<K1Peering>,
    ) -> Result<Self, String>;

    pub fn create(
        &self,
        owner: UserId,
        profile: AuthorizationProfile,
    ) -> Result<ProfileRevision, String>;

    pub fn create_named(
        &self,
        owner: UserId,
        name: ProfileName,
        profile: AuthorizationProfile,
    ) -> Result<ProfileRevision, String>;

    pub fn create_named_colored(
        &self,
        owner: UserId,
        name: ProfileName,
        color: Option<ProfileColor>,
        profile: AuthorizationProfile,
    ) -> Result<ProfileRevision, String>;

    pub fn rename(
        &self,
        actor: UserId,
        profile_id: ProfileId,
        name: ProfileName,
    ) -> Result<ProfileRevision, String>;

    pub fn set_color(
        &self,
        actor: UserId,
        profile_id: ProfileId,
        color: Option<ProfileColor>,
    ) -> Result<ProfileRevision, String>;

    pub fn replace(
        &self,
        actor: UserId,
        profile_id: ProfileId,
        profile: AuthorizationProfile,
    ) -> Result<ProfileRevision, String>;

    pub fn delete(
        &self,
        actor: UserId,
        profile_id: ProfileId,
    ) -> Result<ProfileRevision, String>;

    pub fn get_for_user(
        &self,
        user: UserId,
        profile_id: ProfileId,
    ) -> Result<Option<SavedProfile>, String>;

    pub fn list_for_user(&self, user: UserId) -> Result<Vec<SavedProfile>, String>;

    pub fn resolve(
        &self,
        principal: RequestPrincipal,
        selection: ProfileSelection,
    ) -> Result<ResolvedProfile, String>;
}
```

`create_named_colored` stores a supported optional profile color with the initial profile. `set_color` owner-authorizedly replaces or clears only that color. The original methods and mutation field shapes are unchanged; old create operations remain colorless. Equal profile, name, or color changes preserve the existing revision.

Saved profiles remain private to their immutable owner. Unknown and differently owned profile IDs are indistinguishable as unavailable. A saved profile resolves to concrete normalized `Authorizations` plus its exact saved revision; built-in and inline resolution retain their established behavior. Profile colors are presentation metadata and do not change authorization resolution.

Each mutation uses a fresh random operation ID, canonical profile-wire 0.3.0 bytes, synchronous Peering submission, and a matching KTO callback. The callback action, transaction ID, and apply outcome must reconcile exactly. A mismatch, parse failure, projection failure, or reorganization faults the facade closed. Reorganization clears derived projection state for replay. Operations are not retried.

Mutations and owner-filtered reads are synchronous. Encoding, parsing, and profile resolution are linear in complete payload/profile size; lookup and mutation persistence follow the profile-store 0.4.0 and SQLite 0.3.0 contracts. The facade adds no HTTP, browser state, active-profile selection, migration, polling, timeout, background work, credentials, or object-creation policy.