Architecture Docs

Philosophy

These docs are written to be comprehensive and navigable at the same time. We prefer compact, high-signal sections over long mixed-purpose pages, and we separate routing pages from content pages so readers can choose the exact level they need.

Two Audiences, One Contract

User Docs describe workflows and practical operation. Architecture Docs define implementation boundaries, invariants, control surfaces, and extension contracts. Both tracks must remain consistent.

Source-of-Truth Rule

Architecture docs define the implementation authority for the documented runtime. If behavior diverges from this section, treat it as a defect and update either code or docs deliberately.

Decision Matrix

Question	Start here	Related deep dive
What is the daemon responsible for?	Runtime Overview	Implementation Blueprint
How does a host talk to the daemon safely?	Control API and Lifecycle	Developer Integration Guide
Where does Windows-specific behavior live?	Windows Runtime	Implementation Blueprint
Where does Ubuntu/Linux-specific behavior live?	Linux Runtime	Runtime Overview
How is lifecycle behavior validated?	Verification Strategy	Windows Setup
Where should I change code for a given behavior?	Implementation Blueprint	Runtime Overview

Scope

This section is concept-first and implementation-bound. It documents ownership, data movement, invariants, extension points, and verification policy.

Implementation Anchors

Daemon entry point: src/main.rs
CLI entry point: src/cli_main.rs
Core logic: src/core/*
Platform integrations: src/platform/*

---

Runtime Overview · Control API and Lifecycle · Windows Runtime · Verification Strategy · Blueprint