Date: 2026-05-27
Status: Design approved
Location: ~/Documents/repos/gen-aspects/examples/demo/
Libraries exercised: all 8 (gen-algebra, gen-schema, gen-aspects, gen-scope, gen-graph, gen-select, gen-bind, gen-derive)
A self-contained flake that exercises every gen library in a realistic scenario: a web application deployment with environments, hosts, services, policies, settings composition, and queries. Not a toy — a miniature version of what den v2 will do.
Date: 2026-05-27 Status: Design approved Libraries affected: gen-schema, gen-aspects, gen-algebra, gen-scope Consumer: den (wiring only — no gen-level domain concepts) Supersedes: 2026-05-27-gen-settings-design.md (draft)
Date: 2026-05-27 Context: clan-core#6655 — "The future and scope of Clan relative to other Nix-based self-hosting solutions"
Related: Den × Clan Collaboration Proposal
Related: Gen Ecosystem Integration Opportunities for Clan-core
Related: [den/gen-internal] Den Pragmatic Fleet Features — Learning from Clan, Bridging Strategy
Date: 2026-05-27
Companion to: 2026-05-27-clan-gen-integration-analysis.md (what gen offers Clan)
This document: What den should borrow (functional gaps only), the bridging strategy, and the roadmap.
Den and Clan solve overlapping problems differently. Den has ~100s of users and strong formal foundations: scope graphs, algebraic composition, demand-driven evaluation, multi-class output, and the ability to materialize any output target (NixOS, darwin, homeManager, terraform, devshells, packages, treefmt, nix-unit, flake-parts perSystem) from a single aspect graph. Clan has a slightly larger user base and launched earlier, but forces NixOS module evaluation for every entity and can only target nixos/darwin.
Date: 2026-05-27 Context: Analysis of clan-core architecture against the gen library ecosystem to identify where gen's formal foundations could strengthen Clan's fleet management.
Clan-core is a mature Nix framework for declarative multi-host fleet management. It provides an inventory-driven model where machines are declared, services define roles, and instances bind roles to machines. 30+ production services ship with the framework, alongside a CLI, GUI app, and Python tooling ecosystem. It uses flake-parts, NixOS modules, and a structured scope key system (buildScopeKey/checkScope) for export isolation.
Gen is an eight-library ecosystem providing formal foundations for configuration composition: scope graphs (Neron 2015), algebraic graph composition (Mokhov 2017), demand-driven attribute grammar evaluation (Vogt 1989, Sloane 2010), intensional id
Date: 2026-05-25
Status: Draft
Depends on: gen (pure tier: mkIntensional, intensionalEq) for core; gen-select for adapter tier
gen-derive is a rule dispatch engine for guarded graph transformations. Given a set of rules (condition + action producer), a position in a graph, and a context, gen-derive answers: "which rules fire here, and what actions do they produce?" It owns the dispatch protocol, phase ordering, fixpoint convergence, conflict resolution, and rule dedup. It does NOT own the action vocabulary — actions are opaque tagged values whose semantics belong to the caller.
Date: 2026-05-25
Status: Approved
Depends on: gen (pure tier only: mkIntensional, intensionalEq)
gen-select is a pattern-matching library for attributed graph positions. Given a node and its graph context (expressed as accessor functions), a selector answers: "does this node match?" Pure library — no knowledge of NixOS, aspects, scopes, or configuration. Consumers bring their own graph topology via accessor functions.
A standalone library for injecting external bindings into NixOS/home-manager module functions. Handles partial application, merge conflict detection, lazy contracts, provenance tracking, thunk deferral, signature inference, identity wrapping, and binding arg stripping. The bridge between "scope-computed values" and "the NixOS module system."
NixOS module functions take { config, lib, pkgs, options, ... }: — arguments provided by evalModules. External systems (scope-graph evaluators, rule engines, configuration generators) compute additional context that modules need: structural data (host, user), computed flags (isNixos, isDarwin), and aggregated data (firewall, http-backends).
Today this is done by den's class-module.nix (~250 lines) and wrap-classes.nix (~190 lines). The logic is generic — it has no knowledge of aspects, policies, or scope graphs. It only knows: "here's a module function, here are extra args, mak
| { denTest, ... }: | |
| let | |
| mockMaidModule = | |
| { lib, ... }: | |
| { | |
| options.users.users = lib.mkOption { | |
| type = lib.types.attrsOf ( | |
| lib.types.submodule { | |
| options.maid = lib.mkOption { | |
| type = lib.types.submoduleWith { |