Skip to content

Latest commit

 

History

History

Folders and files

NameName
Last commit message
Last commit date

parent directory

..
 
 
 
 
 
 
 
 
 
 
 
 
 
 

README.md

d2b documentation

Organised as a Diataxis structure with four quadrants — tutorials, how-to, reference, explanation. Today: reference, how-to, and explanation docs ship in this tree, and tutorials/examples live one level up under ../examples/ and ../templates/default/.

Tutorials / Examples

The examples are intentionally small enough to read end-to-end; each example's README explains the pattern.

Reference

The contracts. Stable interfaces a consumer can depend on.

How-to

Task-oriented recipes. Prescriptive, copy-and-adapt.

Explanation

Understanding-oriented prose. The "why" behind the design choices.

  • explanation/design.md — threat model, trust boundaries, component architecture, defense-in- depth controls, known gaps, and a Why not X rationale FAQ. Read this before opening a security-sensitive issue or proposing a structural refactor.
  • explanation/storage-lifecycle.md — why d2b treats host paths, restart adoption, locks, cleanup, and degraded-state reporting as explicit control-plane contracts.
  • explanation/realm-controller-boundaries.md — why host-local realm controller metadata keeps direct socket authorization, local-root resolution, state, and audit boundaries separate.
  • explanation/realm-tree-routing.md — conceptual boundaries for route discovery, namespace delegation, shortcuts, and why the contract does not imply live relay, VPN, overlay, SSH, or raw tunnel routing.
  • explanation/persistent-shells.md — persistence boundary, local IPC model, same-UID AF_UNIX trust boundary, and non-goals for persistent named guest shells.
  • explanation/clipboard-architecture.md — trusted clipboard authority, picker split, Niri integration, and bridge runtime path contract.
  • adr/README.md — architecture decision records for load-bearing design choices that complement the explanation narrative.

Operator runbooks and troubleshooting procedures live under How-to. Reference pages should describe contracts, schemas, and invariants, then link to the relevant how-to for day-2 procedures.