# kcode-k1-daemon-lib
Version 0.12.5 is the library-only composition root for the private K1 loopback daemon and its authority-owned Web serving.
## 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, the authenticated HTTP adapters, and the prefixless authority-owned KTO Web adapter.
The concrete `kcode-k1-daemon-web-startup` leaf owns optional public-origin selection and opens the public Web router from the daemon's existing shared transaction-ordering and peering instances. It uses fixed projection and control roots at `<k1_root>/state/web/projection` and `<k1_root>/state/web/control`; these roots are disposable derived state, while KTO remains canonical package state.
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. Web projection and control roots are disposable derived state rather than additional package authority.
Startup selects the public origin once through `kcode-k1-daemon-web-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 existing authenticated API and the public Web router, binds the private loopback boundary, and writes readiness only after successful preparation. Startup taking more than 100 ms emits the existing readiness warning.
The listener remains fixed at loopback port 4450. When `K1_PUBLIC_ORIGIN` is absent, the canonical public origin is `http://localhost:4450`; when present, its UTF-8 value must pass the boundary's canonical HTTP/HTTPS-origin validation. The selected origin is used consistently for API config, `/config.json`, exact Host acceptance, and readiness. Existing authenticated `/api` behavior, unknown-API fallback, replay protection, CORS and security behavior, and graceful signal handling are retained. Invite links remain rooted at `http://localhost:4321/lib/kcode-k1-ui/*/account.html`, preserving the current browser cross-origin arrangement.
UI selection, proxy and TLS ownership, deployment, and migration remain outside this package. It adds no public bind, proxy-header trust, static legacy Web trees, `/module` or `/lib` aliases, friendly-root rewrites, publication/editing/Group/Access/Ktool behavior, CORS change, or rate limiting.
## 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.