4  How Kailash is built

Kailash is built declaratively from two Nix repositories with a clean contract (the spec’s architecture chapter):

• the OS repository (kailash-os) — the distribution flake: host modules, image matrix, the CLI, the menu. It never contains tool derivations.
• the packages repository (kailash-packages) — bespoke derivations, the overlay, and the tool manifest: the single hand-maintained registry (the manifest section). Every other view — category modules, desktop menu, CLI listing, generated docs, this guide’s reference part — is generated from it.

4.1 Pins and locks

No package floats:

• Bespoke tools are pinned upstream (nvfetcher) and committed with content hashes. A pin changes only together with the manifest entry it belongs to — never by hand in the sources directory.
• Pins carry an update class (fast-moving tools are checked weekly, steady ones fortnightly, nixpkgs-native packages ride the nixpkgs refresh only). Automated checks open update PRs only when the new revision passes its smoke check — freshness never lands unreviewed.
• The nixpkgs lock stays put between scheduled refreshes. The lockfile is the version: nothing re-links, re-installs or re-downloads in the background. Everything — the OS, the tools, the menu, the docs — is expressed in flakes, with no state outside the store and no imperative install steps to drift an environment.

4.2 Software-only posture

The classic layer is software-only by scope: no hardware-hacking, wifi/RF or Bluetooth attack stacks ship (the SDR niche stays opt-in because signal datasets feed ML research). Network-infrastructure exploitation arsenals and social-engineering packs are excluded — the distribution re-aims the integrated-distro shape at the AI-security pillar set rather than porting Kali’s full inventory.