kcode-k1-daemon-lib 0.12.4

Library-only private K1 loopback daemon composition root
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

# kcode-k1-daemon-lib

Version 0.12.4 is the library-only composition root for the private K1 loopback daemon.

## Public API

```text
pub fn run(k1_root: PathBuf) -> ExitCode;
```

`run` builds the multithreaded Tokio runtime, prompts once for the Vault unlock, starts the complete daemon beneath `<k1_root>/state`, writes readiness, serves the loopback HTTP boundary, and returns success only after graceful shutdown. Startup or listener failure returns exit code 1 through the fixed safe daemon error surface.

## Composition

The daemon composes one process-lifetime instance of transaction ordering, peering, Vault, Persons, Invites, Accounts, Users, Groups, saved Access Profiles, Authority Filters, Access, Objects, Audio, Chat, Launch Nodes, replay protection, providers, and the authenticated HTTP adapters.

WebSearch is constructed from a clone of the existing Chat Codex Adapter, so Audio, Chat, and WebSearch share one persistent app-server while every WebSearch uses its own fresh one-shot thread.

The current launch and Kmap selections are:

- `kcode-k1-access-launch-nodes` 0.2.2
- `kcode-k1-launch-nodes` 0.4.0
- `kcode-k1-http-launch-nodes` 0.3.0
- `kcode-k1-http-kmap` 0.1.0

`LaunchNodes::open` receives the shared transaction-ordering and peering handles and retains its append-only startup projection at `<k1_root>/state/launch-nodes`. Only ordered KTO callbacks may append to that projection. The file is a fast rebuildable view rather than an independent authority.

Chat Service opens the sole raw Kmap and Access-Kmap facade. Composition reuses an `Arc` clone of that exact Access-Kmap for both the existing Launch Nodes HTTP adapter and the authenticated Kmap creation adapter; it does not open a second Kmap. Both adapters also reuse the shared saved Profiles. Their dedicated HTTP Access Contexts reuse the shared Authority Filters and `chat_access_model()`.

The authenticated router additively mounts signed `POST /api/kmap/profiles/{profile_id}`. The adapter resolves the authenticated user’s saved Profile server-side, applies its concrete policy, validates every requested connection through the request’s Access Context, preserves connection order, creates Navigation connections, and returns the new Access ID. Unknown or inaccessible Profiles and connection targets are concealed.

Kmap creation is intentionally non-idempotent. Clients must not automatically retry an ambiguous failure because concurrent or repeated successful calls may create distinct nodes. Access-Kmap creates the raw Kmap node before its Access record, so an unexpected Access failure may leave an inaccessible raw-node orphan; the daemon invents no rollback.

The existing authenticated Launch Nodes routes continue to use the same shared Access-Kmap and saved Profiles. All existing Accounts, People, Persons, Chat, Audio, Audio artifact, and profile-presentation routes retain their current composition and behavior.

## State and startup

All durable state remains beneath `<k1_root>/state`, including transaction ordering, peering, Vault, Persons, Invites, Groups, Access Profiles, Authority Filters, Access, Launch Nodes, Objects, Audio state, replay state, invite links, and Chat v2.

Startup opens each subsystem once for process lifetime, unlocks the Vault, resolves provider and FFmpeg configuration, reconciles at least 100 unused wildcard Account invite links, opens replay protection, composes the authenticated API, binds the private loopback boundary, and writes readiness only after successful preparation. Startup taking more than 100 ms emits the existing readiness warning.

The HTTP boundary retains public origin `http://localhost:4450`, authenticated `/api` behavior, replay protection, existing CORS and security behavior, and graceful signal handling. Invite links remain rooted at `http://localhost:4321/lib/kcode-k1-ui/*/account.html`.

## Lifecycle boundary

This package release proves package composition and managed checks only. It does not prove local adoption, a local dependency update, daemon rebuild or restart, signed provider traffic, browser integration, deployment, or a visible live outcome.

Startup and request paths inherit delegated local and provider work and have no finite completion guarantee beyond their owners’ documented contracts.