kcode-k1-access-projection 0.2.0

Semantic in-memory projection for K1 access state
Documentation
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# K1 access projection

`kcode-k1-access-projection` owns the synchronous in-memory authorization projection for the logical KTO subsystem `k1-access-subsystem`. It persists derived state through `kcode-k1-access-store` and performs no KTO registration, replay, Peering, authentication, Groups membership lookup, network request, retry, timeout, worker, or background work.

## Public API

`ApplyOutcome` has `Applied(AccessRevision)`, `Unchanged(AccessRevision)`, and `Rejected(String)` variants. The crate reexports the access action, witness, identity, authorization, request, result, transaction, subsystem, and ordering types used by its API.

`Projection::open(root, ordering)` opens the store, validates its complete snapshot against canonical KTO transaction bytes, and returns the projection with its optional cursor. `apply(callback_txid, action)` serializes one callback and returns an `ApplyOutcome`. `owner_witness(access_id, user, user_groups)` returns direct-user evidence first, otherwise the lowest owner group present in the supplied memberships. `check(principal, access_id, expected_subsystem, user_groups, model_groups, groups_revision)` returns one owned authorization result. `clear()` durably empties the projection and leaves that handle unavailable.

Create derives both access ID and revision from its callback. Duplicate IDs or targets are rejected. Replace requires an existing object and a witness that names either the actor's direct ownership or an exact owner group. Equal normalized authorizations are unchanged and preserve the prior revision; changed authorizations preserve the target and advance the revision. Every successful store commit advances the callback cursor, including rejected and unchanged actions. Store failure or an internal contradiction makes the handle unavailable.

Checks hide unknown objects and subsystem mismatches. User ownership is direct or through a supplied user group. User viewing is ownership or a direct or group viewer grant. Model viewing is a direct model grant or membership in a viewer or owner group; models never manage. `can_manage` is user ownership independent of model visibility, while `can_view` requires both user and model visibility. Targets are returned only for viewable objects. Access and Groups revisions are returned when viewing or management is allowed.

Open treats KTO query errors as fatal without clearing. Missing canonical transactions, wrong subsystems, malformed transaction or payload bytes, mismatched actions, and inconsistent derived rows cause the store to be cleared and opened empty. A nonempty snapshot requires a cursor. Open performs fallible index reservations and issues one data-free warning if the complete operation exceeds 100 milliseconds.

The projection uses one apply mutex and one coherent read-write-locked cursor and pair of hash indexes. It holds no projection lock across Store commits or KTO queries. Queries perform no I/O after open. There are no arbitrary object or membership caps; work is linear in the snapshot on open, average constant time per addressed apply or lookup, and linear in supplied membership slices for authorization evaluation.